PE-формат и минимальное приложение под Windows

Эта заметка написана мной лет 8 назад, для для упорядочивания в голове, содержащихся в ней сведений. Хотя приведённая информация относятся к 32-х разрядной архитектуре, всё более уходящей в прошлое, она может быть полезна и по завершении этого процесса, так как описываемый формат исполняемых файлов PE используется и на 64-х разрядных ОС Windows, с отличием в размерах полей виртуальных адресов, ассемблерный код x86, при желании, может быть заменён на x86-64, а описываемые эксперименты проделаны на современных ОС.

Исходники, приведённых в статье примеров, доступны на bitbucket.org.

Загрузка файлов проекта (должен быть установлен Git):

mkdir asm_low_level
cd asm_low_level
git init
git remote add -f origin https://bitbucket.org/cybergnosis/asm_low_level.git
git config core.sparseCheckout true
echo "min_win_pe/" >> .git/info/sparse-checkout
git pull origin master

Содержание

Введение

1. Макет минимального приложения
2. Обзор PE-формата
   
   
   
   1. Основные понятия PE-формата
   2. Общая структура PE-файла
   3. MS-DOS MZ Header
   4. PE File Header
   5. PE File Optional Header
      • DataDirectory
   6. Таблица секций
   7. Секции
   8. Импорт
      1. Стандартный механизм импорта
      2. Биндинг
      3. Bound-импорт
      4. Delay-импорт
      5. Структуры директории импорта
3. Минамальные приложения
4. Исследование программ
   1. Работоспособность под различными ОС
   2. Особенности запуска «невыровненного» минимального приложения при изменении полей заголовков

Введение

Формат исполняемых файлов PE (Portable Executable) и объектных файлов COFF (Common Object File Format) описывает структуру исполняемых и объектных файлов операционных систем Microsoft Windows. Он используется для бинарных исполняемых файлов, динамически связываемых библиотек, объектных файлов генерируемых компиляторами, на нём так же основывается формат для Common Language Runtime (CLR), используемый для системы .NET. Знание данного формата необходимо при обращении к системному программированию в среде операционных систем Microsoft Windows, связанному с проблемами безопасности (вирусы, антивирусы), созданием средств разработки (компилиторы, отладчики, дизассемблеры, протекторы, упаковщики), изучением внутреннего устройства операционной системы.

Формат используется как 32-х так и 64-х разрядными системами. Для 32-х разрядных систем используется формат PE32, для 64-х — PE32+. Описания ниже относятся к PE32.

Цель работы:

      Создание минимального по выполняемым функциям, объёму кода и размеру windows-проложения, используя непосредственное формирование структуры PE-файла.

Задачи:

1. Исследование структуры PE-файла
2. Разработка минимального приложения
3. Исследование работы приложения

Аппаратное обеспечение:

      Компьютер с процессором Athlon 1200Mhz и 768 Mb ОЗУ.

Программное обеспечение:

1. Операционая система W2K3 Server Sp1 R2
2. Интегрированная среда разработки на ассемблере RadAsm 2.2.0.9 от KetilO
3. Пакет для разработки на ассемблере MASM 10 beta
4. Виртуальная машина WMware Workstation 5.0.0 с установленными под ней операционными системами:
   1. WXP Pro Sp2 ru
   2. W2K Pro Sp4 ru
   3. WNT4.0 WS Sp1 ru
   4. W98 ru
   5. W95 ru
5. Шестнадцатиричный редактор WinHex 12.8 SR5 by Stefan Fleischmann
6. Утилита для работы с PE-файлами PE Tools 1.5.400.2003 от NEOx
7. Отладчик уровня пользователя Olly Dbg v. 1.10 от Olech Yuschuk

Литература:

1. Крис Касперски. Записки исследователя компьютерных вирусов. Часть II
2. Bill /TPOC От зелёного к красному: Глава 2. Статья с wasm.ru
3. Microsoft Portable Executable and Common Object File Format Spetification. Microsoft Corporation. R. 6.0 — February 1998
4. Microsoft Developer Network август 2006

Макет минимального приложения

Минимальным приложением для операционых систем Windows, демонстрирующим результат своей работы, можно считать программу, выводящую информационное сообщение и после этого завершающую свою работу.
Вывод информационных сообщений достигается за счёт использования функции Win API MessageBox, имеющей следующее описание:

int MessageBox(HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, UINT uType);

hWnd — хэндл окна, создающего окно сообщения, если окно сообщения не имеет владельца этот параметр может быть NULL

lpText — указатель на завершающуюся 0 строку, содержащую текст сообщения.

lpCaption — указатель на завершающуюся 0 строку, содержащую заголовок сообщения

uType — содержит битовые флаги, определяющие содержание и поведение окна информационного сообщения, простейшее окно, содержащее кроме текста сообщения только кнопку OK, имеет в этом параметре 0.

Дли завершения работы приложения используется функция ExitProcess, завершающая процесс и все его потоки:

VOID WINAPI ExitProcess( UINT uExitCode );

uExitCode — код выхода приложения.

Но приложение также завершает свою работу, когда завершается его последний поток исполняя команду ret. Это ведёт к передаче управления по находящемуся на вершине стека адресу, положенному туда вызывающим процессом. И после этого происходит освобождение выделенных ресурсов и закрытие объектов ядра завершившегося процесса. Этот способ завершения не гарантирует такую полноту освобождения ресурсов как с использованием ExitProcess, но для минимального приложения это не существенно.

Таким образом минимальное приложение для Windows на ассемблере может иметь следующий вид:

После сборки получается файл размером 1536 байт, при просмотре которого в WinHex видно, что значительное место в нём занимают нули. После его пересборки при помощи утилиты PE Tools получаем файл размером 1108 байт, что на 28% меньше. Этот пример показывает возможность манипуляции со структурой PE-файлов для оптимизации по размеру.

Запустив собранное приложение под отладчиком Olly Dbg получаем следующий дизассемблированный код:

00401000 >/$ 33C0           XOR EAX,EAX
00401002  |. 50             PUSH EAX                                 ; /Style => MB_OK|MB_APPLMODAL
00401003  |. 68 22104000    PUSH minwin.00401022                     ; |Title = "MinWinApp"
00401008  |. 68 14104000    PUSH minwin.00401014                     ; |Text = "Hello, world!"
0040100D  |. 50             PUSH EAX                                 ; |hOwner => NULL
0040100E  |. E8 19000000    CALL            ; \MessageBoxA
00401013  \. C3             RETN
00401014   . 48 65 6C 6C 6F>ASCII "Hello, world!",0
00401022   . 4D 69 6E 57 69>ASCII "MinWinApp",0
0040102C   $-FF25 00204000  JMP DWORD PTR DS:[<&user32.MessageBoxA>] ;  user32.MessageBoxA

Мы видим, что строке исходного текста программы call MessageBoxA, соответствует вызов с относительным переходом

0040100E |. E8 19000000 CALL

к строке

0040102C $-FF25 00204000 JMP DWORD PTR DS:[<&user32.MessageBoxA>] ; user32.MessageBoxA

в которой осуществляется абсолютный переход к адресу, содержащемуся по адресу 402000h

получаем в отладчике дамп памяти по данному адресу и находим там адрес 773BD8DEh. Как указывает дизассемблер отладчика этот адрес соответствует функции MessageBoxA динамически связываемой библиотеки user32.dll

Ещё мы видим, что наш исполняемый код расположен начиная с адреса 401000 и указатели на строки сообщения заданы с учётом этого факта. Таким образом, минимальное приложение, помимо функций исполняемого кода, должно обладать структурой, обеспечивающей соответствующую загрузку исполняемого кода в память, передачу управления на точку входа и доступ к функциям, расположенных в других файлах. Эти все возможности как раз и обеспечиваются соответствующими структурами PE-формата.

Обзор PE-формата

PE-формат создавался для операционных систем семейства Windows NT (новая технология). Основные концепции NT предполагали, что операционная система должна работать на различных существующих аппаратных платформах и быть способна к переносу на аппаратные платформы которые появяться в будущем, иметь большой потенциал развития, отвечать различным потребностям пользователей, соответствовать высоким требованиям безопасности и защиты авторского права. Это наложило сильный отпечаток на данный формат, придав ему некоторую запутанность и неодназначность понимания спецификаций, а также ввело в него большое число пунктов остающихся невостребованными под платформой I386, или невостребованными совсем. Ниже даётся краткий обзор формата, составленный на основе указанной литературы. За более подробными разъяснениями можно обратиться к непосредственно к ней. Прежде чем переходить к рассмотрению структуры PE-файла рассмотрим основные понятия встречающиеся при описании PE-формата. Приведён перевод документации Microsoft

Общая структура PE-файла выглядит следующим образом:

MS-DOS MZ Header

_IMAGE_DOS_HEADER. Заголовок доставшийся в наследство от исполняемых файлов MS-DOS.

Значащими являются поля e_magic и e_lfanew.

MS-DOS Real-Mode Stub Program

Код для MS-DOS, который будет исполнен, если запустить PE-файл под этой операционной системой. Обычно выводит сообщение о том, что программа не может быть под ней исполнена. Хотя может содержать и версию программы для ДОС. Этот код может и отсутствовать, а также вместо него сюда может быть помещено что угодно, например, некоторые данные или вирусный код.

PE File Signature

00004550h — IMAGE_NT_SIGNATURE -‘PE’ и два нуля. Определяет начало PE-заголовков.

PE File Header

_IMAGE_FILE_HEADER. Содержит общую информацию о PE-файле.

PE File Optional Header

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

В конце опционального заголовка идёт таблица директорий — массив, содержащий указатели на директории — служебные структуры, которые могут понадобиться во время загрузки и работы приложения. Каждый элемент этого массива представляет собой следующую структуру:

_IMAGE_DATA_DIRECTORY	STRUCT
    VirtualAddress          DWORD   ?  ;RVA директории
    DirSize                 DWORD   ?  ;размер директории байт
_IMAGE_DATA_DIRECTORY ends

Каждый элемент массива таблицы директорий относится к директории, несущей определённую смысловую нагрузку. Структура таблицы директорий приведена в расположенной ниже таблицы

Таблица секций

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

_IMAGE_SECTION_HEADER       STRUCT
    Name_                   BYTE 8 DUP(?)   ;имя секции, 8 байт
    VirtualSize             DWORD   ?       ;виртуальный размер секции
                                            ;если = 0, то загрузчик использует SizeOfRawData
                                            ;выравненное на SectionAlignment
                                            ;если значение не выравнено, загрузчик может выровнять его
    VirtualAddress          DWORD   ?       ;РВА размещения секции после загрузки
    SizeOfRawData           DWORD   ?       ;размер секции на диске выравненное на FileAligment
    PointerToRawData        DWORD   ?       ;файловое смещение начала секции на диске
                                            ;должно быть кратно FileAligment
    PointerToRelocations    DWORD   ?       ;для исполняемых файлов не используется, может быть любым
    PointerToLinenumbers    DWORD   ?       ;для исполняемых файлов не используется, может быть любым
    NumberOfRelocations     WORD    ?       ;для исполняемых файлов не используется, может быть любым
    NumberOfLinenumbers     WORD    ?       ;для исполняемых файлов не используется, может быть любым
    Characteristics         DWORD   ?       ;атрибуты секций, определяются приведёнными ниже флагами
_IMAGE_SECTION_HEADER ends


;флаги атрибутов секции, используемые для исполняемых файлов
IMAGE_SCN_CNT_CODE                  equ     20h         ;секция содержит исполняемый код
IMAGE_SCN_CNT_INITIALIZED_DATA      equ     40h         ;инициализированные данные
IMAGE_SCN_CNT_UNINITIALIZED_DATA    equ     80h         ;неинициализированные данные
IMAGE_SCN_CNT_MEM_DISCARDABLE       equ     2000000h    ;секция отбрасывается после загрузки программы
IMAGE_SCN_CNT_MEM_SHARED            equ     100000000h  ;является общедоступной
IMAGE_SCN_CNT_MEM_EXECUT            equ     200000000h  ;может исполняться как код
IMAGE_SCN_CNT_MEM_READ              equ     400000000h  ;доступна для чтения, эквивалентна IMAGE_SCN_CNT_MEM_EXECUT
IMAGE_SCN_CNT_MEM_WRITE             equ     800000000h  ;доступна для записи

Секции.

Секции следуют за таблицей секций. Начало каждой секции на диске и в памяти выравнивается на соответствующее смещение. В секциях находится как непосредственно код и данные, которые мы определили для приложения, так и структуры директорий указанных в таблице директорий в конце опционального заголовка. Имена секций могут носить произвольный характер и почти никогда не проверяются. За некоторыми секциями закреплены стандартные имена, например, «.text» для секции кода. Возможности работы с находящейся в секции информацией определяются атрибутами секции, хранящимися в поле Characteristics её заголовка.

Импорт

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

Импорт может осуществляться следующими механизмами:

1. Стандартный механизм импорта

Стандартный механизм импорта связян с директорией импорта, сведения о которой хранятся в поле IMAGE_DIRECTORY_ENTRY_IMPORT тиблицы директорий. Он связан с записью загрузчиком в определённых местах директории импорта адресов импортируемых функций, имена и имена библиотек которых также хранятся в этой директории. Для получения адреса каждой импортируемой функции загрузчик прибегает к вызову функции GetProcAddress из kernel32.dll. Этот механизм очень простой, надёжный, но и долгий. Ниже связанные с ним структуры будут рассмотрены более подробно, так как он будет использован при создании минимального приложения.

2. Биндинг

Этот механизм заключается в записи в файле на диске по определённым смещениям адресов импортируемых функций, что уменьшает время загрузки файла, если временной штамп идентифицирующий сборку ДЛЛ в файле и временной штамп загружаемой ДЛЛ совпадают. При наличии такого импорта проверка на совпадение временного штампа осуществляется для каждой ДЛЛ, и в зависимости от её результатов применяется этот или другой механизм импорта. Запись адресов в файл осуществляется утилитой bind. С этим механизмом связана проблема форвардинга — передачи экспорта, когда экспортирующая функцию библиотека не содержит самой функции, а отсылает к другой библиотеки, содержащей эту функцию, может быть под другим именем. Это делается для обеспечения совместимости приложений с различными версиями ОC Windows. Существует старый и новый стиль биндинга, отличающиеся тем, как они решают проблему форвардинга. И старый и новый стиль использует ту же директорию, что и стандартный механизм импорта. Но старый хранит в ней и информацию о форвардных функциях, а новый использует для этого директорию привязанного импорта, адресуемую через элемент IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT таблицы директорий.

3. Bound-импорт

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

4. Delay-импорт

Delay или отложенный импорт позволяет записывать в соответствующие места файла в памяти адреса функций при первом обращении к ним. Директория связанная с этим видом импорта определяется элементом IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT таблицы директорий. Отложенный импорт связан не только со структурами данных, но и с реализацией внутри приложения программного кода.

К директориям импорта также относится таблица адресов импорта определяемая IMAGE_DIRECTORY_ENTRY_IAT используемая как вспомогательная на WinXP. Но мне о ней подробности неизвестны.

Структуры директории импорта

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

_IMAGE_IMPORT_DESCRIPTOR    STRUCT
    ;Characteristics        DWORD   ? 
    OriginalFirstThunk      DWORD   ? ;РВА массива _IMAGE_THUNK_DATA32 называемого
                                      ;Import Lookup Table
                                      ;в каждом элементе
                                      ;содержащего ординал (если старший бит установлен в 1, остальная
                                      ;часть - ординал, используется редко), или РВА на структуру _IMAGE_IMPORT_BY_NAME
                                      ;этот массив в процессе загрузки не изменяется, может и совсем не использоваться
									;и OriginalFirstThunk может быть любым
									;но он необходим при биндинге
									;линкеры Борланд ставят его в 0
									;для системных ДЛЛ массив содержит адреса импортируемых функций
									;массив паралелен FirstThunk, не правится при загрузке				
    TimeDateStamp           DWORD   ? ;временной штамп создания файла. Может быть равен
                                      ;0 - биндинга нет
									  ; временному штампу - старый стиль биндинга
									  , -1 - новый стиль биндинга
    ForwarderChaine         DWORD   ? ;индекс первого импортируемого форварда в массиве FirstThunk, индекс
                                      ;следующего находится в нём, 0 для последнего, образуя цепочку
                                      ;если нет биндинга может быть любым
    ModName                 DWORD   ? ;РВА указатель на имя ДЛЛ
    FirstThunk              DWORD   ? ;РВА массива _IMAGE_THUNK_DATA32,
                                    ;называемого Import Address Table
                                    ;до загрузки идентичного Import Lookup Table (в случае использования и
									;если нет биндинга),
                                    ;после загрузки его элементы содержат адреса функций
                                    ;оба массива заканчиваются DWORD 0	                                    
                                    ;SizeOfImage => FirstThunk > SizeOfHeaders	
_IMAGE_IMPORT_DESCRIPTOR ends

Элементы Import Lookup Table и Import Address Table состоят из массивов _IMAGE_THUNK_DATA32, представляющих одно двойное слово:

_IMAGE_THUNK_DATA32 UNION
	ForwarderString         DWORD	?
	Function                DWORD	?
	Ordinal                 DWORD	?
	AddressOfData           DWORD	?
_IMAGE_THUNK_DATA32 ends

Если функция импортируется по имени _IMAGE_THUNK_DATA32 содержат RVA структуры _IMAGE_IMPORT_BY_NAME:

_IMAGE_IMPORT_BY_NAME	STRUCT
	Hint                    WORD	? ;укороченный идентификатор точки входа
									 ;индекс в Export Name Pointer Table ДЛЛ
									 ;если индексируемое имя не совподает с Name_
									 ;выполняется поиск по всей Export Name Pointer Table
	Name_                   BYTE	? DUP(?) ;название импортированной функции, StrintZero
_IMAGE_IMPORT_BY_NAME ends

Функция может также импортироваться по ординалу — номеру функции в таблице адресов экспортируемых библиотекой функций (?). В этом случае первый бит _IMAGE_THUNK_DATA32 = 1. Отняв её получаем ординал.

Минамальное приложение

В результате работы над минимальным Windows-приложением были получены следующие программы:

1. minwinpe — создана с использыванием типовой схемы PE-файла. Она содержит одну секцию с файловым выравниванием 200h и выравниванием в памяти 1000h. Получившийся исполняемый файл имеет размер 606 байт.
2. minwinpeunal — создана путём сокращения SectionAlignment и FileAlignment, основанного на том, что на NT-системах, если эти параметры равны и файловый образ совпадает с дисковым то они могут принимать значения меньше 1000h и 200h соответственно. В ходе работы экспериментально было установлено, что эти параметры могут принимать любые значения равные степени двойки начиная с двух. Получившийся исполняемый файл имеет размер 446 байт.
3. minwinpeopt — в результате дальнейшей оптимизации предыдущего приложения путём частичного совмещения _IMAGE_DOS_HEADER с _IMAGE_FILE_HEADER и _IMAGE_OPTIONAL_HEADER. Это достигнуто за счёт того, что поле _IMAGE_OPTIONAL_HEADER SectionAlignment = 4 выполняет также роль поля _IMAGE_DOS_HEADER e_lfanew, а смещение PE-сигнатуры так же равно 4. Урезания таблицы директорий до двух элементов. Частичного совмещения таблицы секцый и директории импорта. Размещения имён импортируемых ДЛЛ и функции в неимеющих критического значения полях _IMAGE_FILE_HEADER и _IMAGE_OPTIONAL_HEADER. Получившийся исполняемый файл имеет размер 213 байт. При открытии в PE-редакторе PE Tools выдаётся сообщение «Module does not appear to be a valid Win32/64 module. Editing of DOS header is not possible.»
4. minwinpeoptend — В этот приложении убрана инструкция обнуления регистра eax, т.к. на NT системах он после загрузки равен 0, а на 9х — нет. Сокращение составило 2 байта и исполняемый файл имеет размер 211 байт.

Приведённые примеры сокращения размера приложения не используют всех возможностей, которые можно применить для этой цели. Одной из возможностей, позволяющей добиться дополнительного уменьшения размера является прямой вызов функций WIN API, адреса которых могут быть вставлены непосредственно в код. Это позволяет избавится от записей в таблице импорта. Но создаёт жёсткую привязку к расположению адресов функций WIN API, которые могут различаться даже на одной операционной системе, в зависимости от версий установленных dll. Как вариант, для исследования запуска подобным образом созданного приложения, можно использовать специальную программу, которая бы изменяла жёстко заданные адреса, а зависимости от реальных адресов API функций на системе. Или править эти адреса в ручную.

Исследование программ

Следующая таблица показывает работоспособность программ под различными операционными системами:

¹Два окна сообщения сообщения:
«Ошибка при запуске программы»
«Файл c:\work1\winminpeunal\winminpeunal.exe скомпанован неправильно, граница выравнивания меньше 1000h. Устраните ошибку и повторите попытку.»
И
«c:\work1\winminpeunal\winminpeunal.exe»
«Запуск программы невозможен, так как она имеет неверный формат»

²Окно сообщения:
«Программа выполнила недопустимую операцию и будет закрыта. Завершите работу со всеми остальными программами и перегрузите компьютер.»
Сведения: «Программа EXPLORER вызвала сбой при обращении к странице памяти в модуле KERNEL32.DLL по адресу 015f:bff8foe4». После нажатия OK сообщение
«Explorer»
«Программа выполнила недопустимую операцию и будет закрыта. Если эта ошибка будет повторяться, обратитесь к разработчику».
Сведения:
«Программа эксплорер вызвала ошибку при обращении к стеку в модуле KERNEL32.DLL по адресу 015f:bff742a3».
И каждый раз после нажатия ОК это сообщение появляется снова, но сведения об ошибке стабилизируются на
«Программа EXPLORER вызвала сбой при обращении к странице памяти в модуле KERNEL32.DLL по адресу 015f:bff9dba7»
Элементы управления продолжают действовать и Пуск->завершить работу выполняется корректно, но повторный запуск программы приводит к тому, что элементы графического интерфейса перестают реагировать на клики мыши, хотя курсор мыши движется

³Окно сообщения:
«Explorer»
«Программа выполнила недопустимую операцию и будет закрыта.Если эта ошибка будет повторяться, обратитесь к разработчику»
Сведения:
«Программа EXPLORER вызвала сбой при обращении к странице памяти в модуле KERNEL32.DLL по адресу 0137:bff7821f»
После нажатия на ОК окно сообщения больше не появляется, но все элементы графического интерфейса перестают реагировать на клики мыши, курсор мыши движется. Отправка через WMware Cnrl_Alt_Del остаётся без результата. Помогает перегрузка виртуальной машины.

Нижеследующая таблица показывает особености выполнения выполнения программы minwinpeunal на базовой хостовой операционной системе W2K3 Serv Sp1 R2 при прямом запуске и под отладчиком при изменении некоторых полей заголовков.

Исходники