Исполняемый файл на диске и модуль, получаемый после загрузки, очень похожи. Загрузчик попросту использует отображенные в память файлы Win32, чтобы загрузить соответствующие части РЕ-файла в адресное пространство программы. Так же просто загружается и DLL. После того как ЕХЕ или.DLL модуль загружены, Windows обращается с ними так же, как и с другими отображенными в память файлами.
В Win32, напротив, память, используемая под программы, данные, ресурсы, таблицы ввода, таблицы вывода и другие элементы, представляет собой один сплошной линейный массив адресного пространства. Все, что достаточно знать в этом случае, – это адрес, в который загрузчик отобразил в памяти исполняемый файл. Тогда для того, чтобы найти лю¬бой элемент модуля, достаточно следовать указателям, которые хранятся как часть отображения.
Заголовок MS-DOS
Заголовок MS-DOS занимает первые 64 байта PE файла. Структура, представляющая содержание MS-DOS-заголовка следующая:
typedef struct _IMAGE_DOS_HEADER { //DOS .EXE заголовок
USHORT e_magic; //MZ
USHORT e_cblp; //Байты на последней
//странице файла
USHORT e_cp; //Страницы в файле
USHORT e_crlc; //Настройки
USHORT e_cparhdr; //Размер заголовка в
//параграфах
USHORT e_minalloc; //Минимальная выделенная память
USHORT e_maxalloc; //Максимальная выделенная память
USHORT e_ss; //Начальное (относительное)
//значение SS
USHORT e_sp; //Начальное значение SP
USHORT e_csum; //Контрольная сумма
USHORT e_ip; //Начальное значение IP
USHORT e_cs; //Начальное (относительное)
//значение CS
USHORT e_lfarlc; //адрес Файла таблицы настройки
USHORT e_ovno; //Оверлейный номер
USHORT e_res ; //Зарезервированные слова
USHORT e_oemid; //OEM идентификатор (для
//e_oeminfo)
USHORT e_oeminfo; //OEM информация; e_oemid
//специфический
USHORT e_res2 ; //Зарезервированные слова
LONG e_lfanew; //адрес смещения PE-заголовка
} IMAGE_DOS_HEADER, * PIMAGE_DOS_HEADER;
Основной заголовок РЕ-файла представляет структуру типа IMAGE_NT_НEADERS, определенную в файле WINNT.H. Структура IMAGE_NT_HEADERS в памяти – это то, что Windows использует в качестве своей базы данных модуля в памяти. Каждый загруженный ЕХЕ-файл или DLL представлены в Windows структурой IMAGE_NT_HEADERS. Эта структура состоит из двойного слова и двух подструктур, как показано ниже:
DWORD Signature;
IMAGE_FILE_HEADER FileHeader;
IMAGE_OPTIONAL_HEADER OptionalHeader;
PE File Signature
Поле Signature (сигнатура – подпись), представленное как ASCII код, – это РЕ\0\0 (два нулевых байта после РЕ). Если поле e_lfanew в заголовке DOS указало вместо обозначения РЕ обозначение NE в этом месте, значит, вы работаете с файлом Win16 NE. Аналогично, если указано обозначение LE в поле Signature, то это файл VxD (VirtualDeviceDriver – драйвер виртуального устройства). Обозначение LX указывает на файл старой соперницы Windows 95 – OS/2.
PE File Header
За двойным словом – сигнатурой РЕ, в заголовке РЕ-файла следует структура типа IMAGE_FILE_HEADER. Поля этой структуры содержат только самую общую информацию о файле.
Далее приводятся поля IMAGE_FILE_HEADER:
typedef struct _IMAGE_FILE_HEADER
{
USHORT Machine;
USHORT NumberOfSections;
ULONG TimeDateStamp;
ULONG PointerToSymbolTable;
ULONG NumberOfSymbols;
USHORT SizeOfOptionalHeader;
USHORT Characteristics;
} IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER
Machine – это центральный процессор, для которого предназначен файл. Определены следующие идентификаторы процессоров:
Intel I386 0xl4C
Intel I860 0xl4D
MIPS R3000 0х162
MIPS R4000 0х166
DEC Alpha AXP 0х184
Power PC 0x1F0 (little endian)
Motorola 68000 0х268
PA RISC 0х290 (Precision Architecture)
NumberOfSections – количество секций в ЕХЕ- или OBJ-файле.
TimeDateStamp – время, когда файл был создан компоновщиком (или компилятором, если это OBJ-файл). В этом поле указано количество секунд, истекших с 16:00 31.12.1969
PointerToSymbolTable – файловое смещение COFF-таблицы символов. Это поле используется только в OBJ- и РЕ-файлах с информацией COFF-отладчика. РЕ-файлы поддерживают разнообразные отладочные форматы, так что отладчики должны ссылаться ко входу IMAGE_DIRECTORY_ENTRY_DEBUG в каталоге данных.
NumberOfSymbols – количество символов в COFF-таблицс символов.
SizeOfOplionalHeader – размер необязательного заголовка, который может следован, за этой структурой. В исполняемых файлах – это размер структуры IMAGE_OPTIONAL_HEADER, которая следует за этой структурой.
Characteristics
– флаги, содержащие информацию о файле. Здесь описываются некоторые важные поля.
0х0001 – файл не содержит перемещений
0х0002 – файл представляет исполняемое отображение (т.е. это не OBJ- или LIB-файл)
0х2000 – файл является библиотекой динамической компоновки (DLL), а не программой
PE File Optional Header
Третьим компонентом заголовка РЕ-файла является структура типа IMAGE_OPTIONAL_HEADER. Для РЕ-файлов эта часть является обязательной. Наиболее важными полями являются поля ImageBase и Subsystem.
ImageBase – когда компоновщик создает исполняемый файл, он предполагает, что файл будет отображен в определенное место в памяти, именно этот адрес и хранится в этом поле.
Subsystem
– тип подсистемы, которую данный исполняемый файл использует для своего пользовательского интерфейса. WINNT.H определяет следующие значения:
NATIVE = 1 – подсистема не требуется (например, для драйвера устройства)
WINDOWS_GUI = 2 – запускается в подсистеме Windows GUI
WINDOWS_GUI = 3 – запускается в подсистеме Windows character (терминальное приложение)
OS2_GUI = 5 – запускается в подсистеме OS/2 (только приложения OS/2 IJC)
POSIX_GUI = 7 – запускается в подсистеме Posix
Таблица секций
Сразу после заголовка РЕ-файла в памяти следует массив из 1MAGE_SECT10N_HEADER. Эта таблица. содержит информацию о каждой секции отображения. Количество элементов этого массива задается в заголовке РЕ-файла (поле IMAGE_NT_HEADER.FileHeader.NumberOfSections). Секции в отображении упорядочены по их стартовому адресу, а не в алфавитном порядке.
Каждый IMAGE_SECTION_HEADER представляет собой полную базу данных об одной секции файла ЕХЕ или OBJ \ и имеет следующий формат.
#define IMAGE_SIZEOF_SHORT_NAME 8
typedef struct _IMAGE_SECTION_HEADER
{
UCHAR Name;
union {
ULONG PhysicalAddress;
ULONG VirtualSize;
} Misc;
ULONG VirtualAddress;
ULONG SizeOfRawData;
ULONG PointerToRawData;
ULONG PointerToRelocations;
ULONG PointerToLinenumbers;
USHORT NumberOfRelocations;
USHORT NumberOfLinenumbers;
ULONG Characteristics;
} IMAGE_SECTION_HEADER, *PIMAGE_SECTION_HEADER;
Name – 8-байтовое имя в стандарте ANSI (не Unicode), которое именует секцию.
Misc – это поле имеет различные назначения в зависимости от того, встречается ли оно в ЕХЕ- или OBJ-файле. В ЕХЕ-файле оно содержит виртуальный размер секции программного кода или данных. В случае OBJ-файлов это поле указывает физический адрес секции.
VirtualAddress – в случае ЕХЕ-файлов это поле содержит RVA, куда загрузчик должен отобразить секцию. Средства Microsoft устанавливают по умолчанию RVA первой секции равным 0х101. Для объектных файлов это поле устанавливается в 0.
SizeOfRawData
– в ЕХЕ-файлах это поле содержит размер секции, выровненный па ближайшую верхнюю границу размера файла.
PointerToRawData – файловое смещение участка, где находятся исходные данные для секции. Если пользователь сам отображает в мять РЕ- или COFF-файл (вместо того, чтобы доверить загрузку операционной системе), это поле важнее, чем в VirtualAddress.
PointerToRelocations – в объектных файлах это файловое смещение информации о поправках, которая следует за исходными данными для данной секции. В ЕХЕ-файлах это поле устанавливается в 0.
PointerToLinenumhers – файловое смещение таблицы номеров строк. Таблица номеров строк ставит в соответствие номера строк исходного файла адресам, по которым можно найти код, сгенерированный для данной строки. Обычно только секции с программным кодом (например, .text или CODE) имеют номера строк. В ЕХЕ-файлах номера строк собраны в конце файла после исходных данных для секций. В объектных файлах таблица номеров строк для секции следует за исходными данными секции и таблицей перемещений для этой секции.
NumberOfRelocations
– количество перемещений в таблице поправок для данной секции (используется только в объектных файлах).
NumberOfLinenumbers – количество номеров строк в таблице номеров строк для данной секции.
Characteristics – набор флагов, которые указывают на атрибуты секции (программа/данные, предназначен для чтения, предназначен для записи и т.н.).
Часто встречающиеся секции
Секция.text (или CODE
В этой секции собран весь программный код общего назначения, генерируемый компилятором или ассемблером. Компоновщик объединяет все секции.text из различных объектных файлов в одну большую секцию.text в ЕХЕ-файле.
Секция.data (или DATA , если PE-файл создан Borland C++)
Инициализированные данные попадают в секцию.data. Инициализированные данные состоят из тех глобальных и статических переменных, которые были проинициализированы во время компиляции. Они также включают строковые литералы (например, строку "Hello World" в программе C/C++). Компоновщик объединяет все секции.data из разных объектных и LIB-файлов в одну секцию.data в ЕХЕ-файле. Локальные переменные расположены в стеке цепочки и не занимают места в секциях.data и.bss.
Секция.bss
В секции.bss хранятся неинициализированные статические и глобальные переменные. Компоновщик объединяет все сек¬ции.bss из разных объектных и LIB-файлов в одну секцию.bss в ЕХЕ-файле.
Секция.CRT
Еще одна секция для инициализированных данных, используемая библиотеками поддержки выполнения программы Microsoft C/C++. Данные из этой секции используются для таких це¬лей, как вызов конструкторов статических классов C++ перед вызовом main или WinMain.
Секция.rsrc
Секция.rsrc содержит ресурсы модуля.
Секция.idata
Секция.idata (или таблица импорта) содержит информацию о функциях (и данных), которые модуль импортирует из других DLL. Таблица импорта начинается с массива, состоящего из IMAGE_IMPORT_DESCRIPTOR. Каждый элемент (IMAGE_IMPORT_DESCRIPTOR) соответствует одной из DLL, с кото¬рой неявно связан данный РЕ-файл. Количество элементов в массиве нигде не учитывается. Вместо этого последняя структу¬ра массива IMAGE_IMPORT_DESCRIPTOR имеет поля, содержащие NULL.
Структура IMAGE_IMPORT_DESCRIPTOR имеет следующий формат
typedef struct _IMAGE_IMPORT_DESCRIPTOR {
union {
DWORD Characteristics;
DWORD OriginalFirstThunk;
};
DWORD TimeDateStamp;
DWORD ForwarderChain;
DWORD Name;
DWORD FirstThunk;
} IMAGE_IMPORT_DESCRIPTOR
Characteristics/OriginalFirstThunk – в этом поле содержится смещение (RVA) массива двойных слов. Каждое из этих двойных слов в действительности является объединением IMAGE_THUNK_DATA. Каждое двойное слово IMAGE_THUNK_DATA соответствует одной функции, импортируемой данным ЕХЕ-файлом или DLL.
TimeDateStamp
– отметка о времени и дате, указывающая, когда был создан данный файл.
ForwarderChain – это поле имеет отношение к передаче, когда одна DLL передает ссылку на какую-то свою функцию другой DLL.
Name – это RVA строки символов ASCII, оканчивающейся нулем и содержащей имена импортируемых DLL.
FirstThunk – RVA-смещение массива двойных слов IMAGE_THUNK_DATA. В большинстве случаев двойное слово рассматривает¬ся как указатель на структуру IMAGE_IMPORT_BY_NAME. Это структура выглядит следующим образом:
typedef struct _IMAGE_IMPORT_BY_NAME {
WORD Hint;
BYTE Name;
} IMAGE_IMPORT_BY_NAME, *PIMAGE_IMPORT_BY_NAME;
Hint
– номер экспорта у функции импорта.
Name
– Строка ASCIIZ с именем импортируемой функции.
Фрагмент программы читающей из РЕ файла список импортируемых программой функций ОС.
Приведенный ниже фрагмент программы зарисывает в файл FunctionList.txt список библиотек с импортируемыми программой функциями.
void ShowImportFunction()
BYTE *pImage = (BYTE*) GetModuleHandle(NULL ) ;
IMAGE_DOS_HEADER *idh;
IMAGE_OPTIONAL_HEADER *ioh;
IMAGE_SECTION_HEADER *ish;
IMAGE_IMPORT_DESCRIPTOR *iid;
IMAGE_IMPORT_BY_NAME *ibn;
IMAGE_THUNK_DATA *thunk;
int i = 0 ;
DWORD j = 0 ;
char lib = "Импортируемая библиотека: " ;
HANDLE file = CreateFile(TEXT("FunctionList.txt" ) ,GENERIC_READ|GENERIC_WRITE,
0 ,0 ,CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL|FILE_FLAG_RANDOM_ACCESS,0 ) ;
idh = (IMAGE_DOS_HEADER*) pImage;
ioh = (IMAGE_OPTIONAL_HEADER*)
(pImage + idh->e_lfanew + 4 +
sizeof (IMAGE_FILE_HEADER) ) ;
ish = (IMAGE_SECTION_HEADER*) ((DWORD) ioh + sizeof (IMAGE_OPTIONAL_HEADER) ) ;
for (i = 0 ; i < 16 ; i++)
Структура PE файла
Общее описание PE файла
Для решения широкого круга программистских задач требуется знание внутренней структуры исполняемых файлов и представление о том, как они загружаются в память.
Во всех 32-разрядных ветках ОС Windows объектные (.OBJ), библиотечные (.LIB) и исполняемые (.EXE и.DLL) файлы хранятся в едином формате COFF (Common Object File Format), который используется некоторыми системами семейства Unix и ОС VMS.
Формат PE (Portable Executable) является специализацией COFF для хранения исполняемых модулей. Он был стандартизован Tool Interface Standard Committee (Microsoft, Intel, IBM, Borland, Watcom и др.) в 1993 г., а затем понемногу обновлялся (последнее известное мне обновление было проведено в феврале 1999 г., но оно не учитывает поддержки метаданных для.NET, добавленной в 2000 г.). Название Portable Executable связано с тем, что данный формат не зависит от архитектуры процессора, для которого построен исполняемый файл.
На сегодняшний день существует два формата PE-файлов: PE32 и PE32+. Оба они ограничивают адресное пространство программы размеров в 4 Гб (0xFFFFFFFF), но PE32 использует 32-битовые адреса (архитектура Win32), а PE32+ - 64-битовые адреса (архитектура Win64).
Большинство описанных ниже структур и констант содержатся в стандартном заголовочном файле Windows WINNT.H.
Любой PE-файл состоит из нескольких заголовков и нескольких (от 1 до 96) секций. Заголовки содержат служебную информацию, описывающую различные свойства исполняемого файла и его структуру. Секции содержат данные, которые размещаются в адресном пространстве процесса во время загрузки исполняемого файла в память.
PE-файлы являются файлами с относительной загрузкой, т.е. теоретически могут размещаться в пространстве адресов 0x00000000 - 0xFFFFFFFF с любого адреса, называемого базовым адресом. Поскольку базовый адрес заранее неизвестен, структура PE-файлов основана на понятия RVA (relative virtual address, относительный виртуальный адрес). RVA представляет собой смещение от базового адреса исполняемого файла до данного адреса. Иными словами, для получения линейного адреса в виртуальной памяти процесса нужно сложить RVA с базовым адресом.
Следует особо подчеркуть, что RVA не имеют ничего общего общего со смещениями относительно начала файла. В процессе загрузки файла каждая его секция размещается в памяти со своего RVA и при необходимости дополняется нулями до заданного размера. При этом RVA секции и ее размер в памяти, вообще говоря, никак не связаны с ее местоположением и размером в исходном файле.
Общая структура PE-файла представлена в таблице 2.1:
Таблица 2.1 - Структура ре файла
Подробно каждая из этих структур описана ниже.
Общее описание заголовка и заглушки DOS
Поскольку и приложения DOS, и приложения Windows имеют расширение.EXE, все исполняемые файлы Windows используют схему двойной загрузки. Она состоит в том, что файл начинается с заголовка DOS, за которым следует заглушка (stub), т.е. небольшой EXE-файл формата DOS. При попытке загрузить файл из DOS"а исполняется заглушка, а при загрузке файла из Windows загрузчик анализирует заголовок DOS и извлекает из него смещение до настоящего заголовка исполняемого файла.
ь Структура заголовка DOS называется IMAGE_DOS_HEADER. Я не буду полностью описывать заголовок DOS, т.к. нас интересуют в нем только два поля, а именно:
ь 2-байтовая (WORD) сигнатура, находящаяся по смещению 0 (e_magic) и равная «MZ» (IMAGE_DOS_SIGNATURE);
ь 4-байтовое (DWORD) смещение от начала файла до заголовка PE, находяшееся по смещению 0x3C (e_lfanew).
При загрузке PE-файла сначала нужно проверить сигнатуру DOS, затем найти смещение до заголовка PE, а затем проверить сигнатуру PE, расположенную в начале его заголовка. Эта сигнатура состоит из 4 байтов и равна «PE» (обозначение IMAGE_NT_SIGNATURE).
Такую же схему двойной загрузки используют и другие файлы (исполняемые файлы Win16 и OS/2 и VxD-драйверы Windows 9x), поэтому проверка правильности сигнатуры PE обязательна.
Обычно заглушка DOS выводит на экран сообщение типа «Эта программа требует Microsoft Windows» и заканчивает работу. Однако при сборке программы мы можем указать в командной строке сборщика любой EXE-файл DOS в качестве заглушки. Это позволяет создавать «дуальные» программы, работающие и в DOS, и в Windows.
Сруктура DOS заголовка
typedef struct _IMAGE_DOS_HEADER { // DOS.EXE заголовок
USHORT e_magic; // Магическое число
USHORT e_cblp; // Количество байт на последней странице файла
USHORT e_cp; // Количество страниц в файле
USHORT e_crlc; // Relocations
USHORT e_cparhdr; // Размер заголовка в параграфах
USHORT e_minalloc; // Minimum extra paragraphs needed
USHORT e_maxalloc; // Maximum extra paragraphs needed
USHORT e_ss; // Начальное (относительное) значение регистра SS
USHORT e_sp; // Начальное значение регистра SP
USHORT e_csum; // Контрольная сумма
USHORT e_ip; // Начальное значение регистра IP
USHORT e_cs; // Начальное (относительное) значение регистра CS
USHORT e_lfarlc; // Адрес в файле на таблицу переадресации
USHORT e_ovno; // Количество оверлеев
USHORT e_res; // Зарезервировано
USHORT e_oemid; // OEM identifier (for e_oeminfo)
USHORT e_oeminfo; // OEM information; e_oemid specific
USHORT e_res2 ; // Зарезервировано
LONG e_lfanew; // Адрес в файле нового.exe-заголовка
} IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;
Самым важным здесь является поле e_lfanew, которое содержит 4-байтовое смещение от начала файла до PE-заголовка. Первое поле структуры e_magic содержит сигнатуру исполняемого файла. Все MS-DOS-совместимые исполняемые файлы имеют сигнатуру 0x54AD, которая в ASCII-символах представлена двумя символами MZ. По этой причине заголовок DOS часто называют MZ-заголовком.
Структура PE заголовка
Заголовок PE (IMAGE_NT_HEADERS) состоит из трех частей (см. Таблицу 2.2):
Таблица 2.2 - Структура заголовка
struct IMAGE_NT_HEADERS {
DWORD Signature;
IMAGE_FILE_HEADER FileHeader;
IMAGE_OPTIONAL_HEADER OptionalHeader;
Заголовок PE всегда начинается с 4-байтовой сигнатуры «PE» (IMAGE_NT_SIGNATURE). За ней следуют два заголовка: заголовок файла (IMAGE_FILE_HEADER) и необязательный заголовок (IMAGE_OPTIONAL_HEADER). Несмотря на свое название, IMAGE_OPTIONAL_HEADER присутствует в PE-файле всегда (необязательным он является с точки зрения общего формата COFF, поскольку не используется в объектных и библиотечных файлах).
Заголовок файла
Заголовок файла состоит из 0x14 байтов (определение IMAGE_SIZEOF_FILE_HEADER), размещается сразу после сигнатуры и содержит общее описание файла. Он состоит из следующих полей:
Таблица 2.3 - Структура заголовка файла
Описание назначения полей.
Поле Machine
16-битовое число, которое задает архитектуру процессора, на которой может выполняться данная программа.
Поле TimeDateStamp
32-битовое число, которое содержит дату и время создания данного файла. Формат этого поля недокументирован, однако сборщики Microsoft заносят сюда время как количество секунд от полуночи 01.01.1970 в UTC (т.е. используют юниксовский формат времени, возвращаемого функцией time языка C). Между прочим, это означает, что текущее состояние формата PE действительно только до 18.01.2038 г.
Поскольку формат этого поля недокументирован, некоторые сборщики третьих фирм сохраняют его значение в других форматах. Это может оказаться важным, т.к. данное поле используется при динамическом связывании импорта из DLL.
Поля PointerToSymbolTable и NumberOfSymbols
Согласно стандарту COFF, эти 4-байтовые поля должны обеспечивать доступ к отладочной информации в файле. Однако все известные мне сборщики заносят в них нули, а для доступа к отладочной информации используется иной способ (см. каталог отладочной информации).
Поле SizeOfOptionalHeader
16-битовое число, задающее размер необязательного заголовка. Оно равно 0xE0 для файлов PE32 (IMAGE_SIZEOF_NT_OPTIONAL32_HEADER) и 0xF0 для файлов PE32+ (IMAGE_SIZEOF_NT_OPTIONAL64_HEADER).
Поле Characteristics
16-битовое поле флагов, содержащее COFF-атрибуты файла.
Необязательный заголовок
Необязательный заголовок имеет два различных формата: для PE32 и для PE32+. Соответствующие структуры называются IMAGE_OPTIONAL_HEADER32 и IMAGE_OPTIONAL_HEADER64. Их поля сведены в Таблице 2.4:
Таблица 2.4 - Структура необязательного заголовка
|
Смещение (hex, PE32/PE32+) |
Размер (PE32/PE32+) |
Тип (PE32/PE32+) |
Название |
Описание |
|
Сигнатура заголовка. |
||||
|
MajorLinkerVersion |
Старшая цифра номера версии сборщика. Загрузчиком не используется. |
|||
|
MinorLinkerVersion |
Младшая цифра номера версии сборщика. Загрузчиком не используется. |
|||
|
Сумма размеров всех секций, содержащих програмный код. |
||||
|
SizeOfInitializedData |
Сумма размеров всех секций, содержащих инициализированные данные. |
|||
|
SizeOfUninitializedData |
Сумма размеров всех секций, содержащих неинициализированные данные. |
|||
|
AddressOfEntryPoint |
RVA точки запуска программы. Для драйвера - это адрес DriverEntry, для DLL - адрес DllMain или нуль. |
|||
|
RVA начала кода программы. |
||||
|
RVA начала данных программы. Ненадежное поле, загрузчиком не используется. В PE32+ отсутствует! |
||||
|
Предпочтительный базовый адрес программы в памяти, кратный 64 Кб. По умолчанию равен 0x00400000 для EXE-файлов в Windows 9x/NT, 0x00010000 для EXE-файлов в Windows CE и 0x10000000 для DLL. Загрузка программы с этого адреса позволяет обойтись без настройки адресов. |
||||
|
SectionAlignment |
Выравнивание в байтах для секций при загрузке в память, большее или равное FileAlignment. По умолчанию равно размеру страницы виртуальной памяти для данного процессора. |
|||
|
Выравнивание в байтах для секций внутри файла. Должно быть степенью 2 от 512 до 64 Кб включительно. По умолчанию равно 512. Если SectionAlignment меньше размера страницы виртуальной памяти, то FileAlignment должно с ним совпадать. |
||||
|
MajorOperatingSystemVersion |
Старшая цифра номера версии операционной системы. Загрузчиком не используется. |
|||
|
MinorOperatingSystemVersion |
Младшая цифра номера версии операционной системы. Загрузчиком не используется. |
|||
|
MajorImageVersion |
Старшая цифра номера версии данного файла. Загрузчиком не используется. |
|||
|
MinorImageVersion |
Младшая цифра номера версии данного файла. Загрузчиком не используется. |
|||
|
MajorSubsystemVersion |
Старшая цифра номера версии подсистемы. |
|||
|
MinorSubsystemVersion |
Младшая цифра номера версии подсистемы. |
|||
|
Win32VersionValue |
Зарезервировано, всегда равно 0. |
|||
|
Размер файла в памяти, включая все заголовки. Должен быть кратен SectionAlignment. |
||||
|
Суммарный размер заголовка и заглушки DOS, заголовка PE и заголовков секций, выравненный на границу FileAlignment. Задает смещение от начала файла до данных первой секции. |
||||
|
Контрольная сумма файла. |
||||
|
Исполняющая подсистема Windows для данного файла. |
||||
|
DllCharacteristics |
Дополнительные атрибуты файла. |
|||
|
SizeOfStackReserve |
Размер стека стартового потока программы в байтах виртуальной памяти. При загрузке в физическую память отображается только SizeOfStackCommit байт, в дальнейшем отображается по одной странице виртуальной памяти. По умолчанию равен 1 Мб. |
|||
|
SizeOfStackCommit |
Начальный размер стека программы в байтах. По умолчанию равен 4 Кб. |
|||
|
SizeOfHeapReserve |
Размер кучи программы в байтах. При загрузке в физическую память отображается только SizeOfHeapCommit байт, в дальнейшем отображается по одной странице виртуальной памяти. По умолчанию равен 1 Мб. Во всех 32-разрядных версиях Windows куча ограничена только размером виртуальной памяти и это поле, по-видимому, игнорируется. |
|||
|
SizeOfHeapCommit |
Начальный размер кучи программы в байтах. По умолчанию равен 4 Кб. |
|||
|
Устаревшее поле, не используется. |
||||
|
NumberOfRvaAndSizes |
Количество описателей каталогов данных. На текущий момент всегда равно 16. |
|||
|
IMAGE_DATA_DIRECTORY |
Описатели каталогов данных. |
16-битовое поле, содержащее сигнатуру заголовка. Может принимать значения (см. Таблицу 2.4):
Таблица 2.4 - Допустимые значения поля Magic
Поля MajorSubsystemVersion и MinorSubsystemVersion
16-битовые числа, указывающее ожидаемую версию Windows. В отличие от всех остальных полей с номерами версий это поле анализировалось при загрузке программ в NT 4.0 и 95. Если программа была графическим приложением и это поле не содержало версии 4.0, то считалось, что программа разработана для NT 3.51 и моделировалось поведение этой ОС (в частности, отсутствие трехмерных стилей диалогов и пр.). В настоящее время не используется и практически всегда равно 4.0.
Поле CheckSum
32-битовая контрольная сумма файла. Проверяется только в Windows NT при загрузке драйверов ядра и нескольких системных DLL. Алгоритм вычисления контрольной суммы недокументирован, но для ее вычисления можно использовать системную функцию CheckSumMappedFile из библиотеки IMAGEHLP.DLL.
Поле Subsystem
16-битовое число, указывающее в какой подсистеме Windows API должен исполняться данный файл. Его возможные значения представлены в таблице 2.5:
Таблица 2.5 - Допустимые значения поля Subsystem
|
Название |
Значение |
Подсистема |
|
IMAGE_SUBSYSTEM_UNKNOWN |
Неизвестная подсистема. |
|
|
IMAGE_SUBSYSTEM_NATIVE |
Подсистема не требуется, используется драйверами и «родными» приложениями NT. |
|
|
IMAGE_SUBSYSTEM_WINDOWS_GUI |
Графическая подсистема Windows. |
|
|
IMAGE_SUBSYSTEM_WINDOWS_CUI |
Консольная подсистема Windows. |
|
|
IMAGE_SUBSYSTEM_OS2_CUI |
Консольная подсистема OS/2. |
|
|
IMAGE_SUBSYSTEM_POSIX_CUI |
Консольная подсистема POSIX. |
|
|
IMAGE_SUBSYSTEM_NATIVE_WINDOWS |
«Родной» драйвер Win 9x. |
|
|
IMAGE_SUBSYSTEM_WINDOWS_CE_GUI |
Графическая подсистема Windows CE. |
|
|
IMAGE_SUBSYSTEM_EFI_APPLICATION |
Программа EFI. |
|
|
IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER |
Драйвер EFI, обеспечивающий загрузочный сервис. |
|
|
IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER |
Драйвер EFI времени выполнения. |
|
|
IMAGE_SUBSYSTEM_EFI_ROM |
Прошивка ПЗУ для EFI. |
|
|
IMAGE_SUBSYSTEM_XBOX |
Подсистема Xbox. |
Поле DLLCharacteristics
16-битовое поле флагов, задающие дополнительные атрибуты файла. Возможные значения флагов представлены в таблице 2.6.
Таблица 2.6 - Возможные значения флагов поля DLLCharacteristics
Поля NumberOfRvaAndSizes и DataDirectory
В конце необязательного заголовка располагается 32-битовое число, в котором хранится количество описателей каталогов данных. За ним следует массив самих описателей, каждый из которых имеет такой вид:
struct IMAGE_DATA_DIRECTORY {
DWORD VirtualAddress;
В настоящее время поле NumberOfRvaAndSizes всегда содержит число 16 (символическое имя IMAGE_NUMBEROF_DIRECTORY_ENTRIES). Соответственно массив DataDirectory состоит также из 16 описателей. Каждый описатель содержит RVA и размер для одного каталога данных. Если какого-либо каталога в файле нет, то оба поля его описателя равны нулю.
Каждый из каталогов данных содержит определенную служебную информацию. Вид этой информации определяется номером каталога в массиве описателей. Поскольку каталоги данных, как правило, располагаются внутри секций, для доступа к их содержимому нам потребуется сначала изучить структуру секций.
Заголовки секций
Сразу после заголовка PE в файле располагается массив заголовков секций. Его размер задается полем NumberOfSections заголовка файла. Каждый заголовок секции состоит из 0x28 байт и имеет следующую структуру (см. Таблицу 2.7):
Таблица 2.7 - Струкура заголовка секции
|
Смещение (hex) |
Название |
Описание |
||
|
Название секции. |
||||
|
Misc. VirtualSize |
Размер секции в памяти. Если это значение больше SizeOfRawData, то секция дополняется в памяти нулевыми байтами. |
|||
|
RVA секции в памяти. |
||||
|
Размер секции в файле. Всегда кратен FileAlignment из необязательного заголовка. Если секция содержит только неинициализированные данные, то это поле равно нулю. |
||||
|
PointerToRawData |
Смещение в файле до начала данных секций. Всегда кратно FileAlignment из необязательного заголовка. Если секция содержит только неинициализированные данные, то это поле равно нулю. |
|||
|
PointerToRelocations |
||||
|
PointerToLinenumbers |
В исполняемых файлах это поле всегда равно нулю. |
|||
|
NumberOfRelocations |
В исполняемых файлах это поле всегда равно нулю. |
|||
|
NumberOfLinenumbers |
В исполняемых файлах это поле всегда равно нулю. |
|||
|
Characteristics |
Атрибуты секции. |
Название секции
Название секции содержит от 0 до 8 ASCII-символов. Вместо константы 8 можно использовать определение IMAGE_SIZEOF_SHORT_NAME. Если длина названия меньше 8 символов, то оно дополняется нулевыми байтами. Если оно состоит ровно из 8 символов, то завершающего нулевого байта нет. Важно отметить, что название секции, вообще говоря, никак не соотносится с ее содержимым. Каждый компилятор использует свое собственное соглашение о именовании секций, поэтому полагаться на название секции при ее анализе нельзя. Единственно надежным способом определить, что содержит данная секция, является анализ ее атрибутов и содержащихся в ней каталогов данных.
Атрибуты секции
32-битовое поле Characteristics содержит набор флагов, описывающих содержимое данной секции. Секции исполняемого файла могут иметь следующие атрибуты (см. Таблицу 2.8):
Таблица 2.8 - Атрибуты секции
|
Название |
Значение |
Описание |
|
IMAGE_SCN_CNT_CODE |
Секция содержит исполняемый код. |
|
|
IMAGE_SCN_CNT_INITIALIZED_DATA |
Секция содержит инициализированные данные. |
|
|
IMAGE_SCN_CNT_UNINITIALIZED_DATA |
Секция содержит неинициализированные данные. |
|
|
IMAGE_SCN_MEM_DISCARDABLE |
Секция может быть удалена из памяти после создания процесса. |
|
|
IMAGE_SCN_MEM_NOT_CACHED |
Секция не может кэшироваться. |
|
|
IMAGE_SCN_MEM_NOT_PAGED |
Секция не может выгружаться в файл подкачки. |
|
|
IMAGE_SCN_MEM_SHARED |
Все копии данного файла могут иметь один общий экземпляр этой секции. По-видимому, используется только для секций данных динамических библиотек. |
|
|
IMAGE_SCN_MEM_EXECUTE |
Секцию можно исполнять как программный код. |
|
|
IMAGE_SCN_MEM_READ |
||
|
IMAGE_SCN_MEM_WRITE |
В секцию можно писать. |
Сами секции располагаются в файле после всех заголовков секций. Каждая секция выравнена на границу FileAlignment из необязательного заголовка.
При анализе содержимого секций следует учитывать, что это содержимое может быть разнородным. Например, одна секция может содержать и исполняемый код, и таблицу импорта.
Для того чтобы загрузчик операционной системы мог правильно загрузить исполняемый файл в память , содержимое этого файла должно соответствовать принятому в данной операционной системе формату исполняемых файлов. В разных операционных системах в разное время существовало и до сих пор существует множество различных форматов. В этой главе мы рассмотрим формат Portable Executable (PE). Формат PE - это основной формат для хранения исполняемых файлов в операционной системе Windows . Сборки. NET тоже хранятся в этом формате.
Кроме того, формат PE может использоваться для представления объектных файлов . Объектные файлы служат для организации раздельной компиляции программы. Смысл раздельной компиляции заключается в том, что части программы (модули) компилируются независимо в объектные файлы , которые затем связываются компоновщиком в один исполняемый файл .
А теперь - немного истории. Формат PE был создан разработчиками Windows NT. До этого в операционной системе Windows использовались форматы New Executable (NE) и Linear Executable (LE) для представления исполняемых файлов, а для хранения объектных файлов использовался Object Module Format (OMF). Формат NE предназначался для 16-разрядных приложений Windows , а формат LE, изначально разработанный для OS/2 , был уже 32-разрядным. Возникает вопрос: почему разработчики Windows NT решили отказаться от существующих форматов? Ответ становится очевидным, если обратить внимание на то, что большая часть команды, работавшей над созданием Windows NT, ранее работала в Digital Equipment Corporation. Они занимались в DEC разработкой инструментария для операционной системы VAX / VMS , и у них уже были навыки и готовый код для работы с исполняемыми файлами, представленными в формате Common Object File Format ( COFF ). Соответственно, формат COFF в слегка модифицированном виде был перенесен в Windows NT и получил название PE.
В ". NET Framework Glossary " сказано, что PE - это реализация Microsoft формата COFF . В то же время в утверждается, что PE - это формат исполняемых файлов, а COFF - это формат объектных файлов . Вообще, мы можем наблюдать путаницу в документации Microsoft относительно названия формата. В некоторых местах они называют его COFF , а в некоторых - PE. Правда, можно заметить, что в новых текстах название COFF используется все меньше и меньше. Более того, формат PE постоянно эволюционирует. Например, несколько лет назад в Microsoft отказались от хранения отладочной информации внутри исполняемого файла, и поэтому теперь многие поля в структурах формата COFF просто не используются. Кроме того, формат COFF - 32-разрядный, а последняя редакция формата PE (она называется PE32+) может использоваться на 64-разрядных аппаратных платформах. Поэтому, видимо, дело идет к тому, что название COFF вообще перестанут использовать.
Интересно отметить, что исполняемые файлы в устаревших форматах NE и LE до сих пор поддерживаются Windows . Исполняемые файлы в формате NE можно запускать под управлением NTVDM (NT Virtual DOS Machine), а формат LE используется для виртуальных драйверов устройств (
Понимание файловой системы Linux, структуры каталогов, размещения конфигурационных, исполняемых и временных файлов поможет вам лучше разбираться в своей системе и стать успешным системным администратором. Файловая система Linux будет непривычна именно для новичка, только что перешедшего с Windows, ведь здесь все совсем по-другому. В отличие от Windows, программа не находится в одной папке, а, как правило, распределена по корневой файловой системе. Это распределение поддается определенным правилам. Вы когда-нибудь задавались вопросом, почему некоторые программы находятся в папке /bin, или /sbin, /usr/sbin, /usr/local/bin, в чем разница между этими каталогами?
Например, программа less, находится в каталоге /usr/bin, но почему не в /sbin или /usr/sbin. А такие программы, как ifconfig или fdisk находятся в каталоге /sbin и нигде иначе.
В этой статье будет полностью рассмотрена структура файловой системы Linux, после ее прочтения вы сможете понять смысл использования большинства папок в корневом каталоге Linux.
/ - корень
Это главный каталог в системе Linux. По сути, это и есть файловая система Linux. Здесь нет дисков или чего-то подобного, как в Windows. Вместо этого, адреса всех файлов начинаются с корня, а дополнительные разделы, флешки или оптические диски подключаются в папки корневого каталога.
Обратите внимание, что у пользователя root домашний каталог /root, но не сам /.
/bin - (binaries) бинарные файлы пользователя
Этот каталог содержит исполняемые файлы. Здесь расположены программы, которые можно использовать в однопользовательском режиме или режиме восстановления. Одним словом, те утилиты, которые могут использоваться пока еще не подключен каталог /usr/. Это такие общие команды, как cat, ls, tail, ps и т д.
/sbin - (system binaries) системные исполняемые файлы
Так же как и /bin, содержит двоичные исполняемые файлы, которые доступны на ранних этапах загрузки, когда не примонтирован каталог /usr. Но здесь находятся программы, которые можно выполнять только с правами суперпользователя. Это разные утилиты для обслуживания системы. Например, iptables, reboot, fdisk, ifconfig,swapon и т д.
/etc - (etcetera) конфигурационные файлы
В этой папке содержатся конфигурационные файлы всех программ, установленных в системе.
Кроме конфигурационных файлов, в системе инициализации Init Scripts, здесь находятся скрипты запуска и завершения системных демонов, монтирования файловых систем и автозагрузки программ. Структура каталогов linux в этой папке может быть немного запутанной, но предназначение всех их - настройка и конфигурация.
/dev - (devices) файлы устройств
В Linux все, в том числе внешние устройства являются файлами. Таким образом, все подключенные флешки, клавиатуры, микрофоны, камеры - это просто файлы в каталоге /dev/. Этот каталог содержит не совсем обычную файловую систему. Структура файловой системы Linux и содержащиеся в папке /dev файлы инициализируются при загрузке системы, сервисом udev. Выполняется сканирование всех подключенных устройств и создание для них специальных файлов. Это такие устройства, как: /dev/sda, /dev/sr0, /dev/tty1, /dev/usbmon0 и т д.
/proc - (proccess) информация о процессах
Это тоже необычная файловая система, а подсистема, динамически создаваемая ядром. Здесь содержится вся информация о запущенных процессах в реальном времени. По сути, это псевдофайловая система, содержащая подробную информацию о каждом процессе, его Pid, имя исполняемого файла, параметры запуска, доступ к оперативной памяти и так далее. Также здесь можно найти информацию об использовании системных ресурсов, например, /proc/cpuinfo, /proc/meminfo или /proc/uptime. Кроме файлов в этом каталоге есть большая структура папок linux, из которых можно узнать достаточно много информации о системе.
/var (variable) - Переменные файлы
Название каталога /var говорит само за себя, он должен содержать файлы, которые часто изменяются. Размер этих файлов постоянно увеличивается. Здесь содержатся файлы системных журналов, различные кеши, базы данных и так далее. Дальше рассмотрим назначение каталогов Linux в папке /var/.
/var/log - Файлы логов
/var/lib - базы данных
Еще один тип изменяемых файлов - это файлы баз данных, пакеты, сохраненные пакетным менеджером и т д.
/var/mail - почта
В эту папку почтовый сервер складывает все полученные или отправленные электронные письма, здесь же могут находиться его логи и файлы конфигурации.
/var/spool - принтер
Изначально, эта папка отвечала за очереди печати на принтере и работу набора программ cpus.
/var/lock - файлы блокировок
Здесь находятся файлы блокировок. Эти файлы означают, что определенный ресурс, файл или устройство занят и не может быть использован другим процессом. Apt-get, например, блокирует свою базу данных, чтобы другие программы не могли ее использовать, пока программа с ней работает.
/var/run - PID процессов
Содержит файлы с PID процессов, которые могут быть использованы, для взаимодействия между программами. В отличие от каталога /run данные сохраняются после перезагрузки.
/tmp (temp) - Временные файлы
В этом каталоге содержатся временные файлы, созданные системой, любыми программами или пользователями. Все пользователи имеют право записи в эту директорию.
Файлы удаляются при каждой перезагрузке. Аналогом Windows является папка Windows\Temp, здесь тоже хранятся все временные файлы.
/usr - (user applications) Программы пользователя
Это самый большой каталог с большим количеством функций. Тут наиболее большая структура каталогов Linux. Здесь находятся исполняемые файлы, исходники программ, различные ресурсы приложений, картинки, музыку и документацию.
/usr/bin/ - Исполняемые файлы
Содержит исполняемые файлы различных программ, которые не нужны на первых этапах загрузки системы, например, музыкальные плееры, графические редакторы, браузеры и так далее.
/usr/sbin/
Содержит двоичные файлы программ для системного администрирования, которые нужно выполнять с правами суперпользователя. Например, таких как Gparted, sshd, useradd, userdel и т д.
/usr/lib/ - Библиотеки
Содержит библиотеки для программ из /usr/bin или /usr/sbin.
/usr/local - Файлы пользователя
Содержит файлы программ, библиотек, и настроек созданные пользователем. Например, здесь могут храниться программы собранные и установленные из исходников и скрипты, написанные вручную.
/home - Домашняя папка
В этой папке хранятся домашние каталоги всех пользователей. В них они могут хранить свои личные файлы, настройки программ и т д. Например, /home/sergiy и т д. Если сравнивать с Windows, то это ваша папка пользователя на диске C, но в отличии от WIndows, home как правило размещается на отдельном разделе, поэтому при переустановке системы все ваши данные и настройки программ сохранятся.
/boot - Файлы загрузчика
Содержит все файлы, связанные с загрузчиком системы. Это ядро vmlinuz, образ initrd, а также файлы загрузчика, находящие в каталоге /boot/grub.
/lib (library) - Системные библиотеки
Содержит файлы системных библиотек, которые используются исполняемыми файлами в каталогах /bin и /sbin.
Библиотеки имеют имена файлов с расширением *.so и начинаются с префикса lib*. Например, libncurses.so.5.7. Папка /lib64 в 64 битных системах содержит 64 битные версии библиотек из /lib. Эту папку можно сравнить с WIndows\system32, там тоже сгружены все библиотеки системы, только там они лежат смешанные с исполняемыми файлами, а здесь все отдельно.
/opt (Optional applications) - Дополнительные программы
В эту папку устанавливаются проприетарные программы, игры или драйвера. Это программы созданные в виде отдельных исполняемых файлов самими производителями. Такие программы устанавливаются в под-каталоги /opt/, они очень похожи на программы Windows, все исполняемые файлы, библиотеки и файлы конфигурации находятся в одной папке.
/mnt (mount) - Монтирование
В этот каталог системные администраторы могут монтировать внешние или дополнительные файловые системы.
/media - Съемные носители
В этот каталог система монтирует все подключаемые внешние накопители - USB флешки, оптические диски и другие носители информации.
/srv (server) - Сервер
В этом каталоге содержатся файлы серверов и сервисов. Например, могут содержаться файлы веб-сервера apache.
/run - процессы
Еще один каталог, содержащий PID файлы процессов, похожий на /var/run, но в отличие от него, он размещен в TMPFS, а поэтому после перезагрузки все файлы теряются.
/sys (system) - Информация о системе
Назначение каталогов Linux из этой папки - получение информации о системе непосредственно от ядра. Это еще одна файловая система организуемая ядром и позволяющая просматривать и изменить многие параметры работы системы, например, работу swap, контролировать вентиляторы и многое другое.
