PE Format & Relocation Tables: How ASLR Gets Its Address

The Portable Executable (PE) format is not just a reverse-engineering subject. It is the contract between a Windows binary, the loader, endpoint telemetry, exploit mitigations, and code-signing policy. Defenders who can read that contract can quickly answer practical questions: was this file built to relocate, did the loader map it where expected, and did a compiler mitigation survive the build pipeline?

The image the loader receives

A PE begins with the DOS header and its e_lfanew pointer, followed by the PE\0\0 signature, COFF file header, optional header, and section table. The optional header is not optional in a normal executable: it declares the preferred ImageBase, image size, entry point RVA, data-directory locations, and security-relevant DLL characteristics. Common sections include .text (code), .rdata (read-only data), .data (writable data), .idata (imports), and .reloc (base relocations).

RVA, VA, file offset: three coordinates, one frequent mistake

An RVA is relative to the image base. A VA is the actual process virtual address: VA = load base + RVA. A file offset is where bytes sit on disk and must be translated through the relevant section's PointerToRawData and VirtualAddress. For example, an import directory at RVA 0x9000 in an image loaded at 0x00007FF700000000 has VA 0x00007FF700009000. Treating an RVA as a raw file offset produces incorrect parsing and unreliable detection tooling.

What a relocation block says

The base-relocation directory contains blocks grouped by 4 KB page. Each block gives a PageRVA and a sequence of 16-bit entries. An entry's high four bits are its type; its low twelve bits are the offset within that page. On 64-bit user-mode images, IMAGE_REL_BASED_DIR64 is the important type. If an image preferred 0x140000000 but the loader maps it at 0x140100000, its delta is 0x100000; the loader adds that delta to each applicable stored absolute address. Relocation records are not code and do not make an image malicious. They make a position-dependent image movable.

ASLR is a mitigation, not a magic property

ASLR makes code and data addresses less predictable across process starts. It raises the cost of reliable exploitation, especially when combined with DEP, Control Flow Guard (CFG), hardware-enforced stack protection, and strong memory-safe design. ASLR needs entropy and a relocatable image. The PE flag IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE indicates that the image can be rebased. On modern 64-bit Windows, high-entropy VA increases the available randomization range; HIGH_ENTROPY_VA requests it for suitable 64-bit images.

Vulnerability context: disclosures that underline mitigation depth

Memory-corruption vulnerabilities have repeatedly shown why address randomization must be one layer in a system, not the system. CVE-2023-21716 was a Microsoft Word RTF remote code execution vulnerability; successful exploitation required working around the target's available mitigations. CVE-2024-21413 was a Windows SmartScreen security-feature bypass, illustrating that delivery and trust-boundary failures can matter even before a memory-safety primitive is relevant. Neither CVE means that PE relocation data itself is defective. They are useful reminders to validate ASLR alongside patching, macro policy, attachment controls, and least privilege.

Defender workflow: inspect, validate, baseline

1. Inspect static properties. Use Microsoft Windows Security Tools, PE-bear, or capa to identify architecture, imports, sections, and mitigation flags.
2. Validate at runtime. Process Explorer shows image bases and loaded modules; Windows Exploit Protection reports per-process mitigations. Do this on a test endpoint before imposing application-wide policy.
3. Baseline the unusual. Flag unsigned images with anomalous sections, unexpected writable/executable memory, or an unusual import profile. Avoid treating a missing relocation table alone as a verdict; fixed-base images and special cases exist.
4. Harden the build. For native code, enable compiler/linker mitigation options appropriate to the toolchain, including ASLR, DEP/NX, CFG, and stack protections. Verify the shipped artifact, not just project settings.

Practical limits

ASLR can be weakened by information leaks, low entropy, shared mapping behavior, or a missing compatible mitigation. A relocation table does not fix unsafe pointer arithmetic, and disabling a mitigation for compatibility should be a documented exception with compensating controls. The durable strategy is prevention first, compiler and OS mitigations second, and telemetry that can reveal the failure of either.