Метки: Portable executable pe, portable executable file format a reverse engineering view, portable executable detective, portable executable inspector, portable executable import table, portable executable скачать.
Расширение | |
---|---|
Сигнатура |
MZ (опционально), PE |
Разработан | |
Тип формата | |
Расширен из |
Portable Executable — (PE, произносится как [по́тэбл экзэкью́тэбл] — переносимый исполняемый) — формат исполняемых файлов, объектного кода и динамических библиотек, используемый в 32- и 64-битных версиях операционной системы Microsoft Windows. Формат PE представляет собой структуру данных, содержащую всю информацию, необходимую PE загрузчику для проецирования файла в память. Исполняемый код включает в себя ссылки для связывания динамически загружаемых библиотек, таблицы экспорта и импорта API функций, данные для управления ресурсами и данные локальной памяти потока (TLS). В операционных системах семейства Windows NT формат PE используется для EXE, DLL, SYS (драйверов устройств), и других типов файлов.
PE представляет собой модифицированную версию COFF формата файла для Unix. PE/COFF - альтернативный термин при разработке Windows.
На операционных системах семейства Windows NT формат PE в настоящий момент поддерживает следующие архитектуры наборов команд: IA-32, IA-64, и x86-64 (AMD64/Intel64). До Windows 2000 Windows NT (таким образом, и PE) поддерживал MIPS, Alpha, и PowerPC. Поскольку PE используется на Windows CE, он продолжает поддерживать несколько разновидностей MIPS, ARM (включая Thumb), и SuperH.
Основные «конкуренты» PE — ELF (используемый в Linux и большинстве других версий Unix) и Mach-O (используемый в Mac OS X).
Содержание |
С появлением операционной системы Windows NT 3.1 Microsoft перешла на формат PE. Все более поздние версии Windows, включая Windows 95/98/ME, поддерживают этот формат. Формат сохранил ограниченную поддержку существующего (MZ) для преодоления разрыва между системами, основанными на DOS, и системами NT. Например, заголовки PE/COFF всё ещё включают исполняемую программу MS-DOS, которая по умолчанию является заглушкой, выводящей на экран простое сообщение "This program cannot be run in DOS mode"
- "Эта программа не может быть выполнена в режиме DOS" (или подобное). PE продолжает служить изменяющейся платформе Windows. Некоторые расширения включают формат PE.NET (см. ниже), 64-разрядную версию под названием PE32+ (иногда PE+), и спецификацию для Windows CE.
Файл PE состоит из нескольких заголовков и секций, которые указывают динамическому компоновщику, как отображать файл в память. Исполняемый образ состоит из нескольких различных областей (секций), каждая из которых требует различных прав доступа к памяти; таким образом, начало каждой секции должно быть выровнено по границе страницы. Например, обычно секция .text, которая содержит код программы, отображена как исполняемая/доступная только для чтения, и секция .data, содержащая глобальные переменные, отображена как неисполняемая/доступная для чтения и записи. Однако, чтобы не тратить впустую пространство на жёстком диске, различные секции на нём на границу страницы не выровнены. Часть работы динамического компоновщика состоит в том, чтобы отобразить каждую секцию в память отдельно и присвоить корректные права доступа получившимся областям согласно указаниям, содержащимся в заголовках.
Одна из известных секций - таблица адресов импорта (IAT - Import Address Table), которая используется в качестве таблицы поиска, когда приложение вызывает функцию из другого модуля. Это может быть сделано и в форме импорта по порядковому номеру функции (ordinal), и импорта по её имени. Поскольку скомпилированной программе неизвестно расположение библиотек, от которых она зависит, то требуется производить косвенный переход всякий раз, когда происходит вызов API функции. Когда динамический компоновщик загружает модули и объединяет их, он записывает действительные адреса в область IAT так, чтобы они указали на ячейки памяти соответствующих библиотечных функций. Хотя это добавляет дополнительный переход внутри модуля, приводящий к потере производительности, это предоставляет ключевое преимущество: количество страниц памяти, которые должны быть скопированы загрузчиком при записи, минимизировано, что приводит к экономии памяти и дискового времени ввода-вывода. Если компилятору будет известно заранее, что вызов будет межмодульным (через атрибут dllimport), то он сможет произвести более оптимизированный код, который просто приводит к коду операции косвенного вызова.
Файлы PE не содержат позиционно-независимого кода. Вместо этого они скомпилированы для предпочтительного базового адреса, и все адреса, генерируемые компилятором/компоновщиком, заранее фиксированы. Если PE файл не может быть загружен по своему предпочтительному адресу (потому что он уже занят чем-то ещё), операционная система будет перебазировать его. Это включает в себя перевычисление каждого абсолютного адреса и изменение кода для того, чтобы использовать новые значения. Загрузчик делает это, сравнивая предпочтительный и фактический адреса загрузки, и вычисляя значение разности. Тогда для получения нового адреса ячейки памяти эта разность складывается с предпочтительным адресом. Базовые адреса перемещений хранятся в списке и при необходимости добавляются к существующей ячейке памяти. Полученный код является теперь отдельным по отношению к процессу и не является больше разделяемым, так что при таком способе теряются многие из преимуществ экономии памяти динамически загружаемых библиотек. Такой способ также значительно замедляет загрузку модуля. По этой причине следует избегать перебазирования везде, где это возможно; например, библиотеки, поставляемые Microsoft, имеют предварительно вычисленные неперекрывающиеся базовые адреса. В случае отсутствия необходимости перебазировании PE файлы имеют преимущество очень эффективного кода, но при наличии перебазирования издержки в использования памяти могут быть значительными. Это отличает формат PE от ELF, который использует полностью позиционно-независимый код и глобальную таблицу смещений, которая жертвует временем выполнения в пользу расходования памяти.
Платформа .NET корпорации Microsoft расширила формат PE с помощью функций, которые поддерживают общеязыковую среду исполнения (Common Language Runtime - CLR). Среди дополнений - заголовок CLR и секция данных CLR. После загрузки двоичного файла загрузчик ОС приводит к выполнению CLR через ссылку в таблице импорта PE/COFF. Затем CLR загружает заголовок CLR и секции данных.
Секция данных CLR содержит два важных сегмента: сегмент метаданных и сегмент кода промежуточного языка (IL):
Формат PE также используется ReactOS, поскольку ReactOS предназначена для того, чтобы быть двоично совместимой с Windows на уровне кода. Кроме того, он исторически использовался многими другими операционными системами, включая SkyOS и BeOS R3. Однако, и SkyOS, и BeOS в конечном счёте перешли на формат ELF.
Поскольку платформа разработки Mono намеревается быть двоично совместимой с Microsoft .NET, она использует тот же формат PE, что и в реализации Microsoft.
На платформе x86 в Unix-подобных операционных системах, некоторые двоичные файлы Windows (в формате PE) могут быть выполнены с помощью Wine. HX DOS Extender также использует формат PE для собственных 32-разрядных двоичных файлов DOS, кроме того, может в некоторой степени выполнить существующие двоичные файлы Windows в DOS, действуя, таким образом, как Wine для DOS.
Mac OS X 10.5 имеет возможность загружать и интерпретировать PE файлы, однако они не являются двоично совместимыми с Windows.
Форматы исполняемых файлов | |
---|---|
Windows, DOS и OS/2 | .COM • .EXE (MZ / NE / LE / LX / PE / W3) |
Unix | a.out • COFF • ECOFF • ELF • Mach-O • SOM • XCOFF |
Прочие | Intel HEX • PEF • SREC |
Это заготовка статьи о программном обеспечении. Вы можете помочь проекту, исправив и дополнив её. |
Tags: Portable executable pe, portable executable file format a reverse engineering view, portable executable detective, portable executable inspector, portable executable import table, portable executable скачать.