Windows Executable

The MZ header was never meant to last. It solved a specific 1981 problem: distinguishing relocatable executables from flat COM binaries on MS-DOS. But when Microsoft needed new executable formats — first the 16-bit New Executable (NE) for Windows 1.0 in 1985, then the 32/64-bit Portable Executable (PE) for Windows NT 3.1 in 1993 — they kept the MZ header as a backward-compatibility stub rather than starting fresh. The result is a format where the first 64 bytes of every modern 64-bit Windows application are a relic of the 8086 era.

The DOS Stub: A Message from 1993

Between the MZ header and the PE signature sits the DOS stub — a small real-mode MS-DOS program. In almost every EXE built by modern compilers, this stub does one thing: print "This program cannot be run in DOS mode" and exit. The message is a fossil. No one has run a PE executable under real-mode DOS in decades, yet the message persists because the Microsoft linker generates it by default and removing it serves no purpose.

The stub is not purely ceremonial. Microsoft's linker supports a /STUB switch that replaces the default stub with a functional DOS program, creating a fat binary that runs different code depending on the operating system. Windows 98's setup program used this technique — the same EXE file contained both a 16-bit DOS installer and a 32-bit PE installer.

PE Binary Structure

The PE format is a layered binary container. From the first byte to the last section, the layout follows a strict hierarchy:

DOS Header (64 bytes): The e_magic field at offset 0x00 holds 4D 5A. The e_lfanew field at offset 0x3C is a 4-byte pointer to the PE signature. Everything between these two fields (e_cblp, e_cp, e_crlc, and other DOS-era relocation fields) is ignored by the Windows PE loader but must be present for structural validity.

DOS Stub (variable length): Starts at offset 0x40. Typically 64-128 bytes of real-mode x86 code. The loader skips it entirely — only real-mode DOS would execute this code.

Rich Header (variable, undocumented): Between the DOS stub and the PE signature, Microsoft's linker inserts an XOR-encrypted block of build metadata. This structure, never described in the official PE specification, begins with the marker DanS (after XOR decryption) and contains comp.id entries that fingerprint every object file and library linked into the binary — recording the exact compiler version, build tool version, and source count for each. Security researchers discovered the Rich header's forensic value when analyzing state-sponsored malware: the Lazarus Group's toolchain signatures were identified through Rich header artifacts, and the Olympic Destroyer malware contained a deliberately forged Rich header designed to frame a different threat actor. For malware analysts, the Rich header is an involuntary build environment confession.

PE Signature (4 bytes): The literal bytes 50 45 00 00 ("PE\0\0") at the offset specified by e_lfanew. If these bytes are missing or corrupted, the Windows loader rejects the file.

COFF Header (20 bytes): Immediately follows the PE signature. The Machine field (2 bytes at offset +0) identifies the target CPU: 0x14C for Intel i386, 0x8664 for AMD64, 0xAA64 for ARM64. NumberOfSections (2 bytes at +2) declares how many section headers follow. TimeDateStamp (4 bytes at +4) records when the linker produced the binary — this is the primary dating mechanism for PE files and is accurate for most production builds. SizeOfOptionalHeader (2 bytes at +16) and Characteristics (2 bytes at +18) complete the structure.

Optional Header (PE32: 224 bytes, PE32+: 240 bytes): Despite the name, this header is mandatory for executables. Its first field, Magic (2 bytes), distinguishes format versions: 0x10B for PE32 (32-bit), 0x20B for PE32+ (64-bit). AddressOfEntryPoint (4 bytes at +16) is the RVA where execution begins. ImageBase specifies the preferred load address — 4 bytes in PE32, 8 bytes in PE32+, enabling PE32+ to address memory above 4 GB. The Subsystem field (2 bytes at +68) determines whether Windows creates a console window (value 3, IMAGE_SUBSYSTEM_WINDOWS_CUI) or a GUI process (value 2, IMAGE_SUBSYSTEM_WINDOWS_GUI). DllCharacteristics (2 bytes at +70) encode critical security flags: bit 0x0040 enables ASLR, bit 0x0100 enables DEP/NX compatibility, and bit 0x4000 enables Control Flow Guard.

Data Directories: Starting at offset 96 (PE32) or 112 (PE32+), an array of 8-byte entries (RVA + Size pairs) points the loader to import tables, export tables, resource trees, exception handlers, the certificate table (Authenticode signatures), base relocations, debug information, TLS data, and the CLR runtime header for .NET assemblies.

Section Table: Each entry is 40 bytes. The Name field (8 bytes, null-padded ASCII) identifies the section: .text holds executable code, .rdata holds read-only data and import descriptors, .data holds initialized global variables, .rsrc holds resources (icons, manifests, version information, embedded files), and .reloc holds base relocation entries that enable ASLR to rebase the image at a random address.

PE32 vs PE32+: The 64-bit Transition

PE32+ is not a new format — it is PE32 with wider address fields. The structural difference is precise: ImageBase grows from 4 bytes to 8. SizeOfStackReserve, SizeOfStackCommit, SizeOfHeapReserve, and SizeOfHeapCommit each grow from 4 bytes to 8. The BaseOfData field present in PE32 is removed entirely in PE32+. This makes the PE32+ optional header 16 bytes larger (240 vs 224 bytes) despite having one fewer field.

The Machine field in the COFF header determines the instruction set: 0x14C for 32-bit x86, 0x8664 for 64-bit x86-64. Windows on ARM64 added 0xAA64 for native ARM64 binaries and 0xA641 for ARM64EC — an interoperability mode where ARM64 code can call x64 functions and vice versa, designed to ease the transition from x64 to ARM64 on Windows.

A 64-bit Windows installation runs 32-bit PE32 executables through WoW64 (Windows 32-bit on Windows 64-bit), a compatibility layer that translates system calls and manages separate 32-bit and 64-bit registry views. A 32-bit Windows installation cannot run PE32+ executables at all.

The COM to PE Evolution

Executable formats on x86 PCs evolved through four generations. COM files (1970s-1981) were flat memory images with no header — the OS loaded the entire file at a fixed segment offset and jumped to byte zero. Maximum size: 65,280 bytes (one 64K segment minus 256 bytes for the Program Segment Prefix). MZ EXE (1981) added a header with relocation entries, allowing programs to exceed 64K and load at variable memory addresses. New Executable (NE) (1985) introduced segment tables, resource forks, and imported/exported functions for the 16-bit Windows and OS/2 environments. NE files still begin with an MZ header and DOS stub. Portable Executable (PE) (1993) replaced NE's segment model with a flat 32-bit address space, COFF-derived headers, and the section table architecture still used today. Each generation maintained backward compatibility by retaining the MZ header at byte zero.

Code Signing and the Trust Chain

Windows Authenticode signs PE files by computing a hash of the binary — excluding the checksum field and the certificate table data directory entry — and embedding an X.509 certificate chain in the PE attribute certificate table (data directory entry 4). The signature includes a timestamp from a Timestamping Authority (TSA) so the signature remains valid after the signing certificate expires.

SmartScreen builds on Authenticode by adding reputation. A validly signed EXE from an unknown publisher still triggers a warning until enough users have downloaded and run it without incident. An unsigned EXE triggers a stronger warning. Extended Validation (EV) code signing certificates bypass the reputation requirement — EV-signed binaries are trusted immediately. This economic mechanism means legitimate small developers face SmartScreen friction while large publishers with EV certificates do not.

Why EXE Files Are Dangerous by Design

The EXE format is not dangerous because of vulnerabilities — it is dangerous because executing arbitrary code is exactly what it was designed to do. An EXE file is a direct instruction to the processor. When Windows loads an EXE, the loader maps the sections into memory, resolves import table entries to DLL functions, and transfers control to the entry point. From that moment, the code has the full privilege level of the user who launched it.

This is why EXE is the primary malware delivery vector. Email services block .exe attachments. Browsers display download warnings. Windows enforces User Account Control prompts for elevation. Enterprise environments deploy AppLocker or Windows Defender Application Control to whitelist approved executables. Every layer of defense exists because the format itself offers no safety — a valid EXE is indistinguishable from malware at the binary level until the code actually runs.

Antivirus engines spend the majority of their analysis budget on PE files. Static analysis parses headers, section entropy, import tables, and Rich header artifacts. Dynamic analysis executes the binary in a sandbox and monitors system calls, registry modifications, file writes, and network connections. Heuristic engines flag unusual section names, abnormal entry point locations, packed or encrypted code sections, and missing or forged Authenticode signatures. The PE format's complexity — hundreds of header fields, arbitrary section layouts, embedded resources, TLS callbacks that execute before the entry point — creates an enormous surface area for evasion techniques.