Heap Exploitation Dev

Heap Exploitation Development

Goal: turn a heap bug into a repeatable primitive and then into the right endgame for that allocator/version, not the most nostalgic House name.

When to activate

• Heap overflow, off-by-one, UAF, double-free, arbitrary free, overlapping chunk, or stale-pointer bug touches heap-managed objects.
• Need allocator-aware exploit design instead of generic memory corruption advice.
• Need to choose between tcache poisoning, bin corruption, FSOP, setcontext/ROP, or data-only outcomes.
• Linux target may use glibc, musl, or custom allocators.
• Windows target uses the default process heap, a private heap, LFH, VS, or Segment Heap.

First classify the environment

1. Identify allocator and version

• glibc/ptmalloc: determine version first; most House viability is version-gated.
• musl mallocng: assume group/slot shaping and application object corruption, not direct House portability.
• Windows: determine whether the bug is on NT heap, LFH, VS, or Segment Heap, and whether it is a private heap.
• Custom allocator: reverse metadata, pool headers, callback tables, and destructor paths before importing glibc assumptions.

2. Classify the bug primitive

• overflow / off-by-one / null byte
• UAF / stale pointer / double free
• arbitrary free / fake chunk / pointer substitution
• overlap / leak / relative write

3. Decide the capability you actually need

• heap leak
• libc leak
• arbitrary allocation
• arbitrary write
• FILE overlap / FSOP
• stack pivot / setcontext / ORW
• data-only corruption

4. Map mitigations before choosing the chain

• tcache
• tcache double-free checks
• safe-linking
• FILE vtable validation
• hook removal (__malloc_hook, __free_hook)
• RELRO / PIE / ASLR
• seccomp / sandboxing
• Windows CFG / CET / heap termination on corruption

Version-first selection

House families worth prioritizing

Treat House names as indexed solution families, not trophies. Primitive + allocator + version wins over naming aesthetics.

Mitigation-driven rules

• Safe-linking (glibc 2.32+): do not plan blind tcache poisoning unless you have a heap leak or a metadata route such as House of Water or safe-link double-protect.
• Hook removal (glibc 2.34+): if the exploit sketch ends at __free_hook or __malloc_hook, it is probably outdated unless libc_malloc_debug.so.0 is explicitly involved.
• FILE vtable validation: assume valid jump-table regions only. Prefer Apple 2/3, _wide_data, _codecvt, or other in-section routes over fake arbitrary vtables.
• Largebin hardening: verify the exact libc. Classic largebin attack is not a universal assumption on 2.42+.
• musl mallocng: cycling offsets, guard pages, cookies, and mmap()-backed groups change heap shaping completely; validate adjacency and slot reuse empirically.
• Windows modern heaps: encoded metadata, heap isolation, safe unlinking, CFG, and CET push you toward adjacent-object corruption and post-primitive ROP/data-only goals, not nostalgic metadata-only exploits.
• Seccomp / SUID / restricted shells: prefer ORW or setcontext/ROP over system("/bin/sh").
• Zeroing / self-using write primitive: if your only path to write a target is an allocation that zeroes the returned chunk (calloc / explicit memset/rep stosq) and the program then immediately uses that region (prints through it, re-reads it), an in-place forge over a libc stream/struct self-destructs before you can finish. Model the write primitive's side effects explicitly; when blocked, route to a print-free / cross-stream write (see fsop-dev: input-buffer redirection) or a second-thread/free()-deposited write rather than fighting the ordering.
• Per-thread allocator state: each thread has its own arena + own tcache, and free() uses the calling thread's tcache. A worker thread's free() of a main-arena chunk lands in the worker's tcache, not main's — so it does not create a same-bin double-free for the main thread. Confirm which thread/tcache a free targets before assuming overlap.

Endgame selection

• glibc < 2.34: hooks, _IO_list_all, stdout/stderr corruption, or classic one-gadget chains may still fit.
• glibc >= 2.34: bias toward FSOP, House of Apple 2/3, _wide_data or _codecvt control, setcontext+61, or clean ORW. Once the allocator work is done and the hard part becomes libio dispatch/trigger selection, hand off to offensive-coding/fsop-dev.
• SUID targets: system("/bin/sh") can drop privilege; use setcontext or ROP to normalize credentials first.
• No libc leak: only choose Roman/Corrosion/Crust-like chains if the target really blocks easier leak paths and you can afford entropy/bruteforce.
• Only heap-relative corruption available: favor overlap-driven data-only attacks, allocator metadata hijack, or tcache-relative writes before chasing code execution.
• Windows: use the heap bug to get AAR/AAW, then pivot to vtable/function-pointer/IAT/stack targets with CFG-aware gadget choice.

Reliability checklist

• Confirm exact allocator, heap type, and libc version before naming a technique.
• Cross-check named glibc techniques against a matching how2heap version folder when available; a House name is a hypothesis, not compatibility proof.
• Validate chunk sizes against the real bin class and alignment rules.
• Track whether the victim chunk will land in tcache, fastbin, unsorted, smallbin, largebin, LFH, VS, or Segment Heap.
• Map aliases between allocator metadata and attacker-used storage. A tcache entry, bin link, chunk field, or application slot may be the same qword; allocator maintenance can destroy a primitive that worked in isolation.
• Re-run later helper allocations after the full corruption sequence. A parser's internal malloc or realloc is part of the exploit state machine, not an independent trigger.
• When a later allocation must bypass sacrificial metadata, test the exact normalized size. A merely larger victim may be sorted and force the allocator to validate the next corrupted node.
• Prove the leak first if the chain needs libc or heap base.
• Model trigger paths separately from corruption paths; many House chains fail at the final call site, not the heap step.
• Stress the exploit under multiple runs and slightly different heap schedules.
• Prefer the shortest stable chain, not the fanciest multi-House stack.

Anti-patterns

• Recommending __free_hook on modern glibc by reflex.
• Assuming House names transfer unchanged across glibc, musl, jemalloc, tcmalloc, and Windows heaps.
• Treating Windows LFH or Segment Heap as if they were old-school unsafe unlink playgrounds.
• Chasing code execution when a stable data-only or ORW path is enough.
• Cargo-culting a public writeup without checking allocator version, build quirks, or mitigation deltas.

Resources

• references/glibc-techniques.md — glibc era map, House families, how2heap-backed compatibility workflow, latest tcache-metadata routes, and version-aware selection.
• references/house-family-atlas.md — dedicated atlas of classic, modern, and post-hook House families with status, prerequisites, and when to de-prioritize them.
• references/patterns-and-mitigations.md — primitive taxonomy, allocator comparison, and mitigation-driven decision rules.
• references/fsop-and-post-hook-targets.md — Apple 2/3, FSOP paths, and post-hook endgames.
• ../fsop-dev/SKILL.md — standalone FSOP router for libio-specific dispatch, trigger, and endgame selection once stream overlap is already on the table.
• references/windows-techniques.md — NT/LFH/Segment Heap notes, realistic primitives, and Windows-specific caveats.
• Upstream methodology: offensive-techniques/binary-exploitation-technique (primitive→impact strategy, mitigation selection) and offensive-ctf/pwn-ctf/references/heap.md (concrete recipes).

Load the reference files only after allocator, version, primitive, and intended endgame are clear; they hold the depth that does not belong in this routing file.