Криптоанализ в деле реинжиниринга кода

Не понял вопроса. Если конкретная программа – одно дело, к тому же если кода мало – можно порыться в дебаггере, и потом начинать переписывать потихоньку. Кто-то умудрялся компиллировать "сишные" листинги IDA. Если так – то на счет криптоанализа – нужно думать о защите реверсируемого .ехе'шника – одно дело, если там простой UPX стоит, а совсем другое если там VMP и защита на этапе компиляции. Но опять таки – видимо я сути вопроса не понял..

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

Конкретной программы нету. Интересует: возможно ли какие-то методы применить и что для этого потребуется от простого к сложному, от теории к практике. Мои предположения пока заканчиваются на том, что исходники нужно формализовать и не надо забывать о hex-файлах. Копание в дебаггере, IMHO, морально устарело.

Копание в дебаггере, IMHO, морально устарело.

Обоснуй) Если говорить о закрытых сорцах, да еще и о винде – то никогда не устареет, точно так же как и сам asm.
Снятие защит, вырезание "ненужных" кусков кода, инфицировани\деинфецировние, полиморф, затирание сигнатуры и тд – только дебаг.

что исходники нужно формализовать и не надо забывать о hex-файлах

Ты можешь конкретную задачу привести в пример? Ну или четко гипотетически сформулированную.

Свои обоснования оставлю лучше при себе :) Легко спорить со скромным тружеником информационных полей. Поэтому сразу дал ссылку на труды ИСП РАН(уж что нашел). Результат научного подхода нескольких десятилетий:

Задача декомпиляции была поставлена в 60-е годы XX века сразу же, когда стали широко применяться компиляторы с языков высокого уровня, но не утратила своей актуальности и по сей день [2]. Эта задача не решена в полной мере до сих пор в силу ряда трудностей принципиального характера.

Хотя понятно, что asm не устареет, раз это язык процессора.


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

Легко спорить со скромным тружеником информационных полей

Я сам к IT отношения вообще не имею, да и не спорю с тобой.

Хотя понятно, что asm не устареет, раз это язык процессора.

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

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

Увы, но я правда не понимаю сути вопроса, может другие поймут и я попробую подключится к диалогу.

Ну, да. Скажем так: просто с отладчиком уже достаточно покопались и сформулировали "трудности принципиального характера". Например:

В частности, при компиляции программы из языка высокого уровня в язык ассемблера характерно отображение «многие к одному» концепций языка высокого уровня в концепции языка ассемблера, и, как следствие, однозначное восстановление программы на языке высокого уровня становится зачастую невозможным.

Отображение «многие к одному» ещё применяется в архиваторах. Совместное использование сжатия данных с шифрованием повышает стойкость к взлому, как я понял. При этом наработаны методики криптоанализа, т.е. сформулированы условия, при которых такой взлом возможен. Вот как бы эти условия применить в реинжиниринге кода?

Это не согласуется с современными направлениями криптографии, которая бракует алгоритмы на стадии сертификационного криптоанализа /comment65563.

И вообще, сжатие без потерь — инъективная функция. Какие «многие (элементы множества) к одному (подмножеству)»? Может, наоборот.

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

Да ехешники то в любом случае пакуются, можешь из кода использовать либы aPlib или LZMA, можешь сторонними пакерами – тот же UPX, который я упомянул. Ну и протекторы тоже пакуют, хотя они больше довешивают, чем сжимают, но у них суть не в сжатии. "Условия, при которых такой взлом возможен" – да без проблем, открываешь OllyDbg, суешь туда ехешник, ищешь ОЕР, ставишь там Break Poin трассируешь дальше, снимаешь дамп, восстанавливаешь импорт – все, ехешник распакован. А защиту обобщать точно нельзя. да и пакеры – тоже в общем, просто с ними проще в разы дела обстоят.

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

Проблема в том, что на момент упаковки часть информации уже утеряна.

С точки зрения криптоанализа восстановлению подлежит вся имеющаяся информация или изъятие ее части – это полный облом?
Например, имеем слово абракадабра
зашифровали и получили y7uhtjhf65j
изъяли ее часть y7.htjhf65j (понятно, что точка – это тоже информация)
получили аб акадабра или без точки восстановлению не подлежит?

Ну и что? Конечная цель, как правило, — восстановить алгоритм, а не конкретный использованный исходник.


Обфускация кода не является шифрованием, а деобфускация и восстановление алгоритма не является расшифрованием или криптоанализом. Так всё-таки, что общего между криптоанализом и реверсингом?


+1

Чье правило? Читайте тему внимательней.

Зачем восстанавливать исходник на ЯП высокого уровня? В чём его ценность? Ценность алгоритма я понимаю, это мне даёт точные данные о том, как работает программа, а вот ценности исходника я не вижу.

Для формальности и наглядности алгоритма. Или предпочитаете описывать алгоритм высоким пушкинским слогом?

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