/exploiting-memory-corruption

name: exploiting-memory-corruption
description: Develop working exploits from memory-corruption bugs in native binaries — turning a stack/heap overflow, use-after-free, or type confusion into control flow, an arbitrary read/write, and a shell, and defeating ASLR, NX, stack canaries, PIE, and RELRO along the way. Use when you have a crashing input or a known bug class in an ELF/PE and need a primitive, when building a ROP chain with pwntools and ROPgadget, or when working a CTF pwn challenge or authorized binary exploitation.
verified: 2026-08-07

Exploiting Memory Corruption

Reverse engineering tells you a binary is buggy. Exploitation is the separate craft of turning that bug into a controlled primitive and then into code execution, against the mitigations the target actually ships. The work is a chain of conversions — bug to primitive, primitive to leak, leak to control — and each link is chosen by what the binary's protections allow, not by rote.

When to Use

• You have a crash or a known bug class in an ELF/PE and need to assess

exploitability and build a working exploit

• Constructing a ROP/JOP chain, a ret2libc, or a heap-grooming sequence
• Defeating a specific mitigation set (ASLR, NX/DEP, canary, PIE, RELRO) on a

lab or CTF target

• Working an authorized binary-exploitation task or a CTF pwn challenge

When NOT to Use

• **Recovering what the binary does** — disassembly, decompilation, algorithm

recovery — is `analyzing-binaries`; do that first if the bug is not yet understood.

• **Unpacking or de-virtualizing a protected binary** before you can even see

the code — use `unpacking-protected-binaries`.

• **Web, deserialization, or injection bugs** — those are their own skills

(`testing-web-applications`, `exploiting-deserialization`); this skill is native memory corruption only.

• **Kernel/driver exploitation** specifically — the primitives differ enough

(no libc, SMEP/SMAP/KASLR, syscall context) that it is out of scope here; the userland method still informs it.

• **Fuzzing to *find* the bug** — that is a discovery step; this skill starts

once you have a crash.

Enumerate the Mitigations First

The exploit you can build is dictated by what is turned on. Read them before planning anything (`checksec`, or `pwntools`' `checksec`/ELF):

| Mitigation | What it blocks | The usual answer | | --- | --- | --- | | **NX / DEP** | Executing your shellcode on the stack/heap | ROP / ret2libc — reuse existing executable code | | **ASLR** | Hardcoding addresses | An info leak to recover a base, then compute offsets | | **Stack canary** | Naive stack-return overwrite | Leak the canary, overwrite something else, or brute a forking server | | **PIE** | Hardcoding the binary's own addresses | Leak a binary address; until then only relative/partial overwrites | | **Partial RELRO** | Little — GOT is still writable | GOT overwrite is on the table | | **Full RELRO** | GOT overwrite | Target `__malloc_hook`/`__free_hook` (pre-2.34), or a ROP-only path |

The two questions that order the work: *do I have an info leak* (ASLR/PIE), and *where can I write* (RELRO). Everything else follows from those.

Bug Class to Primitive

Name what you have before reaching for a technique:

• **Stack buffer overflow** → direct control of saved return address; the

cleanest path to a ROP chain, canary permitting.

• **Heap overflow / off-by-one** → corrupt adjacent chunk metadata or an

adjacent object's pointers; primitive depends on the heap layout you can groom.

• **Use-after-free** → reallocate the freed slot with attacker data so a stale

pointer is used under your control; classic route to a fake vtable/object.

• **Type confusion** → treat one type's fields as another's, often yielding a

read/write or a controlled call directly.

• **Format string** → `%n` for a targeted write and `%p`/`%s` for a leak; often

both a leak and a write from one bug.

• **Integer overflow / OOB** → usually a means to one of the above (a

short-computed size producing a heap overflow).

The goal of this step is one of three primitives: **control flow hijack**, an **arbitrary read**, or an **arbitrary write**. Get to a primitive, then build.

ROP and Code Reuse

With NX on, you execute the program's own bytes in an order you choose:

• **Find gadgets** with ROPgadget or ropper; look for the `pop rdi; ret`-style

register controls that set up a call.

• **ret2libc** — return into `system("/bin/sh")` once you have a libc base; the

most direct chain when libc is available and leaked.

• **ret2csu** to control `rdx`/`rsi` when no clean gadget exists, using

`__libc_csu_init`'s tail on pre-2.34 binaries.

• **SROP** (sigreturn-oriented) when gadgets are scarce but you can stage a

fake signal frame and reach a `sigreturn`.

• **ret2dlresolve** to call a function by forcing the dynamic linker to resolve

it, useful with no leak and partial RELRO.

• **one_gadget** to find a single libc address that execs a shell, collapsing

the final stage when its constraints hold.

Match the leaked libc to a build with `libc-database` so the offsets are right — a chain built against the wrong libc fails silently.

Heap Exploitation (glibc ptmalloc)

Heap work is layout work: you arrange allocations so a corruption lands on something useful. The technique depends on the glibc version, because the allocator's checks have tightened steadily.

• **tcache poisoning** (2.26+) — the highest-leverage modern primitive: corrupt

a freed tcache chunk's `next` to return an arbitrary pointer from the next `malloc`. On 2.32+ the pointer is mangled by **safe-linking** (XORed with the address it is stored at, shifted right by 12), so you need a heap leak to forge it, and 2.34 removed the `__free_hook`/`__malloc_hook` targets that used to end the chain.

• **fastbin dup** — double-free into the fastbin to return the same chunk twice;

watch the tcache-first behaviour on modern glibc.

• **unsorted-bin leak** —