Can't Stop the ROP: Automating Universal ASLR Bypasses

Can't Stop the ROP: Automating Universal ASLR Bypasses

Speakers: Bramwell Brizendine

Conference: DEF CON 33

YouTube: https://www.youtube.com/watch?v=NrTNNi9PP5Y

Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/Dr.%20Bramwell%20Brizendine%20-%20Can%27t%20Stop%20the%20ROP%20Automating%20Universal%20ASLR%20Bypasses%20for%20Windows.pdf

Overview

Address Space Layout Randomization (ASLR) has long been hailed as one of the most consequential mitigations Microsoft has deployed against memory corruption exploits on Windows. By randomizing the base addresses of executables, stacks, heaps, and system DLLs at load time, ASLR forces attackers to discover memory layouts rather than rely on hard-coded addresses. For years, high-entropy ASLR — the stronger variant introduced to make brute-force and spray attacks impractical — was considered the gold standard of process isolation on Windows.

Dr. Bramwell Brizendine's DEF CON 33 talk systematically dismantles that assumption. He demonstrates a universal, portable technique for bypassing high-entropy ASLR on 64-bit Windows by abusing readable metadata in the Process Environment Block (PEB) — metadata that has always been accessible from user mode. The result is a 100% success rate across all tested OS builds, an automated mini-tool integrated into the open-source DropRocket framework, and a live demonstration that leaves little ambiguity about the practical exploitability of the technique.

Background

▶ Watch: Q&A and closing remarks (0:17)

ASLR has a documented history stretching back to 2001, when the PaX project for Linux first introduced it. The core insight is straightforward: if the attacker cannot reliably predict where code or data lives in memory, crafting a working exploit becomes exponentially harder. By 2004, the community recognized that 32-bit entropy was insufficient — the address space was small enough that brute-force attacks could succeed in seconds. Modern 64-bit Windows systems implement high-entropy ASLR, which dramatically expands the randomized range and is supposed to render both brute-force and heap spray approaches infeasible.

Return Oriented Programming (ROP) emerged as the primary technique to circumvent non-executable memory protections like Data Execution Prevention (DEP/NX). Rather than injecting shellcode, ROP chains together short sequences of existing executable instructions — called "gadgets" — ending in a RET instruction. By arranging these gadgets carefully, an attacker can perform arbitrary computation using only code that is already present in the process. However, building a useful ROP chain requires knowing where gadgets reside in memory — which is exactly what ASLR is designed to prevent.

Classic ASLR bypass techniques include:

• Memory disclosure bugs: A use-after-free or format string vulnerability can leak a function pointer, from which the base address of a DLL or the executable can be derived.
• Heap and page spraying: Filling memory with NOP sleds and shellcode, hoping to land somewhere predictable. Effective against low-entropy ASLR, but largely defeated by high-entropy on modern systems.
• Brute force: Repeatedly crashing and restarting a process, cycling through address possibilities. Only viable in limited server-side scenarios or 32-bit address spaces.
• Side-channel and microarchitectural attacks: Spectre-class techniques that infer memory layouts from timing or cache behavior. Powerful but complex and often mitigated at the hardware level.
• Jump Oriented Programming (JOP): A variant of ROP that uses dispatch gadgets ending in indirect jumps rather than RET, sometimes used to avoid RET-based heuristics.

Brizendine's approach is orthogonal to all of these. It exploits a structural feature of the Windows operating system itself — the PEB — and requires only that an attacker already possess a pre-existing memory corruption vulnerability and the ability to execute ROP gadgets. No information leak is needed beyond what is already readable through standard user-mode mechanisms.

Key Findings

▶ Watch: Introduction: History of ASLR and its limitations (2:29)

The central finding is that the Windows Process Environment Block (PEB) provides sufficient information to derive the base addresses of system DLLs, effectively bypassing high-entropy ASLR on any 64-bit Windows installation, regardless of the specific OS build or the specific application being exploited.

Key findings include:

1. The PEB is universally readable from user mode. The Thread Environment Block (TEB), always pointed to by the GS segment register, contains a pointer to the PEB at offset 0x60. This has always been the case and is by design — Windows applications legitimately access PEB data regularly.

1. PEB fields expose DLL load order and base addresses. The Ldr (loader data) field within the PEB structure contains linked lists of loaded modules, including their base addresses. Because these lists exist in user-accessible memory, no privilege escalation or heap leak is required to read them.

1. The technique achieves 100% success across all tested 64-bit Windows OS builds, including those with Force ASLR enabled (HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\MoveImages).

1. The bypass is binary-agnostic. Unlike classic information leak exploits that are tailored to a specific application's memory layout or a specific vulnerable function, this approach works against any Windows application that meets the two prerequisites: a memory corruption bug that enables ROP gadget execution, and a payload large enough to accommodate the ROP chain.

1. Massively expands attack surface. A small application with limited internal gadgets can be leveraged to reach the full gadget inventory of system DLLs like ntdll.dll, kernel32.dll, and kernelbase.dll, each of which contains thousands of gadgets suitable for building powerful ROP chains.

Technical Deep Dive

▶ Watch: PEB explained: how it enables universal ASLR bypass (7:25)

The attack chain proceeds through several well-defined stages.

Stage 1 — Obtaining the PEB address

The most direct method is through the GS segment register. On 64-bit Windows, GS:[0x30] points to the TEB, and [TEB + 0x60] contains the PEB pointer. If a ROP gadget of the form mov rax, gs:[0x60] or equivalent exists in the target process (common in ntdll.dll), this gives the PEB address directly without any memory leak.

For 32-bit processes (or WOW64 processes running 32-bit code in a 64-bit environment), the equivalent is FS:[0x30]. When operating in WOW64, the technique can use Heaven's Gate — a mechanism to transition from 32-bit compatibility mode into 64-bit native mode — after which R12 holds a pointer to the TEB structure, from which the PEB can be derived.

Additional methods to obtain the PEB address include stack walking (the PEB pointer often appears on the stack during early process initialization), structured exception handler (SEH) records, and other indirect reads that become available given arbitrary read primitives.

Stage 2 — Walking PEB loader data

The PEB.Ldr field (at offset 0x18 in the PEB structure on 64-bit Windows) points to a PEB_LDR_DATA structure. This structure contains three doubly-linked lists of LDR_DATA_TABLE_ENTRY structures:

• InLoadOrderModuleList — modules in the order they were loaded
• InMemoryOrderModuleList — modules in the order they appear in memory
• InInitializationOrderModuleList — modules in initialization order

Each LDR_DATA_TABLE_ENTRY contains the DllBase field, which is the actual loaded base address of the corresponding DLL. By traversing these lists via ROP gadgets that perform chained reads (using gadgets like mov rax, [rax+offset] / ret), the attacker can enumerate all loaded DLLs and extract their base addresses without any traditional information leak.

Stage 3 — Building the expanded ROP chain

Once the base address of a target system DLL (e.g., ntdll.dll) is known, the attacker can compute absolute gadget addresses by adding known offsets (determined statically from a copy of the DLL). This completely negates the entropy provided by ASLR for that DLL and all subsequently reachable DLLs.

With access to ntdll.dll gadgets, common ROP primitives become available: stack pivots, arbitrary writes, register manipulation, and ultimately the ability to call NtAllocateVirtualMemory or VirtualProtect to mark shellcode executable or to directly invoke system calls using the ShellWasp tool.

Stage 4 — Automation via DropRocket

Dr. Brizendine's DropRocket tool automates the ROP chain construction process. The technique described in this talk was packaged as a mini-tool and released (around 3:00 AM the morning of the talk) as an addition to the DropRocket suite. DropRocket takes a target binary, identifies available ROP gadgets, and generates chains that implement the PEB-walk technique automatically, making the attack accessible even to those without deep ROP chain construction expertise.

The prerequisite conditions that must be met for the technique to work are:

1. An existing memory corruption vulnerability in the target process.
2. The ability to execute a ROP chain (i.e., control of the instruction pointer and a sufficient gadget payload size).
3. The target must be a 64-bit Windows process.

These are fairly permissive constraints — most exploitable memory corruption bugs on Windows already satisfy conditions 1 and 2 by definition.

Demo / Proof of Concept

▶ Watch: PEB loader data reveals DLL base addresses in user-mode memory (10:10)

During the live demonstration, Dr. Brizendine walked through the attack against a target Windows process with high-entropy ASLR and Force ASLR both enabled. The demo showed:

1. The target binary loaded with randomized base addresses (confirmed via WinDbg).
2. A ROP chain, constructed automatically by the DropRocket tool, executing within the vulnerable process.
3. The chain reading GS:[0x60] to obtain the PEB address, then traversing the InLoadOrderModuleList to extract the base address of ntdll.dll.
4. Gadget addresses within ntdll.dll computed dynamically from the leaked base address.
5. Subsequent ROP execution using ntdll.dll gadgets to invoke system calls and execute arbitrary code.

The demonstration ran successfully on multiple OS builds, consistent with the claimed 100% success rate. The released DropRocket mini-tool code was made publicly available at the time of the talk.

This was originally investigated in the context of a Microsoft bug bounty program (listed value: $5,000–$15,000), which ultimately led to the structured research effort documented in this talk.

Defensive Implications

▶ Watch: DropRocket framework demo: automated ASLR bypass tool (27:29)

The implications for defenders are significant, particularly for organizations that rely on ASLR as a primary or sole mitigation against memory corruption exploits.

ASLR alone is insufficient. As this research demonstrates, ASLR should be considered a speed bump rather than an absolute barrier. It must be combined with other mitigations to provide meaningful defense-in-depth.

Complementary mitigations that remain effective:

• Control Flow Integrity (CFG/CET): Windows Control Flow Guard and Intel CET (Control-flow Enforcement Technology with Shadow Stack) specifically target ROP chains by validating that indirect branches and returns reach legitimate targets. CET's shadow stack makes return address manipulation considerably harder even after an ASLR bypass.
• Heap isolation and type safety: Memory-safe languages (Rust, Go) eliminate the classes of bug that enable ROP in the first place. Microsoft's ongoing migration of Windows components to Rust is directly relevant here.
• Process isolation: Reducing the attack surface of privileged processes; limiting what system DLLs are loaded into sensitive processes.
• ACG (Arbitrary Code Guard): Prevents dynamic code generation and modification of executable pages, limiting what an attacker can do even after a successful ASLR bypass.
• Exploit telemetry: Detect ROP chain indicators in EDR tooling — large numbers of RET-heavy code paths, stack pivot gadgets, or suspicious reads from the TEB/PEB at runtime.

For software vendors, the PEB-walk technique underscores the importance of shipping binaries compiled with /GUARD:CF, enabling CET compatibility, and auditing for any memory corruption vulnerabilities before attackers can use them as the prerequisite first step.

Key Takeaways

• High-entropy ASLR on 64-bit Windows can be bypassed universally using the Process Environment Block, which is always readable from user mode via GS:[0x60] → PEB → PEB.Ldr → LDR_DATA_TABLE_ENTRY.DllBase.
• The technique requires only a pre-existing memory corruption vulnerability and the ability to execute ROP gadgets — no separate information-leak primitive is needed.
• The attack is binary-agnostic and portable across all tested 64-bit Windows OS builds, earning it the "universal" characterization in the talk title.
• DropRocket automates the construction of PEB-walking ROP chains, lowering the barrier for practical exploitation.
• Defenders should treat ASLR as one layer in a defense-in-depth stack, not a standalone control. CET, CFG, ACG, and memory-safe languages are the appropriate complementary mitigations.

About the Speaker(s)

▶ Watch: Bypassing Force ASLR (MoveImages registry setting) as well (37:29)

Dr. Bramwell Brizendine is Director of the Verona Lab at the University of Alabama in Huntsville (UAH) and an Assistant Professor with a PhD in Cyber Operations — a technically intensive degree focused on reverse engineering, malware analysis, and software exploitation. He is the creator of several open-source offensive security tools: ShellWasp (enabling Windows syscall-based shellcode), JOPRocket (automated Jump Oriented Programming), and DropRocket (Return Oriented Programming automation). His research has been funded by the NSA and the DLD (Defense Large-scale Discovery) program to the tune of approximately $300,000. He has presented at Black Hat, Hack in the Box, Virus Bulletin, and numerous other industry conferences. His work spans the intersection of academic research and practical offensive tooling, with an emphasis on Windows low-level exploitation and mitigation analysis.