Есть ли способ определить, не имеют ли двух EXE (скомпилированных из VS.Net 2008 для C++/MFC) никаких изменений на уровне кода между ними, т. Е. Для того, чтобы знать, что изменений инструкции не было.Как узнать, являются ли два exe одинаковыми по коду?
Это соответствует требованиям, когда мой поставщик отправляет мне exe, якобы без изменений, внесенных в код с момента последнего тестирования.
Есть ли инструмент, чтобы проверить, что это так?
Приветствия
Вы можете использовать лицемер разобрать исполняемый файл обратно в сборку и сравнить с обычным инструментом текста дифф.
Но даже это не будет на 100% точным. Процесс компиляции не является без потерь, и большая часть информации теряется или необратимо трансформируется при компиляции кода на C++.
В частности, различные настройки компилятора могут генерировать значительно отличающийся машинный код от точно такого же источника. Различные компиляторы и даже разные версии или уровни пакета обновления/исправления , то же самое компилятор может производить совершенно разные машинные коды из тех же исходных файлов.
Другой вопрос: почему они даже отправляют вам exe обратно «якобы без каких-либо изменений»? Если это так, почему бы вам просто не использовать тот, который был изначально?
+1, если они не могут оправдать обновление, продолжайте использовать проверенную/заверенную версию –
Если поставщик этого EXE является Microsoft, вы не можете использовать дизассемблер в соответствии с EULA. –
@ Kirill: «для целей соблюдения» предлагает юридическое обязательство, которое обычно превосходит договорные условия. Microsoft EULA не может заставить вас нарушить закон. (IANAL, поэтому обратитесь к местному эксперту по вопросам соответствия) – MSalters
Вы всегда можете выполнить MD5sum в исполняемых файлах. Это не скажет вам, являются ли они логически эквивалентными или разными, просто что существует разница.
Я не уверен, что это решает вашу проблему, так как вы можете искать логический инструмент сравнения.
Использование MD5 * всегда * генерирует разные контрольные суммы даже при компиляции того же проекта. Я предполагаю, что компоновщик добавляет в exe некоторые специфичные для времени вещи. – yumcious
Если вы контролируете источник, просто не отправляйте exes, у которых нет соответствующей информации о версии, связанной с ними.
Если по какой-то причине они создают свои собственные exes, я бы предложил создать шаг сборки, который они должны использовать, чтобы вставить номер версии управления версиями в информацию о версии.
Если они не используют ваш шаг сборки (который вы можете обнаружить), вы предполагаете, что они разные.
Большинство систем контроля версий (например, SVN, например) позволят вам создать шаг сборки, который скажет, находится ли код в измененном состоянии или нет. Вы можете включить эту информацию в строку во встроенном ресурсе для exe. Тогда вы просто извлечете этот ресурс.
Итак, все, что происходит, происходит из вашего пользовательского сценария сборки.
Сценарий выглядит следующим образом. Предполагается, что приложение не зависит от языка, т. Е. Строки используют ресурсы (на наш взгляд, не считаются логикой). В начальных тестах мы используем английский язык, и поставщик будет поставлять другие языковые версии позже, но встроен в качестве ресурсов строки. Нам просто нужно было убедиться, что не было никаких изменений кода, когда они доставили нам новый exe. Мы в порядке, если есть изменения в комментариях (не в exe в любом случае, переименованные переменные) или ресурсы. – yumcious
@yumcious: Используйте что-то вроде gettext, чтобы отметить ваши строки. Затем создайте с ним языковые файлы для доставки вашему клиенту. Затем ваш клиент отправит вам только переведенные языковые файлы. Таким образом, вы можете разрабатывать независимые от языковых файлов, и их нужно перевести только один раз для каждой уникальной строки, которая появляется. –
круто, спасибо за наконечник. Я передам его. – yumcious
Автоматизируйте свое тестирование, чтобы тесты могли быть быстро перезапущены.
Несмотря на то, что это небольшое заявление, чтобы сделать, это большое дело
Иногда поставщик отправлял нам неправильные ресурсы (версия, авторское право и т. Д.) Для тестирования. Затем они * внезапно * вспомнили, что им нужно исправить эти ТОЛЬКО ПОСЛЕ того, как мы завершили приемочное тестирование. Нам просто нужен механизм, чтобы доказать, что этот поставщик не пропустил какой-либо код незаметно для использования в производстве. – yumcious
Для бинарного аудита, один из руки вниз лучшие инструменты, которые вы обязательно есть, это Interactive Disassembler, также лучше известный как IDA Pro. Это необходимо, когда вам нужно провести аудит без доступа к исходному коду.Кто-то, кто владеет IDA Pro, сможет с достаточной уверенностью сказать вам, если в исходном коде было нечто большее, чем поверхностные изменения. В этом контексте поверхностные изменения охватывали бы такие вещи, как переименование переменных в исходных файлах или изменение порядка объявлений переменных, функций или классов и определений. Они смогут рассказать вам, есть ли у базовых блоков кода, составляющих исполняемые файлы, различия между ними достаточно существенными, чтобы их можно было помечать как подозрительные, в том смысле, что существует высокая вероятность того, что различия указывают на разницу на уровне источника.
Я говорю более или менее, потому что существует несколько способов, в которых два исполняемых файла, сгенерированных из одного и того же исходного дерева, могут по-прежнему иметь тонкие, а иногда и не столь тонкие различия между собой. Факторы, которые могут оказать влияние на генерацию исполняемых файлов включают: настройки оптимизации
И этот список может продолжаться некоторое время.
Является ли вид бинарного аудита, который вы предлагаете? Да, человек с достаточными знаниями и навыками мог бы это сделать. Хакеры делают это все время. И если человек, делающий анализ, достаточно хорош, они смогут точно сказать, насколько они уверены в своей оценке.
В конечном счете, вопрос будет осуществлен. Сколько вы готовы потратить на этот аудит? Наем или заключение контрактов с кем-то, кто может это сделать, может выходить за рамки того, что предусмотрено бюджетом для такого аудита, достаточно ли денег для этого? Насколько сложно тестировать программное обеспечение? Какова природа ваших отношений с вашим продавцом?
Этот последний вопрос важен, потому что, если он в своих интересах пройти этот аудит, и они это осознают, они могут быть готовы помочь вам в определенной степени. Это может происходить в форме отладочных символов, списка используемых параметров компилятора или некоторых других артефактов процесса сборки, которые они готовы раскрывать. Предыдущие могут быть очень полезны при любом анализе , где исходный код не, который был сделан доступным для целей анализа по любой причине. И если доступ к исходному коду является доступным для такой цели, вещи становятся на порядок легче анализировать.
Если это то, что вы хотели бы заниматься самостоятельно, две книги, которые я рекомендовал бы это The IDA Pro Book: The Unofficial Guide to the World's Most Popular Disassembler Криса Орла и The Shellcoder's Handbook: Discovering and Exploiting Security Holes Криса Anley, Джон Heasman, Феликс Линдер и Херардо Richarte.
Наконец, методы и инструменты, разработанные для анализа такого рода, который поможет вам, по-прежнему являются очень активными областями исследований. Ваш вопрос либо проходит глубже, чем вы можете понять, или, возможно, меня неправильно поняли. Тщательная трактовка вашего вопроса, даже с практической точки зрения и игнорирования теории, которая идет вместе с ней, может и заполняет многие книги.
Надеюсь, вы найдете хотя бы часть этой полезной информации. Удачи!
Отношения с поставщиком не являются полным доверием, так как это финансовая платежная система. Перед развертыванием необходимо пройти набор тестов. Мы действительно не хотим повторять все тесты, если они «забыли» добавить соответствующий ресурс информации о версии и т. Д. И т. Д. Если произошли изменения в коде, то мы вправе отказаться от этого нового exe , или наказать поставщика за задержки. – yumcious
С этого момента добавьте шаг построения сборки, который будет генерировать MD5 файлов источников и добавить его в ресурс VERSION (чтобы вы могли видеть его в свойствах exe).
Это будет стоить вам 2 или 3 человеко-дней.
Загрузите exes в программу сравнения hex (BeyondCompare rocks!).
Если есть какие-то нетривиальные изменения (при условии, что настройки компилятора не изменились), их должно быть довольно легко подобрать. Если это всего лишь временные метки и т. Д., Это может быть довольно очевидным.
Это определенно не является надежным, но это был бы мой первый шаг.
Если у вас есть код и протестирован его, почему бы не скомпилировать его самостоятельно? Почему они даже отправили вам еще один exe без более проверяемого кода? – Karl
@Karl: Я ничего не вижу в вопросе, который подразумевает, что у искателя есть источник. Во всяком случае, для крупных, компонентных приложений не обязательно необычно, что новая версия содержит компоненты, которые были перестроены без изменений кода. – bk1e