.EXE File Format

Introduction

PE32 is the format of programs and libraries on 32-bit Microsoft Windows: Windows NT 3.1 from 1993, Windows 95, and every Windows since. 64-bit Windows still runs PE32 programs, so the format is as common as ever. It is also the format of Windows CE programs, of 32-bit ARM Windows programs, of .NET assemblies built for any processor, and of some UEFI firmware images. The same layout is used for programs (.exe), libraries (.dll), drivers (.sys), control panel items (.cpl), ActiveX controls (.ocx) and screen savers (.scr).

PE stands for Portable Executable. The format is built on COFF, the object file format of Microsoft’s compilers: a PE file is an MS-DOS program, then the signature PE\0\0, a COFF file header, an optional header that every image has, and a table of sections that hold the code, the data and the tables Windows needs to load it. Microsoft publishes the specification.

The 64-bit format, PE32+, has the same structures, but its optional header is laid out differently and its addresses are 64 bits, so it is a separate format here. Everything added to PE32 since 1993 has only added: new data directories, new flags, new machine values, and a load configuration that grows at its end. So every PE32 file is one format. All the variations of .exe are on the EXE page.

A program dropped on any page opens in the explorer. It shows the file’s structure, every header and table in the order of its bytes; its resources, listed by type, name and language; and its code, disassembled as x86 with an instruction decoded at every byte, laid out in columns, so that a jump into the middle of another instruction can be followed. The instructions are described in the x86 instruction reference.

Structure

All numbers are little-endian. Most addresses inside the file are relative virtual addresses (RVAs): offsets from the address the image is loaded at. The section table maps an RVA back to a file offset; see Section table and section data.

The code

A section whose flags include CNT_CODE or MEM_EXECUTE holds machine code. For machine 0x014C (Intel 386 and later) the explorer disassembles each such section in 32-bit mode, from its raw data up to its VirtualSize. The addresses it shows are those the code runs at: the image base plus the RVA.

An instruction is decoded at every byte, not only where the one before ends, and the instructions are laid out in columns: the first column is the plain disassembly from the start of the section, and the others hold the instructions that start inside it. So when a jump lands in the middle of an instruction, the code it reaches is there to read. Every instruction is described in the x86 instruction reference.

The explorer names what it can: the entry point, every export, each import address table slot as KERNEL32.dll!GlobalAlloc, so that a call through the slot shows which function it calls, the TLS callbacks, and the functions in a COFF symbol table, which MinGW and Wine builds keep.

• Code for other machines, such as 32-bit ARM, Alpha and MIPS, is not disassembled; the explorer names the machine.
• A .NET assembly’s .text section holds IL bytecode and metadata, not x86 code. Only its entry stub is x86: an indirect jump through the import address table to _CorExeMain or _CorDllMain in mscoree.dll. The rest disassembles as nonsense.

In the explorer

The tree shows every byte of the file once, in file order:

• the headers as one part: the DOS header, the stub, the Rich header, the PE headers and the section table;
• each section’s raw data, with the tables that lie inside it, and the bytes no table covers as “Code” in an executable section and “Data” in the others;
• what lies after the image: the certificate table, the COFF symbols and the overlay.

Tables are found through the data directories and the RVAs inside them, then placed where their bytes are, not where they are referred to. Many small items of one kind, such as hint/name entries, export names, resource data and unwind records, are grouped.

The Program tab sums the file up: its kind, machine, subsystem, entry point, image base, link time, linker version, the Windows version it needs, its flags, whether its checksum is right, the Rich header, the PDB path, the .NET runtime, the TLS callbacks, the signature, the COFF symbols and the overlay. It then lists the code, the sections, the data directories, the imports and exports, the resources, the debug directory, the tools from the Rich header, and a .NET summary.

Reference pages

• MS-DOS header, stub and Rich header – the 64-byte DOS header, the stub program and Microsoft’s undocumented list of tools
• PE signature and COFF file header – machine types, the time stamp and the characteristics flags
• Optional header – the 32-bit layout, subsystems, DLL characteristics and the checksum
• Data directories – the 16 entries that locate every table
• Section table and section data – section headers, flags, names, and mapping RVAs to file offsets
• Imports – import descriptors, lookup tables, hint/name entries and the import address table
• Delay-load imports – DLLs loaded on the first call
• Bound imports – the table that lets prebound addresses be used as they are
• Exports – the export directory, the address, name and ordinal tables, and forwarders
• Resources – the resource tree and the resource types
• Base relocations – the fixups applied when the image cannot load at its preferred address
• Debug directory – CodeView PDB paths, POGO, FPO and the other debug entries
• Thread-local storage – the TLS directory, the template and the callbacks
• Load configuration – the security cookie, SafeSEH, Control Flow Guard and the rest
• Exception table and unwind information – the function tables of ARM, MIPS and the other machines that have one
• CLR header and .NET metadata – the runtime header, the metadata root, streams and heaps
• Attribute certificates (Authenticode) – the signature appended to the file
• COFF symbol and string tables – symbols that GNU linkers leave in images
• Overlay – data after the image, and the installers and archives found there

Telling it apart

Every .exe format starts with an MS-DOS header. The explorer’s parser for PE32 checks, in order, and turns the file down at the first check that fails:

1. The file is at least 64 bytes long and starts with MZ. Windows does not accept the ZM that some old DOS programs have.
2. e_lfanew, the 32-bit value at 0x3C, is at least 0x40 and leaves room for 24 bytes before the end of the file.
3. The four bytes at e_lfanew are 50 45 00 00, PE\0\0.
4. The optional header’s magic, the two bytes at e_lfanew + 24, is 0x10B. A PE32+ file has 0x20B.
5. SizeOfOptionalHeader is at least 96, the size of the fixed fields.
6. The section table, 40 bytes for each section after the optional header, fits in the file.

Anything wrong after that, such as a table outside every section, two tables that overlap or a wrong checksum, is reported as a problem rather than a reason to turn the file down. Windows itself accepts an e_lfanew below 0x40, where the PE header overlaps the DOS header, as some hand-made tiny programs do; the explorer does not lay such files out.

Within PE32, the DLL flag (0x2000) in the COFF header marks a library, the subsystem says whether a program is a console program, a GUI program, a driver or an EFI image, and a CLR header (directory 14) marks a .NET assembly.

History

PE has no version field. These are the additions that matter; each one only added to the format.

The dates marked “around” come from the Windows releases in general, not from the PE specification.

Variants

• MS-DOS executable (MZ) – 16-bit DOS programs: an MZ header, relocations and the code
• 16-bit Windows executable (NE) – Windows 3.x and early OS/2 programs and DLLs, in movable segments
• Linear Executable (LE) – 32-bit Windows VxD drivers and DOS extender programs, in paged objects
• OS/2 executable (LX) – 32-bit OS/2 programs and DLLs, in paged objects
• Windows executable (PE32) – 32-bit Windows programs and DLLs, with a 32-bit optional header (magic 0x10B)
• Windows 64-bit executable (PE32+) – 64-bit Windows programs and DLLs (x64, ARM64), with a 64-bit optional header (magic 0x20B)

Links