Пишем упаковщик по шагам. Шаг девятый. Delay-loaded DLLs и Image Config.

Предыдущий шаг здесь.

Появилась новая версия библиотеки для работы с PE-файлами (0.1.8). Перекачайте и пересоберите ее.

Сегодня мы будем заниматься теми мелочами, на которые я в свое время забил при написании старого упаковщика. Наш распаковщик уже умеет всё, но есть пара мелких нюансов, которые неплохо бы допилить. Первое - это отложенный импорт (Delay-loaded). Этот механизм позволяет загружать необходимые PE-файлу библиотеки тогда, когда они реально становятся нужны, тем самым экономя время на загрузку образа в память. Механизм этот реализуется исключительно компиляторами/линкерами и никакого отношения к загрузчику не имеет, однако в PE-заголовке есть директория IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT, указывающая на данные отложенного импорта. Не знаю, используется ли это линкером и собранной программой, но загрузчику определенно пофиг. Но лучше оставим эту директорию, не будем ее обнулять. Уберем строку

Эта статья рассказывает о какой-то антинаучной хуйне.
Если вы — физик, химик, биолог или просто слишком хорошо помните школьную программу соответствующего курса, вам лучше ее не читать. В противном случае вы рискуете умереть от смеха. Мы предупредили.

I see what you did there.
Информация в данной статье приведена по состоянию на неизвестно когда. Возможно, она уже безнадёжно устарела и заинтересует только слоупоков.

С отложенным импортом всё. Следующая вещь, требующая внимания - это конфигурация загрузки образа. Есть такая директория в заголовке PE-файлов, IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG. Эта директория может содержать структуру IMAGE_LOAD_CONFIG_DIRECTORY32 для x86 PE-файлов (IMAGE_LOAD_CONFIG_DIRECTORY64 для PE+), которая предоставляет загрузчику информацию о том, как образ должен быть загружен. Еще там же содержится список адресов команд, имеющих префикс LOCK, который на однопроцессорных системах заменяется на NOP, а также список всех SEH-обработчиков (он используется для предотвращения SEH-хакинга и представляет собой список всех легальных и допустимых обработчиков исключений в PE-файле). Компиляторы MSVC++ последних версий иногда генерируют эту директорию, помещая в нее список SEH-обработчиков программы и указатель на свой security cookie (переменная для контроля переполнений и порчи буферов/стэка). Судя по исходникам ядра Win 2000, это все считывается загрузчиком, поэтому убивать напрочь директорию IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG не совсем правильно, хотя нарушений в работе PE-файлов после ее зануления я не наблюдал. Сохраним эту директорию, переместив ее во вторую секцию упакованного файла ("kaimi.io"). Первым делом уберем из кода упаковщика строку

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

строки

Эти строки считывают конфигурацию загрузки образа, если она имеется. Код аналогичен считыванию TLS. Далее, строку

меняем на

так как директорию конфигурации загрузки мы будем размещать там же, в секции "kaimi.io". Далее, аналогично меняем строку

на

и

на

и, наконец,

на

Далее, в структуру packed_file_info (файл structs.h) добавим пару новых полей:

Эти поля нам потребуются в распаковщике, а пока что в упаковщике мы их заполним, дописав после строк

следующие строки:

и после

такие строки:

Поясню, зачем это нужно. Загрузчик увидит, что наша таблица LOCK-префиксов состоит из единственного элемента, который указывает на поле lock_opcode структуры basic_info (мы ее так соберем, разумеется). На однопроцессорной системе опкод команды LOCK (0xf0), который мы записали в это поле, будет заменен на опкод инструкции NOP (0x90), и в распаковщике мы сможем проверить, нужно ли обрабатывать оригинальную таблицу LOCK-префиксов. Вообще, я не уверен, что эта функциональность присутствует в загрузчиках новых систем начиная от XP (похоже, что всем системам наплевать на эти таблицы), однако, пусть будет, мало ли всплывет. На самом деле, я и файлов-то с LOCK-таблицами не видел ни разу, и может мне просто нефиг делать. Хотя видел, в исходниках Win 2000, но об этом ниже. :D

Ладно, с правками покончено, переходим к пересборке директории конфигурации. Сразу после куска кода, ответственного за пересборку экспортов, дописываем следующий код:

Мы пересобираем директорию конфигурации загрузки, располагая ее в самом конце второй добавленной в упакованный файл секции. В опциях распаковщика мы указываем, что таблицу SE-обработчиков и LOCK-префиксов нужно пересобрать. Оригинальную таблицу LOCK-префиксов мы обработаем уже в распаковщике. С упаковщиком на этом все. Переходим к проекту распаковщика (unpacker). Такое впечатление, что снова поехали смещения, указанные в файле parameters.h, и не факт, что в предыдущем шаге они правильные (MSVC++ собирает проект так, как ему соблаговолится, оптимизируя по размеру, поэтому минимальные изменения могут привести к тому, что ассемблерные команды будут использованы другие). Поэтому я решил их раз и навсегда зафиксировать, сделав так:

Теперь у нас смещения ассемблерных команд [mov eax, 0x11111111] и т.д. будут всегда одинаковыми, так как опкод команд [mov eax/ecx/edx, число] всегда одинаков. Поправим под новый код значения смещений в файле parameters.h:

Далее перед кодом, обрабатывающим TLS, напишем следующий код:

Вот мы и закончили заниматься уже, по всей видимости, мало кому нужным функционалом, потому что современным одноядерным процессорам пофиг на префикс LOCK, и загрузчику пофиг на таблицу LOCK-префисков. :)
Забавно кстати, но EXE-файлы из Win 2000 нормально пакуются и работают под ней.

P.S. В Win2000 загрузчику тоже, кажется, насрать на LOCK-префиксы. Единственное, что он делает при загрузке - проверяет, чтобы по адресам LOCK-префиксов не были записаны опкоды инструкции NOP (0x90) для многопроцессорных систем. В то время Windows имела два ядра - однопроцессорное и многопроцессорное, которые подсовывались системе еще на этапе установки. С тех пор, по всей видимости, никто описанный функционал директории Load Configuration так и не реализовал, а поля с описаниями остались. Кстати, в Win2000 и сама структура другая совершенно, в ней отсутствуют некоторые поля. Моя библиотека для работы с PE-файлами ее считать не сможет. Но функционал в упаковщике я решил оставить. Теперь упаковщик самый правильный и соответствует открытой документации от Microsoft, хотя ей не соответствует их загрузчик. :) В конце-концов, пересборка самой директории конфигурации загрузки с сохранением адресов SEH-обработчиков - точно не лишнее.

Полный солюшен для этого шага: Own PE Packer Step 9

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *