Jump to content

Portable Executable: Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous edit
Content deleted Content added
VisualWikitext
No edit summary
m Duplicate word removed
 
(28 intermediate revisions by 17 users not shown)
Line 1: Line 1:
{{short description|File format}}
{{short description|File format}}
{{distinguish|Portable application|Windows Preinstallation Environment}}
{{distinguish|Portable application|Windows Preinstallation Environment}}
{{refimprove|date=December 2010}}
{{Infobox file format
{{Infobox file format
| name = Portable Executable
| name = Portable Executable
| icon =
| icon =
| extension = <code>.acm</code>, <code>.ax</code>, <code>.cpl</code>, <code>.dll</code>, <code>.drv</code>, <code>.efi</code>, <code>.exe</code>, <code>.mui</code>, <code>.ocx</code>, <code>.scr</code>, <code>.sys</code>, <code>.tsp</code>, <code>.mun</code>
| extension = <code>.acm</code>, <code>.ax</code>, <code>.cpl</code>, <code>.dll</code>, <code>.drv</code>, <code>.efi</code>, <code>[[.exe]]</code>, <code>.mui</code>, <code>.ocx</code>, <code>.scr</code>, <code>.sys</code>, <code>.tsp</code>, <code>.mun</code>, <code>.msstyles</code>
| mime = application/vnd.microsoft.portable-executable<ref>{{Cite web|url=https://www.iana.org/assignments/media-types/application/vnd.microsoft.portable-executable|title=application/vnd.microsoft.portable-executable|access-date=2017-03-26|last=Andersson|first=Henrik|date=2015-04-23|publisher=IANA}}</ref>
| mime = application/vnd.microsoft.portable-executable<ref>{{Cite web|url=https://www.iana.org/assignments/media-types/application/vnd.microsoft.portable-executable|title=application/vnd.microsoft.portable-executable|access-date=2017-03-26|last=Andersson|first=Henrik|date=2015-04-23|publisher=IANA}}</ref>
| owner = Currently: [[Microsoft]]
| owner = Currently: [[Microsoft]]
| genre = [[Binary file|Binary]], [[executable]], [[object code|object]], [[shared libraries]]
| genre = [[Binary file|Binary]], [[executable]], [[object code|object]], [[shared libraries]]
| extendedfrom = [[DOS MZ executable]]<br/>[[COFF]]
| extendedfrom = [[DOS MZ executable]]<br />[[COFF]]
| containerfor =
| containerfor =
| containedby =
| containedby =
|=
|=
}}
}}
The '''Portable Executable''' ('''PE''') format is a [[file format]] for [[executable]]s, [[object file|object code]], [[Dynamic-link library|DLL]]s and others used in 32-bit and 64-bit versions of [[Microsoft Windows|Windows]] [[operating system]]s, and in [[UEFI]] environments.<ref>{{Cite web |title=Portable executable (PE) - Definition - Trend Micro IN |url=https://www.trendmicro.com/vinfo/in/security/definition/portable-executable-pe |access-date=2022-11-10 |website=www.trendmicro.com}}</ref> The PE format is a data structure that encapsulates the information necessary for the Windows OS loader to manage the wrapped [[Executable|executable code]]. This includes [[Library (computer science)#Dynamic linking|dynamic library references for linking]], [[Application programming interface|API]] export and import tables, resource management data and [[thread-local storage]] (TLS) data. On [[Windows NT|NT]] operating systems, the PE format is used for [[EXE]], [[Dynamic-link library|DLL]], [[.sys|SYS]] ([[device driver]]), [[.mui|MUI]] and other file types. The [[Unified Extensible Firmware Interface|Unified Extensible Firmware Interface (UEFI)]] specification states that PE is the standard executable format in EFI environments.<ref>{{cite web|url=https://uefi.org/sites/default/files/resources/UEFI%20Spec%202.8B%20May%202020.pdf|title=UEFI Specification, version 2.8B}}, a note on p.15, states that "this image type is chosen to enable UEFI images to contain Thumb and Thumb2 instructions while defining the EFI interfaces themselves to be in ARM mode."</ref>
The '''Portable Executable''' ('''PE''') format is a [[file format]] for [[executable]]s, [[object file|object code]], [[Dynamic-link library|dynamic-link-libraries]] (DLLs), and binary files used on 32-bit and 64-bit [[Microsoft Windows|Windows]] [[operating system]]s, as well as in [[UEFI]] environments.<ref>{{Cite web |title=Portable executable (PE) - Definition - Trend Micro IN |url=https://www.trendmicro.com/vinfo/in/security/definition/portable-executable-pe |access-date=2022-11-10 |website=www.trendmicro.com}}</ref> It is the standard format for executables on Windows NT-based systems, including files such as <code>.exe</code>, <code>.dll</code>, <code>.sys</code> (for system drivers), and <code>.mui</code>. At its core, the PE format is a structured data container that gives the Windows operating system loader eveything it needs to properly manage the [[Executable|executable code]] it contains. This includes references for [[Library (computer science)#Dynamic linking|dynamically linked libraries]], tables for importing and exporting [[Application programming interface|API]]<nowiki/>s, resource management data and [[thread-local storage]] (TLS) information.


On Windows NT operating systems, PE currently supports the [[x86-32]], [[x86-64]] (AMD64/Intel 64), [[IA-64]], [[ARM architecture|ARM]] and [[ARM64]] [[instruction set architecture]]s (ISAs). Prior to [[Windows 2000]], Windows NT (and thus PE) supported the [[MIPS architecture|MIPS]], [[DEC Alpha|Alpha]], and [[PowerPC]] ISAs. Because PE is used on [[Windows CE]], it continues to support several variants of the MIPS, [[ARM architecture|ARM]] (including [[ARM architecture#Thumb|Thumb]]), and [[SuperH]] ISAs.<ref name="PE Format (Windows)">{{cite web|url=https://msdn.microsoft.com/en-us/library/windows/desktop/ms680547(v=vs.85).aspx|title=PE Format (Windows)| access-date=2017-10-21}}</ref>
According to the [[Unified Extensible Firmware Interface|Unified Extensible Firmware Interface (UEFI)]] specification, the PE format is also the accepted standard for executables in EFI environments.<ref>{{cite web |url=https://uefi.org/sites/default/files/resources/UEFI%20Spec%202.8B%20May%202020.pdf |title=UEFI Specification, version 2.8B}}, a note on p.15, states that "this image type is chosen to enable UEFI images to contain Thumb and Thumb2 instructions while defining the EFI interfaces themselves to be in ARM mode."</ref> On Windows NT systems, it currently supports a range of [[Instruction set architecture|instruction sets]], including [[IA-32]], [[x86-64]] (AMD64/Intel 64), [[IA-64]], [[ARM architecture|ARM]] and [[ARM64]]. Before the advent of [[Windows 2000]], Windows NT (and by extension the PE format) also supported [[MIPS architecture|MIPS]], [[DEC Alpha|Alpha]], and [[PowerPC]] architectures. Moreover, thanks to its use in [[Windows CE]], PE has maintained compatibility with several MIPS, [[ARM architecture|ARM]] (including [[ARM architecture#Thumb|Thumb]]), and [[SuperH]] variants.<ref name="PE Format (Windows)">{{cite web|url=https://msdn.microsoft.com/en-us/library/windows/desktop/ms680547(v=vs.85).aspx|title=PE Format (Windows)| access-date=2017-10-21}}</ref>


Analogous formats to PE are [[Executable and Linkable Format|ELF]] (used in [[Linux]] and most other versions of [[Unix]]) and [[Mach-O]] (used in [[macOS]] and [[iOS]]).
Functionally, the PE format is similar to other platform-specific executable formats, such as the [[Executable and Linkable Format|ELF]] format used in [[Linux]] and most [[Unix-like|Unix-like systems]], and the [[Mach-O]] format found in [[macOS]] and [[iOS]].


== History ==
== History ==


Microsoft first introduced the PE format with [[Windows NT 3.1]], replacing the older 16-bit [[New Executable]] (NE) format. Soon after, Windows 95, 98, ME, and the Win32s extension for Windows 3.1x, all adopted the PE structure. Each PE file includes a DOS executable header, which generally displays the message "[[New Executable|This program cannot be run in DOS mode]]". However, this DOS section can be replaced by a fully functional DOS program, as demonstrated in the Windows 98 SE installer. Developers can add such a program using the <code>/STUB</code> switch with Microsoft's linker, effectively creating a [[fat binary]].<ref>{{cite web | url=http://msdn.microsoft.com/en-us/library/7z0585h5.aspx | title=/STUB (MS-DOS Stub File Name) | date=3 August 2021 }}</ref>
Microsoft migrated to the PE format from the 16-bit [[New Executable|NE]] formats with the introduction of the [[Windows NT 3.1]] operating system. All later versions of Windows, including Windows 95/98/ME and the [[Win32s]] addition to Windows 3.1x, support the file structure. The format has retained limited legacy support to bridge the gap between [[DOS]]-based and NT systems. For example, PE/COFF headers still include a [[DOS MZ executable|DOS executable program]], which is by default a [[DOS stub]] that displays a message like "This program cannot be run in DOS mode" (or similar), though it can be a full-fledged DOS version of the program (a later notable case being the Windows 98 SE installer).<ref>E.g. Microsoft's linker has [http://msdn.microsoft.com/en-us/library/7z0585h5.aspx /STUB switch] to attach one</ref> This constitutes a form of [[fat binary]]. PE also continues to serve the changing Windows platform. Some extensions include the .NET PE format (see below), a version with 64-bit address space support called PE32+,<ref>In order to know whether the executable code is 32- or 64-bit, check the Machine field in the IMAGE_FILE_HEADER. ([https://gdatasoftware.com/blog/pebitnesstrick PE trick explained: Telling 32 and 64 bit apart with naked eye] by Karsten Hahn)<br>To see if addresses in the executable are 32- or 64-bit, check the Magic field in the IMAGE_OPTIONAL_HEADER. 10B<sub>16</sub> indicates a PE32 file, whereas 20B<sub>16</sub> indicates a PE32+ file. ([https://docs.microsoft.com/en-us/windows/win32/debug/pe-format PE Format] at Microsoft.com)</ref> and a specification for Windows CE.

Over time, the PE format has grown with the Windows platform. Notable extensions include the [[.NET]] PE format for managed code, PE32+ for 64-bit address space support, and a specialized version for [[Windows Embedded Compact|Windows CE]].

To determine whether a PE file is intended for 32-bit or 64-bit architectures, one can examine the Machine field in the IMAGE_FILE_HEADER.<ref>[https://gdatasoftware.com/blog/pebitnesstrick PE trick explained: Telling 32 and 64 bit apart with naked eye] by Karsten Hahn</ref> Common machine values are <code>0x014c</code> for 32-bit Intel processors and <code>0x8664</code> for x64 processors. Additionally, the Magic field in the <code>IMAGE_OPTIONAL_HEADER</code> reveals whether addresses are 32-bit or 64-bit. A value of <code>0x10B</code> indicates a 32-bit (PE32) file, while <code>0x20B</code> indicates a 64-bit (PE32) file.<ref>[https://docs.microsoft.com/en-us/windows/win32/debug/pe-format PE Format] at Microsoft.com</ref>


==Technical details==
==Technical details==
Line 28: Line 31:
===Layout===
===Layout===
[[File:Portable Executable 32 bit Structure in SVG fixed.svg|thumb|Structure of a Portable Executable 32 bit]]
[[File:Portable Executable 32 bit Structure in SVG fixed.svg|thumb|Structure of a Portable Executable 32 bit]]
A PE file consists of a number of headers and sections that tell the [[dynamic linker]] how to map the file into memory. An executable image consists of several different regions, each of which require different memory protection; so the start of each section must be aligned to a page boundary.<ref>{{cite web |url=http://www.csn.ul.ie/%7Ecaolan/pub/winresdump/winresdump/doc/pefile2.html |title=The Portable Executable File From Top to Bottom |access-date=2017-10-21}}</ref> For instance, typically the ''.text'' section (which holds program code) is mapped as execute/read-only, and the ''.data'' section (holding global variables) is mapped as no-execute/read write. However, to avoid wasting space, the different sections are not page aligned on disk. Part of the job of the dynamic linker is to map each section to memory individually and assign the correct permissions to the resulting regions, according to the instructions found in the headers.<ref name="Peering Inside">{{cite web |url=https://msdn.microsoft.com/en-us/library/ms809762.aspx |title=Peering Inside the PE: A Tour of the Win32 Portable Executable File |access-date=2017-10-21}}</ref>
A PE file consists of a several headers and sections that instruct the [[dynamic linker]] about on how to map the file into memory. An executable image consists of several different regions, each requiring different memory protection attributres. To ensure proper alignment, the start of each section must align to a page boundary.<ref>{{cite web |url=http://www.csn.ul.ie/%7Ecaolan/pub/winresdump/winresdump/doc/pefile2.html |title=The Portable Executable File From Top to Bottom |access-date=2017-10-21}}</ref> For instance, the ''.text'' section, which contains program code, is typically mapped as an execute/read-only. Conversely, the ''.data'' section, which holds global variables, is mapped as no-execute/read write. However, to conserve space, sections are not aligned on disk in this manner. The dynamic linker maps each section to memory individually and assigns the correct permissions based on the information in the headers.<ref name="Peering Inside">{{cite web |url=https://msdn.microsoft.com/en-us/library/ms809762.aspx |title=Peering Inside the PE: A Tour of the Win32 Portable Executable File |date=30 June 2010 |access-date=2017-10-21}}</ref>


===Import table===
===Import table===
One section of note is the ''import address table'' (IAT), which is used as a lookup table when the application is calling a function in a different module. It can be in the form of both [[Dynamic-link library#Symbol resolution and binding|import by ordinal and import by name]]. Because a compiled program cannot know the memory location of the libraries it depends upon, an indirect jump is required whenever an API call is made. As the dynamic linker loads modules and joins them together, it writes actual addresses into the IAT slots, so that they point to the memory locations of the corresponding library functions. Though this adds an extra jump over the cost of an intra-module call resulting in a performance penalty, it provides a key benefit: The number of memory pages that need to be [[copy-on-write]] changed by the loader is minimized, saving memory and disk I/O time. If the compiler knows ahead of time that a call will be inter-module (via a dllimport attribute) it can produce more optimized code that simply results in an indirect call [[opcode]].<ref name="Peering Inside" />
The ''import address table'' (IAT) is used as a lookup table when the application calls a function in a different module. The [[Dynamic-link library|imports]] can be specified by ordinal or by name. Because a compiled program cannot know the memory locations of its dependent libraries beforehand, an indirect jump is necessary for API calls. As the dynamic linker holds modules and resolves dependancies, it populates the IAT slots with actual addresses of the corresponding library functions. Although this adds an extra jump, incurring a performance penalty compared to intermodular calls, it minimizes the number of memory pages that that require [[copy-on-write]] changes, thus conserving memory and disk I/O. If a call is known to be intermodular beforehand (if indicated by a [[Dynamic-link library|dllimport]] attribute), the compiler can generate optimized code with a simple indirect call [[opcode]].<ref name="Peering Inside" />


=== Address Space Layout Randomization (ASLR) ===
===Relocations===
PE files aren't [[position-independent code|position-independent]] by default; they are compiled to run at a specific, fixed memory address. Modern operating systems use Address Space Layout Randomization ([[Address space layout randomization|ASLR]]) to make it harder for attackers to exploit memory-related vulnerabilities. ASLR works by randomly changing the memory address of important parts of the program every time it's loaded. This includes the base address of the program itself, shared libraries (DLLs), and memory areas like the heap and stack. as a defense mechanism against memory-based exploits. ASLR rearranges the address space positions of key data areas of a process, including the base of the [[executable]] and the positions of the [[Stack-based memory allocation|stack]], [[Dynamic memory allocation|heap]] and [[Library (computer science)|libraries]]. By randomizing these memory addresses each time the process an application is loaded, ASLR prevents attackers from being able to reliably predict memory locations.
{{Update|section|reason=Use of [[Address space layout randomization|ASLR]] and the trickery used to dodge the resulting problems|date=October 2017}}
PE files normally do not contain [[position-independent code]]. Instead they are compiled to a preferred ''[[base address]]'', and all addresses emitted by the compiler/linker are fixed ahead of time. If a PE file cannot be loaded at its preferred address (because it's already taken by something else), the operating system will ''[[rebasing|rebase]]'' it. This involves recalculating every absolute address and modifying the code to use the new values. The loader does this by comparing the preferred and actual load addresses, and calculating a [[Delta encoding|delta]] value. This is then added to the preferred address to come up with the new address of the memory location. Base [[Relocation (computing)|relocation]]s are stored in a list and added, as needed, to an existing memory location. The resulting code is now private to the process and no longer [[shared library|shareable]], so many of the memory saving benefits of DLLs are lost in this scenario. It also slows down loading of the module significantly. For this reason rebasing is to be avoided wherever possible, and the DLLs shipped by Microsoft have base addresses pre-computed so as not to overlap. In the no rebase case PE therefore has the advantage of very efficient code, but in the presence of rebasing the memory usage hit can be expensive. This contrasts with [[Executable and Linkable Format|ELF]] where fully position-independent code is usually preferred to load-time relocation, thus trading off execution time in favor of lower memory usage.


==.NET, metadata, and the PE format==
== .NET, metadata, and the PE format ==

In a .NET executable, the PE code section contains a stub that invokes the [[Common Language Runtime|CLR]] virtual machine startup entry, <code>_CorExeMain</code> or <code>_CorDllMain</code> in <code>mscoree.dll</code>, much like it was in [[Visual Basic]] executables. The virtual machine then makes use of .NET metadata present, the root of which, <code>IMAGE_COR20_HEADER</code> (also called "CLR header") is pointed to by <code>IMAGE_DIRECTORY_ENTRY_COMHEADER</code><ref>The entry was previously used for [[COM+]] metadata in COM+ applications, hence the name</ref> entry in the PE header's data directory. <code>IMAGE_COR20_HEADER</code> strongly resembles PE's optional header, essentially playing its role for the CLR loader.<ref name="PE Format (Windows)"/>
In a .NET executable, the PE code section contains a stub that invokes the [[Common Language Runtime|CLR]] virtual machine startup entry, <code>_CorExeMain</code> or <code>_CorDllMain</code> in <code>mscoree.dll</code>, much like it was in [[Visual Basic]] executables. The virtual machine then makes use of .NET metadata present, the root of which, <code>IMAGE_COR20_HEADER</code> (also called "CLR header") is pointed to by <code>IMAGE_DIRECTORY_ENTRY_COMHEADER</code> (the entry was previously used for [[COM+]] metadata in COM+ applications, hence the name{{cn|date=July 2024}}) entry in the PE header's data directory. <code>IMAGE_COR20_HEADER</code> strongly resembles PE's optional header, essentially playing its role for the CLR loader.<ref name="PE Format (Windows)"/>


The CLR-related data, including the root structure itself, is typically contained in the common code section, <code>.text</code>. It is composed of a few directories: metadata, embedded resources, strong names and a few for native-code interoperability. Metadata directory is a set of tables that list all the distinct .NET entities in the assembly, including types, methods, fields, constants, events, as well as references between them and to other assemblies.
The CLR-related data, including the root structure itself, is typically contained in the common code section, <code>.text</code>. It is composed of a few directories: metadata, embedded resources, strong names and a few for native-code interoperability. Metadata directory is a set of tables that list all the distinct .NET entities in the assembly, including types, methods, fields, constants, events, as well as references between them and to other assemblies.


==Use on other operating systems==
==Use on other operating systems==
The PE format is also used by [[ReactOS]], as ReactOS is intended to be [[binary-code compatibility|binary-compatible]] with Windows. It has also historically been used by a number of other operating systems, including [[SkyOS]] and [[BeOS]] R3. However, both SkyOS and BeOS eventually moved to [[Executable and Linkable Format|ELF]].{{citation needed|date=March 2021}}
The PE format is also used by [[ReactOS]], an open-source operating system created to be binary-compatible with Windows. Historically, it has also been used by other operating systems such as [[SkyOS]] and [[BeOS]] R3. However, both SkyOS and BeOS eventually moved to [[Executable and Linkable Format|ELF]].{{citation needed|date=March 2021}}


As the [[Mono (software)|Mono development platform]] intends to be binary compatible with the Microsoft [[.NET Framework]], it uses the same PE format as the Microsoft implementation. The same goes for Microsoft's own cross-platform [[.NET Core]].
The [[Mono (software)|Mono development platform]], which aims to be binary compatible with the Microsoft [[.NET Framework]], uses the same PE format as the Microsoft implementation. The same goes for Microsoft's own cross-platform [[.NET Core]].


On [[x86]](-64) [[Unix-like]] operating systems, Windows binaries (in PE format) can be executed with [[Wine (software)|Wine]]. The [[HX DOS Extender]] also uses the PE format for native DOS 32-bit binaries, plus it can, to some degree, execute existing Windows binaries in DOS, thus acting like an equivalent of Wine for DOS.
On [[x86]](-64) [[Unix-like]] operating systems, Windows binaries (in PE format) can be executed using [[Wine (software)|Wine]]. The [[HX DOS Extender]] also uses the PE format for native DOS 32-bit binaries, and can execute some Windows binaries in DOS, thus acting like an equivalent of Wine for DOS.


⚫
[[Mac OS X 10.5]] has the ability to load and parse PE files, although it does not maintain binary compatibility with Windows.<ref name="chartier">{{cite web|last=Chartier |first=David |title=Uncovered: Evidence that Mac OS X could run Windows apps soon |work=Ars Technica |url=https://arstechnica.com/journals/apple.ars/2007/11/30/uncovered-evidence-that-mac-os-x-could-run-windows-apps-soon |date=2007-11-30 |access-date=2007-12-03 |quote=...&nbsp;Steven Edwards describes the discovery that Leopard apparently contains an undocumented loader for Portable Executables, a type of file used in 32-bit and 64-bit versions of Windows. More poking around revealed that Leopard's own loader tries to find Windows DLL files when attempting to load a Windows binary. }}</ref>
On [[IA-32]] and [[x86-64]] [[Linux]] one can also run [[Microsoft Windows|Windows]]' [[Dynamic-link library|DLLs]] under load library.<ref>{{Cite web|url=https://github.com/taviso/loadlibrary|title = GitHub - taviso/Loadlibrary: Porting Windows Dynamic Link Libraries to Linux|website=[[GitHub]]}}</ref>


⚫
[[UEFI]] and EFI firmware use PE files as well as the Windows [[Application Binary Interface|ABI]] x64 [[calling convention]] for [[UEFI#Applications|applications]].
⚫
[[Mac OS X 10.5]] has the ability to load and parse PE files, but is not binary compatible with Windows.<ref name="chartier">{{cite web|last=Chartier |first=David |title=Uncovered: Evidence that Mac OS X could run Windows apps soon |work=Ars Technica |url=https://arstechnica.com/journals/apple.ars/2007/11/30/uncovered-evidence-that-mac-os-x-could-run-windows-apps-soon |date=2007-11-30 |access-date=2007-12-03 |quote=...&nbsp;Steven Edwards describes the discovery that Leopard apparently contains an undocumented loader for Portable Executables, a type of file used in 32-bit and 64-bit versions of Windows. More poking around revealed that Leopard's own loader tries to find Windows DLL files when attempting to load a Windows binary. }}</ref>

⚫
[[UEFI]] and EFI firmware use Portable Executable files as well as the Windows [[Application Binary Interface|ABI]] x64 [[calling convention]] for [[UEFI#Applications|applications]].


==See also==
==See also==
* [[EXE]]
* [[Executable and Linkable Format]]
* [[Mach-O]]
* [[a.out]]
* [[a.out]]
* [[Comparison of executable file formats]]
* [[Comparison of executable file formats]]
Line 68: Line 66:
{{reflist}}
{{reflist}}


==External links==
== External links ==

*[https://docs.microsoft.com/en-us/windows/desktop/Debug/pe-format PE Format] (latest online document)
* [https://docs.microsoft.com/en-us/windows/desktop/Debug/pe-format PE Format] (latest online document, changes in time)
*[https://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/pecoff.docx Microsoft Portable Executable and Common Object File Format Specification] (revision 11.0, [[.docx]] format, Jan 2017)
* Microsoft Portable Executable and Common Object File Format Specification. [https://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/pecoff.docx Revision 11.0, Jan 2017]; [https://bytepointer.com/download.php?name=pecoff_v10.docx Revision 10.0, Jun 2016]; [https://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/pecoff_v83.docx Revision 8.3, Feb 2013]; [https://web.archive.org/web/20100923032233/http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/pecoff_v8.docx Revision 8.2, Sep 2010]; [https://web.archive.org/web/20081211013825/http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/pecoff_v8.docx Revision 8.1, Feb 2008]; [https://web.archive.org/web/20060706172855/http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/pecoff_v8.doc Revision 8.0, May 2006]; [https://web.archive.org/web/20030724131335/http://www.microsoft.com/whdc/hwdev/download/hardware/pecoff.doc Revision 6.0, Feb 1999]; [https://bytepointer.com/resources/pecoff_v5.0.htm Revision 5.0, Oct 1997]; [https://bytepointer.com/resources/pecoff_v4.1.htm Revision 4.1, Aug 1994]; [https://bytepointer.com/resources/pecoff_v4.0.htm Revision 4.0, Sep 1993]
*[https://bytepointer.com/download.php?name=pecoff_v10.docx Microsoft Portable Executable and Common Object File Format Specification] (revision 10.0, [[.docx]] format, Jun 2016)
⚫
* [https://openwatcom.org/ftp/devel/docs/pe_and_symbols.pdf Tool Interface Standard (TIS) Formats Specifications for Windows Version 1.0] (Intel Order Number 241597, TIS Committee, Feb 1993)
*[https://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/pecoff_v83.docx Microsoft Portable Executable and Common Object File Format Specification] (revision 8.3, [[.docx]] format, Feb 2013)
⚫
* [https://bytepointer.com/resources/oleary_pe_format.htm Portable Executable Format] (Micheal J. O'Leary, Microsoft Developer Support)
*[https://web.archive.org/web/20100923032233/http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/pecoff_v8.docx Microsoft Portable Executable and Common Object File Format Specification] (revision 8.2, [[.docx]] format, Sep 2010)
*[https://web.archive.org/web/20081211013825/http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/pecoff_v8.docx Microsoft Portable Executable and Common Object File Format Specification] (revision 8.1, [[.docx]] format, Feb 2008)
* [https://web.archive.org/web/20080907145154/http://msdn.microsoft.com/en-us/magazine/ms809762.aspx Peering Inside the PE: A Tour of the Win32 Portable Executable File Format]. [[Matt Pietrek]], Microsoft Systems Journal, March 1994
* An In-Depth Look into the Win32 Portable Executable File Format. [[Matt Pietrek]], [[MSDN]] Magazine. [https://web.archive.org/web/20021105233944/http://msdn.microsoft.com/msdnmag/issues/02/02/PE/default.aspx Part I, February 2002]; [https://web.archive.org/web/20021105025618/http://msdn.microsoft.com/msdnmag/issues/02/03/PE2/default.aspx Part II, March 2002]
*[https://web.archive.org/web/20060706172855/http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/pecoff_v8.doc Microsoft Portable Executable and Common Object File Format Specification] (revision 8.0, [[.doc]] format, May 2006)
*[https://web.archive.org/web/20030724131335/http://www.microsoft.com/whdc/hwdev/download/hardware/pecoff.doc Microsoft Portable Executable and Common Object File Format Specification] (revision 6.0, [[.doc]] format, Feb 1999)
* [https://archive.today/20130130042959/http://www.ntcore.com/files/dotnetformat.htm The .NET File Format by Daniel Pistelli]
⚫
* [http://blog.dkbza.org/ Ero Carrera's blog describing the PE header and how to walk through]
*[https://bytepointer.com/resources/pecoff_v5.0.htm Microsoft Portable Executable and Common Object File Format Specification] (revision 5.0, [[.html]] format, Oct 1997)
⚫
* [http://www.andreybazhan.com/pe-internals/ PE Internals provides an easy way to learn the Portable Executable File Format]
*[https://bytepointer.com/resources/pecoff_v4.1.htm Microsoft Portable Executable and Common Object File Format Specification] (revision 4.1, [[.html]] format, Aug 1994)
*[https://bytepointer.com/resources/pecoff_v4.0.htm Microsoft Portable Executable and Common Object File Format Specification] (revision 4.0, [[.html]] format, Sep 1993)
⚫
*[https://openwatcom.org/ftp/devel/docs/pe_and_symbols.pdf Tool Interface Standard (TIS) Formats Specifications for Windows Version 1.0] (Intel Order Number 241597, TIS Committee, Feb 1993)
⚫
*[https://bytepointer.com/resources/oleary_pe_format.htm Portable Executable Format] (Micheal J. O'Leary, Microsoft Developer Support)
*[https://learn.microsoft.com/en-us/previous-versions/ms809762(v=msdn.10) Peering Inside the PE: A Tour of the Win32 Portable Executable File Format] (archived from [https://web.archive.org/web/20080907145154/http://msdn.microsoft.com/en-us/magazine/ms809762.aspx the original]) by [[Matt Pietrek]] (Microsoft Systems Journal, March 1994)
*[https://learn.microsoft.com/en-us/archive/msdn-magazine/2002/february/inside-windows-win32-portable-executable-file-format-in-detail Part I. An In-Depth Look into the Win32 Portable Executable File Format] (archived from [https://web.archive.org/web/20021105233944/http://msdn.microsoft.com/msdnmag/issues/02/02/PE/default.aspx the original]) by [[Matt Pietrek]] ([[MSDN]] Magazine, February 2002)
*[https://learn.microsoft.com/en-us/archive/msdn-magazine/2002/march/inside-windows-an-in-depth-look-into-the-win32-portable-executable-file-format-part-2 Part II. An In-Depth Look into the Win32 Portable Executable File Format] (archived from [https://web.archive.org/web/20021105025618/http://msdn.microsoft.com/msdnmag/issues/02/03/PE2/default.aspx the original] by [[Matt Pietrek]] ([[MSDN]] Magazine, March 2002)
*[https://archive.today/20130130042959/http://www.ntcore.com/files/dotnetformat.htm The .NET File Format by Daniel Pistelli]
⚫
*[http://blog.dkbza.org/ Ero Carrera's blog describing the PE header and how to walk through]
⚫
*[http://www.andreybazhan.com/pe-internals/ PE Internals provides an easy way to learn the Portable Executable File Format]
* [http://www.pe-explorer.com/ PE Explorer]
* [http://www.pe-explorer.com/ PE Explorer]

{{Executables}}
{{Executables}}


Latest revision as of 20:33, 30 December 2024

Not to be confused with Portable application or Windows Preinstallation Environment.
Portable Executable
Filename extension
.acm, .ax, .cpl, .dll, .drv, .efi, .exe, .mui, .ocx, .scr, .sys, .tsp, .mun, .msstyles
Internet media type
application/vnd.microsoft.portable-executable[1]
Developed byCurrently: Microsoft
Type of formatBinary, executable, object, shared libraries
Extended fromDOS MZ executable
COFF

The Portable Executable (PE) format is a file format for executables, object code, dynamic-link-libraries (DLLs), and binary files used on 32-bit and 64-bit Windows operating systems, as well as in UEFI environments.[2] It is the standard format for executables on Windows NT-based systems, including files such as .exe, .dll, .sys (for system drivers), and .mui. At its core, the PE format is a structured data container that gives the Windows operating system loader eveything it needs to properly manage the executable code it contains. This includes references for dynamically linked libraries, tables for importing and exporting APIs, resource management data and thread-local storage (TLS) information.

According to the Unified Extensible Firmware Interface (UEFI) specification, the PE format is also the accepted standard for executables in EFI environments.[3] On Windows NT systems, it currently supports a range of instruction sets, including IA-32, x86-64 (AMD64/Intel 64), IA-64, ARM and ARM64. Before the advent of Windows 2000, Windows NT (and by extension the PE format) also supported MIPS, Alpha, and PowerPC architectures. Moreover, thanks to its use in Windows CE, PE has maintained compatibility with several MIPS, ARM (including Thumb), and SuperH variants.[4]

Functionally, the PE format is similar to other platform-specific executable formats, such as the ELF format used in Linux and most Unix-like systems, and the Mach-O format found in macOS and iOS.

History

[edit]

Microsoft first introduced the PE format with Windows NT 3.1, replacing the older 16-bit New Executable (NE) format. Soon after, Windows 95, 98, ME, and the Win32s extension for Windows 3.1x, all adopted the PE structure. Each PE file includes a DOS executable header, which generally displays the message "This program cannot be run in DOS mode". However, this DOS section can be replaced by a fully functional DOS program, as demonstrated in the Windows 98 SE installer. Developers can add such a program using the /STUB switch with Microsoft's linker, effectively creating a fat binary.[5]

Over time, the PE format has grown with the Windows platform. Notable extensions include the .NET PE format for managed code, PE32+ for 64-bit address space support, and a specialized version for Windows CE.

To determine whether a PE file is intended for 32-bit or 64-bit architectures, one can examine the Machine field in the IMAGE_FILE_HEADER.[6] Common machine values are 0x014c for 32-bit Intel processors and 0x8664 for x64 processors. Additionally, the Magic field in the IMAGE_OPTIONAL_HEADER reveals whether addresses are 32-bit or 64-bit. A value of 0x10B indicates a 32-bit (PE32) file, while 0x20B indicates a 64-bit (PE32) file.[7]

Technical details

[edit]

Layout

[edit]
Structure of a Portable Executable 32 bit

A PE file consists of a several headers and sections that instruct the dynamic linker about on how to map the file into memory. An executable image consists of several different regions, each requiring different memory protection attributres. To ensure proper alignment, the start of each section must align to a page boundary.[8] For instance, the .text section, which contains program code, is typically mapped as an execute/read-only. Conversely, the .data section, which holds global variables, is mapped as no-execute/read write. However, to conserve space, sections are not aligned on disk in this manner. The dynamic linker maps each section to memory individually and assigns the correct permissions based on the information in the headers.[9]

Import table

[edit]

The import address table (IAT) is used as a lookup table when the application calls a function in a different module. The imports can be specified by ordinal or by name. Because a compiled program cannot know the memory locations of its dependent libraries beforehand, an indirect jump is necessary for API calls. As the dynamic linker holds modules and resolves dependancies, it populates the IAT slots with actual addresses of the corresponding library functions. Although this adds an extra jump, incurring a performance penalty compared to intermodular calls, it minimizes the number of memory pages that that require copy-on-write changes, thus conserving memory and disk I/O. If a call is known to be intermodular beforehand (if indicated by a dllimport attribute), the compiler can generate optimized code with a simple indirect call opcode.[9]

Address Space Layout Randomization (ASLR)

[edit]

PE files aren't position-independent by default; they are compiled to run at a specific, fixed memory address. Modern operating systems use Address Space Layout Randomization (ASLR) to make it harder for attackers to exploit memory-related vulnerabilities. ASLR works by randomly changing the memory address of important parts of the program every time it's loaded. This includes the base address of the program itself, shared libraries (DLLs), and memory areas like the heap and stack. as a defense mechanism against memory-based exploits. ASLR rearranges the address space positions of key data areas of a process, including the base of the executable and the positions of the stack, heap and libraries. By randomizing these memory addresses each time the process an application is loaded, ASLR prevents attackers from being able to reliably predict memory locations.

.NET, metadata, and the PE format

[edit]

In a .NET executable, the PE code section contains a stub that invokes the CLR virtual machine startup entry, _CorExeMain or _CorDllMain in mscoree.dll, much like it was in Visual Basic executables. The virtual machine then makes use of .NET metadata present, the root of which, IMAGE_COR20_HEADER (also called "CLR header") is pointed to by IMAGE_DIRECTORY_ENTRY_COMHEADER (the entry was previously used for COM+ metadata in COM+ applications, hence the name[citation needed]) entry in the PE header's data directory. IMAGE_COR20_HEADER strongly resembles PE's optional header, essentially playing its role for the CLR loader.[4]

The CLR-related data, including the root structure itself, is typically contained in the common code section, .text. It is composed of a few directories: metadata, embedded resources, strong names and a few for native-code interoperability. Metadata directory is a set of tables that list all the distinct .NET entities in the assembly, including types, methods, fields, constants, events, as well as references between them and to other assemblies.

Use on other operating systems

[edit]

The PE format is also used by ReactOS, an open-source operating system created to be binary-compatible with Windows. Historically, it has also been used by other operating systems such as SkyOS and BeOS R3. However, both SkyOS and BeOS eventually moved to ELF.[citation needed]

The Mono development platform, which aims to be binary compatible with the Microsoft .NET Framework, uses the same PE format as the Microsoft implementation. The same goes for Microsoft's own cross-platform .NET Core.

On x86(-64) Unix-like operating systems, Windows binaries (in PE format) can be executed using Wine. The HX DOS Extender also uses the PE format for native DOS 32-bit binaries, and can execute some Windows binaries in DOS, thus acting like an equivalent of Wine for DOS.

Mac OS X 10.5 has the ability to load and parse PE files, although it does not maintain binary compatibility with Windows.[10]

UEFI and EFI firmware use PE files as well as the Windows ABI x64 calling convention for applications.

See also

[edit]

References

[edit]
  1. ^ Andersson, Henrik (2015-04-23). "application/vnd.microsoft.portable-executable". IANA. Retrieved 2017-03-26.
  2. ^ "Portable executable (PE) - Definition - Trend Micro IN". www.trendmicro.com. Retrieved 2022-11-10.
  3. ^ "UEFI Specification, version 2.8B" (PDF)., a note on p.15, states that "this image type is chosen to enable UEFI images to contain Thumb and Thumb2 instructions while defining the EFI interfaces themselves to be in ARM mode."
  4. ^ a b "PE Format (Windows)". Retrieved 2017-10-21.
  5. ^ "/STUB (MS-DOS Stub File Name)". 3 August 2021.
  6. ^ PE trick explained: Telling 32 and 64 bit apart with naked eye by Karsten Hahn
  7. ^ PE Format at Microsoft.com
  8. ^ "The Portable Executable File From Top to Bottom". Retrieved 2017-10-21.
  9. ^ a b "Peering Inside the PE: A Tour of the Win32 Portable Executable File". 30 June 2010. Retrieved 2017-10-21.
  10. ^ Chartier, David (2007-11-30). "Uncovered: Evidence that Mac OS X could run Windows apps soon". Ars Technica. Retrieved 2007-12-03. ... Steven Edwards describes the discovery that Leopard apparently contains an undocumented loader for Portable Executables, a type of file used in 32-bit and 64-bit versions of Windows. More poking around revealed that Leopard's own loader tries to find Windows DLL files when attempting to load a Windows binary.
[edit]
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Portable_Executable&oldid=1266252214"