> ## Documentation Index
> Fetch the complete documentation index at: https://mintlify.com/gadievron/raptor/llms.txt
> Use this file to discover all available pages before exploring further.

# /exploit

> Generate exploit proof-of-concepts for vulnerabilities

<Warning>
  This command is in **beta**. Exploits are for educational and authorized security research only.
</Warning>

## Overview

The `/exploit` command generates working proof-of-concept exploit code for identified vulnerabilities. It analyzes findings and creates executable exploits in Python, C, or using pwntools.

## Syntax

```bash theme={null}
python3 raptor.py agentic --repo <path> --sarif <sarif-file> --no-patches [options]
```

## Parameters

<ParamField path="repo" type="string" required>
  Absolute path to the code repository
</ParamField>

<ParamField path="sarif" type="string">
  SARIF file from previous scan (optional if scanning first)
</ParamField>

<ParamField path="no-patches" type="boolean">
  Skip patch generation (exploit generation only)
</ParamField>

<ParamField path="max-findings" type="integer">
  Maximum number of exploits to generate
</ParamField>

## Prerequisites

### MANDATORY: Run Feasibility Analysis First

<Warning>
  **You MUST run exploit feasibility analysis before ANY exploit development.**

  This analysis identifies constraints that make exploitation impossible. Skipping this step wastes hours on approaches that cannot work.
</Warning>

```python theme={null}
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(f"[!] After context compaction, reload with: print_exploit_context('{context_file}')\n")

# Display the analysis
print(print_exploit_context(context_file))
```

### Why Not Use checksec/readelf?

The feasibility 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

### Context Persistence

The analysis survives context compaction. After long conversations:

```python theme={null}
from packages.exploit_feasibility import print_exploit_context, load_exploit_context

# Reload after compaction
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')
```

## Workflow

### Step 1: Find Vulnerabilities

```bash theme={null}
/scan /path/to/code
```

### Step 2: Run Feasibility Analysis

```python theme={null}
from packages.exploit_feasibility import save_exploit_context
context_file = save_exploit_context('/path/to/binary')
```

### Step 3: Generate Exploits

```bash theme={null}
/exploit
```

## Mitigation Analysis

The feasibility analysis provides authoritative information about what works:

### Check the Verdict

* **Likely exploitable**: Clear path to code execution
* **Difficult**: Primitives exist but hard to chain
* **Unlikely**: No known path with current mitigations

### Read the Chain Breaks

These tell you exactly which techniques are **blocked**:

* "%n format specifier disabled" → Don't suggest format string writes
* "Full RELRO" → Don't suggest GOT overwrites **OR** .fini\_array overwrites
* "hooks removed" → Don't suggest \_\_malloc\_hook/\_\_free\_hook overwrites

### Follow Suggested Paths

* Check "alternative\_targets" for viable write targets
* Read "what\_would\_help" for next steps
* Use "Reality check" for honest assessment

<Info>
  **Full RELRO blocks BOTH GOT and .fini\_array**. Standard linker scripts place them in the same RELRO segment. Don't waste time on .fini\_array writes when Full RELRO is enabled.
</Info>

## Output Structure

When presenting exploitation strategy:

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

## Always Offer Next Steps

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

### For "Difficult" Verdict:

* Try alternative targets from the analysis (verify they're 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

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

## Examples

### Generate Exploits for All Findings

```bash theme={null}
python3 raptor.py agentic --repo /path/to/code --no-patches
```

Generates exploits for all discovered vulnerabilities.

### Generate Limited Exploits

```bash theme={null}
python3 raptor.py agentic --repo /path/to/code --no-patches --max-findings 5
```

Generates exploits for the first 5 findings.

### From Existing SARIF

```bash theme={null}
python3 raptor.py agentic --repo /path/to/code --sarif findings.sarif --no-patches
```

Generates exploits from previous scan results.

## Generated Exploit Types

### Python Exploits

```python theme={null}
# exploit-001-sqli.py
import requests

payload = "admin' OR '1'='1-- "
response = requests.post(
    'http://target/login',
    data={'username': payload, 'password': 'x'}
)
print(f"Status: {response.status_code}")
```

### C Exploits

```c theme={null}
// exploit-002-bof.c
#include <stdio.h>
#include <string.h>

int main() {
    char payload[256];
    memset(payload, 'A', 200);
    // ... overflow logic
}
```

### Pwntools Exploits

```python theme={null}
# exploit-003-rop.py
from pwn import *

p = process('./vulnerable')
payload = flat([
    b'A' * 72,
    0xdeadbeef  # RIP control
])
p.sendline(payload)
```

## Output Directory

```
out/agentic_<timestamp>/exploits/
├── exploit-001-sqli.py
├── exploit-002-bof.c
├── exploit-003-rop.py
├── exploit-004-fmt.py
├── README.md
└── feasibility-analysis.json
```

## Use Cases

* Security research and analysis
* Proof-of-concept development
* Vulnerability validation
* Red team operations
* Bug bounty submissions
* Security training and education

## Related Commands

<CardGroup cols={2}>
  <Card title="/scan" href="/api/commands/scan">
    Find vulnerabilities to exploit
  </Card>

  <Card title="/validate" href="/api/commands/validate">
    Validate exploitability before generating exploits
  </Card>

  <Card title="/patch" href="/api/commands/patch">
    Generate patches instead of exploits
  </Card>

  <Card title="/agentic" href="/api/commands/agentic">
    Full workflow including exploit generation
  </Card>
</CardGroup>

## Ethical Usage

<Warning>
  Exploits are for **educational and authorized security research only**.

  * Only test systems you own or have written permission to test
  * Follow responsible disclosure practices
  * Comply with applicable laws and regulations
  * Use for defensive security improvements
</Warning>

## Notes

* Does NOT generate patches (use `/patch` for that)
* Exploits are saved to `out/*/exploits/`
* Nothing is applied to your code
* All exploits require manual review
* Run feasibility analysis first (mandatory)
* Follow mitigation analysis recommendations
* For authorized testing only