Обратная инженерия

Антон Hex Кукоба (xtin@ua.fm)

Спецвыпуск: Хакер, номер #057, стр. 057-012-3

Основные сведения, которые могут пригодиться при исследовании, лежит прямо в файле программы. Это отладочная информация, копирайты, строки, обработка ошибок и т.д. Файл с отладочной информацией часто содержит имена функций, типы их параметров, имена структур и еще много всего. Поэтому всегда нужно искать отладочные варианты. Копирайты поведают о версии использованных библиотек и их именах. Программы на Delphi - вообще отдельная тема: в файлах остаются имена и классов, и модулей. Разные строки в коде, оставленные программистом для ведения лога и анализа ошибок - это просто кладезь информации! Особенно если программист делает вывод ошибки типа "Error at function MYFUNCTION () pointer to XXXXXX object == NULL". Сразу понятно, какая это функция и какие параметры что в нее передают.

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

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

Анализ и систематизация

Общий подход. Перед реверсером всегда стоит дилемма: сверху или снизу? Подход сверху означает, что анализ начинается от обработчика какого-то события GUI, то есть реверсер понятия не имеет, как оно работает. Подход снизу означает анализ от одной из API. Такая проблема особенно актуальна, если исследуется какая-нибудь сложная система.

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

Для начала проведем разделение на уровни, чтобы знать, где мы находимся. Первый анализ должен быть поверхностным, сортировочного типа: "Тут у нас открытие, тут общение с GUI, тут шифрование, здесь реализация SQL".

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