Exploit Writer

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

{
  "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

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.