Автор: Пользователь скрыл имя, 03 Октября 2011 в 21:21, реферат
В практической деятельности большинства программистов рано или поздно возникают проблемы, для решения которых необходимо знать форматы исполняемых файлов. Если ассемблер является отражением архитектуры компьютера, то формат исполняемого файла является отражением архитектуры операционной системы.
Таблица секций состоит из структур размером по 40 байт каждая. Структуры детально описывают соответствующие секции. Поля, составляющие структуру таблицы секций, представлены в табл. 24.
Таблица 24. Содержимое структуры в таблице секций
Смещение Размер Назначение
+00h 8 символов Имя
секции (если имя меньше 8 байт, то оно дополнено
справа нулевыми байтами)
+08h 4 байта Размер секции (потребное количество памяти)
+0ch 4 байта ОАП,
по которому загрузчик должен загрузить
секцию (см.
также поле +14h)
+10h 4 байта Размер
секции, выровненный на ближайшую (в большую
сторону) границу, в соответствии с размером
выравнивания
(см. поля +20h и +24h в табл. 22)
+14h 4 байта ОАП
в PE-файле, где находятся данные для секции.
Это
поле совместно с полем +0ch необходимо
для того, что-
бы позволить программисту самому управлять
загрузкой
PE-файла
+18h 12 байтов 0
+24h 4 байта Флаги, характеризующие атрибуты секции (табл. 25)
В табл. 25 представлены значения флагов в описании секции.
Таблица 25. Значения флагов в описании секции
Значение Значение (если бит установлен)
00000020h Секция содержит программный код
00000040h Секция содержит инициализированные данные
00000080h Секция содержит неинициализированные данные
00000200h Используется компилятором
00000800h Используется компилятором
04000000h Секция не может кэшироваться
08000000h Секция не страничной организации
10000000h Совместно используемая секция
20000000h Секция является исполняемой (см. флаг 00000020h)
40000000h Секция только для чтения
80000000h Секция может использоваться для записи
Вслед за заголовком следует основная часть PE-файла — раздел секций. Необходимо отметить, что компиляторы фирм Microsoft и Bоrland (Inprise), создающие файлы PE-формата, используют несколько отличающихся по составу и наименованию секций. Для однозначности далее будут обсуждаться секции, создаваемые компиляторами фирмы Microsoft. Но если вы столкнетесь с необходимостью работать с PE-файлами, создаваемыми компиляторами фирмы Bоrland (Inprise), то по названиям и содержанию секций вы относительно легко сможете провести аналогию и правильную интерпретацию находящихся в них данных. Типичное приложение Windows реально содержит около девяти секций:
m .text — секция содержит исполняемый код. Так как в 32-разрядном режиме адресации используется сплошная модель памяти, то содержимое секций .text всех объектных файлов, подаваемых на вход компоновщика, собирается в одной секции .text исполняемого файла PE- формата;
m .bss — секция содержит все неинициализированные данные из секций .bss компонуемых объектных файлов, включая все переменные, объявленные как статические в пределах функций или исходного модуля;
m .rdata — секция содержит данные, доступные только для чтения: литеральные строки, константы и отладочную информацию;
m .data — секция содержит инициализированные и глобальные переменные (кроме динамических локальных переменных, которые располагаются в стеке). В основном, это инициализированные и глобальные данные приложения, собранные из всех секций .data компонуемых объектных файлов. Делается это так же, как и для кода, который собирается в секции .text;
m .rsrc — секция содержит информацию о ресурсах приложения. Эта секция начинается с каталога ресурса, и данные этой секции структурированы в дерево ресурсов (см. ниже информацию об описании ресурсов в PE-файле);
m .edata — секция содержит данные об экспортируемых функциях приложения или dll-библиотеки. В начале секции расположен каталог для получения доступа к информации об экспортируемых функциях (см. ниже);
m .idata — секция содержит данные об импортируемых приложением функциях (см. ниже);
m .debug — секция содержит отладочную информацию. Формат PE-файла также поддерживает работу с отдельным файлом отладки (обычно имеющим расширение .dbg), в котором собирается вся отладочная информация.
Рассмотрим более подробно некоторые секции. При этом раскроем некоторые механизмы, на которых основана работа платформы Win32. С секциями кода и данных особых вопросов не возникает, так как их содержание зависит от конкретного приложения. Другие секции имеют более формализованную структуру.
Описание и расположение ресурсов в PE-файле отличаются от того, как это было реализовано в NE-файлах. Сам формат конкретного ресурса остался практически неизменным (детально они описаны в файле resfmt.txt из Win32 SDK), но теперь все ресурсы сведены в сложную иерархию. Отдаленно эта иерархия напоминает структуру каталога диска (рис. 6). Основу этой иерархии составляют два типа элементов, которые, если следовать аналогии с файловой системой, описывают каталоги (типы ресурсов) и файлы (двоичные описания ресурсов). В отличие от структуры оглавления диска, иерархия описания ресурсов имеет четыре уровня. На первых трех уровнях находятся элементы одинаковой структуры, а на четвертом находятся элементы, описывающие конкретный ресурс и имеющие соответствующую описанию этого ресурса структуру.
В начале секции .rsrc находится элемент первого уровня иерархии, через который можно попасть на ветвь дерева каталога, описывающую нужный тип ресурса: меню, окно диалога, растровые изображения и т. д. (табл. 26).
Рис. 6. Пример иерархической структуры описания ресурсов в PE-файле
В начале секции .rsrc находится элемент первого уровня иерархии, через который можно попасть на ветвь дерева каталога, описывающую нужный тип ресурса: меню, окно диалога, растровые изображения и т. д. (см. табл. 26).
За этим элементом следует массив элементов, количество которых равно значению последнего поля табл. 26. Эти элементы имеют структуру, показанную в табл. 27.
Элементы второго уровня описывают экземпляры ресурсов определенного типа. При этом различаются именованные и неименованные (нумерованные) ресурсы. Рассмотрим формат элементов каталога. Они имеют структуру, показанную в табл. 28.
Таблица 26. Структура элемента первого уровня иерархии ресурсов
Смещение Размер, Назначение
байт
+00h 4 Характеристики ресурса или 0
+04h 4 Время и дата создания ресурса
+08h 4 0
+0Сh 2 0
+0Еh 2 Общее
количество типов ресурсов, используемых
в данном
исполняемом файле
Таблица
27. Структура элемента массива, следующего
за элементом каталога первого уровня
Смещение Размер, Назначение
байт
+00h 4 Тип ресурса
+04h 4 Младшие
31 бит представляют собой значение смещения
от начала секции ресурсов до структуры
с описанием эле-
мента каталога для данного типа ресурсов
Таблица 28. Структура элемента второго уровня иерархии ресурсов
Смещение Размер, Назначение
байт
+00h 4 0
+04h 4 Время и дата создания ресурса
+08h 4 0
+0сh 2 Количество
поименованных элементов, следующих за
дан-
ным экземпляром структуры (для корневого
элемента это
поле равно 0)
+0Еh 2 Количество
элементов, идентифицируемых целым значением
и следующих за данным экземпляром структуры
(для
корневого элемента это поле равно общему
количеству типов
ресурсов, используемых в данном исполняемом
файле)
За элементом каталога ресурсов второго уровня следует массив элементов, количество которых равно сумме значений двух последних полей структуры элемента каталога (см. табл. 28), то есть количества поименованных и нумерованных элементов. Эти элементы упорядочены по именам и номерам, соответственно. Формат этих элементов показан в табл. 29.
Последнее поле в табл. 28 содержит указатель на структуру третьего уровня иерархии. Эта структура имеет формат элемента каталога (см. табл. 26 и 28), но массив элементов, следующий за данной структурой, имеет один элемент, структура которого показана в табл. 30.
Таблица 29. Структура элемента массива, следующего за элементом каталога второго уровня
Смещение Размер, Назначение
байт
+00h 4 Интерпретация
этого поля зависит от состояния его старшего
бита (80000000h). Если старший бит нулевой,
то это поле
является целочисленным идентификатором
ресурса. Если
старший бит единичный, то это поле содержит
смещение (по
отношению к началу секции ресурсов) к
структуре, содержа-
щей имя ресурса. Эта структура, в свою
очередь, состоит из
двух полей: первые два байта содержат
количество символов
в имени ресурса, а далее следуют символы
имени, закодиро-
ванные (!) в Unicode
+04h 4 Значение
смещения от начала секции ресурсов до
структуры
с описанием языка
Таблица 30. Структура элемента массива, следующего за элементом каталога третьего уровня
Смещение Размер, Назначение
байт
+00h 4 Идентификатор языка
+04h 4 Значение
смещения от начала секции ресурсов до
струк-
туры с описанием ресурса
Идентификатор языка представляет собой предопределенную константу из файла winnt.h. Ниже приведен фрагмент из этого файла с определениями констант языка.
//Language IDs.
//The following two combinations of primary language ID and
//sublanguage ID have special semantics:
// Primary Language ID Sublanguage ID Result
// LANG_NEUTRAL SUBLANG_NEUTRAL Language neutral
// LANG_NEUTRAL SUBLANG_DEFAULT User default language
//LANG_NEUTRAL SUBLANG_SYS_DEFAULT System default language
//Primary language IDs.
#define LANG_NEUTRAL 0x00
#define LANG_AFRIKAANS 0x36
#define LANG_ALBANIAN 0x1c
… … …
#define LANG_ENGLISH 0x09
… … …
//Sublanguage IDs.
//The name immediately following SUBLANG_ dictates which primary
//language ID that sublanguage ID can be combined with to form a
//valid language ID.
//
… … …
#define SUBLANG_ENGLISH_CAN 0x04 // English (Canadian)
… … …
Второе поле элемента массива третьего уровня иерархии (см. табл. 30) содержит указатель на структуру, с которой начинается непосредственное описание ресурса (табл. 31).
Таблица 31. Структура описания ресурса
Смещение Размер, Назначение
байт
+00h 4 Размер памяти, занимаемой двоичным образом ресурса
+04h 4 Значение
смещения от начала секции ресурсов до
области
памяти, содержащей двоичное описание
ресурса
В качестве примера покажем содержимое секции описания ресурсов некоторого приложения. Допустим, что это приложение использует следующие ресурсы: два меню, одно из которых (MyMenu) является именованным ресурсом, а другое идентифицировано целочисленным значением (5), одно окно диалога (именованный ресурс) — DialogWin и растровое изображение (также именованный ресурс) — BitImage. Таким образом, имеется три именованных ресурса и один ресурс, идентифицированный целочисленным значением. Тогда содержимое секции ресурсов данного исполняемого файла будет представлять собой дерево, изображенное на рис. 6.