pwn-chain

ACTION REQUIRED（読了後すぐに実行）

1. NOW: ../field-journal/precedent-reverse.md を読み込む — 本 skill の操作がすでに承認された定常操作であることを確認する
2. NOW: 現在のタスクが本 skill の適用範囲に該当するか確認する
3. NEXT: ../tool-index.md を読み込み、ツールの可用性と実際のパスを検証する
4. NEXT: ツールが不足している場合は bootstrap を呼び出し、パスを推測しない
5. ACT: 「ワークフロー」の最初のステップに進んで実行し、確認状態で止まらない

脆弱性ポイントから Working Exploit まで (Pwn Chain)

適用範囲

タスクが以下のシナリオに該当する場合に本 skill を使用します：

1. バイナリ + 既知の脆弱性ポイントを入手済み — 静的/監査/fuzz ですでにオーバーフロー/UAF/double free を発見しており、トリガーから shell 取得までが必要
2. CTF 問題はローカルでは通ったが、リモートで通らない — リモート環境の差異によりスクリプトが機能しなくなり、安定化が必要
3. 実ターゲットのバイナリエクスプロイト — SRC / レッドチームのシナリオで、メモリ破壊脆弱性をすでに特定しており、RCE を構築する必要がある
4. Linux カーネルドライバの ioctl bug — ユーザー空間からトリガーし、目標は root への権限昇格

前提：あなたはすでに「どこが壊れたか」を知っています。本 skill は脆弱性の発見（それは fuzzing / 監査）を担当せず、「脆弱性ポイントから exploit を書くこと」のみを担当します。

他の skill との分担

シナリオ	使用するもの
custom VM / anti-debug / 複雑な obfuscation の識別	reverse-engineering/
ゼロからバイナリを開いて静的解析を行う	ida-reverse/ または radare2/
脆弱性ポイントがあり、exploit を書いてリモートを打通する	本 skill
pwn で取得した shell を完全な攻撃チェーンに統合する	attack-chain/（下流）

reverse-engineering/ は「プログラムが何をしているかを理解する」こと（パターン認識、プロトコル復元、CTF 問題の奇妙なメカニズムの解析）に注目し、本 skill は「すでに理解した脆弱性を実行可能な攻撃に変える」ことに注目します。両者はしばしばセットで使用されますが、分担は明確です。

コアワークフロー

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%

典型的なシナリオ

シナリオ 1：リモート 64 ビットバイナリ (NX+PIE+canary, libc 提供あり)

已有：./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 修栈对齐（关键！）

完全なテンプレートは references/stack-pwn.md を参照してください。

シナリオ 2：Linux カーネルドライバ ioctl 境界外書き込み → 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

完全なテンプレートは references/kernel-pwn.md を参照してください。

オンデマンド自举 (On-Demand Bootstrap)

ツール依存関係

ツール	用途	インストール方法
pwntools	exploit 作成フレームワーク	pip install pwntools
GEF	gdb 拡張（カーネル + ユーザー空間で推奨）	git clone https://github.com/bata24/gef (fork が活発にメンテナンス)
pwndbg	gdb 拡張（ヒープデバッグ体験が最高）	git clone https://github.com/pwndbg/pwndbg && ./setup.sh
ROPgadget	gadget 検索	pip install ropgadget
Ropper	gadget 検索（代替、対応アーキテクチャが多い）	pip install ropper
one_gadget	libc magic gadget 検索	gem install one_gadget（ruby が必要）
libc-database	libc フィンガープリント逆引き	git clone https://github.com/niklasb/libc-database && ./get
qemu-system-x86_64	カーネル問題のデバッグ	apt install qemu-system-x86
binwalk / cpio	initramfs の展開	apt install binwalk cpio
patchelf	libc バージョンの切り替え	apt install patchelf

Bootstrap チェックスクリプト

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

同一ツールの自動インストールが 2 回失敗した後

再試行を停止し、構造化された手動インストール手順（pip ソース / gem ソース / git 国内ミラー / apt ソース）を出力してユーザーに確認を求めます。

ルーティングコンテキスト

上流エントリ: skills/SKILL.md（総合管理）、routing.md トリガー条件: バイナリ + 脆弱性ポイントを特定済みで、exploit を書く必要がある

上流 skill（先にこれらを使用してから本 skill に戻る）:

• バイナリが何をしているかまだ理解できていない → reverse-engineering/
• 静的な詳細分析が必要 → ida-reverse/
• 迅速な偵察でアーキテクチャ/保護機構を確認 → radare2/

下流 skill（shell 取得後）:

• 完全な攻撃チェーンへの統合（横展開、権限昇格、永続化）→ attack-chain/

サブモジュールナビゲーション:

• スタック系エクスプロイト（ret2libc / ret2csu / one_gadget / スタックアライメント）→ references/stack-pwn.md
• ヒープ系エクスプロイト（tcache / fastbin / unsorted / large bin / FILE struct）→ references/heap-pwn.md
• カーネル pwn（kROP / SMEP-SMAP バイパス / KASLR leak / modprobe_path）→ references/kernel-pwn.md

注意事項

• ローカルで通ったからといって完了としない — ローカルの libc / ASLR / ネットワーク環境はリモートと異なるため、remote モードで 20 回以上連続実行して安定性を検証する必要があります
• libc バージョンは必ず確認する — leak + libc-database で逆引きし、Ubuntu 22.04 デフォルトの libc と仮定しない
• スタックアライメントは 64 ビットの一般的な落とし穴 — movaps xmm0, [rsp] は rsp が 16 バイトアライメントでないとセグメンテーション違反になるため、空の ret gadget を 1 つ追加して解決します
• ヒープエクスプロイトは glibc バージョンに極めて敏感 — tcache は 2.27 で導入、safe-linking は 2.32 で導入、2.34 で hooks が削除され、各バージョンでエクスプロイトのパスが異なります
• カーネル pwn はまず cpu フラグを確認する — qemu 起動パラメータに +smep +smap +pku があるかどうかが ROP チェーンの書き方を直接左右します
• KASLR leak は 1 回で十分 — カーネルアドレスを 1 つ取得すれば、すべてのアドレスはオフセットで計算できるため、繰り返し leak しない

タスク完了自検（完了を主張する前に MUST 通過）

• ワークフロー内の各ステップを（読むだけでなく）実行しましたか？
• tool-index に基づいて実際のツールパスを使用しましたか？
• 再現可能な証拠（コマンド/スクリプト/スクリーンショット/レポート）を産出しましたか？
• RULES が要求する Checklist 項目を完了し、書き戻しましたか？