exploit - Generate Exploit PoCs (beta)

/exploit - Generate Exploit PoCs (beta)

Generate working exploit proof-of-concepts for vulnerabilities.

Requires: SARIF file from previous /scan, or identified vulnerabilities

What it does:

• Analyzes findings with LLM
• Generates working exploit code (Python, C, pwntools)
• Saves to out/*/exploits/
• Does NOT generate patches (use /patch for that)

Run: python3 raptor.py agentic --repo <path> --sarif <sarif-file> --no-patches --max-findings <N>

Example:

/scan test/                    # First, find vulnerabilities
/exploit                       # Then, generate exploits for findings

MANDATORY: Run Feasibility Analysis First (Persisted)

You MUST run the Python feasibility analysis code below before ANY exploit work. DO NOT use checksec, readelf, or other tools instead - they miss critical constraints.

from packages.exploit_feasibility import save_exploit_context, print_exploit_context

# Run analysis and SAVE to persistent file (survives context compaction)
context_file = save_exploit_context('/path/to/target/binary')
print(f"\n[!] Context saved to: {context_file}")
print("[!] After context compaction, reload with: print_exploit_context('{context_file}')\n")

# Display the analysis
print(print_exploit_context(context_file))

IMPORTANT: Context Persistence The save_exploit_context() function saves critical data to a JSON file that survives context window compaction. If the conversation gets long and context is compacted:

from packages.exploit_feasibility import print_exploit_context, load_exploit_context

# Reload after compaction - use the path printed above
print(print_exploit_context('/path/to/binary_exploit_context.json'))

# Or load as dict for programmatic access
ctx = load_exploit_context('/path/to/binary_exploit_context.json')

This analysis provides information that checksec does NOT:

• Empirical %n verification (does it actually work on this glibc?)
• Null byte constraints from input handlers (strcpy can't write full addresses)
• ROP gadget quality (are there enough gadgets to build a chain?)
• Alternative write targets when GOT/hooks are blocked
• Honest difficulty assessment based on all constraints combined

If you skip this step, you WILL suggest techniques that don't work.

CRITICAL: Follow the Mitigation Analysis

The mitigation analysis output contains authoritative information about what works and what doesn't. You MUST:

1. Check the verdict - Exploitable, Likely exploitable, Difficult, or Unlikely
2. Read the chain breaks - These tell you exactly which techniques are blocked and why
3. Check alternative targets - If standard targets (GOT, hooks) are blocked, look at suggested alternatives
4. Read the "Reality check" - This gives an honest assessment of practical exploitation

DO NOT suggest techniques that are listed as blocked. For example:

• If "%n format specifier disabled" is listed, do NOT suggest format string writes
• If "Full RELRO" is listed, do NOT suggest GOT overwrites OR .fini_array overwrites
• If "hooks removed" is listed, do NOT suggest __malloc_hook/__free_hook overwrites

CRITICAL: Full RELRO typically blocks BOTH GOT and .fini_array (standard linker scripts place them in the same RELRO segment). Many hours have been wasted trying to write to .fini_array when Full RELRO is enabled. The mitigation analysis will NOT list .fini_array as an alternative target if Full RELRO is on.

DO follow the suggested paths. For example:

• If "alternative_targets" lists .fini_array, focus on that approach
• If "what_would_help" suggests an info leak, develop that first
• If verdict is Difficult, explain the challenges honestly to the user

Output Structure

When presenting exploitation strategy:

1. State the verdict from mitigation analysis
2. List what IS possible (from "What you CAN still do")
3. List what is NOT possible (from chain breaks)
4. Propose a path using only viable techniques
5. Always offer next steps (see below)

IMPORTANT: Always Offer Next Steps

Even when verdict is Difficult or Unlikely, offer the user choices:

For Difficult verdict:

• "Try alternative targets from the analysis (check which ones are actually viable)"
• "Focus on info leaks only (useful for chaining with other vulns)"
• "Run in older environment (Docker with Ubuntu 20.04)"
• "Move on to other targets"

NOTE on .fini_array: Full RELRO blocks .fini_array writes (it's in the RELRO segment). Only suggest .fini_array if Full RELRO is NOT enabled. Check the alternative_targets list in the mitigation output - it will only include targets that are actually writable.

For Unlikely verdict:

• "Run in older environment (Docker with Ubuntu 20.04/22.04)"
• "Look for other vulnerability classes in the binary"
• "Focus on DoS/crash demonstration only"
• "Move on to other targets"

Never just stop after saying exploitation is difficult. The user wants to make a decision about how to proceed.

Run: python3 raptor.py agentic --repo <path> --sarif <sarif-file> --no-patches --max-findings <N>

Note: Exploits are for educational/research purposes only.