Exploit Writer

---
name: exploit-writer
description: Build reproducible exploit procedures from validated primitives with clear prerequisites, verification criteria, and safety boundaries.
---

# Exploit Writer

## Purpose
Transform confirmed primitives into reproducible proof-of-exploit artifacts and stepwise execution plans.

## Inputs
- `validated_primitive`
- `target_context`
- `environment_constraints`
- `success_criteria`

## Workflow
### Phase 1: Objective and Boundaries
1. Define exploit goal (data read, privilege gain, state change).
2. Define explicit stop condition.
3. Define prohibited actions and safety constraints.

### Phase 2: Chain Design
1. Break exploit into stages:
- setup
- trigger
- control gain
- impact verification
2. Include fallback branches for unstable stages.

### Phase 3: Procedure Authoring
1. Write deterministic steps with required inputs.
2. Include expected output per step.
3. Include failure diagnostics per step.

### Phase 4: Robustness Checks
1. Re-run in fresh session/environment.
2. Validate whether exploit is deterministic or probabilistic.
3. Capture conditions that break reliability.

### Phase 5: Reporting Package
1. Provide concise replay instructions.
2. Provide artifact index.
3. Provide impact statement tied to observed behavior.

## Exploit Procedure Template
- Preconditions
- Setup commands/actions
- Trigger sequence
- Verification checks
- Cleanup and rollback
- Failure troubleshooting

## Output Contract
```json
{
  "exploit_plan": [],
  "stepwise_procedure": [],
  "success_signals": [],
  "failure_diagnostics": [],
  "safety_notes": []
}
```

## Constraints
- Build only from validated primitives.
- Do not fabricate impact or reliability.

## Quality Checklist
- [ ] Another tester can replay from instructions.
- [ ] Preconditions are explicit.
- [ ] Impact claim matches observed result.

## Detailed Operator Notes
### Validation Discipline
- Confirm static assumptions with targeted runtime checks.
- Keep one controlled input per hypothesis.
- Separate symbol-level hints from observed behavior.

### Exploitability Heuristics
- Control quality over corrupted bytes/pointers.
- Trigger repeatability across process restarts.
- Mitigation interaction required for practical exploitation.

### Common Blind Spots
- Architecture-specific undefined behavior differences.
- Parser edge cases reachable only through nested formats.
- Configuration-dependent code paths not visible in default runs.

### Reporting Rules
- Include prerequisite runtime conditions.
- Include why alternative bug classes were rejected.
- Include a minimal regression-test suggestion for remediation.

## Quick Scenarios
### Scenario A: Control Validation
- Trigger candidate primitive with minimal input.
- Confirm memory/register side effect.
- Repeat across restarts for stability.
- Record constraints that break control.

### Scenario B: Mitigation Interaction
- Confirm active hardening controls.
- Test whether primitive survives mitigations.
- Distinguish crash-only from exploit-capable outcomes.
- Capture bypass requirements if needed.

### Scenario C: Reporting Readiness
- Verify prerequisite environment notes.
- Verify reproduction steps are deterministic.
- Verify impact statement is evidence-bound.
- Verify remediation target is specific.

## Conditional Decision Matrix
| Condition | Action | Evidence Requirement |
|---|---|---|
| Crash reproduces inconsistently | reduce input and isolate triggering fields | minimal trigger artifact |
| Primitive appears but control unclear | instrument memory/register checkpoints | control-surface trace |
| Mitigation blocks direct exploitation | model required bypass preconditions | mitigation interaction notes |
| Parser path uncertain | force parser branch with crafted corpus | branch-selection evidence |
| Static finding lacks runtime proof | add targeted runtime probe before reporting | runtime validation artifact |

## Advanced Coverage Extensions
1. Compare behavior across compiler optimization levels when possible.
2. Check locale/encoding effects on parser and boundary logic.
3. Check integer truncation across 32/64-bit interfaces.
4. Check allocator behavior differences under memory pressure.
5. Check cryptographic error oracles via differential response paths.