PE Format Overview

The Portable Executable file structure: DOS header and stub, NT headers, the optional header, data directories, and section headers — the fundamental container Windows uses for executables, DLLs, and drivers

What is a PE File?

The Portable Executable (PE) format is the standard file format for executables (.exe), dynamic-link libraries (.dll), kernel drivers (.sys), control panel applets (.cpl), and other executable code on Windows. The "portable" in the name is historical — it was designed to be portable across different CPU architectures. There are two variants:

• PE32: 32-bit executable; OptionalHeader.Magic = 0x010B
• PE32+ (PE64): 64-bit executable; OptionalHeader.Magic = 0x020B

The overall structure of a PE file on disk is a sequence of headers followed by sections:

  PE File Layout (on disk)
  ─────────────────────────────────────────────────────────────────────
  Offset 0x00  ┌─────────────────────────────────────────────────┐
               │  DOS Header (IMAGE_DOS_HEADER)         64 bytes  │
               │  Magic: 0x5A4D ("MZ")                            │
               │  e_lfanew: offset to NT Headers                  │
               ├─────────────────────────────────────────────────┤
               │  DOS Stub (variable)                             │
               │  Legacy x86 code: "This program cannot be..."   │
               ├─────────────────────────────────────────────────┤
  e_lfanew ──► │  NT Headers (IMAGE_NT_HEADERS)                   │
               │  ┌──────────────────────────────────────────┐   │
               │  │  Signature: 0x00004550 ("PE\0\0")        │   │
               │  ├──────────────────────────────────────────┤   │
               │  │  File Header (IMAGE_FILE_HEADER) 20 bytes │   │
               │  │  Machine, NumberOfSections, TimeDateStamp │   │
               │  │  Characteristics                          │   │
               │  ├──────────────────────────────────────────┤   │
               │  │  Optional Header                          │   │
               │  │  (variable size, despite the name)        │   │
               │  │  Entry point, image base, section alignment│   │
               │  │  Data directory array (16 entries)         │   │
               │  └──────────────────────────────────────────┘   │
               ├─────────────────────────────────────────────────┤
               │  Section Headers (array, 40 bytes each)          │
               │  IMAGE_SECTION_HEADER × NumberOfSections         │
               ├─────────────────────────────────────────────────┤
               │  .text section (code)                            │
               ├─────────────────────────────────────────────────┤
               │  .data section (initialized globals)             │
               ├─────────────────────────────────────────────────┤
               │  .rdata section (read-only data, imports)        │
               ├─────────────────────────────────────────────────┤
               │  ... other sections ...                          │
               └─────────────────────────────────────────────────┘

  

DOS Header and Stub

Every PE file begins with an IMAGE_DOS_HEADER structure. This is a legacy artifact from the MS-DOS era — it exists to provide a useful error message when someone tries to run a Windows executable on DOS. The two fields that actually matter are:

The DOS stub is a tiny x86 real-mode program stored between the DOS header and the NT headers. When executed on DOS, it prints "This program cannot be run in DOS mode" and exits. On Windows, the loader ignores it entirely — it jumps straight to the address in e_lfanew.

NT Headers

At offset e_lfanew, the NT Headers begin with the 4-byte PE signature (50 45 00 00 = "PE\0\0"), followed by two fixed structures:

IMAGE_FILE_HEADER (20 bytes)

Optional Header

The Optional Header is not optional for executable images — it's always present for .exe and .dll files. It contains the fields the loader needs to map and execute the file.

Data Directories

At the end of the Optional Header is an array of 16 IMAGE_DATA_DIRECTORY entries, each 8 bytes (4-byte RVA + 4-byte Size). Each entry points to a specific structural component of the PE file:

Section Headers

After the NT Headers comes the section table — an array of IMAGE_SECTION_HEADER structures (40 bytes each), one per section. Each section header describes one block of content in the PE file.

  RVA vs Raw Offset — The Address Gap
  ─────────────────────────────────────────────────────────────────
  On disk:                        In memory (after loading):
  ┌──────────────────┐  0x000     ┌──────────────────┐  ImageBase
  │  All headers     │            │  All headers     │  + 0x0000
  │                  │            │                  │
  └──────────────────┘  0x400     └──────────────────┘  + 0x1000
  ┌──────────────────┐            ┌──────────────────┐
  │  .text section   │            │  .text section   │
  │  Raw data starts │            │  Mapped at RVA   │
  │  at 0x400        │            │  0x1000          │
  └──────────────────┘  0x800     └──────────────────┘  + 0x3000
  ┌──────────────────┐            ┌──────────────────┐
  │  .data section   │            │  .data section   │
  └──────────────────┘            └──────────────────┘

  VA (Virtual Address) = ImageBase + RVA
  Raw File Offset = PointerToRawData + (RVA - VirtualAddress)

  

Parsing PE Headers with Python

import pefile
import math
from collections import Counter

def analyze_pe(filepath):
    pe = pefile.PE(filepath)
    dos = pe.DOS_HEADER
    nt = pe.NT_HEADERS
    opt = pe.OPTIONAL_HEADER

    print(f"Magic: {'PE32+' if opt.Magic == 0x20B else 'PE32'}")
    print(f"Machine: {hex(nt.FILE_HEADER.Machine)}")
    print(f"Entry Point (RVA): {hex(opt.AddressOfEntryPoint)}")
    print(f"Image Base: {hex(opt.ImageBase)}")
    print(f"Subsystem: {opt.Subsystem}")  # 2=GUI, 3=console
    print(f"TimeDateStamp: {hex(nt.FILE_HEADER.TimeDateStamp)}")
    is_dll = bool(nt.FILE_HEADER.Characteristics & 0x2000)
    print(f"Is DLL: {is_dll}")
    aslr = bool(opt.DllCharacteristics & 0x0040)
    nx   = bool(opt.DllCharacteristics & 0x0100)
    cfg  = bool(opt.DllCharacteristics & 0x4000)
    print(f"ASLR={aslr}  NX={nx}  CFG={cfg}")

    print("\nSections:")
    for section in pe.sections:
        name = section.Name.decode("utf-8", errors="replace").strip("\x00")
        data = section.get_data()
        entropy = calculate_entropy(data)
        flags = []
        if section.Characteristics & 0x20000000: flags.append("exec")
        if section.Characteristics & 0x40000000: flags.append("read")
        if section.Characteristics & 0x80000000: flags.append("write")
        print(f"  {name:10s}  VA={hex(section.VirtualAddress)}  "
              f"RawSize={hex(section.SizeOfRawData)}  "
              f"Entropy={entropy:.2f}  [{','.join(flags)}]")
    pe.close()

def calculate_entropy(data: bytes) -> float:
    if not data:
        return 0.0
    counts = Counter(data)
    total = len(data)
    return -sum((c/total) * math.log2(c/total) for c in counts.values())

Malware PE Tricks

High-Entropy Sections (Packed Payloads)

Legitimate code sections have entropy around 5.0–6.5 out of 8.0. Encrypted or compressed payloads are near-random, pushing entropy above 7.0 or 7.5. A .text section with entropy 7.8 is a strong indicator of a packed or encrypted payload that decrypts itself at runtime.

Section Name Anomalies

Legitimate compilers produce standard section names: .text, .data, .rdata, .bss, .rsrc, .reloc. Malware uses: unusual names like .upx0/.upx1 (UPX packer), blank names, names with non-ASCII characters, or sections named to look like Windows sections but with unexpected permissions.

Section Permission Anomalies

Normal sections: .text = exec+read (never writable), .data = read+write (never executable). A section that is both writable and executable (0xE0000020) is a major red flag — it's a common property of shellcode loaders that write their payload into memory and then execute from the same region.

Missing or Zeroed Timestamps

The TimeDateStamp field in the File Header is the Unix timestamp when the linker produced the executable. Malware often falsifies this: setting it to 0, setting it to a date before Windows existed, or setting it to a future date. Correlating the compile timestamp against when the file first appeared in your environment is a useful signal.

Minimal Imports

Packed or reflectively-loaded malware often has an import table with only one or two DLLs — typically kernel32.dll with just LoadLibrary and GetProcAddress. This is enough to load all other needed DLLs dynamically at runtime, hiding the true import list from static analysis.

Q & A