mem-exploitability

name	mem-exploitability
description	Memory-corruption exploitability ASSESSMENT. For each memory-safety finding (systems-hunt / verify), the mem-exploit-analyst agent works the analysis phases — vuln shape, control/offset plausibility, input constraints, mitigation posture (NX/PIE/canary/RELRO/FORTIFY/CFG from build flags + read-only binary inspection) — and assigns an exploitability tier + remediation, attaching an `exploitability` block onto .kuzushi/findings.json. Assessment only — never produces exploit payloads or mitigation bypasses.
context	fork
agent	mem-exploit-analyst
user-invocable	false

Memory-corruption exploitability assessment

Assess how exploitable the repo's memory-safety findings are. Requires memory-corruption findings in .kuzushi/findings.json first — run /systems-hunt (native / memory-safety review) or /verify to populate them.

Assessment only. This produces exploitability tiers + mitigation posture + remediation. It does not generate shellcode, ROP/JOP chains, DEP/ASLR/canary/RELRO/CFG bypasses, or any working hijack payload. Empirical crash proof is /poc (gated sandbox).

1. Run node "${CLAUDE_PLUGIN_ROOT}/scripts/cmd/mem-exploitability-prepare.mjs" --target "<repo root>" (optionally --input '{"maxCandidates":12}'). It errors if there are no memory-corruption findings. Read the prep's prepPath — candidates[] and the repo mitigations posture.
2. For each candidate, do the per-candidate walk (vuln shape → control/offset plausibility → constraints → mitigation factor → tier + remediation). Use each candidate's findingFingerprint verbatim. Reason about control; never construct an overwrite or payload.
3. Write the { candidates: [...] } bundle to the prep's draftPath, then run the assembleCommand (finalize) — it validates tiers + remediation and attaches an exploitability block onto each finding (status unchanged).
4. Report tier counts, the repo mitigation posture, and the likely-code-exec / control-flow-hijack-plausible findings. Point to /poc for empirical crash proof.

When NOT to use

• On non-memory findings (injection, authz, SSRF…) — those don't have a memory-corruption tier.
• Before any memory-safety finding exists — run /systems-hunt (or /verify) first.
• To produce a working exploit — out of scope by design; this is assessment only. Empirical crash proof is /poc.

Rationalizations to Reject

• "It's a memory bug, so it's likely-code-exec." → Tier by the actual control/offset plausibility and mitigation posture; many overflows are crash-only or dos, not code-exec.
• "Mitigations are on, so it's not exploitable." → Record the mitigation posture as a factor, not a verdict; NX/PIE/canary raise the bar, they don't always close it.
• "I'll sketch a quick ROP chain to prove it." → Never. Reason about control; do not construct overwrites, payloads, or bypasses.