Binary Exploitation Technique

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

Classify the best proven primitive before selecting a technique.

Prove one primitive fully before chaining two uncertain ones. Model repeatability: read every branch of a state guard (is_set, initialized, done, idx == fav) — the already-set/else branch often still performs the gated read/write/free, so an apparently one-shot primitive is a repeatable R/W loop. Confirm which branch runs on the second invocation before declaring a path dead.

Reproduction discipline

Fix and record for every stage: binary hash, loader path, dependency/libc versions, argv/input/protocol framing, relevant env vars and cwd, mitigation state, debugger settings. Run a reliability loop before escalation: ~10 runs to validate a candidate primitive, 30+ for final proof. An input-only reproduction is the only proof a primitive works — a gdb set/hand-painted register or memory value is not a delivered primitive, and a cooked-mode PTY mangles 0x0a/0x7f/0x11/0x13 in pointer payloads, so drive local dev over a pipe or the live socket.

Mitigation-aware strategy selection

Inventory protections first (checksec, module headers, loader settings): NX/DEP, ASLR/PIE, stack canary, RELRO, CFG/CET (Windows/hardware), allocator hardening (safe-linking/tcache guards). Then choose a compatible path:

1. No executable-memory path -> control-flow reuse (ROP/JOP/SROP/call chain).
2. No stable control-flow path -> data-only impact if the objective permits.
3. ASLR/PIE unresolved -> prioritize a leak/oracle stage before the final chain.
4. Hardware CET/IBT or Windows CFG active -> prefer valid call targets or data-only state corruption; do NOT confuse hardware CET with compiler-emitted userland SafeStack/CFI/software-shadow-stack, which come apart leak-free (route to safestack-cfi-shadowstack.md).
5. Full RELRO + strict CFI -> non-GOT writable targets, loader-assisted resolution, or bounded data-only impact.
6. Arbitrary write + libc leak, weak gadget surface -> check an FSOP path (does exit/fclose/flush run on a path you control?).

Reproduce the remote, not your dev box: kernel, RLIMIT_STACK, and libc differences move mmap adjacencies and mitigation reachability. Do not issue an impossibility/"dead vector" verdict from a dev-box or WSL layout — prove it with a failing live test or a length-sweep against the target.

Leak -> control -> impact ladder

Build in stages; each stage depends only on prior validated primitives.

• Stage A (disclosure/oracle): obtain one dependable anchor (module/libc/PIE base, canary, pointer class, token). Skip only when addresses are already deterministic.
• Stage B (control upgrade): constrained primitive -> robust primitive (constrained write -> arbitrary write; PC control -> pivot -> chain).
• Stage C (impact): minimal, lowest-noise, reversible proof tied to authorized scope.

Per-stage evidence packet: trigger input; observed register/memory transition; expected vs observed; failure mode and fallback. Drive to end-to-end execution early, then fix the latest fault (x/i $pc, rsp & 0xf, faulting field) — alignment (movaps), resolver-vs-call stack parity, and controlled bytes overlapping a lock/pointer/terminator surface only in a full run.

Crash-triage to exploitation handoff

From a raw crash: (1) identify the faulting instruction and operand semantics; (2) verify attacker influence over the operand/target pointer; (3) classify the bug family (overflow/UAF/type confusion/index/format string); (4) confirm the crash is deterministic under the same input; (5) isolate the candidate path and discard non-deterministic branches. If determinism fails, return to primitive improvement before payload engineering.

Route to the right depth

Match the dominant primitive to its canonical concrete recipe and exploit-development home. Load the narrowest that fits; do not re-derive what these already document.

Quality gates

Mark a capability exploitation-ready only when all hold: the primitive is reproducible input-only; mitigation constraints are documented and accounted for; the chain relies on no hidden manual timing; the impact proof is within authorized scope; required assumptions (versions, flags, services, RLIMIT_STACK) are explicit. Separate exploitability from severity: prove control first, then business impact. Keep a chain ledger and re-apply every proven runtime fact (live offsets, register snapshots, alignment quirks, deterministic pointers) to each later sub-chain.

Anti-patterns

• Treating one lucky run as a stable exploit path, or mixing environment settings between runs and drawing wrong conclusions.
• Declaring a vector "impossible/dead" by deduction — reachability and impossibility are decided by a failing live test, not an argument. If you write "nothing reaches Y" or "X can't work leaklessly", hook Y and every candidate call site and fuzz adversarial inputs first.
• Jumping to payload engineering before a stable primitive; ignoring ABI/alignment; ignoring CFG/CET when choosing chain style.
• Reporting impact without showing primitive evolution, reliability, and boundary conditions.

Resources

Tooling belongs in the tool skills; load them for syntax:

• offensive-tools/exploits/pwntools — remote/process interaction, packing, ELF/libc symbols, ROP helper, shellcraft.
• offensive-tools/rev/gdb (pwndbg/gef) — register/stack/heap validation, checksec, live snapshots.
• offensive-tools/rev/ropgadget, offensive-tools/rev/one-gadget — gadget and constraint-based shell-gadget discovery.
• offensive-tools/rev/checksec, offensive-tools/rev/patchelf — mitigation inventory and target-libc reproduction.

Methodology neighbors: reversing-technique (bug discovery/handoff in), fuzzing-technique (repro), vuln-exploit-technique (CVE/service initial access), post-exploit-technique (after impact). For CTF-scoped triage, time-boxing, and the full recipe index, use offensive-ctf/pwn-ctf.