# Exploit Dev

> Use when converting a known crash, UAF, overflow, type confusion, race, or logic flaw into a measured exploit primitive, leak, heap strategy, mitigation-aware PoC, ROP/JOP or shellcode chain, local privilege escalation, and deterministic reliability harness. Routes allocator- and platform-specific work without conflating Windows user mode, Windows kernel, glibc, or Linux kernel; do not use for driver authoring, BYOVD, or multi-host orchestration.

- Skill: `netvar1337/exploit-dev` (Agent Skill)
- Install (CLI): `npx skillmds@latest add netvar1337/exploit-dev`
- Raw SKILL.md: https://api.skillmd.com/api/skills/netvar1337/exploit-dev/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: netvar1337 (https://skillmd.com/u/netvar1337)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/netvar1337/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:

```text
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:

| Axis | Questions that must be answered |
|---|---|
| Address control | Exact address, base+offset, same-slot only, or allocator-selected? |
| Value control | Fully chosen bytes, pointer-derived value, bit flip, increment, or zero? |
| Width/repeatability | 1/2/4/8/N bytes; aligned; one-shot; stable across retries? |
| Lifetime | How long is overlap/stale state valid, and which event ends it? |
| Context | User/kernel, process, namespace, CPU, lock, IRQL, and privilege constraints? |
| Read/leak quality | Object identity, freshness, entropy removed, pointer canonicality, and cross-run stability? |

`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:

| Target allocator | Establish truth | Deep owner |
|---|---|---|
| Windows NT/Segment Heap | `gflags /p`, Application Verifier, `!heap -p -a`, `!heap -triage`, segment-heap metadata on the exact build | `heap-exploitation` |
| glibc ptmalloc/tcache | libc Build ID, `GLIBC_TUNABLES`, Pwndbg `heap`, `bins`, `vis_heap_chunks`, safe-linking state | `heap-exploitation` |
| Windows kernel pool | pool type/tag/size, `!pool`, `!poolfind`, Special Pool, LFH/lookaside behavior, HVCI build state | `windows-driver-0day` |
| Linux SLUB/page allocator | kernel config, KASLR, slab cache, freelist hardening/randomization, KASAN/KFENCE, namespaces | `linux-kernel-exploitation` |

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:

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

```bash
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

| Task | Tool |
| --- | --- |
| Disassembly / decompilation | IDA Pro, Ghidra, Binary Ninja |
| Kernel debugging | WinDbg (kd), QEMU + GDB |
| Dynamic tracing | Intel Pin, DynamoRIO, Frida |
| Fuzzing | AFL++, libFuzzer, kAFL, syzkaller |
| Heap analysis | heap-view (WinDbg), `!pool`, `!poolval` |
| ROP gadget search | ROPgadget, rp++, mona |
| Shellcode assembly | NASM, Keystone, custom assembler |

## 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