Chapter 7: PE Format

📦 What is PE?

📖 Definition: PE (Portable Executable)

The executable file format for Windows. Includes .exe, .dll, .sys, .ocx and more.
"Portable" because the same format works on all Windows versions.

When you open an EXE file in a Hex Editor or RE tool, you see the PE structure. Understanding this format is essential for analyzing malware and suspicious files.

🔨 Who Creates the PE Structure?

The developer only writes source code. The compiler and linker automatically create all the PE headers, signatures, and structure!

┌─────────────────────────────────────────────────────────────────────────┐
│                        FROM CODE TO EXE                                 │
└─────────────────────────────────────────────────────────────────────────┘

     DEVELOPER                    COMPILER                   LINKER
    writes this:                creates this:             creates this:
         │                           │                         │
         ▼                           ▼                         ▼
┌─────────────────┐         ┌─────────────────┐       ┌─────────────────┐
│   main.c        │         │   main.obj      │       │   program.exe   │
│                 │         │                 │       │                 │
│ #include <...>  │         │ Machine code    │       │ ┌─────────────┐ │
│                 │  ───►   │ (just the code, │ ───►  │ │ DOS Header  │ │
│ int main() {    │ compile │  no headers)    │ link  │ │ DOS Stub    │ │
│   printf("Hi"); │         │                 │       │ │ PE Sig      │ │
│   return 0;     │         │ Symbols:        │       │ │ File Header │ │
│ }               │         │ - main          │       │ │ Opt Header  │ │
│                 │         │ - printf (ref)  │       │ │ Sections    │ │
└─────────────────┘         └─────────────────┘       │ │ .text       │ │
                                                      │ │ .data       │ │
     YOU write                COMPILER does           │ │ Imports     │ │
     only this!               the translation         │ └─────────────┘ │
                                                      └─────────────────┘
                                                      
                                                       LINKER builds
                                                       the complete
                                                       PE structure!

💡 Summary: Who Does What?

Role	Creates
Developer	Source code only (what the program does)
Compiler	Machine code (translated instructions)
Linker	Complete PE structure (DOS Header, PE Signature, all headers, sections, imports)

🗂️ General PE Structure

💡 Section Headers vs Sections - What's the difference?

Term	What is it	Analogy
Section Headers	Metadata describing each section (name, size, location, permissions)	Table of Contents in a book
Sections	The actual code/data content (.text, .data, .rsrc)	The actual chapters in a book

Each Section Header (40 bytes) tells you WHERE to find its Section in the file!

📋 DOS Header

📖 Definition: DOS Header

The first 64 bytes of every PE. Starts with MZ (0x4D5A) - initials of Mark Zbikowski, a Microsoft programmer.

Important fields (these are actual field names from the Windows IMAGE_DOS_HEADER structure):

Field	Location	Value	Meaning
`e_magic`	Offset 0x00 (fixed)	`4D 5A` = "MZ"	Magic number - confirms this is an executable
`e_lfanew`	Offset 0x3C (fixed)	Varies per file	Pointer to PE Signature location

💡 How e_lfanew Works

The field e_lfanew is always at offset 0x3C - this never changes.
But the value inside tells you where to find the PE Signature:

Step 1: Go to offset 0x3C
Step 2: Read the 4-byte value there (e.g., 80 00 00 00 = 0x80)
Step 3: Jump to that offset (0x80)
Step 4: You should find: 50 45 00 00 ("PE\0\0")

┌────────────────────────────────────────────────────────────────┐
│ Offset 0x00: 4D 5A ...           ; e_magic = "MZ" (always)     │
│ ...                                                            │
│ Offset 0x3C: 80 00 00 00         ; e_lfanew = 0x80             │
│              ↓                     (this VALUE varies)         │
│              └─────────────────────────────┐                   │
│ ...                                        ↓                   │
│ Offset 0x80: 50 45 00 00         ; PE Signature found here!    │
└────────────────────────────────────────────────────────────────┘

📋 PE Signature & File Header

📖 Definition: PE Signature

4 bytes that confirm this is a Windows PE file: 50 45 00 00
In ASCII: "P" (0x50) + "E" (0x45) + null (0x00) + null (0x00) = "PE\0\0"

💡 Why Both MZ and PE Signatures?

Signature	Bytes	Purpose
`MZ`	`4D 5A`	Says "I might be an executable" (legacy DOS compatibility)
`PE\0\0`	`50 45 00 00`	Confirms "Yes, I'm definitely a Windows PE file!"

Historical reason: PE files start with MZ so old DOS systems show "This program cannot be run in DOS mode" instead of crashing. Windows uses e_lfanew to find the real PE data.

File Header (COFF Header) - 20 bytes:

Field	Size	Description
`Machine`	2	CPU type (0x14c=i386, 0x8664=AMD64)
`NumberOfSections`	2	How many sections are in the file
`TimeDateStamp`	4	Compilation time (Unix timestamp)
`SizeOfOptionalHeader`	2	Size of Optional Header
`Characteristics`	2	Flags (EXE, DLL, etc.)

📋 Optional Header

Despite the name, it's required for EXE and DLL! Contains critical information:

Field	Description
`Magic`	0x10b = PE32, 0x20b = PE32+ (64-bit)
`AddressOfEntryPoint`	RVA of entry point - where code execution starts!
`ImageBase`	Preferred load address (usually 0x00400000)
`SectionAlignment`	Section alignment in memory
`FileAlignment`	Section alignment in file
`SizeOfImage`	Total size in memory
`Subsystem`	GUI (2), Console (3), Driver (1)
`DataDirectory`	Array of 16 entries - imports, exports, resources...

📖 Definition: RVA (Relative Virtual Address)

Address relative to ImageBase. Actual memory address = ImageBase + RVA.

💡 Entry Point

AddressOfEntryPoint is the RVA of the first instruction to execute.
This is the first place to look at in RE!

Actual address = ImageBase + EntryPoint
For example: 0x00400000 + 0x1000 = 0x00401000

📦 Sections

📖 Definition: Section

A region in the file with a specific purpose - code, data, resources, etc. Each section has a name, size, and permissions.

Section	Content	Typical Permissions
`.text`	Program code	Read + Execute
`.data`	Initialized global variables	Read + Write
`.rdata`	Read-only data, strings, imports	Read only
`.bss`	Uninitialized variables	Read + Write
`.rsrc`	Resources (icons, dialogs, strings)	Read only
`.reloc`	Relocation info (for loading at different address)	Read only

Section Header Structure

Each Section Header is exactly 40 bytes and contains info about one Section:

💡 Section Header Entry (40 bytes)

┌──────────────────────────────────────────────────────┐
│ Field              │ Size    │ Example              │
├────────────────────┼─────────┼──────────────────────┤
│ Name               │ 8 bytes │ ".text"              │
│ VirtualSize        │ 4 bytes │ 0x1000               │
│ VirtualAddress     │ 4 bytes │ 0x1000 (RVA)         │
│ SizeOfRawData      │ 4 bytes │ 0x800                │
│ PointerToRawData   │ 4 bytes │ 0x400 ← WHERE in file│
│ ... (other fields) │ 12 bytes│                      │
│ Characteristics    │ 4 bytes │ 0x60000020 (R+X)     │
└──────────────────────────────────────────────────────┘

The key field: PointerToRawData

This tells you the file offset where the actual Section data starts!

Example: 3 sections = 3 headers = 3 × 40 = 120 bytes

Section Headers area in file:
┌─────────────────────────────────────────┐
│ .text header │ PointerToRawData = 0x400 │ → Go to offset 0x400 for code
├──────────────┼──────────────────────────┤
│ .data header │ PointerToRawData = 0x800 │ → Go to offset 0x800 for data
├──────────────┼──────────────────────────┤
│ .rsrc header │ PointerToRawData = 0xC00 │ → Go to offset 0xC00 for resources
└─────────────────────────────────────────┘

📥 Import Table

📖 Definition: Import Table

A list of functions the program imports from other DLLs. Windows fills in the addresses at load time.

Where is the Import Table?

This can be confusing! The Import Table involves two places:

┌─────────────────────────────────────────────────────────────────────────┐
│                  WHERE IS THE IMPORT TABLE?                             │
└─────────────────────────────────────────────────────────────────────────┘

   OPTIONAL HEADER                              SECTIONS
  ┌─────────────────────┐                    ┌─────────────────────┐
  │ ...                 │                    │ .text               │
  │ DataDirectory[0]    │                    │ (code)              │
  │ DataDirectory[1] ───┼───── POINTER ─────►├─────────────────────┤
  │   (Import Table)    │      (RVA)         │ .rdata or .idata    │
  │ DataDirectory[2]    │                    │ ┌─────────────────┐ │
  │ ...                 │                    │ │ IMPORT TABLE    │ │
  └─────────────────────┘                    │ │ (actual data)   │ │
                                             │ │ - kernel32.dll  │ │
   Contains: POINTER                         │ │   - CreateFile  │ │
   (tells you WHERE                          │ │   - ReadFile    │ │
   to find imports)                          │ │ - user32.dll    │ │
                                             │ │   - MessageBox  │ │
                                             │ └─────────────────┘ │
                                             └─────────────────────┘
                                             
                                              Contains: ACTUAL DATA
                                              (the real import list)

💡 Two Parts to Understand

Location	What's there	Analogy
`DataDirectory[1]`	A pointer (RVA) saying "imports are at address X"	Street address on an envelope
Inside a Section (usually `.rdata` or `.idata`)	The actual Import Table data (DLL names, function names)	The actual house at that address

Common imported functions (tells us what the program does):

CreateFile, ReadFile - file access
RegOpenKey - Registry access
socket, connect - network communication
VirtualAlloc - memory allocation
CreateProcess - running programs

💡 Important in RE

Scanning the Imports gives an important hint about what the program does!
Malware sometimes tries to hide imports (dynamic loading, obfuscation).

📤 Export Table

📖 Definition: Export Table

A list of functions the file exports for use by others. Common in DLLs.

Just like Import Table, the Export Table has a pointer and actual data:

DataDirectory[0]  →  POINTER (RVA) saying "exports are at address X"
                           ↓
.edata section    →  ACTUAL EXPORT DATA (function names, addresses)

📋 DataDirectory - The Master Pointer Table

The DataDirectory in the Optional Header is an array of 16 pointers.
Each entry points to different data stored in the sections:

Index	Name	Points to
0	Export Table	Functions this file exports (for DLLs)
1	Import Table	Functions imported from other DLLs
2	Resource Table	Icons, dialogs, strings, etc.
3	Exception Table	Exception handling info
4	Certificate Table	Digital signatures
5	Base Relocation	For loading at different address
6	Debug	Debug information
12	IAT	Import Address Table
14	CLR Runtime	.NET metadata

💡 Key Concept: Headers Have Pointers, Sections Have Data

┌─────────────────────────────────────────────────────────────────┐
│                     HEADERS vs SECTIONS                         │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│   OPTIONAL HEADER                      SECTIONS                 │
│   (DataDirectory)                      (actual content)         │
│                                                                 │
│   ┌──────────────┐                   ┌──────────────────────┐   │
│   │ [0] Export ──┼────► POINTER ────►│ .edata: Export data  │   │
│   │ [1] Import ──┼────► POINTER ────►│ .rdata: Import data  │   │
│   │ [2] Resource─┼────► POINTER ────►│ .rsrc:  Icons, etc.  │   │
│   │ [5] Reloc  ──┼────► POINTER ────►│ .reloc: Reloc data   │   │
│   └──────────────┘                   └──────────────────────┘   │
│                                                                 │
│   Contains: RVA + Size               Contains: ACTUAL DATA      │
│   (WHERE to find it)                 (the real content)         │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Remember: Headers never contain the actual data - they only contain pointers that tell you where to find the data in the sections!

🔧 Tools for PE Analysis

PE-bear - excellent graphical PE analysis tool
CFF Explorer - advanced PE editor
pestudio - PE analysis for malware identification
Detect It Easy (DIE) - identify packers and compilers
pefile (Python) - library for PE analysis in code

📋 Chapter Summary

PE - Windows executable file format
DOS Header - starts with MZ, points to PE Header
File Header - CPU type, number of sections
Optional Header - Entry Point, ImageBase, imports
Sections - .text (code), .data (data), .rsrc (resources)
Import Table - imported functions (very important for analysis!)
RVA - relative address, need to add ImageBase

← Chapter 6: Assembly Flow Control Chapter 8: Calling Conventions →