Как определить, одинаковы ли два exe-кода? - PullRequest
4 голосов
/ 09 апреля 2010

Есть ли способ определить, не имеют ли два EXE-файла (скомпилированные из VS.Net 2008 для C ++ / MFC) какие-либо изменения уровня кода между ними, т. Е. Чтобы узнать, что не было никаких изменений оператора.

Это для целей соответствия, когда мой поставщик отправляет мне исполняемый файл, якобы без изменений, внесенных в код со времени нашей последней проверки.

Есть ли инструмент для проверки, что это так?

Приветствия

Ответы [ 7 ]

4 голосов
/ 09 апреля 2010

Вы можете использовать диссемблер, чтобы разобрать исполняемый файл обратно в сборку и сравнить с обычным текстовым инструментом сравнения.

Но даже это не будет на 100% точным. Процесс компиляции не без потерь, и большая часть информации теряется или необратимо преобразуется при компиляции кода C ++.

В частности, различные настройки компилятора могут генерировать совершенно разные машинные коды из одного и того же источника. Различные компиляторы и даже разные версии или уровни пакетов обновлений / исправлений одного и того же компилятора могут создавать совершенно разные машинные коды из одних и тех же исходных файлов.

Другой вопрос: почему они даже отправляют вам exe обратно "якобы без изменений"? Если это так, почему бы вам не использовать тот, который у вас был изначально?

2 голосов
/ 09 апреля 2010

Для бинарного аудита одним из лучших практических инструментов, которые вы должны иметь, является Интерактивный дизассемблер , также известный как IDA Pro . Это необходимо иметь, когда вам нужно провести аудит без доступа к исходному коду. Кто-то, кто опытен в использовании IDA Pro, сможет с достаточной долей уверенности сказать вам, если в исходном коде произошли какие-либо изменения, кроме поверхностных. В этом контексте поверхностные изменения будут включать такие вещи, как переименование переменных в исходных файлах или изменение порядка объявлений и определений переменных, функций или классов. Они смогут сообщить вам, имеют ли базовые блоки кода, составляющие исполняемые файлы, различия между ними, достаточно существенные, чтобы их можно было назвать подозрительными, в том смысле, что существует высокая вероятность того, что различия указывают на разницу на уровне источника.

Я говорю более или менее, потому что есть несколько способов, которыми два исполняемых файла, сгенерированные из одного и того же дерева исходных текстов, могут все же иметь едва различимые, а иногда и не столь тонкие различия между собой. Факторы, которые могут повлиять на генерацию исполняемых файлов, включают:

  • настройки оптимизации компилятора
  • различные версии библиотек, с которыми связаны исполняемые файлы
  • изменения в заголовочных файлах, внешних по отношению к исходному дереву, которые использовались для построения исполняемых файлов, которые были включены препроцессором C ++ до этапа компиляции
  • исполняемый файл, который манипулирует своим собственным кодом во время выполнения, что может включать в себя распаковку или расшифровку на лету некоторой части себя в некоторой области памяти, в которую он может перейти к

И этот список может продолжаться некоторое время.

Возможен ли тип бинарного аудита, который вы предлагаете? Да, человек с достаточными знаниями и навыками может сделать это. Хакеры делают это все время. И если человек, проводящий анализ, достаточно хорош, он сможет точно сказать вам, насколько он уверен в своей оценке.

В конечном итоге это становится вопросом осуществимости. Сколько вы готовы потратить на этот аудит? Найм или заключение контракта с кем-то, кто может сделать это, может выдвинуть за рамки бюджета, выделенного на такой аудит, достаточно ли денег для этого? Насколько сложным является программное обеспечение, которое вы тестируете? Каков характер ваших отношений с вашим поставщиком?

Этот последний вопрос важен, потому что, если в его интересах пройти этот аудит, и они осознают это, они могут быть готовы помочь вам в определенной степени. Это может быть в форме отладочных символов, списка использованных опций компилятора или некоторых других артефактов процесса сборки, которые они готовы раскрыть. Все вышесказанное может быть очень полезным в любом анализе , где исходный код не становится доступным для целей анализа по любой причине. И если доступ к исходному коду доступен для этой цели, то все становится на порядок проще для анализа.

Если вы хотели бы заняться этим самостоятельно, я бы порекомендовал вам две книги: Книга IDA Pro: неофициальное руководство по самому популярному дизассемблеру в мире от Chris Eagle и Руководство шеллкодера: обнаружение и использование защитных отверстий Криса Энли, Джона Хисмана, Феликса Линдера и Херардо Ричарте.

Наконец, методы и инструменты, разработанные для анализа такого рода, который поможет вам, все еще являются очень активными областями исследований. Ваш вопрос либо идет глубже, чем вы можете себе представить, либо я его неправильно понял. Тщательное рассмотрение вашего вопроса, даже с практической точки зрения, игнорирование теории, которая согласуется с ним, может и действительно может заполнить многие книги.

Надеюсь, вы найдете хоть какую-то часть этого полезного. Удачи!

2 голосов
/ 09 апреля 2010

Автоматизируйте тестирование, чтобы тесты можно было быстро перезапустить.

Несмотря на то, что это небольшое заявление, это большое обязательство

1 голос
/ 10 апреля 2010

Загрузите exes в программу сравнения гексагонов (BeyondCompare пород!).

Если есть какие-либо нетривиальные изменения (при условии, что настройки компилятора не изменились), их будет довольно легко найти. Если это просто вопрос временных меток и т. Д., Это может быть довольно очевидно.

Это определенно не надежно, но это был бы мой первый шаг.

1 голос
/ 10 апреля 2010

Теперь добавьте шаг после сборки, который сгенерирует MD5 исходных файлов, и добавьте его в ресурс VERSION (чтобы его можно было увидеть в свойствах exe).
Это будет стоить вам 2 или 3 человеко-дня.

1 голос
/ 09 апреля 2010

Если вы контролируете источник, просто не отправляйте exe-файлы, с которыми не связана правильная информация о версиях.

Если по какой-то причине они создают свои собственные exe-файлы, я бы предложил использовать шаг сборки, который они должны использовать, чтобы встроить номер версии управления версиями в информацию о версии.

Если они не используют ваш шаг сборки (который вы можете обнаружить), то вы предполагаете, что они разные.

Большинство систем контроля версий (например, таких как SVN) позволяют вам выполнить этап сборки, который скажет, находится ли код в измененном состоянии или нет. Вы могли бы встроить эту информацию в строку во встроенном ресурсе для exe. Затем вы просто извлечете этот ресурс.

Итак, все сводится к тому, чтобы все сборки происходили из вашего пользовательского сценария сборки.

1 голос
/ 09 апреля 2010

Вы всегда можете выполнить MD5sum для исполняемых файлов.Это не скажет вам, являются ли они логически эквивалентными или разными, просто существует разница.

Я не уверен, решит ли это вашу проблему, поскольку вы, возможно, ищете инструмент логического сравнения.

...