LINUX.ORG.RU
ФорумTalks

Хешсумма бинарника с его же хешсуммой внутри него.

 , ,


0

2

Можно ли как-то запихать вовнутрь бинарника его хешсумму уже после компиляции, то есть странная вещь, если я запихаю хешсумму бинарника БЕЗ строки с хешсуммой внутрь, то его хешсумма после компиляции сменится.

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

Мне бы хотелось, чтобы я мог встроить в бинарник его же хешсумму, не вычисляя её как-то при запуске, а именно внутри него должно быть зашито значение хешсуммы, чтобы оно совпадало с тем, что выдаст условный md5sum.

Сломал голову о том, как это реализовать без применения машины времени.



Последнее исправление: cheetah111v (всего исправлений: 2)

Примерно так работает майнинг биткоинов :)

Если у тебя криптографически стойкий хэш, то за приемлемое время задачу вряд ли получится решить.

Puzan ★★★★★
()
Последнее исправление: Puzan (всего исправлений: 1)

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

Leupold_cat ★★★★★
()
Последнее исправление: Leupold_cat (всего исправлений: 5)

а вообще странная задача, проверка хэшей задача внешняя по отношению к проверяемым данным. Разве что пишешь какой-то хитрый пакер и шифер для малвари.

linuxoidspb
()
Ответ на: комментарий от cheetah111v

По любому надо будет либо паковать бинарь пакером, либо использовать внешние средства проверки хэша

linuxoidspb
()
Ответ на: комментарий от cheetah111v

1. Компилируешь со случайной строкой вместо хеша
2. Если строка встречается в бинарнике больше одного раза goto step 1
3. Полный перебор

ratvier ★★
()

Когда-то хотели внедрить патчи в ядро для верификации подписанных ELF-ов, но не сложилось, хотя фича была бы очень полезна в некоторых случаях.

ELF Executable Signing/Verification Comes For Linux https://www.phoronix.com/news/MTI3NTY

linuxoidspb
()
Ответ на: комментарий от ratvier

Это будет типа поиск коллизии? Вероятность 0.00000000000000000000000000000000000003%. Учитывая, что одна итерация компиляции это 10 минут, то 6.341958397x10 в 35 степени, лет.

cheetah111v
() автор топика

Такое работает с простыми контрольными суммами типа CRC32. Можно посчитать по формуле или добавить в конец файла несколько байт, чтобы сделать нужный хеш. Так делали в древности.

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

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

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 1)
Ответ на: комментарий от cheetah111v

Не-не-не, достаточно 1.00000000000000000000000000000000000003 компиляций, дальше просто инкрементировать и проверять хеш.

ratvier ★★
()
Ответ на: комментарий от cheetah111v

Оно не решает, а объясняет почему у тебя это не получится сделать.

ergo ★★★
()

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

bender ★★★★★
()
Ответ на: комментарий от KivApple

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

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

firkax ★★★★★
()

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

firkax ★★★★★
()

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

aiqu6Ait ★★★★
()
Ответ на: комментарий от firkax

Да, как вариант подсчитать хэшсуммы всех секций .text , .data, .bss, и прочих важных секций если такие имеются и запихать хэш-суммы куда-нить в ELF-header.

При запуске программа считывает путь к своему бинарнику (argv[0]) и считывает ELF-header, хэш-суммы секций и смещение к секции и размер секции

linuxoidspb
()
Последнее исправление: linuxoidspb (всего исправлений: 1)
Ответ на: комментарий от firkax

Перебор же хотя бы обычного sha256 уже невообразимо дольше чем любой майнинг, не хватит и миллиарда лет.
не хватит и миллиарда лет

Ставите на то что человечки в ближайшем времени убьют себя ап стену?

anc ★★★★★
()
Ответ на: комментарий от aiqu6Ait

машина времени тебе кстати не поможет

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

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от anc

Имелось ввиду на том оборудовании что у автора есть или может быть в теории. А так то да, можно пофантазировать насчёт вычислительных мощностей будущего.

firkax ★★★★★
()
Ответ на: комментарий от linuxoidspb

Лучше всё-таки посчитать хеш всего файла, временно заменив в нём эти 32 или 64 байта (где сохранить хеш потом) нулями. А то, даже обеспечив неизменность самих секций, можно с помощью заголовков вне их тоже что-то существенное изменить.

firkax ★★★★★
()

А другие варианты идентификации файла не рассматриваются?

eyrell
()
Ответ на: комментарий от firkax

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

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

linuxoidspb
()
Ответ на: комментарий от linuxoidspb

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

firkax ★★★★★
()

c crc16/32 может выйдет. Там вроде как можно посчитать в лоб CRC(y) от CRC(xy) и CRC(x). Существуют недлинные операции конкатенации. Для криптограф.хешей нет

собственно чем и отличаются простые контрольные суммы от криптографических хешей.

то есть в бинарник можно посчитать «довесочек» чтобы crc32 был строго заданным. А для md5 такой фокус не пройдёт

MKuznetsov ★★★★★
()

По-нормальному никак. Перед вычислением хэша бинарника забивай места, где хранится хэш нулями. Но тогда тебе понадобится собственная утилита для вычисления хэша, а не стандартная md5sums и аналоги.

ox55ff ★★★★★
()
Ответ на: комментарий от firkax

А так то да, можно пофантазировать насчёт вычислительных мощностей будущего.

Эти «фантазии» зачастую приходят быстрее чем нам думается.

anc ★★★★★
()
Ответ на: комментарий от firkax

Да и про подпись речи не было, только про сумму.

сумма без подписи деньги на ветер

linuxoidspb
()
Последнее исправление: linuxoidspb (всего исправлений: 2)
Ответ на: комментарий от anc

Ставите на то что человечки в ближайшем времени убьют себя ап стену?

Как вообще что-то типа человечества может протянуть миллиард лет? Тут уже 100 лет может не хватить, ну хорошо, 1000, а миллиард это неприлично большое число.

goingUp ★★★★★
()

Так вполне себе делают.

  1. Пихаешь хешсумму, покрывающую все ELF-секции, кроме той, в которой хеш-сумма.
  2. Пихаешь хешсумму, рассчитанную с нуля и вместо хешсумму, при верификации её тоже зануляешь.
t184256 ★★★★★
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)