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

> Discover how the pwn-chain module in zhaoxuya520/reverse-skill progresses from reverse engineering to exploitation. Transform insights into stable remote exploits with its 8-phase workflow.

- Repository: [ZhaoXu/reverse-skill](https://github.com/zhaoxuya520/reverse-skill)
- Tags: deep-dive
- Published: 2026-08-16

---

**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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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:

```bash
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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/references/stack-pwn.md) for stack overflows
- [`references/heap-pwn.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/references/heap-pwn.md) for heap corruption
- [`references/kernel-pwn.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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:

```bash

# 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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/pwn-chain/SKILL.md) (lines 25-34) ensures these tools are present:

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

```python
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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/SKILL.md) (lines 87-92) and [`docs/ARCHITECTURE.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/docs/ARCHITECTURE.md):

```

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

```

Routing from [`skills/MASTER-ROUTING.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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.