Криптоанализ в деле реинжиниринга кода
Чем криптоанализ может помочь восстановлению программ с языка ассемблера в язык высокого уровня?
О текущем состоянии работ по восстановлению программ с языка ассемблера в язык высокого уровня можно ознакомиться, например, тут.
Для начала весь процесс компиляции, дизассемблирования и восстановление высокоуровнего кода можно разбить на этапы и выделить те, которые в наибольшей степени поддаются методам криптоанализа.
1. программа на яп Си;
2. препроцессорный листинг на яп Си;
3. программа на ассемблере;
4. объектный код;
5. исполняемый файл после линковки;
6. листинг дизассемблера;
7. восстановленная программа на яп Си.
комментариев: 1079 документов: 58 редакций: 59
комментариев: 301 документов: 8 редакций: 4
Вообще, говорят, что в вопросе содержится 80% ответа. Наверно, это среднестатистически. Когда знаешь ответ на 80%, то обычно не составляет особого труда поисковиком найти недостающее. Из всех методов криптоанализа мне полностью понятна только реализация методом шланга, когда можно попросить у разработчика исходники. Понимаю, что вопрос-угадайка, но любые размышления на эту тему приветствуются.
Конкретной программы нету. Интересует: возможно ли какие-то методы применить и что для этого потребуется от простого к сложному, от теории к практике. Мои предположения пока заканчиваются на том, что исходники нужно формализовать и не надо забывать о hex-файлах. Копание в дебаггере, IMHO, морально устарело.
комментариев: 1079 документов: 58 редакций: 59
Обоснуй) Если говорить о закрытых сорцах, да еще и о винде – то никогда не устареет, точно так же как и сам asm.
Снятие защит, вырезание "ненужных" кусков кода, инфицировани\деинфецировние, полиморф, затирание сигнатуры и тд – только дебаг.
Ты можешь конкретную задачу привести в пример? Ну или четко гипотетически сформулированную.
комментариев: 301 документов: 8 редакций: 4
Свои обоснования оставлю лучше при себе :) Легко спорить со скромным тружеником информационных полей. Поэтому сразу дал ссылку на труды ИСП РАН(уж что нашел). Результат научного подхода нескольких десятилетий:
Хотя понятно, что asm не устареет, раз это язык процессора.
Будем считать, что для любой задачи. Если несколько процентов из всего многообразия задач будут не решаемы, то можно оставить на потом. Например, я не вспоминал про уровни оптимизации кода. Если есть принципиальная возможность применить методы криптоанализа для любой целой программы, то зачем искать частный случай? Если же в данном случае криптоанализ не применим, тоже хотелось бы понять обоснования.
комментариев: 1079 документов: 58 редакций: 59
Я сам к IT отношения вообще не имею, да и не спорю с тобой.
Вот ты правильно сказал, соответственно отладчик никогда не устареет и копания в нем – тоже.
Увы, но я правда не понимаю сути вопроса, может другие поймут и я попробую подключится к диалогу.
комментариев: 301 документов: 8 редакций: 4
Ну, да. Скажем так: просто с отладчиком уже достаточно покопались и сформулировали "трудности принципиального характера". Например:
Отображение «многие к одному» ещё применяется в архиваторах. Совместное использование сжатия данных с шифрованием повышает стойкость к взлому, как я понял. При этом наработаны методики криптоанализа, т.е. сформулированы условия, при которых такой взлом возможен. Вот как бы эти условия применить в реинжиниринге кода?
комментариев: 9796 документов: 488 редакций: 5664
Это не согласуется с современными направлениями криптографии, которая бракует алгоритмы на стадии сертификационного криптоанализа /comment65563.
И вообще, сжатие без потерь — инъективная функция. Какие «многие (элементы множества) к одному (подмножеству)»? Может, наоборот.
комментариев: 1079 документов: 58 редакций: 59
Да ехешники то в любом случае пакуются, можешь из кода использовать либы aPlib или LZMA, можешь сторонними пакерами – тот же UPX, который я упомянул. Ну и протекторы тоже пакуют, хотя они больше довешивают, чем сжимают, но у них суть не в сжатии. "Условия, при которых такой взлом возможен" – да без проблем, открываешь OllyDbg, суешь туда ехешник, ищешь ОЕР, ставишь там Break Poin трассируешь дальше, снимаешь дамп, восстанавливаешь импорт – все, ехешник распакован. А защиту обобщать точно нельзя. да и пакеры – тоже в общем, просто с ними проще в разы дела обстоят.
комментариев: 301 документов: 8 редакций: 4
Откомпилированные исходники без поддержки отладки не имеют информации для восстановления исходного кода, "как следствие, однозначное восстановление программы на языке высокого уровня становится зачастую невозможным" в отличие от данных сжатых ариватором.
Проблема в том, что на момент упаковки часть информации уже утеряна.
С точки зрения криптоанализа восстановлению подлежит вся имеющаяся информация или изъятие ее части – это полный облом?
Например, имеем слово абракадабра
зашифровали и получили y7uhtjhf65j
изъяли ее часть y7.htjhf65j (понятно, что точка – это тоже информация)
получили аб акадабра или без точки восстановлению не подлежит?
Ну и что? Конечная цель, как правило, — восстановить алгоритм, а не конкретный использованный исходник.
Обфускация кода не является шифрованием, а деобфускация и восстановление алгоритма не является расшифрованием или криптоанализом. Так всё-таки, что общего между криптоанализом и реверсингом?
+1
комментариев: 301 документов: 8 редакций: 4
Чье правило
?Читайте тему внимательней.комментариев: 11558 документов: 1036 редакций: 4118