PE file format

Welcome! I'm excited to help you master the Windows Portable Executable (PE) file format. Before we dive into the technical details and map out our learning path, I'd love to know a bit more about your background so we can make this session as valuable as possible.

Are you interested in learning about the PE format for general software development, reverse engineering, or malware analysis?

Reverse engineering

Awesome. Since you are diving into reverse engineering, mastering the is one of the most powerful skills you can build. It is the blueprint that tells Windows exactly how to construct a running process from a file on your hard drive.

Your path

Deep Dive: Headers

Deep Dive: Sections

PE Files in Memory vs. On Disk

What is a PE File?

At its heart, a PE file is structured as a linear stream of data divided into two major portions: the headers and the sections. The headers act as a map, telling the Windows where everything else inside the file belongs and how to prepare it for execution.

A vertical stack representing the layout of a PE file on disk.

Would you like to start by looking at how the very first piece of the file—the DOS Header—is structured, or should we make a diagram of the high-level layout first?

loading order step by step

You got it! Let's trace the journey a program takes from a quiet file sitting on your hard drive to an active process running in memory.

The 5 Steps of the Windows Loader

When you double-click an executable, the Windows swings into action. It doesn't just blindly run the code; it carefully processes the binary structure in five distinct steps to build a secure runtime sandbox for the process.

The five structural phases of a program executable loading process, from header processing to execution.

Here is exactly how those five steps unfold:

Header Processing: The loader reads the DOS header and PE headers to verify the file is valid and to find out how much virtual memory it needs to allocate.
Section Mapping: It carves out virtual address space and copies the PE file's sections (like code and raw data) from the disk into their designated locations in that newly allocated memory.
IAT Resolution: It looks at the Import Address Table (IAT) to find out which external the program relies on (like kernel32.dll), loads them, and plugs the real memory addresses of those library functions into the program's jump tables.
Relocation: If the program couldn't be loaded at its preferred base memory address, the loader adjusts all hardcoded memory pointers in the code using a special table called the relocation table.
Execution: With everything mapped and patched, the loader sets the CPU's instruction pointer to the program's entry point and hands over control.

how does it know what to load next the order

To figure out the loading sequence, the OS loader acts like a scavenger hunt participant following a trail of breadcrumbs. It doesn't guess where things are; it reads explicit offsets and pointers embedded inside the file structures to leap from one header to the next.

The DOS Stub and the First Big Leap

Every PE file begins with a legacy structure, which starts with the signature magic bytes MZ (named after MS-DOS architect Mark Zbikowski). But for modern Windows systems, the most important field in this entire 64-byte header is located at the very end: the e_lfanew field.

A structural view of a Portable Executable file header showing how the e_lfanew offset points past the MS-DOS stub to the PE signature.

The e_lfanew field is a 4-byte offset that tells the exactly how many bytes to skip over to find the start of the real PE Header. This allows the loader to ignore the legacy DOS Stub program and jump straight to the actual target configuration.