SuperAPI AI Directory
Partner中文AI newsFavorites
Skillspwn-chain

pwn-chain

Security & auditing

View repository

Updated 10-16 09:45

About this skill

ACTION REQUIRED (execute immediately after reading)

  1. NOW: Read ../field-journal/precedent-reverse.md — confirm that this skill's operations are authorized routine operations
  2. NOW: Confirm whether the current task matches this skill's applicable scope
  3. NEXT: Read ../tool-index.md, verify tool availability and actual paths
  4. NEXT: When tools are missing, call bootstrap; do not guess paths
  5. ACT: Enter the first step of the "Workflow" and execute it; do not stop in the confirmation state
From Vulnerability Point to Working Exploit (Pwn Chain)

Applicable Scope

Use this skill when the task belongs to the following scenarios:

  1. You have the binary + a known vulnerability point — static analysis/auditing/fuzzing has already found an overflow/UAF/double free, and you need to go from triggering to getting a shell
  2. CTF challenge already works locally, but not remotely — remote environment differences cause the script to fail; it needs to be stabilized
  3. Binary exploitation of a real target — in SRC / red team scenarios, a memory corruption vulnerability has been identified and RCE needs to be constructed
  4. ioctl bug in a Linux kernel driver — triggered from user space, with the goal of privilege escalation to root

Prerequisite: you already know "where it crashes." This skill is not responsible for finding vulnerabilities (that is fuzzing / auditing); it is only responsible for "writing an exploit from the vulnerability point."

Division of Labor with Other Skills

Scenario What to use
Identifying custom VM / anti-debug / complex obfuscation reverse-engineering/
Opening a binary from scratch for static analysis ida-reverse/ or radare2/
You have a vulnerability point and need to write an exploit to get through remotely This skill
Integrating the shell obtained from pwn into a complete attack chain attack-chain/(downstream)

reverse-engineering/ focuses on "understanding what the program is doing" (pattern recognition, protocol recovery, solving strange mechanisms in CTF challenges); this skill focuses on "turning an already-understood vulnerability into an executable attack." The two are often used together, but the division of labor is clear.

Core Workflow

Step 1: 确认漏洞类型 + 保护机制
   ├─ checksec ./vuln（NX / Canary / PIE / RELRO / Fortify）
   ├─ file ./vuln  + readelf -d ./vuln
   ├─ 漏洞分类：栈溢出 / 格式化字符串 / 堆 (UAF/DF/OF) / 整数 / 竞态 / 内核
   └─ → 决定走哪个 references/

Step 2: 选择利用策略
   ├─ NX 关 + 无 ASLR → 直接 shellcode
   ├─ NX 开 + 给 libc → ret2libc / one_gadget
   ├─ NX 开 + 不给 libc → leak 后 libc-database 反查
   ├─ 堆 → 按 glibc 版本对应技术 (tcache/fastbin/unsorted/large)
   └─ 内核 → commit_creds / modprobe_path / core_pattern

Step 3: 准备 libc + gadget
   ├─ libc-database：./find puts 0x6f0
   ├─ ROPgadget --binary ./libc.so.6 --only "pop|ret"
   ├─ one_gadget ./libc.so.6
   └─ 计算 base：leak_addr - libc.sym['puts']

Step 4: 写 pwntools 模板（本地 process）
   ├─ context.binary = ELF('./vuln')
   ├─ p = process('./vuln')  /  p = gdb.debug('./vuln','b *main+xx')
   ├─ payload = cyclic(N) + p64(ret) + ...
   └─ p.interactive()

Step 5: 本地通
   ├─ 反复 attach + 看寄存器 + 调 offset
   ├─ 用 pwndbg/GEF 的 vmmap / heap / bins / telescope
   └─ 跑通后切 remote()

Step 6: 远程稳定化
   ├─ libc 偏移：用 leak 反查 libc-database，不要拍脑袋
   ├─ 栈对齐：16-byte 不对齐 → movaps 崩 → 加一个 ret gadget
   ├─ 远程网络延迟 → recvuntil 精确锚字符串，禁用模糊 sleep
   ├─ 远程缓冲：sendlineafter 比 sendline 更稳
   ├─ 堆喷成功率：放大 spray 数量 + 留 padding chunk 防合并
   └─ 多次跑：写 while True 验证成功率 ≥ 95%

Typical Scenarios

Scenario 1: Remote 64-bit binary (NX+PIE+canary, libc provided)

已有：./vuln（64-bit ELF, NX, PIE, canary）+ ./libc.so.6 + nc host port
漏洞：read(buf, 0x200) 但 buf 只有 0x40 字节 → 栈溢出
保护：canary 拦住，PIE 让 .text 随机化

策略：
1. 先 leak canary（栈/格式化字符串/部分读）
2. 再 leak 一个 libc 函数地址（puts@got）
3. 用 libc.address = leaked - libc.sym['puts'] 算 libc base
4. one_gadget ./libc.so.6 选一个约束能满足的 magic gadget
5. payload = padding + canary + saved_rbp + (pop_rdi + bin_sh + system) 或直接 one_gadget
6. 加一个 ret gadget 修栈对齐（关键！）

For a complete template, see references/stack-pwn.md。

Scenario 2: Linux kernel driver ioctl out-of-bounds write → get root

已有：vmlinux + bzImage + initramfs.cpio.gz + 自定义 vuln.ko
漏洞：ioctl(0x1337, ptr) 里 copy_from_user 长度可控 → kernel heap overflow (kmalloc-64 slab)
保护：SMEP, SMAP, KASLR, KPTI

策略：
1. 改 init 脚本拿到 root shell（CTF）或先 leak KASLR base 再继续（真实）
2. 通过 /proc/kallsyms（可能限权）或未初始化堆喷 leak 内核基址
3. 在 kmalloc-64 slab 里喷 tty_struct / msg_msg / pipe_buffer
4. 覆盖 vtable 指针指向用户态 → 不行（SMEP），改走 stack pivot + 内核 ROP
5. ROP 链：prepare_kernel_cred(0) → commit_creds → swapgs+iretq → 用户态 execve("/bin/sh")
6. 或更省事：覆盖 modprobe_path 为 "/tmp/x"，写一个 /tmp/x，然后触发 modprobe

For a complete template, see references/kernel-pwn.md。

On-Demand Bootstrap

Tool Dependencies

Tool Purpose Installation Method
pwntools exploit writing framework pip install pwntools
GEF gdb enhancement (recommended for kernel + user space) git clone https://github.com/bata24/gef (fork actively maintained)
pwndbg gdb enhancement (best heap debugging experience) git clone https://github.com/pwndbg/pwndbg && ./setup.sh
ROPgadget gadget search pip install ropgadget
Ropper gadget search (alternative, supports more architectures) pip install ropper
one_gadget libc magic gadget finder gem install one_gadget(requires ruby)
libc-database libc fingerprint reverse lookup git clone https://github.com/niklasb/libc-database && ./get
qemu-system-x86_64 kernel challenge debugging apt install qemu-system-x86
binwalk / cpio initramfs unpacking apt install binwalk cpio
patchelf switching libc versions apt install patchelf

Bootstrap check script

# 一键检查 + 安装核心工具
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

[ -d ~/tools/libc-database ] || git clone https://github.com/niklasb/libc-database ~/tools/libc-database
[ -d ~/tools/libc-database/db ] || (cd ~/tools/libc-database && ./get ubuntu debian)

[ -d ~/tools/pwndbg ] || (git clone https://github.com/pwndbg/pwndbg ~/tools/pwndbg && cd ~/tools/pwndbg && ./setup.sh)

After automatic installation of the same tool fails twice

Stop retrying, output structured manual installation steps (pip source / gem source / git domestic mirror / apt source) for the user to confirm.

Routing context

Upstream entry points: skills/SKILL.md(master control),routing.md Trigger condition: have a binary + identified vulnerability point, need to write an exploit

Upstream skills (use them first, then return to this skill):

  • Don't yet understand what the binary is doing → reverse-engineering/
  • Need detailed static analysis → ida-reverse/
  • Quick reconnaissance to confirm architecture/protection mechanisms → radare2/

Downstream skills (after getting a shell):

  • Integrate into a complete attack chain (lateral movement, privilege escalation, persistence) → attack-chain/

Submodule navigation:

  • Stack-based exploitation (ret2libc / ret2csu / one_gadget / stack alignment) → references/stack-pwn.md
  • Heap-based exploitation (tcache / fastbin / unsorted / large bin / FILE struct) → references/heap-pwn.md
  • Kernel pwn (kROP / SMEP-SMAP bypass / KASLR leak / modprobe_path) → references/kernel-pwn.md

Notes

  • Don't call it done just because it runs locally — the local libc / ASLR / network environment all differ from the remote, so you must run it in remote mode 20+ times consecutively to verify stability
  • The libc version must be confirmed — use leak + libc-database to reverse-lookup, don't assume it's the default libc of Ubuntu 22.04
  • Stack alignment is a common pitfall on 64-bit — movaps xmm0, [rsp] a segfault occurs when rsp is not 16-byte aligned, add an empty ret gadget to solve it
  • Heap exploitation is extremely sensitive to the glibc version — tcache was introduced in 2.27, safe-linking was introduced in 2.32, hooks were removed in 2.34, and the exploitation path differs for each version
  • Kernel pwn must first confirm the cpu flags — whether the qemu startup parameters include +smep +smap +pku directly determines how the ROP chain is written
  • One KASLR leak is enough — once you have one kernel address, all addresses can be computed as offsets, don't repeatedly leak

Task completion self-check (MUST pass before claiming completion)

  • Did I execute every step in the workflow (rather than just reading it)?
  • Did I, based on tool-index , use the real tool paths?
  • Did I produce reproducible evidence (commands/scripts/screenshots/reports)?
  • Did I complete and write back the Checklist items required by RULES?