Binary Exploitation Technique

Decision engine for converting a confirmed memory-corruption primitive into reproducible, mitigation-aware controlled impact. Finding the bug is upstream (reversing-technique, fuzzing-technique, source-review-technique); this technique decides how to weaponize it, which strategy fits the mitigation set, and what proves it. Concrete per-technique recipes live in offensive-ctf/pwn-ctf/references; primitive-construction depth lives in offensive-coding/*-dev. This skill is the methodology that routes between them.

When this technique applies

• You control PC/return target/indirect call target, or can corrupt heap metadata, an object/vtable pointer, or an allocator-linked structure.
• You have an attacker-influenced crash and must separate "crash only" from "exploitable under constraints".
• You need a mitigation-aware plan before investing in a chain.

If you do not yet have a repeatable, attacker-influenced primitive, stay in bug discovery and improve primitive quality first.

Boundary

• Input: a confirmed primitive from reversing-technique (crash/RE), fuzzing-technique (repro), or source-review-technique.
• Output: a reproducible impact proof; hand a stable session to post-exploit-technique.
• Not here: CVE/PoC initial access on services/web -> vuln-exploit-technique; static/dynamic analysis and crash discovery -> reversing-technique; writing the primitive at code depth (allocator internals, gadget policy, FILE structs, shellcode bytes) -> offensive-coding/*-dev; CTF-scoped triage/time-boxing -> offensive-ctf/pwn-ctf.

Primitive qualification