# 870 Exploit 7ba88d2e

> 870 Exploit 7ba88d2e

- Skill: `tools-only/870-exploit-7ba88d2e` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add tools-only/870-exploit-7ba88d2e`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tools-only/870-exploit-7ba88d2e/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: tools-only (https://skillmd.com/u/tools-only)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/tools-only/870-exploit-7ba88d2e

---

# /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:**
```bash
/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.**

```python
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:

```python
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.