#c #hash #checksum #portable-executable #recompile
#c #хэш #контрольная сумма #переносимый-исполняемый #перекомпилируйте
Вопрос:
Итак, я пытаюсь выяснить, как заставить мой exe иметь тот же хэш-код / контрольную сумму при его перекомпиляции. Я использую FastSum для генерации контрольной суммы. В настоящее время никаких изменений в коде не вносится, я просто перестраиваю проект в VS, и контрольная сумма получается другой. Код написан на c .
Я не знаком с использованием хэш-кодов и / или контрольных сумм таким образом, но я провел некоторое исследование и кое-что прочитал о необходимости согласованного GUID. Но я понятия не имею, как это будет связано с программой генерации контрольной суммы…
Что ж, я оставлю все как есть, заранее спасибо.
Ответ №1:
Вы изучили различия между бывшими? Я подозреваю, что компилятор / компоновщик вставляет дату или время в двоичный файл, и в результате каждый двоичный файл будет отличаться от другого. Или могло быть хуже, иногда компиляторы / компоновщики создают статические таблицы в своей собственной системной памяти, а затем копируют это в двоичный файл, скажем, у вас есть что-то в 9 байтах, и по соображениям выравнивания компилятор предпочитает использовать 12 байт в двоичном файле, я видел, как компиляторы / компоновщики берут все 3 байта, имеющиеся в системной памяти этого компьютера, и копируют это в файл. В идеале вы хотели бы, чтобы инструменты обнуляли память, которую они используют для такой вещи, чтобы вы получали повторяемые результаты.
По сути, выполните двоичное различие между файлами, после чего вы должны выяснить, почему они не совпадают.
Комментарии:
1. Кроме того, даже если компилятор / компоновщик не вставлял информацию о дате / времени, любая ссылка в коде на
__DATE__имела бы тот же эффект.2. Чувак, я надеюсь, что это не имеет никакого отношения к решениям компилятора / компоновщика! Я знаю, что в написанном нами коде нет ссылки на [code]__DATE__[/code], но это не значит, что он не используется, я думаю. Я сделаю двоичное различие и посмотрю, что получится, спасибо, ребята.
3. Я сделал двоичную разницу, и есть два разных раздела. Один находится в самом начале, я предполагаю, что это какая-то часть заголовка, но я не знаю, как точно определить, что это такое. Есть строка «Эта программа не может быть запущена в режиме DOS». новая строка, затем «$ 00000000000000», и следующий фрагмент — это то, где находится первое различие. Вторая, состоящая в основном из текста, находится примерно на полпути к данным и должна иметь какое-то отношение к тому, что компилятор перемещает данные просто потому, что ему так кажется…
4. используйте шестнадцатеричный дамп -C или что-то подобное, чтобы проверить эту область, если это дата и время ascii, это должно бросаться в глаза и быть очевидным.
5. Ну, похоже, это не дата / время, единственное, что выделяется в этом разделе, — это PE, который, как я предполагаю, является переносимым исполняемым файлом, важно это или нет, я не знаю. Но я полагаю, что если другие части данных на полпути меняются, я мало что могу сделать.
Ответ №2:
Насколько я помню, формат EXE включает метку времени сборки, поэтому хэш exe-файла, включая эту метку времени, будет меняться при каждой перекомпиляции.
Комментарии:
1. Хм, хорошо, возможно, я рассмотрю возможность исправления временной метки. Спасибо!
Ответ №3:
Это управляемый двоичный файл? В управляемых двоичных файлах есть раздел GUID, который меняется от сборки к сборке, и вы мало что можете сделать, чтобы остановить это.
Вы можете лучше рассмотреть изменения в вашем двоичном файле, выполнив команду «link / dump /all [имя файла]» или «link / dump / disasm [имя файла]». Опция /all покажет вам все шестнадцатеричные значения, а также их эквивалент в формате ascii, в то время как опция / disasm разберет код и покажет его вам в сборке, что может быть проще для чтения, но может игнорировать некоторые тривиальные различия, которые могли привести к изменению хэша.