Lion Cipher Lab

Exploit the heap with the House of Botcake (bypass the tcache double-free key by routing through the unsorted bin)

• Penetration Testing / Red Team
• Advanced
• ~90 min
• Free · no account required

Why it matters

The two earlier tcache labs each stopped short of one wall. The use-after-free lab reused a freed chunk without ever re-freeing it; the poisoning lab corrupted a freed chunk's fd but never freed the same chunk twice -- both deliberately, because glibc 2.29 added a defence that makes the naive move (free the same tcache chunk twice) abort instantly with 'free(): double free detected in tcache'. That defence is a per-chunk `key` stamped on every tcache insertion; free() checks it and refuses a repeat. House of Botcake is the technique that walks around that check instead of through it, and the…

What you'll learn

• The House of Botcake primitive end to end: fill the tcache bin so the victim's first free is routed to the UNSORTED bin, consolidate it with a neighbour, make room in the tcache, then re-free the victim to place a still-live overlapping chunk on the tcache free-list
• Understanding glibc 2.29's tcache double-free defence exactly: the per-chunk `key` field stamped on tcache insertion, why free() aborts with 'double free detected in tcache' when it sees that key again, and why a chunk that went to the unsorted bin never carries it
• Why filling the 7-entry tcache bin is the whole trick: once the bin is full the next free of that size SKIPS the tcache and falls through to the unsorted bin, which is what strips the key check off the victim
• Reading consolidation in a debugger: freeing an adjacent chunk merges it with the victim into one larger unsorted chunk, so a later malloc hands back a chunk that OVERLAPS the still-tcached victim -- the overlap that becomes the write
• Turning the overlap into tcache poisoning and an arbitrary write: overwrite the overlapped victim's fd through the larger allocation, then two malloc()s return a chunk on an address you named
• Heap-exploitation JUDGMENT: WHEN Botcake is the right pick (you have a double-free/UAF, the tcache is full, glibc >= 2.29 so a naive double-free is blocked), WHEN it fails (safe-linking needing a heap leak on 2.32+, tightened tcache count/key checks on newer glibc, ASLR/PIE), and how a pro adapts
• Watching it in pwndbg's `tcachebins`/`heap`, and how the class is actually killed (null-after-free, hardened allocators, AddressSanitizer, memory-safe languages) rather than merely slowed by one more integrity check

Steps in this lab

1. Read this first: your own container, your own program, authorized-only
2. The wall this climbs: the tcache double-free key (glibc 2.29)
3. The trick in one breath: fill the tcache, consolidate, then re-free
4. Pin glibc with Docker -- the version is the whole game
5. Write the vulnerable target -- a slot allocator with a UAF write and an aligned function pointer
6. Compile with mitigations off for teaching -- and note what stays ON
7. Watch the double-free get ACCEPTED in pwndbg (tcachebins)
8. Fire the exploit: overlap the tcached victim, poison its fd, land the write
9. When it fails, and do it better: version sensitivity and the real fixes

Open the full interactive lab →