| Portable Executable | |
|---|---|
| Filename extension | |
| Internet media type | application/vnd.microsoft.portable-executable[1] |
| Magic number | 4D 5A (MZ inASCII)and 50 45 00 00 (PE) |
| Developed by | Currently:Microsoft |
| Type of format | Binary,executable,object,shared libraries |
| Extended from | DOS MZ executable COFF |
Portable Executable (PE) is afile format for nativeexecutable code on 32-bit and 64-bitWindowsoperating systems, as well as inUEFI environments.[2] It is used for native executables (.exe,.com), dynamic link libraries (.dll,.ocx), system drivers (.sys,.drv) and many other types of files. The PE format supports storing the data required to load and start an operating systemprocess – including references todynamic link libraries, tables for importing and exportingapplication programming interface (API) functions, resource management data andthread-local storage (TLS) information.
According to theUnified 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 ofinstruction sets, includingIA-32,x86-64 (AMD64/Intel 64),IA-64,ARM andARM64. Before the advent ofWindows 2000, Windows NT (and by extension the PE format) also supportedMIPS,Alpha, andPowerPC architectures. Moreover, thanks to its use inWindows CE, PE has maintained compatibility with several MIPS,ARM (includingThumb), andSuperH variants.[4]
Functionally, the PE format is similar to other platform-specific executable formats, such as theELF format used inLinux and mostUnix-like systems, and theMach-O format found inmacOS andiOS.
Microsoft first introduced the PE format withWindows NT 3.1, replacing the older 16-bitNew Executable (NE) format. Soon after, Windows 95, 98, ME, and the Win32s extension forWindows 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 afat binary.[5]
Over time, the PE format has grown with the Windows platform. Notable extensions include the.NET PE format formanaged code, PE32+ for 64-bit address space support, and a specialized version forWindows 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 are0x014c for 32-bit Intel processors and0x8664 for x64 processors. Additionally, the Magic field in theIMAGE_OPTIONAL_HEADER reveals whether addresses are 32-bit or 64-bit. A value of0x10B indicates a 32-bit (PE32) file, while0x20B indicates a 64-bit (PE32+) file.[7]
A PE file consists of several headers and sections that instruct thedynamic linker about on how to map the file into memory. An executable image consists of several different regions, each requiring differentmemory protection attributes. 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]
Theimport address table (IAT) is used as a lookup table when the application calls a function in a different module. Theimports 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 dependencies, 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 requirecopy-on-write changes, thus conserving memory and disk I/O. If a call is known to be intermodular beforehand (if indicated by adllimport attribute), the compiler can generate optimized code with a simple indirect callopcode.[9]
Modern operating systems useAddress space layout randomization (ASLR), a process that makes a PE file's in-memory layout unpredictable and therefore harder to exploit. During ASLR, theloader randomizes the virtual addresses where key components reside. This includes the executable's base,shared libraries, theheap, and thestack. Most PE files are notposition-independent because mainstreamcompilers emit some absolute references relative to an assumed base. To cope with randomized rebasing, thelinker stores a.reloc table that lets the loader adjust those references at load time.
In a .NET executable, the PE code section contains a stub that invokes theCLR virtual machine startup entry,_CorExeMain or_CorDllMain inmscoree.dll, much like it was inVisual 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 byIMAGE_DIRECTORY_ENTRY_COMHEADER (the entry was previously used forCOM+ 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.
The PE format is also used byReactOS, an open-source operating system created to be binary-compatible with Windows. Historically, it has also been used by other operating systems such asSkyOS andBeOS R3. However, both SkyOS and BeOS eventually moved toELF.[citation needed]
TheMono 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.
Onx86(-64)Unix-like operating systems, Windows binaries (in PE format) can be executed usingWine. TheHX 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 WindowsABI x64calling convention forapplications.
... 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.