The 64-Bit Windows Executable Format

November 17, 2015

This page attempts to summarize what is required to create a working 64-bit PE file.

The Windows executable format has two variants: PE32 is the format for 32-bit programs, and PE32+ is the format for 64-bit programs. The formats are similar, but not identical. This page describes only the 64-bit variant, PE32+.

Many of these fields can be set to other values, but reasonable defaults are provided. For example, the file alignment can be set to any power of two between 512 and 64K, but there is little reason to use a larger alignment. Fields omitted from this description must be zero.

The DOS stub program

In nearly all PE executables, there is a DOS stub program after the DOS header and before the PE header. The table below shows where the DOS stub program goes, but the data for a DOS stub program is not listed. (A PE file will still run if the DOS stub is all zero.)

Terminology

• File Position: An offset, in bytes, from the beginning of the file.
• Virtual Address: This is just an ordinary user-space memory address.
• Image Base Address: Specified by a field in the PE header. The executable will be loaded into memory at this address.
• Relative Virtual Address (RVA): The Virtual Address minus the Image Base Address.
• Section Alignment: Specified by a field in the PE header; usually 4 kB. In memory, sections must begin on a multiple of this alignment.
• File Alignment: Specified by a field in the PE header; usually 512 bytes. In the PE file, sections must begin on a multiple of this alignment.
• u8, u16, u32, u64: 8, 16, 32, and 64-bit unsigned integers.

High-Level File Layout

Detailed File Layout

The rest of the file does not have a fixed layout. There are up to 96 section headers immediately following the Data Directory entries. After that comes the data for each of those sections, with each section's data aligned to the File Alignment.

The following data is an example of a small but valid three-section PE file.

The import information in the .rdata section is complex, so it is described separately here:

Structures

struct DataDirectoryEntry
{
	u32 DirectoryRVA;
	u32 DirectorySize;
}

// Repeated according to number-of-sections specified in the header.
struct SectionHeader
{
	u8[8] Name;		// Null-padded string.
	u32 VirtualSize;
	u32 VirtualAddress;
	u32 SizeInFile;
	u32 AddressInFile;
	u8[12] Unused;		// Must be zero.
	u32 Characteristics;
}

// Import Directory
// One entry per DLL imported from. (e.g. kernel32.dll)
// Array is terminated by an all-zero entry.
struct ImportDirectoryEntry
{
	u32 ImportLookupTable;	// RVA of an array in .rdata.
	u32 Timestamp;		// Can be zero.
	u32 ForwarderChain;	// Should be zero.
	u32 Name;		// RVA of name of DLL, a null-terminated string in .rdata.
	u32 ImportAddressTable;	// RVA of an array in .rdata.
}

// Import Lookup Table: Array of these entries.
// Array is terminated by an all-zero entry.
// One entry per function imported from a DLL.
// One array for each entry in the Import Address Table Directory.
// The Import Address Table is a copy of this array, stored elsewhere in .rdata section.
struct ImportLookupTableEntry
{
	u64 Entry;
	// The low 31 bits are the RVA of a Hint/Name table entry, in .rdata.
	// Bits 63 to 32 are zero.
	// (This describes only the name-based lookup format. Ordinal-based lookup is also possible.)
}

// The Import Lookup Table points at these.
// These structs are typically allocated in .rdata.
// Must begin on an even address.
struct HintNamePair
{
	u16 OrdinalHint;	// can be zero)
	u8[*] SymbolName;	// null-terminated string
}

Additional notes

The in-file and in-memory sizes of sections must be multiples of their respective "section alignment" values in the header. The in-memory size will usually be larger; whenever the section is larger in memory than on disk, the extra bytes will be zero. This is a convenient way to define the .bss section!

References

• The official Microsoft PE/COFF specification
• A Python library for parsing PE files: pefile
• OSDev