Издательский дом ООО "Гейм Лэнд"СПЕЦВЫПУСК ЖУРНАЛА ХАКЕР #57, АВГУСТ 2005 г.

Навесная защита

Bit-hack (bit-hack@mail.ru)

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


Разбор полетов среди систем защиты и упаковки win32 PE-файлов

Что такое навесная защита, каковы ее достоинства и недостатки, чем упаковщики отличаются от протекторов и зачем нужны скрэмблеры – обо всем этом ты узнаешь из этой статьи. Кроме того, сможешь научиться писать скрэмблер UPX самостоятельно.

Немного теории

Для начала кратко опишу принципы работы упаковщиков. Обычно они "навешиваются" на уже скомпилированные PE-файлы (win32 Portable Executable), уменьшая их размер и частично обеспечивая защиту исполняемого кода и некоторых других составляющих PE-файла. Стоит, впрочем, отметить, что существуют упаковщики, которые выполнены, например компоненты Delphi, но такие типы упаковщиков мы сегодня рассматривать не будем, так как нам не требуется привязка к одному языку.

Итак, принцип работы рассматриваемых упаковщиков (операции с файлом, по шагам):

1. проверка файла (на принадлежность файла к win32 PE, на упакованность, на возможность сжатия);

2. упаковка кода и некоторых других частей файла;

3. добавление распаковщика;

4. правка некоторых полей PE-заголовка (для дальнейшей работоспособности файла).

Но иногда попадаются упаковщики, которые еще сильнее изменяют файл, например UPX, перестраивающий весь файл во внутренний формат. В этом случае запуск происходит по еще более простой схеме (для упаковщиков):

1. Выполнение распаковщика.

2. Переход на OEP (оригинальная точка входа в программу), то есть на тот код, с которого и начиналась незапакованная программа. На ассемблере такой переход выглядит примерно так (пример на UPX):

POPAD Я Восстановили все процессорные регистры

JMP 01012475 Я Перешли на ОЕР

Принцип работы распаковщиков для протекторов:

1. Сохранение всех процессорных регистров и (иногда) флагов.

2. Сбор служебной информации.

3. Подготовка протектора к работе (заполнение необходимых таблиц, значений).

4. Выполнение кода для обнаружения отладчиков (редко помогает, так как у реверс-инженеров уже написаны средства для борьбы с таким кодом, точнее не с кодом, а с тем, как этот код определяет отладчик).

5. Проверка CRC (циклический контроль избыточности). CRC используется для проверки файла на изменение.

6. Выполнения кода расшифровщика (часто расшифровщик не один), напичканного антиотладочным кодом и мусором.

7. Создание таблицы импорта (обычно она сильно видоизменяется, создаются переходники на оригинальные функции, также функции эмулируются, копируются).

8. Стирание всего кода протектора (это не всегда - зависит от протектора).

9. Продолжение нормального выполнения программы.

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

Содержание  Вперед на стр. 057-088-2