FSOP Development

Goal: turn FILE-structure corruption into the right libio dispatch path for that glibc era, trigger surface, and endgame — not into random _IO_FILE cargo cult.

Repository positioning: keep offensive-coding/heap-exploitation-dev as the allocator and overlap router, then switch here once success depends more on libio structure modeling, validated jump-table reuse, wide/codecvt/cookie-file dispatch, or trigger choice than on heap choreography itself. Engagement methodology and mitigation strategy live in offensive-techniques/binary-exploitation-technique; concrete FSOP recipes in offensive-ctf/pwn-ctf/references/heap-fsop.md.

When to activate

• Heap, UAF, overlap, arbitrary write, partial overwrite, or stream-adjacent corruption reaches stdin, stdout, stderr, another FILE *, or a fake FILE region.
• The exploit reaches a heap-allocated or dangling stream from fopen/fdopen/custom FILE *, and the real question becomes how fputs/fwrite/cleanup will consume it.
• Need to decide whether the target is classic _IO_list_all, vtable-misalignment, _wide_vtable, _codecvt, obstack, or leak-only FILE abuse.
• Hooks are removed or unrealistic, and the real exploit question is whether FSOP beats return-address, callback, or data-only alternatives.
• Need to reason about FILE, _IO_FILE_plus, _IO_wide_data, _IO_codecvt, pointer-guard-adjacent surfaces, or valid jump-table placement.
• Need a hint-style recognition pass for stream corruption opportunities before building a full heap chain.
• The initial bug is not purely “heap-themed” anymore — for example, a relative libc write into a standard stream, an mmapped chunk reaching libc FILE data, or a direct stream-specific corruption bug.

If the problem is mostly allocator selection, heap shaping, tcache/largebin choreography, or House-family routing before the stream overlap exists, start with offensive-coding/heap-exploitation-dev and return here once FSOP is a real candidate.

First classify the FSOP problem