Портативный исполняемый файл

Портативный исполняемый файл
Расширение имени файла	.acm, .ax, .cpl, .dll, .drv, .efi, .exe, .mui, .ocx, .scr, .sys, .tsp, .mun
Тип интернет-СМИ	приложение/vnd.microsoft.portable-исполняемый файл
Разработано	В настоящее время: Майкрософт
Тип формата	Двоичные , исполняемые файлы , объекты , общие библиотеки
Расширено с	Исполняемый файл DOS MZ ; ПАМЯТЬ

Формат Portable Executable ( PE ) — это формат файлов для исполняемых файлов , объектного кода , DLL и других файлов, используемый в 32-битных и 64-битных версиях Windows операционных систем , а также в UEFI . средах ^[2] Формат PE представляет собой структуру данных, инкапсулирующую информацию, необходимую загрузчику ОС Windows для управления завернутым исполняемым кодом . Сюда входят ссылки на динамические библиотеки для связывания , таблицы экспорта и импорта API , данные управления ресурсами и данные локального хранилища потоков (TLS). В операционных системах NT формат PE используется для файлов EXE , DLL , SYS ( драйвер устройства ), MUI и других типов файлов. В спецификации Unified Extensible Firmware Interface (UEFI) указано, что PE является стандартным форматом исполняемого файла в средах EFI. ^[3]

В операционных системах Windows NT PE в настоящее время поддерживает (ISA) IA-32 , x86-64 (AMD64/Intel 64), IA-64 , ARM и ARM64 архитектуры набора команд . До Windows 2000 Windows NT (и, следовательно, PE) поддерживала ISA MIPS , Alpha и PowerPC . Поскольку PE используется в Windows CE , он продолжает поддерживать несколько вариантов MIPS, ARM (включая Thumb ) и SuperH ISA. ^[4]

Аналогичными форматами PE являются ELF (используется в Linux и большинстве других версий Unix ) и Mach-O (используется в macOS и iOS ).

История

Microsoft перешла на формат PE из 16-битных форматов NE с появлением операционной системы Windows NT 3.1 . Все более поздние версии Windows, включая Windows 95/98/ME и дополнение Win32s к Windows 3.1x, поддерживают файловую структуру. Формат сохранил ограниченную устаревшую поддержку, чтобы преодолеть разрыв между системами DOS и NT. Например, заголовки PE/COFF по-прежнему включают в себя исполняемую программу DOS , которая по умолчанию является заглушкой DOS и отображает сообщение типа «Эту программу невозможно запустить в режиме DOS» (или аналогичном), хотя это может быть полноценная программа DOS. версия программы (более поздний известный случай - установщик Windows 98 SE). Компоновщик Microsoft имеет /STUB переключитесь, чтобы прикрепить один. ^[5] Это представляет собой форму жирного двоичного файла .

PE также продолжает обслуживать меняющуюся платформу Windows. Некоторые расширения включают формат .NET PE, версию с поддержкой 64-битного адресного пространства, называемую PE32+, и спецификацию для Windows CE.

Является ли исполняемый код 32- или 64-битным, можно узнать, проверив поле «Машина» в IMAGE_FILE_HEADER. ^[6] Являются ли адреса в исполняемом файле 32- или 64-битными, можно узнать, проверив поле Magic в IMAGE_OPTIONAL_HEADER. 10B ₁₆ указывает на файл PE32, тогда как 20B ₁₆ указывает на файл PE32+. ^[7]

Технические детали

Макет

PE-файл состоит из ряда заголовков и разделов, которые информируют динамический компоновщик о том, как отобразить файл в память. Исполняемый образ состоит из нескольких разных регионов, каждый из которых требует разной защиты памяти; поэтому начало каждого раздела должно быть выровнено по границе страницы. ^[8] Например, обычно раздел .text (который содержит программный код) отображается как доступный только для выполнения/чтения, а раздел .data (содержащий глобальные переменные) отображается как запись без выполнения/чтения. Однако, чтобы избежать потери места, различные разделы не выравниваются по страницам на диске. Часть работы динамического компоновщика заключается в индивидуальном сопоставлении каждого раздела с памятью и назначении правильных разрешений результирующим областям в соответствии с инструкциями, содержащимися в заголовках. ^[9]

Импортировать таблицу

Следует отметить таблицу адресов импорта (IAT), которая используется в качестве таблицы поиска, когда приложение вызывает функцию в другом модуле. Это может быть как импорт по порядковому номеру, так и импорт по имени . Поскольку скомпилированная программа не может знать расположение в памяти библиотек, от которых она зависит, при каждом вызове API требуется непрямой переход. Когда динамический компоновщик загружает модули и объединяет их вместе, он записывает фактические адреса в слоты IAT, чтобы они указывали на ячейки памяти соответствующих библиотечных функций. Хотя это добавляет дополнительный скачок по сравнению со стоимостью внутримодульного вызова, что приводит к снижению производительности, это дает ключевое преимущество: количество страниц памяти, которые необходимо копировать при записи и изменить загрузчиком, сведено к минимуму, что экономит память. и время дискового ввода-вывода. Если компилятор заранее знает, что вызов будет межмодульным (через атрибут dllimport), он может создать более оптимизированный код, который просто приводит к коду операции косвенного вызова. . ^[9]

Переезды

PE-файлы обычно не содержат позиционно-независимый код . Вместо этого они компилируются по предпочтительному базовому адресу , и все адреса, выдаваемые компилятором/компоновщиком, заранее фиксируются. Если PE-файл не может быть загружен по предпочитаемому адресу (поскольку он уже занят чем-то другим), операционная система перебазирует его . Это включает в себя пересчет каждого абсолютного адреса и изменение кода для использования новых значений. Загрузчик делает это, сравнивая предпочтительный и фактический адреса загрузки и вычисляя значение дельты . Затем он добавляется к предпочтительному адресу, чтобы получить новый адрес ячейки памяти. Базовые перемещения сохраняются в списке и при необходимости добавляются в существующую ячейку памяти. Результирующий код теперь является личным для процесса и больше не подлежит совместному использованию , поэтому в этом сценарии теряются многие преимущества DLL по экономии памяти. Это также значительно замедляет загрузку модуля. По этой причине следует избегать перебазирования везде, где это возможно, а в библиотеках DLL, поставляемых Microsoft, базовые адреса заранее рассчитаны, чтобы не перекрываться. Таким образом, в случае отсутствия перебазирования PE имеет преимущество очень эффективного кода, но при наличии перебазирования использование памяти может оказаться дорогостоящим. Это контрастирует с ELF , где полностью позиционно-независимый код обычно предпочтительнее перемещения во время загрузки, таким образом, экономя время выполнения в пользу меньшего использования памяти.

.NET, метаданные и формат PE

В исполняемом файле .NET раздел кода PE содержит заглушку, которая вызывает запись запуска виртуальной машины CLR : _CorExeMain или _CorDllMain в mscoree.dll, так же, как это было в исполняемых файлах Visual Basic . Затем виртуальная машина использует имеющиеся метаданные .NET, корень которых: IMAGE_COR20_HEADER (также называемый «заголовком CLR»), на который указывает IMAGE_DIRECTORY_ENTRY_COMHEADER (эта запись ранее использовалась для метаданных COM+ в приложениях COM+, отсюда и название ^{[ нужна ссылка ]}) запись в каталоге данных заголовка PE. IMAGE_COR20_HEADER сильно напоминает дополнительный заголовок PE, по сути играющий роль загрузчика CLR. ^[4]

Данные, относящиеся к CLR, включая саму корневую структуру, обычно содержатся в разделе общего кода. .text. Он состоит из нескольких каталогов: метаданных, встроенных ресурсов, строгих имен и нескольких каталогов для совместимости с собственным кодом. Каталог метаданных — это набор таблиц, в которых перечислены все отдельные объекты .NET в сборке, включая типы, методы, поля, константы, события, а также ссылки между ними и на другие сборки.

Использование в других операционных системах

Формат PE также используется ReactOS , поскольку ReactOS предназначена для двоичной совместимости с Windows. Он также исторически использовался рядом других операционных систем, включая SkyOS и BeOS R3. Однако и SkyOS, и BeOS в конечном итоге перешли на ELF . ^{[ нужна ссылка ]}

Поскольку платформа разработки Mono должна быть двоично совместима с Microsoft .NET Framework , она использует тот же формат PE, что и реализация Microsoft. То же самое касается собственного кроссплатформенного .NET Core от Microsoft .

В операционных системах x86 (-64) Unix-подобных двоичные файлы Windows (в формате PE) могут выполняться с помощью Wine . HX DOS Extender также использует формат PE для собственных 32-битных двоичных файлов DOS, а также может в некоторой степени выполнять существующие двоичные файлы Windows в DOS, действуя таким образом как эквивалент Wine для DOS.

Mac OS X 10.5 имеет возможность загружать и анализировать PE-файлы, но не совместима на двоичном уровне с Windows. ^[10]

Прошивки UEFI и EFI используют переносимые исполняемые файлы, а также Windows ABI x64 соглашение о вызовах для приложений .

См. также

а.аут
Сравнение форматов исполняемых файлов
Исполняемое сжатие
ar (Unix), поскольку все библиотеки COFF используют один и тот же формат.
Виртуализация приложений

Ссылки

^ Андерссон, Хенрик (23 апреля 2015 г.). «приложение/vnd.microsoft.portable-executable» . ИАНА . Проверено 26 марта 2017 г.
^ «Переносной исполняемый файл (PE) — Определение — Trend Micro IN» . www.trendmicro.com . Проверено 10 ноября 2022 г.
^ «Спецификация UEFI, версия 2.8B» (PDF) . , примечание на стр. 15 гласит, что «этот тип образа выбран для того, чтобы образы UEFI могли содержать инструкции Thumb и Thumb2, при этом сами интерфейсы EFI определяются как находящиеся в режиме ARM».
^ Перейти обратно: ^а ^б «Формат PE (Windows)» . Проверено 21 октября 2017 г.
^ http://msdn.microsoft.com/en-us/library/7z0585h5.aspx
^ различает 32 и 64 бита невооруженным глазом. Объяснение трюка с PE: Карстен Хан
^ Формат PE на Microsoft.com
^ «Переносной исполняемый файл сверху вниз» . Проверено 21 октября 2017 г.
^ Перейти обратно: ^а ^б «Взгляд внутрь PE: обзор переносимого исполняемого файла Win32» . Проверено 21 октября 2017 г.
^ Шартье, Дэвид (30 ноября 2007 г.). «Раскрыто: доказательства того, что Mac OS X вскоре сможет запускать приложения Windows» . Арс Техника . Проверено 3 декабря 2007 г. ... Стивен Эдвардс описывает открытие того, что Leopard, по-видимому, содержит недокументированный загрузчик переносимых исполняемых файлов, типа файла, используемого в 32-битных и 64-битных версиях Windows. Дальнейшие исследования показали, что собственный загрузчик Leopard пытается найти файлы Windows DLL при попытке загрузить двоичный файл Windows.

Внешние ссылки

Формат PE (последний онлайн-документ)
Спецификации форматов стандартного интерфейса инструмента (TIS) для Windows версии 1.0 (номер заказа Intel 241597, комитет TIS, февраль 1993 г.)
Портативный исполняемый формат (Майкл Дж. О'Лири, служба поддержки разработчиков Microsoft)
Заглядывание внутрь PE: обзор формата переносимых исполняемых файлов Win32 . Мэтт Питрек , Microsoft Systems Journal, март 1994 г.
Углубленный анализ формата переносимого исполняемого файла Win32. Мэтт Питрек , MSDN журнал . Часть I, февраль 2002 г .; Часть II, март 2002 г.
Формат файла .NET Дэниела Пистелли
Блог Эро Карреры, описывающий PE-заголовок и порядок его прохождения.
PE Internals предоставляет простой способ изучения формата переносимых исполняемых файлов.
PE Explorer

[1] Андерссон, Хенрик (23 апреля 2015 г.). «приложение/vnd.microsoft.portable-executable» . ИАНА . Проверено 26 марта 2017 г.

[2] «Переносной исполняемый файл (PE) — Определение — Trend Micro IN» . www.trendmicro.com . Проверено 10 ноября 2022 г.

[3] «Спецификация UEFI, версия 2.8B» (PDF) . , примечание на стр. 15 гласит, что «этот тип образа выбран для того, чтобы образы UEFI могли содержать инструкции Thumb и Thumb2, при этом сами интерфейсы EFI определяются как находящиеся в режиме ARM».

[PE_Format_(Windows)-4] Перейти обратно: ^а ^б «Формат PE (Windows)» . Проверено 21 октября 2017 г.

[5] ttp://msdn.microsoft.com/en-us/library/7z0585h5.aspx

[6] различает 32 и 64 бита невооруженным глазом. Объяснение трюка с PE: Карстен Хан

[7] Формат PE на Microsoft.com

[8] «Переносной исполняемый файл сверху вниз» . Проверено 21 октября 2017 г.

[Peering_Inside-9] Перейти обратно: ^а ^б «Взгляд внутрь PE: обзор переносимого исполняемого файла Win32» . Проверено 21 октября 2017 г.

[chartier-10] Шартье, Дэвид (30 ноября 2007 г.). «Раскрыто: доказательства того, что Mac OS X вскоре сможет запускать приложения Windows» . Арс Техника . Проверено 3 декабря 2007 г. ... Стивен Эдвардс описывает открытие того, что Leopard, по-видимому, содержит недокументированный загрузчик переносимых исполняемых файлов, типа файла, используемого в 32-битных и 64-битных версиях Windows. Дальнейшие исследования показали, что собственный загрузчик Leopard пытается найти файлы Windows DLL при попытке загрузить двоичный файл Windows.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]