Print This Post Пишем собственный упаковщик. Шаг 12 — Работа над ошибками

Пятница, 26. Апрель 2013
Раздел: C/C++, Windows, автор:

pack

Благодаря одному товарищу из комментариев в предыдущих постах касательно упаковщика выявился один занятный баг в коде, который я поспешил исправить. Комментатор, не разобравшись в деталях работы пакера, утверждал, что код, запакованный им, окажется неспособным работать с SEH при условии, что DEP включен. При таких условиях код работал хорошо (так как весь распакованный код в памяти находится в пределах одной-единственной секции PE-файла, помеченной как исполняемая. UPX имеет такую же логику работы.). Но случайно была обнаружена следующая ошибка: если программа собрана в MSVC++, использует SEH и имеет релокации, при первом же возникшем исключении она упадет с некоторой долей вероятности (точнее, если файл загрузился не по своему базовому адресу). DEP тут, конечно же, не при чем. Все дело оказалось в злополучной директории IMAGE_LOAD_CONFIG_DIRECTORY. Она создается линкером Visual Studio. Из полезной информации она содержит таблицу адресов (RVA) SE-обработчиков и указатель на внутреннюю переменную crt __security_cookie. Как выяснилось, эта директория нужна не только для внутренностей CRT (хотя она, кажется, как раз хотела плевать на эту структуру), но и системному загрузчику (по крайней мере, в Win7. WinXP, похоже, тоже плевал на эту директорию). Упаковщик, который я описываю, перемещает эту директорию в другую секцию (см. здесь). Поэтому исправить ошибку можно, добавив в таблицу релокаций, создаваемую упаковщиком, несколько записей, которые будут править адреса, указывающие на security cookie и таблицу обработчиков SEH, чтобы он мог считать интересующую его информацию из этой директории на этапе загрузки.

Помимо правки этой ошибки я обновил код упаковщика, чтобы он собирался с использованием последней на данный момент версией библиотеки для работы с PE-файлами (PE Bliss). Ее всегда можно скачать отсюда.

Кстати, насчет библиотеки PE Bliss. Сейчас в свободное время я допиливаю новую версию, в которой появятся следующие дополнительные возможности (список примерный и может измениться):
- высокоуровневая работа с дополнительными типами ресурсов PE-файлов;
- детальный разбор .NET-бинарников (метаданные, сигнатуры, ресурсы);
- обертка над библиотекой на C++/CLI, которая позволит .NET-разработчикам удобно использовать функционал библиотеки в софте на C# или Visual Basic .NET.

Скачать исходники упаковщика: packer source
Скачать собранный вариант: packer binary

Print This Post Пишем упаковщик по шагам. Шаг 11. Интерфейс командной строки. Финальная версия.

Четверг, 4. Октябрь 2012
Раздел: C/C++, Windows, Для новичков, автор:

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

Появилась новая версия библиотеки для работы с PE-файлами (0.1.9). Никакие баги там поправлены не были, был добавлен функционал, который упаковщик не использует, так что ваше дело, перекачивать ее или нет :)

В этом шаге мы запилим нашему упаковщику хороший интерфейс командной строки. Я возьму вариант из старого упаковщика и модифицирую его.

Читать дальше »

Print This Post Пишем упаковщик по шагам. Шаг десятый. Общая архитектура.

Воскресенье, 30. Сентябрь 2012
Раздел: Windows, Для новичков, автор:

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

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

Итак, представим, что у нас есть DLL-файл, имеющий следующие директории:
- импорты
- экспорты
- ресурсы (в том числе информацию о версии)
- релокации
- конфигурацию загрузки
- TLS с коллбэками

Словом, всего по максимуму. Как это все будет расположено в упакованном файле?

Читать дальше »

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

Пятница, 28. Сентябрь 2012
Раздел: C/C++, Windows, Для новичков, автор:

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

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

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

Читать дальше »

Print This Post Пишем упаковщик по шагам. Шаг восьмой. DLL и экспорты.

Среда, 26. Сентябрь 2012
Раздел: Assembler, C/C++, Windows, Для новичков, автор:

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

Наш упаковщик уже умеет все, кроме одной вещи - упаковки бинарников, имеющих экспорты. Это, в частности, абсолютное большинство DLL-файлов и OCX-компоненты. Некоторые exe-файлы также имеют экспорты. Наш упаковщик должен пересобрать таблицу экспортов и расположить ее в доступном месте, чтобы загрузчик мог ею воспользоваться.

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

Читать дальше »

Print This Post Пишем упаковщик по шагам. Шаг седьмой. Релокации.

Вторник, 25. Сентябрь 2012
Раздел: C/C++, Windows, Для новичков, автор:

Предыдущий шаг здесь. Там, кстати, имелась ошибка в коде, я ее поправил. Она проявлялась, когда у файла было больше одного TLS-коллбэка.

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

Перейдем к следующей немаловажной части многих PE-файлов - релокациям. Они используются, когда невозможно загрузить образ по указанному в заголовке базовому адресу. Преимущественно такое поведение характерно для DLL-файлов (они в принципе без релокаций не могут нормально работать). Представьте, что exe-файл грузится по адресу 0x400000. Этот exe-файл грузит DLL, которая также грузится по этому адресу. Адреса совпадают, и загрузчик будет искать релокации у DLL-файла, потому что он грузится вторым после exe. И если релокаций не будет, то загрузка не пройдет.

Сами релокации - это просто набор таблиц с указателеми на DWORD'ы, которе загрузчик должен пересчитать, если образ загружается по адресу, отличному от базового. Типов релокаций много, но реально в x86 (PE) используются только два: IMAGE_REL_BASED_HIGHLOW = 3 и IMAGE_REL_BASED_ABSOLUTE = 0, причем второй ничего не делает, а нужен только для выравнивания таблиц релокаций.

Сразу скажу, что загрузчик exe-файлы грузит практически всегда по базовому адресу, не применяя релокации. DLL наш упаковщик паковать пока не умеет, поэтому для теста упаковки релокаций мы должны создать exe-файл с некорректным базовым адресом, и тогда загрузчик будет вынужден этот файл в памяти переместить. Я тут не буду приводить исходный код проекта для теста, вы найдете его в солюшене в конце статьи. Базовый адрес загрузки (Linker - Advanced - Base Address) я выбрал 0x7F000000.

Релокации, как и все остальное, нам придется обрабатывать после распаковки файла вручную. Но перед этим необходимо дать понять загрузчику, что релокации у файла есть. Кроме того, нам нужно будет узнать новый адрес, на который загрузчик переместил файл.

Чтобы дать загрузчику знать о том, что у нашего файла есть релокации, делать ничего и не надо - у нас еще от оригинального файла остались нужные флаги, выставленные в заголовках PE-файла. Однако, нам нужно знать, по какому адресу файл загрузился.

Читать дальше »

Print This Post Пишем упаковщик по шагам. Шаг шестой. TLS.

Пятница, 21. Сентябрь 2012
Раздел: Assembler, C/C++, Windows, Для новичков, автор:

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

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

Пришло время заняться обработкой такой важной вещи, как Thread Local Storage (TLS) - локальной памяти потока. Что она из себя представляет? Это небольшая структура, которая говорит загрузчику PE-файлов о том, где находятся данные, которые должны быть выделены в памяти для каждого потока. Загрузчиком также производится вызов функции TlsAlloc, и значение, возвращенное ей, записывается по адресу, также указанному в этой структуре (называется это индексом). Кроме того, эта же структура может содержать адрес массива, хранящего набор коллбэков (адресов функций), которые будут вызваны загрузчиком при загрузке файла в память или при создании нового потока в процессе.

С TLS, признаться честно, все будет несколько хардкорнее, чем с остальным, так что приготовьтесь и напрягите мозг. Мой прошлый упаковщик TLS-коллбэки не поддерживал, трусливо выдавая сообщение о том, что они есть, но не обрабатываются. В принципе, поведение разумное, так как TLS-коллбеки имеют в основном всякие странные файлы, использующие эту вещь как антиотладочный прием. Ни один штатный линкер, вроде линкера от Майкрософт или Борланд, не поддерживают создание TLS-коллбэков. Тем не менее, для создания годного упаковщика мы их поддержку запилим.

Читать дальше »

Print This Post Пишем упаковщик по шагам. Шаг пятый. Ресурсы.

Среда, 19. Сентябрь 2012
Раздел: C/C++, Windows, Для новичков, автор:

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

Пора усовершенствовать наш упаковщик. Он уже способен упаковывать и запускать самые простые бинарники, имеющие лишь таблицу импорта. Бинарники с экспортами, ресурсами, TLS, DLL с релокациями ему пока что не под силу. Нужно над этим работать. Для начала сделаем обработку второй по важности вещи после импортов - директории ресурсов.

Читать дальше »

Print This Post Пишем упаковщик по шагам. Шаг четвертый. Запускаем.

Вторник, 18. Сентябрь 2012
Раздел: C/C++, Windows, Для новичков, автор:

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

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

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

Читать дальше »

Print This Post Пишем упаковщик по шагам. Шаг третий. Распаковываем.

Понедельник, 17. Сентябрь 2012
Раздел: Assembler, C/C++, Windows, Для новичков, автор:

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

Идем дальше! Пришло время написать распаковщик, именно этим мы начнем заниматься в этом шаге. Обрабатывать исходную таблицу импорта мы пока не будем, так как и в этом уроке нам будет, чем заняться.

Начнем мы вот с чего. Для работы распаковщика нам стопроцентно потребуются две WinAPI-функции: LoadLibraryA и GetProcAddress. В своем старом упаковщике я писал стаб распаковщика на MASM32 и вообще не создавал таблицу импорта. Я искал адреса этих функций в ядре, что несколько сложно и хардкорно, кроме того, это может вызвать неиллюзорные подозрения у антивирусов. Давайте в этот раз создадим обычную таблицу импортов и сделаем так, чтобы загрузчик сам нам сообщил адреса этих функций! Разумеется, набор из двух этих функций в таблице импорта так же подозрителен, как и полное их отсутствие, но ничто нам не мешает в будущем добавить еще другие левые случайные импорты из различных DLL-файлов. Куда загрузчик будет записывать адреса этих двух функций? Пора расширить нашу структуру packed_file_info!
Читать дальше »

12