Exploit Development Workflow

From Crash to Proof

Everything in this module — stack layout, shellcode, DEP/ASLR/canaries, ROP — feeds into one repeatable workflow. A crash is the starting question, not the answer; most crashes are just crashes. The work is figuring out which ones are something more.

The Workflow

crash triage  ->  root cause  ->  primitive  ->  weaponization

1. Crash triage — a fuzzer, a malformed input, or a bug report produces a fault. First question: is it reproducible, and where does it fault? A crash at a garbage RIP (see e3) is far more interesting than a null-pointer read.
2. Root cause — trace the crash back to the actual bug: which function, which write, why is it unbounded. This is the same disassembly-reading skill from e1 — find the sub rsp, the lea, the unchecked copy.
3. Primitive — determine exactly what the bug lets you do: how many bytes you control, at what offset, with what values. Not every overflow gives you a clean write-what-where; some only let you flip a few bounded bytes, or overwrite one specific field. The primitive is the honest answer to “what can I actually make this program do.”
4. Weaponization — turn the primitive into reliable control flow, accounting for whatever mitigations are active: build the offset math, plan around a canary or route around it, chain gadgets if DEP is on (e4), and account for ASLR with a leak if it’s on.

Crash vs. Primitive

A crash proves a bug exists. It does not prove the bug is exploitable. The gap between the two is the entire point of steps 2 and 3: a SIGSEGV from writing 4 extra bytes past a buffer that lands in unmapped memory is a bug worth fixing, but it may not hand you return-address control at all. A controllable primitive means you know precisely which bytes you influence, where they land, and that the corrupted value is something the program will act on — a return address, a function pointer, a length field. Most reported crashes never clear this bar; the ones that do are the ones worth writing a full proof-of-concept for.

Why This Stays Defensive

A working proof-of-concept exists to answer one question for the people who own the software: is this bug exploitable, and does the fix actually close it. That’s the same reason lab-19 hands you a disassembled function to analyze rather than a target to attack — the value is in the analysis, not in a payload aimed at something you don’t control. Writing and running exploit code against systems you don’t own or don’t have explicit authorization to test is illegal in most jurisdictions and outside the scope of this material, exactly as framed on the About page: everything here applies only to software you own or are authorized to analyze, for patching, research, and defense.

Tying the Module Together

Each lesson here maps onto a defense you now know how to reason about: the offset math in e1 is what a canary is positioned to catch; the shellcode constraints in e2 are what DEP makes irrelevant; e3’s three mitigations are the actual obstacles a real weaponization step has to clear; and e4’s gadget chains are the direct consequence of DEP forcing attackers off the stack and into the binary’s own code. Exploit development isn’t a bag of tricks — it’s this workflow, applied with an accurate model of exactly which defenses are standing in the way.

Takeaway

A crash is a question; root cause, primitive, and weaponization are how you answer it — and the answer only matters when it’s used to fix something, not to break it.