Heap Exploitation Playbook

Problem

In binary exploitation, heap overflows often appear in real service code paths, but glibc heap internals make technique selection easy to get wrong. Structures such as tcache, unsorted bin, fastbin, and chunk metadata impose version-specific constraints. glibc 2.32+ also introduced safe-linking / PROTECT_PTR, which changes traditional fastbin write assumptions. If the wrong glibc assumptions are used, later leak paths and arbitrary write primitives may not fit the target.

How It Works

The skill organizes heap exploitation as a version-aware routing playbook rather than a list of isolated tricks. Its core capabilities include:

• ptmalloc2 internals: arena, chunk, top chunk, bin structure, and allocation paths, helping identify which metadata can be corrupted after an overflow.
• tcache mechanics: tcache entry layout, validation behavior, and constraints relevant to tcache-based attacks.
• libc / heap leaks: deriving usable addresses from heap metadata, bin pointers, or IO_FILE-related paths, then using those leaks to support ASLR/RELRO bypass decisions.
• version routing: selecting techniques such as House of Force, House of Orange, House of Spirit, and tcache attacks based on glibc version, with explicit notes on safe-linking effects.

A typical workflow starts by checking binary protections, heap layout, and which overflow fields are controllable. Then the analyst locates corruptable metadata, chooses a leak path, and converts the resulting arbitrary write into controlled execution. The source material also routes to related skills such as stack-overflow-and-rop, format-string-exploitation, arbitrary-write-to-rce, and binary-protection-bypass, with advanced references in HOUSE_OF_TECHNIQUES.md and IO_FILE_EXPLOITATION.md.

Boundaries

It is focused on glibc heap exploitation and does not cover non-glibc allocators, Windows heap internals, or JavaScript runtime heaps. For real targets, conclusions must be validated against source code, protection settings, privilege context, and the exact glibc version. The techniques mentioned may depend on particular libc structures or versions. Security research should be performed only on systems where you have explicit authorization.