Exploit Dev

Exploit development workflow

Activation

Use when the task involves vulnerability research, exploit writing, PoC development, shellcode authoring, ROP/JOP chain construction, heap manipulation, or privilege escalation.

Workflow phases

1. Vulnerability analysis

• Identify vuln class: UAF, double-free, overflow (stack/heap), type confusion, integer overflow, race condition, uninitialized memory, logic bug.
• Determine trigger path: syscall, IOCTL, network packet, file parse, IPC.
• Map the vulnerable object: size, pool tag, allocation/free sites, lifetime, references.
• Identify constraints: ASLR, CFG, CET, SMEP/SMAP, KASLR, PatchGuard, HVCI, VBS.

2. Root-cause-to-primitive contract

Do not jump from bug class to “arbitrary R/W.” First write a falsifiable contract:

root cause: allocation/free/copy/refcount and violated invariant
trigger: exact input, thread/process context, and first bad state
control: bytes, address bits, width, alignment, mask, count, and timing
lifetime: first valid use, invalidation event, retries, and cleanup owner
observation: debugger assertion proving each claimed capability
side effects: crashes, allocator damage, locks, reference leaks, or one-shot state

Score the capability before selecting a chain:

NtQuerySystemInformation is an observation API, not an arbitrary-read primitive. Call an output an information leak only when a build-specific information class returns target-useful data to the tested caller and the exploit consumes it; record redaction, required privilege, entropy removed, and freshness.

Place debugger assertions at allocation, free, reclaim, corruption, first dereference, and final use. Useful checks include !heap -p -a <addr>, !heap -triage, !pool <addr>, ba r|w <size> <addr>, GDB watch, allocator traces, KASAN, or verifier logs. Synchronize a race on the exact callback, completion, futex/event, breakpoint, or state transition—never a guessed sleep.

3. Strategy selection

1. Prefer a data-only outcome that satisfies the objective before control-flow hijack.
2. Select a reclaim object only after matching allocator, size class, lifetime, controllable fields, destructor behavior, and target build.
3. Require a leak contract before claiming an ASLR/KASLR bypass; a stale or non-canonical pointer is not sufficient.
4. For Windows kernel targets, route driver root cause and build-specific pool behavior to windows-driver-0day; use this skill to integrate only the proved capabilities.
5. For Linux kernel targets, hand the contract to linux-kernel-exploitation; do not transplant Windows token/EPROCESS assumptions into cred, SLUB, or namespace paths.
6. Choose ROP/JOP/shellcode only after the mitigation decision tree below rules out a simpler and more reliable data-oriented chain.

Allocator and build matrix

Pin executable/module hashes, symbols, OS/libc/kernel build, architecture, allocator mode, hardening, and runtime flags for every row:

A grooming plan records allocation API, exact rounded size/class, CPU/thread affinity, occupancy measurement, reclaim probability, destructor/cleanup, and the assertion proving overlap. An API name or spray count without measured placement is not a plan.

4. Shellcode and payload constraints

• Make position independence and forbidden-byte rules properties of the actual transport/loader, not universal folklore.
• In Windows user mode, a PEB/LDR walk and hashed export resolver are one loader design; validate API-set forwarding, WOW64, loader-lock context, and ACG/CIG before selecting it.
• In kernel mode, do not assume MSR LSTAR reliably identifies the required ntoskrnl image or exported routine. Use build-matched symbols/debugger evidence or documented module-enumeration support, then route driver/payload mechanics to the kernel owner.
• Record payload ABI, stack alignment, unwind/CET behavior, page transitions, entry/exit register state, cleanup, and exact module hashes.

5. ROP/JOP chain contract

For every gadget retain module hash + RVA + bytes + instruction boundary + stack delta + clobbers + memory effects + CFG/XFG/CET/IBT status. Simulate the full chain, then assert each transition in the debugger on the target build. Reject gadgets that cross decoded instructions, depend on unstable private layout, or occur only in a sibling build.

A token, credential, or function-pointer outcome is a separate data-structure contract: prove object identity, reference/fast-reference bits, locks, lifetime, and restoration. A generic token-steal sketch is not evidence that the current primitive or build supports that path.

Modern mitigation decision tree

Inventory first; never infer policy from OS name alone:

Get-ProcessMitigation -Name target.exe
Get-ProcessMitigation -System
dumpbin.exe /headers /loadconfig target.exe

checksec --file=./target
readelf -nW ./target
zgrep -E 'RANDOMIZE_BASE|PAGE_TABLE_ISOLATION|CFI|SHADOW_CALL_STACK' /proc/config.gz

1. CFG/XFG: identify the actual indirect transfer and whether the intended destination is a valid CFG target with a matching XFG signature. One historically useful callback does not generalize across binaries or builds.
2. CET shadow stack / IBT: ordinary return-address overwrite or “return-to-csu” does not bypass shadow-stack validation. Prove shadow-stack state, ENDBR requirements, available non-return control, or choose data-only impact.
3. ACG/CIG: if dynamic code or unsigned image loading is prohibited, VirtualProtect -> shellcode is not a default plan. Measure section/image policy and use only mappings and signers allowed by the tested process.
4. ASLR/KASLR/FG-KASLR: quantify leak entropy and module/object lifetime; validate every base and gadget against the exact image hash.
5. SMEP/SMAP/KPTI/PAN-like policy: prove privilege transition, page-table state, and user-pointer accessibility at the use site; route platform mechanics to the kernel specialist.
6. Compiler CFI and HVCI: recover the call-site type/policy and test a candidate target under the enabled policy. A write primitive alone does not imply executable control.

For each mitigation record present, enabled here, blocks which edge, evidence, and chosen response. Unknown is not equivalent to disabled.

Tooling

Deterministic reliability harness

Separate trigger reliability, primitive reliability, impact reliability, and cleanup. The harness must subscribe to an exact process/debugger/IPC completion signal before triggering; fixed sleeps and polling luck are invalid.

For each of at least 100 fresh-state runs:

1. Restore the named snapshot/container state and verify build/module hashes.
2. Launch under dump/debug/telemetry capture and wait for the explicit ready event.
3. Trigger once with a hash-pinned input and capture allocator assertions.
4. Classify no-trigger, expected-crash, wrong-crash, primitive-proved, impact, hang, or cleanup-failure.
5. Collect dump, register/stack state, heap/pool evidence, mitigation state, and input hash.
6. Close handles, undo changed state, and verify the target can start cleanly before the next run.

Write runs.csv with build, seed, CPU count/affinity, allocator mode, mitigation set, stage outcomes, failure signature, cleanup result, and artifact paths. Report Wilson confidence bounds or raw numerator/denominator; never collapse all stages into one “>90%” claim. Run a negative control with the corrupting field or race edge disabled and require it not to reach the primitive assertion.

Routing

• Batch A: bof-coff-development, windows-rpc-com-attack, windows-telemetry-etw, and hyper-v-offensive.
• Batch B: linux-kernel-exploitation, c2-implant-engineering, ebpf-offensive, and linux-host-post-exploitation.
• Route Windows driver root causes to windows-driver-0day, allocator internals to heap-exploitation, shellcode loaders to offensive-shellcode, and BOF/COFF relocation or loader work to bof-coff-development.
• Route broad discovery to vuln-research/offensive-fuzzing, driver implementation to kernel-dev, BYOVD to byovd, and multi-host objectives to attack-chain.

Verification checklist

• Root cause and crash-to-capability contract have debugger assertions
• Controlled bytes/address/width/lifetime/repeatability and leak quality are measured
• Allocator, build, symbols, mitigations, and grooming evidence are pinned
• Platform objects and escalation assumptions are not conflated
• Negative control disproves the primitive when the corrupting edge is removed
• 100-run matrix separates trigger, primitive, impact, and cleanup outcomes
• PoC is minimized; exploit state is restored or the residual effect is explicit