reverse-skills-max: initial public release (restored, redacted, hardened)
This commit is contained in:
baradok609hecl1pq6qi
1361
vendor-new/rev-skills/docs/audit/2026-09-13-factual-audit.md
Normal file
1361
vendor-new/rev-skills/docs/audit/2026-09-13-factual-audit.md
Normal file
File diff suppressed because it is too large
Load Diff
614
vendor-new/rev-skills/docs/audit/2026-09-30-adjudication.md
Normal file
614
vendor-new/rev-skills/docs/audit/2026-09-30-adjudication.md
Normal file
@@ -0,0 +1,614 @@
|
||||
# 监控报告对账判定表（2026-09-30）
|
||||
|
||||
## 一、由来
|
||||
|
||||
2026-09-12 至 2026-09-29 期间，一份外部对话对本仓库做了持续监控，累计报出 **121 条**报告项
|
||||
（事实性错误与过时内容）。逐条对账结果：**30 条已修**、**91 条未修**。
|
||||
|
||||
本表对其中 95 条（91 条未修 + 5 条用于交叉验证的已修项，按 F 编号去重后 95）做逐条**判定**。
|
||||
注意：判定的不是「修了没」，而是**报告本身对不对**。判定为「报告不成立」的条目**不得进入修复**——
|
||||
照报告去改会把正确内容改错。仓库已有先例（补充 30 驳回 udsoncan `ClientConfig` 报告），本表沿用
|
||||
同样要求：**驳回必须给证据链**。
|
||||
|
||||
## 二、方法
|
||||
|
||||
判定不看报告措辞，只看三类可核验依据：
|
||||
|
||||
1. **本地实测**——能跑的一律跑。clang 22 交叉编译（`--target=armv6m-none-eabi` / `mips-unknown-linux-gnu` /
|
||||
`riscv64-unknown-linux-gnu` / `i386-linux-gnu` / `armv7`）、`qemu-system-x86_64` 与 qemu-user / qemu-mips /
|
||||
qemu-riscv64、gdb `starti`、`openssl s_client -msg`、`apksigner` + `zipalign`、`go doc` 与 `LD_PRELOAD`
|
||||
探针、`pacman -Si`、本机 IDA 9.4 安装目录、`/usr/include/linux/bpf.h`、以及 6 份 `jni.h`（JDK 8/11/17/27、
|
||||
GraalVM 21、Android NDK 30）的声明序解析
|
||||
2. **标准与官方文档原文**——ELF gABI、Apple `loader.h`、dyld 与 XNU 源码、Itanium C++ ABI、
|
||||
AAPCS32/AAPCS64、MIPS32 架构手册、System V x86-64 psABI、SMCCC、RFC 8446 / 7301 / 9293、
|
||||
JNI Specification、ISO 14229、eBPF UAPI、MS PE/COFF 文档、Embarcadero Delphi Language Guide
|
||||
3. **官方元数据与发行页**——PyPI `info.version` / `requires_python`、GitHub `releases.atom`（REST API 常被
|
||||
未认证限流）、Debian `sources.debian.org` 与包文件列表、Fedora Bodhi、Arch 官方仓库
|
||||
|
||||
关键判据：**读代码推断不能替代实跑**。多条判定来自实际构造的样本——为验证「取第一个 `IEND` 定 PNG
|
||||
结尾」，构造了子串 `IEND` 落在 tEXt 载荷内的 PNG；为验证 TCP 不保留消息边界，观察 3 次连续 `send()`
|
||||
在接收端合并为 1 个 chunk；为验证 `RegisterNatives` 槽位，解析了 6 份头文件的声明序。
|
||||
|
||||
统计口径：**按 F 编号计**（同一行常合并多条重复上报，如 F058/F070/F088 是同一处原文）。
|
||||
|
||||
## 三、结论汇总
|
||||
|
||||
| 判定 | 条数 | 含义 |
|
||||
|---|---|---|
|
||||
| 采纳（报告成立） | 70 | 仓库确有该问题，按下述「改法」改 |
|
||||
| 部分成立 | 9 | 事实层成立、报告定性偏高；改措辞而非推翻原文 |
|
||||
| 驳回（报告不成立） | 11 | 仓库正确，**不改** |
|
||||
| 已修 | 5 | 报告描述的原文已不存在，无需判定 |
|
||||
| 合计 | 95 | |
|
||||
|
||||
驳回率约 11.6%。驳回集中在两类：「把 AI 可读的措辞当成事实错误」（e_entry / `LC_MAIN` 的公式类指控 5 条）
|
||||
与「把开发线当成已发行版本」（pwntools / Capstone 2 条）。
|
||||
|
||||
## 四、驳回清单（不得修复）
|
||||
|
||||
以下条目**严禁**出现在任何 `fix:` 提交里。改动它们等于把正确内容改错。
|
||||
|
||||
| F 编号 | 位置 | 报告主张 | 驳回依据 |
|
||||
|---|---|---|---|
|
||||
| F022 | `.claude/skills/re-automotive/SKILL.md:119,128` | 示例 `from udsoncan.client import Client, ClientConfig` + `config = ClientConfig()` 不可执行，应改 `default_client_conf | venv 装 udsoncan 1.26.1 实跑——`ClientConfig` 是 TypedDict（`__mro__` 含 dict），`ClientConfig()` 返回 `{}` 且不抛错；`Client.refresh_config` 源码逐键补 `default_client_config`；`Client(Dummy(), request_timeout=2, config=部分配置)` 构造成功，配置键补齐至 19 个 |
|
||||
| F034 | `.claude/skills/re-format-macho/SKILL.md:77` | LC_MAIN.entryoff 语义与入口 VA 公式写错 | Apple loader.h `entryoff; /* file (__TEXT) offset of main() */`；dyld 源码 common/MachOAnalyzer.cpp:627 `startAddress = preferredLoadAddress() + mainCmd->entryoff`；本机 ld64.lld 造的 Mach-O 实测：__TEXT.vmaddr=0x100000000、entryoff=0x330、_main=0x100000330（vmaddr+entryoff |
|
||||
| F035/F072 | `.claude/skills/re-pwn/SKILL.md:27,28、.claude/skills/re-exploit/SKILL.md:27` | pwntools 已进入 5.x 主线，4.15.0 不再是当前正式版 | PyPI pwntools latest = 4.15.0（2025-10-12，>=2.7），122 个版本中无任何 5.*；GitHub releases 最新 tag 同为 4.15.0；dev 分支 `pwnlib/version.py` = `5.0.0dev`，dev README 的「since version 5.0.0」是开发线预告而非已发行版 |
|
||||
| F036 | `.claude/skills/re-format-elf/references/layout.md:26` | 把 ET_DYN 的 e_entry 定义为"相对基址的偏移"是事实错误 | ELF gABI ch5 定义 base address = 内存地址与文件虚拟地址之差，对 executable/shared object 是同一常量，由最低 PT_LOAD p_vaddr 推出（不是"映射起始地址"）；Linux fs/binfmt_elf.c:1245 `e_entry = elf_ex->e_entry + load_bias;`——DYN 下 e_entry 就是相对 base 的值，仓库措辞与该模型一致，且从未称其为文件偏移/RVA |
|
||||
| F047 | `.claude/skills/re-format-elf/references/layout.md:26`（与 F036 同句重复） | 同一句"表述不严谨/易误导" | 同上；报告担心的非零最低 PT_LOAD.p_vaddr 场景已被 load_bias 吸收，该措辞不会产生地址偏差 |
|
||||
| F052 | `.claude/skills/re-riscv/SKILL.md:76` | 把带 PT_INTERP 的动态链接 ELF 的「进程第一条用户态指令」与主程序 `e_entry/_start` 混为一谈 | 该句本身已写「动态链接程序先经 ld.so（PT_INTERP）」，无混淆；实测 gdb starti /bin/ls 首条指令落在 ld.so（0x7ffff7fdf7e0），而其 e_entry=0x5620、ld.so 自身 entry=0x217e0；实测 riscv64 静态 ELF e_entry=0x111b4 恰等于 _start 且无 PT_INTERP（qemu-riscv64 可跑）——「入口即 e_entry=_start」对常规工具链产物成立，「从 _start 起」是分析程序本体的合理建 |
|
||||
| F069 | `.claude/skills/re-format-elf/references/layout.md:26`（重复） | 同上 | 同上（gABI ch4 e_entry 定义 + ch5 base address 定义 + 内核 +load_bias） |
|
||||
| F080 | `.claude/skills/re-emulation/references/gotchas.md:7` | upstream 已发布 Capstone 6 正式线，仓库仍写 5.x 当前 | PyPI capstone latest = 5.0.9（2026-05-28，>=3.8）；6.x 仅有 6.0.0a1–a11 预发行（a11 = 2026-09-21）；GitHub releases 最新同为 `6.0.0-Alpha11`，无正式 6.0.0 |
|
||||
| F110 | `.claude/skills/re-format-elf/references/layout.md:26（重复；报告另引 :48 p_vaddr 同措辞）` | 同上 | 同上；p_vaddr 行同理——段虚拟地址整体施加 load bias，与该文件措辞一致 |
|
||||
| F111 | `.claude/skills/re-exploit/SKILL.md:69` | | psABI 原文即 "the stack needs to be 16 (32 or 64) byte aligned immediately before the call instruction is executed"，与仓库此句逐字对应；实测探针：`call printf` 前 rsp%16==0 正常（rc=0）、==8 触发 movaps SIGSEGV（rc=139）；ROP 式 `ret` 转移同样——转移前 rsp%16==0 正常、==8 SIGSEGV，规则在 ret 场景下同样成立 |
|
||||
|
||||
## 五、报告未列但同源需一并修的传播点
|
||||
|
||||
判定过程中扫出的、报告未点名但属同一错误的散布点。只改报告点名的位置，同一错误会留在别处，
|
||||
且 gateway 会把旧规则注回工作流。
|
||||
|
||||
| 主题 | 报告未列的位置 |
|
||||
|---|---|
|
||||
| rizin 的 `apt install` | 报告点名 4 处，实际 6 处：另含 `re-deobfuscate/SKILL.md:31`、`re-unpack-advanced/SKILL.md:41` |
|
||||
| binwalk 安装说明 | 报告点名 5 处，另含 `re-packer-id/SKILL.md:44`、`re-shellcode/SKILL.md:43-44` |
|
||||
| QEMU 默认网络（安全基线） | `re-fw-emulate/references/commands.md:31,33,97`、`re-fw-emulate/SKILL.md:104,119,121`、`references/gotchas.md:14`。其中 `commands.md:33`「完全断网｜不加任何网络参数即可（默认 `-net none`）」最危险 |
|
||||
| 「等 OEP 后转储」绝对化 | `re-analyze/references/platform-tips.md:93`、`re-loader/SKILL.md:101,106,111`、`re-crypto-keys/SKILL.md:38,61,112,120`、`re-forensics/SKILL.md:15`、`re-anti-analysis/SKILL.md:17,176,184,193`、`re-crypto-decrypt/SKILL.md:109` |
|
||||
| `p7zip` 旧包名 | `re-fw-rootfs/SKILL.md:30` |
|
||||
| JPEG/PNG 结束标记启发式 | `re-fw-extract/SKILL.md:89` 的 `rfind(IEND/FFD9)` |
|
||||
| 分组对齐判密码类型 | `re-crypto-id/SKILL.md:136` 的「16/24/32 对齐」 |
|
||||
| zipalign 顺序 | `re-apk/references/commands.md:38,66-67`、`re-apk/SKILL.md:93` |
|
||||
| IDA 9.x 无 64 后缀 | `re-plugin-dev/SKILL.md:73,107`、`re-deobfuscate/SKILL.md:26`、`re-license/SKILL.md:32` |
|
||||
|
||||
另有两处**报告未提、判定时顺带实测出**的错误，一并纳入修复：
|
||||
|
||||
| 位置 | 问题 | 实测依据 |
|
||||
|---|---|---|
|
||||
| `re-arm/SKILL.md` 变体误选判据 | 报告只说「32 位指令不是幻觉」，未给真判据 | armv6m 下 `movw/movt` 报 `instruction requires: armv8m.base`、`clz/udiv` 报 `thumb2`；armv7m 下正常——这才是变体选错的判据 |
|
||||
| `re-mips/SKILL.md` R6 描述 | 「MIPS32r6 起取消延迟槽」本身不准 | R6 仍保留 BEQ/BNE/JALR/JR 的延迟槽，删的是 branch-likely、新增的是 compact 无延迟槽形式（BEQC/BNEC/BC/BALC/JIC/JIALC） |
|
||||
|
||||
## 六、逐条判定
|
||||
|
||||
以下按判定类别分组：采纳 → 部分成立 → 驳回 → 已修。每条给出位置、报告主张、依据与改法。
|
||||
|
||||
### F005/F059/F071/F116 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-fw-extract/SKILL.md:26（上下文 25/27/29）、.claude/skills/re-mips/SKILL.md:36、.claude/skills/re-arm/SKILL.md:42、.claude/skills/re-rtos/SKILL.md:103、.claude/skills/re-console/SKILL.md:71`
|
||||
- 报告主张: `pip install binwalk` 被写成「跨平台、版本新、签名库全，推荐」，已非 upstream 当前安装渠道
|
||||
- 依据: PyPI binwalk latest = 2.1.0（2015-01-22，无 requires-python）；GitHub releases 最新为 Binwalk v3.1.0（Rust 重写）；README 安装入口 = Docker / Cargo / 源码
|
||||
- 改法: 删去「pip（跨平台、版本新、签名库全，推荐）」，把 pip 与发行版包一并标为 legacy v2（Debian trixie 2.4.3、bookworm 2.3.4 均为 2.x）并要求先 `binwalk --version` 确认 major；v3 走官方 README 的 Docker/Cargo/源码。re-mips/re-arm/re-rtos/re-console 四处只留「同 [[re-fw-extract]]」不带 pip 推荐。CLI 示例无需改：v3.1.0 tag 与 master 的 `src/cliparser.rs` 均保留 `-e/--extract`、`-M/--matryoshka`、`-E/--entropy`（`--carve` 是 master 新增，仓库未使用）
|
||||
|
||||
### F024 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-format-pe/SKILL.md:125`
|
||||
- 报告主张: 经典(Delphi 7 及以前 Win32) VMT 负偏移四处错位，64 位值随之错
|
||||
- 依据: Embarcadero《Delphi Language Guide》VMT 表 Win32 列 TypeInfo -72/MethodTable -64/ClassName -56/InstanceSize -52（Win64 -168/-152/-136/-128），字段序与 undelphi 0.2.0 解析器一致；扣掉 D2009 给 TObject 新增的 3 个虚方法（Win32 3×4）得经典值 -60/-52/-44/-40。仓库四值 -0x20/-0x24/-0x18/-0x10 全落进 TObject 虚方法槽区（-0x20 实为 SafeCallException、-0x24 实为 vmtParent）
|
||||
- 改法: 改为 TypeInfo -0x3C、published 方法表 -0x34、类名字符串指针 -0x2C、实例大小 -0x28（可附 vmtSelfPtr -0x4C、vmtParent -0x24）；删掉"64 位约 -0x40"的推演，改按官方 Win64 值（vmtClassName -0x88、vmtInstanceSize -0x80）；"现代布局"分界改为 Delphi 2009（XE2 只引入 Win64，未改负偏移）
|
||||
|
||||
### F025 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-ios/references/gotchas.md:35`
|
||||
- 报告主张: 越狱矩阵把 unc0ver 写成「iOS 14-15 系」，版本范围错误且陈旧
|
||||
- 依据: appledb.dev/jailbreak/unc0ver 与 onejailbreak 均为 unc0ver 支持 **iOS 11.0-14.8**，末版 **v8.0.2（2022-07-11）**；iOS 15 由 Dopamine/Fugu15 覆盖，unc0ver 不支持任何 iOS 15
|
||||
- 改法: `unc0ver（iOS 14-15 系）` → `unc0ver（iOS 11.0-14.8，A7-A14 分档；末版 v8.0.2/2022 已停更）`。同行的 palera1n「checkm8 设备全系」与 Dopamine「iOS 15-16 系」可保留（Dopamine 覆盖 15.0-16.6.1，与「15-16 系」相符）
|
||||
|
||||
### F037/F049/F061/F079/F101 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-ghidra/SKILL.md:30`
|
||||
- 报告主张: Ghidra 最新正式版已是 12.1.4，仓库仍写「2026-08 最新 12.1.3」
|
||||
- 依据: github.com/NationalSecurityAgency/ghidra/releases.atom 首条 Ghidra 12.1.4（2026-09-21），次条 12.1.3（2026-08-18）
|
||||
- 改法: 删掉 `2026-08 最新 12.1.3` 这类易腐化写法，改为「12.x 为当前主线；安装时以官方 Releases 的 Latest 为准（本文档核验基线 12.1.4，2026-09）」。JDK 描述保持不变：12.1.4 发布包 README 仍要求 64-bit JDK 21；master 构建为 JDK 25 + Gradle 9.1.0+（已实测，与现有表述一致）
|
||||
|
||||
### F038 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-cpp-abi/SKILL.md:81（坑项 :103 同）`
|
||||
- 报告主张: "lambda 无 RTTI"绝对化，且用 _ZTI 缺失反推 lambda 不可靠
|
||||
- 依据: 实测 g++：`auto f1=[](int){...};` 且 `typeid(f1)` 时 nm 出现 `_ZTIN2f1MUliE_E`（"typeinfo for f1::{lambda(int)#1}"）；同一 lambda 不用 typeid 时 _ZTI 计数为 0——说明缺失只是常见产物、不是类型性质，"步骤 2 缺失 ⇒ lambda"的反推无效
|
||||
- 改法: 两处统一改为：closure type 是真实匿名 class type；普通调用场景常不发射独立 RTTI，缺 _ZTI 既不能排除也不能反推 lambda；优先用 `_ZZ<作用域>ENK...`/`operator()` mangling、捕获成员布局、调用点识别；typeid 等 ODR-use 时可有对应 RTTI
|
||||
|
||||
### F039/F121 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-ios/SKILL.md:54-57,96-103,116（另 .claude/skills/re-ios/references/commands.md:36,66-70、re-ios-jb/SKILL.md:126-127,132 联动）`
|
||||
- 报告主张: 仍把原版 `AloneMonkey/frida-ios-dump` 当当前可用默认脱壳方案，给出 clone→pip install→dump.py 直跑路径
|
||||
- 依据: 其 agent `dump.js`（master）使用 `Module.ensureInitialized`(:1)、静态 `Memory.readU8/U16/U32/U64/Pointer/readByteArray`(:27-90)、`Module.findExportByName(null,…)`(:109)、`Process.enumerateModulesSync`(:159)；本机 Frida **17.16.4** 实测这四类 API 全为 `undefined`（`Module.findGlobalExportByName`/`getGlobalExportByName` 为 function，实例方法 `Process.getModuleByName(x).findExportByName` 为 function）。仓库自身 `.claude/skills/re-frida/SKILL.md:147` 已载明 Frida 17 移除静态 Module 查找/枚举 API，两条知识自相矛盾
|
||||
- 改法: 把该工具降为 legacy/historical（注明需旧 Frida 或自行移植 API），默认流程改为「按目标 iOS/越狱版本选已适配 Frida 17 的维护实现」，执行前先核对 `frida --version`、frida-server 与 dumper 的兼容矩阵；能力描述从「frida-ios-dump——App Store 加密应用脱壳」改为「iOS FairPlay 解密/脱壳（backend 按环境选择）」，可并列记录 mremap_encrypted 路线。commands.md 序列 3 与 re-ios-jb 的两处引用同步。未独立核验的次项：报告中「bagbak 已把 runtime dump 标为 deprecated」未复验，不影响结论
|
||||
|
||||
### F040 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-console/SKILL.md:33`
|
||||
- 依据: GB CPU 是 Sharp SM83/LR35902，无 IX/IY、无 DD/FD/ED 前缀、无 IN/OUT，与 Z80 不兼容（Pan Docs/GBdev、Cycle-Accurate GB Doc 均警告勿称 Z80）；Ghidra 核心确无 SM83（第三方 GhidraBoy 提供 SM83 SLEIGH + Game Boy loader）——「Ghidra 无原生模块」这半句是对的
|
||||
- 改法: 第 33 行改为「GB/GBC 用 Sharp SM83：与 8080/Z80 编码相近但不是 Z80 兼容变体（无 IX/IY、无 DD/FD/ED 前缀、无 IN/OUT，有自家 STOP/LDH 与 HL 自增减）；Ghidra 核心无 SM83，装 GhidraBoy 等 SM83 SLEIGH + Game Boy loader；Z80 模块仅可作人工对照，不得作为 ROM 的处理器语言」。坑 6（第 158 行）同步：近似反汇编的具体后果是指令语义分叉（同一编码在 SM83/Z80 含义不同，如 0x22/0xE8/0x10），须以模拟器实测校正
|
||||
|
||||
### F041 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-arm/SKILL.md:33,90,134`
|
||||
- 依据: 实测 clang --target=armv6m-none-eabi：`bl` 编码 f7ff fffe（4 字节 32 位）；dsb/dmb/isb/mrs/msr 同为 32 位（f3bf 8f4f 等）。BL 范围实测：位移 16777214 可编码、16777216 报 Relocation out of range → ±16MB，非 ±4MB。反向判据实测：同一 .s 在 armv6m 下 `movw/movt` 报 instruction requires: armv8m.base、`clz/udiv` 报 thumb2，armv7m 下正常
|
||||
- 改法: 三处同改——第 33 行「Cortex-M0/M0+ 实现 Armv6-M：以 16 位 Thumb 编码为主，但含少量合法 32 位编码（BL、DMB/DSB/ISB、MRS/MSR）；必须选 v6-M 变体，只有出现 Armv6-M 之外的编码（MOVW/MOVT、CLZ、硬件除/取模）才说明变体选错」；第 90 行删「（ARMv6-M 的 16 位 BL 仅 ±4MB）」改「Thumb 态 ±16MB（BL 为 32 位编码，Armv6-M 亦然）」；第 134 行坑项改为按具体 opcode 是否属于 Armv6-M 判定，不以指令宽度判定（第 130 行 veneer 坑的「Thumb-2 ±16MB」同步去掉 Thumb-2 限定）
|
||||
|
||||
### F042 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-binaryninja/SKILL.md:32、:75、.claude/skills/re-binaryninja/references/gotchas.md:8`
|
||||
- 报告主张: 版本说明停在 3.x/4.x，未反映 6.0（2026-09-03）的 Extension Manager / Python 3.13 / Free 版能力变化
|
||||
- 依据: binary.ninja/2026/09/03/binary-ninja-6.0-krypton.html：Plugin Manager 重构为 Extension Manager、bundled Python 升至 3.13 并首次覆盖 Linux、最低外部 Python 仍 3.10、一次性 Plugin Migration 重装依赖；Free 新增 armv8(AArch64)+ARM64 Linux 构建（binary.ninja/free 仍写 No API/plugin access、IL 受限）
|
||||
- 改法: `版本差异: 3.x/4.x…` → `6.x 为当前主线`，补 6.0 迁移条目（Extension Manager 取代 Plugin Manager / 旧 `pluginmanager` 仅 shim / bundled Python 3.13、外部 >=3.10 / 升级后依赖迁移对话框）；Free 能力矩阵改 `x86 / x86_64 / armv7+Thumb2 / armv8`，仍无 API 与插件。`install_api.py` 保留（docs 仍有 Installing via the API 章节），插件目录三平台路径不变（docs 现仍列 `~/.binaryninja/plugins` 等），无需改；菜单名 `File > Manage Plugins` 改指 Extension Manager（6.x 实际菜单路径实施时以 UI 实测确认）。不写死 patch 号
|
||||
|
||||
### F043 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-arm/SKILL.md:105`
|
||||
- 依据: AAPCS32 原文 "Bit 0 of a code pointer indicates the target instruction set type (0 Arm, 1 Thumb)"；AAPCS64 只定义 64-bit code pointer 且 "All 64 bits ... always significant"，无 Thumb 态、无函数指针低位语义
|
||||
- 改法: 该句限定为 AArch32 并移入 AAPCS32 条目：「AArch32 C++ 虚表中指向 Thumb/T32 函数的函数指针同样带 Thumb 状态位（bit0=1，解析实际地址时清 bit0）；AArch64 用 A64、无 Thumb 态，不适用此规则（另有 PAC 等平台扩展）」；AAPCS64 条目内不再出现 Thumb-bit 判据
|
||||
|
||||
### F044 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-radare2/SKILL.md:27`
|
||||
- 报告主张: 「Fedora 42 及更早版本用官方 release 二进制」不成立，F42 仓库有 rizin
|
||||
- 依据: Fedora Bodhi: `rizin-0.7.4-8.fc42` 于 2025-03-10 入 stable（0.7.4-1.fc42 = 2024-12-31，0.7.3-3.fc42 = 2024-09-01）；packages.fedoraproject.org 现列 F43/44/45/Rawhide + EPEL 8/9/10
|
||||
- 改法: 删掉硬编码 Fedora 阈值，改为「Fedora 当前受支持版本 / EPEL 8+：`dnf install rizin`；已 EOL 的 Fedora 先查发行版仓库，无包再用 Rizin 官方 release 或 `rz-pm`」，EPEL 由 8/9 补到 10。附核报告次项：Debian sid 确有 `radare2 6.1.8+ds-1`，故 `.claude/skills/re-radare2/SKILL.md:34` 的 `apt install radare2` 保留
|
||||
|
||||
### F046 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-mips/SKILL.md:78,111`
|
||||
- 依据: 实测 qemu-mips 跑自建 MIPS32 探针：BEQL not-taken 时延迟槽被 annul（exit=0，槽内 `li $t0,0x11` 未执行），BEQ not-taken 时执行（exit=17）；BEQL taken 走目标（exit=34）；mips32r6 下汇编 beql 报错（R6 已删 branch-likely）
|
||||
- 改法: 第 78 行改「pre-R6：普通 BEQ/BNE/J/JAL 的延迟槽在 taken/not-taken 两路都执行；Branch Likely（BEQL/BNEL/BLEZL/BGTZL/BLTZL/BGEZL 及 FP likely 类）只在 taken 时执行延迟槽，not-taken 时被 annul」；第 111 行坑项把「同时计入跳转两路」限定为 non-likely 分支。另注：同句尾「MIPS32r6 起取消延迟槽（r6 代码无此问题）」本身也不准确——R6 仍保留带延迟槽的 BEQ/BNE 与 JALR/JR，只是新增无延迟槽 compact 形式（BEQC/BNEC/BC/BALC/JIC/JIALC）并删除 branch-likely；实测 -march=mips32r6 产物中 bne 之后仍跟有效指令（延迟槽），建议一并改为「R6 删除 branch-likely、新增无延迟槽 compact 分支，按 ISA revision + opcode 分类」
|
||||
|
||||
### F048 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-go/SKILL.md:131（:139 为冲突项）`
|
||||
- 报告主张: 「LD_PRELOAD 对 Go 程序无效」被绝对化，cgo/动态库路径仍可插桩
|
||||
- 依据: 本机 go1.27.1 实测——CGO_ENABLED=0 产物无 PT_INTERP、`readelf -d` 报「no dynamic section」，hook `open/openat` 未命中（现象成立）；CGO_ENABLED=1 + `import "C"` 产物 `DT_NEEDED libc.so.6`，同一 hook 输出 `[HOOK] puts("hello-from-C-puts") intercepted`（绝对表述不成立）。仓库 `re-go/SKILL.md:139` 已有「cgo 混合产物」条目，与之逻辑冲突
|
||||
- 改法: 标题限缩为 `LD_PRELOAD 对纯 Go syscall 路径通常无效`；对策补「先 `readelf -l/-d/-Ws`、`ldd` 判 PT_INTERP/DT_NEEDED 与 cgo 痕迹；纯 Go 走 strace/eBPF/ptrace；存在 cgo 或动态 ELF 符号时 LD_PRELOAD 仍可 interpose」。与 :139 的 cgo 条目互引，消除冲突
|
||||
|
||||
### F051 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-pwn/SKILL.md:106,109`
|
||||
- 依据: psABI 的 va_list 有独立 reg_save_area / overflow_arg_area / gp_offset，并明示「假定所有参数都在栈上」的程序在 x86-64 不成立；实测 `printf("%1$p..%7$p")` 不传任何可变参时 %1$–%5$ 打印寄存器残留（每次运行不同），%6$/%7$ 才是调用者栈槽
|
||||
- 改法: 第 109 行改为「`%N$` 是 printf 逻辑参数列表的第 N 个参数，不是第 N 个栈槽；SysV AMD64 下 format 占 RDI，前 5 个整型/指针可变参来自 RSI/RDX/RCX/R8/R9，第 6 个起才来自 overflow_arg_area；无对应实参时读到的是调用现场残留，偏移必须探测」；第 106 行注释删「即栈上第 1/2 个 8 字节」（若要保留该意思，须写成「%6$/%7$ 即调用者栈上第 1/2 个 8 字节」并移到寄存器列表之后）；示例补 marker + 全量 %p 扫描，注明 fmtstr_payload 的 offset 来自实测而非 ABI 常数
|
||||
|
||||
### F053 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-dotnet/SKILL.md:45`
|
||||
- 报告主张: 「mono 自 2021 年起不在官方仓库，AUR 亦无稳定 mono 包，仅 mono-git」，与当前 Arch 仓库状态不符
|
||||
- 依据: 本机 `pacman -Si mono` → `Repository: extra`、`Version: 6.12.0.206-1`、`Architecture: x86_64`、Provides monodoc
|
||||
- 改法: 改为 `Arch: sudo pacman -S mono`，删除「自 2021 年起不在官方仓库 / AUR 仅 mono-git」整段；仅在明确需要 upstream Git snapshot 时把 AUR `mono-git` 列为可选并注明属 AUR
|
||||
|
||||
### F054 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-arm/SKILL.md:33`
|
||||
- 依据: 同 F041 实测；另实测 armv6m 下 movw/movt 报 instruction requires: armv8m.base、clz/udiv 报 thumb2——这才是变体误选的真判据
|
||||
- 改法: 同 F041（措辞可采用报告建议：「Armv6-M Thumb ISA 以 16 位为主但含少量合法 32 位编码；32 位≠幻觉，应按 Armv6-M 指令集合验证」）
|
||||
|
||||
### F055 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-mem-forensics/SKILL.md:36`
|
||||
- 报告主张: Arch 仍用旧包名 `pacman -S p7zip`
|
||||
- 依据: `pacman -Si p7zip` → `error: package 'p7zip' was not found`；`pacman -Si 7zip` → `extra/7zip 26.03-1`（命令行程序仍为 `7z`，验证步骤无需改）
|
||||
- 改法: `pacman -S p7zip` → `pacman -S 7zip`。同型的 `.claude/skills/re-fw-rootfs/SKILL.md:30` 需一并改（报告未列，同一错误）
|
||||
|
||||
### F056/F115 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-crypto-decrypt/SKILL.md:51`
|
||||
- 报告主张: 「找格式结束标记用第一个（JPEG EOI FFD9、PNG IEND），不是最后一个」不成立，不应以裸字节搜索定容器边界
|
||||
- 依据: 构造实验——PNG：首个子串 `IEND` 落在 offset 78 的 tEXt chunk 载荷内，结构合法的 IEND 结尾在 104，按该规则截掉 26 字节合法数据；JPEG：首个子串 `FF D9` 落在 offset 22 的 APP1 载荷内，真实 EOI 在 63，按该规则截掉 43 字节。报告关于「entropy-coded scan 内因 FF00 stuffing 不会出现裸 FFD9」的纠正亦正确（真正失稳点是 APP/COM 等 length-delimited payload 与嵌入数据）
|
||||
- 改法: 删「用第一个」启发式，改为「不要用 first/last 裸 marker 搜索定边界：PNG 从 8 字节签名起按 Length/Type/Data/CRC 遍历至结构合法且长度为 0 的 IEND（必要时验 CRC）；JPEG 从 SOI 起按 marker/segment 解析，SOS 后按 FF00 stuffing/RSTn 处理，语法位置成立的 EOI 才是结尾；裸字节搜索只能作候选定位」。`.claude/skills/re-fw-extract/SKILL.md:89` 的 `rfind(IEND/FFD9)` 同步（该处已写「第一个还是最后一个取决于…」，但同属启发式，建议一并改成结构化解析）
|
||||
|
||||
### F058/F070/F088 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-tls/SKILL.md:107（:65,87,105 为上下文）`
|
||||
- 报告主张: 把 TLS 1.3 的 ALPN 最终协商结果放在 ServerHello
|
||||
- 依据: 本机 openssl s_server/s_client 走 TLS 1.3 + `-alpn h2` + `-msg`——ServerHello 段内 `00 10`（ALPN 扩展类型）出现 0 次、`68 32`（"h2"）0 次；EncryptedExtensions 报文为 `08 00 00 0b 00 09 00 10 00 05 00 03 02 68 32`，即 ext 0x0010 = ALPN，协议 "h2"。RFC 8446 扩展位置表为 `ALPN
|
||||
- 改法: :107 注释改为「ClientHello 的 ALPN 是客户端候选列表；TLS ≤1.2 的最终选择在 ServerHello，TLS 1.3 的最终选择在 EncryptedExtensions（握手密钥/keylog 解密后可见）」；步骤 4 流程行区分「offered ALPN」与「negotiated ALPN」，不要把 `tls.handshake.extensions_alpn_str` 的输出直接当最终协议（:87 已对 TLS 1.3 Certificate 作过同类提示，原则一致）
|
||||
|
||||
### F060 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-proto-rev/SKILL.md:64-78,102,104（步骤 5 的时序推演同受影响）`
|
||||
- 报告主张: 整个流程把 TCP segment payload 当应用层 message，缺 TCP 流重组
|
||||
- 依据: 代码侧已确认——步骤 2 `Counter()` 对 `bytes(p[TCP].payload)[:8]` 逐包计数、步骤 3 用「载荷实际长度」、步骤 4 逐包 `C2(load)`、步骤 5 按包序重建状态机，全库无 重组/reassemble/TCPSession/follow-stream 步骤（grep 仅命中 :131 的 IRC 应用层分片坑）。语义侧：RFC 9293 §3.7 定义 TCP 为字节流、不保留应用层消息边界。实测：3 次连续 `send()`（无间隔）在接收端合并为 1 个 chunk（`MSG1-payload-AMSG2-payload-BMSG3-payload-C`），间隔 20 ms 才是 3 个 chunk——说明「一次 write 恰好一段」只是时序巧合；反向（一条消息跨多段）在 MSS 限制下同理成立，未做抓包实证（本机 `tshark -i lo` 报 `dumpcap: Permission denied`）
|
||||
- 改法: 在步骤 1 与步骤 2 之间加入强制阶段「TCP 流重建 → 应用层 framing」：按连接与方向依 SEQ 去重、处理重传/重叠/乱序、记录 capture gap，再在字节流上推断 framing（magic+length / 分隔符 / 固定长度 / TLV / 连接关闭）；`Counter(load[:8])` 改为对重组流扫描候选 magic 并验证相邻 frame 满足长度约束；`C2(load)` 改为持续 buffer parser，至少支持 0/1/N 条消息对应一个 segment；Scapy 路线可用 `TCPSession` + `tcp_reassemble()`，或先用 tshark follow-stream。UDP 等 datagram 传输单独说明（datagram 保留消息边界，不套 TCP 模型）
|
||||
|
||||
### F062/F086 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-angr/SKILL.md:27（26/28/123 为上下文）、.claude/skills/re-angr/references/gotchas.md:5`
|
||||
- 报告主张: 仍把 9.3.x 当最新主线，`pip install angr` 实际已解析到 10.x
|
||||
- 依据: PyPI angr latest 10.0.1（2026-09-30 上传；10.0.0 = 2026-09-17），requires_python >=3.12；9.3.0–9.3.4 亦为 >=3.12
|
||||
- 改法: `（最新 9.3.x 线）` → `（当前主线 10.x；Python >=3.12）`，不写死 patch。`Python 3.11 及以下 → angr<9.3` 分支保留（9.2.209 及以前 >=3.10、9.2.214+ 已 >=3.12，gotchas 的「按目标版本核验 requires-python」照留）。是否 pin `angr<10` 取决于本库有没有跑完 10.x 回归，不要在正文默认断言 10.x 兼容
|
||||
|
||||
### F063 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-fw-emulate/references/gotchas.md:27（:28,29 同组）、.claude/skills/re-fw-emulate/references/commands.md:31,33,97、.claude/skills/re-fw-emulate/SKILL.md:104,119,121`
|
||||
- 报告主张: 「qemu-user 无网络；qemu-system 默认 -net none」与 QEMU 实际默认行为相反
|
||||
- 依据: 本机 QEMU **11.1.1**：不带任何网络参数启动后 `info network` 输出 `hub0port1: #net140: index=0,type=user,net=10.0.2.0,restrict=off` 与 `hub0port0: e1000.0: index=0,type=nic,model=e1000,macaddr=...`（默认即自动建 NIC + user/SLIRP backend）；加 `-nic none` 后无任何网络条目。qemu-user 侧：`qemu-aarch64` 运行 arm64 静态 Go 程序，`dial OK to 127.0.0.1:45671`，宿主监听端收到 `hi-from-qemu-user`——user-mode 只是 syscall 转发，不是网络沙箱
|
||||
- 改法: 安全基线反转——`qemu-system 未显式声明网络时会自动创建默认 NIC + user backend（restrict=off）；分析不可信固件必须显式 -nic none`；需要受控网络时 `-nic user,restrict=on` 或隔离 TAP/namespace。**`commands.md:33` 的「完全断网
|
||||
|
||||
### F064 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-patching/SKILL.md:108`
|
||||
- 报告主张: `pesign -d 删除签名` 错误
|
||||
- 依据: Debian pesign(1) 手册——`-d digest`/`--digest-type digest`: "Use the cryptographic digest with --hash (default: sha256)"，需带参数且只作用于 --hash；`-r`/`--remove-signature`: "Remove signature" 才是删除；`-S`/`--show-signature` 显示签名信息；`-u`/`--signature-number number` 供 remove/export/show 指定第 N 个签名
|
||||
- 改法: 改为 `pesign -S -i signed.exe` 先查签名数 → `pesign -r [-u N] -i in.exe -o out.exe`；并把「移除 WIN_CERTIFICATE 证书表」与「仅清 PE Security 目录项 offset+size」明确区分为两种不同操作，保留原文件、输出新文件
|
||||
|
||||
### F065 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-frida-script-author/SKILL.md:25-27`
|
||||
- 报告主张: apt/pacman/choco 不是 frida-tools 的等价官方安装方式
|
||||
- 依据: frida 官方 Installation 页（frida.re/docs/installation/）只给 `pip install frida-tools` 与 GitHub Releases，无 apt/pacman/choco；Ubuntu launchpad getPublishedSources(source_name=frida-tools)=0 条；Arch 官方库 name=frida 命中 0（同接口 radare2 命中 extra 6.2.0，接口有效）；chocolatey.org/packages/frida 与 /packages/frida-tools 均 HTTP 404（对照 radare2、windbg 均 200）——`choco install frida` 指向不存在的包
|
||||
- 改法: 只保留 `python -m pip install -U frida-tools`（建议隔离 venv 或 pipx）；第三方渠道若保留须标注「非 upstream 渠道，安装前核验版本与维护状态」，不与 pip 并列
|
||||
|
||||
### F067 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-unpack-simple/SKILL.md:101`
|
||||
- 报告主张: 把 CheckSum 与 SizeOfImage/NumberOfSections 并列成普通用户态 PE dump 的加载失败原因
|
||||
- 依据: Microsoft IMAGE_OPTIONAL_HEADER.CheckSum 官方原文："The following files are validated at load time: all drivers, any DLL loaded at boot time, and any DLL loaded into a critical system process."——普通用户态 EXE/DLL 无加载期校验
|
||||
- 改法: 原因删去 CheckSum，只留 SizeOfImage/NumberOfSections 并补 SizeOfHeaders、节表 RVA/raw 范围与对齐；CheckSum 另起一句"普通用户态非加载条件，仅驱动/boot DLL/关键进程 DLL 需重算"
|
||||
|
||||
### F068 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-deobfuscate/SKILL.md:32,42,82`
|
||||
- 报告主张: rizin 语境应推荐 rzpipe，r2pipe 属 radare2
|
||||
- 依据: Rizin README(dev) 原文 "We provide a way to interact with Rizin from Python, Haskell, OCaml, Ruby, Rust, and Go languages through [rzpipe](https://github.com/rizinorg/rz-pipe)"；PyPI rzpipe 0.6.2 desc="Interact with rizin"、home=rizin.re；PyPI r2pipe 1.9.8 desc="Interact with radare2 using the #!pipe command..."
|
||||
- 改法: re-deobfuscate 三处 r2pipe → `pip install rzpipe` 并链接 rizinorg/rz-pipe，示例改用 rzpipe API。全仓 r2pipe 仅这 3 处且全在 rizin 语境，无 radare2 语境误伤，无需保留分支
|
||||
|
||||
### F074/F094 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-radare2/references/gotchas.md:9`
|
||||
- 报告主张: 版本节奏仍写 `r2 5.9.x 维护更新`，落后一个 major generation
|
||||
- 依据: radare2 releases.atom 最新 6.2.2（2026-09-06），其后 6.2.0/6.1.8/6.1.6/6.1.4/6.1.2；rizin 最新 0.9.1（2026-06-29），故 rz 一侧表述仍成立
|
||||
- 改法: `r2 5.9.x 维护更新；rz 0.7/0.8/0.9 滚动演进` → `radare2 当前主线 6.2.x；Rizin 当前主线 0.9.x`（不写死 patch），并补「2021 年分叉后独立演进，命令/API/插件 ABI 不按共同版本经验推断，执行前 `r2 -v` / `rizin -v` 核验」
|
||||
|
||||
### F075/F092 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-ebpf/SKILL.md:114（:20,94 同源）`
|
||||
- 报告主张: 「helper 调用号随内核版本漂移」「helper 号是 bpf_func_id 枚举序号，随内核版本增删漂移」不成立
|
||||
- 依据: 本机 `/usr/include/linux/bpf.h`（内核 7.2 头文件）的 `___BPF_FUNC_MAPPER` 逐项显式编号——`FN(unspec, 0)`、`FN(map_lookup_elem, 1)`、`FN(map_update_elem, 2)`、`FN(map_delete_elem, 3)`、`FN(tail_call, 12)`…共 214 项，数值是显式指定而非 enum 位置序号，正是为保证 backport 场景下 ID 可移植
|
||||
- 改法: 整条改为「helper ID 是 Linux BPF UAPI 的稳定编号，已有 BPF_FUNC_* 数值不随内核版本重新编号；版本差异影响的是 helper 是否存在、是否允许用于特定 prog_type/context，以及语义是否扩展。旧 bpftool 显示 `call unknown#N` 是它的名称表不认识较新 ID，不能反推 ID→名称漂移。解析按 UAPI 固定 ID 映射，可调用性用 `bpftool feature probe` + 目标内核确认；kfunc 不属于该稳定 ABI」。标题改「helper 集合/可用性随内核版本演进，ID 本身稳定」；:20「调用号…随版本漂移」与 :94「按运行内核版本查表」同步
|
||||
|
||||
### F076 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-arm/SKILL.md:105`
|
||||
- 依据: 同 F043（AAPCS64 无 Thumb 态，A64 无函数指针 bit0 状态语义）
|
||||
- 改法: 同 F043
|
||||
|
||||
### F077 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-frida/SKILL.md:31,146`
|
||||
- 报告主张: 「版本必须完全一致」过度收紧，实为 major 一致
|
||||
- 依据: 本机 frida 17.16.4 的 _frida.abi3.so 内嵌官方错误串 "Unable to communicate with remote frida-server; please ensure that major versions match and that the remote Frida has the feature you are trying to use"——官方自述判据即 major 一致 + 功能存在，非精确版本一致
|
||||
- 改法: 改为「client 与 frida-server 至少须同 major；为避免 feature/API 差异推荐使用完全相同且最新的版本；报 ProtocolError 时先查 major mismatch，再查目标功能是否被对应版本支持」
|
||||
|
||||
### F081 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-go/SKILL.md:134（同文另见 docs/superpowers/plans/2026-08-18-experience-absorption.md，属冻结存档不回改）`
|
||||
- 报告主张: 把 `crypto/cipher.NewGCM` 第一个参数当 AES 密钥
|
||||
- 依据: 本机 `go doc crypto/cipher.NewGCM` → `func NewGCM(cipher Block) (AEAD, error)`（"returns the given 128-bit block cipher wrapped in Galois Counter Mode"）；`go doc crypto/aes.NewCipher` → `func NewCipher(key []byte) (cipher.Block, error)`（key 必须 16/24/32 字节）
|
||||
- 改法: 该条改为「跟踪 `crypto/aes.NewCipher` 的 key 参数来源，回溯拼接点；若先定位到 `crypto/cipher.NewGCM` / `NewGCMWithNonceSize` / `NewGCMWithTagSize`（及 `NewGCMWithRandomNonce`），其参数是 `cipher.Block` 不是密钥，需继续回溯该 Block 到 `aes.NewCipher` 再取 key」
|
||||
|
||||
### F082 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-unpack-simple/SKILL.md:101`（与 F067 同条重复）
|
||||
- 报告主张: 同上
|
||||
- 依据: 同上（MS 官方文档；"头三字段"应拆开表述）
|
||||
- 改法: 同 F067
|
||||
|
||||
### F083 — 采纳（报告成立）
|
||||
|
||||
- 位置: `re-ida/SKILL.md:14,27,28,46,79,116｜re-ida/references/commands.md:27,28,29,30,61｜re-plugin-dev/SKILL.md:73,107｜re-deobfuscate/SKILL.md:26｜re-license/SKILL.md:32（共 15 处 / 5 文件）`
|
||||
- 报告主张: IDA 9.x 已移除 64 后缀，ida64/idat64 命令不存在
|
||||
- 依据: 本机 IDA 9.4 安装目录（58 个顶层条目）顶层可执行文件仅 hv/ida/idapyswitch/idat/lc/lsadm/picture_decoder/upg32，`ls
|
||||
- 改法: 以 IDA 9.x 为基线统一 `idat -A -S"script.py" sample`、验证用 `idat --help`，删除「idat=32 位 / idat64=64 位」表述；如需兼容旧版加一行版本分支（IDA<=8.x 才用 ida/idat 的 64 后缀形态）
|
||||
|
||||
### F084 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-cpp-abi/SKILL.md:55`
|
||||
- 报告主张: typeinfo 布局硬编码"前 8 字节 vptr、+8 类名"只对 64 位成立
|
||||
- 依据: clang++ -c 实测 i386/armv7 `_ZTI1A` 大小 8，重定位显示 +0→`_ZTVN10__cxxabiv117__class_type_infoE(+8)`、+4→`_ZTS1A`；x86-64 同结构大小 16（+0/+8）。同技能 :66 已按 32/64 分列 vtable 前缀，属内部不一致
|
||||
- 改法: 改为"typeinfo 起始为 vptr，下一 pointer-sized 槽为 __type_name；64 位通常 +0/+8、32 位 +0/+4；解析前先确定 ELF class/指针宽度，__si_class_type_info/__vmi_class_type_info 同样按目标 ABI 对齐与字段宽度解析"
|
||||
|
||||
### F085 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-format-elf/SKILL.md:69`
|
||||
- 报告主张: 步骤标题把 .fini_array 也标成"main 之前执行"
|
||||
- 依据: 实测 constructor/destructor 程序输出 `[ctor][main][dtor B][dtor A]`——析构在退出阶段执行且按 .fini_array 逆序；同技能 :128 坑项已正确写"退出清理阶段"，文内自相矛盾
|
||||
- 改法: 标题改"初始化与终止回调（.init_array / .fini_array）"，正文分写：.init_array→启动初始化、数组正序；.fini_array→退出/dlclose 清理、数组逆序
|
||||
|
||||
### F087 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-arm/SKILL.md:105`
|
||||
- 依据: 同 F043；该文件第 88 行已正确限定「Thumb 函数地址 LSB=1」，问题仅在第 105 行的跨架构泛化
|
||||
- 改法: 同 F043，另可把「Thumb 函数边界」章节标题明确为「AArch32 Thumb/T32 函数边界」
|
||||
|
||||
### F089/F103 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-apk/references/gotchas.md:19（:36 同组）、.claude/skills/re-apk/references/commands.md:38,66-67、.claude/skills/re-apk/SKILL.md:93`
|
||||
- 报告主张: 「v1 签名需要 zipalign，v2/v3 不需要」「apksigner 默认 v1+v2」写反/不成立
|
||||
- 依据: 官方 zipalign 文档原文「If you use `apksigner`, `zipalign` must be used **before** the APK file has been signed. If you sign your APK using `apksigner` and make further changes to the APK, its signature is invalidated」；`apksigner sign --help` 对 v1/v2/v3 三项均写「enabled based on min and max SDK version」（非固定 v1+v2）。实测（apksigner 0.9）：`--min-sdk-version 24` 签名后 verify 得 v1=false / v2=true / v3=true；签名后再 `zipalign -f 4` → `DOES NOT VERIFY`、`ERROR: ... indicates the APK is signed using APK Signature Scheme v2 but no such signature was found. Signature stripped?`（v3 同）
|
||||
- 改法: gotchas.md:19 整条重写为「zipalign 与签名方案是正交要求：用 apksigner 时必须先 zipalign 后签名，签名后不得再修改 APK（v2/v3 保护 ZIP 元数据，签后对齐即失效）；jarsigner 顺序相反但已不推荐；实际启用的 scheme 由 apksigner 依 minSdk/maxSdk 决定」。commands.md:38 删「v2/v3 无需 zipalign」，:66 的重打包路径补 `zipalign -P 16 -f -v 4`（含未压缩 .so 时按官方要求做 16 KiB 页对齐）再 `apksigner sign`，并补 `zipalign -c -P 16 -v 4` 校验
|
||||
|
||||
### F091 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-format-macho/SKILL.md:130`
|
||||
- 报告主张: "64 位下 LC 最小 16 字节"不是规范规则
|
||||
- 依据: loader.h:240 "The cmdsize for 32-bit architectures MUST be a multiple of 4 bytes and for 64-bit architectures MUST be a multiple of 8 bytes"，load_command 仅 cmd+cmdsize=8B；XNU bsd/kern/mach_loader.c:1358 只查 `lcp->cmdsize < sizeof(struct load_command)`(=8)；dyld common/MachOFile.cpp:472 同样 `cmdsize < 8`（%4 检查处带 8 字节对齐 FIXME）。8 字节 LC 头部规范上合法，无 16 字节下界
|
||||
- 改法: 改为"所有 LC 至少 8 字节（load_command 头）；64 位 cmdsize 须为 8 的倍数、32 位为 4 的倍数；再按具体 cmd 校验其结构最小尺寸与尾随 section/字符串，累计不超 sizeofcmds"
|
||||
|
||||
### F093 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-ai-model/SKILL.md:35`
|
||||
- 报告主张: ONNX 版本说明停留 1.22，当前已是 1.23
|
||||
- 依据: PyPI onnx latest 1.23.1（2026-09-29），requires_python >=3.10（1.23.0 = 2026-09-18）；仓库的 Python 下限 3.10 仍正确
|
||||
- 改法: 去掉写死 minor，改为「当前 onnx 要求 Python >=3.10；具体版本以 PyPI Requires-Python 为准」；若需记录格式侧基线，另写 IR/opset 而非工具版本号
|
||||
|
||||
### F097 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-format-elf/SKILL.md:92`
|
||||
- 报告主张: DT_SYMENT 写死 24 字节对 ELF32 错
|
||||
- 依据: /usr/include/elf.h Elf32_Sym=4+4+4+1+1+2=16B、Elf64_Sym=24B；实测 ld.lld 造的 i386 .so 与 PIE `readelf -d` 均 SYMENT=16，x86-64 为 24
|
||||
- 改法: 改为"按 DT_SYMENT 给出的 entry size 遍历；标准 ELF32 的 Elf32_Sym 为 16 字节、ELF64 为 24 字节；应读取并校验 DT_SYMENT，勿硬编码 24"
|
||||
|
||||
### F098 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-riscv/SKILL.md:44`
|
||||
- 依据: Debian 包文件列表：binutils-riscv64-linux-gnu 提供 /usr/bin/riscv64-linux-gnu-objdump 等 16 个 riscv64-linux-gnu- 前缀命令；binutils-riscv64-unknown-elf 是独立包（bullseye–sid 均有）
|
||||
- 改法: 第 44 行按安装项一一对应拆开——Debian/Ubuntu 装 binutils-riscv64-linux-gnu → 验证 riscv64-linux-gnu-objdump --version；需要裸机 triplet 时单列 binutils-riscv64-unknown-elf → riscv64-unknown-elf-objdump --version；Arch/brew 维持 unknown-elf，Fedora 维持 linux-gnu
|
||||
|
||||
### F099 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-frida/SKILL.md:43`
|
||||
- 报告主张: Objection 已要求 Python>=3.10，技能未注明
|
||||
- 依据: PyPI objection 1.12.5 wheel METADATA `Requires-Python: >=3.10`（依赖 click>=8.2.0、frida>=16.0.0、frida-tools>=10.0.0）
|
||||
- 改法: 写 `Python >=3.10: pip install -U objection`，建议另建 3.10+ venv；不要与 frida 的 Python 下限（frida 17.19.0 requires_python >=3.7）合并描述
|
||||
|
||||
### F100 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-arm/SKILL.md:90`
|
||||
- 依据: 同 F041 实测：armv6m 的 bl 是 32 位编码（f7ff fffe），范围 ±16MB（16777214 可编码、16777216 越界）
|
||||
- 改法: 删除「（ARMv6-M 的 16 位 BL 仅 ±4MB）」，改「Thumb BL 为 32 位编码、±16MB；Armv6-M 虽无完整 Thumb-2 仍支持 BL；实际可达范围按具体编码/重定位（如 R_ARM_THM_CALL）判定，超距由链接器插 veneer」
|
||||
|
||||
### F102 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-format-macho/SKILL.md:84`
|
||||
- 报告主张: LC_DYLD_INFO(_ONLY) 漏 weak_bind，应为 5 组
|
||||
- 依据: Apple loader.h 的 dyld_info_command 为 rebase/bind/weak_bind/lazy_bind/export 五组 off+size（8+5×8=48，恰与"48 字节"自洽）；weak_bind 有独立语义（弱符号合并，晚于普通 bind 处理），非别名
|
||||
- 改法: 改为"五组：rebase、bind、weak_bind、lazy_bind、export，各带 offset+size，共 48 字节"，并注明 weak_bind 不得并入 bind
|
||||
|
||||
### F104 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-crypto-id/SKILL.md:99-100（:136 同源）`
|
||||
- 报告主张: 用「密文是否按分组大小对齐」区分分组密码与流密码不成立
|
||||
- 依据: 本机 openssl，37 字节明文：`aes-128-ctr`/`aes-128-ofb`/`aes-128-cfb` 密文均 **37 字节**（与明文等长），`aes-128-cbc`/`aes-128-ecb` 为 48 字节（padding）。AES-CTR/AES-OFB 底层仍是 128-bit 分组密码，按 :100 的规则会被误分到「流密码（RC4/XOR/ChaCha）」一侧。NIST SP 800-38A 中 OFB/CTR 末块允许 `u` bit，CFB 粒度是 segment size `s`
|
||||
- 改法: 两行改为「数据长度只能辅助判断 mode，不能区分 primitive：ECB/传统 CBC 常见整块或 padding 扩长；CTR/OFB/CFB 等基于分组密码的 mode 可产生与明文等长的任意长度密文；CBC-CTS 亦可避免 padding 扩长——长度任意不能推出 RC4/XOR/ChaCha。识别须结合常量表/轮函数/key schedule/IV-nonce-counter 数据流」。删除「16/32 字节对齐 → AES 最可能」启发式，并写明 AES block size 恒为 128 bit（16 字节），192/256 是 key size；:136 的「分组长度（16/24/32 对齐）」同属此误，一并改
|
||||
|
||||
### F105 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-triage/SKILL.md:113`
|
||||
- 报告主张: "ET_DYN=PIE"不成立
|
||||
- 依据: 本机实测 .so 显示 `Type: DYN (Shared object file)`，-pie 可执行文件显示 `DYN (Position-Independent Executable file)`——现代 readelf 依 dynamic 区 DF_1_PIE 区分，e_type 无法区分共享库与 PIE
|
||||
- 改法: 注释改"ET_EXEC 通常为非 PIE；ET_DYN 可能是 PIE 或共享对象"，并补一行 `readelf -d sample
|
||||
|
||||
### F106 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-gdb/SKILL.md:28-40｜re-pwn/SKILL.md:43`
|
||||
- 报告主张: pwndbg 的 git clone+setup.sh 已非官方主路径
|
||||
- 依据: pwndbg 官方 setup 页把仓内那段 `git clone https://github.com/pwndbg/pwndbg; cd pwndbg; ./setup.sh` 明确排在 "Legacy install method" 标题下（"We still support a setup.sh script, but note it requires root as it calls sudo internally"）；主路径 Install Script 标注 "(recommended)"：`curl --proto '=https' --tlsv1.2 -LsSf 'https://install.pwndbg.re'
|
||||
- 改法: portable installer 升为默认，git clone+setup.sh 降为 legacy/开发用；标题去掉「（二选一，装到 ~/.gdbinit）」（已不能覆盖 portable 发行与 pwndbg-lldb）；re-pwn:43 同步
|
||||
|
||||
### F107 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-format-pe/SKILL.md:183`
|
||||
- 报告主张: 由"IAT 槽无 .text 引用"推出"实际走 LoadLibrary+GetProcAddress"不成立
|
||||
- 依据: PE 规范：导入目录表"contains address information that is used to resolve fixup references to the entry points within a DLL image"（loader 解析）；GetProcAddress 官方定义为"从指定 DLL 导出中取址"的独立机制，且纯动态解析的 API 通常根本不进导入表——无 xref 推不出机制改变
|
||||
- 改法: 改为"未引用 import 检测：导入表中有符号但当前 CFG/.text 扫描未见引用，只能作 unused/间接引用候选；继续查数据引用、间接调用与反汇编覆盖。动态解析须由 LoadLibrary*/GetModuleHandle*+GetProcAddress、Ldr* 原生 API、PEB/导出遍历、API hash 等独立证据确认，不得由无 xref 反推"，并删"静态 IAT 分析结论作废"
|
||||
|
||||
### F109 — 采纳（报告成立）
|
||||
|
||||
- 位置: `package.json:26、CLAUDE.md:9`
|
||||
- 报告主张: 运行时基线 `Node >=18` 已把 EOL 运行时纳入受支持配置
|
||||
- 依据: nodejs/Release `schedule.json`：v18 end 2025-04-30、v20 end 2026-04-30（均 EOL）；v22 → 2027-04-30、v24 → 2028-04-30、v26 → 2029-04-30
|
||||
- 改法: `engines.node` 与 CLAUDE.md 同步提升（推荐 `>=22`，或写「当前受支持 LTS」更耐久）；仓库无 `.github/workflows`，无 CI matrix 需改；`docs/superpowers/plans/2026-08-07-re-skills.md:50` 属冻结存档，按既有约定不回改。本波计划 Task 17 已列此项，基线取值与其对齐
|
||||
|
||||
### F112 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-arm/SKILL.md:33`
|
||||
- 依据: 同 F041（官方 Cortex-M0 datasheet 的 "Armv6-M Thumb instruction set with Thumb-2 technology" 与本机 armv6m 实测一致）
|
||||
- 改法: 同 F041
|
||||
|
||||
### F113 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-format-macho/SKILL.md:84`（与 F102 同条重复）
|
||||
- 报告主张: 同上
|
||||
- 依据: 同上（weak_bind_off/weak_bind_size 为独立成员）
|
||||
- 改法: 同 F102
|
||||
|
||||
### F114 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-frida/SKILL.md:164`
|
||||
- 报告主张: 「frida 17+ 内置 Java bridge 已移除，需 frida-compile 打包」过度泛化
|
||||
- 依据: frida.re/docs/bridges/ 原文 "Starting with Frida 17.0.0, bridges are no longer bundled with Frida's GumJS runtime... The Frida REPL and frida-trace do however come with all three bridges bundled, for compatibility with existing scripts"，并给出 `$ frida -p0 -l script.js` 直接可用的示例
|
||||
- 改法: 改为「Frida 17 起 bridge 不再内置于底层 GumJS runtime；但 frida CLI/REPL 与 frida-trace 仍自带三个 bridge，普通 `frida -l` 脚本无需改动；仅自建 agent / 走 bindings 注入脚本时需显式 `npm install frida-java-bridge` 并 `import Java from "frida-java-bridge"`，必要时 frida-compile 打包」
|
||||
|
||||
### F117 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-mips/SKILL.md:78,111`
|
||||
- 依据: 同 F046 qemu-mips 实测（BEQL not-taken → 槽被 annul；BEQ not-taken → 槽执行）
|
||||
- 改法: 同 F046
|
||||
|
||||
### F119 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-variant/SKILL.md:35、.claude/skills/re-patching/SKILL.md:38、.claude/skills/re-license/SKILL.md:32、.claude/skills/re-imports/SKILL.md:37、.claude/skills/re-deobfuscate/SKILL.md:31、.claude/skills/re-unpack-advanced/SKILL.md:41（报告未列，同型，建议一并）`
|
||||
- 报告主张: 把 `apt install rizin` 当 Debian/Ubuntu 通用安装方式
|
||||
- 依据: packages.debian.org 与 packages.ubuntu.com 搜 rizin 均返回「no results」，sources.debian.org exact=null；`.claude/skills/re-radare2/SKILL.md:28` 已正确写明「Debian 仓库无 rizin 包」
|
||||
- 改法: 六处统一改为引用 [[re-radare2]] 安装矩阵，删无条件 `apt install rizin`；Debian/Ubuntu 走官方 release / `rz-pm`（Kali 可用 apt，属其自有仓库，需注明前提）；`re-imports:37` 的「Debian 13+ / Ubuntu 24.04+」是伪版本门槛，一并删除。各技能不再复制发行版命令
|
||||
|
||||
### F120 — 采纳（报告成立）
|
||||
|
||||
- 位置: `.claude/skills/re-android-native/SKILL.md:103、references/probes.md:3,7,14,55,60`
|
||||
- 报告主张: 把 `JNIEnv` 函数表里 `RegisterNatives` 的槽位描述成随 jni.h 声明序/NDK/ART 版本漂移
|
||||
- 依据: 解析 6 份头文件的 `JNINativeInterface_` 声明序：JDK 8/11/17/27、GraalVM 21、Android NDK 30 结果完全一致——`RegisterNatives` = **index 215**、`UnregisterNatives` = 216、`NewStringUTF` = 167、`GetJavaVM` = 219；表项数 233（JDK8/NDK30）→236（JDK27），新增项只追加在尾部，正是固定 ABI 的维护方式。仓库自身 `references/experience.md:7` 已经写死「`RegisterNatives`=0x6b8（槽215）」「`NewStringUTF`=0x538（槽167）」（64 位下 215×8=0x6B8、167×8=0x538，数值正确），与 probes.md 的「槽号漂移」说法互相矛盾
|
||||
- 改法: SKILL.md:103 改为「`RegisterNatives` 位于标准 JNIEnv function table index **215**（`UnregisterNatives` 216），这是 JNI ABI 的固定布局；实际 byte offset = index × 目标指针宽度。Android Dalvik/ART、NDK 与标准 jni.h 不应改变该 index」。probes.md:7 的「槽号随 jni.h 声明序/版本变化，禁止硬编码」删去，:55 的「布局漂移→按当前头文件重新推导」改为「运行时锚点仅用于校验 JNIEnv 有效性、检测 hook/代理函数表或非标准实现」，:3/:60 的「随 NDK/ART 版本演进」限定到真正的易变层（ABI 传参寄存器、libart 内部结构、实现细节）
|
||||
|
||||
### F045 — 部分成立（改措辞，不推翻原文）
|
||||
|
||||
- 位置: `.claude/skills/re-automotive/SKILL.md:143（:139 为对照）`
|
||||
- 报告主张: 把 UDS ECU 下载流程固定写成 `0x27 → 0x34 → 0x36 → 0x37`，0x27 并非下载序列的固定第一步
|
||||
- 依据: 0x34 自身的服务定义即「发起 client→server 数据传输」，ISO 定义的下载传输核心是 `0x34 → 0x36×N → 0x37`（仓库 :139 本已正确写成「0x34-0x36-0x37 固件下载流程」）；0x27 是独立服务，仅当 ECU 的 security level 配置要求时才是前置。但实车刷写中 0x27 确在 0x34 前，「明确错误」定性偏高。ISO 14229-1 原文为付费标准，未直接引用
|
||||
- 改法: 拆两层保留实用信息——`UDS 标准传输核心：0x34 RequestDownload → 0x36 TransferData × N → 0x37 RequestTransferExit；实际 ECU 编程通常先按 OEM 要求进 0x10 编程会话，服务受安全级别保护时执行 0x27，擦除/完整性校验多经 OEM 定义的 0x31，过程可能需 0x3E 保活、结束可能 0x11 复位——具体序列从 ECU 行为/ODX/固件恢复，不假定固定顺序`
|
||||
|
||||
### F050 — 部分成立（改措辞，不推翻原文）
|
||||
|
||||
- 位置: `.claude/skills/re-frida/SKILL.md:45,116`
|
||||
- 报告主张: `objection -g <应用> explore` 已被当前版本替换，应改 `-n ... start`
|
||||
- 依据: 解包 objection 1.12.5 wheel 读 objection/console/cli.py——`--gadget/-g` 仍在（line 55，hidden=True + deprecated="Please use '-n' or '--name' instead"），`explore` 仍在（line 206，hidden + deprecated，经 ctx.invoke(start, ...) 转发，line 225）；click 8.3.3 的 deprecated 仅打告警不报错
|
||||
- 改法: 改为 `objection -n <应用或Bundle ID> start`；报告「-g/explore 已被移除、会 unknown argument 在入口处失败」不成立——旧写法仍可跑，只出弃用告警。措辞写「1.12.x 起 -g/explore 已弃用（隐藏），新写作用 -n + start」，不得写成命令失效
|
||||
|
||||
### F057 — 部分成立（改措辞，不推翻原文）
|
||||
|
||||
- 位置: `.claude/skills/re-shellcode/SKILL.md:165,184`
|
||||
- 依据: MS 官方 /Gd 页：/Gd 是默认（x86 自由函数 __cdecl、成员函数默认 __thiscall），只有 /Gz 才把默认改为 __stdcall——x86 半句确为过泛；但 MS x64 页自述 "uses a four-register, fast-call calling convention by default"，故「x64 默认 fastcall」不构成硬错
|
||||
- 改法: 改为「32 位无唯一约定：Win32 API 常见 WINAPI/__stdcall（callee 清栈、有 RET n），程序自身默认 __cdecl、成员函数 __thiscall——按符号修饰 / 调用者栈平衡 / ECX-EDX 判定；64 位用统一 x64 ABI：前四整型/指针参数 RCX/RDX/R8/R9 + 32 字节 shadow space」（可保留「类 fastcall」的说法，但不要写成 __fastcall）
|
||||
|
||||
### F066 — 部分成立（改措辞，不推翻原文）
|
||||
|
||||
- 位置: `.claude/skills/re-memdump/SKILL.md:34`
|
||||
- 报告主张: 把 Volatility 2 / Python 2 描述成正常「按需」兼容分支，未标已归档
|
||||
- 依据: github.com/volatilityfoundation/volatility 页面显示「archived by the owner on May 16, 2025」，README 首句「This project is archived. See Volatility 3 for modern investigations」，Archived 状态属实；但现文已是「volatility2 旧版 Python2 按需」，并非把它写成当前主线，故「明确错误」定性偏高
|
||||
- 改法: 按报告补一句即可——`Volatility 3 是唯一当前维护主线；Volatility 2 已于 2025-05-16 被 upstream 归档（只读），仅用于旧 V2-only 插件/profile 的历史镜像或结果复现，需置于隔离的 Python 2 环境，现代镜像勿作常规 fallback`。同技能的 vol2 风格描述（如 :55「相比 vol2 手选 profile 已简化」）是历史对照，无需改
|
||||
|
||||
### F073 — 部分成立（改措辞，不推翻原文）
|
||||
|
||||
- 位置: `.claude/skills/re-tee/references/gotchas.md:15(,13)`
|
||||
- 依据: 通道归属本身正确（Arm「Learn the architecture」：SVC/HVC/SMC 分别目标 EL1/EL2/EL3；SCR_EL3.HCE/SMD 控制使能），该行给出的处置建议（先分通道、别把 hypervisor 调用归 TEE）也正确，故「明确错误」不成立；但同组第 13 行「x1-x17（SMC64）」缺版本限定——SMCCC 1.2 才把 SMC64 扩到入参 x1-x17 / 返回 x0-x17，1.0/1.1 仅 x0-x7
|
||||
- 改法: 第 13 行补「（SMCCC ≥1.2；1.0/1.1 仅 x1-x7）」；第 15 行可补「指令由较低 EL 的调用者执行、同步异常取到 EL2/EL3；看到 smc 不能直接等价 TEE，继续按 SMCCC FID/OEN 判服务」
|
||||
|
||||
### F090 — 部分成立（改措辞，不推翻原文）
|
||||
|
||||
- 位置: `.claude/skills/re-ghidra/SKILL.md:30 + docs/audit/2026-09-13-factual-audit.md:890,989,1224`
|
||||
- 报告主张: 同上，并指审计档把「当前最新正式 release」记为 12.1.3
|
||||
- 依据: 12.1.4 已发布属实（同上）；但审计档三处均在 2026-09-13 的「补充」小节内，是当日快照
|
||||
- 改法: 技能正文按上条改；审计档不回改历史行（仓库既有约定是追加「补充 NN」小节，本波计划同此做法），以新追加小节记录 12.1.4
|
||||
|
||||
### F095 — 部分成立（改措辞，不推翻原文）
|
||||
|
||||
- 位置: `.claude/skills/re-memdump/SKILL.md:50,57,134、references/commands.md:12,53、references/gotchas.md:20，并传播至 .claude/skills/re-analyze/references/platform-tips.md:93、.claude/skills/re-loader/SKILL.md:101,106,111、.claude/skills/re-crypto-keys/SKILL.md:38,61,112,120、.claude/skills/re-forensics/SKILL.md:15、.claude/skills/re-anti-analysis/SKILL.md:17,176,184,193、.claude/skills/re-crypto-decrypt/SKILL.md:109`
|
||||
- 报告主张: 把「到 OEP」当通用转储完成条件，与 re-unpack-simple 的「第一次执行即 OEP 不成立」冲突
|
||||
- 依据: 现文确为绝对式（`脱壳样本必须在进程运行到 OEP（壳解密完成）后再 dump`；platform-tips:93 `脱壳须等进程运行到 OEP 完全解密后再 dump`），而 re-memdump 的定位是通用内存转储（`用：任何需要读进程内存的任务`），把加壳专用时机写成默认规则确有不妥；但 `.claude/skills/re-unpack-simple/SKILL.md:70,104` 已要求越过 loader/多阶段/fake OEP 并「重复下断直到控制流稳定离开壳代码」，即库内「OEP」语义已含「壳已完成」，故报告所称「直接逻辑冲突」被放大。次要支持：`re-loader/SKILL.md:111` 已自行写出「太晚（已执行完毕被清理）」的生命周期视角
|
||||
- 改法: 统一限定语——`转储时机由目标明文/代码的 materialization 决定：经典单层壳在真实 OEP 附近转储通常合适，但 OEP 不是通用完成判据；多阶段 loader、按需/逐页解密、虚拟化保护、反射加载、进程注入与 fake OEP 应按「写→执行转移 + 内存保护变化 + payload 头/导入恢复」定 dump 点，必要时多时点快照`。同步 platform-tips:93 与 re-loader/re-crypto-keys/re-forensics/re-anti-analysis 的「等 OEP 后」简写（否则 gateway 会把旧规则注回工作流）；`re-unpack-simple` 原文无需改，作为正例互引
|
||||
|
||||
### F108 — 部分成立（改措辞，不推翻原文）
|
||||
|
||||
- 位置: `.claude/skills/re-format-elf/SKILL.md:106`
|
||||
- 报告主张: 符号出现直接等价"有 Canary"不严谨
|
||||
- 依据: 报告设想的假阴性不成立——grep 为子串匹配（`printf '__stack_chk_fail_local'
|
||||
- 改法: 命令保留，注释改为">0 仅为 SSP 线索（静态链接会因 libc 自带 SSP 误报；SSP 按函数施加，不代表全部函数受保护）"，必要时再抽查 canary 载入/比较序列
|
||||
|
||||
### F118 — 部分成立（改措辞，不推翻原文）
|
||||
|
||||
- 位置: `.claude/skills/re-format-elf/SKILL.md:132`
|
||||
- 报告主张: "缺 PT_GNU_STACK → dlopen EINVAL"过强；workaround 应为 execstack=2 而非 1
|
||||
- 依据: 实测 glibc 2.44/x86-64：把 DSO 的 PT_GNU_STACK 改成 PT_NULL 后 dlopen 仍 EINVAL——因 elf/dl-load.c:1098 缺 header 时用 DEFAULT_STACK_PROT_PERMS，x86_64/i386/arm 等为 RWX、generic(aarch64/riscv 等) 为 RW，故"缺 header=要求可执行栈"只在部分架构成立；tunable 实测 `=1` 失败、`=2` 成功，dl-tunables.list maxval=2/default=1
|
||||
- 改法: 条目改为"dlopen 的 DSO 要求可执行栈而进程启动时未启用可执行栈时加载失败（cannot enable executable stack / EINVAL）；缺 PT_GNU_STACK 是否算要求取决于目标 ABI 默认栈权限（x86/x86-64/arm32 默认可执行，aarch64 等默认不可执行）"，并把 workaround 由 `glibc.rtld.execstack=1` 改为 `=2`（降低安全性，仅兼容用；正解是给目标补非 X 的 PT_GNU_STACK）
|
||||
|
||||
### F022 — 驳回（报告不成立）
|
||||
|
||||
- 位置: `.claude/skills/re-automotive/SKILL.md:119,128`
|
||||
- 报告主张: 示例 `from udsoncan.client import Client, ClientConfig` + `config = ClientConfig()` 不可执行，应改 `default_client_config`
|
||||
- 依据: venv 装 udsoncan 1.26.1 实跑——`ClientConfig` 是 TypedDict（`__mro__` 含 dict），`ClientConfig()` 返回 `{}` 且不抛错；`Client.refresh_config` 源码逐键补 `default_client_config`；`Client(Dummy(), request_timeout=2, config=部分配置)` 构造成功，配置键补齐至 19 个
|
||||
- 改法: 不改（与既有实测驳回结论一致；本轮为独立复核，非转述）
|
||||
|
||||
### F034 — 驳回（报告不成立）
|
||||
|
||||
- 位置: `.claude/skills/re-format-macho/SKILL.md:77`
|
||||
- 报告主张: LC_MAIN.entryoff 语义与入口 VA 公式写错
|
||||
- 依据: Apple loader.h `entryoff; /* file (__TEXT) offset of main() */`；dyld 源码 common/MachOAnalyzer.cpp:627 `startAddress = preferredLoadAddress() + mainCmd->entryoff`；本机 ld64.lld 造的 Mach-O 实测：__TEXT.vmaddr=0x100000000、entryoff=0x330、_main=0x100000330（vmaddr+entryoff 精确命中；__TEXT.fileoff=0 故"相对文件头"与"相对 __TEXT"同值）。报告未给正确值，仓库公式与 Apple 实现一致
|
||||
- 改法: 不改
|
||||
|
||||
### F035/F072 — 驳回（报告不成立）
|
||||
|
||||
- 位置: `.claude/skills/re-pwn/SKILL.md:27,28、.claude/skills/re-exploit/SKILL.md:27`
|
||||
- 报告主张: pwntools 已进入 5.x 主线，4.15.0 不再是当前正式版
|
||||
- 依据: PyPI pwntools latest = 4.15.0（2025-10-12，>=2.7），122 个版本中无任何 5.*；GitHub releases 最新 tag 同为 4.15.0；dev 分支 `pwnlib/version.py` = `5.0.0dev`，dev README 的「since version 5.0.0」是开发线预告而非已发行版
|
||||
- 改法: 不改（与仓库既有「进入迁移窗口、暂不标过时」的判定一致）
|
||||
|
||||
### F036 — 驳回（报告不成立）
|
||||
|
||||
- 位置: `.claude/skills/re-format-elf/references/layout.md:26`
|
||||
- 报告主张: 把 ET_DYN 的 e_entry 定义为"相对基址的偏移"是事实错误
|
||||
- 依据: ELF gABI ch5 定义 base address = 内存地址与文件虚拟地址之差，对 executable/shared object 是同一常量，由最低 PT_LOAD p_vaddr 推出（不是"映射起始地址"）；Linux fs/binfmt_elf.c:1245 `e_entry = elf_ex->e_entry + load_bias;`——DYN 下 e_entry 就是相对 base 的值，仓库措辞与该模型一致，且从未称其为文件偏移/RVA
|
||||
- 改法: 不改
|
||||
|
||||
### F047 — 驳回（报告不成立）
|
||||
|
||||
- 位置: `.claude/skills/re-format-elf/references/layout.md:26`（与 F036 同句重复）
|
||||
- 报告主张: 同一句"表述不严谨/易误导"
|
||||
- 依据: 同上；报告担心的非零最低 PT_LOAD.p_vaddr 场景已被 load_bias 吸收，该措辞不会产生地址偏差
|
||||
- 改法: 不改
|
||||
|
||||
### F052 — 驳回（报告不成立）
|
||||
|
||||
- 位置: `.claude/skills/re-riscv/SKILL.md:76`
|
||||
- 报告主张: 把带 `PT_INTERP` 的动态链接 ELF 的「进程第一条用户态指令」与主程序 `e_entry/_start` 混为一谈
|
||||
- 依据: 该句本身已写「动态链接程序先经 ld.so（PT_INTERP）」，无混淆；实测 gdb starti /bin/ls 首条指令落在 ld.so（0x7ffff7fdf7e0），而其 e_entry=0x5620、ld.so 自身 entry=0x217e0；实测 riscv64 静态 ELF e_entry=0x111b4 恰等于 _start 且无 PT_INTERP（qemu-riscv64 可跑）——「入口即 e_entry=_start」对常规工具链产物成立，「从 _start 起」是分析程序本体的合理建议
|
||||
- 改法: 不改
|
||||
|
||||
### F069 — 驳回（报告不成立）
|
||||
|
||||
- 位置: `.claude/skills/re-format-elf/references/layout.md:26`（重复）
|
||||
- 报告主张: 同上
|
||||
- 依据: 同上（gABI ch4 e_entry 定义 + ch5 base address 定义 + 内核 +load_bias）
|
||||
- 改法: 不改
|
||||
|
||||
### F080 — 驳回（报告不成立）
|
||||
|
||||
- 位置: `.claude/skills/re-emulation/references/gotchas.md:7`
|
||||
- 报告主张: upstream 已发布 Capstone 6 正式线，仓库仍写 5.x 当前
|
||||
- 依据: PyPI capstone latest = 5.0.9（2026-05-28，>=3.8）；6.x 仅有 6.0.0a1–a11 预发行（a11 = 2026-09-21）；GitHub releases 最新同为 `6.0.0-Alpha11`，无正式 6.0.0
|
||||
- 改法: 不改（无 `--pre` 时 `pip install capstone` 仍得 5.0.9，「当前 5.0.x」准确）。6.0.0 正式发行后再复核
|
||||
|
||||
### F110 — 驳回（报告不成立）
|
||||
|
||||
- 位置: `.claude/skills/re-format-elf/references/layout.md:26（重复；报告另引 :48 p_vaddr 同措辞）`
|
||||
- 报告主张: 同上
|
||||
- 依据: 同上；p_vaddr 行同理——段虚拟地址整体施加 load bias，与该文件措辞一致
|
||||
- 改法: 不改
|
||||
|
||||
### F111 — 驳回（报告不成立）
|
||||
|
||||
- 位置: `.claude/skills/re-exploit/SKILL.md:69`
|
||||
- 依据: psABI 原文即 "the stack needs to be 16 (32 or 64) byte aligned immediately before the call instruction is executed"，与仓库此句逐字对应；实测探针：`call printf` 前 rsp%16==0 正常（rc=0）、==8 触发 movaps SIGSEGV（rc=139）；ROP 式 `ret` 转移同样——转移前 rsp%16==0 正常、==8 SIGSEGV，规则在 ret 场景下同样成立
|
||||
- 改法: 不改
|
||||
|
||||
### F006/F029 — 已修（无需判定）
|
||||
|
||||
- 位置: `.claude/skills/re-ai-model/SKILL.md:59`
|
||||
- 报告主张: protobuf 仍写 `Python 3.8+`
|
||||
- 依据: 现文已是「当前 7.x 要求 Python >=3.10，6.x 起下限已在抬升；3.8/3.9 需 pin 对应旧版本」；PyPI protobuf 7.36.2 requires >=3.10
|
||||
- 改法: 不改
|
||||
|
||||
### F007/F030 — 已修（无需判定）
|
||||
|
||||
- 位置: `.claude/skills/re-blockchain/SKILL.md:37`
|
||||
- 报告主张: web3.py 仍写 `7.x / Python ≥3.8`
|
||||
- 依据: 现文已是「当前 8.x 要求 Python >=3.10，PyPI requires-python 为 `<4,>=3.10`——7.x 才支持 3.8」；PyPI web3 8.0.0 = `<4,>=3.10`
|
||||
- 改法: 不改
|
||||
|
||||
### F032 — 已修（无需判定）
|
||||
|
||||
- 位置: `.claude/skills/re-ai-model/SKILL.md:47`
|
||||
- 报告主张: torch 仍写 `Python 3.9+`
|
||||
- 依据: 现文已是「当前 torch 2.x 要求 Python >=3.10…3.9 需 pin 到 2.8.x 及更早」；PyPI torch 2.14.0 >=3.10、2.8.0 >=3.9.0、2.9.0 起 >=3.10（pin 建议准确）
|
||||
- 改法: 不改
|
||||
615
vendor-new/rev-skills/docs/audit/review-state.json
Normal file
615
vendor-new/rev-skills/docs/audit/review-state.json
Normal file
@@ -0,0 +1,615 @@
|
||||
{
|
||||
"$comment": "审查状态：每技能内容 hash + 最近复核日期。changed（内容在复核后又变了）即下一轮审查波的工作集——把审查成本从 O(技能总数) 降到 O(变更数)。last_reviewed=null 表示存量技能尚未按本机制复核。",
|
||||
"skills": {
|
||||
"re-address-space": {
|
||||
"hash": "08b638e606a2c56e",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-ai-attack": {
|
||||
"hash": "7cd9dd26b3c854f2",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-ai-model": {
|
||||
"hash": "89465fbbe42d4a4a",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-ai-triage": {
|
||||
"hash": "7a199c5ab33e8a69",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": ""
|
||||
},
|
||||
"re-analyze": {
|
||||
"hash": "ab47b4b44eb930d7",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-android-crypto": {
|
||||
"hash": "4f303b66b031d232",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-android-native": {
|
||||
"hash": "23a53c64697f7b84",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-angr": {
|
||||
"hash": "384dc09a7cecb9bb",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-anti-analysis": {
|
||||
"hash": "712a8e1a1d64de5e",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-anti-cheat": {
|
||||
"hash": "af3ad1d7a7b20b3e",
|
||||
"last_reviewed": "2026-09-22",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-apk": {
|
||||
"hash": "777943bd778593b9",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-arm": {
|
||||
"hash": "1aa780691af0f6ca",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-attribution": {
|
||||
"hash": "fe4b53de849bf1cc",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-automotive": {
|
||||
"hash": "988ae73a587c3934",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-behavior": {
|
||||
"hash": "f74039b063441199",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-binary-core": {
|
||||
"hash": "b2ee0da81a4881bc",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-binaryninja": {
|
||||
"hash": "34d682df353f5851",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-blockchain": {
|
||||
"hash": "0d649f303c3832ee",
|
||||
"last_reviewed": "2026-09-22",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-browser-ext": {
|
||||
"hash": "301b09455a5f6573",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-console": {
|
||||
"hash": "8d1c3d04c10263a0",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-cpp-abi": {
|
||||
"hash": "db36bad3c5715d97",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-cracking": {
|
||||
"hash": "6d9e51e5309ee167",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-crash-triage": {
|
||||
"hash": "161c402d11632823",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-crypto-decrypt": {
|
||||
"hash": "d2a3b5a9587b3498",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-crypto-id": {
|
||||
"hash": "3b19733b195dd582",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-crypto-keys": {
|
||||
"hash": "197de1e9ba753748",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-ctf": {
|
||||
"hash": "881cc6cbe015a88d",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-deobfuscate": {
|
||||
"hash": "98ea3d5f25a282a4",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-disk-forensics": {
|
||||
"hash": "2b4b8b91a1798633",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-doc-malware": {
|
||||
"hash": "8f21eaf5fb591100",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-dotnet": {
|
||||
"hash": "b55739626795eceb",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-drm": {
|
||||
"hash": "ec0eb12f8cda964f",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-ebpf": {
|
||||
"hash": "747cd9f3c3597513",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-electron": {
|
||||
"hash": "3a8c36e2c94ed3ee",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-emulation": {
|
||||
"hash": "b8e80483d3ef23b6",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-evasion": {
|
||||
"hash": "3c2f97986fdda928",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-exploit": {
|
||||
"hash": "d1c4cdd8f3df138c",
|
||||
"last_reviewed": "2026-09-17",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-feedback": {
|
||||
"hash": "7e81cc993b739da3",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": ""
|
||||
},
|
||||
"re-fileless": {
|
||||
"hash": "f6eea40a113cb136",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-firmware": {
|
||||
"hash": "c0fff1b55a6d8784",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-flutter": {
|
||||
"hash": "707ba79961807efa",
|
||||
"last_reviewed": "2026-09-14",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-forensics": {
|
||||
"hash": "34c47907e93a96ba",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-format-elf": {
|
||||
"hash": "f43f7774e72c9349",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-format-macho": {
|
||||
"hash": "5278645d8ddbcf37",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-format-pe": {
|
||||
"hash": "aeaac45f1bafa091",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-fp-runtime": {
|
||||
"hash": "74a6f67b10a02d8f",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-frida": {
|
||||
"hash": "dd262c38eed86902",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-frida-script-author": {
|
||||
"hash": "3dcbe5d6600acb99",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-fuzzing": {
|
||||
"hash": "826575d3fb7e5006",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-fw-emulate": {
|
||||
"hash": "2d1e4a7ea3493900",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-fw-extract": {
|
||||
"hash": "a70e6f39b0903c26",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-fw-rootfs": {
|
||||
"hash": "6d567331fa5b8848",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-game": {
|
||||
"hash": "b00cece3b2329f84",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-gdb": {
|
||||
"hash": "b3eb1e6e3932ab52",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-ghidra": {
|
||||
"hash": "f8a7a11f61715903",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-go": {
|
||||
"hash": "a033e719305c60b1",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-hardware-io": {
|
||||
"hash": "04d119585fd30f7f",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-harmonyos": {
|
||||
"hash": "2eff39e09b9cffe0",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-hunting": {
|
||||
"hash": "b2fb3969dc21fea1",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-hw-chip": {
|
||||
"hash": "6990f5b3aee52f3f",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-hybrid-app": {
|
||||
"hash": "3a0562fea5f5969e",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-hypervisor": {
|
||||
"hash": "8e58b865aac7f480",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-ics": {
|
||||
"hash": "c70ae74a17373bd5",
|
||||
"last_reviewed": "2026-09-22",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-ida": {
|
||||
"hash": "634bd45cdacc18ca",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-imports": {
|
||||
"hash": "661c30890794780a",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-ioc": {
|
||||
"hash": "d555efb545a66994",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-ios": {
|
||||
"hash": "a6c3a96272f6badb",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-ios-jb": {
|
||||
"hash": "55994dd833db492c",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-iot-proto": {
|
||||
"hash": "6e4b0ffc7d557899",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-java": {
|
||||
"hash": "f9a089e8d8d81880",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-javacard": {
|
||||
"hash": "85b9e316badfb655",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-kernel": {
|
||||
"hash": "1cf5f0945e30999e",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-keygen": {
|
||||
"hash": "47ea1cca699a9ff1",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-license": {
|
||||
"hash": "2b6454833e49697d",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-lldb": {
|
||||
"hash": "18dcb57e88c39720",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-loader": {
|
||||
"hash": "67617eec527578a3",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-macos": {
|
||||
"hash": "44f3185ef083f2e4",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-malware": {
|
||||
"hash": "619eb6352a0bb3a0",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-managed": {
|
||||
"hash": "6c6a63c7db208bdc",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-mem-forensics": {
|
||||
"hash": "e72f64a0672c769b",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-memdump": {
|
||||
"hash": "65655acc83d9bd48",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-mips": {
|
||||
"hash": "8b06f5832c616d56",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-mobile": {
|
||||
"hash": "95855d75cb5193a0",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-mobile-forensics": {
|
||||
"hash": "6f0c739eb124e19e",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-mobile-pack": {
|
||||
"hash": "0d32367ecbf221d4",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-netcap": {
|
||||
"hash": "43182095341450e6",
|
||||
"last_reviewed": "2026-09-14",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-nim": {
|
||||
"hash": "4a22856da69df7cc",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-packer-id": {
|
||||
"hash": "ece21434db2f01ff",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-patching": {
|
||||
"hash": "d31157a3ceac77f5",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-plugin-dev": {
|
||||
"hash": "280cdb482af661d4",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-proto-rev": {
|
||||
"hash": "d8916ee12bcbd664",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-protocol": {
|
||||
"hash": "6e112a19835c0de9",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-pwn": {
|
||||
"hash": "daaee5c304965f7b",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-python": {
|
||||
"hash": "ac0c62132da8576d",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-radare2": {
|
||||
"hash": "e70f9ff51eaed95f",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-ransomware": {
|
||||
"hash": "4b4e095dff266c64",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-riscv": {
|
||||
"hash": "82b07b7cb805c5e2",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-rtos": {
|
||||
"hash": "7d1b35dae0c74971",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-rust": {
|
||||
"hash": "03a3d43f324b885a",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-sample-acquire": {
|
||||
"hash": "a5540ad3634eb2b3",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-sandbox": {
|
||||
"hash": "31caa58528abbc92",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-script-deob": {
|
||||
"hash": "1e1acbc7c20f4b64",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-sdr": {
|
||||
"hash": "dd93276df7f8e856",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-shellcode": {
|
||||
"hash": "5217fa0623d50b15",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-stego": {
|
||||
"hash": "fc79277ff6b75f04",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-swift": {
|
||||
"hash": "603c1a6d605c462a",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-tee": {
|
||||
"hash": "23f10ea6e7107c99",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-ti": {
|
||||
"hash": "38078e941afbbe0b",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-tls": {
|
||||
"hash": "aabdc6c51e2a945a",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-tracing": {
|
||||
"hash": "ee4d6f679729cdd3",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-triage": {
|
||||
"hash": "b64b946192d207be",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-uefi": {
|
||||
"hash": "a01adf2fd1451b9b",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-unpack-advanced": {
|
||||
"hash": "d5adc2359ed3af3b",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-unpack-simple": {
|
||||
"hash": "15a21c26036971b7",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-variant": {
|
||||
"hash": "d3a421b519dd6d9b",
|
||||
"last_reviewed": "2026-10-05",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-vuln": {
|
||||
"hash": "60e88badd531f42f",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-wasm": {
|
||||
"hash": "7f73fc8f2abe781d",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-whitebox": {
|
||||
"hash": "d77efb51d00e5934",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-windbg": {
|
||||
"hash": "2cc41bae71e3a172",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-x64dbg": {
|
||||
"hash": "9ab669f77e16476e",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-z3": {
|
||||
"hash": "4cc0719c9f8bdb12",
|
||||
"last_reviewed": "2026-09-13",
|
||||
"note": "本轮审查波覆盖"
|
||||
},
|
||||
"re-zig": {
|
||||
"hash": "e3f0179d5d1f4f58",
|
||||
"last_reviewed": "2026-09-22",
|
||||
"note": "本轮审查波覆盖"
|
||||
}
|
||||
}
|
||||
}
|
||||
1475
vendor-new/rev-skills/docs/audit/tool-register.json
Normal file
1475
vendor-new/rev-skills/docs/audit/tool-register.json
Normal file
File diff suppressed because it is too large
Load Diff
168
vendor-new/rev-skills/docs/dsh-integration.md
Normal file
168
vendor-new/rev-skills/docs/dsh-integration.md
Normal file
@@ -0,0 +1,168 @@
|
||||
# DSH（DeepSeek Harness）集成
|
||||
|
||||
本文是 rev-skills 与 DSH（DeepSeek Harness）集成的长期参考：DSH 在本库语境里是什么、两条集成路线的差别、DSH 强制执行的兼容规则、安装与卸载命令、预设选择方式、验证方法、排错表，以及维护时必须成对同步的文件。
|
||||
|
||||
命令行实现见 `bin/dsh.mjs` 与 `bin/install.mjs`；bundle 的补丁本体是仓库根的 `dsh.patch.yml`。
|
||||
|
||||
## 1. DSH 在本库语境里是什么
|
||||
|
||||
DSH 是一个宿主（host），它按 **Agent Skills 风格**扫描技能目录：每个被扫描根目录下识别 `<root>/<name>/SKILL.md` 或 `<root>/<name>.md`。本库的 `.claude/skills/` 就是这样一个目录，因此内容不需要转换即可被 DSH 读取——需要处理的只是「放到哪个根目录」与「用哪个预设看到它」。
|
||||
|
||||
两条能力需要分开理解：
|
||||
|
||||
- **技能发现**（`@deepseek-ai/dsh-skill-filesystem`）：扫描根目录 → 解析 frontmatter → 把技能注册进当前预设的可用技能列表。
|
||||
- **预设（agent preset）**：`@deepseek-ai/dsh-agent-preset` 的一行配置，决定该预设挂载哪些插件、看到哪些技能根。预设把「技能目录」和「agent 的工具与提示词」绑定在一起。
|
||||
|
||||
DSH 的默认技能根与优先级（数字小者先匹配，同名技能以先命中者为准）：
|
||||
|
||||
| 优先级 | 根目录 | 说明 |
|
||||
|---|---|---|
|
||||
| 100 | `<projectRoot>/.dsh/skills` | 项目级 DSH 技能 |
|
||||
| 200 | `<projectRoot>/.agents/skills` | 项目级通用 agent 技能 |
|
||||
| 300 | `customSkillDirs` | 由预设显式声明的目录（本库预设用这一档） |
|
||||
| 400 | `<dshHome>/skills` | 全局 DSH 技能（Windows 默认 `C:\Users\<用户>\.dsh\skills`） |
|
||||
| 500 | `<agentsHome>/skills` | 全局通用 agent 技能 |
|
||||
| 600 | `bundledSkillDir` | DSH 自带技能 |
|
||||
|
||||
本机可用 `$env:DSH_HOME`（Windows）确认第 400 档的实际位置。
|
||||
|
||||
## 2. 两条集成路线
|
||||
|
||||
两条路线不互斥，取哪条取决于「要不要一个只带逆向技能层的固定 agent 配置」。
|
||||
|
||||
### 路线一：装进 DSH 技能根（所有预设可见）
|
||||
|
||||
把技能拷到第 100 / 400 档，**任何预设**都能看到这 122 个技能，不需要 bundle：
|
||||
|
||||
```bash
|
||||
npx rev-skills install --target dsh # 交互式选择 global / project
|
||||
npx rev-skills install --target dsh --global # → <dshHome>/skills
|
||||
npx rev-skills install --target dsh --project # → .dsh/skills
|
||||
npx rev-skills install --target dsh --dry-run # 只看计划
|
||||
npx rev-skills uninstall --target dsh --global
|
||||
```
|
||||
|
||||
适用场景：只想让技能在任意会话里可用，不需要独立的 agent 配置。代价是技能与预设的工具集、上下文预算混在一起。
|
||||
|
||||
### 路线二：独立预设（自带技能层）
|
||||
|
||||
本仓库的**根包自身即 bundle**（包名 `rev-skills`）：根 `package.json` 里的 `dsh.bundle.patch` 指向仓库根 `dsh.patch.yml`，该补丁插入一行预设 `preset-rev-skills`。不需要第二个包，也就没有第二处版本号要同步。
|
||||
|
||||
- 预设显示 id（`config.id`）为 `rev-skills`，显示名「逆向工程（rev-skills）」，`order` 为 40；
|
||||
- 该预设自带的 `skill-filesystem` 实例用 `includeDefaultRoots: false`，即**该实例自身**不声明第 100–600 档的根，技能根完全由 `customSkillDirs` 指定；但 DSH 读取技能时会把这个预设层与全局层合并，所以项目/用户技能仍与会话可见（同名条目以更近的预设层为准），其他预设不受影响；
|
||||
- bundle 自身不带技能副本，技能始终从仓库的 `.claude/skills/` 读取，因此技能增删改不需要重新发布 bundle。
|
||||
|
||||
`customSkillDirs` 的解析顺序（取第一个通过校验的候选；校验 = 目录存在且其中至少有一个 `re-` 开头的条目）：
|
||||
|
||||
| 顺序 | 候选 | 说明 |
|
||||
|---|---|---|
|
||||
| 1 | `REV_SKILLS_DIR` | 环境变量，优先级最高；取值是仓库根目录时解析为 `<dir>/.claude/skills`，取值是技能目录本身时原样使用 |
|
||||
| 2 | `<DSH_HOME>/skills` | 默认 `~/.dsh/skills`（Windows `%USERPROFILE%\.dsh\skills`）——即「路线一」装进去的位置 |
|
||||
| 3 | `<rev-skills 包目录>/.claude/skills` | 按包名解析；本包即 bundle，装进 profile 的 `node_modules` 时命中 |
|
||||
|
||||
候选都不可用时回落到第 2 项；目录暂缺不报错（提供方会持续探测）。
|
||||
|
||||
按 DSH `skills` 服务的实际契约，预设作用域的提供方与全局层是**合并**关系而非替换：同名技能以更近的层胜出。因此该预设是把 rev-skills 技能根作为自己的一层加入，用户项目与家目录下的技能仍可见；`includeDefaultRoots: false` 只影响这个预设实例自身的根列表。
|
||||
|
||||
**前置要求**：宿主需提供两个包——`@deepseek-ai/dsh-agent-preset`（agent preset 声明能力）与 `@deepseek-ai/dsh-skill-filesystem`（本地技能目录发现能力），官方发行版自带。bundle 自身零运行时依赖，不需要为它单独跑安装。
|
||||
|
||||
```bash
|
||||
node bin/dsh.mjs check [--dir <skillsRoot>] [--json]
|
||||
node bin/dsh.mjs preset spec
|
||||
node bin/dsh.mjs preset status [--profile-dir <dir>] [--json]
|
||||
node bin/dsh.mjs preset install [--profile-dir <dir>] [--force] [--apply]
|
||||
node bin/dsh.mjs preset uninstall [--profile-dir <dir>] [--apply]
|
||||
```
|
||||
|
||||
`preset install` / `preset uninstall` 默认是 dry-run，打印将要做的编辑；加 `--apply` 才写文件（写入前备份，卸载时存在备份则从备份还原）。
|
||||
|
||||
安装这条路线最省事的方式是交给 DSH 自带的包管理器——它的目标参数既可以是 npm 包名（从 registry 装已发布版本），也可以是本地路径（`link:` / `file:` 规格）：
|
||||
|
||||
```bash
|
||||
dsh plugin --profile <profile> add rev-skills # registry 上的已发布版本
|
||||
dsh plugin --profile <profile> add link:/path/to/rev-skills # 本地工作区（改补丁立即生效）
|
||||
```
|
||||
|
||||
成功后它会**自动把 `rev-skills` 追加进该 profile 的 `dsh.profile.bundles`**（实测：从空 bundles 开始，`add` 完成后 bundles 变为 `[..., "rev-skills"]`）；失败则还原 `package.json`、`pnpm-lock.yaml` 与 `node_modules`，不留半截状态。GUI 插件管理器走同一套机制。
|
||||
|
||||
手工等价写法是把下面两处同时写进 profile 的 `package.json`：
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"dependencies": { "rev-skills": "link:/path/to/rev-skills" },
|
||||
"dsh": { "profile": { "bundles": [ "...", "rev-skills" ] } }
|
||||
}
|
||||
```
|
||||
|
||||
两处必须同时存在：**bundle 行在 `dsh.profile.bundles` 里，且依赖能解析到该包**。profile 的 `package.json` 位于 `$env:DSH_PROFILE_DIR`（Windows 默认 `C:\Users\<用户>\.dsh\profiles\<profile>\package.json`）。
|
||||
|
||||
卸载走对称的一条命令，它会同时摘掉依赖与 `dsh.profile.bundles` 里的那一行（实测），随后重启 DSH；已存在的会话保留创建时的插件组合，需新开会话：
|
||||
|
||||
```bash
|
||||
dsh plugin --profile <profile> remove rev-skills
|
||||
node bin/dsh.mjs preset uninstall --apply # 仓库自带 CLI 的等价路径（有备份时从备份还原）
|
||||
```
|
||||
|
||||
**发布面的一个硬约束**：bundle 的补丁文件必须出现在该包 `package.json` 的 `files` 列表里。pnpm 处理 `file:` 依赖时按 `files` 复制内容，漏列时 `add` 会报 `failed to read overlay …/node_modules/rev-skills/dsh.patch.yml: ENOENT` 并整体回滚（测试里有对应回归断言）。
|
||||
|
||||
适用场景：需要一个只见得到本库技能、且带固定工具与提示词的独立 agent 预设。
|
||||
|
||||
## 3. DSH 强制的兼容规则
|
||||
|
||||
本库 122 个技能已全部满足下列规则；新增或修改技能时按此自检。
|
||||
|
||||
1. **目录布局（一层）**：`<root>/<name>/SKILL.md` 或 `<root>/<name>.md`。扫描只深入一层——嵌套的 `**/SKILL.md` 不会被发现，例如 `.claude/skills/re-analyze/references/analysis-contract.md` 不构成独立技能。
|
||||
2. **frontmatter 分界行必须精确**：开头的行就是 `---`（前后无空格、无 BOM），结尾是同样精确的一行 `---`；闭合行之后才有正文。
|
||||
3. **frontmatter 必须是合法 YAML 且解析为 mapping**：键值映射，块标量与内联 list 都在 YAML 子集内。解析失败时 DSH 记一条告警并**静默跳过该技能**（技能看起来"消失"，不报错中断）。
|
||||
4. **`name` 语法**：必须匹配 `/^[a-z0-9]+(?:-[a-z0-9]+)*$/`（小写字母、数字、单连字符分段），并且与目录名一致。
|
||||
5. **`description` 非空**：缺失或空串即不注册。本库另有更严的约束——`description` 必须同时含 CJK 与拉丁字母（`validate.mjs` 强制，保证中英触发词都可命中）。
|
||||
6. **可选键**：`whenToUse`、`metadata`、`disable-model-invocation`、`user-invocable`；本库技能不需要它们即可被发现。
|
||||
7. **工具结果裁剪**：标准预设会裁剪超过 **8192 字符**的工具结果。本库有 **32 个** `SKILL.md` 的文件字符数超过该阈值（CRLF 检出下为 34；`node bin/dsh.mjs check` 会逐条列出字符数与正文行数，最长 `re-kernel`，约 19979 字符），这些技能被加载时正文可能被截断——需要完整内容时直接读文件，或把该技能拆分为「正文 + `references/`」。
|
||||
|
||||
本机自检 frontmatter 的最短路径：
|
||||
|
||||
```bash
|
||||
node validate.mjs # 结构校验（frontmatter / 命名 / 能力标签 / 死链 / guard / 章节）
|
||||
node bin/dsh.mjs check # 按 DSH 发现规则校验技能根（一层布局 / 分界行 / name 文法 / 裁剪阈值）
|
||||
```
|
||||
|
||||
YAML 本身按换行解析，DSH 允许分界行尾带 CR；本库随库脚本（`validate.mjs` / `lib/frontmatter.mjs`）按 LF 解析，因此检出的工作区行尾须与仓库声明一致（`.gitattributes` 与 `core.autocrlf` 的取向见仓库根）。
|
||||
|
||||
## 4. 验证
|
||||
|
||||
1. `node validate.mjs` 输出 `OK: 122 skills validated`——内容层通过。
|
||||
2. `node bin/dsh.mjs check`——按 DSH 发现规则校验技能根，通过时输出 `OK: N skills DSH-compatible`；`--dir <skillsRoot>` 换根、`--json` 逐条给出检查项与告警。
|
||||
3. `node bin/dsh.mjs preset spec`——确认解析到的技能根（`REV_SKILLS_DIR` → `<DSH_HOME>/skills` → 包目录，见第 2 节的顺序表）。
|
||||
4. 新开会话，在预设列表里选中「逆向工程（rev-skills）」：`skill` 工具目录中应出现入口技能 `re-analyze` 与其余 121 个 `re-*` 技能；加载 `re-analyze` 能返回正文即技能根解析正确。
|
||||
5. 对照检查：切回 `standard` 预设的会话，`re-*` 技能不再由预设层提供——若该会话仍能看到 `re-*`，说明技能同时装进了被扫描的全局技能根（路线一），那属于预期结果而非故障。
|
||||
|
||||
## 5. 排错
|
||||
|
||||
| 现象 | 常见原因 | 处理 |
|
||||
|---|---|---|
|
||||
| 技能全部看不到 | 装错根目录（`--project` 装到了 `.claude/skills` 而非 `.dsh/skills`） | 重跑 `--target dsh --global` 或 `--project`，用 `node bin/dsh.mjs check` 核对根 |
|
||||
| 只有个别技能看不到 | frontmatter 首尾不是精确 `---`，或 YAML 不合法 | DSH 日志会有告警并跳过该条；跑 `node validate.mjs` 定位；修正分界行/YAML |
|
||||
| 技能名不合法 | `name` 含大写、下划线、连续连字符或与目录名不一致 | 改为 `<root>/<name>/SKILL.md` 且 `name` 匹配 `/^[a-z0-9]+(?:-[a-z0-9]+)*$/` |
|
||||
| 技能列表里没有 `references/` 里的文件 | 扫描只深入一层，嵌套 `**/SKILL.md` 不发现 | 属预期行为；把需要独立触发的内容提升为顶层技能 |
|
||||
| 预设不出现 | bundle 名不在 profile 的 `dsh.profile.bundles`，或依赖未安装 | 跑 `node bin/dsh.mjs preset status`；补 bundle 行与依赖后重装 profile |
|
||||
| 预设改完没生效 | profile 未重新安装/未应用 | `node bin/dsh.mjs preset install --apply`，或从 GUI 插件管理器重新安装 bundle |
|
||||
| 旧会话看不到新预设 | 已存在的会话保留创建时的插件组合 | 新开一个会话（旧会话不会热切预设） |
|
||||
| 技能根解析到了别处 | `REV_SKILLS_DIR` 或 `<DSH_HOME>/skills` 先命中，且其中存在 `re-` 条目 | 用 `node bin/dsh.mjs preset spec` 看命中项，清掉不该命中的目录或变量 |
|
||||
| 改了技能正文但会话里没变 | 正文按需加载，编辑正文不需重启 | 重新触发该技能即可 |
|
||||
| 改了技能 frontmatter 但会话里没变 | frontmatter 在启动/加载时解析并缓存 | 重启 DSH 会话（或重载技能根）后生效 |
|
||||
| 技能正文被截断 | 正文超过 8192 字符被预设裁剪 | 直接读文件，或把长技能拆分为正文 + `references/` |
|
||||
|
||||
## 6. 维护同步点
|
||||
|
||||
改 DSH 相关文件时，下列配对必须同时更新，否则出现"命令能跑但预设装不上"这类不一致：
|
||||
|
||||
| 项 | 一处 | 另一处 |
|
||||
|---|---|---|
|
||||
| 补丁文件 | 根 `package.json` → `dsh.bundle.patch` | `dsh.patch.yml` 实际路径，且该路径必须出现在根 `package.json` 的 `files` 里 |
|
||||
| bundle 名 | 根 `package.json` → `name`（`rev-skills`） | profile `package.json` → `dsh.profile.bundles` 的对应行 + 同名依赖；本文档与 README 的安装示例 |
|
||||
| 预设 id | `dsh.patch.yml` 的 `config.id`（`rev-skills`） | 本文档的说明 |
|
||||
| 技能根 | `dsh.patch.yml` 的 `customSkillDirs` 解析顺序 | `REV_SKILLS_DIR` 覆盖逻辑、`bin/dsh.mjs` 的 `resolveLocalSkillRoot` 与本文档第 2 节的候选表 |
|
||||
|
||||
版本号不再有第二处：bundle 就是根包，根 `package.json` 的 `version` 与 `.claude-plugin/marketplace.json` 成对即可。
|
||||
|
||||
发布流程与其他宿主一致：`npm test` 通过 → git tag → npm publish → 同步 `package.json` 与 `.claude-plugin/marketplace.json` 的版本号。
|
||||
36
vendor-new/rev-skills/docs/skill-template.md
Normal file
36
vendor-new/rev-skills/docs/skill-template.md
Normal file
@@ -0,0 +1,36 @@
|
||||
# 技能模板规范
|
||||
|
||||
## 原子技能结构
|
||||
每个技能目录：`SKILL.md`（必含）+ 可选 `references/`（深度知识、gotchas）。
|
||||
|
||||
SKILL.md 章节（顺序固定）：
|
||||
1. frontmatter：`name`（=目录名，re- 前缀）、`type`（原子技能可省略或 `atomic`；入口用 `entry`；网关用 `gateway`）、`description`（中英触发词 + 何时使用；**validate.mjs 强制双语**——须同时含 CJK 与拉丁字母，否则 `npm test` 失败）、`capabilities`（可选，见能力注册表 references/capabilities.md）、`guard`（**可选但敏感技能必须**——机器可读安全前置声明，JSON 格式：`{"require_authorization": true, "forbidden": ["行为标签"]}`；validate.mjs 校验结构；入口按 `RE_AUTH`（owned/ctf/research/unknown）联动——require_authorization=true 时仅 owned/ctf/research 可执行，unknown 只做静态分析并先询问归属）
|
||||
2. `# 标题`（中文，如 "脱壳：压缩壳（UPX/ASPack/FSG）"）
|
||||
3. `## 任务分类器（intent → 路径）` —— **可选但推荐**：多分支技能（一个技能含多个子任务族）在「何时使用」前加用户目的 → 路径映射表（如 re-ai-attack：怀疑模型被复制→fingerprint / 判断训练数据泄露→membership / 测试 API 可复制性→extraction / 测试鲁棒性→adversarial），路径指向操作步骤编号；单任务技能可省略
|
||||
- 多分支技能**建议同时加「输入资产盘点（INPUT INVENTORY）」**：路径命中后确认已有资产（API/模型/数据集/副本/基线），缺资产先索要或说明局限——不同资产组合决定不同路线
|
||||
- **入口判定（Decision Gate）**——目标形态判定树（供自动调度分流）：目标出现先判形态再选技能，如 Android 域：APK→lib/*.so 存在？→ re-android-native / re-apk；单独 so→JNI 符号？→ re-android-native / re-binary-core；加固→re-anti-analysis；crypto→re-android-crypto。多输入形态技能（so/APK/固件/流量）必加，单形态技能可省略
|
||||
- **输入适配（Input Adapter）**——输入驱动类技能（符号执行/协议解析/模糊测试）必加：以 symbol source 表抽象输入形态（stdin/argv/file/memory/network buffer/jni argument/custom bytecode），不默认单一输入通道（样板 re-angr 步骤 1：CTF 的 stdin 只是多种符号源之一，真实目标可能是网络包/mmap/JNI 参数）
|
||||
4. `## 何时使用 / 何时不用` —— 明确边界，防误触发
|
||||
5. `## 工具准备` —— 必含：每个工具给出 apt / dnf / pacman / brew / pip / cargo / choco 安装命令 + 验证命令 + OS 分支（Linux/macOS/Windows/WSL 替代方案）；引用 [[platform-tips]] 相关分支
|
||||
6. `## 操作步骤` —— 可执行、具体，沿用 porting-minecraft-mod 的硬性执行风格（不省略、不"类似处理"）。**知识/操作分离**：机制原理（知识层）保留在核心流程，易变参数（槽位索引/offset/运行时实现细节，随 SDK/运行时版本变化）不写进核心流程——集中到 `references/probes.md` 类探针文件（运行时探测与校验为准，样板 re-android-native 的 RegisterNatives 槽位）。**四层内容分离**（复杂技能必循，样板 re-ai-attack）：
|
||||
- **Method Overview**：每步开头一句话「目标/方法本质」（如「通过 API 查询重建近似模型——蒸馏」）
|
||||
- **Operational Checklist**：步骤编号子列表（可勾选执行），只含动作与产出
|
||||
- **Failure Modes**：坑与失败模式（SKILL.md 坑节 + references/gotchas.md）
|
||||
- **Implementation Notes**：实现经验（soft label 优于 hard label 这类）集中到 `references/implementation-notes.md`，步骤内只留一行「见 [[implementation-notes]]」引用——流程与经验不混杂
|
||||
- 可观测性驱动类技能（攻击/指纹域）在标题后加 `## CORE RULE`（如「攻击面由可观测性决定，不由攻击名称决定」+ 观测性表格）
|
||||
7. `## 跨域联合` —— 本技能在哪些复合任务中被其他大类引用（写 [[技能名]] 链接）
|
||||
8. `## 常见坑与陷阱` —— 至少 3 条具体经验（来源：platform-tips + Task 15/16 调研产出）
|
||||
|
||||
## 网关技能结构
|
||||
1. frontmatter（同原子技能，description 声明"网关"）
|
||||
2. `# 标题`
|
||||
3. `## 完整工作流` —— 该大类从头到尾的流程（步骤编号）
|
||||
4. `## 何时用哪个原子技能（选择树）` —— 按输入特征/目标列选择分支
|
||||
5. `## 跨域联合` —— 规格 2.4 的联合场景表（该网关相关行），含 [[链接]]
|
||||
6. `## 常见坑与陷阱`
|
||||
|
||||
## 多工具兼容约束
|
||||
- 正文纯 Markdown，禁止工具私有语法
|
||||
- frontmatter 标准 YAML
|
||||
- 引用统一用 `[[技能名]]`；引用本技能的 `references/` 文件用裸名 `[[文件名]]`；**跨技能**引用别人的 references 必须限定技能前缀 `[[re-xxx/文件名]]`（同名文件普遍，裸链会歧义——validate.mjs 强制，**references/ 内也校验**）
|
||||
- 文档里写**占位符**时用尖括号形式（`[[re-<技能名>]]`、`[[<文件名>]]`）——它不会被解析成真链接，避免文档示例触发死链报错
|
||||
12
vendor-new/rev-skills/docs/superpowers/README.md
Normal file
12
vendor-new/rev-skills/docs/superpowers/README.md
Normal file
@@ -0,0 +1,12 @@
|
||||
# superpowers 文档（历史存档）
|
||||
|
||||
本目录是技能库建设过程的历史记录，按日期归档：
|
||||
|
||||
- `specs/` —— 设计文档（当时获用户批准后落地）
|
||||
- `plans/` —— 实施计划（任务拆解与执行记录）
|
||||
|
||||
## 阅读须知（对 Agent 尤其重要）
|
||||
|
||||
- 本目录内容**冻结于各自日期**，不随技能修订同步更新——其中可能保留此后已被修正的错误表述
|
||||
- **当前事实以 `.claude/skills/` 下的技能文档为准**；已修正错误的核验依据与修复记录见 `docs/audit/`
|
||||
- 检索/引用时不要把本目录内容当现行技术指引：命中某条断言时，先到对应技能目录核对现文
|
||||
2186
vendor-new/rev-skills/docs/superpowers/plans/2026-08-07-re-skills.md
Normal file
2186
vendor-new/rev-skills/docs/superpowers/plans/2026-08-07-re-skills.md
Normal file
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,461 @@
|
||||
# reverse-skill 经验吸收 实现计划
|
||||
|
||||
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
|
||||
|
||||
**Goal:** 从 reverse-skill field-journal（MIT）吸收 12 个条目的经验到 10 个 rev-skills 技能，技能总数 107 不变。
|
||||
|
||||
**Architecture:** 纯技能文档扩展。每个任务 = 在目标技能「## 常见坑与陷阱」章节末尾追加改写后的坑条目（现象/原因/对策格式）+ 来源注明（MIT）。吸收素材见 /home/DslsDZC/rev-refs/extract-field-journal.md（59 个踩坑点）。
|
||||
|
||||
**Tech Stack:** Markdown / validate.mjs（npm test，现有）
|
||||
|
||||
## Global Constraints
|
||||
|
||||
- **红线 1 呈现中性**：禁用「最推荐」「强烈建议」等最高级强推措辞
|
||||
- **红线 2 隐私脱敏**：按提取稿「脱敏注意」泛化（厂商文件指纹/产品名/真实文件名全部泛化）
|
||||
- **版权**：每条吸收末尾注明「（来源：reverse-skill field-journal，MIT）」
|
||||
- **改写**：不逐字复制——按现象/原因/对策格式改写
|
||||
- **查重**：入库前 grep 目标技能（含 references/）；同现象已存在 → 跳过并在报告中记录
|
||||
- 工作区已干净（无未提交文件）；各任务 commit 只 `git add` 本任务列出的文件
|
||||
- 当前分支 `main`；`npm test` 全程预期 `OK: 107 skills validated`
|
||||
|
||||
---
|
||||
|
||||
### Task 1: re-go 吸收（Go Garble 对抗 + TLS 分片代理）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-go/SKILL.md`（「## 常见坑与陷阱」末尾追加）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 提取稿第 1、12 节素材
|
||||
- Produces: re-go 的 Garble 对抗与源码重建经验
|
||||
|
||||
- [ ] **Step 1: 查重**
|
||||
|
||||
Run: `grep -n "Garble\|GoReSym\|字符串" .claude/skills/re-go/SKILL.md`
|
||||
- 若已有同现象条目 → 跳过对应条并在报告中记录
|
||||
|
||||
- [ ] **Step 2: 追加坑条目**
|
||||
|
||||
在 `.claude/skills/re-go/SKILL.md` 的「## 常见坑与陷阱」章节末尾追加：
|
||||
|
||||
```markdown
|
||||
- **Garble 混淆的 Go 二进制**：现象——stripped + 随机函数名 + 字符串全空；原因——Garble 同时混淆函数名与字符串；对策——GoReSym 恢复 pclntab（函数边界不受名字混淆影响）→ GoResolver CFG 签名恢复标准库名 → GoStringUngarbler 批量解密字符串 → 从解密串找 C2/密钥
|
||||
- **Go 静态链接函数爆炸**：现象——5 万+ 函数看不过来；原因——整个 runtime 静态链接；对策——符号恢复后按包名过滤（只看用户代码包），先分包再筛业务
|
||||
- **Go 加密密钥定位**：现象——找不到 AES 密钥；原因——密钥运行时从多个常量拼接；对策——跟踪 `crypto/aes.NewCipher`（或 `crypto/cipher.NewGCM`）第一个参数来源，回溯拼接点
|
||||
- **Go 接口调用看不懂**：现象——反编译的 interface 调用是间接跳转；原因——Go interface 经 itab 分派；对策——定位 itab 表手动标注接口类型
|
||||
- **符号可用但签名缺失**：现象——函数名有、参数/类型没有；原因——新版本 Go 产物不带完整符号信息；对策——接受函数名可用、签名靠其他证据（配置反序列化类型/调用点）重建
|
||||
- **字符串噪声大**：现象——恢复的字符串混入大量标准库常量；原因——Go 标准库字符串常量；对策——按包级别过滤后再筛业务字符串
|
||||
- **源码重建原则**：现象——逐行还原不现实；原因——产物无源码对应；对策——按包重建可读代码、保留逻辑而非逐行一致（逻辑优先）
|
||||
（来源：reverse-skill field-journal，MIT）
|
||||
```
|
||||
|
||||
- [ ] **Step 3: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 107 skills validated`，无 FAIL
|
||||
|
||||
- [ ] **Step 4: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-go/SKILL.md
|
||||
git commit -m "经验: re-go 吸收 reverse-skill field-journal（Garble 对抗链/密钥定位/源码重建，MIT）"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 2: re-binary-core 吸收（ARM64 跳转表/XOR 解密器）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-binary-core/SKILL.md`（「## 常见坑与陷阱」末尾追加）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 提取稿第 2 节素材
|
||||
- Produces: re-binary-core 的平坦化轻量恢复经验
|
||||
|
||||
- [ ] **Step 1: 查重**
|
||||
|
||||
Run: `grep -n "跳转表\|控制流平坦\|XOR" .claude/skills/re-binary-core/SKILL.md`
|
||||
|
||||
- [ ] **Step 2: 追加坑条目**
|
||||
|
||||
在 `.claude/skills/re-binary-core/SKILL.md` 的「## 常见坑与陷阱」末尾追加：
|
||||
|
||||
```markdown
|
||||
- **间接跳转平坦化主函数**：现象——反编译器只识别函数前部 CFG，分发器处中断；原因——间接 BR 跳转表（控制流平坦化）；对策——按跳转表公式 `target = (table_entry + fixed_delta)` 枚举真实基本块，不依赖默认 CFG；符号长度远大于 CFG 识别长度时优先查 BR/BLR 间接表
|
||||
- **逐函数 XOR 字符串解密器**：现象——字符串扫描只看到少量路径；原因——文本用每字符串独立的循环 XOR；对策——识别「前 N 字节密钥 + 后 M 字节密文」布局，从解密器指令提取 key/output 长度，静态重放算法（对平坦化块局部常量传播即可恢复间接目标与字符串源地址，无需先完整去平坦化）
|
||||
- **自解压归档安全展开**：现象——解包目标含恶意路径；原因——归档内路径可构造；对策——逐成员校验后写出（拒绝绝对路径、`..`、链接、设备节点），不直接执行、不信任成员路径
|
||||
- **压缩载荷定位**：现象——只按魔数找压缩流会漏；原因——魔数不唯一/被混淆；对策——对候选偏移做完整解压测试（有效流校验），不只看头部
|
||||
（来源：reverse-skill field-journal，MIT）
|
||||
```
|
||||
|
||||
- [ ] **Step 3: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 107 skills validated`
|
||||
|
||||
- [ ] **Step 4: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-binary-core/SKILL.md
|
||||
git commit -m "经验: re-binary-core 吸收（跳转表枚举/逐函数 XOR 解密器/自解压安全展开，MIT）"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 3: re-deobfuscate 吸收（验证码 DSL VM）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-deobfuscate/SKILL.md`（「## 常见坑与陷阱」末尾追加）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 提取稿第 3 节素材
|
||||
- Produces: re-deobfuscate 的 DSL VM 对抗经验
|
||||
|
||||
- [ ] **Step 1: 查重**
|
||||
|
||||
Run: `grep -n "DSL\|VM\|opcode\|虚拟机" .claude/skills/re-deobfuscate/SKILL.md`
|
||||
|
||||
- [ ] **Step 2: 追加坑条目**
|
||||
|
||||
在 `.claude/skills/re-deobfuscate/SKILL.md` 的「## 常见坑与陷阱」末尾追加：
|
||||
|
||||
```markdown
|
||||
- **自定义 DSL VM（纯 JS 虚拟机）**：现象——大 JS 文件被当 WASM/常规混淆；原因——自定义解释器循环 + 自定义 opcode；对策——DSL VM 五步：case 提取 → opcode 分类 → 常量表分析 → 函数追踪 → 导出提取；先确认是纯 JS 解释器再决定工具链
|
||||
- **VM 导出函数隐藏**：现象——VM 文件中找不到导出函数名；原因——导出名被指令编码隐藏；对策——从模块注册中心提取真实导出（不通过 VM 文件表面暴露）
|
||||
- **流程就绪 ≠ 会话建立**：现象——接口返回成功但流程没起来；原因——成功只是会话确认；对策——以特定状态码/阶段标志判断流程真正就绪，别拿会话确认当启动
|
||||
（来源：reverse-skill field-journal，MIT）
|
||||
```
|
||||
|
||||
- [ ] **Step 3: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 107 skills validated`
|
||||
|
||||
- [ ] **Step 4: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-deobfuscate/SKILL.md
|
||||
git commit -m "经验: re-deobfuscate 吸收（DSL VM 五步/导出隐藏/流程就绪判断，MIT）"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 4: re-fw-extract 吸收（Cortex-M 分块 XOR）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-fw-extract/SKILL.md`（「## 常见坑与陷阱」末尾追加）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 提取稿第 4 节素材
|
||||
- Produces: re-fw-extract 的固件分块变换恢复经验
|
||||
|
||||
- [ ] **Step 1: 查重**
|
||||
|
||||
Run: `grep -n "XOR\|分块\|掩码" .claude/skills/re-fw-extract/SKILL.md`
|
||||
|
||||
- [ ] **Step 2: 追加坑条目**
|
||||
|
||||
在 `.claude/skills/re-fw-extract/SKILL.md` 的「## 常见坑与陷阱」末尾追加：
|
||||
|
||||
```markdown
|
||||
- **分块周期变换**：现象——单一全文件 XOR/旋转只在开头有效；原因——变换按块大小（常见 256/512/1024/2048/4096）重置；对策——先按常见 Flash/传输块大小检查变换是否按块重置周期，显式分块解码
|
||||
- **块首自带掩码混淆**：现象——高熵固件被当强加密；原因——分块自带掩码混淆（如 `mask = block[0]`、`plain[i] = ROR8(packed[i], n) XOR mask`）；对策——先用强 crib（向量表 SRAM 栈指针/Thumb Reset Vector）约束恢复首块，再验证模型
|
||||
- **众数 crib 不可靠**：现象——文本密集块用众数字节做掩码仍乱码；原因——最常见明文字节不一定是零；对策——改用块首字节模型，验证标准：乱码消失 + 第二份同系列固件复现 + round-trip 逐字节一致
|
||||
- **CRC 字符串 ≠ CRC 字段**：现象——看到 CRC 名字符串就假设末尾是标准 CRC；原因——字符串只是元数据键；对策——系统排除常见 CRC/硬件 CRC/Adler/累加族后保留为未知字段，不强行命名
|
||||
（来源：reverse-skill field-journal，MIT）
|
||||
```
|
||||
|
||||
- [ ] **Step 3: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 107 skills validated`
|
||||
|
||||
- [ ] **Step 4: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-fw-extract/SKILL.md
|
||||
git commit -m "经验: re-fw-extract 吸收（分块周期/块首掩码/强 crib 验证，MIT）"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 5: re-loader 吸收（ELF 自解压加载器）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-loader/SKILL.md`（「## 常见坑与陷阱」末尾追加）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 提取稿第 5 节素材
|
||||
- Produces: re-loader 的自解压加载器经验
|
||||
|
||||
- [ ] **Step 1: 查重**
|
||||
|
||||
Run: `grep -n "自解压\|PHDR\|mmap\|解压" .claude/skills/re-loader/SKILL.md`
|
||||
|
||||
- [ ] **Step 2: 追加坑条目**
|
||||
|
||||
在 `.claude/skills/re-loader/SKILL.md` 的「## 常见坑与陷阱」末尾追加：
|
||||
|
||||
```markdown
|
||||
- **伪装后缀的自解压加载器**：现象——readelf 报错无法解析；原因——PHDR 被故意填充损坏（干扰解析）；对策——忽略损坏的 PHDR 只看有效 LOAD 段；识别标准模式：入口 → 解压函数 → mmap(RW) → 解压 → mprotect(RX) → 跳转
|
||||
- **位操作密集代码反编译差**：现象——Hex-Rays 输出不可读；原因——ARM64 位操作密集；对策——切反汇编视图手动分析（位流读取/移位/条件分支场景反编译器不如直接看汇编）
|
||||
- **自写解压器 bug（carry 语义）**：现象——Python 重写解压器输出错误；原因——refill 路径返回值/进位语义误判；对策——仔细对照汇编核对 carry 语义，用已知明文加断言对比
|
||||
- **入口偏移不确定**：现象——payload 入口字段含义不明；原因——数据表字段无文档；对策——跟踪 loader 实际跳转目标（`br mmap_base + offset`）确认入口
|
||||
- **后缀不可信**：现象——按后缀选工具链出错；原因——自解压样本伪装扩展名；对策——`file` 永远是第一步；解析器选容错实现（可处理损坏头）
|
||||
（来源：reverse-skill field-journal，MIT）
|
||||
```
|
||||
|
||||
- [ ] **Step 3: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 107 skills validated`
|
||||
|
||||
- [ ] **Step 4: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-loader/SKILL.md
|
||||
git commit -m "经验: re-loader 吸收（自解压模式/损坏 PHDR/carry 语义，MIT）"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 6: re-game 吸收（Unity IL2CPP）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-game/SKILL.md`（「## 常见坑与陷阱」末尾追加）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 提取稿第 6 节素材
|
||||
- Produces: re-game 的 IL2CPP 还原经验
|
||||
|
||||
- [ ] **Step 1: 查重**
|
||||
|
||||
Run: `grep -n "IL2CPP\|Il2Cpp\|metadata" .claude/skills/re-game/SKILL.md`
|
||||
|
||||
- [ ] **Step 2: 追加坑条目**
|
||||
|
||||
在 `.claude/skills/re-game/SKILL.md` 的「## 常见坑与陷阱」末尾追加：
|
||||
|
||||
```markdown
|
||||
- **IL2CPP 元数据还原**：现象——dump 工具报版本不支持/输出不全；原因——Unity 版本改 metadata 格式；对策——升级 dump 工具（Il2CppDumper 或 Il2CppInspectorRedux），必须用同一次 dump 的产物对（script.json 与 so 匹配，换 IDA 清缓存）
|
||||
- **加密的 global-metadata.dat**：现象——元数据文件是密文；原因——反作弊/自定义加密；对策——找初始化解密函数（il2cpp_init 周围），Frida 在 mmap/read 后 dump 内存中已解密的元数据再喂给 dump 工具
|
||||
- **IL2CPP 方法 hook**：现象——Frida 裸 hook 报错；原因——IL2CPP 方法非标准 Java/ObjC，需按 metadata 算偏移；对策——用 frida-il2cpp-bridge 库，不硬写 Interceptor.attach
|
||||
- **patch 后闪退**：现象——静态修改后启动崩溃；原因——文件 hash 校验/anti-tamper；对策——hook 优先（不改文件）；必须静态 patch 时同步处理校验逻辑；重打包后删 META-INF 重新签名（apksigner）
|
||||
（来源：reverse-skill field-journal，MIT）
|
||||
```
|
||||
|
||||
- [ ] **Step 3: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 107 skills validated`
|
||||
|
||||
- [ ] **Step 4: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-game/SKILL.md
|
||||
git commit -m "经验: re-game 吸收（IL2CPP 元数据/加密 metadata/方法 hook，MIT）"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 7: re-frida 吸收（OkHttp SSL Pinning，查重优先）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-frida/SKILL.md`（「## 常见坑与陷阱」末尾追加）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 提取稿第 7 节素材
|
||||
- Produces: re-frida 的分层绕过与反检测经验
|
||||
|
||||
- [ ] **Step 1: 查重（关键步骤）**
|
||||
|
||||
Run: `grep -n "CertificatePinner\|TrustManager\|pinning\|固定" .claude/skills/re-frida/SKILL.md .claude/skills/re-frida/references/frida-scripts.md`
|
||||
- frida-scripts.md 已有「SSL 固定绕过」模板（TrustManager + CertificatePinner）——**该条跳过**，报告记录
|
||||
- 其余条（分层 hook 思维/反 Frida 检测/ProGuard 混淆定位）查重后决定
|
||||
|
||||
- [ ] **Step 2: 追加坑条目（查重后剩余）**
|
||||
|
||||
在 `.claude/skills/re-frida/SKILL.md` 的「## 常见坑与陷阱」末尾追加（按 Step 1 查重结果裁剪，未命中才写入）：
|
||||
|
||||
```markdown
|
||||
- **多层 TLS 校验栈**：现象——单点 hook 后部分请求仍 SSL 错误；原因——App 同时用 OkHttp/原生 HttpsURLConnection/Conscrypt 多套栈；对策——分层覆盖（OkHttp CertificatePinner + TrustManagerImpl.verifyChain + HostnameVerifier 同时 hook），全栈覆盖才算绕过完成
|
||||
- **ProGuard 混淆后定位目标类**：现象——类名被改成短名；原因——混淆；对策——jadx 里 Find Usages 反查谁实例化关键 Builder，从实例化点反推原类
|
||||
（来源：reverse-skill field-journal，MIT）
|
||||
```
|
||||
|
||||
- [ ] **Step 3: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 107 skills validated`
|
||||
|
||||
- [ ] **Step 4: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-frida/SKILL.md
|
||||
git commit -m "经验: re-frida 吸收（多层 TLS 栈覆盖/混淆定位，MIT）"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 8: re-ios-jb 吸收（越狱检测绕过）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-ios-jb/SKILL.md`（「## 常见坑与陷阱」末尾追加）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 提取稿第 8 节素材
|
||||
- Produces: re-ios-jb 的检测绕过与抓包经验
|
||||
|
||||
- [ ] **Step 1: 查重**
|
||||
|
||||
Run: `grep -n "越狱检测\|jailbreak\|spawn\|证书信任" .claude/skills/re-ios-jb/SKILL.md`
|
||||
|
||||
- [ ] **Step 2: 追加坑条目**
|
||||
|
||||
在 `.claude/skills/re-ios-jb/SKILL.md` 的「## 常见坑与陷阱」末尾追加：
|
||||
|
||||
```markdown
|
||||
- **检测在加载期执行**：现象——hook 来不及，App 启动前已检测；原因——检测在 `+load` / `__attribute__((constructor))` 中执行；对策——spawn 模式在最早时机注入（`-f` + 启动即 hook）
|
||||
- **双重校验**：现象——绕过越狱检测后仍闪退；原因——越狱检测与 SSL Pinning 叠加；对策——同时禁用两者，不要只处理一个
|
||||
- **hook 系统函数波及自身**：现象——hook stat 后 App 卡住；原因——系统级 hook 影响正常逻辑；对策——按 caller 过滤，只 hook 应用自身代码触发的调用
|
||||
- **证书信任开关**：现象——mitmproxy 装证书后仍 SSL 错误；原因——iOS 14+ 需在证书信任设置手动开启；对策——装完证书后到「通用 → 关于本机 → 证书信任设置」勾选
|
||||
- **越狱检测 hook 模板**：现象——需要快速绕过常见检测；对策——拦截文件存在性检查（越狱路径列表返回不存在）+ fork 返回 -1（越狱机能 fork，非越狱机返回 -1）
|
||||
（来源：reverse-skill field-journal，MIT）
|
||||
```
|
||||
|
||||
- [ ] **Step 3: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 107 skills validated`
|
||||
|
||||
- [ ] **Step 4: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-ios-jb/SKILL.md
|
||||
git commit -m "经验: re-ios-jb 吸收（加载期检测/双重校验/证书信任开关，MIT）"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 9: re-proto-rev 吸收（PCAP 自定义协议）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-proto-rev/SKILL.md`（「## 常见坑与陷阱」末尾追加）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 提取稿第 9 节素材
|
||||
- Produces: re-proto-rev 的帧界/加密判定/闭环验证经验
|
||||
|
||||
- [ ] **Step 1: 查重**
|
||||
|
||||
Run: `grep -n "熵\|dissector\|长度字段\|nonce" .claude/skills/re-proto-rev/SKILL.md`
|
||||
|
||||
- [ ] **Step 2: 追加坑条目**
|
||||
|
||||
在 `.claude/skills/re-proto-rev/SKILL.md` 的「## 常见坑与陷阱」末尾追加：
|
||||
|
||||
```markdown
|
||||
- **私有协议无解析器**：现象——Wireshark 只显示 Data；原因——私有协议无 dissector；对策——写 Lua dissector（<100 行）或 Python 离线分析
|
||||
- **数据无规律 → 先验加密**：现象——每帧都不同；原因——压缩/加密层；对策——熵分析（>7.5 几乎肯定加密），加密层找 nonce/IV 字段；长度字段解不出时按「长度可能 little/big-endian、含/不含自身」列方程组解语义
|
||||
- **重放被拒**：现象——数据正确但服务端不响应；原因——协议带递增 seq/nonce；对策——搞清楚 seq 计算方式（前一帧 hash 或递增计数器），复现时正确推进
|
||||
- **闭环验证**：现象——协议还原是否成立无判据；对策——用还原的帧结构写 client 发一帧，服务端响应一致才算成立
|
||||
（来源：reverse-skill field-journal，MIT）
|
||||
```
|
||||
|
||||
- [ ] **Step 3: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 107 skills validated`
|
||||
|
||||
- [ ] **Step 4: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-proto-rev/SKILL.md
|
||||
git commit -m "经验: re-proto-rev 吸收（私有协议解析/熵判加密/seq 推进，MIT）"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 10: re-script-deob + re-crypto-id 吸收（JS 签名）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-script-deob/SKILL.md`（「## 常见坑与陷阱」末尾追加）
|
||||
- Modify: `.claude/skills/re-crypto-id/SKILL.md`（「## 常见坑与陷阱」末尾追加）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 提取稿第 10 节素材
|
||||
- Produces: re-script-deob 的 webpack 定位经验 + re-crypto-id 的签名模式识别经验
|
||||
|
||||
- [ ] **Step 1: 查重**
|
||||
|
||||
Run: `grep -n "webpack\|签名\|initiator" .claude/skills/re-script-deob/SKILL.md .claude/skills/re-crypto-id/SKILL.md`
|
||||
|
||||
- [ ] **Step 2: 追加坑条目（2 文件）**
|
||||
|
||||
`.claude/skills/re-script-deob/SKILL.md` 的「## 常见坑与陷阱」末尾追加：
|
||||
|
||||
```markdown
|
||||
- **webpack 打包定位签名函数**：现象——搜 "sign" 结果太多；原因——打包压缩变量名；对策——搜特征串（`sign=`）或用网络面板 initiator 列回溯发起请求的调用栈（比搜源码快）
|
||||
- **本地复现结果不一致**：现象——签名逻辑对但服务端不认；原因——参数排序/时间戳精度不对；对策——核对源码 sort 逻辑（按 key 字母序 + 特殊字符规则）；时间戳用 `Math.floor(Date.now() / 1000)`（秒级）
|
||||
- **密钥在另一 chunk**：现象——签名函数里找不到密钥；原因——密钥经 require 从其他 chunk 引入；对策——签名函数断点处 console.log 打印密钥变量
|
||||
（来源：reverse-skill field-journal，MIT）
|
||||
```
|
||||
|
||||
`.claude/skills/re-crypto-id/SKILL.md` 的「## 常见坑与陷阱」末尾追加：
|
||||
|
||||
```markdown
|
||||
- **常见签名模式速查**：现象——签名算法识别慢；对策——按模式快速对照：HmacSHA256(sorted_params, key) 最常见；MD5(params + salt + timestamp) 较老系统；AES(JSON.stringify(params), key) 是加密而非签名；RSA sign 少见（多为金融类）
|
||||
（来源：reverse-skill field-journal，MIT）
|
||||
```
|
||||
|
||||
- [ ] **Step 3: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 107 skills validated`
|
||||
|
||||
- [ ] **Step 4: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-script-deob/SKILL.md .claude/skills/re-crypto-id/SKILL.md
|
||||
git commit -m "经验: re-script-deob/re-crypto-id 吸收（webpack 定位/签名模式速查，MIT）"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 11: re-managed 吸收（Electron Bytenode 更新链）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-managed/SKILL.md`（「## 常见坑与陷阱」末尾追加）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 提取稿第 11 节素材
|
||||
- Produces: re-managed 的 Electron/Bytenode 分析经验
|
||||
|
||||
- [ ] **Step 1: 查重**
|
||||
|
||||
Run: `grep -n "Electron\|Bytenode\|ASAR\|字节码" .claude/skills/re-managed/SKILL.md`
|
||||
|
||||
- [ ] **Step 2: 追加坑条目**
|
||||
|
||||
在 `.claude/skills/re-managed/SKILL.md` 的「## 常见坑与陷阱」末尾追加：
|
||||
|
||||
```markdown
|
||||
- **Bytenode 字节码绑定 ABI**：现象——宿主 Node 加载 JSC 失败；原因——Bytenode 字节码绑定特定 V8/Node ABI；对策——用样本自带 Electron 的 RunAsNode 模式（`ELECTRON_RUN_AS_NODE=1`）执行，不启动业务 GUI
|
||||
- **注册面 ≠ 执行面**：现象——枚举 handler 无法证明数据流；原因——注册存在不等于路径执行；对策——先枚举 IPC/preload 注册面，再对高风险 handler 用 mock fixture 调用并捕获副作用（URL 接收/下载/解压/spawn 参数），形成证据闭环
|
||||
- **更新链五元组取证**：现象——更新流程证据不全；原因——链路节点分散；对策——按 `source URL → downloader → archive path → extractor → executable` 每个节点保存哈希与时间戳
|
||||
- **签名状态分四态**：现象——双签名 DLL 判断含糊；原因——各签名状态可能不同；对策——`signtool verify /pa /all /v` 逐签名检查（存在性/有效期/时间戳/信任验证分开报告）
|
||||
- **静态能力 ≠ 已执行**：现象——native 字符串/导入显示高权限能力；原因——导入是线索不是证据；对策——能力描述结合 xref/调用链，报告分栏「条件性能力」与「已观察行为」
|
||||
（来源：reverse-skill field-journal，MIT）
|
||||
```
|
||||
|
||||
- [ ] **Step 3: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 107 skills validated`
|
||||
|
||||
- [ ] **Step 4: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-managed/SKILL.md
|
||||
git commit -m "经验: re-managed 吸收（Bytenode ABI/注册面执行面分离/更新链取证，MIT）"
|
||||
```
|
||||
@@ -0,0 +1,509 @@
|
||||
# 4 个语言逆向技能 实现计划
|
||||
|
||||
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
|
||||
|
||||
**Goal:** 新增 4 个语言逆向原子技能（re-swift / re-zig / re-nim / re-fp-runtime）+ 挂载同步，技能总数 97 → 101。
|
||||
|
||||
**Architecture:** 纯技能文档扩展。4 个新技能目录（SKILL.md，按 docs/skill-template.md 原子技能规范，全部挂 re-binary-core）+ 挂载（re-binary-core 子技能/选择树、re-ios/re-macos 跨域）+ 计数同步（README / AGENTS / marketplace）。
|
||||
|
||||
**Tech Stack:** Markdown / YAML frontmatter / validate.mjs（npm test，现有）
|
||||
|
||||
## Global Constraints
|
||||
|
||||
- **红线 1 呈现中性**：禁用「最推荐」「强烈建议」等最高级强推措辞
|
||||
- **红线 2 隐私脱敏**：内容不指向具体项目/公司/产品
|
||||
- **不绑定具体工具**：方法为核心，工具为可替换示例；「工具准备」按模板给跨 OS 安装命令
|
||||
- validate.mjs：frontmatter `name`=目录名、`description` 非空、`type: atomic` 必含「## 工具准备」、`[[链接]]` 必须解析
|
||||
- 工作区已干净（无未提交文件）——所有目标文件（含 re-binary-core/SKILL.md）可正常修改提交；各任务 commit 只 `git add` 本任务列出的文件
|
||||
- 当前分支 `main`；`npm test` 预期按任务标注递增（98 → 101）
|
||||
|
||||
---
|
||||
|
||||
### Task 1: 创建 re-swift 技能
|
||||
|
||||
**Files:**
|
||||
- Create: `.claude/skills/re-swift/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无（新目录）
|
||||
- Produces: 技能目录 `re-swift`（供 Task 5 的 [[re-swift]] 链接解析；计数 97 → 98）
|
||||
|
||||
- [ ] **Step 1: 创建目录与 SKILL.md**
|
||||
|
||||
```bash
|
||||
mkdir -p .claude/skills/re-swift
|
||||
```
|
||||
|
||||
写入 `.claude/skills/re-swift/SKILL.md`：
|
||||
|
||||
````markdown
|
||||
---
|
||||
name: re-swift
|
||||
type: atomic
|
||||
description: >
|
||||
Swift 二进制逆向：mangling 解码、协议 witness table、闭包捕获、ObjC 互操作。
|
||||
触发词：Swift逆向、swiftc、witness table、swift demangle、闭包捕获、Swift 产物。
|
||||
---
|
||||
|
||||
# Swift 逆向
|
||||
|
||||
## 何时使用 / 何时不用
|
||||
|
||||
- 用：Swift 产物（Mach-O/ELF 含 Swift mangling 特征 `$s` 前缀）
|
||||
- 不用：纯 ObjC（走 [[re-ios]] / [[re-macos]] 的 ObjC 路径）
|
||||
|
||||
## 工具准备
|
||||
|
||||
### swift-demangle（Swift 工具链，mangling 解码）
|
||||
|
||||
- macOS: Xcode 自带（`xcrun swift-demangle`）；Linux: `apt install swiftlang` 或 Swift 官方工具链
|
||||
- Windows: Swift 官方工具链
|
||||
- 验证: `echo '$s3foo3bar' | swift-demangle`（输出可读形式）
|
||||
|
||||
### llvm-objdump（反汇编辅助）
|
||||
|
||||
- 安装与验证见 [[re-cpp-abi]] 工具准备
|
||||
|
||||
### Ghidra / IDA（反编译底座）
|
||||
|
||||
- 安装与验证见 [[re-ghidra]] / [[re-ida]]
|
||||
|
||||
## 操作步骤
|
||||
|
||||
按顺序执行，每步产物存档（路径 + sha256，见 [[re-triage]]）。
|
||||
|
||||
1. **产物识别**：
|
||||
```sh
|
||||
strings sample | grep -E '^\$s' | head
|
||||
readelf -s sample 2>/dev/null | grep -E 'swift_' | head # ELF；Mach-O 用 llvm-nm
|
||||
```
|
||||
- `$s` mangling 前缀是 Swift 标志；swift_* 运行时导入（swift_retain / swift_release / swift_allocObject）确认
|
||||
- 纯 ObjC 无 `$s` → 转 [[re-ios]] / [[re-macos]]
|
||||
|
||||
2. **mangling 解码（批量）**：
|
||||
```sh
|
||||
readelf -s sample | grep '^\$s' | awk '{print $8}' | swift-demangle | head -20
|
||||
```
|
||||
- 解码内容：模块名/类型/函数签名/泛型参数展开
|
||||
- 解码结果写入符号表（供 [[re-ghidra]] / [[re-ida]] 重命名）
|
||||
|
||||
3. **协议 witness table**：
|
||||
- witness table 是协议方法的分发表（Swift 动态分派的核心）
|
||||
- 定位：搜索 `swift_witnessTable` 相关引用 / 协议 conformance 记录（`_swift_getWitnessTable` 调用点）
|
||||
- 还原：表内槽位 = 协议要求的方法实现地址 → 结合 [[re-cpp-abi]] 的 vtable 恢复思路反推协议一致性
|
||||
|
||||
4. **闭包捕获**：
|
||||
- 闭包是 context 对象：捕获变量布局（按捕获顺序 + 引用语义标记）
|
||||
- 定位：`swift_allocObject` 调用点 → context 分配 → 捕获字段初始化
|
||||
- 还原：context 结构体字段 → 捕获变量名/类型（与函数签名关联）
|
||||
|
||||
5. **ObjC 互操作**：
|
||||
- `@objc` 桥接：Swift 类经 ObjC runtime 可见（NSObject 子类、消息发送 objc_msgSend）
|
||||
- 分析：ObjC 方法列表（class-dump 思路）→ Swift 实现入口（桥接 thunk）
|
||||
- 混合产物：先走 ObjC 路径（[[re-ios]] / [[re-macos]]）再进 Swift 层
|
||||
|
||||
## 跨域联合
|
||||
|
||||
- [[re-binary-core]] 网关：本技能归属（选择树「Swift 产物」分支）
|
||||
- [[re-ios]] / [[re-macos]]：生态衔接（ObjC 层、App 层分析）
|
||||
- [[re-cpp-abi]]：vtable/witness table 恢复思路同源
|
||||
- [[analysis-contract]]：符号表按数据契约传递
|
||||
|
||||
## 常见坑与陷阱
|
||||
|
||||
- **mangling 版本差异**：现象——新版本 Swift 产物解码失败；原因——mangling 方案演进；对策——升级 swift-demangle 匹配目标编译版本
|
||||
- **泛型展开符号爆炸**：现象——解码输出大量 `$s...Gy` 泛型实例；原因——泛型特化；对策——按模块/类型聚类过滤
|
||||
- **witness table 无符号名**：现象——分发表槽位全是裸地址；原因——协议 conformance 无命名符号；对策——结合协议方法调用点反推
|
||||
- **闭包捕获含引用语义**：现象——context 字段是引用计数对象；原因——捕获变量含类实例；对策——按 swift_retain/release 调用点确认引用字段
|
||||
- **纯 ObjC 误入**：现象——无 `$s` 却按 Swift 流程走；原因——产物实为 ObjC；对策——步骤 1 先确认（无 `$s` 即转）
|
||||
````
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 98 skills validated`（[[链接]]：re-ios/re-macos/re-cpp-abi/re-ghidra/re-ida/re-triage/analysis-contract 均存在）
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-swift/SKILL.md
|
||||
git commit -m "feat: re-swift 技能——mangling/witness table/闭包捕获/ObjC 互操作"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 2: 创建 re-zig 技能
|
||||
|
||||
**Files:**
|
||||
- Create: `.claude/skills/re-zig/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无（新目录）
|
||||
- Produces: 技能目录 `re-zig`（供 Task 5 的 [[re-zig]] 链接解析；计数 98 → 99）
|
||||
|
||||
- [ ] **Step 1: 创建目录与 SKILL.md**
|
||||
|
||||
```bash
|
||||
mkdir -p .claude/skills/re-zig
|
||||
```
|
||||
|
||||
写入 `.claude/skills/re-zig/SKILL.md`：
|
||||
|
||||
````markdown
|
||||
---
|
||||
name: re-zig
|
||||
type: atomic
|
||||
description: >
|
||||
Zig 编译产物逆向：产物识别、comptime 展开、panic/错误处理路径、C ABI 边界。
|
||||
触发词：Zig逆向、zig、comptime、zig 产物、panic。
|
||||
---
|
||||
|
||||
# Zig 逆向
|
||||
|
||||
## 何时使用 / 何时不用
|
||||
|
||||
- 用：Zig 产物（无 C++ RTTI/异常表、panicking 函数特征）
|
||||
- 不用：C/C++ 产物（走 [[re-cpp-abi]]）
|
||||
|
||||
## 工具准备
|
||||
|
||||
### readelf / llvm-nm（符号与节分析）
|
||||
|
||||
- 安装与验证见 [[re-cpp-abi]] 工具准备
|
||||
|
||||
### Ghidra / IDA（反编译底座）
|
||||
|
||||
- 安装与验证见 [[re-ghidra]] / [[re-ida]]
|
||||
|
||||
## 操作步骤
|
||||
|
||||
按顺序执行，每步产物存档（路径 + sha256，见 [[re-triage]]）。
|
||||
|
||||
1. **产物识别**：
|
||||
```sh
|
||||
readelf -s sample | grep -iE 'panicking|std.debug|zig' | head
|
||||
readelf -S sample | grep -E 'eh_frame|gcc_except' # 无 C++ 异常表特征
|
||||
```
|
||||
- Zig 特征：panicking 函数（panic 处理链）、std 符号模式（std.debug.print 等）、**无 C++ RTTI/异常表**（对比 [[re-cpp-abi]] 的 RTTI/异常密集特征）
|
||||
- 与 C 混合编译：Zig 符号与 C 符号共存（见步骤 4 边界）
|
||||
|
||||
2. **导出符号与启动路径**：
|
||||
```sh
|
||||
readelf -s sample | grep -E 'start|main|init' | head
|
||||
```
|
||||
- 启动路径：`_start` → 运行时初始化 → `main`（Zig 的 main 入口）
|
||||
- comptime 展开产物：编译期计算已内联/展开——无对应源码结构，按行为分析
|
||||
|
||||
3. **panic/错误处理路径**：
|
||||
- panic 链：`@panic` → panic 函数（打印 + abort）——定位 panic 调用点可找输入校验/不变量
|
||||
- 错误联合（error union）：`!T` 类型布局（错误码 + 值），调用点检查 `orelse`/`catch` 分支
|
||||
- 分析：错误路径是逆向重点（校验逻辑、失败分支）
|
||||
|
||||
4. **C ABI 边界**：
|
||||
- `@extern` / `@cImport`：Zig 调用 C 库（导入表清晰可查）
|
||||
- 混合产物：按符号来源区分（Zig 符号 vs C 符号——链接器分组/节归属）
|
||||
- 边界处是逻辑入口（Zig 主体逻辑在边界内侧）
|
||||
|
||||
## 跨域联合
|
||||
|
||||
- [[re-binary-core]] 网关：本技能归属（选择树「Zig 产物」分支）
|
||||
- [[re-cpp-abi]]：边界区分（无 RTTI/异常 → 非 C++）
|
||||
- [[analysis-contract]]：符号表按数据契约传递
|
||||
|
||||
## 常见坑与陷阱
|
||||
|
||||
- **comptime 展开导致符号膨胀**：现象——产物符号与源码不对应；原因——编译期展开/内联；对策——按行为分析而非源码映射
|
||||
- **panic 路径误导**：现象——大量 panic 处理代码被当主逻辑；原因——错误路径与正常路径交织；对策——先分离 panic 调用点（校验），再分析正常路径
|
||||
- **错误联合布局版本差异**：现象——错误码读取错位；原因——error union 布局随版本变化；对策——按目标版本确认布局（错误码位宽/对齐）
|
||||
- **与 C 混合编译难分界**：现象——Zig/C 符号混杂；原因——混合编译；对策——按符号来源与节归属分组，边界处进 Zig 逻辑
|
||||
- **无异常表 ≠ 无保护**：现象——误判无错误处理；原因——Zig 错误处理走 error union 不走异常表；对策——查错误联合调用点（`catch`/`orelse` 分支）
|
||||
````
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 99 skills validated`（[[链接]]：re-cpp-abi/re-ghidra/re-ida/re-triage/analysis-contract 均存在）
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-zig/SKILL.md
|
||||
git commit -m "feat: re-zig 技能——产物识别/comptime/panic 与错误路径"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 3: 创建 re-nim 技能
|
||||
|
||||
**Files:**
|
||||
- Create: `.claude/skills/re-nim/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无（新目录）
|
||||
- Produces: 技能目录 `re-nim`（供 Task 5 的 [[re-nim]] 链接解析；计数 99 → 100）
|
||||
|
||||
- [ ] **Step 1: 创建目录与 SKILL.md**
|
||||
|
||||
```bash
|
||||
mkdir -p .claude/skills/re-nim
|
||||
```
|
||||
|
||||
写入 `.claude/skills/re-nim/SKILL.md`：
|
||||
|
||||
````markdown
|
||||
---
|
||||
name: re-nim
|
||||
type: atomic
|
||||
description: >
|
||||
Nim 编译产物逆向：运行时识别、NimString 结构、异常与 GC 路径。
|
||||
触发词：Nim逆向、nim、NimString、NimMain、nim 产物。
|
||||
---
|
||||
|
||||
# Nim 逆向
|
||||
|
||||
## 何时使用 / 何时不用
|
||||
|
||||
- 用：Nim 产物（NimMain / GC 符号、NimString 结构特征）
|
||||
- 不用：C 产物（走 [[re-binary-core]] 通用）
|
||||
|
||||
## 工具准备
|
||||
|
||||
### readelf / llvm-nm（符号分析）
|
||||
|
||||
- 安装与验证见 [[re-cpp-abi]] 工具准备
|
||||
|
||||
### Ghidra / IDA（反编译底座）
|
||||
|
||||
- 安装与验证见 [[re-ghidra]] / [[re-ida]]
|
||||
|
||||
## 操作步骤
|
||||
|
||||
按顺序执行，每步产物存档（路径 + sha256，见 [[re-triage]]）。
|
||||
|
||||
1. **产物识别**：
|
||||
```sh
|
||||
readelf -s sample | grep -iE 'NimMain|nimGC|NimString' | head
|
||||
```
|
||||
- Nim 特征：`NimMain`（入口）、GC 符号（nimGC_*）、`NimString` 结构
|
||||
- 入口：`NimMain` 调用链（运行时初始化 → 模块初始化 → main）
|
||||
|
||||
2. **字符串与序列结构**：
|
||||
- NimStringV2 布局：`len`（int）+ `reserved`（int）+ `data`（char* 或内联）——按版本确认字段序
|
||||
- 定位：`newString` 分配调用点 → 结构布局 → 字符串操作函数（`eqStrings` 等）
|
||||
- 分析：字符串比较点是关键逻辑（校验/协议/命令分发）
|
||||
|
||||
3. **异常与 raises 路径**：
|
||||
- Nim 异常：`raise` → 异常对象分配 → 异常表（Nim 有异常表，与 C++ 不同）
|
||||
- 定位：异常处理入口（`nimSetjmp` / 异常表）→ catch 分支
|
||||
- 分析：异常路径揭示输入校验与失败处理
|
||||
|
||||
4. **GC 与引用计数**：
|
||||
- refc（旧默认）：引用计数——`nimIncRef` / `nimDecRef` 调用点
|
||||
- orc（新默认）：循环收集——`nimGC_*` 分配/收集
|
||||
- 分析：GC 调用点帮助识别对象生命周期与所有权（配合字符串结构）
|
||||
|
||||
## 跨域联合
|
||||
|
||||
- [[re-binary-core]] 网关：本技能归属（选择树「Nim 产物」分支）
|
||||
- [[analysis-contract]]：符号表按数据契约传递
|
||||
|
||||
## 常见坑与陷阱
|
||||
|
||||
- **GC 版本差异（refc/orc）**：现象——找不到引用计数调用；原因——orc 无显式 inc/dec；对策——按 Nim 版本确认 GC 模式再分析
|
||||
- **NimString 布局随版本变化**：现象——data 字段偏移错；原因——版本演进；对策——按目标版本确认（字段序 len/reserved/data）
|
||||
- **导出符号被 strip**：现象——无 NimMain/NimString 符号；原因——strip 处理；对策——按特征字符串/运行时行为识别（[[re-triage]] 初勘兜底）
|
||||
- **C 混合编译**：现象——Nim/C 符号混杂；原因——`{.compile:}` 混合；对策——按符号来源分组，Nim 侧进本技能路径
|
||||
- **字符串比较点误判**：现象——关键校验被当普通比较；原因——eqStrings 包装；对策——追踪 Nim 字符串函数调用点定位比较逻辑
|
||||
````
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 100 skills validated`（[[链接]]：re-cpp-abi/re-ghidra/re-ida/re-triage/analysis-contract 均存在）
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-nim/SKILL.md
|
||||
git commit -m "feat: re-nim 技能——运行时识别/NimString/异常与 GC 路径"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 4: 创建 re-fp-runtime 技能
|
||||
|
||||
**Files:**
|
||||
- Create: `.claude/skills/re-fp-runtime/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无（新目录）
|
||||
- Produces: 技能目录 `re-fp-runtime`（供 Task 5 的 [[re-fp-runtime]] 链接解析；计数 100 → 101）
|
||||
|
||||
- [ ] **Step 1: 创建目录与 SKILL.md**
|
||||
|
||||
```bash
|
||||
mkdir -p .claude/skills/re-fp-runtime
|
||||
```
|
||||
|
||||
写入 `.claude/skills/re-fp-runtime/SKILL.md`：
|
||||
|
||||
````markdown
|
||||
---
|
||||
name: re-fp-runtime
|
||||
type: atomic
|
||||
description: >
|
||||
函数式语言运行时逆向（Haskell/OCaml）：闭包/堆对象模型、调用约定、数据流优先策略。
|
||||
触发词：Haskell逆向、OCaml逆向、GHC RTS、thunk、STG、OCaml runtime、闭包、函数式产物。
|
||||
---
|
||||
|
||||
# 函数式运行时逆向（Haskell / OCaml）
|
||||
|
||||
## 何时使用 / 何时不用
|
||||
|
||||
- 用：Haskell/OCaml 产物（GHC RTS 符号、OCaml block 头特征）
|
||||
- 不用：命令式语言产物（各归各技能：C++ → [[re-cpp-abi]]、Go → [[re-go]]、Rust → [[re-rust]]）
|
||||
|
||||
## 工具准备
|
||||
|
||||
### readelf / llvm-nm（符号分析）
|
||||
|
||||
- 安装与验证见 [[re-cpp-abi]] 工具准备
|
||||
|
||||
### ghc 工具链（Haskell 侧，可选）
|
||||
|
||||
- Linux/macOS: GHC 安装包（`apt install ghc` / `brew install ghc` / ghcup）；验证: `ghc --version`
|
||||
|
||||
### ocamlobjinfo（OCaml 侧，可选）
|
||||
|
||||
- Linux/macOS: OCaml 工具链（`apt install ocaml` / `brew install ocaml`）；验证: `ocamlobjinfo -version`
|
||||
|
||||
### Ghidra / IDA（反编译底座）
|
||||
|
||||
- 安装与验证见 [[re-ghidra]] / [[re-ida]]
|
||||
|
||||
## 操作步骤
|
||||
|
||||
按顺序执行；逆向着重**数据流**而非控制流（函数式产物控制流被打散，见坑 4）。每步产物存档（路径 + sha256，见 [[re-triage]]）。
|
||||
|
||||
1. **运行时识别**：
|
||||
```sh
|
||||
readelf -s sample | grep -iE 'ghc|stg_|RTS|HsMain' | head # GHC 特征
|
||||
readelf -s sample | grep -iE 'caml_|camlMain' | head # OCaml 特征
|
||||
```
|
||||
- GHC：`HsMain` 入口、`stg_*` 运行时符号、`RTS` 段
|
||||
- OCaml：`camlMain` 入口、`caml_*` 运行时符号
|
||||
- **字节码 vs 原生**：OCaml 字节码产物（非 native）特征（`caml_start_program`）→ 字节码可反汇编还原；native 产物走常规反编译
|
||||
|
||||
2. **闭包与堆对象**：
|
||||
- GHC：thunk（未求值闭包）与已求值值的堆对象布局——closure header（info table 指针）+ 字段；CAF（顶层常量）在启动时初始化
|
||||
- OCaml：block 头（tag + 大小，低 2 位 = 标记）；tagged int（奇数值 = 直接整数，偶数值 = 指针）
|
||||
- 分析：字段与构造器是主要线索（数据流优先）
|
||||
|
||||
3. **调用约定**：
|
||||
- GHC：函数参数经栈传递（STG 机），返回在栈顶——与常规寄存器约定不同
|
||||
- OCaml：参数经寄存器（前 N 个）传递，闭包调用经 `caml_applyN`
|
||||
- 分析：先识别运行时包装（`caml_apply` / stg 入口）再进用户逻辑
|
||||
|
||||
4. **分析策略（数据流优先）**：
|
||||
- 控制流打散：惰性求值导致求值顺序不可预测——静态控制流分析价值低
|
||||
- 数据流线索：闭包字段初始化点（构造器参数）、模式匹配分支（构造器标签分发）、字符串/常量引用
|
||||
- 产出：数据流图（构造器 → 字段 → 使用点）替代控制流图（与 [[analysis-contract]] 数据契约衔接）
|
||||
|
||||
## 跨域联合
|
||||
|
||||
- [[re-binary-core]] 网关：本技能归属（选择树「Haskell/OCaml 产物」分支）
|
||||
- [[analysis-contract]]：数据流图按数据契约传递
|
||||
|
||||
## 常见坑与陷阱
|
||||
|
||||
- **RTS 版本差异**：现象——closure 布局解读失败；原因——GHC/OCaml 版本演进；对策——按目标版本确认布局
|
||||
- **thunk 惰性求值误导**：现象——未求值闭包被当已求值数据；原因——惰性求值；对策——区分 thunk 头（info table 指向求值代码）与已求值值
|
||||
- **OCaml 字节码非 native**：现象——反编译全是运行时包装；原因——字节码产物；对策——识别 `caml_start_program` 后按字节码反汇编（非常规反编译）
|
||||
- **控制流打散导致静态分析失效**：现象——函数体无连续逻辑；原因——函数式编译产物；对策——转数据流分析（步骤 4），不硬追控制流
|
||||
- **tagged int 误读**：现象——整数被当指针/指针被当整数；原因——OCaml 值标记位；对策——按低 2 位区分（1=整数，0=指针），访问前先解标记
|
||||
````
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 101 skills validated`（[[链接]]：re-cpp-abi/re-go/re-rust/re-ghidra/re-ida/re-triage/analysis-contract 均存在）
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-fp-runtime/SKILL.md
|
||||
git commit -m "feat: re-fp-runtime 技能——函数式运行时逆向（GHC/OCaml 闭包与数据流）"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 5: 挂载与计数同步
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-binary-core/SKILL.md`（子技能列表加 4 个 + 选择树加 4 分支）
|
||||
- Modify: `.claude/skills/re-ios/SKILL.md`（跨域联合加 [[re-swift]]）
|
||||
- Modify: `.claude/skills/re-macos/SKILL.md`（跨域联合加 [[re-swift]]）
|
||||
- Modify: `README.md`（计数 97→101、84→88、re-binary-core 导航行加 4 个）
|
||||
- Modify: `AGENTS.md`（97→101、84→88）
|
||||
- Modify: `.claude-plugin/marketplace.json`（97→101）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1-4 的 4 个技能目录（链接可解析）
|
||||
- Produces: 4 技能全库可达；计数 101 = 1 + 12 + 88
|
||||
|
||||
- [ ] **Step 1: re-binary-core 挂载（2 处）**
|
||||
|
||||
`.claude/skills/re-binary-core/SKILL.md` 子技能列表（现含 `、[[re-cpp-abi]]` 的 description 行）末尾追加 `、[[re-swift]]、[[re-zig]]、[[re-nim]]、[[re-fp-runtime]]`（在 `[[re-cpp-abi]]` 之后）。
|
||||
|
||||
选择树（现含「**目标是 C++（RTTI/异常表密集）** → [[re-cpp-abi]]」行）在其后插入 4 行：
|
||||
|
||||
```markdown
|
||||
- **目标是 Swift 产物（$s mangling 特征）** → [[re-swift]]（mangling/witness table/闭包捕获）
|
||||
- **目标是 Zig 产物（无 RTTI/异常表、panicking 特征）** → [[re-zig]]（comptime/错误路径）
|
||||
- **目标是 Nim 产物（NimMain/NimString 特征）** → [[re-nim]]（运行时/字符串结构）
|
||||
- **目标是 Haskell/OCaml 产物（GHC RTS/OCaml block 特征）** → [[re-fp-runtime]]（闭包/数据流）
|
||||
```
|
||||
|
||||
- [ ] **Step 2: re-ios / re-macos 跨域引用（2 处）**
|
||||
|
||||
`.claude/skills/re-ios/SKILL.md` 跨域联合节末尾追加：
|
||||
|
||||
```markdown
|
||||
- Swift 层分析（mangling/witness table）→ [[re-swift]]
|
||||
```
|
||||
|
||||
`.claude/skills/re-macos/SKILL.md` 跨域联合节末尾追加：
|
||||
|
||||
```markdown
|
||||
- Swift 层分析（mangling/witness table）→ [[re-swift]]
|
||||
```
|
||||
|
||||
- [ ] **Step 3: 计数同步（3 文件）**
|
||||
|
||||
`README.md`：
|
||||
- `## 技能导航（97）` → `## 技能导航（101）`
|
||||
- `入口 → 12 大类网关 → 84 原子技能` → `入口 → 12 大类网关 → 88 原子技能`
|
||||
- 第 5 行 `97 个逆向工程技能` → `101 个逆向工程技能`
|
||||
- re-binary-core 导航行末尾加 `、re-swift、re-zig、re-nim、re-fp-runtime`（在 `re-cpp-abi` 之后）
|
||||
|
||||
`AGENTS.md`：
|
||||
- `（97 个技能）` → `（101 个技能）`
|
||||
- `原子技能（84）` → `原子技能（88）`
|
||||
|
||||
`.claude-plugin/marketplace.json`：
|
||||
- `97 个技能` → `101 个技能`
|
||||
|
||||
- [ ] **Step 4: 校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 101 skills validated`
|
||||
|
||||
Run: `grep -c "re-swift\|re-zig\|re-nim\|re-fp-runtime" README.md`
|
||||
Expected: ≥ 4
|
||||
|
||||
- [ ] **Step 5: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-binary-core/SKILL.md .claude/skills/re-ios/SKILL.md .claude/skills/re-macos/SKILL.md README.md AGENTS.md .claude-plugin/marketplace.json
|
||||
git commit -m "增强: 4 语言技能挂载与计数同步 101（re-binary-core 选择树/re-ios-macos 跨域/README-AGENTS-marketplace）"
|
||||
```
|
||||
@@ -0,0 +1,386 @@
|
||||
# re-feedback 经验反馈网关 实现计划
|
||||
|
||||
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
|
||||
|
||||
**Goal:** 新增第 12 个网关技能 re-feedback（元网关），实现经验三源收集 → 蒸馏脱敏 → 归域 → 三档处理（发表 issue / 本地入库 / 不入库），并在 re-analyze 末尾挂可选复盘钩子。
|
||||
|
||||
**Architecture:** 纯技能库扩展（Markdown 指令集，无新增代码）。新技能目录 `.claude/skills/re-feedback/`（SKILL.md + references/intake.md + references/issue-template.md）；re-analyze/SKILL.md 加「第四步（可选）：经验复盘」；README/AGENTS 同步计数与导航。校验靠现有 validate.mjs（`npm test`）。
|
||||
|
||||
**Tech Stack:** Markdown / YAML frontmatter / validate.mjs（Node，现有）
|
||||
|
||||
## Global Constraints
|
||||
|
||||
- **红线 1 呈现中性**：选项/建议禁用「最推荐」「强烈建议」等最高级强推措辞；选项不带推荐标注，只中性列出与适用场景，用户自决
|
||||
- **红线 2 隐私脱敏**：蒸馏产物禁止具体到某个项目/公司/产品，暗示也不行（行业+规模+地域组合、专有协议名、内部代号等）；技能库公开发布（npm + 插件市场），本地入库同样受约束；入库/发 issue 前必须脱敏自检
|
||||
- validate.mjs 规则：frontmatter `name` = 目录名、`description` 非空、`type` ∈ atomic/entry/gateway、正文 `[[链接]]` 必须解析到技能目录或 references/*.md 文件名；gateway 类型豁免「工具准备」
|
||||
- 工作区现有 3 个未提交修改（`.claude/skills/re-binary-core/SKILL.md`、`re-mobile/SKILL.md`、`re-protocol/SKILL.md`）是用户待处理的入库内容——**各任务 commit 只 `git add` 本任务列出的文件，严禁 `git add -A`**
|
||||
- 正文纯 Markdown，frontmatter 标准 YAML，技能引用统一 `[[技能名]]`
|
||||
- 当前分支 `feat/re-skills`
|
||||
|
||||
---
|
||||
|
||||
### Task 1: 创建 re-feedback 网关主文件
|
||||
|
||||
**Files:**
|
||||
- Create: `.claude/skills/re-feedback/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无（新目录）
|
||||
- Produces: 技能目录 `re-feedback`（validate 的 knownSkills 里新增，供 Task 4 的 `[[re-feedback]]` 链接解析）；引用 `[[intake]]`、`[[issue-template]]`（对应 Task 2/3 的 references 文件名，先建链接后建文件，validate 的 knownRefs 在文件存在后才收录——故本任务验证只检查名称/格式，完整链接校验在 Task 3 后）
|
||||
|
||||
- [ ] **Step 1: 创建目录与 SKILL.md**
|
||||
|
||||
```bash
|
||||
mkdir -p .claude/skills/re-feedback/references
|
||||
```
|
||||
|
||||
写入 `.claude/skills/re-feedback/SKILL.md`：
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: re-feedback
|
||||
type: gateway
|
||||
description: >
|
||||
经验反馈元网关。三源收集（会话复盘/文章扫描/手动输入）→ 蒸馏脱敏 → 归域 → 三档处理（发表 issue/本地入库/不入库）。
|
||||
触发词：反馈经验、经验入库、提交经验、经验复盘、心得沉淀、lessons learned。
|
||||
---
|
||||
|
||||
# 经验反馈
|
||||
|
||||
<HARD-GATE>
|
||||
两条红线，违反即停：
|
||||
1. 呈现中性：选项/建议禁用「最推荐」「强烈建议」等最高级强推措辞，只中性列出选项与适用场景，由用户自决。
|
||||
2. 隐私脱敏：蒸馏产物禁止具体到某个项目/公司/产品，暗示也不行（行业+规模+地域组合、专有协议名、内部代号等）。
|
||||
本库公开发布（npm + 插件市场），本地入库同样受约束。入库/发 issue 前必须做脱敏自检。
|
||||
</HARD-GATE>
|
||||
|
||||
## 完整工作流
|
||||
|
||||
1. 收集（三源归一）：
|
||||
- 会话复盘：本次分析会话的踩坑/新方法（[[re-analyze]] 第四步调用时已就绪）
|
||||
- 文章扫描：`bin/wxsource.mjs` 抓取看雪/微信文章（`kanxue thread <ID> --md` / `wechat <URL> --md`），逐篇蒸馏
|
||||
- 手动输入：用户一句话/一段笔记
|
||||
2. 蒸馏与脱敏：按 `references/intake.md` —— 坑格式 `**标题**：现象——…；原因——…；对策——…`，同步脱敏
|
||||
3. 归域分类：`references/intake.md` 决策表 → grep 技能库兜底 → 仍不确定问用户（不猜）
|
||||
4. 三档处理（中性呈现，不带推荐标注）：
|
||||
- ① 发表 issue：`which gh` + `gh auth status` 探测；可用则 `gh issue create --repo DslsDZC/aihk --label 经验`，标题「经验: <技能>: <一句话>」，正文按 `references/issue-template.md`；不可用 → 输出 markdown 草稿供手动提交
|
||||
- ② 本地入库：grep 去重 → 追加到该技能 `references/experience.md`（无则创建，条目含来源+日期）→ SKILL.md「常见坑与陷阱」精选同步或追加 experience.md 链接（先建文件再加链接，避免断链）→ `npm test` 校验
|
||||
- ③ 不入库：确认后结束
|
||||
5. （文章扫描路径可选）提交 commit：「经验: 第N轮扫描入库X篇——<篇目>」，message 列出每技能新增条目
|
||||
|
||||
## 何时走哪条路（选择树）
|
||||
|
||||
- 输入 = 本次分析会话摘要 → 会话复盘源；目标 = 沉淀本次实战
|
||||
- 输入 = 文章 URL / 帖子 ID / 文章文本 → 文章扫描源；逐篇蒸馏，按 intake.md 标准跳过工具/推广帖
|
||||
- 输入 = 用户一句话/笔记 → 手动源；直接蒸馏
|
||||
- 三档选择（中性呈现）：1. 发表 issue（可公开分享、他人可复用）2. 本地入库（本库沉淀、随库发布）3. 不入库（一次性心得）
|
||||
|
||||
## 跨域联合
|
||||
|
||||
- [[re-analyze]] 第四步（可选）调用本网关做会话复盘
|
||||
- 归域目标为全部技能（[[re-binary-core]] [[re-malware]] [[re-firmware]] [[re-protocol]] [[re-mobile]] [[re-anti-analysis]] [[re-cracking]] [[re-vuln]] [[re-ctf]] [[re-managed]] [[re-forensics]] 及其原子技能）
|
||||
- 文章抓取用仓库 `bin/wxsource.mjs`；入库后用 `npm test`（validate.mjs）校验结构
|
||||
|
||||
## 常见坑与陷阱
|
||||
|
||||
- 蒸馏不脱敏直接入库/发 issue → 泄漏项目身份 —— 红线 2，入库前逐项列专有名词自检
|
||||
- 呈现带「最推荐」等强推 → 绑架用户判断 —— 红线 1，只中性列选项
|
||||
- 归域不确定硬猜 → 经验写错技能、下次检索不到 —— 问用户
|
||||
- 入库后不跑 npm test → 断链/格式错破坏 CI —— 每次入库后必须 `npm test`
|
||||
- 重复条目重复入库 → 库膨胀 —— 入库前 grep 关键词去重
|
||||
- 文章扫描不跳过工具/推广帖 → 经验贬值 —— 按 intake.md 跳过标准过滤
|
||||
```
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 89 skills validated`（re-feedback 计入；[[]] 链接中的 [[intake]]/[[issue-template]] 此时可能报 broken——属预期，Task 2/3 补齐 references 后复跑解除）
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-feedback/SKILL.md
|
||||
git commit -m "feat: re-feedback 经验反馈网关主文件（三源收集/三档处理/双红线）"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 2: 创建蒸馏方法论 references/intake.md
|
||||
|
||||
**Files:**
|
||||
- Create: `.claude/skills/re-feedback/references/intake.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无
|
||||
- Produces: references 文件 `intake`（加入 validate 的 knownRefs，解除 SKILL.md 中 [[intake]] 的 broken 状态）；内容约定：条目格式、脱敏规则、归域决策表（决策表目标链接全部为已存在技能）、去重规则、文章扫描跳过标准
|
||||
|
||||
- [ ] **Step 1: 创建 references/intake.md**
|
||||
|
||||
写入 `.claude/skills/re-feedback/references/intake.md`：
|
||||
|
||||
```markdown
|
||||
# 蒸馏方法论
|
||||
|
||||
经验条目统一格式、脱敏规则、归域决策表、去重规则、文章扫描跳过标准。
|
||||
|
||||
## 条目格式
|
||||
|
||||
每条一格，格式固定：
|
||||
|
||||
**标题（动词短语，10-20 字）**：现象——（可复现的现象描述）；原因——（根因，不重复现象）；对策——（可执行的下一步，含技能/工具名）
|
||||
|
||||
示例：
|
||||
|
||||
**重打包保持原始格式参数**：现象——重打包/替换资源后的包在真机加载崩溃或解析失败；原因——重打包工具默认输出格式与原格式存在差异（压缩方式/对齐/容器标志）；对策——保留原包的格式参数（压缩标志/对齐方式），产出与原始文件同量级同格式，先本地验证再上真机
|
||||
|
||||
- 一条一格：一个现象 + 一个根因 + 一个对策，不把多个坑合并进一条
|
||||
- 「坑」与「方法」同格式：坑写避坑；方法写「现象——旧做法低效；原因——…；对策——更优路径」
|
||||
|
||||
## 脱敏规则（红线）
|
||||
|
||||
- 禁止出现：公司/产品/项目名、目标样本名、内部代号、专有协议名、域名/包名/签名指纹
|
||||
- 禁止暗示：行业+规模+地域组合、独特技术特征组合（可推断身份）
|
||||
- 泛化写法：目标 → 「某移动应用」「某嵌入式设备」「某通信协议」；只保留技术结论（现象/原因/对策）
|
||||
- 来源字段：实战会话 → `2026-08 实战会话`（只写时间）；文章 → 文章标题 + URL（公开信息可保留）
|
||||
- 入库/发 issue 前自检：列出条目中所有专有名词逐项确认已泛化；任一不通过 → 回炉重蒸
|
||||
|
||||
## 归域决策表
|
||||
|
||||
| 条目主题 | 目标技能 |
|
||||
|---|---|
|
||||
| 壳/脱壳/反混淆/花指令/控制流平坦化 | [[re-anti-analysis]] 系（[[re-packer-id]] [[re-unpack-simple]] [[re-unpack-advanced]] [[re-deobfuscate]]） |
|
||||
| 恶意行为/持久化/注入/C2 | [[re-malware]] 系（[[re-behavior]] [[re-loader]] [[re-fileless]] [[re-ioc]]） |
|
||||
| 固件/IoT/嵌入式/rootfs | [[re-firmware]] 系（[[re-fw-extract]] [[re-fw-rootfs]] [[re-fw-emulate]]） |
|
||||
| 协议/流量/抓包/加密通信 | [[re-protocol]] 系（[[re-netcap]] [[re-proto-rev]] [[re-crypto-id]] [[re-crypto-keys]] [[re-crypto-decrypt]] [[re-tls]]） |
|
||||
| 移动 App/JNI/Frida/加固脱壳 | [[re-mobile]] 系（[[re-apk]] [[re-android-native]] [[re-frida]] [[re-mobile-pack]]） |
|
||||
| 一般二进制/反编译/调试/格式 | [[re-binary-core]] 系（[[re-triage]] [[re-format-pe]] [[re-ghidra]] [[re-gdb]]） |
|
||||
| 破解/授权/注册码/补丁 | [[re-cracking]] 系（[[re-license]] [[re-patching]] [[re-keygen]]） |
|
||||
| fuzz/崩溃/漏洞/利用 | [[re-vuln]] 系（[[re-fuzzing]] [[re-crash-triage]] [[re-exploit]]） |
|
||||
| CTF/angr/z3 | [[re-ctf]] 系（[[re-angr]] [[re-z3]] [[re-pwn]]） |
|
||||
| .NET/Java/脚本/WASM/合约/AI 模型 | [[re-managed]] 系（[[re-dotnet]] [[re-java]] [[re-script-deob]] [[re-wasm]] [[re-blockchain]] [[re-ai-model]]） |
|
||||
| 取证/内存取证/威胁情报 | [[re-forensics]] 系（[[re-mem-forensics]] [[re-disk-forensics]] [[re-ti]]） |
|
||||
| 反作弊/内核驱动/虚拟化 | [[re-kernel]] [[re-anti-cheat]] [[re-hypervisor]]（[[re-binary-core]] 系） |
|
||||
|
||||
兜底：`grep -rn "关键词" .claude/skills/*/SKILL.md` 找最相关技能；仍不确定 → 问用户，不猜。
|
||||
|
||||
## 去重规则
|
||||
|
||||
- 入库前 `grep -n "标题关键词" .claude/skills/<技能>/references/experience.md`（文件不存在 = 无重复）
|
||||
- 同现象已存在 → 跳过并告知用户；内容更完整的新版本可替换旧条目
|
||||
|
||||
## 文章扫描跳过标准
|
||||
|
||||
- 工具/工作流推广帖（新手教程、工具介绍、无新方法论）
|
||||
- 正文截断/无法提取正文
|
||||
- 纯新闻/非逆向内容
|
||||
```
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 89 skills validated`（[[intake]] broken 状态解除；[[issue-template]] 仍可能报 broken，属预期）
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-feedback/references/intake.md
|
||||
git commit -m "feat: re-feedback 蒸馏方法论（条目格式/脱敏规则/归域决策表/去重/跳过标准）"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 3: 创建 issue 模板 references/issue-template.md
|
||||
|
||||
**Files:**
|
||||
- Create: `.claude/skills/re-feedback/references/issue-template.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无
|
||||
- Produces: references 文件 `issue-template`（解除 SKILL.md 中 [[issue-template]] 的 broken 状态）；约定：gh 提交用 `--body` 传填充后的模板，草稿档直接输出
|
||||
|
||||
- [ ] **Step 1: 创建 references/issue-template.md**
|
||||
|
||||
写入 `.claude/skills/re-feedback/references/issue-template.md`：
|
||||
|
||||
```markdown
|
||||
# Issue 正文模板
|
||||
|
||||
`gh issue create` 用 `--body` 传填充后的模板（占位符全部替换）；草稿档直接输出填充后的模板正文。
|
||||
|
||||
**标题**：`经验: <技能名>: <一句话概括>`
|
||||
|
||||
**正文**：
|
||||
|
||||
## 技能
|
||||
<技能名，如 re-mobile>
|
||||
|
||||
## 现象
|
||||
<可复现的现象描述>
|
||||
|
||||
## 原因
|
||||
<根因>
|
||||
|
||||
## 对策
|
||||
<可执行的下一步，含技能/工具名>
|
||||
|
||||
## 来源
|
||||
<2026-08 实战会话 / 文章标题 + URL>
|
||||
|
||||
## 脱敏声明
|
||||
- [ ] 已确认：不含具体项目/公司/产品名
|
||||
- [ ] 已确认：无暗示性细节（行业+规模+地域组合、专有协议名、内部代号）
|
||||
```
|
||||
|
||||
- [ ] **Step 2: 结构校验（全部链接应已解析）**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 89 skills validated`，无任何 FAIL 输出
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-feedback/references/issue-template.md
|
||||
git commit -m "feat: re-feedback issue 模板（gh 提交/草稿共用，含脱敏声明）"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 4: re-analyze 末尾挂经验复盘钩子
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-analyze/SKILL.md`（在「## 第三步：编排分派」段落末尾、`## 何时使用 / 何时不用` 之前插入「## 第四步（可选）：经验复盘」；第三步段落以"…必要时回退调整路径（见 triage.md 复合任务示例）。"结尾，紧邻其后插入）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1 的技能目录 `re-feedback`（[[re-feedback]] 链接可解析）
|
||||
- Produces: re-analyze 第四步（可选）——分析后引导用户调用 [[re-feedback]]；triage.md 不改（第四步不属于任务识别路径）
|
||||
|
||||
- [ ] **Step 1: 插入第四步段落**
|
||||
|
||||
在 `.claude/skills/re-analyze/SKILL.md` 中，`## 何时使用 / 何时不用` 标题之前插入：
|
||||
|
||||
```markdown
|
||||
## 第四步（可选）：经验复盘
|
||||
|
||||
分析结论交付后，问用户是否把本次踩坑/新方法反馈给技能库——需要则调用 [[re-feedback]]（三档：发表 issue / 本地入库 / 不入库；蒸馏必须脱敏，见该网关红线）。
|
||||
```
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 89 skills validated`，无 FAIL
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-analyze/SKILL.md
|
||||
git commit -m "feat: re-analyze 第四步（可选）经验复盘钩子 → re-feedback"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 5: README / AGENTS 同步计数与导航
|
||||
|
||||
**Files:**
|
||||
- Modify: `README.md`（第 5 行技能数、第 48 行「技能导航（88）」、第 50 行「入口 → 11 大类网关 → 76 原子技能」、re-forensics 行后追加 re-feedback 行）
|
||||
- Modify: `AGENTS.md`（第 3 行「88 个技能」、第 8 行「大类网关（11）」）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1 的技能目录（计数 88→89、11→12）
|
||||
- Produces: 文档一致性（validate.mjs 不校验这两文件，人工 grep 验证）
|
||||
|
||||
- [ ] **Step 1: 修改 README.md**
|
||||
|
||||
`README.md` 第 5 行：
|
||||
- `88 个逆向工程技能` → `89 个逆向工程技能`
|
||||
- `**通用、可发布**` 描述不变
|
||||
|
||||
`README.md` 第 48-50 行附近：
|
||||
- `## 技能导航（88）` → `## 技能导航（89）`
|
||||
- `入口 → 11 大类网关 → 76 原子技能` → `入口 → 12 大类网关 → 76 原子技能`
|
||||
|
||||
re-forensics 行（`- **re-forensics**：...`）之后追加一行：
|
||||
|
||||
```markdown
|
||||
- **re-feedback**：经验反馈元网关——三源收集（会话复盘/文章扫描/手动输入）→ 蒸馏脱敏 → 归域 → 三档处理（发表 issue / 本地入库 / 不入库），re-analyze 第四步挂钩
|
||||
```
|
||||
|
||||
- [ ] **Step 2: 修改 AGENTS.md**
|
||||
|
||||
`AGENTS.md` 第 3 行：`（88 个技能）` → `（89 个技能）`
|
||||
|
||||
`AGENTS.md` 第 8 行：`大类网关（11）：re-binary-core / re-malware / re-firmware / re-protocol / re-mobile / re-anti-analysis / re-cracking / re-vuln / re-ctf / re-managed / re-forensics` → `大类网关（12）：re-binary-core / re-malware / re-firmware / re-protocol / re-mobile / re-anti-analysis / re-cracking / re-vuln / re-ctf / re-managed / re-forensics / re-feedback（经验反馈元网关）`
|
||||
|
||||
- [ ] **Step 3: 校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 89 skills validated`
|
||||
|
||||
Run: `grep -c "re-feedback" README.md AGENTS.md`
|
||||
Expected: 两个文件各至少 1 处
|
||||
|
||||
- [ ] **Step 4: Commit**
|
||||
|
||||
```bash
|
||||
git add README.md AGENTS.md
|
||||
git commit -m "docs: README/AGENTS 同步 re-feedback（89 技能/12 网关）"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 6: 端到端走查（三档处理）
|
||||
|
||||
**Files:**
|
||||
- Test: 临时样本经验（不入库样例，仅走查；如需真入库用后删除或保留为演示条目）
|
||||
- Test: `.claude/skills/re-feedback/references/experience.md`（② 档演练产物，验证后保留——作为该技能自身的经验全集首条）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1-4 全部产物
|
||||
- Produces: 验证三档路径可用；为 re-feedback 技能自身沉淀一条首条经验
|
||||
|
||||
- [ ] **Step 1: 准备脱敏样本**
|
||||
|
||||
用以下已脱敏样本（技术内容真实、无项目身份）：
|
||||
|
||||
```
|
||||
**三档选择先问用户再动手**：现象——拿到经验直接按默认档处理（如直接发 issue），用户其实想本地留底；原因——档位是用户的权利，预设处理侵犯自主判断；对策——步骤 4 先用中性句式问「这次经验怎么处理？1. 发表 issue 2. 本地入库 3. 不入库」，等用户选定再执行
|
||||
```
|
||||
|
||||
- [ ] **Step 2: 走查 ① 档（仅验证 gh + 草稿，不真实发 issue）**
|
||||
|
||||
Run: `which gh && gh auth status`
|
||||
- gh 存在且已登录 → 用填充后的模板拼出完整 issue 内容（标题「经验: re-feedback: 三档选择先问用户再动手」+ 技能/现象/原因/对策/来源/脱敏声明 六段），**验证 gh 命令形式**（`gh issue create --help` 确认参数写法），**不执行真实创建**；展示填充后的草稿全文供用户核对
|
||||
- gh 不存在/未登录 → 确认输出填充后的模板 markdown 草稿（标题 + 技能/现象/原因/对策/来源/脱敏声明 六段），提示用户手动提交
|
||||
- 无论哪种情况：不调用 `gh issue create` 真实发帖（用户决定：演练零对外影响）
|
||||
|
||||
- [ ] **Step 3: 走查 ② 档（本地入库）**
|
||||
|
||||
1. 去重：`grep -n "三档选择" .claude/skills/re-feedback/references/experience.md` → 文件不存在（无重复）
|
||||
2. 创建 `.claude/skills/re-feedback/references/experience.md`：
|
||||
|
||||
```markdown
|
||||
# 经验全集
|
||||
|
||||
条目按时间倒序，来源见每条末尾；本文件与 SKILL.md「常见坑与陷阱」精选并存。
|
||||
|
||||
## 2026-08
|
||||
|
||||
- **三档选择先问用户再动手**：现象——拿到经验直接按默认档处理（如直接发 issue），用户其实想本地留底；原因——档位是用户的权利，预设处理侵犯自主判断；对策——步骤 4 先用中性句式问「这次经验怎么处理？1. 发表 issue 2. 本地入库 3. 不入库」，等用户选定再执行（来源：2026-08 实战会话）
|
||||
```
|
||||
|
||||
3. SKILL.md「常见坑与陷阱」末尾追加链接行：`- 更多经验见本技能 [[experience]]（经验全集）`
|
||||
4. Run: `npm test` → Expected: `OK: 89 skills validated`（[[experience]] 链接解析成功）
|
||||
5. Commit:
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-feedback/references/experience.md .claude/skills/re-feedback/SKILL.md
|
||||
git commit -m "经验: re-feedback 首条入库（三档选择先问用户再动手）"
|
||||
```
|
||||
|
||||
- [ ] **Step 4: 走查 ③ 档（不入库）**
|
||||
|
||||
用另一条样本（如「临时心得」），确认网关在用户选 ③ 后不再写任何文件、只口头确认结束，无残留产物（`git status` 无新增文件）。
|
||||
|
||||
- [ ] **Step 5: 全量校验收尾**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 89 skills validated`，无 FAIL；`git log --oneline -6` 可见本计划的全部提交（Task 1-6）
|
||||
@@ -0,0 +1,447 @@
|
||||
# rev-skills 能力新增 实现计划
|
||||
|
||||
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
|
||||
|
||||
**Goal:** 新增 2 个原子技能（re-python / re-frida-script-author）+ 3 处并入（Keystore 审计 / Flutter channel / svc 检测），技能总数 89 → 91。
|
||||
|
||||
**Architecture:** 纯技能文档扩展。2 个新技能目录（SKILL.md，按 docs/skill-template.md 原子技能规范）+ 3 处现有技能/契约文件补章节 + 计数同步（README/AGENTS/marketplace.json）。校验靠 validate.mjs（npm test）。
|
||||
|
||||
**Tech Stack:** Markdown / YAML frontmatter / validate.mjs（Node，现有）
|
||||
|
||||
## Global Constraints
|
||||
|
||||
- **红线 1 呈现中性**：禁用「最推荐」「强烈建议」等最高级强推措辞
|
||||
- **红线 2 隐私脱敏**：内容不指向具体项目/公司/产品；示例泛化（「某移动应用」等）
|
||||
- **不绑定具体工具**：方法为核心，工具为可替换示例；「工具准备」按模板给跨 OS 安装命令
|
||||
- validate.mjs：frontmatter `name`=目录名、`description` 非空、`type: atomic` 必含「## 工具准备」、`[[链接]]` 必须解析（技能目录或 references/*.md）
|
||||
- 工作区有 3 个未提交修改（re-binary-core / re-mobile / re-protocol 的 SKILL.md）——**各任务 commit 只 `git add` 本任务列出的文件，严禁 `git add -A`**；本计划不涉及这 3 个文件
|
||||
- 当前分支 `main`；提交信息按仓库惯例（feat:/增强:/docs:）
|
||||
- 新技能创建后 `npm test` 预期输出 `OK: 91 skills validated`
|
||||
|
||||
---
|
||||
|
||||
### Task 1: 创建 re-python 技能
|
||||
|
||||
**Files:**
|
||||
- Create: `.claude/skills/re-python/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无（新目录）
|
||||
- Produces: 技能目录 `re-python`（validate 的 knownSkills 新增，供 Task 3 的 [[re-python]] 链接解析；计数 89 → 90）
|
||||
|
||||
- [ ] **Step 1: 创建目录与 SKILL.md**
|
||||
|
||||
```bash
|
||||
mkdir -p .claude/skills/re-python
|
||||
```
|
||||
|
||||
写入 `.claude/skills/re-python/SKILL.md`：
|
||||
|
||||
````markdown
|
||||
---
|
||||
name: re-python
|
||||
type: atomic
|
||||
description: >
|
||||
Python 打包/混淆样本分析：PyInstaller/PyArmor/Nuitka/Cython 解包、pyc 版本识别与反编译。
|
||||
触发词：Python打包、PyInstaller、PyArmor、pyc、python exe、Python 样本、打包样本。
|
||||
---
|
||||
|
||||
# Python 打包样本分析（PyInstaller / PyArmor / pyc）
|
||||
|
||||
## 何时使用 / 何时不用
|
||||
|
||||
- 用：PyInstaller 单文件/目录 exe、PyArmor 加固样本、.pyc 文件、Nuitka/Cython 编译产物、Python 恶意软件打包样本
|
||||
- 不用：纯 .py 源码混淆（base64/编码包装）→ 转 [[re-script-deob]]；Python 模型权重（pkl/onnx）→ [[re-ai-model]]
|
||||
|
||||
## 工具准备
|
||||
|
||||
### python3（基础运行时，必备）
|
||||
|
||||
- Linux: `apt install python3` / `dnf install python3` / `pacman -S python`
|
||||
- macOS: `brew install python`（系统自带）
|
||||
- Windows: 官网安装包或 `choco install python`
|
||||
- 验证: `python3 --version`
|
||||
|
||||
### pyinstxtractor（PyInstaller 归档提取）
|
||||
|
||||
- 多平台: `pip install pyinstxtractor-ng` 或 GitHub 脚本 `python pyinstxtractor.py`
|
||||
- 验证: `pyinstxtractor-ng <目标.exe>` 运行无报错（无独立 --help 命令）
|
||||
|
||||
### PyArmor-Unpacker（PyArmor 加固解包）
|
||||
|
||||
- 多平台: `git clone https://github.com/Svenskithesource/PyArmor-Unpacker`，按 README 按 PyArmor 版本选三方法之一
|
||||
- 验证: 仓库内 python 脚本可运行
|
||||
|
||||
### pycdc / pycdas（pyc 反编译）
|
||||
|
||||
- Linux/macOS: `git clone https://github.com/zrax/pycdc && cd pycdc && cmake . && make`
|
||||
- Windows: 预编译二进制或 WSL 编译
|
||||
- 验证: `./pycdc --help`
|
||||
|
||||
### file（打包器识别辅助，通用）
|
||||
|
||||
- 各系统自带（Linux binutils / macOS / Windows 需额外装或跳过）
|
||||
- 验证: `file --version`
|
||||
|
||||
## 操作步骤
|
||||
|
||||
按顺序执行，每步产物存档（路径 + sha256，见 [[re-triage]]）。
|
||||
|
||||
1. **识别打包器**：
|
||||
```sh
|
||||
file sample.exe
|
||||
strings sample.exe | grep -iE 'PyInstaller|_MEIPASS|pyi-|PyArmor|pyarmor' | head
|
||||
```
|
||||
- PyInstaller 特征：`PyInstaller` 版本串、`_MEI` 临时目录名、`pyi-` 前缀引导器
|
||||
- PyArmor 特征：`pyarmor` runtime 字符串
|
||||
- Nuitka/Cython：无 pyc、纯编译产物（`file` 显示普通可执行，无 Python runtime 打包特征）
|
||||
- 识别失败但确认 Python 相关 → 按可疑 PyInstaller 处理
|
||||
|
||||
2. **PyInstaller 解包**：
|
||||
```sh
|
||||
python pyinstxtractor.py sample.exe
|
||||
# 输出 sample.exe_extracted/ 目录，含 PYZ-00.pyz（依赖归档）与主脚本 .pyc
|
||||
```
|
||||
- 定位主 .pyc（名字与入口脚本对应）；PYZ 内模块自动解出至 `PYZ-00.pyz_extracted/`；模块清单可用 archive_viewer.py 查看
|
||||
|
||||
3. **PyArmor 解包**（步骤 1 检测到 PyArmor 时）：
|
||||
- 按 PyArmor 版本选 PyArmor-Unpacker 三方法之一（README 判断版本 → 对应方法）
|
||||
- 解包产物仍为 pyc 或源码，继续下一步
|
||||
|
||||
4. **pyc 版本识别**：
|
||||
```sh
|
||||
python3 -c "import struct,sys; print(struct.unpack('<H', open('main.pyc','rb').read(2))[0])"
|
||||
```
|
||||
- magic 对照（小端 2 字节，常见值；以本机 MAGIC_NUMBER 为准）：
|
||||
- `0d33`=3.6、`0d42`=3.7、`0d55`=3.8、`0d61`=3.9、`0d6f`=3.10、`0dcb`=3.11
|
||||
- 3.12+：不写死数值，按本机 MAGIC_NUMBER 换算（`python3 -c "import importlib.util; print(hex(int.from_bytes(importlib.util.MAGIC_NUMBER[:2],'little')))"`）
|
||||
- 版本匹配目标则用对应版本 python 或 pycdc 反编译；不匹配先装匹配版本再试
|
||||
|
||||
5. **反编译与清理**：
|
||||
```sh
|
||||
pycdc main.pyc > main_decompiled.py # 或匹配版本 python 的 dis 模块
|
||||
```
|
||||
- 清理 confusion code：删假函数/死代码（PyArmor 常见的无引用包装函数），定位核心逻辑（加密/网络/外泄）
|
||||
- 反编译失败（版本不匹配/混淆）→ 用 `dis` 字节码级分析关键函数，或转 [[re-binary-core]] 深度还原
|
||||
|
||||
## 跨域联合
|
||||
|
||||
- [[re-managed]] 网关：本技能归属（选择树「Python 打包样本」分支）
|
||||
- [[re-script-deob]]：纯脚本混淆（无打包）场景
|
||||
- [[re-malware]]：恶意 Python 样本的行为验证与 IOC（解包后转行为分析）
|
||||
- [[re-binary-core]]：pyc 深度还原 / 混合产物（内嵌 native 模块 [[re-format-elf]]）
|
||||
- 底座 [[re-triage]]：打包器识别的初勘输入
|
||||
|
||||
## 常见坑与陷阱
|
||||
|
||||
- **pyc 版本不匹配直接反编译失败**：现象——pycdc 输出乱码或报错；原因——magic 版本与目标不符；对策——先做步骤 4 的 magic 识别，按版本选工具
|
||||
- **PyArmor 版本差异导致解包器失效**：现象——PyArmor-Unpacker 报不支持；原因——PyArmor 版本过新/过旧；对策——按版本换方法，或手动定位 runtime 的加解密逻辑（转 [[re-binary-core]]）
|
||||
- **Cython/Nuitka 无 pyc**：现象——找不到 .pyc；原因——编译型产物；对策——直接分析产物（[[re-format-elf]] / [[re-ghidra]]），不找 pyc
|
||||
- **假函数干扰定位**：现象——解包后源码充斥无引用包装函数；原因——PyArmor 的 confusion code；对策——先按调用关系过滤（无调用者即候选），再定位核心逻辑
|
||||
- **strings 找打包器特征被加密隐藏**：现象——strings 无 PyInstaller 特征但行为是 Python；原因——字符串加密/壳；对策——按行为线索与扩展名判断，必要时动态侧（[[re-sandbox]]）观察
|
||||
````
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 91 skills validated`（re-python 计入；[[链接]] 全部指向已存在技能）
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-python/SKILL.md
|
||||
git commit -m "feat: re-python 技能——PyInstaller/PyArmor 解包与 pyc 识别"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 2: 创建 re-frida-script-author 技能
|
||||
|
||||
**Files:**
|
||||
- Create: `.claude/skills/re-frida-script-author/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无（新目录）
|
||||
- Produces: 技能目录 `re-frida-script-author`（供 Task 3 的 [[re-frida-script-author]] 链接解析；计数 90 → 91）；引用 [[frida-scripts]]（re-frida 的 references，已存在）
|
||||
|
||||
- [ ] **Step 1: 创建目录与 SKILL.md**
|
||||
|
||||
```bash
|
||||
mkdir -p .claude/skills/re-frida-script-author
|
||||
```
|
||||
|
||||
写入 `.claude/skills/re-frida-script-author/SKILL.md`：
|
||||
|
||||
````markdown
|
||||
---
|
||||
name: re-frida-script-author
|
||||
type: atomic
|
||||
description: >
|
||||
Frida 脚本生成方法论：目标特征 → 模板选择 → 改写 → 验证。独立于执行插桩（re-frida）。
|
||||
触发词：生成Frida脚本、写hook脚本、frida脚本怎么写、写个hook、脚本生成。
|
||||
---
|
||||
|
||||
# Frida 脚本生成
|
||||
|
||||
## 何时使用 / 何时不用
|
||||
|
||||
- 用：需要新脚本时——拦截（加密/网络/文件）、绕过（检测/固定）、追踪（JNI/方法调用）
|
||||
- 不用：执行现成脚本 → 转 [[re-frida]]；反检测对抗面分析 → [[anti-dynamic-workflow]]
|
||||
|
||||
## 工具准备
|
||||
|
||||
### frida-tools（脚本编写与运行验证）
|
||||
|
||||
- Linux: `pip install frida-tools`（或 `apt install frida-tools` / `pacman -S frida`）
|
||||
- macOS: `pip install frida-tools` / `brew install frida`
|
||||
- Windows: `pip install frida-tools` / `choco install frida`
|
||||
- 验证: `frida --version`、`frida-ps -U`（连设备后）
|
||||
|
||||
### python3（配合脚本调试）
|
||||
|
||||
- 各平台同 [[re-python]] 工具准备
|
||||
|
||||
### 目标设备/模拟器
|
||||
|
||||
- Android 真机/模拟器 + frida-server（安装见 [[re-frida]] 工具准备）；桌面目标直接本机
|
||||
|
||||
## 操作步骤
|
||||
|
||||
按「探 → 选 → 改 → 验」四步，先探后写，不猜：
|
||||
|
||||
1. **目标侦察**：
|
||||
- 静态：目标包名/类名/关键 API（[[re-apk]] jadx 输出）、加固商特征（[[re-mobile-pack]]）、Flutter/RN 混合结构（[[re-hybrid-app]]）
|
||||
- 动态基线：原样跑一次抓崩溃（崩溃特征 → 保护机制对照，见 [[anti-dynamic-workflow]]）
|
||||
- 产出：目标特征清单（检测点/目标 API/输入输出形态）
|
||||
|
||||
2. **模板选择**：按特征清单对照 [[frida-scripts]] 模板表：
|
||||
|
||||
| 目标特征 | 模板 |
|
||||
|---|---|
|
||||
| HTTPS 抓包被 TLS 加密（BoringSSL） | TLS 密钥日志（SSLKEYLOGFILE） |
|
||||
| 证书固定挡抓包 | SSL 固定绕过（TrustManager/CertificatePinner） |
|
||||
| 加密算法/密钥要提取 | 加密拦截（Cipher/SecretKeySpec 全 overload） |
|
||||
| 加固/运行时解密 | DEX dump（类加载点）/ SO dump |
|
||||
| 双向 TLS 客户端证书 | keystore p12 导出 |
|
||||
| JNI 动态注册要还原 | RegisterNatives + 汇聚点双 hook |
|
||||
| 反调试/检测拦截 | 检测绕过表（root/属性/文件/命令） |
|
||||
|
||||
3. **改写**：
|
||||
- 替换占位符：包名/类名/方法名（精确匹配，Java 全限定名）
|
||||
- overload 精确匹配：目标方法多 overload 时逐一定义或按参数类型选
|
||||
- 保存 original 引用、带原 `this` 调用；输出 JSON（可打印 ASCII + hex 双格式）
|
||||
- 同一类多 hook 合并进一个 `.implementation`（缓存静默覆盖）
|
||||
|
||||
4. **验证**：
|
||||
```sh
|
||||
frida -U -f <pkg> -l script.js --pause # spawn + 停在早期代码前
|
||||
```
|
||||
- 输出 JSON 可解析、目标行为符合预期（拦截到目标调用/绕过生效）
|
||||
- 失败 → 回步骤 2 重选模板或细化特征；崩溃 → 按 [[anti-dynamic-workflow]] 崩溃对照表定位
|
||||
|
||||
## 跨域联合
|
||||
|
||||
- [[re-frida]]：脚本执行（本技能产出 → re-frida 运行）
|
||||
- [[re-mobile]] / [[re-android-native]]：移动目标场景衔接
|
||||
- [[anti-dynamic-workflow]]：检测面与崩溃迭代法
|
||||
- [[frida-scripts]]：模板素材库（re-frida references）
|
||||
- [[analysis-contract]]：脚本输出按数据契约消费（证据存档）
|
||||
|
||||
## 常见坑与陷阱
|
||||
|
||||
- **overload 不匹配静默失效**：现象——hook 无输出；原因——目标方法 overload 签名与定义不符；对策——先 `Java.use(...).<method>.overloads` 列出全部重载再选
|
||||
- **Java.use 缓存覆盖**：现象——多个 hook 只生效最后一个；原因——同类多次 `.implementation` 赋值静默覆盖；对策——合并进一个 hook
|
||||
- **参数索引版本相关**：现象——native 参数读错；原因——目标版本字段/参数位次变化；对策——对照目标符号核实，不照搬经验值
|
||||
- **不侦察就写脚本**：现象——脚本对不上目标；原因——跳过步骤 1；对策——先探后写
|
||||
- **绕过类脚本只观察不持久化**：现象——测试后目标状态被改；原因——脚本含写操作；对策——脚本只做读取/日志，绕过仅用于观察
|
||||
|
||||
## 使用注意
|
||||
|
||||
- 全部在沙箱内执行（[[platform-tips]] 最高原则）
|
||||
- 输出 JSON 供 [[analysis-contract]] 数据契约消费
|
||||
````
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 91 skills validated`（[[frida-scripts]] / [[anti-dynamic-workflow]] 等链接全部解析）
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-frida-script-author/SKILL.md
|
||||
git commit -m "feat: re-frida-script-author 技能——目标特征到 Frida 脚本的生成方法论"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 3: 网关挂载（re-managed / re-frida）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-managed/SKILL.md`（选择树加 re-python 分支）
|
||||
- Modify: `.claude/skills/re-frida/SKILL.md`（跨域联合加 re-frida-script-author 引用）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1 的 `re-python`、Task 2 的 `re-frida-script-author`（链接可解析）
|
||||
- Produces: 两个新技能在网关层的可达性
|
||||
|
||||
- [ ] **Step 1: re-managed 选择树加分支**
|
||||
|
||||
在 `.claude/skills/re-managed/SKILL.md` 的 `.ps1 / .docm ...（脚本或宏）` 分支行之后插入：
|
||||
|
||||
```markdown
|
||||
- **Python 打包样本（.exe 含 PyInstaller/PyArmor 特征 / .pyc / python 打包）** → [[re-python]]（pyinstxtractor 解包、PyArmor-Unpacker、pyc 反编译；纯脚本混淆转 [[re-script-deob]]）
|
||||
```
|
||||
|
||||
- [ ] **Step 2: re-frida 跨域联合加引用**
|
||||
|
||||
在 `.claude/skills/re-frida/SKILL.md` 的「## 跨域联合」节追加一行：
|
||||
|
||||
```markdown
|
||||
- 脚本生成：目标特征 → 模板选择 → 改写验证 → [[re-frida-script-author]]（模板素材 [[frida-scripts]]）
|
||||
```
|
||||
|
||||
- [ ] **Step 3: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 91 skills validated`，无 FAIL
|
||||
|
||||
- [ ] **Step 4: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-managed/SKILL.md .claude/skills/re-frida/SKILL.md
|
||||
git commit -m "增强: re-managed/re-frida 挂载 re-python 与 re-frida-script-author"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 4: Keystore 审计 + Flutter channel 并入
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-android-native/SKILL.md`（加「## Keystore 审计」章节）
|
||||
- Modify: `.claude/skills/re-hybrid-app/SKILL.md`（加「## Flutter MethodChannel 动态拦截」章节）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无（纯章节新增）
|
||||
- Produces: 两技能的动态分析能力补全；引用 [[re-frida]] / [[anti-dynamic-workflow]] / [[analysis-contract]]（均已存在）
|
||||
|
||||
- [ ] **Step 1: re-android-native 加 Keystore 审计章节**
|
||||
|
||||
在 `.claude/skills/re-android-native/SKILL.md` 的「## 跨域联合」标题之前插入：
|
||||
|
||||
```markdown
|
||||
## Keystore 审计
|
||||
|
||||
Android 密钥体系分析——目标密钥来自 AndroidKeyStore 时 `getEncoded()` 不可用（硬件背书），须走审计：
|
||||
|
||||
- **遍历**：`KeyStore.getInstance("AndroidKeyStore")` → `aliases()` 枚举全部条目
|
||||
- **条目属性**：算法（AES/RSA/EC）、用途（encrypt/decrypt/sign/verify）、来源（`KeyInfo.isInsideSecureHardware`——TEE 与 StrongBox 区分）
|
||||
- **生物绑定**：`setUserAuthenticationRequired` 的密钥在认证失败时不可用（绕过与检测见 [[anti-dynamic-workflow]]）
|
||||
- **与 hook 衔接**：加密拦截（[[re-frida]] 的 [[frida-scripts]]）时密钥来自 Keystore → 记录别名与用途，不记录密钥字节
|
||||
```
|
||||
|
||||
- [ ] **Step 2: re-hybrid-app 加 Flutter channel 章节**
|
||||
|
||||
在 `.claude/skills/re-hybrid-app/SKILL.md` 的「## 跨域联合」标题之前插入：
|
||||
|
||||
```markdown
|
||||
## Flutter MethodChannel 动态拦截
|
||||
|
||||
Flutter 平台通道（PlatformChannel）是 Dart ↔ native 通信主干，拦截可观察全部原生能力调用：
|
||||
|
||||
- **Java/Kotlin 侧**：hook `io.flutter.plugin.common.MethodChannel` 的 MethodCallHandler——记录 channel 名 / 方法名 / 参数 JSON
|
||||
- **engine messenger 层**：`io.flutter.embedding.engine.FlutterEngine` 的 messenger 消息（低层兜底）
|
||||
- **与 Dart 侧静态观察互补**：静态找 channel 名与调用点（字符串字面量），动态确认实际流量
|
||||
- **输出**：结构化 JSON（channel / method / args），供 [[analysis-contract]] 数据契约消费（证据存档）
|
||||
```
|
||||
|
||||
- [ ] **Step 3: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 91 skills validated`，无 FAIL
|
||||
|
||||
- [ ] **Step 4: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-android-native/SKILL.md .claude/skills/re-hybrid-app/SKILL.md
|
||||
git commit -m "增强: Keystore 审计（re-android-native）+ Flutter MethodChannel 拦截（re-hybrid-app）"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 5: svc 裸系统调用检测并入 anti-dynamic-workflow
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-analyze/references/anti-dynamic-workflow.md`（追加「### 裸系统调用检测」节）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无
|
||||
- Produces: 通用对抗工作流的检测面补全（[[anti-dynamic-workflow]] 已是全库引用目标）
|
||||
|
||||
- [ ] **Step 1: 追加章节**
|
||||
|
||||
在 `.claude/skills/re-analyze/references/anti-dynamic-workflow.md` 的「## 高频检测面清单」节之后、`## 实现教训` 节之前插入：
|
||||
|
||||
```markdown
|
||||
## 裸系统调用检测
|
||||
|
||||
目标自实现系统调用（绕过 libc）时，基于 libc 符号的 hook 与检测全部失效——svc 指令级捕获：
|
||||
|
||||
- **架构分支**：arm64 SYS_OPEN=56、svc 机器码 `01 00 00 D4`；arm SYS_OPEN=5、`00 00 00 EF`
|
||||
- **手法**：遍历可执行段（r-x）过滤 .so → 特征码扫描命中 → 回读 svc 前一条指令取系统调用号（arm64 读 `mov x8` 立即数位、arm 读 r7）→ 系统调用号等于目标（如 SYS_OPEN）才 attach → 打印文件名与返回值
|
||||
- **注意**：arm64 参数索引按系统调用约定核对（open 路径参数在 x0，不照搬经验值）；系统调用号表按目标内核/Android 版本核对
|
||||
```
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 91 skills validated`，无 FAIL
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-analyze/references/anti-dynamic-workflow.md
|
||||
git commit -m "增强: 裸系统调用检测（svc 指令级）并入通用动态对抗工作流"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 6: 计数同步（README / AGENTS / marketplace）
|
||||
|
||||
**Files:**
|
||||
- Modify: `README.md`（技能导航 89→91、「12 大类网关 → 76 原子技能」→78、re-managed 行加 re-python、re-mobile 行加 re-frida-script-author）
|
||||
- Modify: `AGENTS.md`（「（89 个技能）」→「（91 个技能）」）
|
||||
- Modify: `.claude-plugin/marketplace.json`（description「89 个技能」→「91 个技能」）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1/2 的技能目录（计数 89 → 91）
|
||||
- Produces: 文档一致性（validate.mjs 不校验这三文件，人工 grep 验证）
|
||||
|
||||
- [ ] **Step 1: README.md 三处修改**
|
||||
|
||||
`README.md`：
|
||||
- `## 技能导航（89）` → `## 技能导航（91）`
|
||||
- `入口 → 12 大类网关 → 76 原子技能` → `入口 → 12 大类网关 → 78 原子技能`
|
||||
- `- **re-managed**：re-dotnet、re-java、re-script-deob、re-wasm、re-ai-model、re-blockchain` → `- **re-managed**：re-dotnet、re-java、re-script-deob、re-wasm、re-ai-model、re-blockchain、re-python`
|
||||
- `- **re-mobile**：re-apk、re-ios、re-frida、re-mobile-pack、re-hybrid-app、re-android-native、re-ios-jb` → `- **re-mobile**：re-apk、re-ios、re-frida、re-frida-script-author、re-mobile-pack、re-hybrid-app、re-android-native、re-ios-jb`
|
||||
|
||||
- [ ] **Step 2: AGENTS.md / marketplace.json 修改**
|
||||
|
||||
`AGENTS.md` 第 3 行：`（89 个技能）` → `（91 个技能）`
|
||||
|
||||
`.claude-plugin/marketplace.json` 第 6 行：`"description": "通用逆向工程技能库：89 个技能（...）"` 中 `89` → `91`
|
||||
|
||||
- [ ] **Step 3: 校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 91 skills validated`
|
||||
|
||||
Run: `grep -c "re-python\|re-frida-script-author" README.md`
|
||||
Expected: ≥ 2
|
||||
|
||||
- [ ] **Step 4: Commit**
|
||||
|
||||
```bash
|
||||
git add README.md AGENTS.md .claude-plugin/marketplace.json
|
||||
git commit -m "docs: 计数同步 89→91（re-python / re-frida-script-author 入导航）"
|
||||
```
|
||||
@@ -0,0 +1,185 @@
|
||||
# 中途再路由机制 实现计划
|
||||
|
||||
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
|
||||
|
||||
**Goal:** 建立「中途再路由」机制——分析中证据特征出现即触发对应技能、网关完成必查、未命中按约束换路，解决「走完入口不再调用技能」的痛点。
|
||||
|
||||
**Architecture:** 新建 `re-analyze/references/rerouting.md`（证据→技能触发表，A/B 双表）+ re-analyze 第三步改双轨强制 + 两个引用点（analysis-contract / triage）统一指向。无新技能，91 技能不变。
|
||||
|
||||
**Tech Stack:** Markdown / validate.mjs（npm test，现有）
|
||||
|
||||
## Global Constraints
|
||||
|
||||
- **红线 1 呈现中性**：禁用「最推荐」「强烈建议」等最高级强推措辞
|
||||
- **红线 2 隐私脱敏**：内容不指向具体项目/公司/产品
|
||||
- validate.mjs：references/*.md 文件名（去扩展名）为合法 [[链接]] 目标；SKILL.md 正文 [[链接]] 必须可解析
|
||||
- rerouting.md 的 [[链接]] 全部指向已存在技能（re-cpp-abi 未建——该行用文字标注「（re-cpp-abi 待建，先走 [[re-binary-core]]）」，**不写 [[re-cpp-abi]] 死链**）
|
||||
- 工作区有 4 个未提交修改（re-binary-core / re-mobile / re-protocol 的 SKILL.md、README.md）——**各任务 commit 只 `git add` 本任务列出的文件，严禁 `git add -A`**；本计划不涉及这 4 个文件
|
||||
- 当前分支 `main`；`npm test` 预期 `OK: 91 skills validated`
|
||||
|
||||
---
|
||||
|
||||
### Task 1: 创建 rerouting.md 触发表
|
||||
|
||||
**Files:**
|
||||
- Create: `.claude/skills/re-analyze/references/rerouting.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无（新 references 文件）
|
||||
- Produces: references 目标 `rerouting`（validate 的 knownRefs 收录，供 Task 2/3 的 [[rerouting]] 链接解析）
|
||||
|
||||
- [ ] **Step 1: 创建 rerouting.md**
|
||||
|
||||
写入 `.claude/skills/re-analyze/references/rerouting.md`：
|
||||
|
||||
````markdown
|
||||
# 中途再路由触发表
|
||||
|
||||
运行时证据触发的唯一事实源（区别于 triage.md 的入口「目标→路径」决策表）。分析过程中按双轨使用：
|
||||
|
||||
- **轨 1（网关完成必查）**：每网关完成后对照 A/B 表检查新证据
|
||||
- **轨 2（证据出现即查）**：每产出新证据类型（字符串/节表/行为/加密特征）立即对照 A 表
|
||||
- **未命中** → 按 B 表约束行动，禁止自行硬琢磨
|
||||
|
||||
## A 表：证据特征 → 触发技能
|
||||
|
||||
| 证据特征（分析中看到） | 触发技能 |
|
||||
|---|---|
|
||||
| 节表异常（UPX0/.aspack）、熵 >7.0 | [[re-packer-id]] → [[re-anti-analysis]] |
|
||||
| 未知加密算法、S-box/常量指纹、加密流量 | [[re-crypto-id]] |
|
||||
| 硬编码密钥/口令、内存中的 key | [[re-crypto-keys]] |
|
||||
| 解密函数已定位、密文可还原 | [[re-crypto-decrypt]] |
|
||||
| 反调试/反 VM 特征（ptrace、CPUID、时间检测） | [[re-evasion]] / [[re-anti-analysis]] |
|
||||
| 动态注册 JNI、so 函数级加密 | [[re-android-native]] |
|
||||
| 混淆（CFF/花指令/字符串加密） | [[re-deobfuscate]] |
|
||||
| 网络回连/信标/C2 特征 | [[re-netcap]] → [[re-behavior]] |
|
||||
| 持久化/注入/进程树异常 | [[re-behavior]] |
|
||||
| 崩溃/段错误/ASAN 报告 | [[re-crash-triage]] |
|
||||
| Python 打包特征（PyInstaller/PyArmor） | [[re-python]] |
|
||||
| Flutter/RN 引擎特征 | [[re-hybrid-app]] |
|
||||
| 加固商特征（加固壳） | [[re-mobile-pack]] |
|
||||
| RTTI/异常表（.pdata/.xdata）密集 | （re-cpp-abi 待建，先走 [[re-binary-core]]） |
|
||||
|
||||
## B 表：卡住信号 → 换路
|
||||
|
||||
| 卡住信号 | 换路 |
|
||||
|---|---|
|
||||
| 同参数重复 ≥2 次无新证据 | 对照 A 表重查 / 换工具视角（[[analysis-contract]] 调查预算） |
|
||||
| 单命令 ≥3 次无进展 | 停下评估，重跑 re-analyze 第二步（任务识别）或换网关 |
|
||||
| 分析超 30 次工具调用无结论 | 回退到最近有产出的环节，按 [[analysis-contract]] 复核格式交付部分结论 |
|
||||
| 目标行为与静态结论矛盾 | 动态侧 [[re-sandbox]] / [[re-tracing]] 对照 |
|
||||
|
||||
## 使用规则
|
||||
|
||||
1. 每产出新证据类型 → 查 A 表，命中即调用对应技能，完成后回到轨 1 继续
|
||||
2. 每网关完成 → 查 A+B 表
|
||||
3. 未命中任何表项 → 按 B 表约束行动（换思路/回退/交付部分结论）
|
||||
````
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 91 skills validated`（references 文件不校验正文链接，但保持全部链接有效；[[re-netcap]]→[[re-behavior]] 等箭头链接为文字序列，非 [[死链]]）
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-analyze/references/rerouting.md
|
||||
git commit -m "feat: rerouting 中途再路由触发表（A 证据→技能 / B 卡住→换路）"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 2: re-analyze 第三步改双轨强制 + 常见坑
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-analyze/SKILL.md`（第三步编排分派段落改双轨；常见坑追加一条）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1 的 `rerouting`（[[rerouting]] 链接可解析）
|
||||
- Produces: 入口级双轨强制机制（第三步 + 常见坑）
|
||||
|
||||
- [ ] **Step 1: 第三步段落改双轨**
|
||||
|
||||
`.claude/skills/re-analyze/SKILL.md` 现状（第三步段落）：
|
||||
|
||||
```
|
||||
调用对应大类网关技能（`[[re-binary-core]]` `[[re-malware]]` `[[re-firmware]]` `[[re-protocol]]` `[[re-mobile]]` `[[re-anti-analysis]]` `[[re-cracking]]` `[[re-vuln]]` `[[re-ctf]]` `[[re-managed]]` `[[re-forensics]]`），网关内部自行选择原子技能。每个环节完成后检查新证据，必要时回退调整路径（见 triage.md 复合任务示例）。
|
||||
```
|
||||
|
||||
改为（在原文后追加双轨段，原文保留）：
|
||||
|
||||
```
|
||||
调用对应大类网关技能（`[[re-binary-core]]` `[[re-malware]]` `[[re-firmware]]` `[[re-protocol]]` `[[re-mobile]]` `[[re-anti-analysis]]` `[[re-cracking]]` `[[re-vuln]]` `[[re-ctf]]` `[[re-managed]]` `[[re-forensics]]`），网关内部自行选择原子技能。每个环节完成后检查新证据，必要时回退调整路径（见 triage.md 复合任务示例）。
|
||||
|
||||
**双轨再路由（强制，见 [[rerouting]]）**：
|
||||
- 轨 1（网关完成必查）：每网关完成后，对照 [[rerouting]] 的 A/B 表检查新证据；命中 → 调用对应技能，完成后回到轨 1 继续
|
||||
- 轨 2（证据出现即查）：分析中每产出新证据类型（字符串/节表/行为/加密特征），立即对照 A 表；命中 → 调用技能
|
||||
- 未命中任何表项 → 按 B 表约束行动（换思路/回退/交付部分结论），禁止自行硬琢磨
|
||||
```
|
||||
|
||||
- [ ] **Step 2: 常见坑追加一条**
|
||||
|
||||
`.claude/skills/re-analyze/SKILL.md` 常见坑末尾（「自挖前先搜社区逆向成果」条之后）追加：
|
||||
|
||||
```
|
||||
- **走完入口不再调用技能**：现象——入口编排后自己硬琢磨，中途发现新特征（壳/加密/反调试）不调对应技能；原因——再路由未执行；对策——按第三步双轨：每网关完成/每新证据对照 [[rerouting]] 触发表，命中即调
|
||||
```
|
||||
|
||||
- [ ] **Step 3: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 91 skills validated`（[[rerouting]] 解析成功，无 FAIL）
|
||||
|
||||
- [ ] **Step 4: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-analyze/SKILL.md
|
||||
git commit -m "增强: re-analyze 第三步双轨再路由强制（网关完成必查 + 证据出现即查）"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 3: 两个引用点统一指向 rerouting
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-analyze/references/analysis-contract.md`（加引用行）
|
||||
- Modify: `.claude/skills/re-analyze/references/triage.md`（第 31 行改指向）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1 的 `rerouting`（链接可解析）
|
||||
- Produces: 触发表唯一事实源的全库指向
|
||||
|
||||
- [ ] **Step 1: analysis-contract.md 加引用行**
|
||||
|
||||
`.claude/skills/re-analyze/references/analysis-contract.md` 的「分析全流程遵守本契约」段（首段）末尾追加一行：
|
||||
|
||||
```markdown
|
||||
中途再路由：证据触发按 [[rerouting]] 双轨执行（轨 1 网关完成必查 / 轨 2 证据出现即查），命中即调对应技能。
|
||||
```
|
||||
|
||||
- [ ] **Step 2: triage.md 第 31 行改指向**
|
||||
|
||||
`.claude/skills/re-analyze/references/triage.md` 现状第 31 行：
|
||||
|
||||
```
|
||||
- 每个环节完成后检查是否有新证据改变后续路径（如动态分析发现加壳 → 回退 re-anti-analysis）。
|
||||
```
|
||||
|
||||
改为：
|
||||
|
||||
```
|
||||
- 每个环节完成后检查是否有新证据改变后续路径（如动态分析发现加壳 → 回退 re-anti-analysis）。中途再路由统一按 [[rerouting]] 双轨执行（证据触发 / 网关完成必查）。
|
||||
```
|
||||
|
||||
- [ ] **Step 3: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 91 skills validated`，无 FAIL
|
||||
|
||||
- [ ] **Step 4: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-analyze/references/analysis-contract.md .claude/skills/re-analyze/references/triage.md
|
||||
git commit -m "增强: analysis-contract/triage 统一指向 rerouting 触发表"
|
||||
```
|
||||
@@ -0,0 +1,281 @@
|
||||
# 7 处融入 实现计划
|
||||
|
||||
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
|
||||
|
||||
**Goal:** 7 处章节融入现有技能（re-blockchain / re-automotive / re-script-deob / re-forensics / re-exploit / re-tracing / re-disk-forensics），技能总数 97 不变。
|
||||
|
||||
**Architecture:** 纯技能文档扩展。每处融入 = 在目标技能「## 跨域联合」标题前插入一个「## 章节」（按 docs/skill-template.md 体例），章节全文在本计划中给出。
|
||||
|
||||
**Tech Stack:** Markdown / validate.mjs（npm test，现有）
|
||||
|
||||
## Global Constraints
|
||||
|
||||
- **红线 1 呈现中性**：禁用「最推荐」「强烈建议」等最高级强推措辞
|
||||
- **红线 2 隐私脱敏**：内容不指向具体项目/公司/产品
|
||||
- **不绑定具体工具**：方法为核心，工具为可替换示例
|
||||
- validate.mjs：SKILL.md 正文 `[[链接]]` 必须可解析（技能目录或 references/*.md）
|
||||
- 工作区有 3 个未提交修改（re-binary-core / re-mobile / re-protocol 的 SKILL.md）——**各任务 commit 只 `git add` 本任务列出的文件，严禁 `git add -A`**；本计划 7 个融入目标技能均为干净文件
|
||||
- 当前分支 `main`；`npm test` 预期全程 `OK: 97 skills validated`
|
||||
|
||||
---
|
||||
|
||||
### Task 1: re-blockchain 融入「非 EVM 链」
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-blockchain/SKILL.md`（「## 跨域联合」标题前插入章节）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无
|
||||
- Produces: re-blockchain 的非 EVM 覆盖（Solana BPF / Move）
|
||||
|
||||
- [ ] **Step 1: 插入章节**
|
||||
|
||||
在 `.claude/skills/re-blockchain/SKILL.md` 的「## 跨域联合」标题之前插入：
|
||||
|
||||
```markdown
|
||||
## 非 EVM 链（Solana / Move）
|
||||
|
||||
流程与 EVM 同构（字节码反编译 → 漏洞分析），指令集与资源模型不同——先识别运行时，再按对应路径走。
|
||||
|
||||
- **Solana（BPF 字节码）**：识别特征——ELF 文件 + .text 段为 BPF 指令（eBPF 类指令集）；反编译路径——`llvm-objdump -d`（BPF 反汇编）或专用反编译器；分析重点——程序账户与指令调度（CPI 跨程序调用链）、账户数据布局（结构体偏移）
|
||||
- **Sui / Aptos（Move 字节码）**：识别特征——模块/资源/函数表结构；反编译——move disassembler（`move disassemble`）；分析重点——资源模型（对象/能力）对漏洞面的影响（转账/所有权逻辑）、模块依赖图
|
||||
- **DeFi/NFT 场景**：池子合约（AMM 常量积公式）、代币标准变体（SPL 等）、授权与提现逻辑定位
|
||||
- 漏洞分析承接：逻辑漏洞（重入/权限）沿用 EVM 思路，资源/账户模型差异处单独判断
|
||||
```
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 97 skills validated`（章节内 [[链接]] 无；如含需确认指向已存在技能）
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-blockchain/SKILL.md
|
||||
git commit -m "增强: re-blockchain 融入非 EVM 链（Solana BPF / Move 字节码）"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 2: re-automotive 融入「IVI / T-Box / V2X 路径」
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-automotive/SKILL.md`（「## 跨域联合」标题前插入章节）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无
|
||||
- Produces: re-automotive 的车联网覆盖（IVI / T-Box / V2X 分流）
|
||||
|
||||
- [ ] **Step 1: 插入章节**
|
||||
|
||||
在 `.claude/skills/re-automotive/SKILL.md` 的「## 跨域联合」标题之前插入：
|
||||
|
||||
```markdown
|
||||
## IVI / T-Box / V2X 路径
|
||||
|
||||
按目标形态分流（判定规则）：
|
||||
|
||||
- **IVI（车载娱乐系统）**：本质是 Android/Linux 系统——应用层走 [[re-apk]]，系统镜像走 [[re-firmware]]；关注 OEM 定制层（启动器、诊断接口、ADB/调试口）
|
||||
- **T-Box（远程信息处理箱）**：蜂窝模组（AT 指令接口）、MCU 固件（[[re-fw-extract]] 提取分析）、远程控制协议（车控指令——门锁/空调/启动，走 [[re-protocol]]）
|
||||
- **V2X（车联网通信）**：DSRC / C-V2X 帧结构 → [[re-protocol]] / [[re-ics]] 路径（协议状态机重建、PC5/Uu 接口区分）
|
||||
- 判定规则：应用层 → 移动/系统路径（[[re-apk]] / [[re-firmware]]）；通信层 → 协议路径（[[re-protocol]] / [[re-ics]]）；固件层 → 固件路径（[[re-fw-extract]] / [[re-fw-rootfs]]）
|
||||
```
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 97 skills validated`（[[re-apk]] / [[re-firmware]] / [[re-fw-extract]] / [[re-protocol]] / [[re-ics]] / [[re-fw-rootfs]] 均存在）
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-automotive/SKILL.md
|
||||
git commit -m "增强: re-automotive 融入 IVI/T-Box/V2X 路径分流"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 3: re-script-deob 融入「高级混淆对抗」
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-script-deob/SKILL.md`（「## 跨域联合」标题前插入章节）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无
|
||||
- Produces: re-script-deob 的商业混淆器对抗覆盖
|
||||
|
||||
- [ ] **Step 1: 插入章节**
|
||||
|
||||
在 `.claude/skills/re-script-deob/SKILL.md` 的「## 跨域联合」标题之前插入：
|
||||
|
||||
```markdown
|
||||
## 高级混淆对抗（商业混淆器）
|
||||
|
||||
JScrambler 类商业混淆器的手法与对抗：
|
||||
|
||||
- **特征识别**：bootstrap 加载器（自执行入口）、字符串表隐藏（数组 + 索引引用）、`_0x` 变量重命名模式、函数体加密（运行时解密）
|
||||
- **控制流平坦化（CFF）对抗**：dispatcher 识别（switch 分发中心）→ 状态变量追踪 → 分支还原为顺序/条件结构（方法衔接 [[re-deobfuscate]]）
|
||||
- **字符串加密对抗**：隐藏字符串表定位（解码函数调用点）→ 运行时提取（沙箱内执行解码函数取值，见 [[re-sandbox]]）或静态还原（解码循环脚本化）
|
||||
- **死代码注入对抗**：无引用函数过滤（按调用关系，无调用者即候选删除）
|
||||
- 工具链：js-beautify 美化 → 按手法选对抗路径；动态侧沙箱执行取值（默认沙箱原则）
|
||||
```
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 97 skills validated`（[[re-deobfuscate]] / [[re-sandbox]] 均存在）
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-script-deob/SKILL.md
|
||||
git commit -m "增强: re-script-deob 融入高级混淆对抗（商业混淆器）"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 4: re-forensics 融入「容器镜像取证」
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-forensics/SKILL.md`（「## 跨域联合」标题前插入章节）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无
|
||||
- Produces: re-forensics 的云原生覆盖（容器镜像取证）
|
||||
|
||||
- [ ] **Step 1: 插入章节**
|
||||
|
||||
在 `.claude/skills/re-forensics/SKILL.md` 的「## 跨域联合」标题之前插入：
|
||||
|
||||
```markdown
|
||||
## 容器镜像取证
|
||||
|
||||
- **镜像结构**：tar 归档 + 分层（每层 = 文件系统快照差异；`docker save` / `skopeo copy` 导出）
|
||||
- **层提取**：解包层归档 → 逐层文件系统分析（复用 [[re-disk-forensics]] / [[re-fw-rootfs]] 的方法：文件枚举、删除文件恢复）
|
||||
- **分析重点**：配置与密钥（环境变量、挂载点、entrypoint/CMD 脚本）、历史层残留（删除的文件在旧层仍可恢复）、恶意镜像判定（启动命令、网络行为、可疑二进制）
|
||||
- **输出**：镜像内容清单 + 可疑项列表（与 [[re-ioc]] 的指标提取衔接）
|
||||
```
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 97 skills validated`（[[re-disk-forensics]] / [[re-fw-rootfs]] / [[re-ioc]] 均存在）
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-forensics/SKILL.md
|
||||
git commit -m "增强: re-forensics 融入容器镜像取证（分层提取与文件系统分析）"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 5: re-exploit 融入「内核利用」
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-exploit/SKILL.md`（「## 跨域联合」标题前插入章节）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无
|
||||
- Produces: re-exploit 的内核利用覆盖（提权原语 / 堆喷 / UAF 路径）
|
||||
|
||||
- [ ] **Step 1: 插入章节**
|
||||
|
||||
在 `.claude/skills/re-exploit/SKILL.md` 的「## 跨域联合」标题之前插入：
|
||||
|
||||
```markdown
|
||||
## 内核利用
|
||||
|
||||
与用户态同框架：fuzz（[[re-fuzzing]]）→ crash（[[re-crash-triage]]）→ 利用（本路径）。
|
||||
|
||||
- **提权原语**：modprobe_path 覆写（触发内核执行任意路径）、cred 结构覆写（uid/gid 置 0）、io_uring / BPF 子系统利用面
|
||||
- **堆喷与对象布局**：堆喷策略（同尺寸对象占位）、对象重叠（UAF 后伪造对象）、SLUB 分配器行为（per-CPU 缓存）
|
||||
- **内核 UAF 利用路径**：漏洞触发（悬垂引用）→ 对象重用（占位伪造）→ 控制流劫持（函数指针 / ops 表覆写）
|
||||
- **环境**：调试内核（KASAN 开、KASLR 关闭或绕过）、gdb/kgdb 断点、模块化测试（只读分析 + 沙箱验证）
|
||||
```
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 97 skills validated`（[[re-fuzzing]] / [[re-crash-triage]] 均存在）
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-exploit/SKILL.md
|
||||
git commit -m "增强: re-exploit 融入内核利用（提权原语/堆喷/UAF 路径）"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 6: re-tracing 融入「指令级追踪」
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-tracing/SKILL.md`（「## 跨域联合」标题前插入章节）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无
|
||||
- Produces: re-tracing 的指令级覆盖（QEMU 插件 / Intel PT）
|
||||
|
||||
- [ ] **Step 1: 插入章节**
|
||||
|
||||
在 `.claude/skills/re-tracing/SKILL.md` 的「## 跨域联合」标题之前插入：
|
||||
|
||||
```markdown
|
||||
## 指令级追踪
|
||||
|
||||
比系统调用级更深一层——指令粒度执行流：
|
||||
|
||||
- **QEMU 插件**：`-plugin` 加载指令级 trace 插件（insn 粒度、call/ret 路径、guest 代码块事件）；用途——脱壳后真实路径还原、反混淆（静态混淆无法隐藏实际执行）
|
||||
- **Intel PT**：硬件 trace（`perf record -e intel_pt`）→ 解码（`perf script` 或第三方解析）→ 分支流还原；用途——无插桩开销的完整执行路径
|
||||
- **trace 分析**：热点（执行频次排序）、路径还原（调用链重建）、与 [[re-deobfuscate]] 衔接（按真实路径过滤死代码）
|
||||
- **输出**：指令级执行流摘要（供 [[analysis-contract]] 证据存档）
|
||||
```
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 97 skills validated`（[[re-deobfuscate]] / [[analysis-contract]] 均存在）
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-tracing/SKILL.md
|
||||
git commit -m "增强: re-tracing 融入指令级追踪（QEMU 插件/Intel PT）"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 7: re-disk-forensics 融入「数据库文件格式」
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-disk-forensics/SKILL.md`（「## 跨域联合」标题前插入章节）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无
|
||||
- Produces: re-disk-forensics 的数据库文件覆盖（SQLite 结构 / WAL / 恢复）
|
||||
|
||||
- [ ] **Step 1: 插入章节**
|
||||
|
||||
在 `.claude/skills/re-disk-forensics/SKILL.md` 的「## 跨域联合」标题之前插入：
|
||||
|
||||
```markdown
|
||||
## 数据库文件格式
|
||||
|
||||
- **SQLite 结构**：页头（page header 字段）、btree 页（interior/leaf 类型）、记录格式（varint 长度编码 / 类型码）、溢出页（大字段跨页）
|
||||
- **WAL 恢复**：WAL 文件帧解析（未 checkpoint 的事务）、checkpoint 边界判定（恢复点）
|
||||
- **取证应用**：浏览器/App 数据库——删除记录恢复（freelist 页残留）、未提交事务提取（WAL 内）
|
||||
- **工具**：`sqlite3` CLI 只读模式（`sqlite3 -readonly`）、页级解析脚本（python 按页结构遍历）
|
||||
```
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 97 skills validated`（章节内无 [[链接]] 或确认指向已存在技能）
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-disk-forensics/SKILL.md
|
||||
git commit -m "增强: re-disk-forensics 融入数据库文件格式（SQLite 页结构/WAL/恢复）"
|
||||
```
|
||||
@@ -0,0 +1,768 @@
|
||||
# 6 个新技能 实现计划
|
||||
|
||||
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
|
||||
|
||||
**Goal:** 新增 6 个原子技能（re-doc-malware / re-variant / re-hunting / re-mobile-forensics / re-stego / re-browser-ext）+ 挂载同步，技能总数 101 → 107。
|
||||
|
||||
**Architecture:** 纯技能文档扩展。6 个新技能目录（SKILL.md，按 docs/skill-template.md 原子技能规范）+ 挂载（5 网关子技能/选择树、rerouting 3 行）+ 计数同步（README / AGENTS / marketplace）。
|
||||
|
||||
**Tech Stack:** Markdown / YAML frontmatter / validate.mjs（npm test，现有）
|
||||
|
||||
## Global Constraints
|
||||
|
||||
- **红线 1 呈现中性**：禁用「最推荐」「强烈建议」等最高级强推措辞
|
||||
- **红线 2 隐私脱敏**：内容不指向具体项目/公司/产品
|
||||
- **不绑定具体工具**：方法为核心，工具为可替换示例；「工具准备」按模板给跨 OS 安装命令
|
||||
- validate.mjs：frontmatter `name`=目录名、`description` 非空、`type: atomic` 必含「## 工具准备」、`[[链接]]` 必须解析
|
||||
- 工作区已干净（无未提交文件）——所有目标文件可正常修改提交；各任务 commit 只 `git add` 本任务列出的文件
|
||||
- 当前分支 `main`；`npm test` 预期按任务标注递增（102 → 107）
|
||||
|
||||
---
|
||||
|
||||
### Task 1: 创建 re-doc-malware 技能
|
||||
|
||||
**Files:**
|
||||
- Create: `.claude/skills/re-doc-malware/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无（新目录）
|
||||
- Produces: 技能目录 `re-doc-malware`（供 Task 7 的 [[re-doc-malware]] 链接解析；计数 101 → 102）
|
||||
|
||||
- [ ] **Step 1: 创建目录与 SKILL.md**
|
||||
|
||||
```bash
|
||||
mkdir -p .claude/skills/re-doc-malware
|
||||
```
|
||||
|
||||
写入 `.claude/skills/re-doc-malware/SKILL.md`：
|
||||
|
||||
````markdown
|
||||
---
|
||||
name: re-doc-malware
|
||||
type: atomic
|
||||
description: >
|
||||
恶意文档分析：PDF/Office 武器化、宏链、文档漏洞利用、载荷提取。
|
||||
触发词：恶意文档、钓鱼文档、PDF恶意、宏文档、docm、文档漏洞、恶意附件。
|
||||
---
|
||||
|
||||
# 恶意文档分析
|
||||
|
||||
## 何时使用 / 何时不用
|
||||
|
||||
- 用：钓鱼附件（PDF/Office/RTF）、文档漏洞利用样本、宏文档、文档型恶意载荷
|
||||
- 不用：纯脚本宏（转 [[re-script-deob]]）；文档仅是载体（核心逻辑在下载载荷）
|
||||
|
||||
## 工具准备
|
||||
|
||||
### pdf-parser / peepdf（PDF 结构分析）
|
||||
|
||||
- Linux: `apt install pdf-parser` 或 `pip install peepdf`；macOS: `brew install pdf-parser` / pip
|
||||
- Windows: pip（WSL 亦可）
|
||||
- 验证: `pdf-parser --version`（无则 `python3 -m pdf_parser --help`）
|
||||
|
||||
### olevba / oledump（Office 宏提取）
|
||||
|
||||
- 多平台: `pip install oletools`
|
||||
- 验证: `olevba --help`
|
||||
|
||||
### LibreOffice（沙箱打开验证，可选）
|
||||
|
||||
- Linux: `apt install libreoffice` / `dnf install libreoffice`；macOS: `brew install --cask libreoffice`；Windows: 官方安装包
|
||||
- 验证: `libreoffice --version`
|
||||
|
||||
### 7z（OLE/OOXML 解包）
|
||||
|
||||
- Linux: `apt install p7zip-full`；macOS: `brew install sevenzip`；Windows: 官方安装包
|
||||
- 验证: `7z --help`
|
||||
|
||||
## 操作步骤
|
||||
|
||||
按顺序执行；动态打开文档必须沙箱（[[re-sandbox]]，[[platform-tips]] 最高原则）。每步产物存档（路径 + sha256，见 [[re-triage]]）。
|
||||
|
||||
1. **文档类型识别**：
|
||||
```sh
|
||||
file sample.pdf sample.docm sample.rtf
|
||||
```
|
||||
- PDF：`%PDF` 头；Office 旧格式：CFB（OLE 复合文档，`D0 CF 11 E0`）；OOXML：zip（`PK`）；RTF：`{\rtf`
|
||||
- 类型决定后续工具链
|
||||
|
||||
2. **PDF 恶意分析**：
|
||||
```sh
|
||||
pdf-parser -f sample.pdf | head -50 # 对象树遍历（-f 强制，解 FlateDecode）
|
||||
pdf-parser -s /JS sample.pdf # JavaScript 动作
|
||||
pdf-parser -s /OpenAction sample.pdf # 打开即执行动作
|
||||
```
|
||||
- 恶意特征：`/JS`（JavaScript 动作）、`/OpenAction`（打开触发）、`/AA`（自动动作）、`/Launch`（外部程序）、嵌入文件（`/EmbeddedFile`）
|
||||
- 漏洞文档：`/JBIG2Decode`（JBIG2 漏洞）、`/RichMedia`（Flash 遗留）等 CVE 对应结构——按结构特征对照已知利用模式
|
||||
- JS 载荷 → [[re-script-deob]] 还原
|
||||
|
||||
3. **Office 分析**：
|
||||
```sh
|
||||
olevba -c sample.docm > macro.txt # 提取宏源码
|
||||
olevba --decode -c sample.docm > macro_decoded.txt
|
||||
strings sample.docm | grep -iE 'DDEAUTO|http|powershell' | head
|
||||
```
|
||||
- 宏链：AutoOpen / Workbook_Open / Document_Open / Auto_Open
|
||||
- 其他向量：DDE 域（`DDEAUTO`）、外部链接（`/hyperlink`）、OLE 嵌入对象（7z 解包后逐个分析）、模板注入（`/word/_rels`）
|
||||
- 宏载荷 → [[re-script-deob]] 去混淆链
|
||||
|
||||
4. **载荷提取**：
|
||||
- 提取项：脚本/URL/二进制/多级载荷（每层存档编号）
|
||||
- 指标提取 → [[re-ioc]]（URL/域名/哈希）
|
||||
- 提取物初勘 → [[re-triage]]
|
||||
|
||||
5. **动态验证**（沙箱）：
|
||||
- [[re-sandbox]] 内用 LibreOffice/阅读器打开，网络隔离（INetSim/fake DNS）
|
||||
- 观察：文件释放、进程链、网络回连（[[re-behavior]] 衔接）
|
||||
|
||||
## 跨域联合
|
||||
|
||||
- [[re-malware]] 网关：本技能归属（选择树「钓鱼附件」分支）
|
||||
- [[re-script-deob]]：宏/JS 去混淆还原
|
||||
- [[re-sandbox]]：动态打开强制前置
|
||||
- [[re-ioc]]：提取指标
|
||||
- [[re-behavior]]：行为验证衔接
|
||||
|
||||
## 常见坑与陷阱
|
||||
|
||||
- **PDF 对象流压缩未解**：现象——pdf-parser 输出无 `/JS`；原因——对象在 FlateDecode 压缩流内；对策——`-f` 强制解压再查
|
||||
- **宏被混淆**：现象——olevba 提取后满屏拼接/编码；原因——宏混淆；对策——[[re-script-deob]] 去混淆链逐层解
|
||||
- **文档漏洞版本特征**：现象——结构特征与已知 CVE 不符；原因——利用代码针对特定版本；对策——按结构特征（非版本号）对照利用模式，标注版本假设
|
||||
- **沙箱检测文档（延迟执行）**：现象——沙箱内无行为；原因——文档检测环境后不触发；对策——延长观察窗口、模拟用户交互（滚动/点击）
|
||||
- **模板注入易漏**：现象——宏正常但仍有外联；原因——`/word/_rels` 远程模板；对策——解包后检查全部 rels 文件
|
||||
````
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 102 skills validated`（[[链接]]：re-script-deob/re-sandbox/re-triage/re-ioc/re-behavior/re-malware/platform-tips 均存在）
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-doc-malware/SKILL.md
|
||||
git commit -m "feat: re-doc-malware 技能——PDF/Office 武器化分析与载荷提取"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 2: 创建 re-variant 技能
|
||||
|
||||
**Files:**
|
||||
- Create: `.claude/skills/re-variant/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无（新目录）
|
||||
- Produces: 技能目录 `re-variant`（供 Task 7 的 [[re-variant]] 链接解析；计数 102 → 103）
|
||||
|
||||
- [ ] **Step 1: 创建目录与 SKILL.md**
|
||||
|
||||
```bash
|
||||
mkdir -p .claude/skills/re-variant
|
||||
```
|
||||
|
||||
写入 `.claude/skills/re-variant/SKILL.md`：
|
||||
|
||||
````markdown
|
||||
---
|
||||
name: re-variant
|
||||
type: atomic
|
||||
description: >
|
||||
二进制变体/补丁对比：函数匹配、N-day 补丁 diff、变体溯源与相似度分析。
|
||||
触发词：二进制对比、补丁对比、N-day、变体分析、BinDiff、函数匹配、样本相似。
|
||||
---
|
||||
|
||||
# 二进制变体/补丁对比
|
||||
|
||||
## 何时使用 / 何时不用
|
||||
|
||||
- 用：补丁前后对比（漏洞定位）、家族变体关联、样本溯源、N-day 分析
|
||||
- 不用：单样本深度分析（走 [[re-binary-core]] 通用路径）
|
||||
|
||||
## 工具准备
|
||||
|
||||
### BinDiff / Diaphora（函数匹配插件）
|
||||
|
||||
- BinDiff: Windows 商业工具（安装指引，可替换为开源替代）；Diaphora: 多平台开源（`git clone https://github.com/joxeankoret/diaphora`，IDA/Ghidra 插件）
|
||||
- Ghidra 侧替代: BinDiff 官方 Ghidra 插件或 Diaphora 的 Ghidra 移植
|
||||
- 验证: 插件在反编译器内可加载
|
||||
|
||||
### radiff2 / rz-diff（rizin 命令行对比）
|
||||
|
||||
- Linux: `apt install rizin` / `pacman -S rizin`；macOS: `brew install rizin`；Windows: 官方安装包
|
||||
- 验证: `rz-diff --version`
|
||||
|
||||
### readelf（符号对齐辅助）
|
||||
|
||||
- 安装与验证见 [[re-cpp-abi]] 工具准备
|
||||
|
||||
## 操作步骤
|
||||
|
||||
按顺序执行，每步产物存档（路径 + sha256，见 [[re-triage]]）。
|
||||
|
||||
1. **函数匹配**：
|
||||
```sh
|
||||
# 命令行快速对比（rizin 系）：指令哈希 + 调用图相似度
|
||||
rz-diff -ss sample_v1 sample_v2 | head -30
|
||||
```
|
||||
- 匹配维度：指令哈希（相同代码）、调用图（子图同构）、导入导出对齐、字符串/常量引用
|
||||
- 工具（BinDiff/Diaphora）输出：matched / changed / new / deleted 函数集
|
||||
- strip 后符号缺失：靠结构匹配（见坑 2）
|
||||
|
||||
2. **补丁 diff（N-day）**：
|
||||
- 修复前后对比 → `changed` 函数集 = 漏洞点候选
|
||||
- 变更函数深挖：新条件分支/新校验/新增调用（[[re-ghidra]] / [[re-ida]] 反编译）
|
||||
- 反推漏洞：旧代码的缺陷模式（缺失校验/越界/释放后使用）
|
||||
- 产出：漏洞函数 + 缺陷模式推断（置信度标注）
|
||||
|
||||
3. **变体溯源**：
|
||||
- 家族内样本两两对比 → 相似度矩阵 → 聚类（共享函数比例阈值）
|
||||
- 演进链：按时间线/相似度排序样本（早期 vs 晚期变体）
|
||||
- 共享独有函数 = 家族标志（与 [[re-attribution]] 能力证据衔接）
|
||||
|
||||
4. **输出差异清单**：
|
||||
- 格式：变更函数表（函数名/地址/变更类型/相似度）+ 结论
|
||||
- 按 [[analysis-contract]] 数据契约传递（下游消费）
|
||||
|
||||
## 跨域联合
|
||||
|
||||
- [[re-binary-core]] 网关：本技能归属（选择树「补丁/N-day 对比」分支）
|
||||
- [[re-ghidra]] / [[re-ida]]：反编译底座（变更函数深挖）
|
||||
- [[re-attribution]]：变体关联的能力证据衔接
|
||||
- [[analysis-contract]]：差异清单按数据契约传递
|
||||
|
||||
## 常见坑与陷阱
|
||||
|
||||
- **编译器差异干扰匹配**：现象——同源码不同编译器编译被判不相似；原因——优化/代码生成差异；对策——用调用图与常量引用加权，降低指令哈希权重
|
||||
- **strip 后符号缺失**：现象——函数名全无；原因——符号剥离；对策——结构匹配（入口特征/调用模式）、导入表锚定
|
||||
- **跨架构对比降级**：现象——x86 vs ARM 匹配率低；原因——指令集不同；对策——只比逻辑层（调用图/常量/字符串），标注跨架构局限
|
||||
- **大量相似导致误关联**：现象——共享库代码导致虚高相似度；原因——公共依赖（libc/框架）；对策——排除共享库符号，只比业务代码
|
||||
- **补丁 diff 定位偏差**：现象——changed 函数多，漏洞点被淹没；原因——补丁含重构；对策——按变更语义过滤（新增校验/边界处理优先）
|
||||
````
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 103 skills validated`（[[链接]]：re-binary-core/re-ghidra/re-ida/re-attribution/analysis-contract/re-triage/re-cpp-abi 均存在）
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-variant/SKILL.md
|
||||
git commit -m "feat: re-variant 技能——函数匹配/补丁 diff/变体溯源"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 3: 创建 re-hunting 技能
|
||||
|
||||
**Files:**
|
||||
- Create: `.claude/skills/re-hunting/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无（新目录）
|
||||
- Produces: 技能目录 `re-hunting`（供 Task 7 的 [[re-hunting]] 链接解析；计数 103 → 104）
|
||||
|
||||
- [ ] **Step 1: 创建目录与 SKILL.md**
|
||||
|
||||
```bash
|
||||
mkdir -p .claude/skills/re-hunting
|
||||
```
|
||||
|
||||
写入 `.claude/skills/re-hunting/SKILL.md`：
|
||||
|
||||
````markdown
|
||||
---
|
||||
name: re-hunting
|
||||
type: atomic
|
||||
description: >
|
||||
威胁狩猎方法论：假设驱动、遥测源选择、基线对比与验证闭环。
|
||||
触发词：威胁狩猎、狩猎、hunting、假设驱动、遥测分析、异常检测。
|
||||
---
|
||||
|
||||
# 威胁狩猎
|
||||
|
||||
## 何时使用 / 何时不用
|
||||
|
||||
- 用：主动狩猎请求（「环境里有没有 X 的活动」）、假设驱动的环境排查
|
||||
- 不用：已知样本分析（[[re-behavior]]）；IOC 查询（[[re-ti]]）；单点证据深挖（各域技能）
|
||||
|
||||
## 工具准备
|
||||
|
||||
### 日志分析工具（通用）
|
||||
|
||||
- 多平台: jq / grep / awk（各发行版自带或 `apt install jq` / `brew install jq`）
|
||||
- 验证: `jq --version`
|
||||
|
||||
### 遥测查询（按环境）
|
||||
|
||||
- SIEM/EDR 查询接口（按部署环境给查询指引，工具不绑定）
|
||||
- 本地日志: journalctl / Windows 事件日志工具（按平台）
|
||||
|
||||
### ATT&CK 导航（假设对齐参考）
|
||||
|
||||
- 网页工具（公开访问）；本地可下载 Navigator 层文件
|
||||
|
||||
## 操作步骤
|
||||
|
||||
按顺序执行；假设明确再动手（坑 5）。每步产物存档（路径 + sha256，见 [[re-triage]]）。
|
||||
|
||||
1. **狩猎假设生成**：
|
||||
- 输入：威胁情报（[[re-ti]]）、已知攻击模式（[[re-behavior]] 经验）、环境特征
|
||||
- 假设句式：「攻击者可能通过 X 技术在环境内做了 Y」——X 对齐 ATT&CK 技术
|
||||
- 产出：假设列表（每个假设 = 可证伪的搜索目标）
|
||||
|
||||
2. **遥测源选择**：
|
||||
- 按假设选数据源：进程行为 → EDR/进程日志；网络 → 流量/防火墙日志；登录 → 认证日志；文件 → 文件系统监控
|
||||
- 数据源缺失 → 标注盲区（结论的有效性边界）
|
||||
|
||||
3. **基线 vs 异常**：
|
||||
- 基线：正常窗口的统计分布（频率/来源/目标特征）
|
||||
- 异常检测：偏离基线的行为（新进程链、非常规时段、异常目标）、规则匹配（已知模式）
|
||||
- 聚类：异常条目按特征聚类（减少人工逐个审查）
|
||||
|
||||
4. **验证闭环**：
|
||||
- 命中确认：异常 → 深挖（[[re-behavior]] 行为分析、[[re-variant]] 样本关联）
|
||||
- 误报排除：白名单核对、环境解释（合法变更/维护窗口）
|
||||
- 证据存档：按 [[analysis-contract]] 复核格式（结论/证据/置信度）
|
||||
- 闭环输出：确认命中 → 事件报告；未命中 → 假设归档（可复跑）
|
||||
|
||||
## 跨域联合
|
||||
|
||||
- [[re-forensics]] 网关：本技能归属
|
||||
- [[re-ti]]：情报输入（假设来源）
|
||||
- [[re-behavior]]：命中深挖
|
||||
- [[re-variant]]：样本关联
|
||||
- [[analysis-contract]]：结论按复核格式交付
|
||||
|
||||
## 常见坑与陷阱
|
||||
|
||||
- **基线污染**：现象——异常被视为正常；原因——环境本身已被攻陷（基线含恶意活动）；对策——基线窗口选择在已知干净时段，标注基线假设
|
||||
- **遥测缺失盲区**：现象——无异常结论但环境有活动；原因——关键数据源未采集；对策——步骤 2 显式标注盲区，结论限定「在已采集遥测内」
|
||||
- **误报疲劳**：现象——大量命中无人深挖；原因——规则过宽/阈值过低；对策——先聚类再审查，阈值按基线校准
|
||||
- **假设过窄**：现象——只查了一个技术；原因——假设单一；对策——按 ATT&CK 技术族生成多假设（覆盖率声明）
|
||||
- **结论过强**：现象——「环境干净」声明；原因——未标注盲区与假设边界；对策——结论带限定（见坑 2）
|
||||
````
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 104 skills validated`（[[链接]]：re-behavior/re-ti/re-variant/re-forensics/analysis-contract/re-triage 均存在）
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-hunting/SKILL.md
|
||||
git commit -m "feat: re-hunting 技能——假设驱动狩猎/遥测选择/验证闭环"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 4: 创建 re-mobile-forensics 技能
|
||||
|
||||
**Files:**
|
||||
- Create: `.claude/skills/re-mobile-forensics/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无（新目录）
|
||||
- Produces: 技能目录 `re-mobile-forensics`（供 Task 7 的 [[re-mobile-forensics]] 链接解析；计数 104 → 105）
|
||||
|
||||
- [ ] **Step 1: 创建目录与 SKILL.md**
|
||||
|
||||
```bash
|
||||
mkdir -p .claude/skills/re-mobile-forensics
|
||||
```
|
||||
|
||||
写入 `.claude/skills/re-mobile-forensics/SKILL.md`：
|
||||
|
||||
````markdown
|
||||
---
|
||||
name: re-mobile-forensics
|
||||
type: atomic
|
||||
description: >
|
||||
移动设备取证：Android/iOS 备份解析、应用数据提取、删除恢复与时间线。
|
||||
触发词：移动取证、手机取证、ADB备份、iTunes备份、手机数据提取。
|
||||
---
|
||||
|
||||
# 移动设备取证
|
||||
|
||||
## 何时使用 / 何时不用
|
||||
|
||||
- 用：设备备份/镜像的数据提取、应用数据取证、删除恢复
|
||||
- 不用：App 逆向分析（[[re-mobile]]）；通用文件系统分析（[[re-disk-forensics]]）
|
||||
|
||||
## 工具准备
|
||||
|
||||
### adb（Android 设备接口）
|
||||
|
||||
- Linux: `apt install adb` / `dnf install android-tools`；macOS: `brew install android-platform-tools`；Windows: 官方平台工具
|
||||
- 验证: `adb --version`
|
||||
|
||||
### libimobiledevice（iOS 设备接口）
|
||||
|
||||
- Linux: `apt install libimobiledevice-utils`；macOS: `brew install libimobiledevice`；Windows: 官方构建
|
||||
- 验证: `idevice_id -l`（列出设备）
|
||||
|
||||
### 备份解析工具
|
||||
|
||||
- Android: `ab` 备份格式解析（python 脚本或工具）；iOS: `libimobiledevice` 的 `idevicebackup2` + manifest 解析
|
||||
- sqlite3（数据库读取，见 [[re-disk-forensics]] 工具准备）
|
||||
|
||||
## 操作步骤
|
||||
|
||||
按顺序执行；设备操作遵循授权边界（红线：仅授权设备）。每步产物存档（路径 + sha256，见 [[re-triage]]）。
|
||||
|
||||
1. **Android 提取**：
|
||||
```sh
|
||||
adb backup -f backup.ab -all # 全量备份（应用需允许备份）
|
||||
# ab 格式：头（ANDROID BACKUP）+ 可选 AES 加密 + tar 负载
|
||||
adb shell run-as com.target.app ls data # 应用沙箱（debuggable 应用）
|
||||
```
|
||||
- 备份解析：ab 头 → 解包 tar（加密备份需密码）
|
||||
- 应用沙箱：`run-as`（debuggable）/ root 设备直接读
|
||||
- 数据库提取 → sqlite3（[[re-disk-forensics]] 的 SQLite 页结构方法）
|
||||
|
||||
2. **iOS 提取**：
|
||||
```sh
|
||||
idevicebackup2 backup --full ./backup_dir
|
||||
# 备份结构：manifest.plist + 按哈希路径组织的文件
|
||||
```
|
||||
- 备份解析：manifest.plist（文件映射）、加密备份需密码（无密码则标注不可提取）
|
||||
- Keychain 条目（需提取工具，权限边界）
|
||||
- 应用数据：Library/Preferences、Documents、Caches（按应用沙箱路径）
|
||||
|
||||
3. **删除恢复与时间线**：
|
||||
- SQLite 删除记录（freelist 残留——[[re-disk-forensics]] 数据库文件格式方法）
|
||||
- 时间线重建：文件时间戳 + 数据库记录时间（注意时区——见坑 5）
|
||||
- 产出：时间线表（时间/动作/来源）+ 恢复数据
|
||||
|
||||
## 跨域联合
|
||||
|
||||
- [[re-forensics]] 网关：本技能归属
|
||||
- [[re-disk-forensics]]：SQLite 结构/WAL/删除恢复方法
|
||||
- [[re-mobile]]：App 结构理解（沙箱路径/数据结构）
|
||||
|
||||
## 常见坑与陷阱
|
||||
|
||||
- **加密备份无密钥**：现象——备份无法解析；原因——AES 加密；对策——无密码则标注不可提取，不硬破解（授权边界）
|
||||
- **ADB backup 权限限制**：现象——备份为空；原因——应用未声明 `allowBackup`；对策——换 root/镜像提取，标注路径局限
|
||||
- **iOS 哈希路径混淆**：现象——文件找不到；原因——备份文件按内容哈希组织（非原名）；对策——manifest.plist 映射解析
|
||||
（注：本行表述已于 2026-09-13 修正——文件按 fileID 组织且 fileID 由路径派生（SHA1(domain + "-" + relativePath)）不是内容哈希，索引文件是 Manifest.db；现文见 `.claude/skills/re-mobile-forensics/SKILL.md`，核验记录见 `docs/audit/`）
|
||||
- **时间线时区**：现象——时间错位；原因——设备时区与取证时区不一致；对策——统一 UTC 记录，标注设备时区
|
||||
- **沙箱边界**：现象——拿不到目标数据；原因——无 root/未越狱；对策——按可提取范围交付（限定结论），不越授权
|
||||
````
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 105 skills validated`（[[链接]]：re-mobile/re-disk-forensics/re-forensics/re-triage 均存在）
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-mobile-forensics/SKILL.md
|
||||
git commit -m "feat: re-mobile-forensics 技能——Android/iOS 备份解析与删除恢复"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 5: 创建 re-stego 技能
|
||||
|
||||
**Files:**
|
||||
- Create: `.claude/skills/re-stego/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无（新目录）
|
||||
- Produces: 技能目录 `re-stego`（供 Task 7 的 [[re-stego]] 链接解析；计数 105 → 106）
|
||||
|
||||
- [ ] **Step 1: 创建目录与 SKILL.md**
|
||||
|
||||
```bash
|
||||
mkdir -p .claude/skills/re-stego
|
||||
```
|
||||
|
||||
写入 `.claude/skills/re-stego/SKILL.md`：
|
||||
|
||||
````markdown
|
||||
---
|
||||
name: re-stego
|
||||
type: atomic
|
||||
description: >
|
||||
隐写术检测与提取：文件尾附加、图片 LSB、音频与其他载体、提取验证。
|
||||
触发词：隐写、stego、LSB、文件尾附加、隐写提取、图片隐写。
|
||||
---
|
||||
|
||||
# 隐写术检测与提取
|
||||
|
||||
## 何时使用 / 何时不用
|
||||
|
||||
- 用：隐写怀疑（CTF 题/取证对象）、文件尾异常、图片/音频异常
|
||||
- 不用：正常文件分析（各归各域技能）
|
||||
|
||||
## 工具准备
|
||||
|
||||
### zsteg（图片 LSB 扫描）
|
||||
|
||||
- 多平台: `gem install zsteg` 或源码（GitHub）
|
||||
- 验证: `zsteg -v`
|
||||
|
||||
### steghide（图片/音频隐写）
|
||||
|
||||
- Linux: `apt install steghide` / `dnf install steghide`；macOS: `brew install steghide`
|
||||
- 验证: `steghide info --help`
|
||||
|
||||
### binwalk（尾部扫描）
|
||||
|
||||
- 安装与验证见 [[re-fw-extract]] 工具准备
|
||||
|
||||
### python3（位操作/验证脚本）
|
||||
|
||||
- 安装与验证见 [[re-python]] 工具准备
|
||||
|
||||
## 操作步骤
|
||||
|
||||
按顺序执行，每步产物存档（路径 + sha256，见 [[re-triage]]）。
|
||||
|
||||
1. **文件尾附加检测**：
|
||||
```sh
|
||||
binwalk sample.png | tail -20 # 附加数据扫描
|
||||
hexdump -C sample.png | tail -10 # 尾部目检
|
||||
```
|
||||
- 尾部附加：文件正常但尾部有多余数据（衔接 [[re-patching]] 尾部附加经验）
|
||||
- 提取：binwalk 自动分割或 dd 按偏移提取 → magic 检查（[[re-triage]]）
|
||||
|
||||
2. **图片 LSB**：
|
||||
```sh
|
||||
zsteg sample.png # 全通道 LSB 扫描
|
||||
zsteg -E 'b1,rgb,lsb,xy' sample.png # 指定通道/位平面提取
|
||||
```
|
||||
- 通道：RGB/alpha 各通道最低位；位平面：b1/b2（低 2 位）
|
||||
- 顺序：行序/位序影响提取结果（见坑 1）
|
||||
- 无工具时的脚本路径：python3 按像素遍历提取位序列
|
||||
|
||||
3. **其他载体**：
|
||||
- 音频：频谱隐写（音频可视化工具查频域图案）、相位/回声隐写
|
||||
- 文件冗余区：EXIF、文件头保留区、压缩文件未用空间
|
||||
- 多载体组合（题目常用）
|
||||
|
||||
4. **提取验证**：
|
||||
- magic 检查（提取物头部特征）
|
||||
- 可读性验证（strings/file）
|
||||
- 隐写前压缩：先提取再解压（提取物查压缩头——zlib `78 9C` / gzip `1F 8B`，见坑 3）
|
||||
|
||||
## 跨域联合
|
||||
|
||||
- [[re-ctf]] 网关：本技能归属
|
||||
- [[re-fw-extract]]：binwalk 复用
|
||||
- [[re-patching]]：尾部附加经验衔接
|
||||
- [[re-triage]]：提取物初勘
|
||||
|
||||
## 常见坑与陷阱
|
||||
|
||||
- **LSB 顺序**：现象——提取乱码；原因——行序（从上到下/从下到上）/位序（LSB 优先/MSB 优先）；对策——工具自动尝试或脚本枚举组合
|
||||
- **多载体误判**：现象——一个文件中多个隐写层；原因——嵌套隐写；对策——分层提取，每层验证
|
||||
- **隐写前压缩**：现象——提取物乱码；原因——明文先压缩再嵌入；对策——先查压缩特征（zlib 头）再解压
|
||||
- **工具输出噪声**：现象——大量候选；原因——扫描输出含误报；对策——按 magic/可读性过滤
|
||||
- **载体本身异常**：现象——文件损坏；原因——隐写写入破坏结构；对策——先修复/容忍损坏（按位提取不依赖结构）
|
||||
````
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 106 skills validated`（[[链接]]：re-ctf/re-fw-extract/re-patching/re-triage/re-python 均存在）
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-stego/SKILL.md
|
||||
git commit -m "feat: re-stego 技能——文件尾/LSB/多载体隐写检测与提取"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 6: 创建 re-browser-ext 技能
|
||||
|
||||
**Files:**
|
||||
- Create: `.claude/skills/re-browser-ext/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无（新目录）
|
||||
- Produces: 技能目录 `re-browser-ext`（供 Task 7 的 [[re-browser-ext]] 链接解析；计数 106 → 107）
|
||||
|
||||
- [ ] **Step 1: 创建目录与 SKILL.md**
|
||||
|
||||
```bash
|
||||
mkdir -p .claude/skills/re-browser-ext
|
||||
```
|
||||
|
||||
写入 `.claude/skills/re-browser-ext/SKILL.md`：
|
||||
|
||||
````markdown
|
||||
---
|
||||
name: re-browser-ext
|
||||
type: atomic
|
||||
description: >
|
||||
浏览器扩展逆向：权限清单、恶意行为定位、混淆还原、上架审查绕过面。
|
||||
触发词：浏览器扩展、Chrome扩展、Firefox扩展、恶意扩展、extension。
|
||||
---
|
||||
|
||||
# 浏览器扩展逆向
|
||||
|
||||
## 何时使用 / 何时不用
|
||||
|
||||
- 用：扩展文件（crx/xpi/zip）、恶意扩展行为分析、扩展权限审计
|
||||
- 不用：网页 JS 混淆（[[re-script-deob]] 覆盖纯脚本）
|
||||
|
||||
## 工具准备
|
||||
|
||||
### unzip / 7z（解包）
|
||||
|
||||
- 安装与验证见 [[re-doc-malware]] 工具准备（7z）
|
||||
|
||||
### jq（manifest 解析）
|
||||
|
||||
- Linux: `apt install jq`；macOS: `brew install jq`；Windows: 官方构建
|
||||
- 验证: `jq --version`
|
||||
|
||||
### node（扩展脚本运行/验证，可选）
|
||||
|
||||
- 各平台安装见 [[re-python]] 工具准备模式（node 官方安装包）
|
||||
- 验证: `node --version`
|
||||
|
||||
## 操作步骤
|
||||
|
||||
按顺序执行，每步产物存档（路径 + sha256，见 [[re-triage]]）。
|
||||
|
||||
1. **解包与结构**：
|
||||
```sh
|
||||
unzip sample.crx -d ext/ # crx/xpi = zip 容器
|
||||
jq '.permissions, .host_permissions' ext/manifest.json
|
||||
```
|
||||
- 结构：manifest.json + 背景脚本（background/service_worker）+ 内容脚本（content_scripts）+ 页面
|
||||
- 权限清单：`permissions`（API 权限）、`host_permissions`（站点访问）——权限决定能力边界
|
||||
|
||||
2. **恶意行为定位**：
|
||||
- 数据外泄：fetch/XHR/beacon（[[re-netcap]] 衔接）、`navigator.sendBeacon`、图片像素外传
|
||||
- 权限滥用：tabs（读取页面）、storage（数据收集）、webRequest（流量篡改/监控）、clipboard（剪贴板窃取）
|
||||
- 注入面：content_scripts 匹配站点、动态注入（`chrome.scripting.executeScript`）
|
||||
- 后台脚本是核心（MV3 的 service worker / MV2 的 background page）
|
||||
|
||||
3. **混淆还原**：
|
||||
- 衔接 [[re-script-deob]] 高级混淆对抗（bootstrap/字符串表/CFF）
|
||||
- 远程代码：MV2 允许远程 JS（`eval`/动态加载）；MV3 禁止远程 JS（远程代码是审查绕过信号）
|
||||
|
||||
4. **上架审查绕过面分析**：
|
||||
- 动态加载（运行时拉取代码——MV2 特征）
|
||||
- obfuscation 检测规避（代码混淆超过阈值触发审查）
|
||||
- 多阶段（无害首版 + 更新后恶意——版本对比 [[re-variant]] 思路）
|
||||
|
||||
## 跨域联合
|
||||
|
||||
- [[re-managed]] 网关：本技能归属（选择树「浏览器扩展」分支）
|
||||
- [[re-script-deob]]：混淆还原
|
||||
- [[re-netcap]]：网络行为衔接
|
||||
- [[re-variant]]：扩展版本对比（更新后恶意检测）
|
||||
|
||||
## 常见坑与陷阱
|
||||
|
||||
- **manifest 版本差异**：现象——MV2 分析思路套 MV3 失效；原因——权限模型不同（MV3 禁远程代码/后台改 service worker）；对策——先确认 manifest_version
|
||||
- **远程代码策略**：现象——静态找不到恶意逻辑；原因——代码远程拉取（MV2）；对策——网络侧抓取（[[re-netcap]]）后还原
|
||||
- **动态注入绕过静态分析**：现象——content_scripts 无恶意但行为异常；原因——运行时注入；对策——hook 注入 API（scripting.executeScript）
|
||||
- **沙箱与页面隔离**：现象——扩展 API 调用点难定位；原因——扩展上下文与页面上下文隔离；对策——分上下文分析（background/content/page）
|
||||
- **更新后恶意**：现象——首版干净；原因——版本更新注入恶意；对策——版本 diff（[[re-variant]]）
|
||||
````
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 107 skills validated`（[[链接]]：re-script-deob/re-netcap/re-variant/re-managed/re-triage/re-doc-malware 均存在——re-variant 由 Task 2 创建，re-doc-malware 由 Task 1 创建）
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-browser-ext/SKILL.md
|
||||
git commit -m "feat: re-browser-ext 技能——扩展权限审计/恶意行为/混淆还原"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 7: 挂载与计数同步
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-malware/SKILL.md`（子技能列表 + 选择树分支）
|
||||
- Modify: `.claude/skills/re-binary-core/SKILL.md`（子技能列表 + 选择树分支）
|
||||
- Modify: `.claude/skills/re-forensics/SKILL.md`（子技能列表加 2 个）
|
||||
- Modify: `.claude/skills/re-ctf/SKILL.md`（子技能列表加 1 个）
|
||||
- Modify: `.claude/skills/re-managed/SKILL.md`（子技能列表 + 选择树分支）
|
||||
- Modify: `.claude/skills/re-analyze/references/rerouting.md`（A 表加 3 行）
|
||||
- Modify: `README.md`（计数 101→107、88→94、导航加 6 行）
|
||||
- Modify: `AGENTS.md`（101→107、88→94）
|
||||
- Modify: `.claude-plugin/marketplace.json`（101→107）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1-6 的 6 个技能目录（链接可解析）
|
||||
- Produces: 6 技能全库可达；计数 107 = 1 + 12 + 94
|
||||
|
||||
- [ ] **Step 1: 网关挂载（5 文件，7 处编辑）**
|
||||
|
||||
`.claude/skills/re-malware/SKILL.md` 子技能列表（description 行，末尾 `[[re-fileless]]`）追加 `、[[re-doc-malware]]`；选择树（「**无文件样本**…」分支后）插入：
|
||||
|
||||
```markdown
|
||||
- **钓鱼附件（PDF/Office/RTF 文档）** → [[re-doc-malware]]（文档武器化/宏链/载荷提取）
|
||||
```
|
||||
|
||||
`.claude/skills/re-binary-core/SKILL.md` 子技能列表（description 行，末尾 `[[re-fp-runtime]]`）追加 `、[[re-variant]]`；选择树（「**目标是 Haskell/OCaml 产物**…」分支后）插入：
|
||||
|
||||
```markdown
|
||||
- **补丁/N-day 对比（修复前后/变体关联）** → [[re-variant]]（函数匹配/补丁 diff）
|
||||
```
|
||||
|
||||
`.claude/skills/re-forensics/SKILL.md` 子技能列表（description 行，末尾 `[[re-attribution]]`）追加 `、[[re-hunting]]、[[re-mobile-forensics]]`
|
||||
|
||||
`.claude/skills/re-ctf/SKILL.md` 子技能列表（description 行，末尾 `[[re-pwn]]`）追加 `、[[re-stego]]`
|
||||
|
||||
`.claude/skills/re-managed/SKILL.md` 子技能列表（description 行，末尾 `[[re-blockchain]]`）追加 `、[[re-browser-ext]]`；选择树（「**EVM 合约字节码**…」分支后）插入：
|
||||
|
||||
```markdown
|
||||
- **浏览器扩展（crx/xpi/zip 扩展文件）** → [[re-browser-ext]]（权限审计/恶意行为/混淆还原）
|
||||
```
|
||||
|
||||
- [ ] **Step 2: rerouting A 表加 3 行**
|
||||
|
||||
`.claude/skills/re-analyze/references/rerouting.md` A 表末尾（RTTI 行之后）追加：
|
||||
|
||||
```markdown
|
||||
| PDF/Office 宏/钓鱼文档特征 | [[re-doc-malware]] |
|
||||
| 补丁/N-day 对比需求（修复前后/变体） | [[re-variant]] |
|
||||
| 文件尾附加/图片异常（隐写怀疑） | [[re-stego]] |
|
||||
```
|
||||
|
||||
- [ ] **Step 3: 计数同步（3 文件）**
|
||||
|
||||
`README.md`：
|
||||
- `## 技能导航（101）` → `## 技能导航（107）`
|
||||
- `入口 → 12 大类网关 → 88 原子技能` → `入口 → 12 大类网关 → 94 原子技能`
|
||||
- 第 5 行 `101 个逆向工程技能` → `107 个逆向工程技能`
|
||||
- 导航行：re-malware 行加 `、re-doc-malware`；re-binary-core 行加 `、re-variant`；re-forensics 行加 `、re-hunting、re-mobile-forensics`；re-ctf 行加 `、re-stego`；re-managed 行加 `、re-browser-ext`
|
||||
|
||||
`AGENTS.md`：
|
||||
- `（101 个技能）` → `（107 个技能）`
|
||||
- `原子技能（88）` → `原子技能（94）`
|
||||
|
||||
`.claude-plugin/marketplace.json`：
|
||||
- `101 个技能` → `107 个技能`
|
||||
|
||||
- [ ] **Step 4: 校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 107 skills validated`
|
||||
|
||||
Run: `grep -c "re-doc-malware\|re-variant\|re-hunting\|re-mobile-forensics\|re-stego\|re-browser-ext" README.md`
|
||||
Expected: ≥ 5（各技能名在导航行各出现 1 次，grep -c 按行计，5 个网关行各含 1+ 名）
|
||||
|
||||
- [ ] **Step 5: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-malware/SKILL.md .claude/skills/re-binary-core/SKILL.md .claude/skills/re-forensics/SKILL.md .claude/skills/re-ctf/SKILL.md .claude/skills/re-managed/SKILL.md .claude/skills/re-analyze/references/rerouting.md README.md AGENTS.md .claude-plugin/marketplace.json
|
||||
git commit -m "增强: 6 技能挂载与计数同步 107（5 网关/rerouting 3 行/README-AGENTS-marketplace）"
|
||||
```
|
||||
@@ -0,0 +1,835 @@
|
||||
# 6 个单开技能 实现计划
|
||||
|
||||
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
|
||||
|
||||
**Goal:** 新增 6 个原子技能（re-cpp-abi / re-macos / re-attribution / re-hw-chip / re-ai-attack / re-sdr）+ 挂载同步，技能总数 91 → 97。
|
||||
|
||||
**Architecture:** 纯技能文档扩展。6 个新技能目录（SKILL.md，按 docs/skill-template.md 原子技能规范）+ 挂载（re-binary-core / re-forensics 网关、rerouting A 表 RTTI 行、4 处跨域引用）+ 计数同步（README / AGENTS / marketplace）。
|
||||
|
||||
**Tech Stack:** Markdown / YAML frontmatter / validate.mjs（npm test，现有）
|
||||
|
||||
## Global Constraints
|
||||
|
||||
- **红线 1 呈现中性**：禁用「最推荐」「强烈建议」等最高级强推措辞
|
||||
- **红线 2 隐私脱敏**：内容不指向具体项目/公司/产品（归因技能只写方法不写真实案例）
|
||||
- **不绑定具体工具**：方法为核心，工具为可替换示例；「工具准备」按模板给跨 OS 安装命令（硬件类技能给选购指引）
|
||||
- validate.mjs：frontmatter `name`=目录名、`description` 非空、`type: atomic` 必含「## 工具准备」、`[[链接]]` 必须解析
|
||||
- 工作区有 4 个未提交修改（re-binary-core / re-mobile / re-protocol 的 SKILL.md、README.md）——各任务 commit 只 add 本任务列出的文件
|
||||
- **re-binary-core/SKILL.md 有用户未提交改动**：Task 7 对该文件只做工作区修改、**不 git add 提交该文件**（挂载行与用户改动共存于工作区，由用户一并提交）
|
||||
- 新技能创建后 `npm test` 预期输出按任务标注（92 → 97 递增）
|
||||
|
||||
---
|
||||
|
||||
### Task 1: 创建 re-cpp-abi 技能
|
||||
|
||||
**Files:**
|
||||
- Create: `.claude/skills/re-cpp-abi/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无（新目录）
|
||||
- Produces: 技能目录 `re-cpp-abi`（供 Task 7 的 [[re-cpp-abi]] 链接解析；计数 91 → 92）
|
||||
|
||||
- [ ] **Step 1: 创建目录与 SKILL.md**
|
||||
|
||||
```bash
|
||||
mkdir -p .claude/skills/re-cpp-abi
|
||||
```
|
||||
|
||||
写入 `.claude/skills/re-cpp-abi/SKILL.md`：
|
||||
|
||||
````markdown
|
||||
---
|
||||
name: re-cpp-abi
|
||||
type: atomic
|
||||
description: >
|
||||
现代 C++ 二进制逆向：RTTI/异常/虚表恢复、ABI 识别、mangling 解码。
|
||||
触发词：C++逆向、RTTI、虚表恢复、异常处理、C++ ABI、mangling、C++反编译。
|
||||
---
|
||||
|
||||
# 现代 C++ 逆向（RTTI / 异常 / 虚表）
|
||||
|
||||
## 何时使用 / 何时不用
|
||||
|
||||
- 用：RTTI/异常表密集的二进制、反编译结果混乱的 C++ 目标（类层次/虚调用/异常流无法直接读出）
|
||||
- 不用：C 代码或纯汇编（走 [[re-binary-core]] 通用路径）；混淆主导的目标（先 [[re-deobfuscate]]）
|
||||
|
||||
## 工具准备
|
||||
|
||||
### readelf / llvm-objdump（节表与异常表）
|
||||
|
||||
- Linux: `apt install binutils llvm` / `dnf install binutils llvm` / `pacman -S binutils llvm`
|
||||
- macOS: `brew install llvm`（binutils 部分 macOS 自带）
|
||||
- Windows: WSL 或 llvm 预编译
|
||||
- 验证: `readelf --version`、`llvm-objdump --version`
|
||||
|
||||
### c++filt / undname（mangling 解码）
|
||||
|
||||
- Linux/macOS: `c++filt`（binutils 自带）；Windows: `undname`（VS 工具链）
|
||||
- 验证: `echo '_ZN3foo3barEv' | c++filt`（输出 `foo::bar()`）
|
||||
|
||||
### Ghidra / IDA（反编译底座，脚本化 RTTI 遍历）
|
||||
|
||||
- 安装与验证见 [[re-ghidra]] / [[re-ida]] 工具准备
|
||||
|
||||
### gdb（异常断点，可选）
|
||||
|
||||
- 安装与验证见 [[re-gdb]]
|
||||
|
||||
## 操作步骤
|
||||
|
||||
按顺序执行，每步产物存档（路径 + sha256，见 [[re-triage]]）。
|
||||
|
||||
1. **ABI 识别**：
|
||||
```sh
|
||||
readelf -s sample | grep -E '_ZN|_ZTV|_ZTI' | head # Itanium（GCC/Clang）
|
||||
strings sample | grep -E '^\?\?_' | head # MSVC
|
||||
```
|
||||
- Itanium 特征：`_ZN`（函数）、`_ZTV`（虚表）、`_ZTI`（RTTI 类型信息）
|
||||
- MSVC 特征：`??_7`（vftable）、`??_R`（RTTI）
|
||||
- 识别错则后续全部偏——先确认再继续
|
||||
|
||||
2. **RTTI 重建（Itanium）**：
|
||||
```sh
|
||||
readelf -s sample | grep _ZTI | head
|
||||
# _ZTI<类名> 指向 typeinfo；typeinfo+8 处 _ZTVN10__cxxabiv1... 链到 vtable 前缀
|
||||
```
|
||||
- 结构：`typeinfo` → `__class_type_info` 派生链 → 每个类的完整继承路径
|
||||
- 脚本化：Ghidra/IDA 遍历 _ZTI 引用，重建类继承图（父子关系表）
|
||||
- 产出：类名 → 继承链映射（写入会话 symbols_known，见 [[analysis-contract]]）
|
||||
|
||||
3. **虚表恢复**：
|
||||
```sh
|
||||
readelf -s sample | grep _ZTV | head
|
||||
```
|
||||
- `_ZTV<类名>` 指向 vtable 起点（虚函数指针数组）；`offset to top` + `typeinfo ptr` 位于 vtable 前 8 字节（Itanium ABI）
|
||||
- 定位 vtable 后：每个槽位的函数地址 → 调用点反推虚方法名（结合步骤 2 的继承图）
|
||||
- 虚调用（`call *reg`）无法静态定名 → 用调用点上下文（参数/返回值使用）缩小候选
|
||||
|
||||
4. **异常处理表**：
|
||||
```sh
|
||||
readelf -S sample | grep -E 'pdata|xdata' # PE：.pdata/.xdata
|
||||
readelf -S sample | grep -E 'eh_frame|gcc_except' # ELF：.eh_frame
|
||||
```
|
||||
- PE：`.pdata` 的 RUNTIME_FUNCTION（Begin/End/UnwindInfo）→ `.xdata` 展开数据 → 异常处理器（__CxxFrameHandler3）
|
||||
- ELF：`.eh_frame` 的 FDE/CIE → 展开规则与 LSDA（.gcc_except_table）→ 异常处理函数
|
||||
- 用途：恢复被异常路径打断的控制流、定位析构/清理逻辑（catch 块）
|
||||
|
||||
5. **模板/lambda 识别**：
|
||||
- 模板：符号含 `<...>` 参数（Itanium mangling 中展开为长串）；实例化爆炸时按调用模式聚类
|
||||
- lambda：Itanium 中 `_ZZ<作用域>ENK...` 特征、MSVC 中 `<lambda_...>`；lambda 局部类**无 RTTI**（步骤 2 缺失时反推）
|
||||
- 输出：疑似模板实例化/lambda 的函数清单 + 调用点
|
||||
|
||||
6. **mangling 解码（批量）**：
|
||||
```sh
|
||||
readelf -s sample | grep -E '_ZN|_ZTV|_ZTI' | awk '{print $8}' | c++filt | head -20
|
||||
```
|
||||
- MSVC: `undname` 或在线等价工具
|
||||
- 解码结果写入符号表（供 [[re-ghidra]] / [[re-ida]] 重命名）
|
||||
|
||||
## 跨域联合
|
||||
|
||||
- [[re-binary-core]] 网关：本技能归属（选择树「现代 C++」分支待加）
|
||||
- [[re-ghidra]] / [[re-ida]]：反编译底座与脚本化
|
||||
- [[re-deobfuscate]]：混淆与 ABI 分析衔接
|
||||
- [[analysis-contract]]：类继承图/符号表按数据契约传递
|
||||
- [[rerouting]]：RTTI/异常表特征触发本技能（A 表已挂）
|
||||
|
||||
## 常见坑与陷阱
|
||||
|
||||
- **ABI 误判导致全部解析失败**：现象——用 Itanium 结构解析 MSVC 目标（或反之）全盘错位；原因——识别步骤跳过；对策——先做步骤 1，mangling 特征双查
|
||||
- **模板展开导致符号爆炸**：现象——readelf 输出几万行 `_Z...`；原因——模板实例化；对策——按调用模式聚类、过滤标准库符号（libstdc++/STL 前缀）
|
||||
- **lambda 无 RTTI**：现象——类继承图缺节点；原因——lambda 局部类不生成 typeinfo；对策——按 `_ZZ` mangling 特征与调用点识别，不硬找 RTTI
|
||||
- **异常表版本差异**：现象——.xdata 解析错位；原因——MSVC 异常处理版本（__CxxFrameHandler3 等）不同；对策——按导入函数（__CxxFrameHandler）确认版本再解析
|
||||
- **虚调用无法静态定名**：现象——`call *reg` 全是间接调用；原因——虚分派；对策——结合 vtable 槽位与调用点证据缩小候选，不猜
|
||||
````
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 92 skills validated`（re-cpp-abi 计入；[[链接]] 全部指向已存在技能：re-binary-core/re-deobfuscate/re-ghidra/re-ida/analysis-contract/rerouting/re-triage/re-gdb 均存在）
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-cpp-abi/SKILL.md
|
||||
git commit -m "feat: re-cpp-abi 技能——RTTI/异常/虚表恢复与 ABI 识别"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 2: 创建 re-macos 技能
|
||||
|
||||
**Files:**
|
||||
- Create: `.claude/skills/re-macos/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无（新目录）
|
||||
- Produces: 技能目录 `re-macos`（供 Task 7 的 [[re-macos]] 链接解析；计数 92 → 93）
|
||||
|
||||
- [ ] **Step 1: 创建目录与 SKILL.md**
|
||||
|
||||
```bash
|
||||
mkdir -p .claude/skills/re-macos
|
||||
```
|
||||
|
||||
写入 `.claude/skills/re-macos/SKILL.md`：
|
||||
|
||||
````markdown
|
||||
---
|
||||
name: re-macos
|
||||
type: atomic
|
||||
description: >
|
||||
macOS 原生应用逆向：App Bundle/签名公证、entitlements、沙箱与 TCC、钥匙串与 Secure Enclave。
|
||||
触发词：macOS逆向、mac app、entitlements、Secure Enclave、钥匙串、TCC、codesign、公证。
|
||||
---
|
||||
|
||||
# macOS 应用逆向
|
||||
|
||||
## 何时使用 / 何时不用
|
||||
|
||||
- 用：macOS 原生/闭源应用（.app/.dylib/.framework）、带签名公证与沙箱的目标、钥匙串/Secure Enclave 硬件密钥场景
|
||||
- 不用：iOS 应用（转 [[re-ios]]）；纯 Mach-O 格式解析（转 [[re-format-macho]]）
|
||||
|
||||
## 工具准备
|
||||
|
||||
### codesign / spctl / otool / lipo（签名与 Mach-O 工具，macOS 内置）
|
||||
|
||||
- macOS: 系统自带（Xcode 命令行工具 `xcode-select --install`）
|
||||
- Linux: 可静态分析 Mach-O（`llvm-otool`，`brew install llvm` 或发行版 llvm 包）
|
||||
- 验证: `codesign --version`、`otool --version`
|
||||
|
||||
### Hopper / IDA / Ghidra（反编译底座）
|
||||
|
||||
- 安装与验证见 [[re-ida]] / [[re-ghidra]]
|
||||
|
||||
### lldb（动态调试）
|
||||
|
||||
- 安装与验证见 [[re-lldb]]
|
||||
|
||||
## 操作步骤
|
||||
|
||||
按顺序执行，每步产物存档（路径 + sha256，见 [[re-triage]]）。
|
||||
|
||||
1. **包结构与签名检查**：
|
||||
```sh
|
||||
file Sample.app/Contents/MacOS/Sample
|
||||
codesign -dv Sample.app 2>&1 | head # 签名者/Team ID/要求
|
||||
spctl -a -vv Sample.app 2>&1 # 公证状态（Gatekeeper）
|
||||
defaults read Sample.app/Contents/Info.plist # Info.plist 关键键
|
||||
```
|
||||
- 关注：签名者（Apple 开发者/分发证书）、Team ID、Hardened Runtime（runtime 标志）、Info.plist 的 CFBundleIdentifier/版本
|
||||
|
||||
2. **entitlements 与沙箱**：
|
||||
```sh
|
||||
codesign -d --entitlements :- Sample.app 2>&1 | head -30
|
||||
```
|
||||
- 关键键：`com.apple.security.app-sandbox`（沙箱开启）、`com.apple.security.network.client/server`、`com.apple.security.files.user-selected.*`、`com.apple.security.device.*`（摄像头/麦克风）
|
||||
- 沙箱 profile 决定能力边界——分析授权逻辑时先看 entitlements 清单
|
||||
|
||||
3. **TCC 权限库**：
|
||||
```sh
|
||||
# 用户级 TCC 库（授权记录）
|
||||
ls ~/Library/Application\ Support/com.apple.TCC/
|
||||
```
|
||||
- TCC.db（SQLite）记录各 App 对隐私资源的授权；分析目标对 TCC 的依赖（它请求了什么权限、何时请求）
|
||||
- 注意：TCC 数据属系统隐私数据，只读分析不导出内容（红线 2）
|
||||
|
||||
4. **钥匙串与 Secure Enclave**：
|
||||
- 钥匙串条目类型（通用密码/互联网密码/密钥）与 ACL（`kSecAttrAccess` 可访问性类：非锁定/首次解锁/此设备）
|
||||
- Secure Enclave 密钥：`SecKeyCreateWithData` 带 `kSecAttrTokenIDSecureEnclave` —— 私钥**不可提取**（等价 Android Keystore 硬件背书，见 [[re-android-native]] Keystore 审计）
|
||||
（注：本行 API 用法已于 2026-09-13 修正——SE 密钥须用 `SecKeyCreateRandomKey`，`SecKeyCreateWithData` 是外部数据导入；现文见 `.claude/skills/re-macos/SKILL.md`，核验记录见 `docs/audit/`）
|
||||
- 分析：目标读哪些钥匙串条目（SecItemCopyMatching 调用点）、密钥是否 Secure Enclave 绑定（不可提取 → 记录用途而非字节）
|
||||
|
||||
5. **dyld 加载链**：
|
||||
```sh
|
||||
otool -L Sample.app/Contents/MacOS/Sample | head # LC_LOAD_DYLIB 依赖
|
||||
otool -l Sample.app/Contents/MacOS/Sample | grep -A4 LC_RPATH
|
||||
```
|
||||
- 依赖清单与 RPATH → Dylib Hijacking 面（可写目录 + 缺失依赖）
|
||||
- 注入面：DYLD_INSERT_LIBRARIES（受 hardened runtime 限制——有 `com.apple.security.cs.allow-dyld-environment-variables` 才可注入）
|
||||
|
||||
6. **反调试与保护**：
|
||||
- taskgated/签名校验：改签名或注入触发校验失败的典型点
|
||||
- 对抗面分析：代码签名校验（`SecStaticCodeCheckValidity`）、调试器检测（`PT_DENY_ATTACH`）、反注入（`DYLD_INSERT_LIBRARIES` 检查）
|
||||
- 动态侧：[[re-lldb]] attach 前先处理 PT_DENY_ATTACH（ptrace 调用点 patch）
|
||||
|
||||
## 跨域联合
|
||||
|
||||
- [[re-format-macho]]：Mach-O 格式底座（LC_* 解析）
|
||||
- [[re-ios]]：iOS 侧互补（越狱生态与 entitlements 差异）
|
||||
- [[re-lldb]]：动态调试
|
||||
- [[re-frida]]：动态插桩（macOS 桌面支持）
|
||||
- [[analysis-contract]]：签名/entitlements 信息按数据契约传递
|
||||
|
||||
## 常见坑与陷阱
|
||||
|
||||
- **签名校验多处触发**：现象——patch 后运行即退；原因——加载/运行/更新多处校验；对策——逐点定位（步骤 6），先处理校验点再过逻辑
|
||||
- **Secure Enclave 密钥不可提取**：现象——内存搜不到私钥；原因——硬件背书；对策——记录用途与 ACL，不找字节（见步骤 4）
|
||||
- **TCC 权限导致功能缺失**：现象——目标功能灰掉；原因——TCC 未授权；对策——分析其请求逻辑而非绕过系统权限（红线）
|
||||
- **公证检查离线不可复现**：现象——离线环境 spctl 结果异常；原因——公证需要网络查询；对策——用 codesign 的本地签名信息替代
|
||||
- **hardened runtime 限制注入**：现象——DYLD_INSERT_LIBRARIES 无效；原因——runtime 标志未含 allow-dyld 环境变量；对策——静态分析路径（[[re-ghidra]]），不硬注入
|
||||
````
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 93 skills validated`（[[链接]]：re-ios/re-format-macho/re-lldb/re-frida/re-android-native/analysis-contract/re-triage/re-ida/re-ghidra 均存在）
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-macos/SKILL.md
|
||||
git commit -m "feat: re-macos 技能——签名公证/entitlements/钥匙串与 Secure Enclave"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 3: 创建 re-attribution 技能
|
||||
|
||||
**Files:**
|
||||
- Create: `.claude/skills/re-attribution/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无（新目录）
|
||||
- Produces: 技能目录 `re-attribution`（供 Task 7 的 [[re-attribution]] 链接解析；计数 93 → 94）
|
||||
|
||||
- [ ] **Step 1: 创建目录与 SKILL.md**
|
||||
|
||||
```bash
|
||||
mkdir -p .claude/skills/re-attribution
|
||||
```
|
||||
|
||||
写入 `.claude/skills/re-attribution/SKILL.md`：
|
||||
|
||||
````markdown
|
||||
---
|
||||
name: re-attribution
|
||||
type: atomic
|
||||
description: >
|
||||
威胁归因方法论：钻石模型、基础设施图谱、置信度分级与归因报告。
|
||||
触发词：归因、APT、attribution、攻击者身份、基础设施图谱、钻石模型、威胁组织。
|
||||
---
|
||||
|
||||
# 威胁归因（APT Attribution）
|
||||
|
||||
## 何时使用 / 何时不用
|
||||
|
||||
- 用：情报归因请求（「谁干的」）、基础设施关联分析、样本/能力到攻击者的推理
|
||||
- 不用：单个 IOC 查询（转 [[re-ti]]）；恶意行为判定（转 [[re-behavior]]）
|
||||
|
||||
## 工具准备
|
||||
|
||||
### 关联查询工具（Passive DNS / 证书透明 / Whois）
|
||||
|
||||
- 多平台: 命令行客户端 + 在线服务（查询类工具，给 API 使用指引）
|
||||
- 验证: 任一查询工具可返回结果
|
||||
|
||||
### MISP（情报关联与共享）
|
||||
|
||||
- Linux: `apt install misp` 或 Docker 部署；验证: 实例可访问
|
||||
- 轻量替代: 本地 CSV/图文件 + 脚本分析
|
||||
|
||||
### 图分析（基础设施关系）
|
||||
|
||||
- 多平台: `pip install networkx`（python 图分析）；验证: `python3 -c "import networkx"`
|
||||
|
||||
## 操作步骤
|
||||
|
||||
按顺序执行；全部内容脱敏处理（红线 2：不指向具体组织/受害者身份）。
|
||||
|
||||
1. **钻石模型定位**：
|
||||
- 四角：受害者（已明确）/ 基础设施（C2 域名/IP/证书）/ 能力（工具/样本/漏洞利用）/ 对手（待推断）
|
||||
- 产出：四角已知信息表 + 缺失角（归因目标）
|
||||
- 规则：只有两角以上才能开始推理；单角（仅样本）不支撑归因声明
|
||||
|
||||
2. **基础设施图谱**：
|
||||
```sh
|
||||
# 域名/IP/证书关联聚类（示例流程，工具可替换）
|
||||
# 1) 收集 C2 域名/IP → Whois 注册信息
|
||||
# 2) 证书透明日志查共用证书 → 关联其他域名
|
||||
# 3) 图分析（networkx）聚类：共享注册者/证书/NS 的节点合并
|
||||
```
|
||||
- 聚类特征：同一注册者/注册邮箱、共用证书、共用 DNS 基础设施、IP 段归属
|
||||
- 跳板/托管商共存不能作为归属证据（见坑 1）
|
||||
|
||||
3. **能力与样本归因**：
|
||||
- 代码复用（样本间相似度：字符串/函数/资源）、TTP 对比（行为模式与已知活动对齐）、时间线（活动窗口对齐）
|
||||
- 唯一性特征优先：独特字符串/编译特征/语言习惯（比通用 TTP 更有区分度）
|
||||
- 产出：能力证据表（每条证据 → 支持/反对假设）
|
||||
|
||||
4. **置信度分级**：
|
||||
- 低：单类证据（仅基础设施或仅能力）
|
||||
- 中：两类独立证据交叉（如基础设施 + 能力）
|
||||
- 高：三类以上 + 时间线一致 + 无矛盾证据
|
||||
- 规则：无高置信度证据时声明「关联活动」而非「归属组织」；明确列出未解决的反证
|
||||
|
||||
5. **报告**：
|
||||
- 结构：结论（分级声明）→ 证据链（每角证据 + 来源）→ 置信度依据 → 反证与未决项 → 方法边界（哪些无法判定）
|
||||
- 脱敏：不公开受害者身份/真实组织名（用代号），不发表过度归因声明
|
||||
|
||||
## 跨域联合
|
||||
|
||||
- [[re-ti]]：情报输入（IOC 查询与背景）
|
||||
- [[re-ioc]]：指标提取（域名/IP/哈希）
|
||||
- [[re-behavior]]：行为证据（TTP 对齐）
|
||||
- [[re-protocol]]：C2 协议分析（基础设施特征）
|
||||
- [[re-feedback]]：归因案例经验沉淀（脱敏后）
|
||||
|
||||
## 常见坑与陷阱
|
||||
|
||||
- **基础设施重叠导致误归因**：现象——两活动共享 C2 基础设施被并为一组；原因——共用托管/被劫持基础设施；对策——区分「共享」与「控制」证据（注册信息 vs 仅托管）
|
||||
- **跳板机 ≠ 归属**：现象——经第三方跳板的活动归到跳板所有者；原因——混淆路径；对策——只把「控制面证据」（注册/配置/唯一特征）算入归属
|
||||
- **置信度虚高**：现象——单一独特性状（罕见字符串）即高置信度；原因——单证据强但无交叉验证；对策——按步骤 4 分级，单类证据最高「中」
|
||||
- **脱敏红线**：现象——报告中出现真实受害者/组织身份；原因——复制原始情报未处理；对策——报告前逐项检查（红线 2 强制）
|
||||
- **时间线证据不足**：现象——活动窗口无法对齐；原因——被动数据缺失；对策——标注时间线缺口，不强行对齐
|
||||
````
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 94 skills validated`（[[链接]]：re-ti/re-ioc/re-behavior/re-protocol/re-feedback 均存在）
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-attribution/SKILL.md
|
||||
git commit -m "feat: re-attribution 技能——钻石模型/基础设施图谱/置信度分级"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 4: 创建 re-hw-chip 技能
|
||||
|
||||
**Files:**
|
||||
- Create: `.claude/skills/re-hw-chip/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无（新目录）
|
||||
- Produces: 技能目录 `re-hw-chip`（供 Task 7 的 [[re-hw-chip]] 链接解析；计数 94 → 95）
|
||||
|
||||
- [ ] **Step 1: 创建目录与 SKILL.md**
|
||||
|
||||
```bash
|
||||
mkdir -p .claude/skills/re-hw-chip
|
||||
```
|
||||
|
||||
写入 `.claude/skills/re-hw-chip/SKILL.md`：
|
||||
|
||||
````markdown
|
||||
---
|
||||
name: re-hw-chip
|
||||
type: atomic
|
||||
description: >
|
||||
物理层硬件逆向：去封装、裸片分析、探针与 FIB、PCB 电路分析、硬件木马检测。
|
||||
触发词：芯片逆向、去封装、decapping、PCB、硬件木马、电路分析、裸片、FIB。
|
||||
---
|
||||
|
||||
# 芯片/PCB 硬件逆向
|
||||
|
||||
## 何时使用 / 何时不用
|
||||
|
||||
- 用：物理芯片/板级分析（固件提取失败后的物理层）、芯片解密、硬件木马检测
|
||||
- 不用：固件级分析（转 [[re-fw-extract]]）；接口提取（转 [[re-hardware-io]]）；无线信号（转 [[re-sdr]]）
|
||||
|
||||
## 工具准备
|
||||
|
||||
### 显微镜/探针台（观察与接触）
|
||||
|
||||
- 选购指引：体视显微镜（初检）→ 金相显微镜（裸片）；探针台按预算分级
|
||||
- 验证: 无软件验证——以成像清晰度验收
|
||||
|
||||
### decapping 设备与耗材（去封装）
|
||||
|
||||
- 化学 decap：发烟硝酸/硫酸 + 加热台（防护：通风橱/护目镜）；激光 decap：专用激光器（高成本，外包可选）
|
||||
- 验证: 无软件验证——以裸露程度验收
|
||||
|
||||
### 逻辑分析仪（信号提取）
|
||||
|
||||
- 多平台: Saleae 类（配套软件各平台可用）或开源方案（sigrok/PulseView：`pip install sigrok` 或发行版包）
|
||||
- 验证: `pulseview --version`
|
||||
|
||||
### 热成像（功耗/时序异常，可选）
|
||||
|
||||
- 选购指引：按分辨率与测温范围选型；验证: 成像验收
|
||||
|
||||
## 操作步骤
|
||||
|
||||
按顺序执行；全程注意防护与破坏性风险（步骤 1 不可逆）。
|
||||
|
||||
1. **去封装（decapping）**：
|
||||
- 化学法：加热台预加热 → 滴加发烟硝酸溶解环氧 → 清洗（丙酮）→ 显微镜检查
|
||||
- 激光法：激光逐层烧蚀（精度高，成本高）
|
||||
- 风险控制：通风橱、防酸手套/护目镜、废弃液处理；先练习废片
|
||||
- 验收：金属层可见、无过度腐蚀（伤及晶圆）
|
||||
|
||||
2. **裸片分析**：
|
||||
- 显微成像（金相显微镜/电子显微镜）→ 金属层走线观察
|
||||
- ROM/熔丝提取：成像 → 位图还原（金属层/多晶硅层图案 → 二进制）
|
||||
- 产出：ROM 位图 → 数据（与 [[re-fw-extract]] 固件对照）
|
||||
|
||||
3. **探针与信号提取**：
|
||||
- 探针台接触测试点（总线/时钟/数据线）
|
||||
- FIB（聚焦离子束）：修改互连/暴露内部节点（高成本，外包）
|
||||
- 信号嗅探：逻辑分析仪挂总线（时序对照数据手册）
|
||||
- 注意：探针负载可能改变信号（见坑 2）
|
||||
|
||||
4. **PCB 电路分析**：
|
||||
- 走线还原（万用表导通/成像 → 网络表）
|
||||
- IC 标识识别（丝印 → 型号 → 数据手册 → 引脚功能）
|
||||
- JTAG/SWD 引脚定位（测试点/走线特征 → 调试接口枚举）
|
||||
|
||||
5. **硬件木马检测**：
|
||||
- 冗余逻辑特征（无功能路径的触发器/计数器）
|
||||
- 功耗/时序异常（热成像 + 电流曲线对照基线）
|
||||
- 触发条件分析（特定输入组合/温度/时间条件）
|
||||
|
||||
## 跨域联合
|
||||
|
||||
- [[re-hardware-io]]：接口提取衔接（JTAG/UART 是软件侧入口）
|
||||
- [[re-fw-extract]]：固件侧对照（ROM 提取物与固件 dump 比对）
|
||||
- [[re-sdr]]：无线侧（RF 接口）
|
||||
- [[re-triage]]：提取物初勘
|
||||
|
||||
## 常见坑与陷阱
|
||||
|
||||
- **decap 不可逆**：现象——封装破坏后无法恢复；原因——物理破坏；对策——先存档固件（[[re-fw-extract]]）再做物理操作
|
||||
- **探针负载改变信号**：现象——挂探针后时序异常；原因——容性负载；对策——高阻探针、记录挂载前后基线
|
||||
- **FIB 高成本易毁**：现象——FIB 修改失败晶圆报废；原因——离子束损伤；对策——先成像规划、外包给专业服务
|
||||
- **木马误报**：现象——正常冗余逻辑被当木马；原因——厂商设计含测试/修复逻辑；对策——对照数据手册与已知电路模式，低置信度不发布
|
||||
- **安全防护缺失**：现象——化学 decap 事故；原因——未用通风橱/防护；对策——步骤 1 风险控制强制前置
|
||||
````
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 95 skills validated`（[[链接]]：re-fw-extract/re-hardware-io/re-sdr/re-triage 均存在）
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-hw-chip/SKILL.md
|
||||
git commit -m "feat: re-hw-chip 技能——去封装/裸片/探针/PCB/硬件木马"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 5: 创建 re-ai-attack 技能
|
||||
|
||||
**Files:**
|
||||
- Create: `.claude/skills/re-ai-attack/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无（新目录）
|
||||
- Produces: 技能目录 `re-ai-attack`（供 Task 7 的 [[re-ai-attack]] 链接解析；计数 95 → 96）
|
||||
|
||||
- [ ] **Step 1: 创建目录与 SKILL.md**
|
||||
|
||||
```bash
|
||||
mkdir -p .claude/skills/re-ai-attack
|
||||
```
|
||||
|
||||
写入 `.claude/skills/re-ai-attack/SKILL.md`：
|
||||
|
||||
````markdown
|
||||
---
|
||||
name: re-ai-attack
|
||||
type: atomic
|
||||
description: >
|
||||
AI 模型攻击与取证：模型提取攻击、指纹/水印检测、成员推断、对抗样本基础。
|
||||
触发词：模型提取、模型窃取、水印检测、模型指纹、成员推断、对抗样本、模型攻击。
|
||||
---
|
||||
|
||||
# AI 模型攻击与取证
|
||||
|
||||
## 何时使用 / 何时不用
|
||||
|
||||
- 用：模型泄露/窃取取证、API 模型攻击评估（提取/指纹）、训练数据泄露判定
|
||||
- 不用：模型文件格式解析与权重提取（转 [[re-ai-model]]）；模型训练/微调（非逆向）
|
||||
|
||||
## 工具准备
|
||||
|
||||
### python3（核心运行时）
|
||||
|
||||
- 各平台安装见 [[re-python]] 工具准备
|
||||
|
||||
### 模型库（torch / tensorflow，按目标格式选）
|
||||
|
||||
- 多平台: `pip install torch` / `pip install tensorflow`（按硬件可选 CPU 版）
|
||||
- 验证: `python3 -c "import torch"`
|
||||
|
||||
### 查询接口客户端（API 目标）
|
||||
|
||||
- 多平台: `pip install requests`；验证: `python3 -c "import requests"`
|
||||
|
||||
## 操作步骤
|
||||
|
||||
按顺序执行；仅限授权评估场景（红线：不针对未授权目标）。
|
||||
|
||||
1. **模型提取攻击**：
|
||||
- 目标：通过 API 查询重建近似模型（蒸馏）
|
||||
- 步骤：
|
||||
1. 确认接口能力（返回 logits/概率 或仅标签？置信度可得性决定策略）
|
||||
2. 查询采样（输入分布覆盖：代表性输入 + 边界扰动）
|
||||
3. 蒸馏训练（以 API 输出为教师标签，学生模型拟合）
|
||||
4. 评估近似度（同输入集输出对比）
|
||||
- 仅标签时：降级为决策边界采样（输出分布重建受限——标注此局限）
|
||||
|
||||
2. **模型指纹/水印检测**：
|
||||
- 嵌入检测：输入扰动（特定噪声/触发器）→ 输出特征比对（水印触发行为）
|
||||
- 指纹提取：模型行为签名（代表性输入集输出向量）→ 与疑似副本比对
|
||||
- 窃取取证：嫌疑模型与受害者模型的指纹距离（阈值判定相似）
|
||||
- 产出：指纹向量 + 距离报告（置信度）
|
||||
|
||||
3. **成员推断**：
|
||||
- 目标：判定某样本是否在训练集中
|
||||
- 方法：过拟合特征（样本损失/置信度分布对比基线）、影子模型
|
||||
- 局限：只能给出统计判定（误报控制：阈值校准）
|
||||
|
||||
4. **对抗样本基础**：
|
||||
- 白盒：梯度扰动（FGSM/PGD 类方法）
|
||||
- 黑盒：查询/迁移扰动
|
||||
- 用途：鲁棒性评估与防御验证（非攻击部署）
|
||||
|
||||
## 跨域联合
|
||||
|
||||
- [[re-ai-model]]：格式/权重侧（提取物分析衔接）
|
||||
- [[re-python]]：Python 工具链基础
|
||||
- [[re-feedback]]：攻击案例经验沉淀（脱敏后）
|
||||
|
||||
## 常见坑与陷阱
|
||||
|
||||
- **查询预算限制**：现象——API 限流/计费中断；原因——高查询量；对策——预算内采样设计（先小批估计）
|
||||
- **置信度不可得时降级**：现象——接口只返回标签；原因——服务端裁剪输出；对策——决策边界采样 + 标注局限，不硬造概率
|
||||
- **水印被抹除**：现象——指纹比对失败；原因——嫌疑方做了剪枝/微调；对策——用鲁棒指纹（多触发器）并标注「可能被抹除」
|
||||
- **成员推断误报**：现象——统计判定错误；原因——阈值偏差；对策——影子模型校准 + 报告置信区间
|
||||
- **授权边界**：现象——对未授权 API 发起攻击测试；原因——范围未确认；对策——先确认授权（使用边界红线）
|
||||
````
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 96 skills validated`（[[链接]]：re-ai-model/re-python/re-feedback 均存在）
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-ai-attack/SKILL.md
|
||||
git commit -m "feat: re-ai-attack 技能——模型提取/指纹水印/成员推断"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 6: 创建 re-sdr 技能
|
||||
|
||||
**Files:**
|
||||
- Create: `.claude/skills/re-sdr/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 无（新目录）
|
||||
- Produces: 技能目录 `re-sdr`（供 Task 7 的 [[re-sdr]] 链接解析；计数 96 → 97）
|
||||
|
||||
- [ ] **Step 1: 创建目录与 SKILL.md**
|
||||
|
||||
```bash
|
||||
mkdir -p .claude/skills/re-sdr
|
||||
```
|
||||
|
||||
写入 `.claude/skills/re-sdr/SKILL.md`：
|
||||
|
||||
````markdown
|
||||
---
|
||||
name: re-sdr
|
||||
type: atomic
|
||||
description: >
|
||||
射频逆向：信号采集、频谱分析、解调、帧同步与协议恢复、重放。
|
||||
触发词：SDR、射频、信号分析、解调、RTL-SDR、HackRF、无线协议、遥测。
|
||||
---
|
||||
|
||||
# 射频信号逆向（SDR）
|
||||
|
||||
## 何时使用 / 何时不用
|
||||
|
||||
- 用：无线协议/遥控/遥测信号（IoT 无线、遥控器、遥测链路）、信号级协议恢复
|
||||
- 不用：有线协议（转 [[re-protocol]]）；无线 IoT 协议已封装分析（转 [[re-iot-proto]]）
|
||||
|
||||
## 工具准备
|
||||
|
||||
### RTL-SDR / HackRF（接收硬件）
|
||||
|
||||
- 选购指引：RTL-SDR（接收，低成本入门）/ HackRF（收发，重放需要）
|
||||
- 验证: 硬件插入后 `rtl_test` 或 `hackrf_info` 有输出
|
||||
|
||||
### GNU Radio（信号处理）
|
||||
|
||||
- Linux: `apt install gnuradio` / `pacman -S gnuradio`；macOS: `brew install gnuradio`
|
||||
- Windows: 官方安装包
|
||||
- 验证: `gnuradio-companion --version` 或 `grcc --version`
|
||||
|
||||
### inspectrum（频谱/时序可视化）
|
||||
|
||||
- Linux: `apt install inspectrum` 或源码编译；macOS: `brew install inspectrum`
|
||||
- 验证: `inspectrum --version`
|
||||
|
||||
### Universal Radio Hacker (URH)（解调与帧恢复）
|
||||
|
||||
- 多平台: `pip install urh`
|
||||
- 验证: `urh --version`
|
||||
|
||||
## 操作步骤
|
||||
|
||||
按顺序执行；仅限授权测试（红线：重放/交互需授权）。
|
||||
|
||||
1. **信号采集与频谱分析**：
|
||||
```sh
|
||||
# 示例（工具可替换）：GNU Radio 或命令行采集
|
||||
rtl_sdr -f 433.9M -s 1M capture.iq
|
||||
```
|
||||
- 先全频段扫（找活跃信号）→ 定中心频率与带宽 → 采集 IQ
|
||||
- 调制识别：频谱形状（FSK 双峰/PSK 平坦/AM 载波）
|
||||
|
||||
2. **解调**：
|
||||
- URH：加载 IQ → 自动/手动调制识别 → 解调出位流
|
||||
- GNU Radio：按识别结果搭解调链（AM/FM/PSK/QAM/FSK）
|
||||
- 产出：解调位流（0/1 序列）
|
||||
|
||||
3. **帧同步与协议恢复**：
|
||||
```sh
|
||||
# URH 位流分析：preamble/同步字识别、编码反转（NRZ/Manchester）
|
||||
urh --decode
|
||||
```
|
||||
- 找同步字（重复模式/固定前缀）→ 定帧边界 → 字段划分（地址/长度/载荷/CRC）
|
||||
- 多帧对照（重复发射）→ 不变字段=固定头、变化字段=数据/序号
|
||||
- 产出：帧结构表（字段偏移/长度/语义）
|
||||
|
||||
4. **重放与交互**（授权场景）：
|
||||
- HackRF 回放捕获帧（重放攻击验证——仅授权目标）
|
||||
- 交互式：改字段重发（滚动码/加密需先分析算法——转 [[re-crypto-*]]）
|
||||
|
||||
## 跨域联合
|
||||
|
||||
- [[re-iot-proto]]：无线 IoT 协议衔接（MQTT/CoAP 等封装层）
|
||||
- [[re-protocol]]：帧结构状态机重建衔接
|
||||
- [[re-crypto-id]] / [[re-crypto-decrypt]]：载荷加密分析
|
||||
- [[re-feedback]]：信号案例经验沉淀（脱敏后）
|
||||
|
||||
## 常见坑与陷阱
|
||||
|
||||
- **频率偏移/采样率错误**：现象——解调全乱码；原因——中心频率偏、采样率不匹配；对策——先用已知信号（FM 广播）校准
|
||||
- **调制误判**：现象——FSK 当 PSK 解；原因——频谱特征相似；对策——对照时域波形（inspectrum）再定
|
||||
- **重放需授权**：现象——未授权重放触发设备动作；原因——越界操作；对策——红线：仅授权目标
|
||||
- **编码反转漏看**：现象——位流全反；原因——NRZ/Manchester 未识别；对策——试反相与编码模式组合
|
||||
- **捕获不完整**：现象——帧被截断；原因——带宽不够/触发时机；对策——加宽带宽、延长采集、按同步字触发
|
||||
````
|
||||
|
||||
- [ ] **Step 2: 结构校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 97 skills validated`（[[链接]]：re-iot-proto/re-protocol/re-crypto-id/re-crypto-decrypt/re-feedback 均存在）
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-sdr/SKILL.md
|
||||
git commit -m "feat: re-sdr 技能——信号采集/解调/帧恢复/重放"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 7: 挂载与计数同步
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-analyze/references/rerouting.md`（A 表 RTTI 行）
|
||||
- Modify: `.claude/skills/re-binary-core/SKILL.md`（子技能列表加 re-cpp-abi——**工作区修改，不提交该文件**）
|
||||
- Modify: `.claude/skills/re-forensics/SKILL.md`（子技能列表加 re-attribution）
|
||||
- Modify: `.claude/skills/re-ios/SKILL.md`（跨域联合加 [[re-macos]]）
|
||||
- Modify: `.claude/skills/re-hardware-io/SKILL.md`（跨域联合加 [[re-hw-chip]]）
|
||||
- Modify: `.claude/skills/re-ai-model/SKILL.md`（跨域联合加 [[re-ai-attack]]）
|
||||
- Modify: `.claude/skills/re-iot-proto/SKILL.md`（跨域联合加 [[re-sdr]]）
|
||||
- Modify: `README.md`（计数 91→97、78→84、导航 6 行——**注意：README 有用户未提交改动（安装方式重排），已在上轮随提交纳入；本任务 README 改动会叠加新计数，提交时含全部 README 改动**）
|
||||
- Modify: `AGENTS.md`（91→97、78→84）
|
||||
- Modify: `.claude-plugin/marketplace.json`（91→97）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1-6 的 6 个技能目录（链接可解析）
|
||||
- Produces: 6 技能全库可达；计数 97 = 1 + 12 + 84
|
||||
|
||||
- [ ] **Step 1: rerouting.md RTTI 行更新**
|
||||
|
||||
`.claude/skills/re-analyze/references/rerouting.md` A 表 RTTI 行：
|
||||
|
||||
```
|
||||
| RTTI/异常表（.pdata/.xdata）密集 | （re-cpp-abi 待建，先走 [[re-binary-core]]） |
|
||||
```
|
||||
|
||||
改为：
|
||||
|
||||
```
|
||||
| RTTI/异常表（.pdata/.xdata）密集 | [[re-cpp-abi]] |
|
||||
```
|
||||
|
||||
- [ ] **Step 2: 网关与跨域挂载（6 处编辑）**
|
||||
|
||||
`.claude/skills/re-binary-core/SKILL.md` 子技能列表（含 re-anti-cheat 的那行）末尾追加 `、[[re-cpp-abi]]`（即 `re-anti-cheat、[[re-cpp-abi]]`——**本文件只做工作区修改，不 git add**）。
|
||||
|
||||
`.claude/skills/re-forensics/SKILL.md` 子技能列表末尾追加 `、[[re-attribution]]`。
|
||||
|
||||
`.claude/skills/re-ios/SKILL.md` 跨域联合节末尾追加一行：
|
||||
|
||||
```markdown
|
||||
- 桌面 macOS 生态（签名/entitlements/Secure Enclave）→ [[re-macos]]
|
||||
```
|
||||
|
||||
`.claude/skills/re-hardware-io/SKILL.md` 跨域联合节末尾追加一行：
|
||||
|
||||
```markdown
|
||||
- 物理层芯片/PCB 分析（decap/裸片/木马检测）→ [[re-hw-chip]]
|
||||
```
|
||||
|
||||
`.claude/skills/re-ai-model/SKILL.md` 跨域联合节末尾追加一行：
|
||||
|
||||
```markdown
|
||||
- 模型攻击侧（提取/指纹水印/成员推断）→ [[re-ai-attack]]
|
||||
```
|
||||
|
||||
`.claude/skills/re-iot-proto/SKILL.md` 跨域联合节末尾追加一行：
|
||||
|
||||
```markdown
|
||||
- 射频信号级逆向（采集/解调/帧恢复）→ [[re-sdr]]
|
||||
```
|
||||
|
||||
- [ ] **Step 3: 计数同步（3 文件）**
|
||||
|
||||
`README.md`：
|
||||
- `## 技能导航（91）` → `## 技能导航（97）`
|
||||
- `入口 → 12 大类网关 → 78 原子技能` → `入口 → 12 大类网关 → 84 原子技能`
|
||||
- 第 5 行 `91 个逆向工程技能` → `97 个逆向工程技能`
|
||||
- 导航列表：re-binary-core 行末尾加 `、re-cpp-abi`；re-forensics 行加 `、re-attribution`；新增两行：
|
||||
- `- **re-macos**：macOS 应用逆向（签名/entitlements/Secure Enclave）`
|
||||
- `- **re-hw-chip**：芯片/PCB 物理层（decap/裸片/木马检测）`
|
||||
- `- **re-ai-attack**：模型攻击（提取/指纹/成员推断）`
|
||||
- `- **re-sdr**：射频逆向（采集/解调/帧恢复）`
|
||||
- 说明：README 已含用户安装方式重排改动（上轮随提交纳入），本次计数改动叠加后一并提交
|
||||
|
||||
`AGENTS.md`：
|
||||
- `（91 个技能）` → `（97 个技能）`
|
||||
- `原子技能（78）` → `原子技能（84）`
|
||||
|
||||
`.claude-plugin/marketplace.json`：
|
||||
- `91 个技能` → `97 个技能`
|
||||
|
||||
- [ ] **Step 4: 校验**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: `OK: 97 skills validated`
|
||||
|
||||
Run: `grep -c "re-cpp-abi\|re-macos\|re-attribution\|re-hw-chip\|re-ai-attack\|re-sdr" README.md`
|
||||
Expected: ≥ 6
|
||||
|
||||
- [ ] **Step 5: Commit（re-binary-core 除外）**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-analyze/references/rerouting.md .claude/skills/re-forensics/SKILL.md .claude/skills/re-ios/SKILL.md .claude/skills/re-hardware-io/SKILL.md .claude/skills/re-ai-model/SKILL.md .claude/skills/re-iot-proto/SKILL.md README.md AGENTS.md .claude-plugin/marketplace.json
|
||||
git commit -m "增强: 6 技能挂载与计数同步 97（rerouting RTTI 行/网关与跨域/README-AGENTS-marketplace）"
|
||||
```
|
||||
|
||||
**注意**：`re-binary-core/SKILL.md` 的工作区修改（re-cpp-abi 挂载）**不 git add、不提交**——与用户的未提交改动共存于工作区，由用户后续一并提交。提交后 `git status` 应显示 re-binary-core/SKILL.md 仍为 M。
|
||||
@@ -0,0 +1,258 @@
|
||||
# 技能库第三轮扩充实施计划（2026-08-20）
|
||||
|
||||
## 总览
|
||||
|
||||
- 范围：5 新增 + 6 技能融合（8 章）+ 全库同步项（计数/导航/路由）
|
||||
- 总数：107 → 112
|
||||
- 设计依据：docs/superpowers/specs/2026-08-20-skill-wave-v3-design.md（归位决策已定案，勿改动）
|
||||
- 工作流：每任务 = 实现 → 评审（技术事实核对 + 红线对照）→ npm test → commit → 下一任务
|
||||
- 红线：呈现中性（禁「最推荐/强烈建议」）、隐私脱敏（不指向具体项目/公司/产品）、不绑定具体工具（跨 OS 安装命令/硬件选购指引）、git add 只加任务文件
|
||||
|
||||
## 任务顺序（关键：新技能先于引用它的融合任务，避免中间态死链）
|
||||
|
||||
1. re-flutter（新增）
|
||||
2. re-rtos（新增）
|
||||
3. re-mips（新增）
|
||||
4. re-tee（新增）
|
||||
5. re-harmonyos（新增）
|
||||
6. re-hybrid-app（融合 RN/Hermes + [[re-flutter]] 链接）
|
||||
7. re-iot-proto（融合 BLE + NFC 两章）
|
||||
8. re-game（融合 Lua + Shader 两章）
|
||||
9. re-hw-chip（融合侧信道一章）
|
||||
10. re-fw-extract（融合 MCU 一章 + [[re-rtos]] 链接）
|
||||
11. re-format-pe（融合 Delphi/VB6 一章）
|
||||
12. 同步项（计数/README/triage/re-mobile 网关清单）
|
||||
13. 最终全分支评审 + 修复波
|
||||
|
||||
每个新增技能完成后 npm test 允许有「指向未来任务的死链」？——不允许：validate.mjs 会 FAIL。因此**新增技能内部不允许链接未创建技能**；对未来的引用留到融合任务时再补（如 re-hybrid-app 的 [[re-flutter]] 在 Task 6 才写）。新增技能只链接已存在技能。
|
||||
|
||||
## 通用格式要求（所有任务）
|
||||
|
||||
- SKILL.md 结构：frontmatter（name=目录名、description 含触发词）→ # 标题 → ## 何时使用 / 何时不用 → ## 工具准备（跨 OS 安装命令 + 验证命令；硬件类给选购指引不绑型号）→ ## 操作步骤（编号、每步命令、存档习惯）→ 章节 → ## 跨域联合（[[链接]]）→ ## 常见坑与陷阱（**标题**：现象——…；原因——…；对策——… 格式）
|
||||
- 触发词与既有技能不重叠（如 re-flutter 不抢 re-apk 的 smali 触发词）
|
||||
- 坑条目 ≥3 条，每条含现象/原因/对策三要素
|
||||
|
||||
---
|
||||
|
||||
## Task 1：re-flutter（新增）
|
||||
|
||||
**目标文件**：`.claude/skills/re-flutter/SKILL.md`
|
||||
|
||||
**内容结构**：
|
||||
- 何时用/不用：用 Flutter App（Android `libapp.so` / iOS App.framework、`libflutter.so`、`kernel_blob.bin`、assets 下 snapshot）；不用纯原生 App（[[re-apk]] / [[re-ios]]）、不用 Web 版 Flutter
|
||||
- 工具准备：python3（blob 结构解析）、strings/binutils、Ghidra（blob 反汇编与字符串交叉引用）、frida（动态侧，见 [[platform-tips]] 沙箱原则）、`--split-debug-info` 符号映射说明
|
||||
- 操作步骤（编号）：
|
||||
1. 识别：`file` + `strings` 定位 libapp.so、检查 assets/flutter_assets 下的 kernel_blob.bin（debug 模式）vs AOT snapshot（release 模式）
|
||||
2. snapshot 结构：Dart AOT snapshot 的 blobs 分区（ObjCode/rodata/instructions/strings/…）手动解析与字符串定位——strings blob 里找业务字符串，交叉引用回指令 blob
|
||||
3. 符号还原：有 `--split-debug-info` 的 symbol 映射文件 → 名字直接映射；无映射 → 从字符串/`dart:` 库注册调用点反推
|
||||
4. 引擎 vs 业务区分：libflutter.so 是引擎不分析（除非引擎层 hook），重点 libapp.so
|
||||
5. 动态侧（沙箱）：frida hook Dart VM 入口（`Dart_CreateRootLibrary` / 库注册）观察加载流程；Dart VM Service 可连时直接枚举 isolate/库
|
||||
- 跨域联合：[[re-apk]]、[[re-ios]]、[[re-mobile]]、[[re-frida]]、[[re-hybrid-app]]
|
||||
- 坑（至少 3）：
|
||||
- release 无 kernel_blob（只有 AOT）——别找 snapshot 文件
|
||||
- 混淆后 Dart 名字是短名（tree-shaking/obfuscate）——用 symbol 映射或字符串定位，参考 [[re-go]] garble 思路（不写死链接，可提）
|
||||
- 引擎代码混入业务 —— 按 libapp/libflutter 边界过滤
|
||||
- frida 版本与设备匹配（沿用 re-frida 工具准备要求）
|
||||
|
||||
**验收**：npm test 通过（112 前为 107+1=108）；无死链；触发词不撞 re-apk/re-hybrid-app
|
||||
|
||||
## Task 2：re-rtos（新增）
|
||||
|
||||
**目标文件**：`.claude/skills/re-rtos/SKILL.md`
|
||||
|
||||
**内容结构**：
|
||||
- 何时用/不用：MCU/IoT 固件跑 FreeRTOS/ThreadX/Zephyr/RT-Thread；不用裸机固件（MCU 镜像基础走 [[re-fw-extract]]）、不用 Linux 内核（[[re-kernel]]）
|
||||
- 工具准备：Ghidra（结构体定义与任务表还原，ARM/ARM Thumb 处理器模块）、binwalk（镜像提取先行）、python3
|
||||
- 操作步骤：
|
||||
1. 前置：镜像提取与格式识别（链接 [[re-fw-extract]]）
|
||||
2. RTOS 识别：启动代码（reset handler → 系统初始化 → 调度器启动）、搜索调度器特征串/符号（`xTaskCreate`/`osKernelStart`/`_tx_thread_create`/`z_thread_entry` 类）、头部字符串
|
||||
3. 任务表定位：FreeRTOS 的 `pxCurrentTCB`/任务链表静态区、ThreadX 的 `_tx_thread_created_list` 双向链表、Zephyr 的 `_kernel` 结构 —— 在 Ghidra 中定义结构体逐字段还原（优先级/状态/栈指针/任务名）
|
||||
4. 任务栈识别：栈底/栈顶常量定位，按栈归属切分任务边界
|
||||
5. 内核对象：队列/信号量/互斥/定时器 结构体定位，看板式从内核 API 调用点反推
|
||||
6. 按任务拆分反编译：每个任务一个入口点，独立分析（对应 [[re-analyze]] 的单函数深分析）
|
||||
- 跨域联合：[[re-fw-extract]]、[[re-fw-emulate]]、[[re-binary-core]]、[[re-mcu]]（Task 10 后才建，Task 2 先不链接！）
|
||||
- 坑（至少 3）：
|
||||
- 调度器启动前代码别当任务分析
|
||||
- 任务名是调试符号，stripped 固件里没有——用栈指针/优先级特征定位
|
||||
- 不同 RTOS 任务结构差异大（链表 vs 静态表）——先识别再定结构体
|
||||
- RTOS 版本文本串可被混淆（新版本去掉字符串）——用结构特征兜底
|
||||
|
||||
**注意**：Task 2 不得链接 re-mcu（Task 10 才创建）。re-mcu 的引用由 Task 10 补写。
|
||||
|
||||
## Task 3：re-mips（新增）
|
||||
|
||||
**目标文件**：`.claude/skills/re-mips/SKILL.md`
|
||||
|
||||
**内容结构**：
|
||||
- 何时用/不用：MIPS 固件/恶意软件（路由器/嵌入式）、MIPS 架构样本；不用 ARM/x86 系（[[re-binary-core]] 通用底座）
|
||||
- 工具准备：Ghidra/IDA 的 MIPS 处理器模块、binwalk（固件提取）、qemu-user 的 MIPS 模式（动态，沙箱原则）、python3
|
||||
- 操作步骤：
|
||||
1. 前置：固件提取（[[re-fw-extract]]）与架构确认（`file`/`readelf -h`）
|
||||
2. 字节序判断：MIPS 大端/小端（`readelf` e_flags、字符串可读性）
|
||||
3. 反编译注意：**延迟槽**（branch/jump 后一条指令仍执行——反汇编工具处理但手读代码时容易错位）、`$gp`/`$ra` 调用约定、GP 相对寻址（`.got` 重定位表）、`-mlong-calls` 跳板
|
||||
4. 路由器固件专项：web 后端 httpd 定位（认证绕过/命令注入模式）、`/bin/busybox` 集成命令识别、固件配置与密码哈希提取
|
||||
5. 动态验证（沙箱）：qemu-user 跑 MIPS 样本或固件内程序，观察行为
|
||||
- 跨域联合：[[re-fw-extract]]、[[re-fw-rootfs]]、[[re-binary-core]]、[[re-ghidra]]、[[re-vuln]]、[[re-sandbox]]
|
||||
- 坑（至少 3）：
|
||||
- 延迟槽：分支后的指令在跳转前已执行——跟踪执行流时容易错
|
||||
- 大小端判断错 → 指令全部乱
|
||||
- `$gp` 相对引用没有重定位信息时靠基址猜测
|
||||
- 路由器固件常见非标准头/压缩层（多步 binwalk）
|
||||
|
||||
## Task 4：re-tee（新增）
|
||||
|
||||
**目标文件**：`.claude/skills/re-tee/SKILL.md`
|
||||
|
||||
**内容结构**：
|
||||
- 何时用/不用：TrustZone/OP-TEE/Trusted App/secure storage/设备密钥相关；不用 Windows 内核（[[re-kernel]]）、不用普通 App 层
|
||||
- 工具准备：Ghidra/IDA（ARM64）、固件提取工具链（[[re-fw-extract]]）、frida/内核侧 hook（[[re-frida]] 沙箱原则）、python3
|
||||
- 操作步骤：
|
||||
1. 架构定位：normal world vs secure world、SMC 指令与监控模式（EL3）、TEE OS 加载入口（bootrom/固件中定位）
|
||||
2. OP-TEE 结构：core（可信 OS 内核）与 TA（可信应用）分离；TA 二进制格式（`.ta`：ELF with TA 头/签名）解析
|
||||
3. TA 分析：入口（`TA_InvokeCommand`/命令分发表）、命令号枚举、secure storage 对象操作（`TEE_*` API 调用点）
|
||||
4. 主机侧调用面：Linux 侧 `TEE_IOC_*` ioctl 结构、client 库调用序列——从两头夹逼 TA 的输入输出格式
|
||||
5. 常见厂商差异（泛化表述，不指具体产品）：自定义 TEE 的接口/结构差异处理思路
|
||||
- 跨域联合：[[re-fw-extract]]、[[re-kernel]]、[[re-mobile]]、[[re-hw-chip]]、[[re-binary-core]]
|
||||
- 坑（至少 3）：
|
||||
- TA 是签名+加密的固件镜像——先解密/验签流程再谈静态分析
|
||||
- secure world 代码拿不到时用主机侧 ioctl 调用面反推
|
||||
- 反调试：secure world 侧监测/防 dump 机制（泛化）
|
||||
- SMC 参数传递寄存器约定（x0-x7 泛化）错误会导致完全误读
|
||||
|
||||
## Task 5：re-harmonyos（新增）
|
||||
|
||||
**目标文件**：`.claude/skills/re-harmonyos/SKILL.md`
|
||||
|
||||
**内容结构**：
|
||||
- 何时用/不用：鸿蒙 App（hap/hsp/har）、ArkTS 字节码；不用普通 Android（[[re-apk]]）
|
||||
- 工具准备：hap 解包工具（hap-tools 类，不绑定具体实现——给通用描述与备选）、python3、字符串/资源提取工具、[[re-java]] 思路复用（jadx 类工具针对 abc 的替代——泛化）
|
||||
- 操作步骤：
|
||||
1. 包结构：hap ≈ APK 变体（`module.json`、`resources/`、`ets/` 字节码目录、`.abc` 文件）；解包流程与 APK 同源（zip 容器）
|
||||
2. 字节码识别：`.abc`（ArkCompiler 字节码）文件头/段结构特征
|
||||
3. 业务逻辑还原：字符串定位 + 反汇编（ArkCompiler 反汇编器思路）、JS/TS 业务资源提取（与 [[re-script-deob]] 方法衔接）
|
||||
4. 与 Android 异同：无 dex/smali 层（跳过 [[re-apk]] 的 dex 环节）、资源与 manifest 结构类似（可复用 jadx 思路但目标格式不同）
|
||||
5. 动态侧（沙箱）：模拟器/真机运行时观察（[[re-mobile]] 编排）
|
||||
- 跨域联合：[[re-apk]]、[[re-hybrid-app]]、[[re-java]]、[[re-mobile]]、[[re-script-deob]]
|
||||
- 坑（至少 3）：
|
||||
- 用 Android 工具直接开 hap 会漏 ets 目录——记住是双容器（zip + 内部资源）
|
||||
- abc 反汇编器版本敏感（ArkCompiler 演进）——先识别编译版本
|
||||
- 混淆后的 ArkTS 名字短名——字符串/资源定位兜底
|
||||
|
||||
## Task 6：re-hybrid-app（融合）
|
||||
|
||||
**目标文件**：`.claude/skills/re-hybrid-app/SKILL.md`
|
||||
|
||||
**内容**：追加「## React Native / Hermes」章节（位置在现有内容之后、跨域联合之前）：
|
||||
- 识别：`.hbc` 文件头魔数（`c61fbc03` 类）、RN 应用结构（`index.android.bundle` 类）
|
||||
- Hermes 字节码：反汇编思路（hermesc 类工具）、内存布局/段特征
|
||||
- JS bundle 提取：Metro 打包结构（`__d` 函数注册表类）、从 bundle 恢复业务 JS
|
||||
- 原生桥接：NativeModules 定位（`TurboModule`/`NativeModules` 引用点）、桥接方法名与实现映射
|
||||
- 动态：[[re-frida]] hook JS 运行时（`console.log`/模块加载点）
|
||||
- 在现有 Flutter 段末尾补一句指向 [[re-flutter]]（「Flutter 专项见 [[re-flutter]]」，不重复内容）
|
||||
- 更新 frontmatter description 触发词补 Hermes/hbc
|
||||
|
||||
**验收**：章节格式与既有章节一致；[[re-flutter]] 链接有效（Task 1 已建）；坑 ≥3 条（Hermes 版本差异、bundle 加密、字节码与明文 JS 混合等）
|
||||
|
||||
## Task 7：re-iot-proto（融合两章）
|
||||
|
||||
**目标文件**：`.claude/skills/re-iot-proto/SKILL.md`
|
||||
|
||||
**内容 A「## BLE 链路层」**：
|
||||
- 嗅探：nRF 系硬件（泛化给选购指引）与主机软件抓包流程
|
||||
- 广播/连接：广播包解析（ADV_IND/ADV_SCAN_IND 类）、连接事件时序、信道 37/38/39
|
||||
- 配对加密：LE Legacy Pairing / LE Secure Connections 协商流程、LTK/STK 定位点、白名单/绑定密钥存储
|
||||
- GATT：服务/特征枚举、handle 定位、读写通知点
|
||||
- 与既有 MQTT/CoAP/Zigbee 章节并列
|
||||
|
||||
**内容 B「## NFC / 智能卡」**：
|
||||
- ISO14443 帧结构、防冲突流程（UID/SAK 类）
|
||||
- APDU 交互（CLA/INS/P1/P2/数据）、卡片应用定位
|
||||
- MIFARE Classic：Crypto-1 弱点（重放/破解思路，泛化）、扇区密钥处理
|
||||
- proxmark3 类设备流程（泛化选购）
|
||||
|
||||
**验收**：两章不重叠既有章节；坑 ≥3 条/章（或合并 ≥5）；frontmatter 触发词补 BLE 链路/NFC/智能卡
|
||||
|
||||
## Task 8：re-game（融合两章）
|
||||
|
||||
**目标文件**：`.claude/skills/re-game/SKILL.md`
|
||||
|
||||
**内容 A「## 游戏脚本引擎（Lua）」**：
|
||||
- Lua 字节码：header（签名/版本）、指令结构、常量表/upvalue 表定位
|
||||
- 反汇编：luac 类工具思路；LuaJIT 字节码差异（不同版本）
|
||||
- Cocos 系脚本资源提取：`.jsc`/`.luac` 混淆变体（XOR/头截断——参考 [[re-fw-extract]] 的 XOR 章节思路）
|
||||
- 脚本 hook：[[re-frida]] 或内存侧 hook Lua 函数（`lua_pcall` 类入口）
|
||||
|
||||
**内容 B「## 图形与 Shader」**：
|
||||
- SPIR-V：`spirv-dis` 反汇编、指令集结构
|
||||
- DXIL/DXBC：dxc 反汇编思路、SM 版本识别
|
||||
- GLSL 还原：spirv-cross 类工具（泛化）
|
||||
- 找渲染入口：着色器加载点（文件/内存）、常量表定位
|
||||
|
||||
**验收**：两章格式一致；坑 ≥3/章；不抢 re-frida/re-script-deob 触发词
|
||||
|
||||
## Task 9：re-hw-chip（融合一章）
|
||||
|
||||
**目标文件**：`.claude/skills/re-hw-chip/SKILL.md`
|
||||
|
||||
**内容「## 侧信道与故障注入」**：
|
||||
- SPA/DPA：功耗曲线采集原理、差分分析思路（密钥位相关性）、采集设备（chipwhisperer 类泛化选购指引）
|
||||
- 故障注入：时钟毛刺/电压毛刺、glitch 宽度/相位定位流程、重放与结果判定（跳过分支/改返回值类）
|
||||
- 与去封装衔接：已有章节的流程联动
|
||||
- 安全边界提示：授权范围（沿用技能库使用边界）
|
||||
|
||||
**验收**：与现有去封装/裸片章节并列不冲突；坑 ≥3
|
||||
|
||||
## Task 10：re-fw-extract（融合一章）
|
||||
|
||||
**目标文件**：`.claude/skills/re-fw-extract/SKILL.md`
|
||||
|
||||
**内容「## MCU 镜像分析」**：
|
||||
- 镜像格式：Intel HEX（.hex）/bin 差异、程序内存布局（flash 起始/中断向量表）
|
||||
- 向量表定位：复位向量 → 启动代码（衔接 [[re-rtos]]：跑 RTOS 的固件）
|
||||
- ISA 识别与反汇编：8051/AVR/PIC/MSP430 各自特征（Ghidra 处理器模块），熔丝位/配置位概念（泛化）
|
||||
- 与既有 binwalk/magic 流程衔接（镜像提取后进入本节的判断条件）
|
||||
|
||||
**验收**：[[re-rtos]] 链接有效（Task 2 已建）；坑 ≥3
|
||||
|
||||
## Task 11：re-format-pe（融合一章）
|
||||
|
||||
**目标文件**：`.claude/skills/re-format-pe/SKILL.md`
|
||||
|
||||
**内容「## 老运行时识别（Delphi / VB6）」**：
|
||||
- Delphi VCL：RTTI 结构定位（类名/方法表）、vmt 定位、Borland 资源段（`.rsrc` 内特征）
|
||||
- VB6：MSVBVM60 运行时特征（导入/资源）、入口定位（`WinMain` 类）
|
||||
- 老壳注意：PECompact 类轻壳与 [[re-packer-id]] 衔接
|
||||
- 识别先行：格式解析阶段就判断运行时（Delphi 的 `TApplication` 类串、VB6 的资源脚本特征）
|
||||
|
||||
**验收**：不抢 [[re-packer-id]] 触发词；坑 ≥3
|
||||
|
||||
## Task 12：同步项
|
||||
|
||||
**改动文件**：
|
||||
1. `package.json` description：107 → 112
|
||||
2. `.claude-plugin/marketplace.json` description（顶层）：107 → 112（插件条目 description 无计数，不动）
|
||||
3. `README.md`：首段「107 个逆向工程技能」→ 112；技能导航段：re-mobile 组 + re-flutter、re-harmonyos；re-firmware 组 + re-rtos；re-binary-core 组 + re-mips；re-tee 挂组按 Task 4 实现时定（默认 re-firmware 组）；导航清单里同步各融合技能（不列章节，只保持技能名完整）
|
||||
4. `.claude/skills/re-analyze/references/triage.md`：移动路径补 re-flutter/re-harmonyos；固件路径补 re-rtos
|
||||
5. `.claude/skills/re-mobile/SKILL.md`：子技能清单 + [[re-flutter]] + [[re-harmonyos]]
|
||||
6. `README.md` 安装段不动；marketplace.json 版本保持 0.0.2
|
||||
|
||||
**验收**：`grep -c` 全文无残留「107 个」；npm test 112 全绿；claude plugin validate 通过
|
||||
|
||||
## Task 13：最终全分支评审
|
||||
|
||||
- 全量 diff 复核（结构/红线 2/触发词重叠/坑格式）
|
||||
- 技术事实抽查（延迟槽、Hermes 魔数、Dart snapshot、RTOS 结构、abc 格式、Crypto-1、SPIR-V 指令）
|
||||
- npm test + claude plugin validate 双绿
|
||||
- 台账更新 .superpowers/sdd/progress.md
|
||||
|
||||
## 评审清单（每任务）
|
||||
|
||||
- [ ] frontmatter name=目录名、description 含触发词、type=atomic
|
||||
- [ ] 有「## 工具准备」（跨 OS 命令 + 验证）
|
||||
- [ ] [[链接]] 全部存在（validate.mjs 强制）
|
||||
- [ ] 红线 1：无最高级强推措辞
|
||||
- [ ] 红线 2：无具体项目/公司/产品指代
|
||||
- [ ] 不绑定具体工具（方法为核心，工具可替换）
|
||||
- [ ] 坑条目含现象/原因/对策三要素
|
||||
- [ ] 触发词不重叠
|
||||
- [ ] npm test 全绿
|
||||
@@ -0,0 +1,44 @@
|
||||
# zws 收藏库经验吸收实施计划（2026-08-20）
|
||||
|
||||
## 总览
|
||||
|
||||
- 范围：14 个融合吸收任务（99 候选 → ~40 条入库），技能数 112 不变
|
||||
- 素材：/home/DslsDZC/rev-refs/extract-zws-*.md（已脱敏，7 文件）
|
||||
- 设计依据：docs/superpowers/specs/2026-08-20-zws-absorption-design.md
|
||||
- 流程：读素材+目标技能 → 查重（grep 关键词，同现象跳过/深化合并）→ 改写坑条目（现象/原因/对策）→ 追加进「## 常见坑与陷阱」→ 来源注明（仅 MIT/Apache）→ 脱敏对照 → npm test → commit
|
||||
- 红线：呈现中性（禁「最推荐/强烈建议」）、隐私脱敏（无具体项目/公司/产品）、不绑定工具、git add 只加任务文件
|
||||
|
||||
## 任务表（全部可并行——不同目标文件）
|
||||
|
||||
| # | 目标 | 素材文件 | 候选条目 | 目标条数 | 来源注明 |
|
||||
|---|---|---|---|---|---|
|
||||
| 1 | re-flutter/SKILL.md | extract-zws-reverse-skills.md | 4,5,6,7,8,10,13,14,17,18 | 6-8 | （来源：reverse-skills（inliver233），MIT） |
|
||||
| 2 | re-hybrid-app/SKILL.md | extract-zws-hermes.md | 2,3,5,7,11,14,15 | 5-7 | （来源：hermes-decomp（SymbioticSec），MIT） |
|
||||
| 3 | re-script-deob/SKILL.md | extract-zws-hermes.md | 10,14 | 1-2 | （来源：hermes-decomp（SymbioticSec），MIT） |
|
||||
| 4 | re-game/SKILL.md | extract-zws-cpp2il.md | 1,2,3,5,6,8 | 4-5 | （来源：Cpp2IL（SamboyCoding），MIT） |
|
||||
| 5 | re-deobfuscate/SKILL.md | extract-zws-chernobog.md | 1,3,5,8,12,13,14,15 | 4-6（查重最严） | 不注源（无许可蒸馏） |
|
||||
| 6 | re-python/SKILL.md | extract-zws-pyarmor.md | 1,2,3,5,7,9 | 4-5 | 不注源（无许可蒸馏） |
|
||||
| 7 | re-patching/SKILL.md | extract-zws-reverse-skills.md | 9,11,12 | 2-3 | （来源：reverse-skills（inliver233），MIT） |
|
||||
| 8 | re-mobile-pack/SKILL.md | extract-zws-reverse-skills.md | 20,21 | 2 | （来源：reverse-skills（inliver233），MIT） |
|
||||
| 9 | re-apk/SKILL.md | extract-zws-reverse-skills.md | 19,25 | 2 | （来源：reverse-skills（inliver233），MIT） |
|
||||
| 10 | re-frida/SKILL.md | extract-zws-reverse-skills.md | 22,23,24 | 2-3 | （来源：reverse-skills（inliver233），MIT） |
|
||||
| 11 | re-analyze/references/（新增 analysis-tools.md 或入坑） | extract-zws-reva.md | 1,2,3,4,8,10,13 | 3-5 | （来源：ReVa（cyberkaida），Apache-2.0） |
|
||||
| 12 | re-dotnet/SKILL.md | extract-zws-lazy.md | 1 | 1 | （来源：LazyReverse（a0yami），MIT） |
|
||||
| 13 | re-ida/SKILL.md | extract-zws-lazy.md | 2 | 1 | （来源：LazyReverse（a0yami），MIT） |
|
||||
| 14 | re-feedback/SKILL.md | extract-zws-reverse-skills.md | 26,27 | 1-2 | （来源：reverse-skills（inliver233），MIT） |
|
||||
|
||||
## 通用执行规则（实现者必读）
|
||||
|
||||
1. **读素材条目原文**（/home/DslsDZC/rev-refs/extract-zws-<file>.md 对应条目）→ 按现象/原因/对策改写为坑条目，不逐字复制素材文本
|
||||
2. **查重**：`grep -n <主题关键词> <目标技能>/SKILL.md`；同现象已存在 → 跳过该条；内容更完整 → 深化合并（改写后覆盖原条）
|
||||
3. **追加位置**：「## 常见坑与陷阱」列表末尾；有来源注明的素材在追加的坑条目末行加注（多条坑可共用一行注明或每条加，取每条加——与上轮 reverse-skill 吸收一致）
|
||||
4. **坑格式**：`**标题**：现象——…；原因——…；对策——…`，三要素齐全
|
||||
5. **脱敏对照**：素材已脱敏；入库时检查无具体项目/公司/产品名、无目标战役细节
|
||||
6. **Task 11 特殊**：ReVa 方法论偏「编排/工具设计」，与 re-analyze 既有 references（analysis-contract/rerouting）比对——若条目与其思想重合度高且已覆盖，跳过或合并；真正新的（工具粒度/schema 宽容/后台作业轮询/脚本逃逸舱）写为坑条目或简短 references 说明（实现者自定，倾向坑条目）
|
||||
7. **npm test** 必须全绿（112 不变）；不新增/删除技能
|
||||
8. 不 git add/commit（控制器统一提交）
|
||||
|
||||
## 验收
|
||||
|
||||
- 每任务：坑条目数达标、三要素齐全、来源注明正确（有则加无则无）、npm test 绿
|
||||
- 终审：全波次复核 + 技术事实抽查（VLE 编码/位域头/metadata 版本考古/CFF 证据纪律/PyArmor 窗口/ReVa 轮询）
|
||||
@@ -0,0 +1,169 @@
|
||||
# 深度波（现有技能加深度）实施计划
|
||||
|
||||
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
|
||||
|
||||
**Goal:** 给现有全部技能加深度——T1 薄技能正文扩写至 ~130 行基线 + 全部技能按类型配 references/ 深度文件（每技能 2 个），技能计数不变（112，v4 落地后 118）。
|
||||
|
||||
**Architecture:** 纯技能文档扩展。映射表任务先产出 112 技能 × 类型 × 分层清单 → 样板任务（re-x64dbg/re-format-elf）用户定调 → T1/T2/T3 分层滚动（簇任务，每簇 3-5 技能）→ re-rtos/re-behavior 深度（v4 落地后）→ 终审波。深度文件主题命名（commands/gotchas/layout/examples/decision-tree），`[[链接]]` 目标 = 文件名去扩展名。
|
||||
|
||||
**Tech Stack:** Markdown / YAML frontmatter / validate.mjs（npm test，现有）。
|
||||
|
||||
**设计依据：** docs/superpowers/specs/2026-08-25-depth-wave-design.md（已提交 1c71097）——分层定义（§2）、类型-文件集映射（§3）、质量闸口（§5）以设计文档为准。
|
||||
|
||||
**并行协调：** wave-v4 计划（docs/superpowers/plans/2026-08-25-skill-wave-v4.md）同时执行。文件集隔离：本计划只碰现有技能（v4 的 6 新技能目录 + re-rtos/re-behavior/triage/rerouting/计数文件**不碰**）；re-rtos/re-behavior 的深度产出放队列末尾（v4 落地后套用）。两计划不得交叉修改对方文件。
|
||||
|
||||
## Global Constraints
|
||||
|
||||
- **红线 1 呈现中性**：禁用「最推荐」「强烈建议」等最高级强推措辞（最多「推荐」）
|
||||
- **红线 2 隐私脱敏**：内容不指向具体项目/公司/产品；硬件类给泛化选购指引
|
||||
- **不绑定具体工具**：方法为核心，工具为可替换示例；「工具准备」按模板给跨 OS 安装命令
|
||||
- validate.mjs：references/*.md 文件名（去扩展名）为合法 `[[链接]]` 目标；SKILL.md 的 `[[链接]]` 必须解析（深度文件内引用其他技能必须指向存在目标）；正文扩写不破坏 frontmatter（`name`=目录名、`description` 非空、`type: atomic` 必含「## 工具准备」）与固定五节结构
|
||||
- 事实核验：命令必须可执行、字段/格式断言以官方文档为准；抽查机制进终审波
|
||||
- **commit 纪律**：每任务 commit 只 `git add` 本任务列出的文件，严禁 `git add -A`
|
||||
- 当前分支 `main`；每任务 `npm test` 输出 `OK: 112 skills validated`（v4 落地后为 118）——深度波不改计数
|
||||
- 输出不用 emoji
|
||||
|
||||
---
|
||||
|
||||
### Task 1: 映射表任务（112 技能 × 类型 × 分层）
|
||||
|
||||
**Files:**
|
||||
- Create: `docs/superpowers/specs/2026-08-25-depth-wave-mapping.md`（映射表设计附录）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 设计文档 §2（分层判定）§3（类型规则与代表技能）
|
||||
- Produces: 映射表（后续每个簇任务据此确定成员与文件集）
|
||||
|
||||
- [ ] **Step 1: 生成映射表**
|
||||
|
||||
逐技能判定：分层（T1 <100 行 / T2 100-130 / T3 >130 / 网关）按 2026-08-25 实测行数；类型（工具/格式/方法论/领域混合→取主类型）按设计 §3 规则。每行：`技能 | 行数 | 分层 | 类型 | 文件集`。产出 `docs/superpowers/specs/2026-08-25-depth-wave-mapping.md`。
|
||||
核查：112 行全量覆盖、T1+T2+T3+网关 = 112 闭环。
|
||||
|
||||
- [ ] **Step 2: 验证** — `node validate.mjs` → `OK: 112 skills validated`（映射表是 docs/ 文件，不影响计数）
|
||||
- [ ] **Step 3: Commit** — `docs: 深度波映射表——112 技能 × 类型 × 分层`
|
||||
|
||||
### Task 2: 样板任务（re-x64dbg 工具类 + re-format-elf 格式类）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-x64dbg/SKILL.md`（正文扩写至 ~130 行）
|
||||
- Create: `.claude/skills/re-x64dbg/references/commands.md`
|
||||
- Create: `.claude/skills/re-x64dbg/references/gotchas.md`
|
||||
- Modify: `.claude/skills/re-format-elf/SKILL.md`（正文适度补强）
|
||||
- Create: `.claude/skills/re-format-elf/references/layout.md`
|
||||
- Create: `.claude/skills/re-format-elf/references/examples.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 设计文档 §4（样板审阅要点）
|
||||
- Produces: 两个完整样板（正文 + 深度文件），供用户定调与后续批量任务同构参照
|
||||
|
||||
- [ ] **Step 1: re-x64dbg 深度产出**
|
||||
|
||||
正文扩写至 ~130 行基线（补：常用断点/跟踪命令组合、Scylla 插件流程、附加与启动两种模式差异）；`references/commands.md`（命令速查/常用操作序列/组合套路，含断点命令族、内存读写、补丁导出）；`references/gotchas.md`（工具特有坑 ≥3：x64dbg 与 olly 兼容差异、Scylla 使用注意、反调试检测绕过边界、版本差异）。
|
||||
|
||||
- [ ] **Step 2: re-format-elf 深度产出**
|
||||
|
||||
正文补强（补：section 头/程序头典型布局示例、动态链接结构解析要点）；`references/layout.md`（ELF ehdr/phdr/shdr 字段表与偏移、常见 section 布局图）；`references/examples.md`（最小解析示例：readelf 输出对照 + Python struct 解析 ehdr 示例 + 字节样例）。
|
||||
|
||||
- [ ] **Step 3: 验证** — `node validate.mjs` → `OK: 112 skills validated`（新增 references 文件为合法 [[链接]] 目标）；`npm test` 全绿
|
||||
- [ ] **Step 4: Commit** — `enhance: 深度样板——re-x64dbg（commands/gotchas）+ re-format-elf（layout/examples）`
|
||||
- [ ] **Step 5: 用户审阅定调（评审闸口）**
|
||||
|
||||
向用户提交样板审阅：正文扩写密度与风格、深度文件骨架与命名、命令/示例颗粒度。用户确认或提出修改；定调后批量任务按样板同构执行。**未获确认前不得进入 Task 3。**
|
||||
|
||||
### Task 3-7: T1 批次（<100 行原子技能，约 18 个 → 4-5 簇任务）
|
||||
|
||||
**Files（每簇）:**
|
||||
- Modify: 簇内每个技能 `.claude/skills/<技能>/SKILL.md`（正文扩写至 ~130 行基线）
|
||||
- Create: 簇内每个技能 2 个深度文件（按映射表类型：`references/commands.md`+`gotchas.md` / `layout.md`+`examples.md` / `decision-tree.md`+`gotchas.md`）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1 映射表（簇成员）、Task 2 样板（同构参照）
|
||||
- Produces: T1 全部技能达标（正文基线 + 深度文件）
|
||||
|
||||
- [ ] **Step 1: 簇内技能逐一深度产出**
|
||||
|
||||
每个技能：正文扩写至 ~130 行基线——保持五节结构，补缺章节（工具类补命令组合与验证、格式类补布局与示例、方法论类补决策树与反例），正文内新增 `[[链接]]` 必须指向存在目标；按映射表类型创建 2 个 references/ 深度文件（骨架按样板同构）。
|
||||
|
||||
- [ ] **Step 2: 验证** — `node validate.mjs` → `OK: 112 skills validated`；`npm test` 全绿
|
||||
- [ ] **Step 3: Commit** — `enhance: 深度 T1 簇<编号>——<技能名列表>（正文基线 + 深度文件）`
|
||||
|
||||
（簇划分由 Task 1 映射表确定；预估 4-5 簇，每簇 3-5 技能，主题相邻优先：如工具类簇、格式类簇、方法论类簇、领域混合簇。）
|
||||
|
||||
### Task 8-19: T2 批次（100-130 行，48 个 → 10-12 簇任务）
|
||||
|
||||
**Files（每簇）:**
|
||||
- Modify: 簇内技能 `.claude/skills/<技能>/SKILL.md`（正文适度补强：补缺章/示例/坑，无硬基线）
|
||||
- Create: 关键者（判定规则见设计 §2）2 个深度文件；非关键者本批次不建
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1 映射表、Task 2 样板
|
||||
- Produces: T2 全部技能正文补强、关键者配深度文件
|
||||
|
||||
- [ ] **Step 1: 簇内技能逐一补强**
|
||||
|
||||
正文补强：对照五节模板找出缺口（工具类缺验证命令/版本差异、格式类缺布局说明、方法论类缺边界/反例），补至内容自洽；关键者（跨域引用 ≥2 或网关/triage 直接引用）创建深度文件，骨架按样板同构。
|
||||
|
||||
- [ ] **Step 2: 验证** — `node validate.mjs` → `OK: 112 skills validated`；`npm test` 全绿
|
||||
- [ ] **Step 3: Commit** — `enhance: 深度 T2 簇<编号>——<技能名列表>（正文补强 + 关键者深度文件）`
|
||||
|
||||
### Task 20-26: T3 批次（>130 行，约 33 个 → 6-7 簇任务）
|
||||
|
||||
**Files（每簇）:**
|
||||
- Create: 簇内每个技能 2 个深度文件（按映射表类型）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1 映射表、Task 2 样板
|
||||
- Produces: T3 技能深度文件（正文不动）
|
||||
|
||||
- [ ] **Step 1: 簇内技能逐一创建深度文件**
|
||||
|
||||
正文不动；按映射表类型创建 2 个 references/ 深度文件（内容从现有正文提炼 + 扩展：命令组合/布局图/决策树 + 新坑），骨架按样板同构；深度文件内 `[[链接]]` 指向存在目标。
|
||||
|
||||
- [ ] **Step 2: 验证** — `node validate.mjs` → `OK: 112 skills validated`；`npm test` 全绿
|
||||
- [ ] **Step 3: Commit** — `enhance: 深度 T3 簇<编号>——<技能名列表>（深度文件）`
|
||||
|
||||
### Task 27: re-rtos / re-behavior 深度产出（v4 落地后）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-rtos/SKILL.md`（按 v4 扩章后的最终形态补强，如需要）
|
||||
- Create: `.claude/skills/re-rtos/references/decision-tree.md` + `gotchas.md`（方法论类文件集）
|
||||
- Create: `.claude/skills/re-behavior/references/decision-tree.md` + `gotchas.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: v4 计划 Task 7/8 完成（两技能扩章落地）、Task 1 映射表、Task 2 样板
|
||||
- Produces: 两技能深度文件（与 v4 扩章内容衔接）
|
||||
|
||||
- [ ] **Step 1: 确认 v4 扩章已落地**
|
||||
|
||||
`git log` 确认 re-rtos/re-behavior 的 v4 扩章 commit 存在；若未落地，本任务挂起（不得与 v4 并发修改同一文件）。
|
||||
|
||||
- [ ] **Step 2: 创建深度文件**
|
||||
|
||||
按方法论类文件集创建 4 个文件；内容覆盖 v4 新增章节（re-rtos 的 VxWorks/QNX/INTEGRITY 决策要点、re-behavior 的行为监控工具链使用决策）。
|
||||
|
||||
- [ ] **Step 3: 验证** — `node validate.mjs` → `OK: 118 skills validated`（v4 已落地）；`npm test` 全绿
|
||||
- [ ] **Step 4: Commit** — `enhance: 深度 re-rtos/re-behavior——v4 扩章配套深度文件`
|
||||
|
||||
### Task 28: 终审修复波
|
||||
|
||||
**Files:** 视修复结果（全库）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 2-27 完成
|
||||
- Produces: 全库深度达标、无死链、事实与红线复核通过
|
||||
|
||||
- [ ] **Step 1: 全库审查**
|
||||
|
||||
- `node validate.mjs` / `npm test` 全绿
|
||||
- grep 检查：新增 references/ 文件名均为合法链接目标（validate 已保证）；SKILL.md 结构未被破坏（抽查五节顺序）
|
||||
- 事实抽查：每簇至少 1 条关键断言核对（命令可执行性 / 格式字段官方依据），必要时 web 核实
|
||||
- 红线对照：无强推措辞、无具体项目/产品指向
|
||||
- 深度文件与正文重复度抽查（避免 references 与 SKILL.md 大段重复）
|
||||
|
||||
- [ ] **Step 2: 修复与提交**
|
||||
|
||||
修复发现项（每文件独立 commit：`fix: 深度终审——<内容>`）；全部完成后最终 `node validate.mjs` → `OK: 112 skills validated`（v4 落地后 118）+ `npm test` 全绿。
|
||||
|
||||
---
|
||||
|
||||
**最终验证**：`node validate.mjs` 输出 `OK: 112 skills validated`（v4 落地后 `OK: 118 skills validated`）；`npm test` 22 单测全绿；`git log` 含本计划全部任务 commit。
|
||||
@@ -0,0 +1,304 @@
|
||||
# wave-v4（覆盖缺口波）实施计划
|
||||
|
||||
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
|
||||
|
||||
**Goal:** 新增 6 个原子技能（re-arm/re-riscv/re-console/re-electron/re-javacard/re-ebpf）+ 2 处扩章（re-rtos +VxWorks/QNX/INTEGRITY、re-behavior +行为监控工具链），技能总数 112 → 118。
|
||||
|
||||
**Architecture:** 纯技能文档扩展。6 个新技能目录（SKILL.md 按 docs/skill-template.md 原子技能规范，内容按设计文档 §3 各节）+ 2 处扩章（第 4 节）+ 挂载同步（triage/rerouting/网关子技能列表/跨域引用）+ 计数同步（README/AGENTS/marketplace.json）。
|
||||
|
||||
**Tech Stack:** Markdown / YAML frontmatter / validate.mjs（npm test，现有）。
|
||||
|
||||
**设计依据：** docs/superpowers/specs/2026-08-25-skill-wave-v4-design.md（已提交 f7e4db9）——每任务的技能内容骨架（边界/工具/步骤/坑）以设计文档对应小节为准，本计划不重复整文。
|
||||
|
||||
**并行协调：** 深度波计划（docs/superpowers/plans/2026-08-25-depth-wave.md）同时执行。文件集隔离：本计划只碰 6 新技能目录 + re-rtos/re-behavior/triage/rerouting/网关列表/计数文件；深度波只碰其余现有技能。两计划不得交叉修改对方文件。
|
||||
|
||||
## Global Constraints
|
||||
|
||||
- **红线 1 呈现中性**：禁用「最推荐」「强烈建议」等最高级强推措辞（最多「推荐」）
|
||||
- **红线 2 隐私脱敏**：内容不指向具体项目/公司/产品；硬件类给泛化选购指引
|
||||
- **不绑定具体工具**：方法为核心，工具为可替换示例；「工具准备」按模板给跨 OS 安装命令（Linux/macOS/Windows/WSL 分支）
|
||||
- validate.mjs：frontmatter `name`=目录名、`description` 非空（中英触发词）、`type: atomic` 必含「## 工具准备」、`[[链接]]` 必须解析；新技能先于引用它的同步任务（避免中间态死链）
|
||||
- 事实核验：命令必须可执行、格式/字段断言以官方文档为准（必要时 web 核实），技术事实由实现时抽查，终审波复核
|
||||
- **commit 纪律**：每任务 commit 只 `git add` 本任务列出的文件，严禁 `git add -A`
|
||||
- 当前分支 `main`；`npm test` 预期按任务标注递增（112 → 118）
|
||||
- 输出不用 emoji
|
||||
|
||||
---
|
||||
|
||||
### Task 1: 创建 re-arm 技能
|
||||
|
||||
**Files:**
|
||||
- Create: `.claude/skills/re-arm/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 设计文档 §3.1（边界/工具/步骤/坑）
|
||||
- Produces: 技能目录 `re-arm`（供 Task 9 的 [[re-arm]] 链接解析；计数 112 → 113）
|
||||
|
||||
- [ ] **Step 1: 撰写 SKILL.md**
|
||||
|
||||
按 docs/skill-template.md 五节结构 + 设计文档 §3.1 撰写。frontmatter：
|
||||
```yaml
|
||||
---
|
||||
name: re-arm
|
||||
description: >
|
||||
ARM 架构逆向（非 Android）：Cortex-M/A 向量表、Thumb/ARM 切换、AAPCS 调用约定、位置相关代码重定位、MMIO 外设寄存器交叉。
|
||||
触发词：ARM、arm32、Cortex-M、Cortex-A、Thumb、AAPCS、嵌入式逆向、裸机固件、stm32、向量表。
|
||||
---
|
||||
```
|
||||
「工具准备」必含：Ghidra/IDA（架构导入与 Thumb 支持）、`readelf`/`file`、`qemu-arm`/`qemu-aarch64`（用户态仿真）、`gdb-multiarch`、binwalk（联动 re-fw-extract），跨 OS 安装命令 + 验证命令。
|
||||
「何时使用 / 何时不用」：明确排除 Android so（→ re-android-native）、通用 AArch64 Linux 用户态（→ re-binary-core）。
|
||||
「操作步骤」6 步按设计 §3.1（架构确认 → 入口定位 → Thumb 边界 → 重定位 → AAPCS → 外设 xref）。
|
||||
「常见坑与陷阱」≥3 条按设计 §3.1 列表。
|
||||
|
||||
- [ ] **Step 2: 验证**
|
||||
|
||||
Run: `node validate.mjs`；`npm test`
|
||||
Expected: `OK: 113 skills validated`；22 单测全绿。
|
||||
|
||||
- [ ] **Step 3: Commit**
|
||||
|
||||
```bash
|
||||
git add .claude/skills/re-arm/SKILL.md
|
||||
git commit -m "feat: 新增 re-arm——ARM 架构逆向（Cortex-M/A、Thumb、AAPCS、MMIO），113/118"
|
||||
```
|
||||
|
||||
### Task 2: 创建 re-riscv 技能
|
||||
|
||||
**Files:**
|
||||
- Create: `.claude/skills/re-riscv/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 设计文档 §3.2
|
||||
- Produces: 技能目录 `re-riscv`（供 Task 9 的 [[re-riscv]] 链接解析；计数 113 → 114）
|
||||
|
||||
- [ ] **Step 1: 撰写 SKILL.md**
|
||||
|
||||
frontmatter：
|
||||
```yaml
|
||||
---
|
||||
name: re-riscv
|
||||
description: >
|
||||
RISC-V 架构逆向：RV32/RV64、压缩指令（RVC）、gp 相对寻址、ABI 与 ecall 系统调用约定、工具链指纹。
|
||||
触发词：RISC-V、riscv、RV32、RV64、RVC、压缩指令、ecall、ESP32-C3、GD32V。
|
||||
---
|
||||
```
|
||||
五节按设计 §3.2；「工具准备」含 Ghidra（RISC-V 支持）、`qemu-riscv64/32`、binutils 交叉工具链（`riscv64-unknown-elf-objdump`）、readelf；「操作步骤」7 步；「坑」≥3 条按设计。
|
||||
|
||||
- [ ] **Step 2: 验证** — `node validate.mjs` → `OK: 114 skills validated`；`npm test` 全绿
|
||||
- [ ] **Step 3: Commit** — `feat: 新增 re-riscv——RISC-V 架构逆向（RVC/gp/ABI/ecall），114/118`
|
||||
|
||||
### Task 3: 创建 re-console 技能
|
||||
|
||||
**Files:**
|
||||
- Create: `.claude/skills/re-console/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 设计文档 §3.3
|
||||
- Produces: 技能目录 `re-console`（供 Task 9 的 [[re-console]] 链接解析；计数 114 → 115）
|
||||
|
||||
- [ ] **Step 1: 撰写 SKILL.md**
|
||||
|
||||
frontmatter：
|
||||
```yaml
|
||||
---
|
||||
name: re-console
|
||||
description: >
|
||||
现代主机与复古平台逆向：Switch NSO/NPDM 容器与加密分区、PS4/PS5 ORBIS 结构、SDK 库指纹；复古 ROM 头/卡带格式/存档与 Cheat 码。
|
||||
触发词：主机逆向、Switch、NSO、NPDM、PS4、PS5、ORBIS、Xbox、复古、ROM、NES、GBA、模拟器、Cheat。
|
||||
---
|
||||
```
|
||||
五节按设计 §3.3；「何时不用」显式声明改机/盗版授权边界；「工具准备」含通用反编译器 + 平台容器工具（hactoolnet 类，**实现时 web 核实工具名与可用性**）+ 模拟器调试器 + 卡带读取器选购指引；「操作步骤」6 步（含复古存档/Cheat 小节）；「坑」≥3 条。
|
||||
|
||||
- [ ] **Step 2: 验证** — `node validate.mjs` → `OK: 115 skills validated`；`npm test` 全绿
|
||||
- [ ] **Step 3: Commit** — `feat: 新增 re-console——现代主机（NSO/NPDM/ORBIS）与复古平台逆向，115/118`
|
||||
|
||||
### Task 4: 创建 re-electron 技能
|
||||
|
||||
**Files:**
|
||||
- Create: `.claude/skills/re-electron/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 设计文档 §3.4
|
||||
- Produces: 技能目录 `re-electron`（供 Task 9 的 [[re-electron]] 链接解析；计数 115 → 116）
|
||||
|
||||
- [ ] **Step 1: 撰写 SKILL.md**
|
||||
|
||||
frontmatter：
|
||||
```yaml
|
||||
---
|
||||
name: re-electron
|
||||
description: >
|
||||
Electron 桌面应用逆向：asar 解包、主/渲染进程 JS、V8 字节码（.jsc）边界、CDP 动态调试、反调试对抗。
|
||||
触发词：Electron、asar、桌面应用逆向、.jsc、V8 快照、CDP、ELECTRON_RUN_AS_NODE、devtools 检测。
|
||||
---
|
||||
```
|
||||
五节按设计 §3.4；「工具准备」含 `npx asar extract` 类解包、Node/Electron 版本识别、CDP 客户端、strings、通用反编译器；「操作步骤」7 步（静态 → 动态 → 对抗）；「坑」≥3 条按设计（.jsc 边界注明限制）。
|
||||
|
||||
- [ ] **Step 2: 验证** — `node validate.mjs` → `OK: 116 skills validated`；`npm test` 全绿
|
||||
- [ ] **Step 3: Commit** — `feat: 新增 re-electron——Electron 桌面应用逆向（asar/CDP/.jsc），116/118`
|
||||
|
||||
### Task 5: 创建 re-javacard 技能
|
||||
|
||||
**Files:**
|
||||
- Create: `.claude/skills/re-javacard/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 设计文档 §3.5
|
||||
- Produces: 技能目录 `re-javacard`（供 Task 9 的 [[re-javacard]] 链接解析；计数 116 → 117）
|
||||
|
||||
- [ ] **Step 1: 撰写 SKILL.md**
|
||||
|
||||
frontmatter：
|
||||
```yaml
|
||||
---
|
||||
name: re-javacard
|
||||
description: >
|
||||
Java Card / SIM 卡 applet 逆向：CAP 文件九组件解析、CAP 字节码（Java 子集）还原、AID 与安装参数、process(APDU) 分派。
|
||||
触发词：Java Card、javacard、CAP 文件、SIM 卡、USIM、applet、AID、银行卡、JCVM。
|
||||
---
|
||||
```
|
||||
五节按设计 §3.5；「工具准备」含 CAP 解析（开源解析器或自写 Python 脚本，实现时核实可用解析器）、Ghidra/IDA 无原生 CAP 支持说明、`javap` 对照、读卡器选购指引 + 授权边界；「操作步骤」6 步；「坑」≥3 条。
|
||||
|
||||
- [ ] **Step 2: 验证** — `node validate.mjs` → `OK: 117 skills validated`；`npm test` 全绿
|
||||
- [ ] **Step 3: Commit** — `feat: 新增 re-javacard——Java Card/SIM applet（CAP 组件/字节码还原），117/118`
|
||||
|
||||
### Task 6: 创建 re-ebpf 技能
|
||||
|
||||
**Files:**
|
||||
- Create: `.claude/skills/re-ebpf/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 设计文档 §3.6
|
||||
- Produces: 技能目录 `re-ebpf`（供 Task 9 的 [[re-ebpf]] 链接解析；计数 117 → 118）
|
||||
|
||||
- [ ] **Step 1: 撰写 SKILL.md**
|
||||
|
||||
frontmatter：
|
||||
```yaml
|
||||
---
|
||||
name: re-ebpf
|
||||
description: >
|
||||
eBPF 程序逆向与对抗分析：BPF-64 指令集、progs/maps 关联、bpftool 反汇编、跟踪取证/恶意样本/EDR 对抗三用途。
|
||||
触发词：eBPF、BPF、bpftool、bcc、libbpf、xlated、BPF 指令、bpf hook、EDR 对抗、tracepoint、kprobe。
|
||||
---
|
||||
```
|
||||
五节按设计 §3.6；「工具准备」含 `bpftool`（`prog dump xlated`/`feature`）、`llvm-objdump -d bpf`、pyelftools、专用逆向工具（实现时核实，如 bpf-gazelle 类）、受控环境（联动 re-sandbox）；「操作步骤」5 步；「坑」≥3 条（helper 调用号版本漂移对策写明按版本查表）。
|
||||
|
||||
- [ ] **Step 2: 验证** — `node validate.mjs` → `OK: 118 skills validated`；`npm test` 全绿
|
||||
- [ ] **Step 3: Commit** — `feat: 新增 re-ebpf——eBPF 程序逆向与对抗（BPF-64/progs-maps/xlated），118/118`
|
||||
|
||||
### Task 7: re-rtos 扩章（VxWorks/QNX/INTEGRITY）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-rtos/SKILL.md`（frontmatter 触发词、正文 +3 章、跨域联合 +[[re-automotive]]、「何时使用」扩一句商业 RTOS）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 设计文档 §4.1
|
||||
- Produces: re-rtos 覆盖 7 个 RTOS（计数不变）
|
||||
|
||||
- [ ] **Step 1: 扩写 SKILL.md**
|
||||
|
||||
- frontmatter description 触发词追加：`VxWorks、QNX、INTEGRITY`
|
||||
- 正文按现有四章同构追加三章（每章：TCB/内核对象关键字段 → 定位方法 → 特征串）：
|
||||
- **VxWorks**：WIND_TCB（任务名表/栈指针/优先级字段）、VxWorks 7 结构变化、任务名串特征定位
|
||||
- **QNX**：线程控制块（procnto 微内核）、MsgSend/MsgReceive 消息传递调度链、车机中控场景
|
||||
- **INTEGRITY**：分区（partitions）内存布局、任务/进程表结构、航电/工业场景特征
|
||||
- 跨域联合追加 `[[re-automotive]]`（QNX 车机联动）
|
||||
|
||||
- [ ] **Step 2: 验证** — `node validate.mjs` → `OK: 118 skills validated`；`npm test` 全绿
|
||||
- [ ] **Step 3: Commit** — `enhance: re-rtos 扩章——VxWorks/QNX/INTEGRITY 三章 + 车机联动`
|
||||
|
||||
### Task 8: re-behavior 扩章（行为监控工具链）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-behavior/SKILL.md`（追加「行为监控工具链」一节）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: 设计文档 §4.2
|
||||
- Produces: re-behavior 覆盖 Windows 行为监控（计数不变）
|
||||
|
||||
- [ ] **Step 1: 扩写 SKILL.md**
|
||||
|
||||
正文追加一节「行为监控工具链（Windows）」：
|
||||
- **ProcMon**：过滤/标注/CSV 导出关联（进程→文件→注册表→网络时间线）、过滤语法要点
|
||||
- **API Monitor**：API 级 hook 链与调用参数记录（与 re-tracing 的 strace/ltrace 对应）
|
||||
- **ETW**：会话与事件解析（logman/wevtutil 命令；采集侧视角，与 re-evasion 绕过侧互补）
|
||||
- **Process Explorer**：进程树/句柄/签名验证视图要点
|
||||
- 仅 Windows 工具在「工具准备」注明跨 OS 约束（Linux 侧对应走 [[re-tracing]]）
|
||||
|
||||
- [ ] **Step 2: 验证** — `node validate.mjs` → `OK: 118 skills validated`；`npm test` 全绿
|
||||
- [ ] **Step 3: Commit** — `enhance: re-behavior 扩章——Windows 行为监控工具链（ProcMon/API Monitor/ETW/PE）`
|
||||
|
||||
### Task 9: 挂载同步（triage / rerouting / 网关列表 / 跨域引用）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-analyze/references/triage.md`（路由表补分支）
|
||||
- Modify: `.claude/skills/re-analyze/references/rerouting.md`（A/B 表补行）
|
||||
- Modify: `.claude/skills/re-binary-core/SKILL.md`（子技能列表补 [[re-arm]]/[[re-riscv]]）
|
||||
- Modify: `.claude/skills/re-managed/SKILL.md`（子技能列表补 [[re-electron]]/[[re-javacard]]）
|
||||
- Modify: `.claude/skills/re-game/SKILL.md`（跨域联合补 [[re-console]]）
|
||||
- Modify: `.claude/skills/re-iot-proto/SKILL.md`（跨域联合补 [[re-javacard]]）
|
||||
- Modify: `.claude/skills/re-fw-emulate/SKILL.md`（架构识别节补 [[re-arm]]/[[re-riscv]]）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1-6 的技能目录（[[链接]] 解析目标）
|
||||
- Produces: 新技能可被发现（计数不变）
|
||||
|
||||
- [ ] **Step 1: triage.md 补路由**
|
||||
|
||||
按现有路由表行式逐行核对，补：
|
||||
- 固件行：`→（ARM 架构 → re-arm；RISC-V → re-riscv）`
|
||||
- 托管行：`→（Electron 应用 → re-electron；Java Card/SIM → re-javacard）`
|
||||
- 游戏行：`→（现代主机/复古 → re-console）`
|
||||
|
||||
- [ ] **Step 2: rerouting.md 补证据→技能行**
|
||||
|
||||
A/B 表补行（至少 5 行）：`.NSO/NPDM` 结构 → re-console；BPF ELF section（.BTF/.maps）→ re-ebpf；CAP 文件头（`0xDE 0xCA` 类魔数，实现时按 CAP 规范核实）→ re-javacard；asar 结构（`files` 目录 + app.asar）→ re-electron；VxWorks/QNX 特征串 → re-rtos；MMIO 外设区 + Thumb 特征 → re-arm。
|
||||
|
||||
- [ ] **Step 3: 网关子技能列表与跨域引用**
|
||||
|
||||
re-binary-core 子技能行补 `[[re-arm]]`、`[[re-riscv]]`（对标 `[[re-mips]]` 行）；re-managed 子技能行补 `[[re-electron]]`、`[[re-javacard]]`；re-game 跨域联合补 `[[re-console]]`；re-iot-proto 跨域联合补 `[[re-javacard]]`；re-fw-emulate 架构识别节补 `[[re-arm]]`/`[[re-riscv]]`。
|
||||
|
||||
- [ ] **Step 4: 验证** — `node validate.mjs` → `OK: 118 skills validated`（无死链）；`npm test` 全绿
|
||||
- [ ] **Step 5: Commit** — `enhance: 挂载同步——triage/rerouting 路由补 6 技能 + 网关列表与跨域引用`
|
||||
|
||||
### Task 10: 计数同步（README / AGENTS / marketplace.json）
|
||||
|
||||
**Files:**
|
||||
- Modify: `README.md`（技能数 112 → 118，按实际表述核对）
|
||||
- Modify: `AGENTS.md`（技能数 112 → 118）
|
||||
- Modify: `marketplace.json`（逐字段核对，有技能数/版本则同步）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1-9 完成
|
||||
- Produces: 全库计数一致（118）
|
||||
|
||||
- [ ] **Step 1: 计数替换**
|
||||
|
||||
grep 全库 `112` 相关技能数表述（README/AGENTS/marketplace.json 及他处），逐一更新为 118；不含数字的其他字段不动。
|
||||
|
||||
- [ ] **Step 2: 验证** — `node validate.mjs` → `OK: 118 skills validated`；`npm test` 全绿
|
||||
- [ ] **Step 3: Commit** — `docs: 计数同步 112 → 118（README/AGENTS/marketplace）`
|
||||
|
||||
### Task 11: 终审修复波
|
||||
|
||||
**Files:** 视修复结果（全库）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1-10 完成
|
||||
- Produces: 全库一致、无死链、事实与红线达标
|
||||
|
||||
- [ ] **Step 1: 全库审查**
|
||||
|
||||
- `node validate.mjs` / `npm test` 全绿
|
||||
- grep 检查：6 新技能触发词与 description 一致性、[[链接]] 全部可解析（validate 已保证）、计数 118 一致
|
||||
- 技术事实抽查：每个新技能至少 1 条关键断言核对（命令可执行性 / 格式字段官方依据），必要时 web 核实
|
||||
- 红线对照：新内容无强推措辞、无具体项目/产品指向
|
||||
|
||||
- [ ] **Step 2: 修复与提交**
|
||||
|
||||
修复发现项（每文件独立 commit：`fix: 终审——<内容>`）；全部完成后最终 `node validate.mjs` → `OK: 118 skills validated` + `npm test` 全绿。
|
||||
|
||||
---
|
||||
|
||||
**最终验证**：`node validate.mjs` 输出 `OK: 118 skills validated`；`npm test` 22 单测全绿；`git log` 含本计划全部任务 commit。
|
||||
@@ -0,0 +1,416 @@
|
||||
# 事实核查波（监控报告对账后修复）实施计划
|
||||
|
||||
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
|
||||
|
||||
**Goal:** 处理 2026-09-12 至 2026-09-29 ChatGPT 监控对话中的 121 条报告项——30 条已修不动，91 条未修项经实测判定后，对确证成立者修正内容、补回归断言、回填审查状态。
|
||||
|
||||
**Architecture:** 先出判定表（逐条给出实测证据与结论：采纳/驳回/部分采纳），再按**技能文件集**分组串行修复（每个技能只归一个任务，避免同文件并发修改）。两条「安装矩阵收敛」任务（rizin / binwalk）先落地源侧单一事实源，其余任务改写各自的副本指回源侧。终审波统一补断言与审查记录。
|
||||
|
||||
**Tech Stack:** Markdown / YAML frontmatter / Node ESM 工具链（`validate.mjs`、`bin/capindex.mjs`、`bin/auditstate.mjs`）/ node:test。
|
||||
|
||||
**设计依据：** 本次对账的三份本地产物（`/analysis/` 下，gitignore 已排除，不进公开仓库）：
|
||||
- `analysis/chatgpt-share-6abc3084.txt` —— 对话全文（238 条消息）
|
||||
- `analysis/unfixed-report.md` —— 121 条修复状态对账（含 A/B/C 三类判定与文件:行证据）
|
||||
- `analysis/findings.json` —— 报告项结构化数据（F001–F121）
|
||||
|
||||
已确立的前提：**「未修」不等于「是缺陷」**。
|
||||
|
||||
**判定已完成（2026-09-30）**：95 条逐条判定——采纳 70、部分成立 9、**驳回 11**、已修 5。判定表见
|
||||
`docs/audit/2026-09-30-adjudication.md`（提交 f532491），依据与改法以该表为准。
|
||||
|
||||
**驳回的 11 条（F022 / F034 / F035 / F036 / F047 / F052 / F069 / F072 / F080 / F110 / F111）
|
||||
严禁出现在任何 `fix:` 提交里**——改动它们等于把正确内容改错。Task 5 Step 1 与 Task 6 Step 1
|
||||
已按此改写作废步骤。各任务的「Consumes」栏引用的判定结论，以判定表中该条目的「改法」列为准；
|
||||
标「不改」的即跳过。
|
||||
|
||||
**并行协调：** 本计划任务**串行执行**（后一任务依赖前一任务 commit）；执行期间不得与其他计划交叉修改同一技能目录。文件集隔离见各任务 Files 清单。
|
||||
|
||||
## Global Constraints
|
||||
|
||||
- **红线 1 呈现中性**：禁用「最推荐」「强烈建议」等最高级强推措辞（最多「推荐」）
|
||||
- **红线 2 隐私脱敏**：内容不指向具体项目/公司/产品；本波源自一份对话记录，**改写时只保留技术结论，不得把对话里的措辞、引用标记（`filecite`/`cite` 残留）、模型署名带进技能**
|
||||
- **红线 3 不用 emoji**：文档与提交信息一律纯文本
|
||||
- **红线 4 事实核验**：每条改动必须附实测证据（PyPI/官方文档/源码/本地实跑命令与输出），禁止「按报告照改」。仓库历史上多处断言因想当然出错，本波尤其要求先证后改
|
||||
- **红线 5 授权边界**：内容边界不变，不因修 bug 引入新的绕过/破解类操作指引
|
||||
- **内容边界**：`.claude/skills/` 只写「是什么/怎么做」——**不写审查历史**（日期戳、finding 编号、progress 标记、`docs/audit/` 引用）。判定过程与编号一律留在 `docs/audit/`
|
||||
- **validate 约束**：frontmatter 的 `name`=目录名、`description` 非空且含 CJK+拉丁、`capabilities` 标签须在注册表内、正文 `[[链接]]` 必须解析（**先建文件再加链接**）
|
||||
- **commit 纪律**：每任务 commit 只 `git add` 本任务列出的文件，**严禁 `git add -A`**
|
||||
- 每任务收尾 `npm test` 必须输出 `OK: 122 skills validated` 且全绿；改动 `capabilities` 时先跑 `node bin/capindex.mjs`
|
||||
- 当前分支 `main`；本波**不改技能总数**（122）
|
||||
|
||||
---
|
||||
|
||||
### Task 1: 判定表（91 条未修项逐条实测）
|
||||
|
||||
**Files:**
|
||||
- Create: `docs/audit/2026-09-30-adjudication.md`（判定表）
|
||||
- Modify: `docs/audit/2026-09-13-factual-audit.md`（追加「补充 33：监控报告对账波——判定表」小节，指向判定表）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: `analysis/unfixed-report.md`（A/B/C 三类清单）、`analysis/findings.json`（F001–F121 原文）
|
||||
- Produces: 判定表——后续每个修复任务的输入；每条给出 `F 编号 | 目标文件:行 | 报告主张 | 实测证据 | 结论（采纳/驳回/部分采纳）| 改法`
|
||||
|
||||
- [ ] **Step 1: 逐条实测**
|
||||
|
||||
对 A 类（约 53 项）与 B 类（14 条）逐条取证。取证手段按类型：
|
||||
- 版本/依赖类 → 查官方元数据（`curl -sS https://pypi.org/pypi/<pkg>/json` 的 `info.version` 与 `requires_python`）；GitHub 发行用 `https://github.com/<owner>/<repo>/releases.atom`（API 有未认证限流）
|
||||
- 格式/常量类 → 官方规范、头文件（如 Apple `loader.h`、Linux `elf.h`）、工具源码，必要时本地编译/构造样本实跑
|
||||
- 命令/API 类 → 能用则本地实跑（`--help`、最小样例），不能实跑则注明依据来源
|
||||
- 判定规则同仓库既有做法：**报告主张逐条列出，逐条给反证或佐证**；证不成立即驳回，并写明「驳回也要有证据链」
|
||||
|
||||
- [ ] **Step 2: 落表并标注排序**
|
||||
|
||||
按目标技能聚合写入判定表；标注每条的结论与依赖（如「依赖 Task 2 的源侧结论」）。**C 类 3 条单列一节**，写明报告错在哪、仓库写法为何正确，供日后防止「照报告把正确内容改错」。
|
||||
|
||||
- [ ] **Step 3: 验证** — `node validate.mjs` → `OK: 122 skills validated`（判定表在 `docs/`，不影响技能结构）
|
||||
- [ ] **Step 4: Commit** — `docs: 监控报告对账判定表——91 条未修项逐条实测`
|
||||
- [ ] **Step 5: 用户确认（评审闸口）**
|
||||
|
||||
提交判定表摘要：采纳/驳回/部分采纳各多少条，其中拟驳回的条目与理由。**未获确认前不得进入 Task 2。**
|
||||
|
||||
### Task 2: rizin 安装矩阵收敛（源侧）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-radare2/SKILL.md`（定为 rizin 安装的**单一事实源**）
|
||||
- Modify: `.claude/skills/re-radare2/references/gotchas.md`（radare2 版本代际）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1 判定表中 rizin Debian 包状态与 r2 当前版本的实测结论
|
||||
- Produces: rizin 安装矩阵（Debian/Ubuntu、Kali、Arch、Fedora/RHEL 分列）+ r2 版本基线；Task 13 据此改写六个副本
|
||||
|
||||
- [ ] **Step 1: 定矩阵**
|
||||
|
||||
按判定表结论重写安装段：Debian/Ubuntu 用官方 release 二进制或 `rz-pm`（**删除无条件的 `apt install rizin`**）；Kali 可 apt；Arch `pacman -S`；Fedora/RHEL 按当前仓库实际情况；每类给出 `rizin -v` 验证。**不保留未经核实的版本门槛猜测**（如「Debian 13+」）。同处修正被报告指为过时的 Fedora 行。
|
||||
- [ ] **Step 2: 版本代际** — `references/gotchas.md` 的 r2 版本基线按实测更新，不写死 patch 号则改为「以官方 Releases Latest 为准」
|
||||
- [ ] **Step 3: 验证** — `node validate.mjs`；`npm test` 全绿
|
||||
- [ ] **Step 4: 回填** — `node bin/auditstate.mjs update re-radare2`
|
||||
- [ ] **Step 5: Commit** — `fix: re-radare2 定为 rizin 安装单一事实源 + r2 版本基线更新`
|
||||
|
||||
### Task 3: binwalk 安装矩阵收敛（源侧）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-fw-extract/SKILL.md`（定为 binwalk 安装的**单一事实源**）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1 判定表中 binwalk 上游当前形态（v2 Python 包 vs v3 Rust 端口）的实测结论
|
||||
- Produces: binwalk 安装段（含版本形态与验证命令）；Task 8 / Task 9 / Task 14 据此改写副本
|
||||
|
||||
- [ ] **Step 1: 定矩阵** — 按实测结论重写安装段，删除「pip 版版本新、跨平台（推荐）」这类未经核实的比较，写明当前推荐形态与 `binwalk --version` 验证方式
|
||||
- [ ] **Step 2: 验证** — `node validate.mjs`；`npm test` 全绿
|
||||
- [ ] **Step 3: 回填** — `node bin/auditstate.mjs update re-fw-extract`
|
||||
- [ ] **Step 4: Commit** — `fix: re-fw-extract 定为 binwalk 安装单一事实源`
|
||||
|
||||
### Task 4: 版本基线组（re-ghidra / re-angr / re-ai-model）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-ghidra/SKILL.md`
|
||||
- Modify: `.claude/skills/re-angr/SKILL.md` + `.claude/skills/re-angr/references/gotchas.md`
|
||||
- Modify: `.claude/skills/re-ai-model/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1 判定表（Ghidra 12.1.4 已发布、angr 10.0.0 / `>=3.12`、onnx 1.23）
|
||||
- Produces: 三处版本基线更新；re-angr 同时是 angr Python 矩阵的全库单一事实源
|
||||
|
||||
- [ ] **Step 1: re-ghidra** — 版本行改为按官方 Releases Latest 表述，不写死 patch 号（若确需 patch 号再写）；JDK 要求按判定表结论（12.2 未进入正式 Releases 前不改）
|
||||
- [ ] **Step 2: re-angr** — 主线版本与 Python 下限按实测更新；**同步检查**引用方 `re-crypto-decrypt` / `re-exploit` 是否已指向本技能（已指向，勿再复制矩阵）
|
||||
- [ ] **Step 3: re-ai-model** — onnx 版本与 Python 下限
|
||||
- [ ] **Step 4: 验证** — `node validate.mjs`；`npm test` 全绿
|
||||
- [ ] **Step 5: 回填** — `node bin/auditstate.mjs update re-ghidra re-angr re-ai-model`
|
||||
- [ ] **Step 6: Commit** — `fix: 版本基线——Ghidra / angr / onnx 三处按实测更新`
|
||||
|
||||
### Task 5: re-format-elf（字段语义组）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-format-elf/SKILL.md`
|
||||
- Modify: `.claude/skills/re-format-elf/references/layout.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1 判定表（ELF gABI 字段定义、glibc `dlopen` 对缺 `PT_GNU_STACK` 的实际行为、`DT_SYMENT` 的 ELF32/64 差异）
|
||||
- Produces: 修正后的字段表与步骤；**消除本技能内部的两处自相矛盾**
|
||||
|
||||
- [ ] **Step 1: `e_entry` 语义 — 已作废，不改**（判定表 F036/F047/F069/F110 驳回）
|
||||
|
||||
报告称「DYN 下为相对基址的偏移」是事实错误。实测反证：gABI ch5 定义 base address = 内存地址与文件
|
||||
虚拟地址之差，对 executable/shared object 是同一常量；Linux `fs/binfmt_elf.c:1245` 即
|
||||
`e_entry = elf_ex->e_entry + load_bias;`——DYN 下 `e_entry` 本就是相对 base 的值，仓库措辞与该模型
|
||||
一致，且从未称其为文件偏移/RVA。`p_vaddr` 行同理。**本步骤不执行任何修改**，仅保留此记录防止
|
||||
后续有人照报告把正确措辞改错。
|
||||
- [ ] **Step 2: `DT_SYMENT`** — 删除固定 24 字节的写法，按 ELFCLASS 分别给出（或写明以 `DT_SYMENT` 实际值为准）
|
||||
- [ ] **Step 3: `.fini_array` 定位** — `SKILL.md` 步骤 3 标题不再把 `.fini_array` 与 `.init_array` 并列为「main 之前执行」；与同文件坑项（fini 在退出清理阶段）对齐
|
||||
- [ ] **Step 4: Canary 判定** — 删除「符号表出现 `__stack_chk_fail` ⇒ 有 Canary」的等价关系，改为「存在引用 ⇒ 有带该保护的编译单元」，并说明与"该二进制启用了栈保护"的区别
|
||||
- [ ] **Step 5: `PT_GNU_STACK` 缺失** — `SKILL.md` 与 `references/layout.md` 两条表述统一到同一结论（缺失时的实际行为依 ABI/glibc 版本而异，不写成必然 `EINVAL`，也不写成必然可执行栈），按判定表实测结论落笔
|
||||
- [ ] **Step 6: 验证** — `node validate.mjs`；`npm test` 全绿
|
||||
- [ ] **Step 7: 回填** — `node bin/auditstate.mjs update re-format-elf`
|
||||
- [ ] **Step 8: Commit** — `fix: ELF 字段语义 4 项——DT_SYMENT / fini_array / Canary / PT_GNU_STACK`
|
||||
|
||||
### Task 6: re-format-macho（load command 组）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-format-macho/SKILL.md`
|
||||
- Modify: `.claude/skills/re-format-macho/references/layout.md` + `references/examples.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1 判定表（`LC_DYLD_INFO(_ONLY)` 的信息流条数、`cmdsize` 对齐规则）。注意 `LC_MAIN.entryoff` 一条已驳回，不在本任务范围
|
||||
- Produces: 修正后的入口定位与 dyld 信息表描述
|
||||
|
||||
- [ ] **Step 1: `LC_MAIN.entryoff` — 已作废，不改**（判定表 F034 驳回）
|
||||
|
||||
报告称语义与入口 VA 公式写错。实测反证：Apple `loader.h` 注释 `file (__TEXT) offset of main()`；
|
||||
dyld `common/MachOAnalyzer.cpp:627` 为 `startAddress = preferredLoadAddress() + mainCmd->entryoff`；
|
||||
本机用 `ld64.lld` 造 Mach-O 实测 `__TEXT.vmaddr=0x100000000`、`entryoff=0x330`、`_main=0x100000330`
|
||||
精确命中。仓库公式与 Apple 实现一致。**本步骤不执行任何修改**。
|
||||
- [ ] **Step 2: LC 最小长度** — 修正「64 位下 LC 最小 16 字节」的说法（按结构体实际对齐规则）
|
||||
- [ ] **Step 3: `LC_DYLD_INFO(_ONLY)`** — 补 `weak_bind`，删除「四张表」的计数表述；同步 `references/layout.md` 的三处
|
||||
- [ ] **Step 4: 验证** — `node validate.mjs`；`npm test` 全绿
|
||||
- [ ] **Step 5: 回填** — `node bin/auditstate.mjs update re-format-macho`
|
||||
- [ ] **Step 6: Commit** — `fix: Mach-O load command 2 项——LC 最小长度 / LC_DYLD_INFO 信息流`
|
||||
|
||||
### Task 7: 格式判定组（re-format-pe / re-cpp-abi / re-unpack-simple / re-triage）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-format-pe/SKILL.md`
|
||||
- Modify: `.claude/skills/re-cpp-abi/SKILL.md`
|
||||
- Modify: `.claude/skills/re-unpack-simple/SKILL.md`
|
||||
- Modify: `.claude/skills/re-triage/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1 判定表（Delphi VMT 布局版本差异、Itanium RTTI 布局、PE `CheckSum` 的加载期作用、`DF_1_PIE` 判据）
|
||||
- Produces: 四技能的判定规则修正
|
||||
|
||||
- [ ] **Step 1: re-format-pe** — Delphi VMT 负偏移表按版本分开（经典 vs XE2+），或改为「以自指指针双向校验为主、偏移仅作候选」；「死导入检测」不再由「IAT 项未被 `.text` 直接引用」单向推导动态解析，改为列出多因并给出区分判据
|
||||
- [ ] **Step 2: re-cpp-abi** — `std::type_info` 布局不写死位宽；lambda closure type 的 RTTI 表述改为「按需发射」，明确「缺 `_ZTI` 不能排除 lambda」，并与步骤 5、坑项两处对齐
|
||||
- [ ] **Step 3: re-unpack-simple** — 把 `CheckSum` 从「与 `SizeOfImage`/`NumberOfSections` 并列的加载失败原因」中拆出，写明各自的实际作用域
|
||||
- [ ] **Step 4: re-triage** — PIE 判定补 `DF_1_PIE`（`readelf -d`）判据，删除「`ET_DYN` = PIE」的直接映射
|
||||
- [ ] **Step 5: 验证** — `node validate.mjs`；`npm test` 全绿
|
||||
- [ ] **Step 6: 回填** — `node bin/auditstate.mjs update re-format-pe re-cpp-abi re-unpack-simple re-triage`
|
||||
- [ ] **Step 7: Commit** — `fix: 格式判定 4 技能——Delphi VMT / RTTI 与 lambda / PE CheckSum / PIE 判据`
|
||||
|
||||
### Task 8: CPU/ISA 组（re-arm / re-mips / re-riscv / re-console / re-tee）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-arm/SKILL.md`
|
||||
- Modify: `.claude/skills/re-mips/SKILL.md`
|
||||
- Modify: `.claude/skills/re-riscv/SKILL.md`
|
||||
- Modify: `.claude/skills/re-console/SKILL.md`
|
||||
- Modify: `.claude/skills/re-tee/references/gotchas.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1 判定表（Armv6-M 实际指令集、AAPCS32/64 的 Thumb 位规则、MIPS Branch Likely 的 annul 语义、RISC-V binutils 包名、SM83 ISA、SMCCC 调用约定）。**RISC-V 入口定位一条已驳回，不在本任务范围**、Task 3 的 binwalk 源侧结论
|
||||
- Produces: 五处 ISA/ABI 判定修正；re-arm / re-mips / re-console 的 binwalk 副本指回 `[[re-fw-extract]]`
|
||||
|
||||
- [ ] **Step 1: re-arm** — 删除「Cortex-M0/M0+ 只有 16 位 Thumb」及「32 位指令是反汇编幻觉」的表述，按 Armv6-M 实际指令集改写（三处：变体说明、BL 距离、坑项）；虚表函数指针的 Thumb 位规则限定到 AArch32 并写明 AAPCS64 下的差异（两处）
|
||||
- [ ] **Step 2: re-mips** — 延迟槽不再写成「无条件执行」，补 Branch Likely 的 annul/nullify 语义（步骤 + 坑项两处）
|
||||
- [ ] **Step 3: re-riscv** — 只改一处：binutils 安装与验证命令一一对应（装 `binutils-riscv64-linux-gnu` 就验 `riscv64-linux-gnu-objdump`；需要裸机 triplet 则单列 `binutils-riscv64-unknown-elf`）。**入口定位那句不改**——判定表 F052 驳回：该句本身已写「动态链接程序先经 ld.so（PT_INTERP）」，`gdb starti /bin/ls` 实测首条指令确在 ld.so
|
||||
- [ ] **Step 4: re-console** — SM83 不再描述成 Z80 变体，删除「用 Z80 近似」的默认路径，改为专用 SM83 language/loader 或明确标注近似；与同文件坑项对齐
|
||||
- [ ] **Step 5: re-tee** — `HVC`/`SMC` 不再简化成「EL2 用 HVC、EL3 用 SMC」，按调用者 EL 与目标 EL 拆开（并检查 x1–x17 的 SMCCC 版本限定）
|
||||
- [ ] **Step 6: binwalk 副本** — re-arm / re-mips / re-console 三处改写为引用 `[[re-fw-extract]]` 的安装矩阵，删除各自复制的 `pip install binwalk` 比较性描述
|
||||
- [ ] **Step 7: 验证** — `node validate.mjs`；`npm test` 全绿
|
||||
- [ ] **Step 8: 回填** — `node bin/auditstate.mjs update re-arm re-mips re-riscv re-console re-tee`
|
||||
- [ ] **Step 9: Commit** — `fix: CPU/ISA 判定 5 技能——Armv6-M / Thumb 位 / MIPS 延迟槽 / RISC-V binutils / SM83 / SMCCC`
|
||||
|
||||
### Task 9: 调用约定组（re-shellcode / re-pwn）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-shellcode/SKILL.md`
|
||||
- Modify: `.claude/skills/re-pwn/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1 判定表（x86-64 SysV 栈对齐的准确条件、`%N$` 参数槽语义、Windows x86 调用约定现状）、Task 3 的 binwalk 源侧结论
|
||||
- Produces: 三处调用约定/栈布局修正
|
||||
|
||||
- [ ] **Step 1: re-shellcode** — 删除「Win32 默认 stdcall」的概括，按实际（编译器/调用约定声明）改写；binwalk 副本指回 `[[re-fw-extract]]`
|
||||
- [ ] **Step 2: re-exploit — 栈对齐不改**（判定表 F111 驳回）。仓库「`call` 时 `$rsp % 16 == 0`」与 psABI 原文 "immediately before the call instruction is executed" 逐字对应；探针实测 `call printf` 前 `rsp%16==0` 正常、`==8` 触发 `movaps` SIGSEGV，`ret` 转移场景同样成立。本技能本波**无改动项**
|
||||
- [ ] **Step 3: re-pwn** — `%N$...` 的参数槽描述改为「第 N 个位置参数（前若干走寄存器）」，删除自相矛盾的注释；**pwntools 版本保持现状**（判定表已驳回，勿改）
|
||||
- [ ] **Step 4: 验证** — `node validate.mjs`；`npm test` 全绿
|
||||
- [ ] **Step 5: 回填** — `node bin/auditstate.mjs update re-shellcode re-pwn`
|
||||
- [ ] **Step 6: Commit** — `fix: 调用约定 2 技能——stdcall / printf 参数槽`
|
||||
|
||||
### Task 10: Frida 组（re-frida / re-frida-script-author）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-frida/SKILL.md`
|
||||
- Modify: `.claude/skills/re-frida/references/frida-scripts.md`（如涉及）
|
||||
- Modify: `.claude/skills/re-frida-script-author/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1 判定表（Objection 当前 CLI 形态、Frida host 与 frida-server 的实际兼容规则、Frida 17 Java bridge 的实际情况）
|
||||
- Produces: Frida 工具链用法与版本兼容表述修正
|
||||
|
||||
- [ ] **Step 1: Objection** — 启动命令按当前版本更新（两处）；安装说明补 Python 下限或指向官方要求
|
||||
- [ ] **Step 2: 版本兼容** — 删除「host 与 frida-server 版本必须完全一致」，按实际的兼容规则（major 一致 + 官方兼容矩阵）改写，协议错误不再单一归因版本号
|
||||
- [ ] **Step 3: Java bridge** — 修正 Frida 17 后 Java bridge 的获取方式描述
|
||||
- [ ] **Step 4: re-frida-script-author** — 删除/限定发行版包管理器作为 Frida CLI 等价安装方式的表述（注明非 upstream 渠道）
|
||||
- [ ] **Step 5: 验证** — `node validate.mjs`；`npm test` 全绿
|
||||
- [ ] **Step 6: 回填** — `node bin/auditstate.mjs update re-frida re-frida-script-author`
|
||||
- [ ] **Step 7: Commit** — `fix: Frida 工具链 2 技能——Objection / 版本兼容 / Java bridge / 安装渠道`
|
||||
|
||||
### Task 11: iOS 组（re-ios / re-ios-jb）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-ios/SKILL.md`
|
||||
- Modify: `.claude/skills/re-ios/references/gotchas.md` + `references/commands.md`
|
||||
- Modify: `.claude/skills/re-ios-jb/SKILL.md`（引用点同步）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1 判定表（FairPlay 解密方案的当前实践、越狱工具与 iOS 版本对应关系）
|
||||
- Produces: 脱壳路径改写 + 越狱矩阵更新
|
||||
|
||||
- [ ] **Step 1: 脱壳路径** — 原版 `frida-ios-dump` 从默认工具准备路径降级为 legacy/参考实现（写明所需 Frida 世代），默认流程改为按目标 iOS/jailbreak 选择当前适配的维护实现；删除「clone → pip install → 直接运行」的当前安装路径。**与 Task 10 的 Frida 版本结论保持一致**
|
||||
- [ ] **Step 2: 越狱矩阵** — `references/gotchas.md` 的 unc0ver 版本范围按当前实际更新
|
||||
- [ ] **Step 3: 引用点同步** — `re-ios-jb/SKILL.md` 中指向脱壳步骤的三处同步；`references/commands.md` 的工具族说明同步
|
||||
- [ ] **Step 4: 验证** — `node validate.mjs`；`npm test` 全绿
|
||||
- [ ] **Step 5: 回填** — `node bin/auditstate.mjs update re-ios re-ios-jb`
|
||||
- [ ] **Step 6: Commit** — `fix: iOS 脱壳路径与越狱矩阵 2 技能`
|
||||
|
||||
### Task 12: 工具用法组（re-ida / re-gdb / re-patching / re-binaryninja）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-ida/SKILL.md` + `references/commands.md`
|
||||
- Modify: `.claude/skills/re-gdb/SKILL.md`
|
||||
- Modify: `.claude/skills/re-patching/SKILL.md`
|
||||
- Modify: `.claude/skills/re-binaryninja/SKILL.md` + `references/gotchas.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1 判定表（IDA 无头可执行文件名、Pwndbg 当前安装方式、`pesign` 的删除签名用法、Binary Ninja 当前主版本与其 Python/扩展系统变化）
|
||||
- Produces: 四处工具用法修正；re-ida 的传播面（`re-plugin-dev` / `re-deobfuscate` / `re-license`）以引用方式收敛
|
||||
|
||||
- [ ] **Step 1: re-ida** — 无头模式命令按实际可执行文件名与参数改写；**传播面**：`re-plugin-dev`、`re-deobfuscate`、`re-license` 三处不再各自复制命令，改为引用 `[[re-ida]]`
|
||||
- [ ] **Step 2: re-gdb** — Pwndbg 安装方式按当前官方推荐更新；`re-pwn` 的引用说明同步（**注意与 Task 9 的文件集边界：`re-pwn/SKILL.md` 归 Task 9，本任务只改 `re-gdb`**，如需改 re-pwn 则在 Task 9 完成后再单独提一条修正）
|
||||
- [ ] **Step 3: re-patching** — `pesign` 删除签名的正确用法
|
||||
- [ ] **Step 4: re-binaryninja** — 版本说明按当前主版本与其 Python/扩展系统变化更新
|
||||
- [ ] **Step 5: 验证** — `node validate.mjs`；`npm test` 全绿
|
||||
- [ ] **Step 6: 回填** — `node bin/auditstate.mjs update re-ida re-gdb re-patching re-binaryninja`
|
||||
- [ ] **Step 7: Commit** — `fix: 工具用法 4 技能——IDA 无头 / Pwndbg / pesign / Binary Ninja`
|
||||
|
||||
### Task 13: rizin 副本同步组（re-deobfuscate / re-unpack-advanced / re-variant / re-license / re-imports）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-deobfuscate/SKILL.md`
|
||||
- Modify: `.claude/skills/re-unpack-advanced/SKILL.md`
|
||||
- Modify: `.claude/skills/re-variant/SKILL.md`
|
||||
- Modify: `.claude/skills/re-license/SKILL.md`
|
||||
- Modify: `.claude/skills/re-imports/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: **Task 2 的 rizin 安装矩阵**（本任务不得自行发明发行版结论）
|
||||
- Produces: 五个副本收敛为引用 `[[re-radare2]]`；同仓库对 rizin 安装的结论归一
|
||||
|
||||
- [ ] **Step 1: 逐个改写** — 删除本地复制的 `apt install rizin` 矩阵，改为引用 `[[re-radare2]]` 的安装矩阵；`re-license` 作为替代工具入口的说明同步
|
||||
- [ ] **Step 2: re-deobfuscate 的绑定** — 同一文件内 Rizin 自动化驱动改用 Rizin 侧绑定（`rzpipe`），删除 `r2pipe` 作为 Rizin 驱动方式的表述（三处）
|
||||
- [ ] **Step 3: 验证** — `grep -rn "apt install rizin" .claude/skills/` 应只剩 `re-radare2` 内的说明性提及；`npm test` 全绿
|
||||
- [ ] **Step 4: 回填** — `node bin/auditstate.mjs update re-deobfuscate re-unpack-advanced re-variant re-license re-imports`
|
||||
- [ ] **Step 5: Commit** — `fix: rizin 安装五处副本收敛到 re-radare2 单一事实源`
|
||||
|
||||
### Task 14: 取证与固件组（re-rtos / re-packer-id / re-memdump / re-mem-forensics / re-fw-emulate / re-dotnet）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-rtos/SKILL.md`
|
||||
- Modify: `.claude/skills/re-packer-id/SKILL.md`
|
||||
- Modify: `.claude/skills/re-memdump/SKILL.md`
|
||||
- Modify: `.claude/skills/re-mem-forensics/SKILL.md`
|
||||
- Modify: `.claude/skills/re-fw-rootfs/SKILL.md`（同源 p7zip 行）
|
||||
- Modify: `.claude/skills/re-fw-emulate/references/gotchas.md`
|
||||
- Modify: `.claude/skills/re-dotnet/SKILL.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1 判定表（gcore 的适用边界、Volatility 2 的归档状态、qemu-system 的默认网络行为、Arch 包名现状）、Task 3 的 binwalk 源侧结论
|
||||
- Produces: 六处取证/仿真类修正
|
||||
|
||||
- [ ] **Step 1: re-rtos / re-packer-id** — binwalk 副本指回 `[[re-fw-extract]]`
|
||||
- [ ] **Step 2: re-memdump** — 默认转储方式改为符合平台经验的方案（gcore 的适用边界写明），传播面（`re-analyze/references/platform-tips.md`、`re-forensics`、`re-loader`）一并核对；Volatility 2 标注为已归档的兼容分支而非等价「按需」选项
|
||||
- [ ] **Step 3: re-mem-forensics / re-fw-rootfs** — 7-Zip 包名按当前发行版现状（两处同源行一并处理）
|
||||
- [ ] **Step 4: re-fw-emulate** — 删除「qemu-system 默认 `-net none`」的前提，改为按实际默认行为给隔离建议
|
||||
- [ ] **Step 5: re-dotnet** — Arch 的 Mono 安装说明按当前官方仓库状态
|
||||
- [ ] **Step 6: 验证** — `node validate.mjs`；`npm test` 全绿
|
||||
- [ ] **Step 7: 回填** — `node bin/auditstate.mjs update re-rtos re-packer-id re-memdump re-mem-forensics re-fw-emulate re-dotnet`
|
||||
- [ ] **Step 8: Commit** — `fix: 取证与仿真 6 技能——转储方式 / Volatility 2 / 包名 / qemu 网络 / Mono`
|
||||
|
||||
### Task 15: 协议与加密组（re-tls / re-proto-rev / re-crypto-decrypt / re-crypto-id / re-apk）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-tls/SKILL.md`
|
||||
- Modify: `.claude/skills/re-proto-rev/SKILL.md`
|
||||
- Modify: `.claude/skills/re-crypto-decrypt/SKILL.md`
|
||||
- Modify: `.claude/skills/re-crypto-id/SKILL.md`
|
||||
- Modify: `.claude/skills/re-apk/references/gotchas.md` + `references/commands.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1 判定表（TLS 1.3 的 ALPN 落点、TCP 字节流与应用层消息的边界、JPEG/PNG 结束标记的实际行为、分组/流密码的可区分特征、zipalign 与签名方案的当前关系）
|
||||
- Produces: 五处协议/加密判定修正
|
||||
|
||||
- [ ] **Step 1: re-tls** — ALPN 最终协商结果的落点按 RFC 改写（TLS 1.3 与 1.2 分开表述）
|
||||
- [ ] **Step 2: re-proto-rev** — 流程中补 TCP 流重组与应用层 framing 阶段，不再把 segment payload 当 message（步骤与示例同步）
|
||||
- [ ] **Step 3: re-crypto-decrypt** — 结束标记的取法改为按格式规范（JPEG 需处理嵌入缩略图等情形），删除「第一个 vs 最后一个」的简化断言；`re-fw-extract` 内的同源表述一并核对（**注意文件集：如需改 `re-fw-extract` 则在 Task 3 已完成的基础上追加，勿与其他任务并发**）
|
||||
- [ ] **Step 4: re-crypto-id** — 删除「按分组对齐区分分组/流密码」的决策规则，改为多判据并列（并说明反例）
|
||||
- [ ] **Step 5: re-apk** — zipalign 与 v1/v2/v3 的关系按当前构建工具链实际行为改写（两处）
|
||||
- [ ] **Step 6: 验证** — `node validate.mjs`；`npm test` 全绿
|
||||
- [ ] **Step 7: 回填** — `node bin/auditstate.mjs update re-tls re-proto-rev re-crypto-decrypt re-crypto-id re-apk`
|
||||
- [ ] **Step 8: Commit** — `fix: 协议与加密 5 技能——ALPN / TCP 重组 / 结束标记 / 密码分组 / zipalign`
|
||||
|
||||
### Task 16: 杂项组（re-go / re-android-native / re-ebpf / re-automotive / re-emulation）
|
||||
|
||||
**Files:**
|
||||
- Modify: `.claude/skills/re-go/SKILL.md`
|
||||
- Modify: `.claude/skills/re-android-native/SKILL.md` + `references/probes.md`
|
||||
- Modify: `.claude/skills/re-ebpf/SKILL.md`
|
||||
- Modify: `.claude/skills/re-automotive/SKILL.md`
|
||||
- Modify: `.claude/skills/re-emulation/references/gotchas.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1 判定表（`LD_PRELOAD` 对 Go 程序的实际边界、`crypto/cipher.NewGCM` 的参数语义、JNI 函数表的规范布局、eBPF helper 号的稳定性、UDS 下载流程的实际状态机形态、Capstone 当前版本形态）
|
||||
- Produces: 五处修正；**消除 re-android-native 的槽位自相矛盾**
|
||||
|
||||
- [ ] **Step 1: re-go** — `LD_PRELOAD` 条目按实际边界改写（Go 静态链接与否、`cgo` 参与时的差异），不再绝对化；加密密钥定位不再把 `NewGCM` 的第一个参数当 AES 密钥
|
||||
- [ ] **Step 2: re-android-native** — `RegisterNatives` 等槽位按 JNI 规范的固定布局表述（写明 index 与「byte offset = index × 指针宽度」的换算），删除「槽号随 jni.h/NDK/ART 漂移」的建模；`references/probes.md` 的探测策略相应改为「确认 `JNIEnv*` 有效性 / hook 表检测 / 非标准实现」，与 `references/experience.md` 已写死的槽位值对齐
|
||||
- [ ] **Step 3: re-ebpf** — helper 号的稳定性按规范改写（枚举为追加式，不以"漂移"描述），保留「以内核源码为准」的核对建议
|
||||
- [ ] **Step 4: re-automotive** — UDS 下载流程不再写成固定四步序列，按实际可选路径（含 `0x31`/`0x37` 的变体）表述。**udsoncan 示例保持现状**（判定表已驳回，勿改）
|
||||
- [ ] **Step 5: re-emulation — 不改**（判定表 F080 驳回）。PyPI 稳定版仍是 5.0.9，6.x 仅有 `6.0.0a1–a11` 预发行，仓库「当前 5.0.x」准确。6.0.0 正式发行后再复核
|
||||
- [ ] **Step 6: 验证** — `node validate.mjs`；`npm test` 全绿
|
||||
- [ ] **Step 7: 回填** — `node bin/auditstate.mjs update re-go re-android-native re-ebpf re-automotive re-emulation`
|
||||
- [ ] **Step 8: Commit** — `fix: 杂项 4 技能——LD_PRELOAD / JNI 槽位 / eBPF helper / UDS 流程`
|
||||
|
||||
### Task 17: 运行时基线（Node）
|
||||
|
||||
**Files:**
|
||||
- Modify: `package.json`（`engines.node`）
|
||||
- Modify: `CLAUDE.md`
|
||||
- Modify: `bin/wxsource.mjs`（注释中的版本表述）
|
||||
- Modify: 其余 `>=18` 表述所在文件（先 `grep -rn ">=18" --include="*.md" --include="*.json" --include="*.mjs" .` 确认全集；`docs/superpowers/`、`analysis/` 为存档/本地产物，不改）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1 判定表（当前受支持 LTS 与 EOL 版本表）
|
||||
- Produces: 全库运行时基线统一
|
||||
|
||||
- [ ] **Step 1: 定基线** — 按判定表结论提升 `engines.node`；同步文档表述与安装器/CI 的前置检查（如存在）
|
||||
- [ ] **Step 2: 一致性** — `grep` 确认无残留旧基线；确认无代码依赖新基线以下版本才有的特性说明
|
||||
- [ ] **Step 3: 验证** — `npm test` 全绿（本机 Node 版本需满足新基线）
|
||||
- [ ] **Step 4: Commit** — `chore: 运行时基线提升——engines.node 与文档同步`
|
||||
|
||||
### Task 18: 终审波（断言 + 回填 + 审查记录）
|
||||
|
||||
**Files:**
|
||||
- Modify: `tests/audit-regressions.test.mjs`（新增本波回归断言）
|
||||
- Modify: `docs/audit/review-state.json`（Task 2-17 未回填项补齐）
|
||||
- Modify: `docs/audit/2026-09-13-factual-audit.md`（追加「补充 34：监控报告对账波——落地与固化」）
|
||||
- Modify: `docs/audit/tool-register.json`（如本波涉及工具的使用点/核验状态变化，跑 `node bin/toollife.mjs check` 后同步）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 2-17 全部完成
|
||||
- Produces: 回归断言、审查记录、状态回填闭环
|
||||
|
||||
- [ ] **Step 1: 补回归断言**
|
||||
|
||||
按仓库既有 `absent` / `present` 助手（注意 `NEGATION` 词表——迁移说明会刻意写出旧写法）为本波每条采纳项加断言：错的说法不得写回、修正后的表述必须在位。**每条断言注释里写明对应的判定表条目**（不含日期戳进技能内容，注释在测试文件内不受「技能不写审查历史」约束）。
|
||||
- [ ] **Step 2: 变异测试** — 抽查 3-5 条：把技能写回旧表述，断言应精准失败；还原后全过（仓库既有做法，防止断言空转）
|
||||
- [ ] **Step 3: 全库审查** — `node validate.mjs` → `OK: 122 skills validated`；`node bin/capindex.mjs --check`；`node bin/toollife.mjs check`；`node bin/probelist.mjs --check`；`npm test` 全绿
|
||||
|
||||
顺带修正一处既有计数漂移：`CLAUDE.md:45` 写「`npm test` = validate + **103** 项测试」，实际为 132 项（`tests/counts.test.mjs` 覆盖了技能计数但未覆盖测试计数）。改为实际值，并按仓库「把约定变成检查」的做法把该计数纳入 `counts.test.mjs`。
|
||||
- [ ] **Step 4: 红线对照** — 抽查本波改动文件：无强推措辞、无对话残留（`filecite`、模型署名、日期戳、finding 编号）、无 emoji
|
||||
- [ ] **Step 5: 回填与记录** — `node bin/auditstate.mjs status` 确认无遗漏；审查记录追加到 `docs/audit/`
|
||||
- [ ] **Step 6: Commit** — `fix: 审查修复波——监控报告对账落地（回归断言 + 记录固化）`
|
||||
|
||||
---
|
||||
|
||||
**最终验证**：`node validate.mjs` → `OK: 122 skills validated`；`npm test` 全绿（现有 103 项 + 本波新增断言）；`git log` 含本计划全部任务 commit；`node bin/auditstate.mjs status` 显示本波技能均为「已复核未变」。
|
||||
|
||||
**收尾提醒**：C 类 3 条（udsoncan `ClientConfig`、pwntools 4.15.0、Capstone 6）**不得**出现在任何 `fix:` 提交里——判定表已给出驳回证据，改动它们属于把正确内容改错。回归断言中应包含「这些正确表述不得被改错」的守护项（参照既有补充 30 的做法）。
|
||||
@@ -0,0 +1,412 @@
|
||||
# DSH 预设就地化实施计划
|
||||
|
||||
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
|
||||
|
||||
**Goal:** 把 rev-skills 的 DSH 独立预设从「仓库内第二个 npm 包（`dsh/`）」改为「根包自带的 bundle 声明（`dsh.patch.yml`）」，删掉重复包壳与随之而来的同步点，预设行为不变。
|
||||
|
||||
**Architecture:** DSH 的 bundle = 任意 npm 包 + manifest 里的 `dsh.bundle.patch`，profile 的 `dsh.profile.bundles` 填**包名**。因此根包 `rev-skills` 自己就能当 bundle：新增一个仓库根的补丁文件，在根 `package.json` 声明它并列入 `files`，删掉 `dsh/` 整个目录，`bin/dsh.mjs` 只改两个常量。
|
||||
|
||||
**Tech Stack:** 零依赖 Node.js ESM（>=22）、`node --test`、DSH 0.2.0-rc.2（本机 `/home/DslsDZC/.npm-global/bin/dsh`）。
|
||||
|
||||
## Global Constraints
|
||||
|
||||
- 分支：`dsh-preset`（跟踪 `dnfme/feat/dsh-preset`，PR #5 就地更新）
|
||||
- commit message 中文，前缀 `feat:` / `fix:` / `chore:` / `docs:` / `enhance:` / `经验:`
|
||||
- **每个 commit 只 `git add` 本任务 Files 列出的文件，严禁 `git add -A`**
|
||||
- 呈现中性（禁用「最推荐」「强烈建议」等最高级强推措辞）；不用 emoji
|
||||
- 不改 `.claude/skills/` 下任何技能内容；不动 PR 中无关改动（`.gitattributes`、`lib/frontmatter.mjs`、`bin/install.mjs` 的 `--target dsh`）
|
||||
- 保留 `bin/dsh.mjs` 的四个 `preset` 子命令
|
||||
- 任一任务结束时 `node validate.mjs` 必须输出 `OK: 122 skills validated`，`npm test` 必须全绿
|
||||
- `dsh.bundle.patch` 指向的文件**必须**出现在根 `package.json` 的 `files` 里（实测：漏列时 pnpm `file:` 安装被拒 `failed to read overlay … ENOENT` 并整体回滚）
|
||||
- CLAUDE.md 的测试计数与实际顶层 `test(` 数一致（`tests/counts.test.mjs` 强制），增删测试必须在同一 commit 更新
|
||||
|
||||
---
|
||||
|
||||
### Task 1: 补丁就地化（文件迁移 + manifest 声明 + 常量 + 守卫测试）
|
||||
|
||||
**Files:**
|
||||
- Create: `dsh.patch.yml`（由 `dsh/cordis.patch.yml` 移动并改写）
|
||||
- Delete: `dsh/package.json`、`dsh/LICENSE`、`dsh/README.md`
|
||||
- Modify: `package.json`（新增 `dsh` 字段，`files` 换条目）
|
||||
- Modify: `bin/dsh.mjs:29-33`（两个常量）、`bin/dsh.mjs:425`（候选说明文案）、`bin/dsh.mjs:~430`（`仓库技能根` 候选的括号说明）
|
||||
- Modify: `tests/dsh-preset.test.mjs:13-15`（路径常量）、`216-246`（manifest 与 LICENSE 守卫）、`293`（候选断言）、`335-350`（包解析夹具）、测试计数相关
|
||||
- Modify: `tests/dsh.test.mjs:148`、`397`
|
||||
|
||||
**Interfaces:**
|
||||
- Produces: `bin/dsh.mjs` 导出的 `BUNDLE_DIR` 语义变为「仓库根（即 bundle 包目录）」，`BUNDLE_PACKAGE` 变为 `'rev-skills'`；后续任务与文档全部按这两个值书写
|
||||
- Consumes: 无
|
||||
|
||||
- [ ] **Step 1: 移动补丁文件到仓库根并改写头部注释**
|
||||
|
||||
```bash
|
||||
git mv dsh/cordis.patch.yml dsh.patch.yml
|
||||
```
|
||||
|
||||
把 `dsh.patch.yml` 开头到 `- insert:` 之前的注释块整体替换为：
|
||||
|
||||
```yaml
|
||||
# rev-skills 的 DSH bundle 补丁：本仓库根包（rev-skills）自身即 bundle，根
|
||||
# package.json 用 `"dsh": { "bundle": { "patch": "./dsh.patch.yml" } }` 指向本文件。
|
||||
# 顶层一条 `- insert:` 行声明独立 agent preset `rev-skills`，其子条目对齐官方
|
||||
# `cordis` 预设（去掉 Cordis 编写相关的行与 plan mode）。
|
||||
# `skill-filesystem` 行设置 `includeDefaultRoots: false`，该 preset 贡献的是 rev-skills
|
||||
# 技能根这一层，不继承项目与用户技能根；技能目录解析仍会把该层与查看作用域的项目/
|
||||
# 用户根合并：同名条目以本 preset 层为准，其他 preset 不受影响。
|
||||
# 技能根部进包内副本：`customSkillDirs` 表达式按顺序探测 `REV_SKILLS_DIR`（指向仓库根
|
||||
# 或直接指向技能目录）、DSH 用户技能根（`$DSH_HOME/skills`，默认 `~/.dsh/skills`）、
|
||||
# 本包目录（`rev-skills/package.json` 反解），取第一个存在且至少含一个 `re-*` 条目的候选。
|
||||
```
|
||||
|
||||
- [ ] **Step 2: 从 `customSkillDirs` 表达式删掉最后一个候选**
|
||||
|
||||
把该行末尾的候选数组由：
|
||||
|
||||
```
|
||||
const c = [tj(process.env.REV_SKILLS_DIR), process.env.REV_SKILLS_DIR, hd(), tj(pj('rev-skills/package.json')), tj(pt.join(pj('rev-skills-dsh-preset/package.json'), '..'))].filter((d) => d);
|
||||
```
|
||||
|
||||
改为（删掉 `rev-skills-dsh-preset` 那项；原第 3 候选即本包自身）：
|
||||
|
||||
```
|
||||
const c = [tj(process.env.REV_SKILLS_DIR), process.env.REV_SKILLS_DIR, hd(), tj(pj('rev-skills/package.json'))].filter((d) => d);
|
||||
```
|
||||
|
||||
- [ ] **Step 3: 根 `package.json` 声明 bundle 并换 `files` 条目**
|
||||
|
||||
`files` 数组里 `"dsh"` 换成 `"dsh.patch.yml"`；在 `"bin"` 块之后新增：
|
||||
|
||||
```json
|
||||
"dsh": {
|
||||
"bundle": {
|
||||
"patch": "./dsh.patch.yml"
|
||||
}
|
||||
},
|
||||
```
|
||||
|
||||
- [ ] **Step 4: 删掉包壳文件**
|
||||
|
||||
```bash
|
||||
git rm dsh/package.json dsh/LICENSE dsh/README.md
|
||||
```
|
||||
|
||||
（`dsh/README.md` 的面向 DSH 侧说明在 Task 3 并入 `docs/dsh-integration.md`，本步骤先记下其内容要点：bundle 安装方式、预设清单、技能根解析顺序。）
|
||||
|
||||
- [ ] **Step 5: 改 `bin/dsh.mjs` 的两个常量**
|
||||
|
||||
```js
|
||||
export const BUNDLE_DIR = REPO_ROOT;
|
||||
export const BUNDLE_PACKAGE = 'rev-skills';
|
||||
```
|
||||
|
||||
- [ ] **Step 6: 改 `bin/dsh.mjs` 的两处说明文案**
|
||||
|
||||
`resolveLocalSkillRoot` 里：
|
||||
|
||||
```js
|
||||
add('仓库技能根 <repo>/.claude/skills（补丁里由包解析得到）', join(repoRoot, '.claude', 'skills'));
|
||||
candidates.push({ source: '从 rev-skills 的 package.json 反解（本包即 bundle）', root: null, exists: null, skills: null, resolvable: false });
|
||||
```
|
||||
|
||||
- [ ] **Step 7: 同步 `tests/dsh-preset.test.mjs` 的路径常量**
|
||||
|
||||
```js
|
||||
const DSH_DIR = fileURLToPath(new URL('../', import.meta.url));
|
||||
const PACKAGE_FILE = join(DSH_DIR, 'package.json');
|
||||
const PATCH_FILE = join(DSH_DIR, 'dsh.patch.yml');
|
||||
```
|
||||
|
||||
- [ ] **Step 8: 改写 `tests/dsh-preset.test.mjs` 的 bundle 清单守卫**
|
||||
|
||||
把 `test('dsh/package.json 是合法 bundle 清单', …)` 整个替换为：
|
||||
|
||||
```js
|
||||
test('根 package.json 是合法 bundle 清单', () => {
|
||||
const pkg = JSON.parse(readFileSync(PACKAGE_FILE, 'utf8'));
|
||||
assert.equal(pkg.name, 'rev-skills');
|
||||
assert.match(pkg.version, /^\d+\.\d+\.\d+/);
|
||||
assert.match(pkg.license, /Apache-2\.0/, 'bundle 随根包发布，许可证沿用根包');
|
||||
assert.equal(pkg.type, 'module');
|
||||
const rel = pkg.dsh?.bundle?.patch;
|
||||
assert.equal(typeof rel, 'string', 'dsh.bundle.patch 必须存在');
|
||||
const abs = join(DSH_DIR, rel);
|
||||
assert.ok(existsSync(abs), `dsh.bundle.patch 指向不存在的文件：${rel}`);
|
||||
assert.ok(abs.startsWith(DSH_DIR), 'dsh.bundle.patch 必须落在仓库内');
|
||||
assert.ok(Array.isArray(pkg.files) && pkg.files.length > 0);
|
||||
for (const f of pkg.files) {
|
||||
assert.ok(existsSync(join(DSH_DIR, f)), `files 里列了未随包发布的文件：${f}`);
|
||||
}
|
||||
});
|
||||
```
|
||||
|
||||
（删掉了原断言里对 `dependencies === undefined` 与 `main`/`exports`/`bin` 三项为空的检查：那是「包壳不得指向未发布文件」的守卫，根包本来就有 `bin`。`dependencies` 为空由 Task 2 单独守卫。）
|
||||
|
||||
- [ ] **Step 9: 把 LICENSE 守卫改指根 LICENSE**
|
||||
|
||||
把 `test('dsh/LICENSE 是仓库根 LICENSE 的 Apache-2.0 正文', …)` 整个替换为：
|
||||
|
||||
```js
|
||||
test('根 LICENSE 是 Apache-2.0 全文，供随包发布的补丁使用', () => {
|
||||
const license = readFileSync(join(DSH_DIR, 'LICENSE'), 'utf8');
|
||||
assert.ok(license.includes('Apache License'), 'LICENSE 应含 Apache License 标题行');
|
||||
assert.ok(license.includes('Version 2.0, January 2004'), 'LICENSE 应是 Apache-2.0 全文');
|
||||
assert.ok(license.includes('END OF TERMS AND CONDITIONS'), 'LICENSE 应是全文而非节选');
|
||||
});
|
||||
```
|
||||
|
||||
- [ ] **Step 10: 改 `tests/dsh-preset.test.mjs` 的技能根表达式断言**
|
||||
|
||||
`assert.ok(expr.includes('rev-skills-dsh-preset/package.json'), …)` 一行删除，并把上一行改为：
|
||||
|
||||
```js
|
||||
assert.ok(expr.includes('rev-skills/package.json'), '表达式应支持从本包（rev-skills 即 bundle）解析');
|
||||
```
|
||||
|
||||
- [ ] **Step 11: 改包解析夹具的假目录**
|
||||
|
||||
```js
|
||||
const app = mkdtempSync(join(tmpdir(), 'dsh-preset-app-'));
|
||||
const fakeRepo = join(app, 'node_modules', 'rev-skills');
|
||||
const fakeKeys = join(fakeRepo, '.claude', 'skills', 're-fake');
|
||||
mkdirSync(fakeKeys, { recursive: true });
|
||||
writeFileSync(join(fakeRepo, 'package.json'), '{}');
|
||||
writeFileSync(join(fakeKeys, 'SKILL.md'), 'x');
|
||||
try {
|
||||
const baseUrl = join(fakeRepo, 'package.json');
|
||||
// DSH_HOME 指向一个不存在的目录，确保回落到包解析候选
|
||||
const viaPkg = evalExpr(expr, baseUrl, { revSkillsDir: '', dshHome: join(app, 'empty-dsh-home') });
|
||||
assert.equal(viaPkg, join(fakeRepo, '.claude', 'skills'));
|
||||
} finally {
|
||||
rmSync(app, { recursive: true, force: true });
|
||||
}
|
||||
```
|
||||
|
||||
（删掉了原来额外创建的 `node_modules/rev-skills-dsh-preset` 目录与它的 `package.json`——bundle 即 `rev-skills` 自己，`baseUrl` 落在同一个包内。）
|
||||
|
||||
- [ ] **Step 12: 改 `tests/dsh.test.mjs` 的两处**
|
||||
|
||||
第 148 行：
|
||||
|
||||
```js
|
||||
assert.equal(BUNDLE_PACKAGE, 'rev-skills');
|
||||
```
|
||||
|
||||
第 397 行：
|
||||
|
||||
```js
|
||||
assert.equal(bundleExists, true, '根包即 bundle（dsh.patch.yml + dsh.bundle.patch），install 用例依赖它');
|
||||
```
|
||||
|
||||
- [ ] **Step 13: 跑测试**
|
||||
|
||||
Run: `node validate.mjs && npm test`
|
||||
Expected: `OK: 122 skills validated`，且 `node --test` 汇总 `fail 0`；若出现 CLAUDE.md 计数不一致的失败（`CLAUDE.md 的测试计数与实际测试数一致`），记下实际数，Task 3 会统一同步——本任务不新增/删除顶层 `test(`，正常应仍是 202。
|
||||
|
||||
- [ ] **Step 14: 提交**
|
||||
|
||||
```bash
|
||||
git add dsh.patch.yml package.json bin/dsh.mjs tests/dsh-preset.test.mjs tests/dsh.test.mjs
|
||||
git commit -m "feat: DSH 预设就地化——根包自带 bundle，取消独立 dsh/ 包"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 2: 把「patch 不在 files 里」的坑固化成回归断言
|
||||
|
||||
**Files:**
|
||||
- Modify: `tests/dsh-preset.test.mjs`（新增一条测试）
|
||||
- Modify: `CLAUDE.md`（测试计数）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1 产出的根 `package.json` 的 `dsh.bundle.patch` 与 `files`
|
||||
- Produces: 无
|
||||
|
||||
- [ ] **Step 1: 写这条测试（先写出会通过的版本）**
|
||||
|
||||
在 `tests/dsh-preset.test.mjs` 的根 manifest 守卫测试之后追加：
|
||||
|
||||
```js
|
||||
test('dsh.bundle.patch 指向的文件必须随包发布（files 里漏列即安装期失败）', () => {
|
||||
const pkg = JSON.parse(readFileSync(PACKAGE_FILE, 'utf8'));
|
||||
const rel = pkg.dsh?.bundle?.patch;
|
||||
assert.equal(typeof rel, 'string', 'dsh.bundle.patch 必须存在');
|
||||
// 归一成包内相对路径：'./dsh.patch.yml' 与 files 里的 'dsh.patch.yml' 视为同一项
|
||||
const norm = (p) => p.replace(/^\.\//, '').split('\\').join('/');
|
||||
const target = norm(rel);
|
||||
const listed = (pkg.files ?? []).map(norm);
|
||||
assert.ok(
|
||||
listed.includes(target),
|
||||
`dsh.bundle.patch 指向 ${rel}，但 package.json 的 files 里没有它；`
|
||||
+ 'pnpm 的 file: 安装按 files 复制，漏列会让 dsh plugin add 报 '
|
||||
+ 'failed to read overlay … ENOENT 并整体回滚',
|
||||
);
|
||||
// bundle 会被整包装进 profile 的 node_modules，不得带上运行时依赖
|
||||
assert.equal(pkg.dependencies, undefined, 'bundle 包不得有运行时依赖');
|
||||
});
|
||||
```
|
||||
|
||||
- [ ] **Step 2: 跑测试确认通过**
|
||||
|
||||
Run: `node --test tests/dsh-preset.test.mjs`
|
||||
Expected: PASS（Task 1 已把 `dsh.patch.yml` 列进 `files`）。
|
||||
|
||||
- [ ] **Step 3: 验证这条断言真的会红（刻意的红-绿验证）**
|
||||
|
||||
临时把根 `package.json` 的 `files` 里 `"dsh.patch.yml"` 改为 `"dsh.patch.yml.bak"`，运行：
|
||||
|
||||
Run: `node --test tests/dsh-preset.test.mjs`
|
||||
Expected: FAIL，报 `files 里列了未随包发布的文件` 或本测试的 `files 里没有它`。看到失败后**改回** `"dsh.patch.yml"`，重跑确认转绿。
|
||||
|
||||
- [ ] **Step 4: 同步 CLAUDE.md 的测试计数**
|
||||
|
||||
Run: `node --test tests/*.test.mjs 2>&1 | grep '^ℹ tests'`
|
||||
|
||||
把 CLAUDE.md 里 `` `npm test` = validate + N 项测试 `` 的 N 改为实测值（本任务新增 1 条，预期 202 → 203）。
|
||||
|
||||
- [ ] **Step 5: 跑全量**
|
||||
|
||||
Run: `npm test`
|
||||
Expected: 全绿，且 `CLAUDE.md 的测试计数与实际测试数一致` 通过。
|
||||
|
||||
- [ ] **Step 6: 提交**
|
||||
|
||||
```bash
|
||||
git add tests/dsh-preset.test.mjs CLAUDE.md
|
||||
git commit -m "test: 固化 dsh.bundle.patch 必须随包发布的回归断言"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 3: 文档同步
|
||||
|
||||
**Files:**
|
||||
- Modify: `docs/dsh-integration.md`（第 1 节表述、第 2 节路线二、第 4 节验证、第 5 节排错表、第 6 节同步点表）
|
||||
- Modify: `README.md:66-69`、`README_EN.md:66-69`、`AGENTS.md:14`、`CLAUDE.md`（DSH 段）
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1 的 `BUNDLE_PACKAGE = 'rev-skills'`、补丁路径 `dsh.patch.yml`
|
||||
- Produces: 无
|
||||
|
||||
- [ ] **Step 1: 改写 `docs/dsh-integration.md` 第 2 节「路线二」**
|
||||
|
||||
原来的三句描述与候选表：bundle 包名改为 `rev-skills`（根包自身即 bundle，`dsh.bundle.patch` → `./dsh.patch.yml`）；技能根候选表**删掉第 4 行**（`<rev-skills-dsh-preset 包目录>/../.claude/skills`），第 3 行改为「`<rev-skills 包目录>/.claude/skills`（本包即 bundle，按包名解析）」。
|
||||
|
||||
手工路径的 jsonc 示例改为：
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"dependencies": { "rev-skills": "link:/path/to/rev-skills" },
|
||||
"dsh": { "profile": { "bundles": [ "@deepseek-ai/dsh-base", "rev-skills" ] } }
|
||||
}
|
||||
```
|
||||
|
||||
并补一句实测事实：从 registry 或本地路径安装时，`dsh plugin --profile <name> add rev-skills` 成功后会**自动把 `rev-skills` 追加进 `dsh.profile.bundles`**，失败则还原 `package.json`、`pnpm-lock.yaml` 与 `node_modules`。
|
||||
|
||||
- [ ] **Step 2: 改写 `docs/dsh-integration.md` 第 6 节「维护同步点」表**
|
||||
|
||||
把「版本号」（根 `package.json` ↔ `dsh/package.json`）一行删除（只剩根包一处，由仓库既有的版本同步规则覆盖）；「bundle 名」一行的另一侧由 `dsh/package.json` → `name` 改为根 `package.json` → `name`；「补丁文件」一行改为：
|
||||
|
||||
| 项 | 一处 | 另一处 |
|
||||
|---|---|---|
|
||||
| 补丁文件 | 根 `package.json` → `dsh.bundle.patch` | `dsh.patch.yml` 实际路径，且必须出现在根 `package.json` 的 `files` 里 |
|
||||
|
||||
- [ ] **Step 3: 把 `dsh/README.md` 的要点并入文档**
|
||||
|
||||
`dsh/README.md` 里未被 `docs/dsh-integration.md` 覆盖的内容（bundle 的安装输入、预设清单概览）并入第 2 节路线二；重复内容不搬。原文件已在 Task 1 删除，内容以 `git show dnfme/feat/dsh-preset:dsh/README.md` 取回参考。
|
||||
|
||||
- [ ] **Step 4: 同步 README / README_EN / AGENTS / CLAUDE**
|
||||
|
||||
`README.md` 第 69 行那段改为：
|
||||
|
||||
```markdown
|
||||
也可用 DSH 自带的插件管理器安装：`dsh plugin --profile <name> add rev-skills`（本地路径用 `link:` / `file:` 规格；成功后会自动登记进该 profile 的 `dsh.profile.bundles`）。技能目录可用环境变量 `REV_SKILLS_DIR` 覆盖。细节与排错见 [docs/dsh-integration.md](docs/dsh-integration.md)。
|
||||
```
|
||||
|
||||
`README_EN.md` 第 69 行按同义改写（英文）。`AGENTS.md` 第 14 行把「bundle `dsh/`」改为「bundle 即根包 `rev-skills`（补丁 `dsh.patch.yml`）」。
|
||||
|
||||
`CLAUDE.md` 的 DSH 段（第 63-72 行）：
|
||||
- 「独立预设路线」条目改为：根包自身即 bundle（根 `package.json` 的 `dsh.bundle.patch` → `dsh.patch.yml`；该文件必须在 `files` 里），补丁插入预设行 `preset-rev-skills`（`config.id` = `rev-skills`），启用方式 `dsh plugin --profile <name> add rev-skills` 或 `node bin/dsh.mjs preset install --apply`
|
||||
- 「必须成对同步的项」那句删掉所有 `dsh/package.json` 相关配对，改为：`dsh.bundle.patch` ↔ `dsh.patch.yml` 实际路径 ↔ 根 `package.json` 的 `files` 条目；补丁里的 `config.id`（`rev-skills`）↔ `docs/dsh-integration.md` 的说明
|
||||
|
||||
- [ ] **Step 5: 全库自检残留**
|
||||
|
||||
Run: `grep -rn "rev-skills-dsh-preset\|dsh/package.json\|dsh/cordis.patch.yml" --include="*.md" --include="*.json" --include="*.mjs" --include="*.yml" . | grep -v "^./docs/superpowers/"`
|
||||
|
||||
Expected: 无输出（`docs/superpowers/specs/2026-09-30-factual-audit-wave.md` 等历史存档允许保留旧表述，已由路径过滤排除；若命中历史存档以外的文件，逐个改正）。
|
||||
|
||||
- [ ] **Step 6: 跑测试并提交**
|
||||
|
||||
Run: `node validate.mjs && npm test`
|
||||
Expected: 全绿（若 `tests/counts.test.mjs` 的 README 站点断言因措辞变化而红，按报错补齐缺失关键词）。
|
||||
|
||||
```bash
|
||||
git add docs/dsh-integration.md README.md README_EN.md AGENTS.md CLAUDE.md
|
||||
git commit -m "docs: DSH 集成文档与清单同步根包自带 bundle 的形态"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 4: 端到端实机验证
|
||||
|
||||
**Files:**
|
||||
- 不改文件；发现缺陷则回改对应文件并 `fix:` 提交
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: Task 1-3 的全部产物
|
||||
- Produces: 供 PR 描述引用的验证结论
|
||||
|
||||
- [ ] **Step 1: 静态闸口**
|
||||
|
||||
```bash
|
||||
node validate.mjs
|
||||
node bin/dsh.mjs check
|
||||
```
|
||||
Expected: `OK: 122 skills validated`；`OK: 122 skills DSH-compatible (32 warning(s))`。
|
||||
|
||||
- [ ] **Step 2: 补丁里的技能根表达式实测求值**
|
||||
|
||||
```bash
|
||||
node -e '
|
||||
const fs=require("fs"),pt=require("path");
|
||||
const y=fs.readFileSync("dsh.patch.yml","utf8");
|
||||
const expr=y.match(/customSkillDirs:\n\s*- !!js "([\s\S]*?)"\n/)[1].replace(/\\"/g,"\"");
|
||||
const baseUrl=process.argv[1];
|
||||
console.log(new Function("baseUrl","return ("+expr+")")(baseUrl));
|
||||
' /tmp/nowhere/package.json
|
||||
```
|
||||
Expected: 打印 `REV_SKILLS_DIR` 未设、`DSH_HOME` 未设时的回落路径（`$HOME/.dsh/skills`）；把 `baseUrl` 换成已安装 profile 里 `node_modules/rev-skills/package.json` 时，应打印该包的 `.claude/skills`。
|
||||
|
||||
- [ ] **Step 3: 真实 profile 上装一遍（宿主自带插件管理器）**
|
||||
|
||||
```bash
|
||||
export DSHX=/tmp/dsh-verify && rm -rf $DSHX && mkdir -p $DSHX/profiles/e2e
|
||||
printf '{"name":"dsh-profile-e2e","private":true,"dependencies":{},"dsh":{"profile":{"bundles":["@deepseek-ai/dsh-base"]}}}\n' > $DSHX/profiles/e2e/package.json
|
||||
cd $DSHX/profiles/e2e && DSH_HOME=$DSHX dsh plugin --profile e2e add link:/home/DslsDZC/rev-skills
|
||||
DSH_HOME=$DSHX dsh --profile e2e --dump-config | grep -c preset-rev-skills
|
||||
```
|
||||
Expected: 安装成功无告警；`dsh.profile.bundles` 自动变为 `["@deepseek-ai/dsh-base","rev-skills"]`；`grep -c` 输出 `1`（预设行在配置树末层）；stderr 无 `skipping profile bundle`。
|
||||
|
||||
- [ ] **Step 4: `bin/dsh.mjs preset` 往返（本仓 CLI 路径）**
|
||||
|
||||
```bash
|
||||
node bin/dsh.mjs preset spec
|
||||
node bin/dsh.mjs preset status --profile-dir $DSHX/profiles/e2e --json
|
||||
node bin/dsh.mjs preset install --profile-dir /tmp/dsh-verify/other # dry-run
|
||||
node bin/dsh.mjs preset install --profile-dir /tmp/dsh-verify/other --apply
|
||||
node bin/dsh.mjs preset status --profile-dir /tmp/dsh-verify/other --json # ok: true
|
||||
node bin/dsh.mjs preset uninstall --profile-dir /tmp/dsh-verify/other --apply
|
||||
```
|
||||
Expected: `spec` 打印 bundle 绝对路径为仓库根、`link:` 规格与 profile 编辑；`status` 对 e2e profile 报 `ok: true`；dry-run 不写文件；`--apply` 生成备份；uninstall 从备份还原。
|
||||
|
||||
- [ ] **Step 5: 发布面检查**
|
||||
|
||||
```bash
|
||||
npm pack --dry-run 2>&1 | grep -E "dsh\.patch\.yml|dsh/"
|
||||
```
|
||||
Expected: 输出含 `dsh.patch.yml`，不含 `dsh/` 目录条目。
|
||||
|
||||
- [ ] **Step 6: 清理临时目录并汇报**
|
||||
|
||||
```bash
|
||||
rm -rf /tmp/dsh-verify
|
||||
```
|
||||
把 Step 1-5 的实际输出整理进 PR #5 的描述更新（不新建文件）。若任何一步暴露缺陷，回改对应文件并以 `fix:` 提交后重跑该步。
|
||||
@@ -0,0 +1,246 @@
|
||||
# 设计：逆向工程技能库（aihk）
|
||||
|
||||
日期：2026-08-07
|
||||
状态：已批准
|
||||
|
||||
## 1. 背景与目标
|
||||
|
||||
构建一个**通用、可发布**的逆向工程 AI 技能库，存放于 `/home/DslsDZC/aihk` 仓库。
|
||||
|
||||
- **场景覆盖**：恶意软件分析、CTF 逆向、固件/嵌入式、软件破解/脱壳、协议逆向、移动应用逆向（全部方向）
|
||||
- **平台覆盖**：Windows PE、Linux ELF、macOS Mach-O、固件/嵌入式多架构、Android/iOS
|
||||
- **通用性要求**：技能不能假设用户已安装任何工具——每个技能必须含跨 OS 安装指引
|
||||
- **发布形式**：GitHub 仓库直发 + npm（`npx` 安装器）+ Claude Code 插件市场（三者兼顾）
|
||||
- **多工具适配**：Claude Code、Gemini CLI、Cline、Codex CLI（原生 SKILL.md）；Cursor、GitHub Copilot、Windsurf（规则文件转换）
|
||||
|
||||
## 2. 架构：三层技能体系
|
||||
|
||||
### 2.1 第 1 层 — 入口（1 个）
|
||||
|
||||
`re-analyze`：唯一分析入口。流程：**环境探测 → 偏好询问 → 任务识别 → 编排分派**。
|
||||
|
||||
**① 环境探测（自动，`references/probe.sh`）**：
|
||||
|
||||
- **OS 平台**：Linux / macOS / Windows / WSL（`uname -s` + WSL 检测）——决定后续一切工具选择与平台经验分支
|
||||
- **硬件**：CPU 架构（`uname -m`）、核心数（`nproc`）、内存总量（`free -g`）——用于评估工具可行性（Ghidra 建议 ≥4GB 可用内存；angr 符号执行吃内存；QEMU 仿真按架构选内核）
|
||||
- **已装逆向工具**：`which` 探测 ghidra / ida / radare2 / gdb / frida / binwalk / qemu / jadx / angr / z3 等清单——**仅作可选优化**：探测到已装工具则优先使用；**默认假设空白环境（用户机器无任何已装工具）**，未探测到工具时按对应技能的「工具准备」章节引导安装，绝不因"没装"而卡住流程
|
||||
- 探测失败（如 Windows 无 `uname/free`）→ 退化为向用户询问硬件情况
|
||||
|
||||
**② 偏好询问（用户选择，问题集在 `references/preferences.md`）**：
|
||||
|
||||
| 问题 | 选项 | 说明 |
|
||||
|---|---|---|
|
||||
| **分析目标** | 用户自然语言描述 | **必答、第一项**：想达成什么（判定恶意行为 / 脱壳拿干净样本 / 找密钥或注册码 / 还原算法 / 确认漏洞 / 提取配置……）——决定整个编排路径与产出形态 |
|
||||
| 反编译器选择 | IDA / Ghidra / radare2 / **自动推荐** | 推荐依据：免费 vs 商业、平台支持、内存可行性——**不是已装哪个**（通用场景默认没装任何工具） |
|
||||
| 分析深度 | 快速结论 / 标准分析 / 深度报告 | 决定走哪条流程路径与产出规模 |
|
||||
| 输出报告 | 要 / 不要 | 决定是否走报告流程（IOC/YARA 等） |
|
||||
| 平台确认 | 自动识别 / 手动指定 | 文件存在时自动识别为主 |
|
||||
|
||||
询问顺序：**目标描述优先**（第一问），其后是反编译器、深度、报告、平台确认。目标决定 `triage.md` 决策表选择哪条编排路径；目标不明确时，入口追问直到可执行（如"想确认这个样本会不会回连"→ 编排：沙箱 → 行为 → netcap → 报告）。
|
||||
|
||||
**反编译器选择依据**（写入 `references/preferences.md`，不依赖已装工具）：
|
||||
|
||||
- **Ghidra**：免费开源、跨平台（Win/Linux/macOS）、Linux 最顺——**通用场景默认推荐**
|
||||
- **IDA**：商业付费（有 7.x 免费版）、Windows 生态最强、插件丰富——用户明确选或目标为 Windows 闭源软件时推荐
|
||||
- **radare2/rizin**：命令行轻量、终端友好、脚本化强——内存紧张或 CLI 工作流时推荐
|
||||
- 内存 <4GB → 提示 Ghidra 可能吃力，建议轻量工具（radare2）或先加内存
|
||||
|
||||
偏好询问**一次完成**，结果存入会话变量，贯穿本次分析全程——被调用的子技能读取该状态（如用户选 Ghidra → 所有反编译步骤直接走 `re-ghidra` 工作流；未装该工具 → 先执行其「工具准备」安装步骤）。
|
||||
|
||||
**③ 任务识别与编排**：根据输入（文件路径 / 描述 / 请求）判断任务类型，查 `references/triage.md` 决策表，编排调用大类网关。复合任务（命中多个大类）按依赖顺序串联。
|
||||
|
||||
### 2.2 第 2 层 — 大类网关（8 个，独立）
|
||||
|
||||
按学科划分，**互不合并**；大类之间的联合通过跨网关引用（`[[链接]]`）实现。
|
||||
|
||||
| 网关 | 学科 | 核心职责 |
|
||||
|---|---|---|
|
||||
| `re-binary-core` | 软件逆向核心 | 公共底座：格式、反编译、调试器、静态/动态通用技术 |
|
||||
| `re-malware` | 恶意软件分析 | 沙箱、行为分析、IOC/YARA、报告（`re-sandbox` 为动态分析强制前置） |
|
||||
| `re-firmware` | 固件/嵌入式/硬件 | 固件提取、rootfs、QEMU 仿真、JTAG/UART |
|
||||
| `re-protocol` | 协议逆向 | 流量捕获、状态机重建、加密识别/密钥/解密 |
|
||||
| `re-mobile` | 移动应用 | APK、iOS、Frida |
|
||||
| `re-anti-analysis` | 反分析对抗 | 壳识别、脱壳（简单/高级）、反混淆 |
|
||||
| `re-cracking` | 软件破解 | 授权逻辑、补丁、注册机 |
|
||||
| `re-ctf` | CTF 实践 | angr、Z3 |
|
||||
| `re-managed` | 托管代码/字节码 | .NET CIL、Java 字节码、脚本/宏去混淆、WASM |
|
||||
| `re-forensics` | 取证/威胁情报 | 内存取证（Volatility 3）、威胁情报查询（VT/沙箱/MISP） |
|
||||
| `re-vuln` | 漏洞挖掘 | 覆盖率引导 fuzzing、崩溃分析/漏洞定位 |
|
||||
|
||||
每个网关 SKILL.md 必含三部分：**该大类完整工作流**、**何时用哪个原子技能（选择树）**、**跨域联合章节**。
|
||||
|
||||
### 2.3 第 3 层 — 原子技能（37 个）
|
||||
|
||||
| 大类 | 原子技能 |
|
||||
|---|---|
|
||||
| `re-binary-core` | `re-triage`、`re-format-pe`、`re-format-elf`、`re-format-macho`、`re-imports`、`re-ghidra`、`re-ida`、`re-radare2`、`re-gdb`、`re-x64dbg`、`re-lldb`、`re-tracing`、`re-memdump`、`re-windbg`、`re-binaryninja`、`re-emulation`、`re-kernel`、`re-game`、`re-go`、`re-rust`、`re-plugin-dev`、`re-shellcode`、`re-hypervisor`、`re-anti-cheat` |
|
||||
| `re-malware` | `re-sandbox`、`re-behavior`、`re-ioc`、`re-ransomware`、`re-loader`、`re-fileless` |
|
||||
| `re-firmware` | `re-fw-extract`、`re-fw-rootfs`、`re-fw-emulate`、`re-hardware-io`、`re-uefi` |
|
||||
| `re-protocol` | `re-netcap`、`re-proto-rev`、`re-crypto-id`、`re-crypto-keys`、`re-crypto-decrypt`、`re-iot-proto`、`re-whitebox`、`re-tls` |
|
||||
| `re-mobile` | `re-apk`、`re-ios`、`re-frida`、`re-mobile-pack`、`re-hybrid-app`、`re-android-native`、`re-ios-jb` |
|
||||
| `re-anti-analysis` | `re-packer-id`、`re-unpack-simple`、`re-unpack-advanced`、`re-deobfuscate`、`re-evasion` |
|
||||
| `re-cracking` | `re-license`、`re-patching`、`re-keygen`、`re-drm` |
|
||||
| `re-ctf` | `re-angr`、`re-z3`、`re-pwn` |
|
||||
| `re-managed` | `re-dotnet`、`re-java`、`re-script-deob`、`re-wasm`、`re-ai-model`、`re-blockchain` |
|
||||
| `re-forensics` | `re-mem-forensics`、`re-ti`、`re-disk-forensics` |
|
||||
| `re-vuln` | `re-fuzzing`、`re-crash-triage`、`re-exploit` |
|
||||
|
||||
总数：**1 入口 + 11 网关 + 76 原子 = 88 技能**。
|
||||
|
||||
### 2.4 跨大类引用机制
|
||||
|
||||
大类独立、任务联合。已知联合场景（写进各网关的「跨域联合」章节）：
|
||||
|
||||
| 联合场景 | 主大类 → 引用 |
|
||||
|---|---|
|
||||
| 恶意样本加壳 | `re-malware` → `re-anti-analysis`（packer-id / unpack-*） |
|
||||
| C2 通信分析 | `re-malware` → `re-protocol`（netcap / proto-rev / crypto-*） |
|
||||
| 破解先脱壳 | `re-cracking` → `re-anti-analysis` |
|
||||
| 移动 App 含原生库 | `re-mobile` → `re-binary-core`（format-elf / ghidra） |
|
||||
| 固件通信协议 | `re-firmware` → `re-protocol` |
|
||||
| CTF 题 = 核心技能应用 | `re-ctf` → `re-binary-core` |
|
||||
| .NET/Java 恶意样本 | `re-malware` → `re-managed`（dotnet / java） |
|
||||
| 恶意样本内存取证 | `re-malware` → `re-forensics`（mem-forensics） |
|
||||
| 内核驱动/rootkit 样本 | `re-malware` → `re-kernel` |
|
||||
| 威胁情报关联 | `re-malware` → `re-forensics`（ti） |
|
||||
| 游戏破解 | `re-cracking` → `re-game` |
|
||||
| 崩溃样本定位 | `re-vuln` → `re-binary-core`（triage/ghidra 定位）+ `re-memdump`（core 分析） |
|
||||
| CTF pwn 题 | `re-ctf` → `re-vuln`（fuzzing/crash-triage） |
|
||||
| 工控协议分析 | `re-protocol` → `re-ics` |
|
||||
| 车载/ECU 固件 | `re-firmware` → `re-automotive` |
|
||||
|
||||
落地方式：
|
||||
1. 每个网关 SKILL.md 含「跨域联合」章节，声明引用场景与顺序（引用即 `[[链接]]`，被引用技能按需加载）
|
||||
2. `re-analyze/references/triage.md` 决策表处理复合任务编排（如"脱壳 → 静态 → 动态 → C2 协议 → 报告"）
|
||||
|
||||
## 2.5 平台经验知识库（`re-analyze/references/platform-tips.md`）
|
||||
|
||||
每个技能的工具准备与操作步骤按 **OS 分支**给出方案；跨大类共享的平台经验沉淀在入口的 `platform-tips.md`，被所有技能引用。初始内容（实战经验，后续扩充）：
|
||||
|
||||
| 平台 | 场景 | 经验方案 |
|
||||
|---|---|---|
|
||||
| **所有平台** | **运行任何样本/动态分析** | **默认沙箱，强制前置**：虚拟机快照 / 容器（Docker、firejail）/ 专用沙箱（Cuckoo/CAPE）；网络隔离（INetSim、fake DNS、断网）。样本可能已被污染或含攻击行为——**静态分析可免沙箱，一切动态执行默认在沙箱内**，分析结束后恢复快照。此原则优先于本表所有其他条目 |
|
||||
| **Linux** | 分析 Windows PE 程序 | **Wine 直读进程内存**：wine 运行 PE → `gdb attach` 或读 `/proc/<pid>/mem`——**无需整机虚拟化**；脱壳/读内存直接对 Wine 进程操作。比 QEMU 全套虚拟化轻一个量级 |
|
||||
| **Linux** | 跑非本机架构程序 | QEMU 用户态仿真（`qemu-<arch>`）优先，全系统仿真仅必要时用 |
|
||||
| **Linux** | **内存转储的极端段** | `[vsyscall]`（固定地址 `0xffffffffff600000`，只执行 `--xp`）、`[vdso]`/`[vvar]`：`/proc/<pid>/mem` 读取会失败，gdb 访问报错属正常。**转储前必须按 `/proc/<pid>/maps` 过滤这些段**（只 dump `r--p`/`rw-p` 可读映射），否则 dump 含垃圾页、脱壳/分析全被污染。识别特征：`maps` 中 `[vsyscall]`/`[vdso]`/`[vvar]` 名称、地址落在 `0xffffffffff6xxxxx` 高段、无文件路径的匿名 `00:00` 映射 |
|
||||
| **Windows** | 读目标进程内存 | 需装 Sysinternals 套件（`procdump`）/ `DumpIt` 做内存转储 + Volatility 分析；attach 需要管理员权限 |
|
||||
| **macOS** | attach/调试 | SIP 与 TCC 限制：调试工具需授权（Developer Tools 权限），`lldb` attach 前检查 |
|
||||
| **WSL** | 分析 Windows 侧目标 | WSL 无法直接 attach Windows 进程——跨边界的分析走 Windows 侧工具，WSL 内只做文件/静态分析 |
|
||||
|
||||
原则：**先给最轻的可行方案**（Wine 直读 > 用户态仿真 > 全系统虚拟化 > 物理机），按平台经验分支执行。
|
||||
|
||||
**「直读 vs 转储」决策**（`re-memdump` 等技能引用，依据实战与社区共识）：
|
||||
|
||||
**默认策略：转储优先。** 一次转储获得完整内存布局 + 寄存器/线程状态（ELF notes），可导入 Ghidra/IDA、可存档复现；后续所有定向提取（密钥搜索、脱壳段、DEX 挖掘）都从转储产物里做，进程状态被冻结后反复分析也不受干扰。
|
||||
|
||||
| 场景 | 方案 |
|
||||
|---|---|
|
||||
| **默认（任何需要读内存的任务）** | **转储** `gcore` → ELF core 文件；取证/存档场景用全量转储 + 映射清单（manifest） |
|
||||
| 需要完整内存布局 + 寄存器/线程状态（导入 Ghidra/IDA、事后复现分析） | **转储** `gcore` → ELF core 文件（含 ELF notes） |
|
||||
| 进程已死 | 直接分析已有 core 文件（`kernel.core_pattern` / systemd-coredump / 容器 runtime dump） |
|
||||
| ptrace 被禁 / 沙箱容器 / attach 失败 | **转储兜底**：core 文件不需要 `/proc/<pid>/mem` 权限路径 |
|
||||
| 特例①：进程必须保持运行、实时交互调试 | **直读** `/proc/<pid>/mem`：先读 `/proc/<pid>/maps` 确定有效地址范围 → SIGSTOP 暂停进程防竞态 → chunked `pread` 只取目标区段 |
|
||||
| 特例②：只需极小特定区段且性能敏感（在线检查某地址） | **直读** 单区段，同上流程 |
|
||||
|
||||
关键经验：**转储时机**——脱壳须等进程运行到 OEP 完全解密后再 dump，否则转的是壳的初始状态；直读前必须先查 maps（无脑 open `/proc/<pid>/mem` 必然报错）；dump 前过滤 `[vsyscall]`/`[vdso]` 等特殊段（见上表）。
|
||||
|
||||
## 3. 技能统一模板
|
||||
|
||||
### 3.1 原子技能模板
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: re-xxx
|
||||
description: > 中英双语触发词 + 何时使用
|
||||
---
|
||||
|
||||
# 技能名
|
||||
|
||||
## 何时使用 / 何时不用 ← 明确边界，避免误触发
|
||||
## 工具准备 ← 必含：每工具 apt/dnf/pacman/brew/pip/cargo/choco
|
||||
← 安装命令 + 验证命令
|
||||
← 按 OS 分支：Linux/macOS/Windows/WSL 各自的方案与替代工具
|
||||
← 优先引用 platform-tips.md 的平台经验
|
||||
## 操作步骤 ← 可执行、具体（沿用 porting-minecraft-mod 的硬性执行风格）
|
||||
## 跨域联合 ← 本技能在哪些复合任务中被其他大类引用
|
||||
## 常见坑与陷阱
|
||||
```
|
||||
|
||||
### 3.2 多工具兼容约束（保证转换无损）
|
||||
|
||||
- 正文纯 Markdown，不依赖任何工具私有语法
|
||||
- frontmatter 标准 YAML，description 中英双语触发词
|
||||
- 技能保持原子粒度 → 转换聚合后才有结构
|
||||
|
||||
## 4. 发布与安装机制
|
||||
|
||||
### 4.1 仓库结构
|
||||
|
||||
```
|
||||
aihk/
|
||||
├── AGENTS.md # 跨工具通用入口（Claude/Codex/Gemini/Cursor/Zed 都读）
|
||||
├── README.md # 三种安装方式 + 多工具适配说明 + 技能目录导航
|
||||
├── LICENSE # MIT
|
||||
├── package.json # npm 包 re-skills，bin: re-skills → bin/install.mjs
|
||||
├── bin/install.mjs # 安装器（--target 多工具）
|
||||
├── bin/convert.mjs # 转换器：SKILL.md → Cursor/Copilot/Windsurf 规则格式
|
||||
├── .claude-plugin/marketplace.json # claude plugin add 支持
|
||||
├── .claude/skills/ # 46 个技能（标准结构）
|
||||
│ └── re-analyze/
|
||||
│ ├── SKILL.md # 入口：环境探测 → 偏好询问 → 任务识别 → 编排
|
||||
│ ├── references/probe.sh # OS/硬件与工具自动探测脚本
|
||||
│ ├── references/preferences.md# 偏好问题集与默认值
|
||||
│ ├── references/platform-tips.md # 平台经验知识库（Wine 直读/内存转储等）
|
||||
│ └── references/triage.md # 任务类型判定决策表
|
||||
└── tests/validate.mjs # 结构冒烟测试
|
||||
```
|
||||
|
||||
### 4.2 安装器 --target 矩阵
|
||||
|
||||
| target | 安装位置 | 方式 |
|
||||
|---|---|---|
|
||||
| `claude` | `~/.claude/skills/` 或项目 `.claude/skills/` | 原样复制（原生） |
|
||||
| `gemini` | `~/.gemini/skills/` | 原样复制（原生） |
|
||||
| `cline` | 项目 `.claude/skills/` | 原样复制（原生兼容） |
|
||||
| `codex` | `~/.codex/skills/` | 原样复制（原生） |
|
||||
| `cursor` | `.cursor/rules/` | 转换 → `.mdc` |
|
||||
| `copilot` | `.github/copilot-instructions.md` | 转换 → 聚合指令 |
|
||||
| `windsurf` | `.windsurf/rules/` | 转换 → `.md` |
|
||||
| `all` | 以上全部 | 混合 |
|
||||
|
||||
命令形式：`npx re-skills install`（交互）/ `--global` / `--project` / `--target <x>` / `--dry-run` / `uninstall`
|
||||
|
||||
安装器行为：
|
||||
- 复制优先（符号链接在 Windows 需管理员权限；`--link` 可选）
|
||||
- 自动跳过同名冲突技能并提示
|
||||
- 安装后输出验证方法
|
||||
|
||||
### 4.3 兼容性边界（写入 README）
|
||||
|
||||
- **原生技能类**（Claude Code / Gemini CLI / Cline / Codex CLI / Zed）：完整技能体验，按需动态加载
|
||||
- **规则文件类**（Cursor / Copilot / Windsurf）：获得"知识 + 流程"聚合，无按需加载
|
||||
- 转换产物保证每个工具都能用于实际分析
|
||||
|
||||
### 4.4 转换器原理
|
||||
|
||||
`bin/convert.mjs`：解析 SKILL.md frontmatter + 正文，按目标工具模板生成规则文件——`.mdc` 带 YAML 头（description + globs）；Copilot 聚合为单文件纯 Markdown；Windsurf 每技能一文件。
|
||||
|
||||
## 5. 测试与发布验证
|
||||
|
||||
`tests/validate.mjs`（`npm test` 运行）校验：
|
||||
1. 每个技能目录有 `SKILL.md` + 合法 frontmatter（name/description）
|
||||
2. 所有 `[[链接]]` 指向仓库内真实存在的技能（防死链）
|
||||
3. 每个技能含「工具准备」章节（通用性硬性检查）
|
||||
4. 命名规范（`re-` 前缀）
|
||||
|
||||
发布流程：`npm test` 通过 → git tag → npm publish → 同步 marketplace.json 版本。
|
||||
|
||||
## 6. 成功标准
|
||||
|
||||
- 88 个技能全部通过 validate（合法 frontmatter、无死链、含工具准备）
|
||||
- `probe.sh` 能输出 OS 平台 + CPU/内存/已装工具清单（Linux/macOS），Windows 下降级为询问；空白环境（无任何工具）时输出安装引导而非中断
|
||||
- `platform-tips.md` 覆盖 5 个平台分支（Linux/macOS/Windows/WSL/跨平台），被至少 10 个技能引用
|
||||
- `re-analyze` 完整走通"探测 → 偏好 → 识别 → 分派"，偏好状态能被子技能读取
|
||||
- `npx re-skills install --target all --dry-run` 输出全部安装计划
|
||||
- 转换器对每种规则类 target 生成产物成功
|
||||
- README 完整覆盖三种安装方式与七种工具适配说明
|
||||
@@ -0,0 +1,73 @@
|
||||
# reverse-skill 经验吸收设计（2026-08-18）
|
||||
|
||||
## 背景
|
||||
|
||||
reverse-skill（zhaoxuya520/reverse-skill，MIT 许可）的 field-journal 含 42 个经验 md（18 真实条目 + 17 seed + 3 precedent + 索引/模板）。经评估：24 个跳过（渗透测试类非逆向域、reverse-skill 自身工程类、已覆盖、索引类），12 个逆向域候选值得吸收。机制层（routing.json/scope 门/自动回流 CI 等）用户确认不做。
|
||||
|
||||
设计约束（沿用全库红线与原则）：
|
||||
- **红线 1 呈现中性**：禁用「最推荐」「强烈建议」等最高级强推措辞
|
||||
- **红线 2 隐私脱敏**：吸收条目按脱敏规范泛化（不指向具体项目/公司/产品）
|
||||
- **版权**：reverse-skill 为 MIT 许可——吸收条目注明来源（「来源：reverse-skill field-journal（MIT）」）
|
||||
- **改写**：不逐字复制——按 rev-skills 坑格式（现象/原因/对策）改写
|
||||
- **查重**：入库前对目标技能 grep 去重（如 SSL 绕过——frida-scripts.md 已有模板则跳过或合并）
|
||||
- 工作区已干净，无未提交文件冲突
|
||||
- 当前分支 `main`
|
||||
|
||||
## 变更总览（12 个吸收候选 → 归域）
|
||||
|
||||
| # | 源条目 | 蒸馏主题 | 归域技能 | 吸收形态 |
|
||||
|---|---|---|---|---|
|
||||
| 1 | seed-002 | Go stripped+Garble 对抗（GoReSym/GoResolver/GoStringUngarbler 链、AES 密钥定位） | re-go | 坑 3-4 条 + 工具链方法 |
|
||||
| 2 | 2026-07-14 | Android ARM64 间接跳转表静态求解、XOR 解密器重放 | re-binary-core | 坑 2-3 条 |
|
||||
| 3 | 2026-07-05 | 验证码系统 VM 混淆对抗 | re-deobfuscate | 坑 2-3 条 |
|
||||
| 4 | 2026-08-06 | Cortex-M 固件自旋 XOR 封装（自带掩码旋转） | re-fw-extract | 坑 1-2 条 |
|
||||
| 5 | seed-001 | ELF 自解压加载器（bzip2 尾部流定位、__ARCHIVE_BELOW__ 自解压脚本） | re-loader | 坑 2 条 |
|
||||
| 6 | seed-014 | Unity IL2CPP 元数据还原（global-metadata.dat、方法指针） | re-game | 坑 2-3 条 |
|
||||
| 7 | seed-008 | APK OkHttp SSL Pinning 绕过 | re-frida | 查重（frida-scripts.md 已有 SSL 模板）——命中则跳过 |
|
||||
| 8 | seed-009 | iOS 越狱检测绕过 + 抓包 | re-ios-jb | 坑 2 条 |
|
||||
| 9 | seed-011 | PCAP 自定义二进制协议还原 | re-proto-rev | 坑 2 条 |
|
||||
| 10 | seed-004 | JS 签名逆向（Webpack+AES+时间戳） | re-script-deob / re-crypto-id | 坑 2 条 |
|
||||
| 11 | 2026-07-22 | Electron Bytenode 特权更新链（字节码+更新校验） | re-managed（re-dotnet 相邻） | 坑 2 条 |
|
||||
| 12 | 2026-05-15 | Go TLS 分片代理逆向 | re-go / re-tls | 坑 2 条 |
|
||||
|
||||
## 吸收格式与规则
|
||||
|
||||
**坑格式**（与技能库既有体例一致）：`**标题**：现象——…；原因——…；对策——…`
|
||||
|
||||
**改写规则**：
|
||||
1. seed 的踩坑表（问题/原因/解决方案）直接映射为现象/原因/对策
|
||||
2. 真实条目的方法链蒸馏成可复用坑（保留技术结论，删目标细节）
|
||||
3. 每技能吸收 1-4 条（按价值裁量，不硬凑）
|
||||
|
||||
**查重规则**：
|
||||
- 入库前 `grep -n "关键词" <目标技能>/SKILL.md`（含 references/）
|
||||
- 同现象已存在 → 跳过并记录
|
||||
- 内容更完整的新版本可合并
|
||||
|
||||
**版权注明**：
|
||||
- 每技能吸收的条目末尾加一行：`（来源：reverse-skill field-journal，MIT）`
|
||||
- README 不需要额外声明（条目级注明即可）——或按技能库惯例在吸收批次 commit message 注明
|
||||
|
||||
**脱敏**：
|
||||
- 真实条目中的目标特征（名称/域名/指纹）全部泛化
|
||||
- 工具名/版本号/公开技术特征保留（如 GoReSym、跳转表公式）
|
||||
|
||||
## 查重预检（已识别）
|
||||
|
||||
- seed-008 SSL Pinning：frida-scripts.md 已有「SSL 固定绕过」模板——**预判命中，吸收时先查重，命中则跳过**
|
||||
- seed-010 pwn ROP：re-pwn 已有——不在候选（跳过清单已含）
|
||||
- seed-015 UART：re-hardware-io 已有——不在候选（跳过清单已含）
|
||||
- seed-011 PCAP：re-proto-rev 已覆盖协议状态机——吸收前查重，可能部分命中
|
||||
|
||||
## 校验与测试
|
||||
|
||||
- 每处吸收后 `npm test` 全绿（107 skills 不变，无新技能）
|
||||
- 吸收条目无 [[死链]]（引用技能均存在）
|
||||
- 红线 2：吸收内容无具体项目/公司/产品指代
|
||||
- 不触碰工作区其他文件
|
||||
|
||||
## 范围外
|
||||
|
||||
- reverse-skill 机制层（routing.json/tool-index/自动回流 CI/scope 门/下一步菜单/CTF 编排）——用户确认不做
|
||||
- 渗透测试类条目（Web/AD/云渗透）——非逆向域
|
||||
- reverse-skill 自身工程类条目
|
||||
@@ -0,0 +1,102 @@
|
||||
# 4 个语言逆向技能设计（2026-08-18）
|
||||
|
||||
## 背景
|
||||
|
||||
rev-skills（97 技能）语言逆向覆盖目前只有 re-go / re-rust。用户确认新增 4 个语言技能：Swift / Zig / Nim / 函数式运行时（Haskell+OCaml 合并）。
|
||||
|
||||
设计约束（沿用全库红线与原则）：
|
||||
- **红线 1 呈现中性**：禁用「最推荐」「强烈建议」等最高级强推措辞
|
||||
- **红线 2 隐私脱敏**：内容不指向具体项目/公司/产品
|
||||
- **不绑定具体工具**：方法为核心，工具为可替换示例（工具准备保留跨 OS 安装指引）
|
||||
- 工作区已干净（无未提交文件）——re-binary-core 可正常修改提交
|
||||
- 当前分支 `main`
|
||||
|
||||
## 变更总览
|
||||
|
||||
| # | 新技能 | 类型 | 挂载 | 计数 |
|
||||
|---|---|---|---|---|
|
||||
| 1 | re-swift | 原子 | re-binary-core | 98 |
|
||||
| 2 | re-zig | 原子 | re-binary-core | 99 |
|
||||
| 3 | re-nim | 原子 | re-binary-core | 100 |
|
||||
| 4 | re-fp-runtime | 原子 | re-binary-core | 101 |
|
||||
|
||||
最终：101 技能 = 1 入口 + 12 网关 + 88 原子。
|
||||
|
||||
## ① re-swift（Swift 生态）
|
||||
|
||||
- **定位**：Swift 二进制逆向——mangling、协议 witness table、闭包捕获、ObjC 互操作
|
||||
- **frontmatter**：`name: re-swift`；触发词：Swift逆向、swiftc、witness table、swift demangle、闭包捕获、Swift 产物
|
||||
- **章节**：
|
||||
1. 何时使用 / 何时不用——用：Swift 产物（Mach-O/ELF 含 Swift mangling 特征）；不用：纯 ObjC（走 [[re-ios]] / [[re-macos]] 的 ObjC 路径）
|
||||
2. 工具准备——swift-demangle（Swift 工具链）、llvm-objdump、Ghidra/IDA；跨 OS 安装命令
|
||||
3. 操作步骤——
|
||||
1. 产物识别（`$s` mangling 前缀、swift_* 运行时导入）
|
||||
2. mangling 解码（swift-demangle 批量：类型/函数/泛型展开）
|
||||
3. 协议 witness table（协议方法分发表定位与还原）
|
||||
4. 闭包捕获（context 结构：捕获变量布局还原）
|
||||
5. ObjC 互操作（@objc 桥接、NSObject 子类、消息发送路径）
|
||||
4. 跨域联合——[[re-binary-core]] 网关；[[re-ios]] / [[re-macos]] 生态衔接
|
||||
5. 常见坑与陷阱——mangling 版本差异、泛型展开符号爆炸、witness table 无符号名、闭包捕获含引用语义
|
||||
- **挂载**：re-binary-core 子技能列表 + 选择树分支；re-ios / re-macos 跨域引用
|
||||
|
||||
## ② re-zig（Zig 产物）
|
||||
|
||||
- **定位**：Zig 编译产物逆向——ABI 简单（无 RTTI/无异常）、comptime 展开、panic/错误处理路径
|
||||
- **frontmatter**：触发词：Zig逆向、zig、comptime、zig 产物、panic
|
||||
- **章节**：
|
||||
1. 何时使用 / 何时不用——用：Zig 产物（无 C++ RTTI/异常表、panicking 函数特征）；不用：C/C++ 产物（走 [[re-cpp-abi]]）
|
||||
2. 工具准备——readelf / llvm-nm、Ghidra/IDA；跨 OS 安装
|
||||
3. 操作步骤——
|
||||
1. 产物识别（panicking 函数特征、std 符号模式、无 RTTI/异常表）
|
||||
2. 导出符号与启动路径（start/main、comptime 展开产物）
|
||||
3. panic/错误处理路径（错误联合类型布局）
|
||||
4. C ABI 边界（@extern/@cImport 产物识别）
|
||||
4. 跨域联合——[[re-binary-core]] 网关；[[re-cpp-abi]] 边界区分
|
||||
5. 常见坑与陷阱——comptime 展开导致符号膨胀、panic 路径误导、错误联合布局版本差异、与 C 混合编译难分界
|
||||
- **挂载**：re-binary-core
|
||||
|
||||
## ③ re-nim（Nim 产物）
|
||||
|
||||
- **定位**：Nim 编译产物逆向——GC/异常运行时、NimString、导出符号
|
||||
- **frontmatter**：触发词：Nim逆向、nim、NimString、NimMain、nim 产物
|
||||
- **章节**：
|
||||
1. 何时使用 / 何时不用——用：Nim 产物（NimMain/GC 符号特征）；不用：C 产物（走 [[re-binary-core]] 通用）
|
||||
2. 工具准备——readelf、Ghidra/IDA；跨 OS 安装
|
||||
3. 操作步骤——
|
||||
1. 产物识别（NimMain / GC 符号、NimString 结构特征）
|
||||
2. 字符串与序列结构（NimStringV2 布局：len/reserved/data）
|
||||
3. 异常与 raises 路径（Nim 异常机制）
|
||||
4. GC 与引用计数（refc/orc 差异）
|
||||
4. 跨域联合——[[re-binary-core]] 网关
|
||||
5. 常见坑与陷阱——GC 版本差异（refc/orc）、NimString 布局随版本变化、导出符号被 strip、C 混合编译
|
||||
- **挂载**：re-binary-core
|
||||
|
||||
## ④ re-fp-runtime（函数式运行时：Haskell / OCaml 合并）
|
||||
|
||||
- **定位**：函数式语言运行时逆向——GHC RTS 与 OCaml runtime 的闭包/堆模型；逆向着重数据流而非控制流
|
||||
- **frontmatter**：触发词：Haskell逆向、OCaml逆向、GHC RTS、thunk、STG、OCaml runtime、闭包、函数式产物
|
||||
- **章节**：
|
||||
1. 何时使用 / 何时不用——用：Haskell/OCaml 产物（RTS 符号、block 头特征）；不用：命令式语言产物（各归各技能）
|
||||
2. 工具准备——readelf、ghc 工具链（ghc-nm 等）、ocamlobjinfo、Ghidra/IDA；跨 OS 安装
|
||||
3. 操作步骤——
|
||||
1. 运行时识别（GHC RTS 符号 / OCaml block 头；字节码 vs 原生产物区分）
|
||||
2. 闭包与堆对象（GHC thunk/CAF 布局；OCaml tagged int / block 头）
|
||||
3. 调用约定（GHC 栈/寄存器约定；OCaml 参数传递）
|
||||
4. 分析策略（数据流优先——函数式产物控制流被打散，闭包字段与构造器是主要线索）
|
||||
4. 跨域联合——[[re-binary-core]] 网关
|
||||
5. 常见坑与陷阱——RTS 版本差异、thunk 惰性求值误导（未求值闭包 vs 已求值）、OCaml 字节码非 native、控制流打散导致静态分析失效
|
||||
- **挂载**：re-binary-core
|
||||
|
||||
## 同步
|
||||
|
||||
- re-binary-core：子技能列表加 4 个 + 选择树加 4 分支（目标语言 → 对应技能）
|
||||
- re-ios / re-macos 跨域联合各加一行 [[re-swift]]
|
||||
- README：技能导航（97）→（101）、「12 大类网关 → 84 原子技能」→ 88、re-binary-core 导航行加 4 个
|
||||
- AGENTS.md：（97 个技能）→（101 个技能）、原子技能（84）→（88）
|
||||
- marketplace.json：97 个技能 → 101 个技能
|
||||
|
||||
## 校验与测试
|
||||
|
||||
- validate.mjs 自动覆盖 4 个新技能（frontmatter name=目录名 / type=atomic / 工具准备 / 链接）
|
||||
- `npm test` 全绿（101 skills validated）
|
||||
- 工作区已干净，无未提交文件冲突
|
||||
@@ -0,0 +1,78 @@
|
||||
# re-feedback 网关设计（2026-08-18）
|
||||
|
||||
## 背景与问题
|
||||
|
||||
aiHK/re-skills 是 88 个逆向工程技能库（1 入口 re-analyze + 11 大类网关 + 76 原子技能），公开发布（npm + 插件市场）。
|
||||
|
||||
现有经验流：`wxsource.mjs` 抓看雪/微信文章 → 手动蒸馏成「坑」条目 → 就近写入对应技能 SKILL.md → commit（如「经验: 第八轮扫描入库4篇」）。
|
||||
|
||||
缺失能力：
|
||||
- 实战分析会话的经验回馈通道（分析完踩的坑没有沉淀路径）
|
||||
- 用户手动投喂经验的入口
|
||||
- 统一的呈现与隐私规范
|
||||
|
||||
## 目标
|
||||
|
||||
新建第 12 个网关技能 `re-feedback`（**元网关**——管理技能库自身的经验，不分析 RE 目标），实现：
|
||||
|
||||
1. **收集**：三源归一——分析会话复盘 / 文章扫描蒸馏（wxsource.mjs）/ 用户手动输入
|
||||
2. **蒸馏**：按「坑」格式产出条目，并强制脱敏
|
||||
3. **归域**：条目映射到具体技能
|
||||
4. **三档处理**（中性呈现，用户自决）：① 发表 issue ② 本地入库 ③ 不入库
|
||||
5. **钩子**：re-analyze 流程末尾加「可选经验复盘」步骤
|
||||
|
||||
## 设计原则（两条红线）
|
||||
|
||||
### 呈现中性原则
|
||||
- 呈现选项/方案时**禁止「最推荐」「强烈建议」等最高级/强推措辞**，推荐最多到「推荐」级
|
||||
- 选项不带推荐标注，只中性列出选项与适用场景，用户凭内容自决
|
||||
- 类比：视频加背景音乐，画面情绪被音乐带走——强推措辞会绑架用户判断，不允许
|
||||
|
||||
### 隐私脱敏原则
|
||||
- 蒸馏产物**不允许具体到某一个项目**（公司/产品/目标样本名），**暗示也不行**（可推断身份的行业+规模+地域组合、专有协议名、内部代号、独特技术特征组合一律禁止）
|
||||
- 目标泛化为通用描述（「某移动应用」「某嵌入式设备」「某通信协议」），条目只留技术结论（现象/原因/对策）
|
||||
- 来源字段：实战会话 → 只写「实战分析会话」+ 时间（如 `2026-08 实战会话`）；文章扫描 → 可保留公开文章标题/URL
|
||||
- **本地入库同样受约束**：技能库公开发布（npm + 插件市场），本地即公开
|
||||
- 入库/发 issue 前做**脱敏自检**：列出条目中所有专有名词逐项确认已泛化；任一不通过则回炉重蒸
|
||||
|
||||
## 目录结构
|
||||
|
||||
```
|
||||
.claude/skills/re-feedback/
|
||||
├── SKILL.md # 网关：完整工作流 + 选择树 + 常见坑
|
||||
└── references/
|
||||
├── intake.md # 蒸馏方法论：坑条目格式、脱敏规则、归域决策表、去重规则
|
||||
└── issue-template.md # issue 正文模板（gh 提交与草稿共用）
|
||||
```
|
||||
|
||||
- **每技能新增** `references/experience.md`（经验全集，条目带来源与日期；无 references 目录的技能新建）
|
||||
- 各技能 SKILL.md「常见坑与陷阱」：保留精选 + 追加链接到本技能 experience.md
|
||||
- re-analyze/SKILL.md：第三步编排后加「第四步（可选）：经验复盘」→ 调用 [[re-feedback]]
|
||||
|
||||
## 工作流（5 步）
|
||||
|
||||
1. **收集**：三源归一——会话复盘摘要 / 文章 URL 或文本（可走 wxsource.mjs 抓取）/ 手动输入
|
||||
2. **蒸馏**：每条按坑格式 `**标题**：现象——…；原因——…；对策——…`；「坑」（避坑）与「方法」（方法论）统一格式；**同步脱敏**（见隐私脱敏原则）
|
||||
3. **归域**：主题 → 技能映射（决策表 + grep 技能库兜底 + 不确定时问用户，不猜）
|
||||
4. **三档处理**（中性呈现，不带推荐标注）：
|
||||
- **① 发表 issue**：探测 `gh`（`which gh` + `gh auth status` + 仓库可达）→ 可用则 `gh issue create --repo DslsDZC/aihk --label 经验`，标题「经验: <技能>: <一句话>」，正文按 issue-template.md（技能名/现象/原因/对策/来源）；不可用 → 输出 markdown 草稿供手动提交
|
||||
- **② 本地入库**：grep 去重 → 追加到该技能 `references/experience.md`（含来源+日期）→ SKILL.md 精选同步或加链接 → `npm test` 校验
|
||||
- **③ 不入库**：确认后结束
|
||||
5. **（文章扫描路径可选）commit**：「经验: 第N轮扫描入库X篇——<篇目>」，message 列出每技能新增条目
|
||||
|
||||
## 错误处理
|
||||
|
||||
| 情况 | 处理 |
|
||||
|---|---|
|
||||
| gh 未装/未登录/仓库不可达 | 降级为草稿输出 |
|
||||
| gh 报 label「经验」不存在 | 去掉 --label 重试，或提示用户先创建 label |
|
||||
| 归域不确定 | 问用户，不猜 |
|
||||
| 条目重复 | 跳过并告知 |
|
||||
| npm test 失败 | 修复格式后再入库 |
|
||||
| 脱敏自检不通过 | 回炉重蒸，不入库/不发 issue |
|
||||
|
||||
## 校验与测试
|
||||
|
||||
- `validate.mjs` 自动覆盖新技能：frontmatter（name=目录名、description、type: gateway）、[[链接]] 完整性（re-feedback 目录存在后 [[re-feedback]] 链接即合法）
|
||||
- type: gateway 豁免「工具准备」章节校验
|
||||
- 手工验证：`npm test` 全绿 + 用一条样本经验走通三档处理
|
||||
@@ -0,0 +1,94 @@
|
||||
# rev-skills 能力新增设计（2026-08-18）
|
||||
|
||||
## 背景
|
||||
|
||||
rev-skills（89 技能 = 1 入口 + 12 网关 + 76 原子）经四库拆解与技能级对标调研（ctf-skills / headless-ghidra / Android-Pentesting-Skill / android-reverse-engineering-skill 等），识别出 5 项生态已有、本库缺失的能力。用户确认全部新增。
|
||||
|
||||
设计约束（沿用全库红线与原则）：
|
||||
- **红线 1 呈现中性**：禁用「最推荐」等强推措辞
|
||||
- **红线 2 隐私脱敏**：内容不指向具体项目/公司/产品
|
||||
- **不绑定具体工具**：方法为核心，工具为可替换示例（工具准备章节保留跨 OS 安装指引）
|
||||
- 工作区有 3 个未提交文件（re-binary-core / re-mobile / re-protocol 的 SKILL.md）——各提交不得包含它们
|
||||
|
||||
## 变更总览
|
||||
|
||||
| # | 项 | 类型 | 计数影响 |
|
||||
|---|---|---|---|
|
||||
| 1 | re-python | 新原子技能（挂 re-managed） | 90 |
|
||||
| 2 | re-frida-script-author | 新原子技能 | 91 |
|
||||
| 3 | Keystore 审计 | 并入 re-android-native | — |
|
||||
| 4 | Flutter MethodChannel 拦截 | 并入 re-hybrid-app | — |
|
||||
| 5 | svc 裸系统调用检测 | 并入 anti-dynamic-workflow.md | — |
|
||||
|
||||
最终：91 技能 = 1 入口 + 12 网关 + 78 原子。
|
||||
|
||||
## ① re-python（新原子技能）
|
||||
|
||||
- **定位**：Python 打包/混淆样本分析——PyInstaller / PyArmor / Nuitka / Cython / pyc
|
||||
- **frontmatter**：`name: re-python`，description 含触发词：Python打包、PyInstaller、PyArmor、pyc、python exe、Python 样本
|
||||
- **章节**（按 docs/skill-template.md 原子技能规范）：
|
||||
1. 何时使用 / 何时不用——用：PyInstaller 单文件/目录 exe、PyArmor 加固、.pyc 样本、Nuitka/Cython 编译产物；不用：纯 .py 源码混淆（转 [[re-script-deob]]）
|
||||
2. 工具准备——pyinstxtractor（pip 或脚本）、PyArmor-Unpacker（按版本选法）、pycdc / pycdas、python3、file；各工具跨 OS 安装命令
|
||||
3. 操作步骤——
|
||||
1. 识别打包器：`file` + strings 特征（PyInstaller 的 `PyInstaller`/`_MEI` 字符串、PyArmor runtime 特征）
|
||||
2. PyInstaller 解包：pyinstxtractor 提取归档，定位主 .pyc
|
||||
3. PyArmor 解包：按 PyArmor 版本选 PyArmor-Unpacker 三方法之一
|
||||
4. pyc 版本识别：magic 号对照表（按 struct.unpack 读头 4 字节，对照 Python 版本）
|
||||
5. 清理 confusion code：删假函数/死代码，定位核心加密/外泄逻辑
|
||||
4. 跨域联合——[[re-managed]] 网关调用；纯脚本混淆转 [[re-script-deob]]；恶意场景转 [[re-malware]]；pyc 深度还原转 [[re-binary-core]]
|
||||
5. 常见坑与陷阱——pyc 版本不匹配、PyArmor 版本差异、Cython 产物无 pyc、假函数干扰定位
|
||||
- **挂载**：re-managed 选择树加分支「.exe 且含 PyInstaller/PyArmor 特征 → [[re-python]]」
|
||||
|
||||
## ② re-frida-script-author（新原子技能）
|
||||
|
||||
- **定位**：目标特征 → Frida 脚本生成方法论（探 → 选 → 改 → 验）；独立于 re-frida 的执行操作（用户确认独立技能）
|
||||
- **frontmatter**：`name: re-frida-script-author`，description 含触发词：生成Frida脚本、写hook脚本、frida脚本怎么写、写个hook
|
||||
- **章节**：
|
||||
1. 何时使用 / 何时不用——用：需要新脚本时（拦截/绕过/追踪）；不用：执行现成脚本（转 [[re-frida]]）
|
||||
2. 工具准备——frida-tools、python3、目标设备/模拟器；模板素材 [[frida-scripts]]
|
||||
3. 操作步骤——
|
||||
1. 目标侦察：静态特征（目标 API/类名/加固商）+ 基线行为（崩溃迭代法，见 [[anti-dynamic-workflow]]）
|
||||
2. 检测点/目标 API 识别：加密 → 拦截模板；证书固定 → SSL 模板；双向 TLS → keystore 模板；反调试 → 检测绕过模板
|
||||
3. 模板选择：按 [[frida-scripts]] 模板表选骨架
|
||||
4. 改写：包名/类名/方法名/overload 精确匹配（保存 original、带 this 调用）
|
||||
5. 验证：spawn + `--pause` 跑通，输出 JSON 可解析，失败回退步骤 2
|
||||
4. 跨域联合——[[re-frida]] 执行；[[re-mobile]] / [[re-android-native]] 场景衔接；[[anti-dynamic-workflow]] 对抗面
|
||||
5. 常见坑与陷阱——overload 不匹配静默失效、Java.use 缓存覆盖、参数索引版本相关、先探后写不猜
|
||||
- **挂载**：re-frida 跨域联合加「脚本生成 → [[re-frida-script-author]]」
|
||||
|
||||
## ③ Keystore 审计（并入 re-android-native）
|
||||
|
||||
re-android-native 加「Keystore 审计」章节：
|
||||
- AndroidKeyStore 遍历：`KeyStore.getInstance("AndroidKeyStore")` → `aliases()` 枚举
|
||||
- 条目属性：算法/用途/来源（KeyInfo 的 isInsideSecureHardware——TEE vs StrongBox 区分）
|
||||
- 用途判断：签名密钥 / 加密密钥 / 生物绑定（setUserAuthenticationRequired）
|
||||
- 与 hook 的衔接：加密拦截时若密钥来自 Keystore，`getEncoded()` 不可用——记录别名与用途而非密钥字节
|
||||
|
||||
## ④ Flutter MethodChannel 拦截（并入 re-hybrid-app）
|
||||
|
||||
re-hybrid-app 加「Flutter MethodChannel 动态拦截」章节：
|
||||
- hook `io.flutter.plugin.common.MethodChannel` 的 MethodCallHandler（channel 名/方法名/参数 JSON 记录）
|
||||
- engine messenger 层拦截（平台通道消息）
|
||||
- 与 Dart 侧静态观察互补（channel 名与调用点）
|
||||
|
||||
## ⑤ svc 裸系统调用检测（并入 anti-dynamic-workflow.md）
|
||||
|
||||
anti-dynamic-workflow.md 加「裸系统调用检测」节：
|
||||
- 原理：目标自实现系统调用绕过 libc，基于 libc 符号的 hook 与检测失效
|
||||
- 手法：按架构分支特征码（arm64 SYS_OPEN=56、svc 机器码 `01 00 00 D4`；arm SYS_OPEN=5、`00 00 00 EF`）
|
||||
- 可执行段扫描（r-x）过滤 .so 段 → Memory.scan 特征码 → 回读 svc 前一条指令取系统调用号 → 命中 SYS_OPEN 才 attach → 打印文件名与返回值
|
||||
- 注意：arm64 分支参数索引按系统调用约定核对
|
||||
|
||||
## 计数同步
|
||||
|
||||
- README：技能导航（89）→（91）；「12 大类网关 → 76 原子技能」→ 78；导航列表加 re-python / re-frida-script-author 两行
|
||||
- AGENTS.md：（89 个技能）→（91 个技能）
|
||||
- marketplace.json：description「89 个技能」→「91 个技能」
|
||||
- re-managed / re-frida 挂载（见 ①②）
|
||||
|
||||
## 校验与测试
|
||||
|
||||
- validate.mjs 自动覆盖两个新技能（frontmatter name=目录名 / type=atomic / 工具准备章节 / [[链接]] 完整性）
|
||||
- `npm test` 全绿（91 skills validated）
|
||||
- 手工验证：新技能 frontmatter 触发词有效、挂载链接可解析
|
||||
- 不触碰工作区 3 个未提交文件；提交按文件粒度
|
||||
@@ -0,0 +1,79 @@
|
||||
# 中途再路由机制设计（2026-08-18）
|
||||
|
||||
## 背景与问题
|
||||
|
||||
rev-skills（91 技能）的入口流程（re-analyze：探测 → 偏好 → 识别 → 编排）是一次性的：执行中遇到**新证据类型**（发现加壳、加密、反调试、行为异常）时，agent 不会回头重跑任务识别再调对应技能，而是自行硬琢磨。现有「检查新证据」只有一句建议性表述（triage.md:31「每个环节完成后检查是否有新证据改变后续路径」、re-analyze:43「每个环节完成后检查新证据」），无强制机制、无触发表、不可执行。
|
||||
|
||||
**结果**：技能库存在但分析中途不触发——这是技能库价值闭环的核心缺口。
|
||||
|
||||
## 目标
|
||||
|
||||
建立「中途再路由」机制：分析过程中，证据特征出现即触发对应技能；网关完成必查；未命中时按约束换路，禁止无限硬琢磨。
|
||||
|
||||
## 设计
|
||||
|
||||
### ① 新建 `re-analyze/references/rerouting.md`（证据→技能触发表）
|
||||
|
||||
**定位**：运行时证据触发的唯一事实源（区别于 triage.md 的入口「目标→路径」决策表）。
|
||||
|
||||
**A 表：证据特征 → 触发技能**（分析中看到什么 → 调什么）：
|
||||
|
||||
| 证据特征（分析中看到） | 触发技能 |
|
||||
|---|---|
|
||||
| 节表异常（UPX0/.aspack）、熵 >7.0 | [[re-packer-id]] → [[re-anti-analysis]] |
|
||||
| 未知加密算法、S-box/常量指纹、加密流量 | [[re-crypto-id]] |
|
||||
| 硬编码密钥/口令、内存中的 key | [[re-crypto-keys]] |
|
||||
| 解密函数已定位、密文可还原 | [[re-crypto-decrypt]] |
|
||||
| 反调试/反 VM 特征（ptrace、CPUID、时间检测） | [[re-evasion]] / [[re-anti-analysis]] |
|
||||
| 动态注册 JNI、so 函数级加密 | [[re-android-native]] |
|
||||
| 混淆（CFF/花指令/字符串加密） | [[re-deobfuscate]] |
|
||||
| 网络回连/信标/C2 特征 | [[re-netcap]] → [[re-behavior]] |
|
||||
| 持久化/注入/进程树异常 | [[re-behavior]] |
|
||||
| 崩溃/段错误/ASAN 报告 | [[re-crash-triage]] |
|
||||
| Python 打包特征（PyInstaller/PyArmor） | [[re-python]] |
|
||||
| Flutter/RN 引擎特征 | [[re-hybrid-app]] |
|
||||
| 加固商特征（加固壳） | [[re-mobile-pack]] |
|
||||
| RTTI/异常表（.pdata/.xdata）密集 | （re-cpp-abi 待建，先走 [[re-binary-core]]） |
|
||||
|
||||
**B 表：卡住信号 → 换路**（防硬琢磨）：
|
||||
|
||||
| 卡住信号 | 换路 |
|
||||
|---|---|
|
||||
| 同参数重复 ≥2 次无新证据 | 对照 A 表重查 / 换工具视角（[[analysis-contract]] 调查预算） |
|
||||
| 单命令 ≥3 次无进展 | 停下评估，重跑 re-analyze 第二步（任务识别）或换网关 |
|
||||
| 分析超 30 次工具调用无结论 | 回退到最近有产出的环节，按复核格式交付部分结论 |
|
||||
| 目标行为与静态结论矛盾 | 动态侧 [[re-sandbox]] / [[re-tracing]] 对照 |
|
||||
|
||||
**使用规则**：每产出新证据类型 → 查 A 表命中即调技能；每网关完成 → 查 A+B 表；未命中 → 按 B 表约束行动，禁止无限硬琢磨。
|
||||
|
||||
### ② re-analyze/SKILL.md 第三步改双轨强制
|
||||
|
||||
现状（一句建议）改为：
|
||||
|
||||
```
|
||||
第三步编排分派（双轨再路由）：
|
||||
- 轨 1（网关完成必查）：每网关完成后，对照 rerouting.md 的 A/B 表检查新证据；命中 → 调用对应技能，完成后回到轨 1 继续
|
||||
- 轨 2（证据出现即查）：分析中每产出新证据类型（字符串/节表/行为/加密特征），立即对照 A 表；命中 → 调用技能
|
||||
- 未命中任何表项 → 按 B 表约束行动（换思路/回退/交付部分结论），禁止自行硬琢磨
|
||||
```
|
||||
|
||||
### ③ 两个引用点
|
||||
|
||||
- `analysis-contract.md`：加一行「中途再路由：证据触发按 [[rerouting]]（双轨），命中即调技能」
|
||||
- `triage.md:31`：原「每个环节完成后检查是否有新证据改变后续路径」改为指向 [[rerouting]]（统一事实源）
|
||||
|
||||
### ④ re-analyze 常见坑加一条
|
||||
|
||||
- **走完入口不再调用技能**：现象——入口编排后自己硬琢磨，中途发现新特征（壳/加密/反调试）不调对应技能；原因——再路由未执行；对策——按第三步双轨：每网关完成/每新证据对照 [[rerouting]] 触发表，命中即调
|
||||
|
||||
## 校验
|
||||
|
||||
- `npm test` 全绿（91 skills 不变，无新增技能）
|
||||
- rerouting.md 的 [[链接]] 全部指向已存在技能；re-cpp-abi 未建（触发表该行用文字标注待建，不写死链）
|
||||
- 不触碰工作区未提交文件（re-binary-core / re-mobile / re-protocol SKILL.md、README.md）
|
||||
|
||||
## 范围外（后续子项目）
|
||||
|
||||
- 6 个单开技能（re-cpp-abi / re-macos / re-attribution / re-hw-chip / re-ai-attack / re-sdr）
|
||||
- 7 处融入（区块链进阶 / 汽车 IVI-V2X / JS 高级混淆 / 容器镜像 / 内核利用 / 指令级追踪 / 数据库格式）
|
||||
- 均各自独立 brainstorm → spec → plan
|
||||
@@ -0,0 +1,95 @@
|
||||
# 7 处融入设计（2026-08-18）
|
||||
|
||||
## 背景
|
||||
|
||||
rev-skills（97 技能）扩展方向调研的第二批：7 处「应用场景/方法论延伸」融入现有技能（不新增技能、不改计数）。
|
||||
|
||||
设计约束（沿用全库红线与原则）：
|
||||
- **红线 1 呈现中性**：禁用「最推荐」「强烈建议」等最高级强推措辞
|
||||
- **红线 2 隐私脱敏**：内容不指向具体项目/公司/产品
|
||||
- **不绑定具体工具**：方法为核心，工具为可替换示例
|
||||
- 工作区有 3 个未提交文件（re-binary-core / re-mobile / re-protocol 的 SKILL.md）——本计划 7 个融入目标技能均为干净文件，不涉及
|
||||
- 计数不变：97 = 1 入口 + 12 网关 + 84 原子
|
||||
|
||||
## 变更总览
|
||||
|
||||
| # | 融入目标 | 新增章节 | 内容 |
|
||||
|---|---|---|---|
|
||||
| 1 | re-blockchain | ## 非 EVM 链（Solana / Move） | Solana BPF 字节码、Sui/Aptos Move、DeFi/NFT 场景 |
|
||||
| 2 | re-automotive | ## IVI / T-Box / V2X 路径 | 路径分流（IVI→系统分析、T-Box→模组、V2X→协议） |
|
||||
| 3 | re-script-deob | ## 高级混淆对抗（商业混淆器） | JScrambler 类：CFF/字符串加密/死代码注入对抗 |
|
||||
| 4 | re-forensics | ## 容器镜像取证 | 镜像层提取与文件系统分析 |
|
||||
| 5 | re-exploit | ## 内核利用 | 提权原语、堆喷、内核 UAF 路径 |
|
||||
| 6 | re-tracing | ## 指令级追踪 | QEMU 插件、Intel PT、trace 分析 |
|
||||
| 7 | re-disk-forensics | ## 数据库文件格式 | SQLite 页结构、WAL、删除恢复 |
|
||||
|
||||
## ① re-blockchain：非 EVM 链（Solana / Move）
|
||||
|
||||
「## 跨域联合」前插入：
|
||||
|
||||
- **Solana**：BPF 字节码（eBPF 类指令集）——识别特征（ELF + .text 段 BPF 指令）、反编译路径（llvm-objdump BPF 反汇编 / 专用反编译器）、程序账户与指令调度（CPI 调用链）
|
||||
- **Sui / Aptos（Move）**：Move 字节码（模块/资源/函数表）——反编译（move disassembler）、资源模型（对象/能力）对漏洞面的影响（转账/所有权逻辑）
|
||||
- **DeFi/NFT 场景**：池子合约（AMM 常量积公式）、代币标准（ERC-20 变体/SPL）、授权与提现逻辑定位
|
||||
- 流程与 EVM 同构（字节码反编译 → 漏洞分析），指令集与资源模型不同——识别运行时后按对应路径走
|
||||
|
||||
## ② re-automotive：IVI / T-Box / V2X 路径
|
||||
|
||||
「## 跨域联合」前插入：
|
||||
|
||||
- **IVI（车载娱乐系统）**：本质是 Android/Linux 系统——走 [[re-apk]]（Android 应用）/ [[re-firmware]]（系统镜像）路径；关注 OEM 定制层（启动器/诊断接口）
|
||||
- **T-Box（远程信息处理箱）**：蜂窝模组（AT 指令接口）、MCU 固件（[[re-fw-extract]]）、远程控制协议（车控指令）
|
||||
- **V2X（车联网通信）**：DSRC / C-V2X 帧结构 → [[re-protocol]] / [[re-ics]] 路径（协议状态机重建）
|
||||
- 判定规则：按目标形态分流（应用层→移动/系统路径；通信层→协议路径；固件层→固件路径）
|
||||
|
||||
## ③ re-script-deob：高级混淆对抗（商业混淆器）
|
||||
|
||||
「## 跨域联合」前插入：
|
||||
|
||||
- **特征识别**：JScrambler 类商业混淆器特征（bootstrap 加载器、字符串表隐藏、`_0x` 变量重命名模式）
|
||||
- **控制流平坦化（CFF）对抗**：dispatcher 识别（switch 分发中心）→ 状态变量追踪 → 分支还原（与 [[re-deobfuscate]] 的方法衔接）
|
||||
- **字符串加密对抗**：隐藏字符串表定位（解码函数调用点）→ 运行时提取（动态执行取值或静态还原）
|
||||
- **死代码注入对抗**：无引用函数过滤（同 ctf-malware 配方：按调用关系过滤）
|
||||
- 工具链：js-beautify 美化 → 手动还原或半自动脚本；动态侧（[[re-sandbox]] 内执行解码函数）
|
||||
|
||||
## ④ re-forensics：容器镜像取证
|
||||
|
||||
「## 跨域联合」前插入：
|
||||
|
||||
- **镜像结构**：tar 归档 + 分层（每层 = 文件系统快照差异）
|
||||
- **层提取**：`docker save` / `skopeo copy` 导出 → 解包层（复用 [[re-disk-forensics]] / [[re-fw-rootfs]] 的文件系统分析）
|
||||
- **分析重点**：配置与密钥（环境变量/挂载点/entrypoint 脚本）、历史层残留（删除文件在旧层仍可恢复）、恶意镜像判定（启动命令/网络行为）
|
||||
- 输出：镜像内容清单 + 可疑项（与 [[re-ioc]] 衔接）
|
||||
|
||||
## ⑤ re-exploit：内核利用
|
||||
|
||||
「## 跨域联合」前插入：
|
||||
|
||||
- **提权原语**：modprobe_path 覆写、cred 结构覆写、io_uring/BPF 子系统利用面
|
||||
- **堆喷与对象布局**：堆喷策略、对象重叠（UAF 后伪造对象）、SLUB 分配器行为
|
||||
- **内核 UAF 利用路径**：漏洞触发 → 对象重用 → 控制流劫持（函数指针/ops 表）
|
||||
- 与用户态同框架：fuzz（[[re-fuzzing]]）→ crash（[[re-crash-triage]]）→ 利用（本技能内核路径）
|
||||
- 环境：调试内核（KASAN/KASLR 关闭或绕过）、gdb/kgdb
|
||||
|
||||
## ⑥ re-tracing：指令级追踪
|
||||
|
||||
「## 跨域联合」前插入：
|
||||
|
||||
- **QEMU 插件**：`-plugin` 指令级 trace（insn 粒度、call/ret 路径）、插桩事件（guest 代码块）
|
||||
- **Intel PT**：硬件 trace（`perf record -e intel_pt`）→ 解码（perf script / 第三方解析）、分支流还原
|
||||
- **trace 分析**：热点（执行频次）、路径还原（调用链）、与反混淆衔接（跟踪真实执行路径绕过静态混淆）
|
||||
- 输出：指令级执行流（供 [[analysis-contract]] 证据存档）
|
||||
|
||||
## ⑦ re-disk-forensics：数据库文件格式
|
||||
|
||||
「## 跨域联合」前插入：
|
||||
|
||||
- **SQLite 结构**：页头（page header）、btree 页（interior/leaf）、记录格式（varint/类型码）、溢出页
|
||||
- **WAL 恢复**：WAL 文件解析（未提交事务的帧）、checkpoint 边界
|
||||
- **取证应用**：浏览器/App 数据库（删除记录恢复——freelist 页）、未提交事务提取
|
||||
- 工具：sqlite3 CLI（只读模式 `-readonly`）、页级解析脚本
|
||||
|
||||
## 校验与测试
|
||||
|
||||
- 每处融入后 `npm test` 全绿（97 skills 不变）
|
||||
- 融入章节的 [[链接]] 全部指向已存在技能（re-apk/re-firmware/re-protocol/re-ics/re-fw-extract/re-disk-forensics/re-fw-rootfs/re-ioc/re-deobfuscate/re-sandbox/re-fuzzing/re-crash-triage/analysis-contract 等）
|
||||
- 不触碰工作区 3 个未提交文件
|
||||
@@ -0,0 +1,142 @@
|
||||
# 6 个单开技能设计（2026-08-18）
|
||||
|
||||
## 背景
|
||||
|
||||
rev-skills（91 技能）经扩展方向调研，确认 6 个方法论独特、值得单开的技能。用户确认全部新增。
|
||||
|
||||
设计约束（沿用全库红线与原则）：
|
||||
- **红线 1 呈现中性**：禁用「最推荐」「强烈建议」等最高级强推措辞
|
||||
- **红线 2 隐私脱敏**：内容不指向具体项目/公司/产品（攻击者身份归因只写方法不写真实案例）
|
||||
- **不绑定具体工具**：方法为核心，工具为可替换示例（工具准备章节保留跨 OS 安装指引）
|
||||
- 工作区有 4 个未提交文件（re-binary-core / re-mobile / re-protocol 的 SKILL.md、README.md）——各提交不得包含它们；re-binary-core 网关子技能列表挂载时**叠加编辑**该文件需谨慎（该文件有用户未提交改动，挂载行写入会与用户改动共存于工作区，提交时只 add 本任务文件会连同用户改动——**改用 git add 后以 patch 粒度提交或由用户确认**，实施时控制器处理）
|
||||
|
||||
## 变更总览
|
||||
|
||||
| # | 新技能 | 类型 | 挂载 | 计数 |
|
||||
|---|---|---|---|---|
|
||||
| 1 | re-cpp-abi | 原子 | re-binary-core 网关 | 92 |
|
||||
| 2 | re-macos | 原子 | 独立 | 93 |
|
||||
| 3 | re-attribution | 原子 | re-forensics 网关 | 94 |
|
||||
| 4 | re-hw-chip | 原子 | 独立 | 95 |
|
||||
| 5 | re-ai-attack | 原子 | 独立 | 96 |
|
||||
| 6 | re-sdr | 原子 | 独立 | 97 |
|
||||
|
||||
最终：97 技能 = 1 入口 + 12 网关 + 84 原子。
|
||||
|
||||
## ① re-cpp-abi（挂 re-binary-core）
|
||||
|
||||
- **定位**：现代 C++ 二进制（异常/RTTI/模板/lambda）反编译混乱时的专门恢复方法
|
||||
- **frontmatter**：`name: re-cpp-abi`；触发词：C++逆向、RTTI、虚表恢复、异常处理、C++ ABI、mangling
|
||||
- **章节**（按 docs/skill-template.md 原子技能规范）：
|
||||
1. 何时使用 / 何时不用——用：RTTI/异常表密集的二进制、反编译结果混乱的 C++ 目标；不用：C 代码/纯汇编（走 re-binary-core 通用路径）
|
||||
2. 工具准备——readelf / llvm-objdump（节表与异常表）、gdb（异常断点）、c++filt / undname（mangling 解码）、Ghidra/IDA 脚本（RTTI 遍历）；跨 OS 安装命令
|
||||
3. 操作步骤——
|
||||
1. ABI 识别（Itanium vs MSVC：mangling 特征 `_ZN...` / `??_...`）
|
||||
2. RTTI 重建（_RTTICompleteObjectLocator / _RTTITypeDescriptor 链 → 类继承图）
|
||||
3. 虚表恢复（vtable 定位、类关系反推、调用点定名）
|
||||
4. 异常处理表（.pdata/.xdata、SEH/C++ EH 表 → 控制流恢复）
|
||||
5. 模板/lambda 识别（符号特征与调用模式）
|
||||
6. mangling 解码（c++filt / undname 批量）
|
||||
4. 跨域联合——[[re-binary-core]] 网关调用；[[re-ghidra]] / [[re-ida]] 反编译底座；[[re-deobfuscate]] 混淆衔接
|
||||
5. 常见坑与陷阱——ABI 误判导致 RTTI 解析失败、异常表版本差异、模板展开导致的符号爆炸、lambda 局部类无 RTTI
|
||||
- **挂载**：re-binary-core 子技能列表加 re-cpp-abi；rerouting A 表 RTTI 行改 [[re-cpp-abi]]（去「待建」）
|
||||
|
||||
## ② re-macos（独立）
|
||||
|
||||
- **定位**：macOS 原生应用逆向——App Bundle / 签名公证 / entitlements / 沙箱 / 钥匙串与 Secure Enclave
|
||||
- **frontmatter**：触发词：macOS逆向、mac app、entitlements、Secure Enclave、钥匙串、TCC、codesign
|
||||
- **章节**：
|
||||
1. 何时使用 / 何时不用——用：macOS 原生/闭源应用、带签名公证与沙箱的目标；不用：iOS 应用（转 [[re-ios]]）
|
||||
2. 工具准备——codesign / spctl / otool / lipo（签名与 Mach-O 工具）、Hopper/IDA/Ghidra、lldb；跨 OS（macOS 为主，Linux 可分析 Mach-O 静态）
|
||||
3. 操作步骤——
|
||||
1. 包结构（App Bundle、Info.plist、签名/公证检查 `codesign -dv` / `spctl -a`）
|
||||
2. entitlements 与沙箱（`codesign -d --entitlements`、沙箱 profile、TCC 权限库）
|
||||
3. 钥匙串与 Secure Enclave（钥匙串 ACL、可访问性类、硬件密钥——getEncoded 不可用的等效场景）
|
||||
4. dyld 加载链（LC_*、注入面、Dylib Hijacking）
|
||||
5. 反调试与保护（taskgated、代码签名校验对抗、Gatekeeper 绕过面分析）
|
||||
4. 跨域联合——[[re-ios]] 互补（iOS 越狱生态）；[[re-format-macho]] 格式底座；[[re-lldb]] 调试
|
||||
5. 常见坑与陷阱——签名校验在多处（加载/运行/更新）、TCC 权限数据在系统库、Secure Enclave 密钥不可提取、公证检查离线不可复现
|
||||
- **挂载**：独立；re-ios 跨域联合加引用
|
||||
|
||||
## ③ re-attribution（挂 re-forensics）
|
||||
|
||||
- **定位**：威胁归因方法论——从线索到攻击者身份的推理链（区别于 re-ti 的情报查询）
|
||||
- **frontmatter**：触发词：归因、APT、attribution、攻击者身份、基础设施图谱、钻石模型
|
||||
- **章节**：
|
||||
1. 何时使用 / 何时不用——用：情报归因请求、基础设施关联分析；不用：单个 IOC 查询（转 [[re-ti]]）
|
||||
2. 工具准备——关联查询工具（Passive DNS、证书透明日志、Whois）、MISP、图分析工具；跨 OS 安装
|
||||
3. 操作步骤——
|
||||
1. 钻石模型（受害者/基础设施/能力/对手四角关系）
|
||||
2. 基础设施图谱（域名/IP/证书/Whois 关联聚类）
|
||||
3. 能力与样本归因（代码复用、TTP 对比、时间线对齐）
|
||||
4. 置信度分级（低/中/高 + 证据链，避免过度归因）
|
||||
5. 报告（脱敏、声明边界）
|
||||
4. 跨域联合——[[re-ti]] 情报输入；[[re-ioc]] 指标提取；[[re-behavior]] 行为证据
|
||||
5. 常见坑与陷阱——基础设施重叠导致的误归因、跳板机≠归属、置信度虚高、脱敏红线
|
||||
- **挂载**：re-forensics 网关子技能列表加 re-attribution
|
||||
|
||||
## ④ re-hw-chip（独立）
|
||||
|
||||
- **定位**：物理层硬件逆向——芯片解密、PCB 电路分析、硬件木马检测
|
||||
- **frontmatter**：触发词：芯片逆向、去封装、decapping、PCB、硬件木马、电路分析、裸片
|
||||
- **章节**：
|
||||
1. 何时使用 / 何时不用——用：物理芯片/板级分析（固件提取失败后的物理层）；不用：固件级分析（转 [[re-fw-extract]] / [[re-hardware-io]]）
|
||||
2. 工具准备——显微镜/探针台、decapping 设备与耗材、逻辑分析仪、热成像；耗材类工具给选购指引
|
||||
3. 操作步骤——
|
||||
1. 去封装（化学/激光 decap，风险控制与防护）
|
||||
2. 裸片分析（显微成像、金属层/ROM 提取）
|
||||
3. 探针与信号提取（FIB 修改、总线嗅探）
|
||||
4. PCB 电路分析（走线还原、IC 标识、JTAG/SWD 引脚定位）
|
||||
5. 硬件木马检测（冗余逻辑、触发器特征、功耗/时序异常）
|
||||
4. 跨域联合——[[re-hardware-io]] 接口提取衔接；[[re-fw-extract]] 固件侧；[[re-sdr]] 无线侧
|
||||
5. 常见坑与陷阱——decap 破坏性不可逆、探针负载改变信号、FIB 高成本、木马误报
|
||||
- **挂载**：独立；re-hardware-io 跨域引用
|
||||
|
||||
## ⑤ re-ai-attack（独立）
|
||||
|
||||
- **定位**：AI 模型攻击与取证——提取攻击、指纹/水印、成员推断
|
||||
- **frontmatter**：触发词：模型提取、模型窃取、水印检测、模型指纹、成员推断、对抗样本
|
||||
- **章节**：
|
||||
1. 何时使用 / 何时不用——用：模型泄露/窃取取证、API 模型攻击评估；不用：模型文件格式解析（转 [[re-ai-model]]）
|
||||
2. 工具准备——python3、ML 工具链（torch/tf）、查询接口客户端；跨 OS 安装
|
||||
3. 操作步骤——
|
||||
1. 模型提取攻击（API 查询蒸馏、输出分布重建、置信度利用）
|
||||
2. 模型指纹/水印（嵌入检测、指纹提取、窃取取证）
|
||||
3. 成员推断（训练数据泄露判定）
|
||||
4. 对抗样本基础（黑盒/白盒扰动）
|
||||
4. 跨域联合——[[re-ai-model]] 格式与权重侧；[[re-feedback]] 经验（攻击案例脱敏沉淀）
|
||||
5. 常见坑与陷阱——查询预算限制、置信度不可得时降级、水印被抹除、成员推断误报
|
||||
- **挂载**：独立；re-ai-model 跨域引用
|
||||
|
||||
## ⑥ re-sdr（独立）
|
||||
|
||||
- **定位**：射频逆向——信号采集、解调、协议帧恢复
|
||||
- **frontmatter**：触发词：SDR、射频、信号分析、解调、RTL-SDR、HackRF
|
||||
- **章节**：
|
||||
1. 何时使用 / 何时不用——用：无线协议/遥控/遥测信号；不用：有线协议（转 [[re-protocol]]）
|
||||
2. 工具准备——RTL-SDR/HackRF、GNU Radio、inspectrum、Universal Radio Hacker (URH)；跨 OS 安装
|
||||
3. 操作步骤——
|
||||
1. 信号采集与频谱分析（中心频率/带宽/调制识别）
|
||||
2. 解调（AM/FM/PSK/QAM/FSK）
|
||||
3. 帧同步与协议恢复（preamble、同步字、URH 位流恢复）
|
||||
4. 重放与交互（授权测试场景）
|
||||
4. 跨域联合——[[re-iot-proto]] 无线 IoT 协议衔接；[[re-feedback]] 经验沉淀
|
||||
5. 常见坑与陷阱——频率偏移/采样率错误、调制误判、重放需授权、法律边界
|
||||
- **挂载**：独立；re-iot-proto 跨域引用
|
||||
|
||||
## 同步
|
||||
|
||||
- rerouting A 表 RTTI 行：`（re-cpp-abi 待建，先走 [[re-binary-core]]）` → `[[re-cpp-abi]]`
|
||||
- README：技能导航（91）→（97）、「12 大类网关 → 78 原子技能」→ 84、导航加 6 行
|
||||
- AGENTS.md：（91 个技能）→（97 个技能）、原子技能（78）→（84）
|
||||
- marketplace.json：91 个技能 → 97 个技能
|
||||
- re-binary-core 网关子技能列表加 re-cpp-abi（**该文件有用户未提交改动——提交粒度由控制器处理**）
|
||||
- re-forensics 网关子技能列表加 re-attribution
|
||||
- re-ios / re-hardware-io / re-ai-model / re-iot-proto 跨域联合各加一行引用
|
||||
|
||||
## 校验与测试
|
||||
|
||||
- validate.mjs 自动覆盖 6 个新技能（frontmatter name=目录名 / type=atomic / 工具准备 / 链接）
|
||||
- `npm test` 全绿（97 skills validated）
|
||||
- rerouting A 表 RTTI 行改 [[re-cpp-abi]] 后链接可解析
|
||||
- 不触碰工作区 4 个未提交文件（re-binary-core 网关挂载例外，控制器处理提交粒度）
|
||||
@@ -0,0 +1,137 @@
|
||||
# 6 个新技能设计 v2（2026-08-18）
|
||||
|
||||
## 背景
|
||||
|
||||
rev-skills（101 技能）生态对标盘点后的第二批缺口：恶意文档 / 变体对比 / 威胁狩猎 / 移动取证 / 隐写 / 浏览器扩展。用户确认全部新增。
|
||||
|
||||
设计约束（沿用全库红线与原则）：
|
||||
- **红线 1 呈现中性**：禁用「最推荐」「强烈建议」等最高级强推措辞
|
||||
- **红线 2 隐私脱敏**：内容不指向具体项目/公司/产品
|
||||
- **不绑定具体工具**：方法为核心，工具为可替换示例（工具准备保留跨 OS 安装指引）
|
||||
- 工作区已干净，无未提交文件冲突
|
||||
- 当前分支 `main`
|
||||
|
||||
## 变更总览
|
||||
|
||||
| # | 新技能 | 类型 | 挂载 | 计数 |
|
||||
|---|---|---|---|---|
|
||||
| 1 | re-doc-malware | 原子 | re-malware | 102 |
|
||||
| 2 | re-variant | 原子 | re-binary-core | 103 |
|
||||
| 3 | re-hunting | 原子 | re-forensics | 104 |
|
||||
| 4 | re-mobile-forensics | 原子 | re-forensics | 105 |
|
||||
| 5 | re-stego | 原子 | re-ctf | 106 |
|
||||
| 6 | re-browser-ext | 原子 | re-managed | 107 |
|
||||
|
||||
最终：107 技能 = 1 入口 + 12 网关 + 94 原子。
|
||||
|
||||
## ① re-doc-malware（挂 re-malware）
|
||||
|
||||
- **定位**：恶意文档分析——PDF/Office 武器化、宏链、文档漏洞利用
|
||||
- **frontmatter**：触发词：恶意文档、钓鱼文档、PDF恶意、宏文档、docm、文档漏洞、恶意附件
|
||||
- **章节**：
|
||||
1. 何时使用 / 何时不用——用：钓鱼附件（PDF/Office/RTF）、文档漏洞利用样本、宏文档；不用：纯脚本宏（转 [[re-script-deob]]）
|
||||
2. 工具准备——pdf-parser / peepdf（PDF 结构）、olevba / oledump（Office 宏，已有）、LibreOffice（沙箱打开验证）、7z（OLE 解包）；跨 OS 安装
|
||||
3. 操作步骤——
|
||||
1. 文档类型识别（`file`：PDF/CFB OLE/RTF/OOXML zip）
|
||||
2. PDF 恶意分析（对象树、JS 动作流 openAction/AA、嵌入文件、漏洞特征——CVE 对应结构）
|
||||
3. Office 分析（宏链 AutoOpen/Workbook_Open、DDE 域、外部链接、OLE 嵌入对象）
|
||||
4. 载荷提取（脚本/URL/二进制 → [[re-script-deob]] / [[re-ioc]]）
|
||||
5. 动态验证（[[re-sandbox]] 内打开文档，网络隔离）
|
||||
4. 跨域联合——[[re-malware]] 网关；[[re-script-deob]]；[[re-sandbox]]；[[re-ioc]]
|
||||
5. 常见坑与陷阱——PDF 对象流压缩（FlateDecode 未解）、Office 宏被混淆（衔接去混淆链）、文档漏洞版本特征、沙箱检测文档（延迟执行）
|
||||
- **挂载**：re-malware 子技能列表 + 选择树分支（钓鱼附件 → [[re-doc-malware]]）
|
||||
|
||||
## ② re-variant（挂 re-binary-core）
|
||||
|
||||
- **定位**：二进制变体/补丁对比——函数匹配、N-day 补丁 diff、变体溯源
|
||||
- **frontmatter**：触发词：二进制对比、补丁对比、N-day、变体分析、BinDiff、函数匹配、样本相似
|
||||
- **章节**：
|
||||
1. 何时使用 / 何时不用——用：补丁前后对比（漏洞定位）、家族变体关联、样本溯源；不用：单样本深度分析（走 re-binary-core 通用）
|
||||
2. 工具准备——BinDiff / Diaphora（IDA/Ghidra 插件，安装指引）、radiff2/rz-diff（rizin）、readelf；跨 OS 安装
|
||||
3. 操作步骤——
|
||||
1. 函数匹配（指令哈希、调用图相似度、导入导出对齐——BinDiff/Diaphora 思路）
|
||||
2. 补丁 diff（修复前后 → 变更函数定位 → 漏洞点推断）
|
||||
3. 变体溯源（家族内样本关联：相似度聚类、演进链）
|
||||
4. 输出差异清单（变更函数表 + 相似度，[[analysis-contract]] 衔接）
|
||||
4. 跨域联合——[[re-binary-core]] 网关；[[re-ghidra]] / [[re-ida]] 反编译底座
|
||||
5. 常见坑与陷阱——编译器差异干扰匹配、strip 后符号缺失、架构差异（跨架构对比降级）、大量相似导致误关联
|
||||
- **挂载**：re-binary-core 子技能列表 + 选择树分支（补丁/N-day 对比 → [[re-variant]]）
|
||||
|
||||
## ③ re-hunting（挂 re-forensics）
|
||||
|
||||
- **定位**：威胁狩猎方法论——假设驱动、遥测选择、验证闭环
|
||||
- **frontmatter**：触发词：威胁狩猎、狩猎、hunting、假设驱动、遥测分析、异常检测
|
||||
- **章节**：
|
||||
1. 何时使用 / 何时不用——用：主动狩猎请求（"环境里有没有 X"）；不用：已知样本分析（[[re-behavior]]）、IOC 查询（[[re-ti]]）
|
||||
2. 工具准备——日志分析工具（jq/grep/awk 通用）、SIEM 查询（按环境）、ATT&CK 导航；跨 OS 说明
|
||||
3. 操作步骤——
|
||||
1. 狩猎假设生成（ATT&CK 技术对齐基线、威胁情报输入 [[re-ti]]）
|
||||
2. 遥测源选择（端点/网络/日志——按假设选数据源）
|
||||
3. 基线 vs 异常（统计基线、规则匹配、异常聚类）
|
||||
4. 验证闭环（命中确认——误报排除、[[re-behavior]] 深挖、证据存档 [[analysis-contract]]）
|
||||
4. 跨域联合——[[re-forensics]] 网关；[[re-ti]]；[[re-behavior]]；[[re-ioc]]
|
||||
5. 常见坑与陷阱——基线污染（环境本身被攻陷）、遥测缺失导致盲区、误报疲劳、假设过窄
|
||||
- **挂载**：re-forensics 子技能列表
|
||||
|
||||
## ④ re-mobile-forensics（挂 re-forensics）
|
||||
|
||||
- **定位**：移动设备取证——Android/iOS 数据提取、备份解析、删除恢复
|
||||
- **frontmatter**：触发词：移动取证、手机取证、ADB备份、iTunes备份、手机数据提取
|
||||
- **章节**：
|
||||
1. 何时使用 / 何时不用——用：设备备份/镜像数据提取、应用数据取证；不用：App 逆向（[[re-mobile]]）、通用文件系统（[[re-disk-forensics]]）
|
||||
2. 工具准备——adb（Android）、libimobiledevice（iOS）、备份解析工具、sqlite3（[[re-disk-forensics]] 衔接）；跨 OS 安装
|
||||
3. 操作步骤——
|
||||
1. Android 提取（ADB backup 解析（ab 格式）、应用沙箱（run-as/root）、SQLite 数据库）
|
||||
2. iOS 提取（iTunes 备份解析（manifest.db）、加密备份、Keychain 条目）
|
||||
3. 删除恢复与时间线（SQLite 删除记录——[[re-disk-forensics]] 方法、应用时间线重建）
|
||||
4. 跨域联合——[[re-forensics]] 网关；[[re-disk-forensics]]；[[re-mobile]] 衔接
|
||||
5. 常见坑与陷阱——加密备份无密钥、ADB backup 权限限制（应用未启用 backup）、iOS 备份字段混淆（manifest 哈希路径）、时间线时区
|
||||
- **挂载**：re-forensics 子技能列表
|
||||
|
||||
## ⑤ re-stego（挂 re-ctf）
|
||||
|
||||
- **定位**：隐写术检测与提取——LSB、文件尾附加、隐写工具链
|
||||
- **frontmatter**：触发词：隐写、stego、LSB、文件尾附加、隐写提取、图片隐写
|
||||
- **章节**：
|
||||
1. 何时使用 / 何时不用——用：隐写怀疑（CTF 题/取证对象）、文件尾异常；不用：正常文件分析（走各域技能）
|
||||
2. 工具准备——zsteg / steghide / binwalk（尾部扫描已有）/ strings / python3；跨 OS 安装
|
||||
3. 操作步骤——
|
||||
1. 文件尾附加检测（binwalk/hexdump 尾部 → 附加数据提取——衔接 [[re-patching]] 尾部附加经验）
|
||||
2. 图片 LSB（zsteg 扫描、逐位提取、通道分析）
|
||||
3. 其他载体（音频相位/频谱、文件冗余区）
|
||||
4. 提取验证（magic 检查、可读性验证）
|
||||
4. 跨域联合——[[re-ctf]] 网关；[[re-fw-extract]] 的 binwalk 复用；[[re-triage]] 初勘
|
||||
5. 常见坑与陷阱——LSB 顺序（行序/位序）、多载体误判、隐写前压缩（先提取再解压——提取物查压缩头：zlib `78 9C` / gzip `1F 8B`）、工具输出噪声
|
||||
- **挂载**：re-ctf 子技能列表
|
||||
|
||||
## ⑥ re-browser-ext（挂 re-managed）
|
||||
|
||||
- **定位**：浏览器扩展逆向——权限清单、恶意行为、混淆还原
|
||||
- **frontmatter**：触发词：浏览器扩展、Chrome扩展、Firefox扩展、恶意扩展、extension
|
||||
- **章节**：
|
||||
1. 何时使用 / 何时不用——用：扩展文件（crx/xpi/zip）、恶意扩展行为分析；不用：网页 JS（[[re-script-deob]] 覆盖纯脚本）
|
||||
2. 工具准备——unzip/7z（解包）、jq（manifest 解析）、node（扩展脚本运行）、浏览器（加载验证）；跨 OS 安装
|
||||
3. 操作步骤——
|
||||
1. 解包与结构（crx/xpi = zip + manifest.json，权限清单解析）
|
||||
2. 恶意行为定位（CSP 绕过、数据外泄（fetch/beacon）、权限滥用（tabs/storage/webRequest）、后台脚本）
|
||||
3. 混淆还原（衔接 [[re-script-deob]] 高级混淆对抗）
|
||||
4. 上架审查绕过面分析（动态加载、远程代码、obfuscation 检测规避）
|
||||
4. 跨域联合——[[re-managed]] 网关；[[re-script-deob]]；[[re-netcap]] 网络行为衔接
|
||||
5. 常见坑与陷阱——manifest 版本差异（MV2/MV3 权限模型）、远程代码策略（MV3 禁远程 JS）、动态注入绕过静态分析、扩展沙箱与页面上下文隔离
|
||||
- **挂载**：re-managed 子技能列表 + 选择树分支（浏览器扩展 → [[re-browser-ext]]）
|
||||
|
||||
## 同步
|
||||
|
||||
- 5 个网关子技能列表挂载（re-malware +1 / re-binary-core +1 / re-forensics +2 / re-ctf +1 / re-managed +1）
|
||||
- re-malware / re-binary-core / re-managed 选择树各加分支
|
||||
- rerouting A 表加 3 行：PDF/Office 宏特征 → [[re-doc-malware]]；补丁/N-day 对比需求 → [[re-variant]]；文件尾附加/图片异常 → [[re-stego]]
|
||||
- README：技能导航（101）→（107）、「12 大类网关 → 88 原子技能」→ 94、导航加 6 行
|
||||
- AGENTS.md：（101 个技能）→（107 个技能）、原子技能（88）→（94）
|
||||
- marketplace.json：101 个技能 → 107 个技能
|
||||
|
||||
## 校验与测试
|
||||
|
||||
- validate.mjs 自动覆盖 6 个新技能（frontmatter name=目录名 / type=atomic / 工具准备 / 链接）
|
||||
- `npm test` 全绿（107 skills validated）
|
||||
- rerouting 新增行的 [[链接]] 指向已存在技能
|
||||
- 工作区干净，无未提交文件冲突
|
||||
@@ -0,0 +1,122 @@
|
||||
# 技能库第三轮扩充设计（2026-08-20）
|
||||
|
||||
## 背景
|
||||
|
||||
107 技能覆盖审查后识别 13 个实战缺口（移动端 Flutter/RN、固件 RTOS/MCU/MIPS/TEE、语言运行时 Lua/老运行时、无线 BLE/NFC、图形 Shader、硬件侧信道、新兴 HarmonyOS）。用户定案：**全上**，融合优先——可融合的进现有技能，无自然宿主的独立成技能。
|
||||
|
||||
归位决策（用户已确认）：
|
||||
- 独立 5 个：re-flutter、re-rtos、re-mips、re-tee、re-harmonyos
|
||||
- 融合 8 项进 6 个技能：re-hybrid-app(+RN/Hermes)、re-iot-proto(+BLE/+NFC)、re-game(+Lua/+Shader)、re-hw-chip(+侧信道)、re-fw-extract(+MCU)、re-format-pe(+Delphi/VB6)
|
||||
|
||||
总数 107 → **112**（5 新增 + 107）。
|
||||
|
||||
## 变更总览
|
||||
|
||||
| # | 类型 | 目标 | 内容 |
|
||||
|---|---|---|---|
|
||||
| 1 | 新增 | re-flutter | Flutter/Dart AOT 逆向（libapp.so、AOT snapshot、Dart 符号定位） |
|
||||
| 2 | 新增 | re-rtos | RTOS 结构分析（FreeRTOS/ThreadX/Zephyr：TCB/任务表/内核对象） |
|
||||
| 3 | 新增 | re-mips | MIPS ISA + 路由器固件逆向 |
|
||||
| 4 | 新增 | re-tee | TEE/TrustZone（OP-TEE、Trusted App、SMC 接口） |
|
||||
| 5 | 新增 | re-harmonyos | HarmonyOS（hap 包、ArkTS 字节码） |
|
||||
| 6 | 融合 | re-hybrid-app | +React Native/Hermes 字节码章节 |
|
||||
| 7 | 融合 | re-iot-proto | +BLE 链路层章节 +NFC/智能卡章节 |
|
||||
| 8 | 融合 | re-game | +Lua/LuaJIT 字节码章节 +Shader 反汇编章节 |
|
||||
| 9 | 融合 | re-hw-chip | +侧信道/故障注入章节 |
|
||||
| 10 | 融合 | re-fw-extract | +MCU 镜像分析章节（8051/AVR/PIC） |
|
||||
| 11 | 融合 | re-format-pe | +Delphi/VB6 老运行时识别章节 |
|
||||
|
||||
## 新增技能边界（实现者大纲）
|
||||
|
||||
### re-flutter（原子，挂 re-mobile 组）
|
||||
|
||||
- 用：Flutter App（Android `libapp.so` / iOS `App.framework`、`libflutter.so`、`kernel_blob.bin`）；不用：纯原生 App（走 re-apk/re-ios）
|
||||
- 核心内容：Dart AOT snapshot 结构（blobs 分区：ObjCode/rodata/instructions/strings）、字符串定位与交叉引用、Dart 符号还原（`--split-debug-info` 的 symbol 映射文件）、引擎与业务代码区分、Flutter 特有混淆（tree-shaking 后的名字处理）
|
||||
- 工具：无官方 Dart 反编译器——blob 手动解析、`strings`+IDA/Ghidra 配合、动态侧 frida hook Dart VM 入口（`Dart_CreateRootLibrary`/`dart:...` 库注册点）或 Dart VM Service
|
||||
- 跨域：[[re-apk]] [[re-ios]] [[re-mobile]] [[re-frida]] [[re-hybrid-app]]
|
||||
|
||||
### re-rtos（原子，挂 re-firmware 组）
|
||||
|
||||
- 用：MCU/IoT 固件跑 RTOS（FreeRTOS/ThreadX/Zephyr/RT-Thread）；不用：裸机固件（MCU 镜像节，见 re-fw-extract）
|
||||
- 核心内容：RTOS 识别（启动代码 → 调度器入口 `osKernelStart`/`xTaskCreate` 链）、TCB/任务表结构定位（FreeRTOS `pxCurrentTCB` 静态表、ThreadX 双向链表、Zephyr `_kernel` 结构）、任务栈识别、内核对象（队列/信号量/互斥）定位、按任务拆分反编译
|
||||
- 跨域：[[re-fw-extract]] [[re-fw-emulate]] [[re-binary-core]] [[re-mcu]]
|
||||
|
||||
### re-mips（原子，挂 re-binary-core 组）
|
||||
|
||||
- 用：MIPS 固件/恶意软件（路由器、嵌入式）；不用：ARM/x86 系（走 re-binary-core 通用）
|
||||
- 核心内容：MIPS32/64 调用约定与**延迟槽**（坑）、GP 相对寻址/重定位、反编译注意（伪指令、`$ra` 链）、路由器固件 web 后端分析（httpd 认证/命令注入模式）、busybox 集成命令识别
|
||||
- 跨域：[[re-fw-extract]] [[re-fw-rootfs]] [[re-binary-core]] [[re-ghidra]] [[re-vuln]]
|
||||
|
||||
### re-tee（原子，挂 re-mobile 组或 re-firmware 组，实现时定）
|
||||
|
||||
- 用：TrustZone/OP-TEE、Trusted App、secure storage、设备密钥相关逆向；不用：普通内核（re-kernel 是 Windows 侧）
|
||||
- 核心内容：TEE 架构（normal/secure world 划分、SMC 接口、EL0-EL3）、OP-TEE 结构（core 与 TA 分离、`.ta` 二进制格式）、Trusted App 分析（入口/命令分发/secure storage 对象）、主机侧调用面（ioctl/`TEE_IOC`）、常见厂商 TEE 差异
|
||||
- 跨域：[[re-fw-extract]] [[re-kernel]] [[re-mobile]] [[re-hw-chip]]
|
||||
|
||||
### re-harmonyos（原子，挂 re-mobile 组）
|
||||
|
||||
- 用：鸿蒙 App（hap/hsp/har 包）、ArkTS 字节码；不用：普通 Android（re-apk）
|
||||
- 核心内容：hap 包结构（与 APK 同源：resources/index、ets/ 目录、module.json）、ArkCompiler 字节码（`.abc`）特征与反汇编思路、JS/TS 业务资源提取、与 Android 工具链的复用与差异（jadx 思路可借鉴、dex 层不存在）
|
||||
- 跨域：[[re-apk]] [[re-hybrid-app]] [[re-java]] [[re-mobile]]
|
||||
|
||||
## 融合内容清单（实现者大纲）
|
||||
|
||||
### re-hybrid-app +1 章（React Native / Hermes）
|
||||
|
||||
- `.hbc` 字节码识别（文件头 `c61fbc03` 类魔数）、Hermes 反汇编（hermesc 系）、JS bundle 提取（Metro 打包结构）、RN 原生桥接（NativeModules）定位
|
||||
- 既有 Flutter 名义覆盖补一句指向 [[re-flutter]]（不重复内容）
|
||||
|
||||
### re-iot-proto +2 章（BLE / NFC）
|
||||
|
||||
- BLE：链路层嗅探（nRF 系硬件/软件抓包）、广播包与连接事件解析、配对/加密协商（LE Legacy / Secure Connections）、GATT 服务与特征枚举
|
||||
- NFC/智能卡：ISO14443 帧、APDU 交互、MIFARE Classic（Crypto-1 弱点）、proxmark3 类设备流程
|
||||
|
||||
### re-game +2 章（Lua / Shader）
|
||||
|
||||
- Lua：Lua/LuaJIT 字节码识别与反汇编（luac 系）、Cocos 系游戏脚本资源提取（jsc/luac 混淆变体）、脚本函数 hook（[[re-frida]] 或游戏内存侧）
|
||||
- Shader：SPIR-V（spirv-dis）、DXIL/DXBC 反汇编、GLSL 还原（spirv-cross 类）、找渲染入口与着色器常量
|
||||
|
||||
### re-hw-chip +1 章（侧信道/故障注入）
|
||||
|
||||
- SPA/DPA 功耗分析基础、采集设备与流程（chipwhisperer 类）、时钟/电压故障注入、glitch 定位与重放、与去封装工序衔接
|
||||
|
||||
### re-fw-extract +1 章（MCU 镜像）
|
||||
|
||||
- MCU 程序镜像格式（Intel HEX/bin）、向量表与熔丝位识别、8051/AVR/PIC/MSP430 的 Ghidra 处理器模块反汇编、与 RTOS 技能衔接（跑 RTOS 的固件 → [[re-rtos]]）
|
||||
|
||||
### re-format-pe +1 章（老运行时识别）
|
||||
|
||||
- Delphi VCL：RTTI 结构、类表/vmt 定位、Borland 资源段特征
|
||||
- VB6：MSVBVM60 运行时特征、资源特征定位入口
|
||||
- 老壳注意（PECompact 类）与 [[re-packer-id]] 衔接
|
||||
|
||||
## 同步项（融合/新增波及）
|
||||
|
||||
1. **计数 107 → 112**：package.json description、`.claude-plugin/marketplace.json` 两处 description、README 首段
|
||||
2. **README 技能导航**：新技能挂组（re-flutter→re-mobile 组、re-rtos→re-firmware 组、re-mips→re-binary-core 组、re-tee→re-firmware 组（实现时定）、re-harmonyos→re-mobile 组）
|
||||
3. **re-analyze/references/triage.md**：移动 App 路径补 re-flutter/re-harmonyos 引用；固件路径补 re-rtos
|
||||
4. **re-mobile 网关子技能清单**：+[[re-flutter]] +[[re-harmonyos]]
|
||||
5. **re-feedback 无关**（不触碰）
|
||||
6. marketplace.json 版本保持 0.0.2（永久版本策略，内容更新不 bump）
|
||||
|
||||
## 规则（沿用全库红线）
|
||||
|
||||
- 红线 1 呈现中性：禁用「最推荐」「强烈建议」等最高级强推措辞，最多「推荐」
|
||||
- 红线 2 隐私脱敏：不指向具体项目/公司/产品
|
||||
- 不绑定具体工具：方法为核心，工具为可替换示例；「工具准备」按模板给跨 OS 安装命令（硬件类给选购指引）
|
||||
- 新技能 type=atomic、frontmatter name=目录名、必须有「## 工具准备」、[[链接]] 指向存在的技能或 references 文件名
|
||||
- 通用方法论进 re-analyze/references（如 MIPS 延迟槽若属通用二进制知识可进 platform-tips 的链接，技能内保留专有内容）
|
||||
|
||||
## 校验与测试
|
||||
|
||||
- 每任务完成后 `npm test` 全绿（112 skills）
|
||||
- `claude plugin validate .` 通过（marketplace.json 未动结构，只改 description 文本）
|
||||
- 无 [[死链]]
|
||||
- 红线 2 逐条对照（新增内容无具体指代）
|
||||
- 工作区未提交文件谨慎处理（git add 只加任务文件）
|
||||
|
||||
## 范围外
|
||||
|
||||
- 不新增网关技能（12 网关结构不变）
|
||||
- 不触碰 reverse-skill 机制层（沿用上轮结论）
|
||||
- 游戏机（Switch/PS）等法律灰区不涉
|
||||
@@ -0,0 +1,71 @@
|
||||
# zws 收藏库经验吸收设计（2026-08-20）
|
||||
|
||||
## 背景
|
||||
|
||||
收藏型 GitHub 账号 `123456789zws`（4432 个 fork，全 RE 主题）暴露了中文 RE 圈的高密度工具/技能索引。从中挑选 7 个高价值仓库克隆并深挖（素材挖掘 7 代理完成，产出 99 条候选，存于 /home/DslsDZC/rev-refs/extract-zws-*.md，均已脱敏）。
|
||||
|
||||
用户决策：**全吸收**。
|
||||
|
||||
## 素材清单与许可分级
|
||||
|
||||
| 素材 | 许可 | 候选数 | 吸收规则 |
|
||||
|---|---|---|---|
|
||||
| reverse-skills（inliver233） | MIT | 28 | 注明来源吸收 |
|
||||
| ReVa（cyberkaida） | Apache-2.0 | 15 | 注明来源吸收 |
|
||||
| hermes-decomp（SymbioticSec） | MIT | 16 | 注明来源吸收 |
|
||||
| Cpp2IL（SamboyCoding） | MIT | 9 | 注明来源吸收 |
|
||||
| chernobog（19h） | 无许可 | 16 | 只蒸馏，不注源 |
|
||||
| pyarmor-research（Fadi002） | 无许可 | 10 | 只蒸馏，不注源 |
|
||||
| LazyReverse（a0yami） | MIT | 5 | 注明来源吸收 |
|
||||
|
||||
## 变更总览（99 候选 → 裁剪 ~40 入库）
|
||||
|
||||
| # | 目标技能 | 素材 | 吸收条目（执行时查重裁剪） |
|
||||
|---|---|---|---|
|
||||
| 1 | re-flutter | reverse-skills | 对象池 VLE 反序列化（条目4）、字符串双编码（5）、池槽→.text xref 桥（6）、cid 虚拟分派墙（7）、Dart AOT ABI/bool 编码（8）、Dart False≠0 patch 陷阱（10）、弹窗三源分诊（13）、平台通道 stub 陷阱（14）、万级函数分诊（17）、状态链追踪（18）→ 挑 6-8 条 |
|
||||
| 2 | re-hybrid-app | hermes-decomp | 函数表/边界定位（2）、字符串表解析（3）、版本化指令集（5）、寄存器→变量还原（7）、转译产物去抽象（10）、Metro 模块层（11）、字节码写回补丁（14）、已知限制（15）→ 挑 5-7 条 |
|
||||
| 3 | re-script-deob | hermes-decomp | 转译去抽象（10 兼）、写回补丁（14 兼）→ 1-2 条 |
|
||||
| 4 | re-game | Cpp2IL | 双文件结构模型（1）、版本识别考古（2）、注册结构定位（3）、篡改对抗（5）、反编译管线（6）、已知限制（8）→ 挑 4-5 条 |
|
||||
| 5 | re-deobfuscate | chernobog | dispatcher 识别（1）、Z3 状态机求解（3）、CFG 重构护栏（5）、不透明谓词证据纪律（8）、LLM 编排纪律（12/13）、混合分析（14/15）→ 查重后挑 4-6 条 |
|
||||
| 6 | re-python | pyarmor-research | 保护模型（1）、载体识别（2）、密钥派生还原（3）、marshal 重建（5）、运行时解密窗口（7）、版本差异（9）→ 挑 4-5 条 |
|
||||
| 7 | re-patching | reverse-skills | patch 四原语（9）、爆炸半径（11）、safe-NOP（12）→ 2-3 条 |
|
||||
| 8 | re-mobile-pack | reverse-skills | 加固识别/重打包黑屏（20）、三条交付路径（21）→ 2 条 |
|
||||
| 9 | re-apk | reverse-skills | repack 闭环（19）、签名校验链（25）→ 2 条 |
|
||||
| 10 | re-frida | reverse-skills | 测试环境决策树（22）、redroid 搭建（23）、Frida 流程（24）→ 2-3 条 |
|
||||
| 11 | re-analyze references | ReVa | 工具粒度（1）、schema 宽容（2）、错误重定向（3）、context rot 抑制（4）、后台作业+轮询游标（8）、脚本逃逸舱（13）、证据纪律（10）→ 3-5 条（进 references 或坑） |
|
||||
| 12 | re-dotnet | LazyReverse | dnSpy 无头批量（1）→ 1 条 |
|
||||
| 13 | re-ida | LazyReverse | IDA 无头批量（2）→ 1 条 |
|
||||
| 14 | re-feedback | reverse-skills | 工具前置断言（26）、多代理协作（27）→ 1-2 条 |
|
||||
|
||||
## 吸收格式与规则
|
||||
|
||||
**坑格式**：`**标题**：现象——…；原因——…；对策——…`（与全库体例一致，追加进「## 常见坑与陷阱」）
|
||||
|
||||
**查重规则**：入库前 `grep -n <关键词> <目标技能>/SKILL.md`（含 references/）；同现象已存在 → 跳过；内容更完整的深化版本 → 合并。re-deobfuscate 覆盖已高，执行时最严格。
|
||||
|
||||
**来源注明**（仅 MIT/Apache 素材）：
|
||||
- reverse-skills → `（来源：reverse-skills（inliver233），MIT）`
|
||||
- ReVa → `（来源：ReVa（cyberkaida），Apache-2.0）`
|
||||
- hermes-decomp → `（来源：hermes-decomp（SymbioticSec），MIT）`
|
||||
- Cpp2IL → `（来源：Cpp2IL（SamboyCoding），MIT）`
|
||||
- LazyReverse → `（来源：LazyReverse（a0yami），MIT）`
|
||||
- chernobog / pyarmor-research → 不注源（无许可蒸馏）
|
||||
|
||||
**改写规则**：不逐字复制——按现象/原因/对策改写；素材已脱敏，入库时再逐条对照红线 2（无具体项目/公司/产品暗示）
|
||||
|
||||
## 红线（沿用全库）
|
||||
|
||||
- 红线 1 呈现中性：禁「最推荐/强烈建议」，最多「推荐」
|
||||
- 红线 2 隐私脱敏：素材已脱敏，入库抽查
|
||||
- 不绑定具体工具：方法为核心；工具名（blutter/capstone/frida/dnSpy/IDA 等公开工具）可保留
|
||||
- 每条入库后 `npm test` 全绿（112 不变——融合吸收不改技能数）
|
||||
|
||||
## 校验
|
||||
|
||||
- 每任务：查重 → 追加坑条目（+来源注明）→ 脱敏对照 → npm test → commit
|
||||
- 终审：全波次复核 + 技术事实抽查（VLE 编码、Hermes 位域头、IL2CPP metadata 版本、CFF dispatcher、PyArmor 运行时、ReVa 工具设计）
|
||||
|
||||
## 范围外
|
||||
|
||||
- 不新增技能（全部融合进现有技能与 references）
|
||||
- MCP 服务类仓库（reversing-mcp 等收藏）——本轮只吸收方法论，不引入 MCP 工具绑定
|
||||
@@ -0,0 +1,79 @@
|
||||
# 技能库深度扩充设计（深度波）
|
||||
|
||||
日期：2026-08-25
|
||||
状态：已获用户批准（2026-08-25 逐节确认）
|
||||
|
||||
## 1. 总览
|
||||
|
||||
**目标**：给现有全部技能加深度——薄技能正文扩写至基线 + 全部技能按类型配 references/ 深度文件（每技能 2 个）。
|
||||
|
||||
**已确认决策**：
|
||||
1. 形态：两者结合（正文扩写 + references/ 深度文件）
|
||||
2. 范围：分层滚动（T1/T2/T3，网关正文不动）
|
||||
3. 粒度：按技能类型多文件（每技能 2 个，主题命名）
|
||||
4. 流程：样板先行（2 个样板定调后批量）
|
||||
5. 实现方案：A（类型映射表 + 技能簇任务）
|
||||
|
||||
**范围**：112 个现有技能（v4 的 6 新技能 + re-rtos/re-behavior 标注「待 v4 落地后套用」，不在本设计内重复设计）。技能计数不变：112（v4 落地后 118）。深度文件总量约 220 个。
|
||||
|
||||
## 2. 分层范围
|
||||
|
||||
| 分层 | 判定 | 产出 | 规模 |
|
||||
|---|---|---|---|
|
||||
| T1 | 原子技能 SKILL.md <100 行 | 正文扩写至 ~130 行基线 + 2 个深度文件 | 约 18 技能 |
|
||||
| T2 | 原子技能 100-130 行 | 正文适度补强（补缺章/示例/坑，无硬基线）+ 关键者配深度文件 | 48 技能 |
|
||||
| T3 | 原子技能 >130 行 | 只补深度文件（尚无者） | 约 33 技能 |
|
||||
| 网关（12+1） | 编排器设计使然 | 正文不动（re-analyze 已有 references/ 不动） | 13 |
|
||||
|
||||
行数按 2026-08-25 实测（`wc -l .claude/skills/*/SKILL.md`，中位 99 行；86-130 行共 62 个）。T1/T3 为约数，精确清单由实施计划首个任务（映射表）产出并确认。
|
||||
|
||||
**关键者判定规则**（T2 内）：跨域引用数 ≥ 2，或被网关子技能清单 / triage 路由直接引用，或与 T1 相邻主题（如 re-rtos 与 T1 的 re-tee 同簇）。
|
||||
|
||||
## 3. 类型-文件集映射
|
||||
|
||||
每技能 2 个 references/ 文件，主题命名对齐 frida-scripts.md 惯例；`[[链接]]` 目标 = 文件名去扩展名（validate 既有支持）。
|
||||
|
||||
| 类型 | 文件集 | 内容骨架 | 代表技能（示例） |
|
||||
|---|---|---|---|
|
||||
| 工具类 | `commands.md` + `gotchas.md` | 命令速查/常用操作序列/组合套路；工具特有坑/版本差异/边界 | ghidra / ida / radare2 / gdb / lldb / x64dbg / windbg / binaryninja / angr / z3 / netcap / frida / tracing / sandbox / ti / sdr / mem-forensics / emulation / fw-emulate / plugin-dev / apk（jadx/apktool 为主） |
|
||||
| 格式类 | `layout.md` + `examples.md` | 结构图/字段表/布局与偏移；最小解析示例/字节样例/字段对照 | format-pe / format-elf / format-macho / wasm / cpp-abi / go / rust / nim / zig / swift / fp-runtime / flutter / hybrid-app / harmonyos / python / dotnet / java / rtos / mips / uefi / crypto-id / blockchain / drm / whitebox / mobile-pack |
|
||||
| 方法论类 | `decision-tree.md` + `gotchas.md` | 场景决策树/分支逻辑/证据分级；方法论坑/边界/反例 | behavior / hunting / attribution / proto-rev / ioc / anti-cheat / evasion / fileless / ransomware / loader / doc-malware / browser-ext / keygen / license / patching / variant / deobfuscate / unpack-simple / unpack-advanced / stego / fuzzing / crash-triage / exploit / pwn / shellcode / kernel / hypervisor |
|
||||
| 领域混合类 | 取主类型文件集 | 判定规则：按技能主属性归类（场景为主取主类型；工具密集取工具类） | ics / iot-proto / automotive / hardware-io / hw-chip / tee / game / macos / ios / ios-jb / android-native / mobile-forensics / disk-forensics / memdump / triage / fw-extract / fw-rootfs / crypto-decrypt / crypto-keys / a-model / a-attack / stego 等 |
|
||||
|
||||
**完整映射表**（112 技能 → 类型 × 分层 → 所属簇任务）由实施计划首个任务产出并确认，本设计定规则与形态。
|
||||
|
||||
## 4. 任务结构
|
||||
|
||||
任务队列（每任务 = 实现 → 事实核验（必要时 web）→ 红线对照 → `npm test` → commit 只 add 本任务文件）：
|
||||
|
||||
1. **映射表任务**：产出 112 技能的类型×分层映射表（设计附录，供后续任务引用）
|
||||
2. **样板任务**：re-x64dbg（工具类）+ re-format-elf（格式类）完整深度产出 → 提交后用户审阅定调
|
||||
3. **T1 批次**（约 18 技能 → 4-5 个簇任务）：正文扩写至 ~130 行基线 + 2 个深度文件；簇按「类型 × 主题相邻」划分（如 T1 工具类簇、T1 格式类簇…）
|
||||
4. **T2 批次**（48 技能 → 10-12 个簇任务）：正文补强 + 关键者（判定规则见第 2 节）配深度文件
|
||||
5. **T3 批次**（约 33 技能 → 6-7 个簇任务）：只补深度文件
|
||||
6. **re-rtos / re-behavior**：深度产出放队列末尾（v4 落地后套用）
|
||||
7. **终审波**：全库 references 死链/计数/事实抽查/红线对照
|
||||
|
||||
**样板审阅要点**：正文扩写密度与风格、深度文件骨架与命名、命令/示例颗粒度；定调后批量任务按样板同构执行。
|
||||
|
||||
## 5. 质量闸口与验证
|
||||
|
||||
- validate.mjs：references/*.md 文件名（去扩展名）为合法 `[[链接]]` 目标；SKILL.md `[[链接]]` 必须解析（深度文件内引用其他技能必须指向存在目标）
|
||||
- 正文扩写不破坏 frontmatter（`name`=目录名、`description` 非空、`type: atomic` 必含「## 工具准备」）与固定五节结构
|
||||
- 事实核验：命令/字段/格式断言以官方文档为准（命令必须可执行；字段名以本机输出验证的写法沿用仓库惯例）；抽查机制进终审波
|
||||
- 红线：呈现中性（禁「最推荐/强烈建议」）/ 隐私脱敏（不指具体项目/公司/产品）/ 不绑定具体工具（跨 OS 安装命令）
|
||||
- 每任务 `npm test`；深度波不改技能计数（112 → v4 后 118 由 v4 负责）
|
||||
|
||||
## 6. 与 v4 并行协调
|
||||
|
||||
- 两个计划独立任务队列、独立 commit、独立评审
|
||||
- 文件集隔离：v4 只碰 6 新技能目录 + re-rtos/re-behavior/triage/rerouting/计数文件；深度波只碰其余约 104 个现有技能的 SKILL.md 与 references/（re-rtos/re-behavior 深度产出在 v4 落地后套用）
|
||||
- 并行执行方式：两计划均按 subagent-driven-development 思路推进（计划内任务串行、两计划间并行），git 冲突面为零
|
||||
- 计数同步只由 v4 负责；深度波每任务 `npm test` 输出一致
|
||||
|
||||
## 7. 产出物清单
|
||||
|
||||
- 约 220 个 references/ 深度文件（commands/gotchas/layout/examples/decision-tree）
|
||||
- 约 80 个 SKILL.md 正文扩写/补强（T1 全量 + T2 适度）
|
||||
- 映射表设计附录（112 技能 × 类型 × 分层）
|
||||
- 技能计数保持 112（v4 后 118）
|
||||
@@ -0,0 +1,171 @@
|
||||
# 深度波映射表：技能 × 类型 × 分层（2026-08-25）
|
||||
|
||||
> 设计附录（design: `docs/superpowers/specs/2026-08-25-depth-wave-design.md` §2 分层判定、§3 类型-文件集映射与关键者规则）。本表由深度波实施计划任务 1 产出，是后续每个簇任务的成员与文件集依据。
|
||||
|
||||
## 0. 生成依据与方法
|
||||
|
||||
- 行数：`wc -l .claude/skills/*/SKILL.md` 实测（2026-08-25，任务执行时基线；中位 99 行，86-130 行 62 个（112 技能基线；re-arm 落地后 86-130 行 63 个）
|
||||
- 分层判定（设计 §2）：T1 原子技能 <100 行；T2 100-130 行；T3 >130 行；网关 13 个（编排器，正文不动）。设计 §2 中 T1≈18/T3≈33 为约数，精确清单以本表为准
|
||||
- 类型判定（设计 §3）：工具 / 格式 / 方法论 三类主类型；领域混合技能按主属性取主类型（场景为主取主类型；工具密集取工具类），最终类型直接决定文件集
|
||||
- 关键者判定（设计 §2，仅 T2 内）：跨域引用数 ≥ 2（grep 全库 `[[链接]]` 引用图按网关子技能域归属计跨域，含网关与 triage 的引用；被网关子技能清单 / triage 路由直接引用的技能均已计入该数）
|
||||
- v4 并行：任务执行时 v4 新技能 re-arm 已落地，纳入本表并标注「v4 新增」；其余 v4 技能（re-riscv/re-console/re-electron/re-javacard/re-ebpf）生成时未落地，落地后由 v4 接入。当前实测技能总数 113，`node validate.mjs` → `OK: 113 skills validated`
|
||||
- 队列末尾（设计 §4.6）：re-rtos / re-behavior 深度产出放队列末尾（v4 落地后套用），分层与类型照常判定
|
||||
|
||||
## 1. 类型-文件集对照（设计 §3）
|
||||
|
||||
| 类型 | 文件集 | 内容骨架 |
|
||||
|---|---|---|
|
||||
| 工具 | `references/commands.md` + `references/gotchas.md` | 命令速查/操作序列；工具坑/版本差异 |
|
||||
| 格式 | `references/layout.md` + `references/examples.md` | 结构图/字段表/布局偏移；解析示例/字节样例 |
|
||||
| 方法论 | `references/decision-tree.md` + `references/gotchas.md` | 场景决策树/证据分级；方法论坑/边界 |
|
||||
| 网关 | —（正文不动） | 编排器（re-analyze 已有 references/ 不动） |
|
||||
|
||||
## 2. 全量映射表
|
||||
|
||||
### 2.1 网关（13）
|
||||
|
||||
| 技能 | 行数 | 分层 | 类型 | 文件集 | 备注 |
|
||||
|---|---|---|---|---|---|
|
||||
| re-analyze | 84 | 网关 | 网关 | —（正文不动；re-analyze 已有 references/ 不动） | |
|
||||
| re-anti-analysis | 200 | 网关 | 网关 | —（正文不动；re-analyze 已有 references/ 不动） | |
|
||||
| re-binary-core | 152 | 网关 | 网关 | —（正文不动；re-analyze 已有 references/ 不动） | |
|
||||
| re-cracking | 62 | 网关 | 网关 | —（正文不动；re-analyze 已有 references/ 不动） | |
|
||||
| re-ctf | 67 | 网关 | 网关 | —（正文不动；re-analyze 已有 references/ 不动） | |
|
||||
| re-feedback | 57 | 网关 | 网关 | —（正文不动；re-analyze 已有 references/ 不动） | |
|
||||
| re-firmware | 49 | 网关 | 网关 | —（正文不动；re-analyze 已有 references/ 不动） | |
|
||||
| re-forensics | 54 | 网关 | 网关 | —（正文不动；re-analyze 已有 references/ 不动） | |
|
||||
| re-malware | 49 | 网关 | 网关 | —（正文不动；re-analyze 已有 references/ 不动） | |
|
||||
| re-managed | 58 | 网关 | 网关 | —（正文不动；re-analyze 已有 references/ 不动） | |
|
||||
| re-mobile | 62 | 网关 | 网关 | —（正文不动；re-analyze 已有 references/ 不动） | |
|
||||
| re-protocol | 65 | 网关 | 网关 | —（正文不动；re-analyze 已有 references/ 不动） | |
|
||||
| re-vuln | 68 | 网关 | 网关 | —（正文不动；re-analyze 已有 references/ 不动） | |
|
||||
|
||||
### 2.2 T1（28，<100 行）
|
||||
|
||||
| 技能 | 行数 | 分层 | 类型 | 文件集 | 备注 |
|
||||
|---|---|---|---|---|---|
|
||||
| re-ai-attack | 72 | T1 | 方法论 | decision-tree.md + gotchas.md | |
|
||||
| re-attribution | 79 | T1 | 方法论 | decision-tree.md + gotchas.md | |
|
||||
| re-binaryninja | 82 | T1 | 工具 | commands.md + gotchas.md | |
|
||||
| re-browser-ext | 73 | T1 | 方法论 | decision-tree.md + gotchas.md | |
|
||||
| re-doc-malware | 93 | T1 | 方法论 | decision-tree.md + gotchas.md | |
|
||||
| re-drm | 92 | T1 | 格式 | layout.md + examples.md | |
|
||||
| re-format-macho | 93 | T1 | 格式 | layout.md + examples.md | |
|
||||
| re-fp-runtime | 73 | T1 | 格式 | layout.md + examples.md | |
|
||||
| re-frida-script-author | 86 | T1 | 方法论 | decision-tree.md + gotchas.md | |
|
||||
| re-hunting | 70 | T1 | 方法论 | decision-tree.md + gotchas.md | |
|
||||
| re-ida | 99 | T1 | 工具 | commands.md + gotchas.md | |
|
||||
| re-kernel | 87 | T1 | 方法论 | decision-tree.md + gotchas.md | |
|
||||
| re-keygen | 90 | T1 | 方法论 | decision-tree.md + gotchas.md | |
|
||||
| re-license | 98 | T1 | 方法论 | decision-tree.md + gotchas.md | |
|
||||
| re-lldb | 96 | T1 | 工具 | commands.md + gotchas.md | |
|
||||
| re-macos | 94 | T1 | 方法论 | decision-tree.md + gotchas.md | |
|
||||
| re-mobile-forensics | 74 | T1 | 方法论 | decision-tree.md + gotchas.md | |
|
||||
| re-nim | 63 | T1 | 格式 | layout.md + examples.md | |
|
||||
| re-radare2 | 97 | T1 | 工具 | commands.md + gotchas.md | |
|
||||
| re-rtos | 99 | T1 | 格式 | layout.md + examples.md | 深度产出放队列末尾（设计 §4.6，v4 落地后套用） |
|
||||
| re-sdr | 80 | T1 | 工具 | commands.md + gotchas.md | |
|
||||
| re-stego | 80 | T1 | 方法论 | decision-tree.md + gotchas.md | |
|
||||
| re-swift | 80 | T1 | 格式 | layout.md + examples.md | |
|
||||
| re-tee | 99 | T1 | 方法论 | decision-tree.md + gotchas.md | |
|
||||
| re-variant | 74 | T1 | 方法论 | decision-tree.md + gotchas.md | |
|
||||
| re-windbg | 86 | T1 | 工具 | commands.md + gotchas.md | |
|
||||
| re-x64dbg | 85 | T1 | 工具 | commands.md + gotchas.md | |
|
||||
| re-zig | 69 | T1 | 格式 | layout.md + examples.md | |
|
||||
|
||||
### 2.3 T2（49，100-130 行）
|
||||
|
||||
| 技能 | 行数 | 分层 | 类型 | 文件集 | 备注 |
|
||||
|---|---|---|---|---|---|
|
||||
| re-angr | 122 | T2 | 工具 | commands.md + gotchas.md | 关键者（跨域引用 4：grep 实测） |
|
||||
| re-anti-cheat | 104 | T2 | 方法论 | decision-tree.md + gotchas.md | 非关键者（跨域引用 0） |
|
||||
| re-apk | 118 | T2 | 工具 | commands.md + gotchas.md | 关键者（跨域引用 7：grep 实测） |
|
||||
| re-arm | 129 | T2 | 格式 | layout.md + examples.md | v4 新增；非关键者（跨域引用 0） |
|
||||
| re-behavior | 119 | T2 | 方法论 | decision-tree.md + gotchas.md | 深度产出放队列末尾（设计 §4.6，v4 落地后套用）；关键者（跨域引用 10：grep 实测） |
|
||||
| re-cpp-abi | 104 | T2 | 格式 | layout.md + examples.md | 非关键者（跨域引用 1） |
|
||||
| re-crash-triage | 127 | T2 | 方法论 | decision-tree.md + gotchas.md | 关键者（跨域引用 2：grep 实测） |
|
||||
| re-crypto-decrypt | 118 | T2 | 方法论 | decision-tree.md + gotchas.md | 关键者（跨域引用 16：grep 实测） |
|
||||
| re-crypto-keys | 122 | T2 | 方法论 | decision-tree.md + gotchas.md | 关键者（跨域引用 11：grep 实测） |
|
||||
| re-deobfuscate | 124 | T2 | 方法论 | decision-tree.md + gotchas.md | 关键者（跨域引用 9：grep 实测） |
|
||||
| re-dotnet | 122 | T2 | 格式 | layout.md + examples.md | 非关键者（跨域引用 1） |
|
||||
| re-emulation | 106 | T2 | 工具 | commands.md + gotchas.md | 关键者（跨域引用 3：grep 实测） |
|
||||
| re-evasion | 113 | T2 | 方法论 | decision-tree.md + gotchas.md | 关键者（跨域引用 4：grep 实测） |
|
||||
| re-exploit | 129 | T2 | 方法论 | decision-tree.md + gotchas.md | 非关键者（跨域引用 1） |
|
||||
| re-fileless | 116 | T2 | 方法论 | decision-tree.md + gotchas.md | 非关键者（跨域引用 0） |
|
||||
| re-format-elf | 113 | T2 | 格式 | layout.md + examples.md | 关键者（跨域引用 14：grep 实测） |
|
||||
| re-fw-emulate | 110 | T2 | 工具 | commands.md + gotchas.md | 关键者（跨域引用 5：grep 实测） |
|
||||
| re-fw-rootfs | 124 | T2 | 方法论 | decision-tree.md + gotchas.md | 关键者（跨域引用 3：grep 实测） |
|
||||
| re-gdb | 114 | T2 | 工具 | commands.md + gotchas.md | 关键者（跨域引用 20：grep 实测） |
|
||||
| re-ghidra | 115 | T2 | 工具 | commands.md + gotchas.md | 关键者（跨域引用 47：grep 实测） |
|
||||
| re-go | 120 | T2 | 格式 | layout.md + examples.md | 非关键者（跨域引用 0） |
|
||||
| re-hardware-io | 107 | T2 | 工具 | commands.md + gotchas.md | 关键者（跨域引用 4：grep 实测） |
|
||||
| re-harmonyos | 102 | T2 | 格式 | layout.md + examples.md | 非关键者（跨域引用 0） |
|
||||
| re-hw-chip | 118 | T2 | 方法论 | decision-tree.md + gotchas.md | 关键者（跨域引用 2：grep 实测） |
|
||||
| re-hypervisor | 120 | T2 | 方法论 | decision-tree.md + gotchas.md | 非关键者（跨域引用 0） |
|
||||
| re-ics | 113 | T2 | 方法论 | decision-tree.md + gotchas.md | 非关键者（跨域引用 1） |
|
||||
| re-imports | 117 | T2 | 格式 | layout.md + examples.md | 关键者（跨域引用 6：grep 实测） |
|
||||
| re-ioc | 116 | T2 | 方法论 | decision-tree.md + gotchas.md | 关键者（跨域引用 28：grep 实测） |
|
||||
| re-ios | 109 | T2 | 工具 | commands.md + gotchas.md | 关键者（跨域引用 4：grep 实测） |
|
||||
| re-java | 118 | T2 | 格式 | layout.md + examples.md | 非关键者（跨域引用 1） |
|
||||
| re-loader | 118 | T2 | 方法论 | decision-tree.md + gotchas.md | 非关键者（跨域引用 0） |
|
||||
| re-mem-forensics | 106 | T2 | 工具 | commands.md + gotchas.md | 非关键者（跨域引用 1） |
|
||||
| re-memdump | 121 | T2 | 工具 | commands.md + gotchas.md | 关键者（跨域引用 29：grep 实测） |
|
||||
| re-mips | 115 | T2 | 格式 | layout.md + examples.md | 非关键者（跨域引用 0） |
|
||||
| re-mobile-pack | 118 | T2 | 格式 | layout.md + examples.md | 非关键者（跨域引用 0） |
|
||||
| re-netcap | 124 | T2 | 工具 | commands.md + gotchas.md | 关键者（跨域引用 13：grep 实测） |
|
||||
| re-patching | 110 | T2 | 方法论 | decision-tree.md + gotchas.md | 关键者（跨域引用 5：grep 实测） |
|
||||
| re-plugin-dev | 103 | T2 | 工具 | commands.md + gotchas.md | 非关键者（跨域引用 0） |
|
||||
| re-python | 107 | T2 | 格式 | layout.md + examples.md | 关键者（跨域引用 3：grep 实测） |
|
||||
| re-ransomware | 102 | T2 | 方法论 | decision-tree.md + gotchas.md | 非关键者（跨域引用 0） |
|
||||
| re-rust | 117 | T2 | 格式 | layout.md + examples.md | 非关键者（跨域引用 0） |
|
||||
| re-sandbox | 128 | T2 | 工具 | commands.md + gotchas.md | 关键者（跨域引用 48：grep 实测） |
|
||||
| re-ti | 117 | T2 | 工具 | commands.md + gotchas.md | 关键者（跨域引用 2：grep 实测） |
|
||||
| re-tracing | 106 | T2 | 工具 | commands.md + gotchas.md | 关键者（跨域引用 14：grep 实测） |
|
||||
| re-unpack-advanced | 103 | T2 | 方法论 | decision-tree.md + gotchas.md | 关键者（跨域引用 5：grep 实测） |
|
||||
| re-unpack-simple | 104 | T2 | 方法论 | decision-tree.md + gotchas.md | 关键者（跨域引用 5：grep 实测） |
|
||||
| re-wasm | 121 | T2 | 格式 | layout.md + examples.md | 非关键者（跨域引用 1） |
|
||||
| re-whitebox | 111 | T2 | 格式 | layout.md + examples.md | 非关键者（跨域引用 0） |
|
||||
| re-z3 | 102 | T2 | 工具 | commands.md + gotchas.md | 关键者（跨域引用 4：grep 实测） |
|
||||
|
||||
### 2.4 T3（23，>130 行）
|
||||
|
||||
| 技能 | 行数 | 分层 | 类型 | 文件集 | 备注 |
|
||||
|---|---|---|---|---|---|
|
||||
| re-ai-model | 156 | T3 | 格式 | layout.md + examples.md | |
|
||||
| re-android-native | 146 | T3 | 方法论 | decision-tree.md + gotchas.md | |
|
||||
| re-automotive | 153 | T3 | 工具 | commands.md + gotchas.md | |
|
||||
| re-blockchain | 146 | T3 | 格式 | layout.md + examples.md | |
|
||||
| re-crypto-id | 137 | T3 | 格式 | layout.md + examples.md | |
|
||||
| re-disk-forensics | 147 | T3 | 方法论 | decision-tree.md + gotchas.md | |
|
||||
| re-flutter | 156 | T3 | 格式 | layout.md + examples.md | |
|
||||
| re-format-pe | 183 | T3 | 格式 | layout.md + examples.md | |
|
||||
| re-frida | 162 | T3 | 工具 | commands.md + gotchas.md | |
|
||||
| re-fuzzing | 153 | T3 | 方法论 | decision-tree.md + gotchas.md | |
|
||||
| re-fw-extract | 168 | T3 | 工具 | commands.md + gotchas.md | |
|
||||
| re-game | 205 | T3 | 工具 | commands.md + gotchas.md | |
|
||||
| re-hybrid-app | 183 | T3 | 格式 | layout.md + examples.md | |
|
||||
| re-ios-jb | 149 | T3 | 方法论 | decision-tree.md + gotchas.md | |
|
||||
| re-iot-proto | 208 | T3 | 格式 | layout.md + examples.md | |
|
||||
| re-packer-id | 132 | T3 | 方法论 | decision-tree.md + gotchas.md | |
|
||||
| re-proto-rev | 139 | T3 | 方法论 | decision-tree.md + gotchas.md | |
|
||||
| re-pwn | 141 | T3 | 方法论 | decision-tree.md + gotchas.md | |
|
||||
| re-script-deob | 153 | T3 | 方法论 | decision-tree.md + gotchas.md | |
|
||||
| re-shellcode | 184 | T3 | 方法论 | decision-tree.md + gotchas.md | |
|
||||
| re-tls | 135 | T3 | 格式 | layout.md + examples.md | |
|
||||
| re-triage | 143 | T3 | 工具 | commands.md + gotchas.md | |
|
||||
| re-uefi | 133 | T3 | 格式 | layout.md + examples.md | |
|
||||
|
||||
## 3. 闭环核查
|
||||
|
||||
- 分层闭环：T1 28 + T2 49 + T3 23 + 网关 13 = 113 = 当前实测技能总数 113
|
||||
- 类型闭环：工具 28 + 格式 30 + 方法论 42 + 网关 13 = 113 = 技能总数 113
|
||||
- T2 关键者 29 个（跨域引用 ≥2，grep 实测）：re-angr, re-apk, re-behavior, re-crash-triage, re-crypto-decrypt, re-crypto-keys, re-deobfuscate, re-emulation, re-evasion, re-format-elf, re-fw-emulate, re-fw-rootfs, re-gdb, re-ghidra, re-hardware-io, re-imports, re-ioc, re-ios, re-memdump, re-netcap, re-patching, re-sandbox, re-ti, re-tracing, re-unpack-advanced, re-unpack-simple, re-z3, re-python, re-hw-chip
|
||||
- T2 非关键者 20 个：re-anti-cheat, re-dotnet, re-exploit, re-fileless, re-go, re-hypervisor, re-ics, re-java, re-loader, re-mem-forensics, re-mobile-pack, re-plugin-dev, re-ransomware, re-rust, re-wasm, re-whitebox, re-cpp-abi, re-mips, re-harmonyos, re-arm
|
||||
- 覆盖核查：本表行数 = 表内技能数 = 113（脚本从 `ls .claude/skills/` 生成，无遗漏无重复）
|
||||
|
||||
## 4. 簇任务提示（供后续任务引用）
|
||||
|
||||
- T1 批次：正文扩写至 ~130 行基线 + 2 个深度文件；簇按「类型 × 主题相邻」划分（如 re-rtos 与 re-tee 同固件簇；格式类 T1 有 format-macho/nim/zig/swift/fp-runtime/rtos 等）
|
||||
- T2 批次：正文适度补强；关键者（29 个）配深度文件，非关键者（20 个）以正文补强为主
|
||||
- T3 批次：只补深度文件（尚无者）
|
||||
- 文件集命名对齐 frida-scripts.md 惯例；`[[链接]]` 目标 = 文件名去扩展名（validate 既有支持）
|
||||
@@ -0,0 +1,120 @@
|
||||
# 技能库第四轮扩充（覆盖缺口波）设计
|
||||
|
||||
日期：2026-08-25
|
||||
状态：已获用户批准（2026-08-25 逐节确认）
|
||||
|
||||
## 1. 总览
|
||||
|
||||
**目标**：补齐 8 个未覆盖领域——6 个新原子技能 + 2 处扩章，技能总数 112 → 118。
|
||||
|
||||
| # | 领域 | 形态 | 挂载点 |
|
||||
|---|---|---|---|
|
||||
| 1 | ARM 架构逆向（非 Android） | 新技能 re-arm | re-binary-core 子技能列表、re-fw-emulate、triage 固件行 |
|
||||
| 2 | RISC-V 架构逆向 | 新技能 re-riscv | 同 re-arm |
|
||||
| 3 | 现代主机与复古平台 | 新技能 re-console（含复古小节） | re-game 跨域、re-cracking |
|
||||
| 4 | Electron 桌面 JS 应用 | 新技能 re-electron | re-managed 网关子技能列表、triage 托管行、re-browser-ext 跨域 |
|
||||
| 5 | Java Card / SIM applet | 新技能 re-javacard | re-managed（Java 字节码族）、re-iot-proto 智能卡节、re-hardware-io |
|
||||
| 6 | eBPF 程序逆向与对抗 | 新技能 re-ebpf | re-tracing / re-evasion / re-kernel 跨域、rerouting 表 |
|
||||
| 7 | VxWorks/QNX/INTEGRITY | 扩 re-rtos（+3 章） | 触发词同步、跨域加 re-automotive |
|
||||
| 8 | Windows 行为监控工具链 | 扩 re-behavior（+1 节） | 无挂载变更 |
|
||||
|
||||
**产出体量**：对标 re-mips 深度——每个新技能 SKILL.md 约 120-180 行，固定五节（何时使用/工具准备/操作步骤/跨域联合/常见坑与陷阱 ≥3），references/ 仅按需。
|
||||
|
||||
## 2. 全局约束
|
||||
|
||||
- **红线 1 呈现中性**：禁用「最推荐」「强烈建议」等最高级强推措辞
|
||||
- **红线 2 隐私脱敏**：内容不指向具体项目/公司/产品；硬件类给泛化选购指引
|
||||
- **不绑定具体工具**：方法为核心，工具为可替换示例；「工具准备」按模板给跨 OS 安装命令（Linux/macOS/Windows/WSL 分支），仅 Windows 工具注明跨 OS 约束
|
||||
- **validate.mjs**：frontmatter `name`=目录名、`description` 非空（中英触发词）、`type: atomic` 必含「## 工具准备」、`[[链接]]` 必须解析（技能目录或 references/*.md）；新技能先于引用它的同步任务，避免中间态死链
|
||||
- **commit 纪律**：每任务 commit 只 `git add` 本任务列出的文件，严禁 `git add -A`
|
||||
- 当前分支 `main`；`npm test` 预期按任务标注递增（112 → 118）
|
||||
|
||||
## 3. 新技能设计
|
||||
|
||||
### 3.1 re-arm —— ARM 架构逆向
|
||||
|
||||
- **何时使用**：非 Android 场景 ARM——嵌入式裸机/固件（Cortex-M0/M3/M4/M7、Cortex-A）、Thumb/ARM 切换、AAPCS 调用约定、M 系向量表、位置相关代码重定位
|
||||
- **何时不用**：Android `.so` 走 re-android-native；通用 AArch64 Linux 用户态走 re-binary-core
|
||||
- **工具准备**：Ghidra/IDA（Thumb 支持）、`readelf`/`file`、`qemu-arm`/`qemu-aarch64`（用户态仿真）、`gdb-multiarch`、binwalk（联动 re-fw-extract）
|
||||
- **操作步骤**：① 架构与字节序确认（`file`/`readelf -h`）② 入口定位（M 系向量表 0x0 起 4B/项、reset handler 在第 2 项；A 系启动代码）③ Thumb 函数边界（BL 目标奇地址、veneer、`bx` 切换点）④ 基址/重定位（flash 加载地址 vs 链接地址偏移修正）⑤ AAPCS 识别（r0-r3 传参、`push {r4-lr}` 栈帧、HFABI 硬浮点变体）⑥ 外设寄存器 xref（0x4000xxxx MMIO 区、`LDR rN,[pc,#imm]` 立即数池）
|
||||
- **坑（≥3）**：Thumb 奇地址函数起点误判；BL/BLX ±32MB 范围外 veneer 混淆；M 系外设映射区当数据段；R14 双用途反编译失真；HFABI 与软浮点混用时参数解读错误
|
||||
|
||||
### 3.2 re-riscv —— RISC-V 架构逆向
|
||||
|
||||
- **何时使用**：RV32/RV64、压缩指令（RVC）、嵌入式（ESP32-C3 类）与 Linux 用户态
|
||||
- **何时不用**：工具链极端定制且无头绪时先走 re-fw-emulate 仿真兜底
|
||||
- **工具准备**：Ghidra（RISC-V 支持成熟）、`qemu-riscv64`/`qemu-riscv32`、binutils 交叉工具链（`riscv64-unknown-elf-objdump`）、readelf
|
||||
- **操作步骤**：架构确认（RV32/RV64 + 字节序）→ reset/入口定位 → RVC 压缩指令识别（2/4 字节混合，勿固定宽度切割）→ gp 相对寻址恢复（`lui+addi` 对、.sdata/.sbss）→ ABI 识别（整数/浮点 ABI、a0-a7 约定）→ 系统调用边界（`ecall` + a7 号）→ 生态指纹（工具链/库函数特征）
|
||||
- **坑（≥3）**：压缩指令流按 4 字节切割全错；gp 全局指针缺失致数据访问散乱；`la`/`li` 伪指令展开形态多变；`ecall` 系统调用号绑定 ABI、无 OS 时为自定义语义；链接器 relax（R_RISCV_RELAX）影响反汇编边界
|
||||
|
||||
### 3.3 re-console —— 现代主机与复古平台逆向
|
||||
|
||||
- **何时使用**：现代主机（Switch NPDM/NSO/加密分区、PS4/PS5 ORBIS、Xbox 系）与复古平台（NES/GB/SNES/GBA/PSX ROM 头、卡带格式、存档/Cheat 码）
|
||||
- **何时不用**：PC 端 Unity/Unreal 走 re-game；改机/盗版操作受授权边界约束（「何时不用」显式声明合规边界）
|
||||
- **工具准备**：Ghidra/IDA + 平台容器工具（hactoolnet 类 NSO/NPDM 解析、ORBIS 解析脚本，实现时核实工具名与可用性）、模拟器调试器（mGBA/no$psx 类）、卡带读取器（泛化选购指引）
|
||||
- **操作步骤**：容器识别 → 容器解析（分区/加密边界区分）→ 代码段提取进通用反编译 → SDK 库指纹 → 补丁差异（联动 re-variant）→ 复古：存档/Cheat 格式（内存地址+值模式）
|
||||
- **坑（≥3）**：加密容器当明文解；SDK 指纹误判；ND 头与正文分离；模拟器与真机行为差异；授权边界声明
|
||||
|
||||
### 3.4 re-electron —— Electron 桌面应用逆向
|
||||
|
||||
- **何时使用**：Electron/asar 应用——asar 解包、主/渲染进程 JS、V8 字节码（`.jsc`）、动态 CDP（`--inspect`）、`ELECTRON_RUN_AS_NODE`
|
||||
- **何时不用**：纯浏览器扩展走 re-browser-ext；混淆 JS 走 re-script-deob
|
||||
- **工具准备**：`npx asar extract` 类、Node/Electron 版本识别、CDP 客户端（chrome-remote-interface 类）、strings、通用反编译器（原生模块）
|
||||
- **操作步骤**：识别 Electron（目录/version 文件）→ asar 提取 → 主进程入口 → 渲染进程混淆 JS（联动 re-script-deob）→ 原生模块 `.node`（联动 re-format-elf）→ 动态 CDP → 反调试对抗（devtools 检测，联动 re-evasion）
|
||||
- **坑（≥3）**：`.jsc` 是 V8 快照非普通 JS（解析/反编译边界注明限制）；asar 内路径混淆；`ELECTRON_RUN_AS_NODE` 行为差异；contextIsolation/sandbox 影响注入面；fuses 配置改变运行能力
|
||||
|
||||
### 3.5 re-javacard —— Java Card / SIM applet 逆向
|
||||
|
||||
- **何时使用**：Java Card applet——CAP 文件组件解析（规范 12 组件，tag 1-12：Header/Directory/Applet/Import/ConstantPool/Class/Method/StaticField/ReferenceLocation/Export/Descriptor/Debug；实现时以 Oracle JC VM 规范为准——设计初稿「九组件」遗漏 StaticField/ReferenceLocation，已 errata 见文末）、CAP 字节码（Java 子集+卡片扩展指令，四类 invoke 齐备含 invokevirtual 0x8B——设计初稿「无 invokevirtual 等」断言错误，已 errata）、AID 与安装参数、SIM/USIM/银行卡 applet
|
||||
- **何时不用**：APDU 协议层与 MIFARE/DESFire 物理层走 re-iot-proto；CAP 获取依赖读卡（re-hardware-io）或固件提取（re-firmware）
|
||||
- **工具准备**：CAP 解析（开源解析器或自写 Python 脚本）、Ghidra/IDA 无原生 CAP 支持（脚本化解析）、`javap` 类对照（字节码差异说明）、读卡器（泛化选购指引 + 授权边界）
|
||||
- **操作步骤**：CAP 来源（EEPROM dump/固件/资料）→ Directory 组件偏移表驱动解析 → Method 组件方法体还原 → Import/常量池跨组件引用解析 → Applet `process(APDU)` 入口（CLA/INS 分派表）→ 与 APDU 交互对照（联动 re-iot-proto）
|
||||
- **坑（≥3）**：组件偏移表错误致全文件错位；Import 外部引用（跨 CAP 依赖）；字节码子集与 JVM 差异（无 invokedynamic/multianewarray/monitor 等）；卡片 dump 访问控制；AID/安装参数影响行为分支
|
||||
|
||||
### 3.6 re-ebpf —— eBPF 程序逆向与对抗分析
|
||||
|
||||
- **何时使用**：BPF-64 指令集、progs/maps 关联、加载链、BCC/libbpf/手工字节码三种来源；用途三分——跟踪取证（bpftrace/bcc 还原）、恶意 eBPF（内核驻留/规避）、EDR 对抗（bpf hook）
|
||||
- **何时不用**：经典内核模块（.ko 驱动）走 re-kernel
|
||||
- **工具准备**：`bpftool`（`prog dump xlated`/`feature`）、`llvm-objdump -d bpf`、pyelftools（ELF section 定位）、专用逆向工具（如 bpf-gazelle 类，实现时核实工具名与可用性）、受控环境（联动 re-sandbox）
|
||||
- **操作步骤**：定位载体（ELF `.text`/`.maps`/`.BTF` 或运行期 dump）→ 反汇编（原始或 `xlated`）→ progs/maps 关系还原 → hook 点识别（kprobe/tracepoint/cgroup 等 attach 类型）→ 语义还原（helper 调用号→内核 API，联动 re-kernel）
|
||||
- **坑（≥3）**：BTF 缺失类型盲区；verifier 重写后 `xlated` 与源码不对应（bpf2bpf 内联/尾调用）；helper 调用号随内核版本漂移；map 与 prog 分离；无符号库函数匹配
|
||||
|
||||
## 4. 扩章设计
|
||||
|
||||
### 4.1 re-rtos + VxWorks/QNX/INTEGRITY（+3 章）
|
||||
|
||||
每章同构于现有四章（TCB/内核对象关键字段 → 定位方法 → 特征串）：
|
||||
|
||||
- **VxWorks**：WIND_TCB（任务名表、栈指针、优先级字段）、VxWorks 7 结构变化、任务名串特征定位
|
||||
- **QNX**：线程控制块（procnto 微内核）、MsgSend/MsgReceive 消息传递调度链、车机中控场景联动 re-automotive
|
||||
- **INTEGRITY**：分区（partitions）内存布局、任务/进程表结构、航电/工业场景特征
|
||||
|
||||
同步：frontmatter 触发词加 VxWorks/QNX/INTEGRITY；跨域联合加 `[[re-automotive]]`；「何时使用」扩一句商业 RTOS 场景。
|
||||
|
||||
### 4.2 re-behavior + 行为监控工具链（+1 节）
|
||||
|
||||
- **ProcMon**：过滤/标注/CSV 导出关联（进程→文件→注册表→网络时间线）、过滤语法要点
|
||||
- **API Monitor**：API 级 hook 链与调用参数记录（与 re-tracing 的 strace/ltrace 形成 Windows 侧对应）
|
||||
- **ETW**：会话与事件解析（logman/wevtutil 命令；采集侧视角，与 re-evasion 的绕过侧互补）
|
||||
- **Process Explorer**：进程树/句柄/签名验证视图要点
|
||||
- 仅 Windows 工具注明跨 OS 约束（Linux 侧对应走 re-tracing）
|
||||
|
||||
## 5. 挂载与同步清单
|
||||
|
||||
1. `re-analyze/references/triage.md`：路由表补分支——固件行（ARM/RISC-V 分流）、托管行（Electron/Java Card）、游戏行（re-console）；按实际表格逐行核对
|
||||
2. `re-analyze/references/rerouting.md`：A/B 证据→技能表补行（`.NSO/NPDM`→re-console、BPF ELF section→re-ebpf、CAP 文件头→re-javacard、asar 结构→re-electron、VxWorks/QNX 特征串→re-rtos、MMIO 外设区→re-arm 等）
|
||||
3. 网关子技能列表：re-binary-core 补 `[[re-arm]]`/`[[re-riscv]]`（对标 `[[re-mips]]` 行）；re-managed 补 `[[re-electron]]`/`[[re-javacard]]`；re-game 补跨域 `[[re-console]]`；re-iot-proto 补跨域 `[[re-javacard]]`
|
||||
4. 计数同步：README / AGENTS.md / marketplace.json 技能数 112 → 118（逐字段核对，有计数则同步）
|
||||
5. 新技能创建后 `npm test` 预期输出按任务标注递增
|
||||
|
||||
## 6. 任务顺序与验证
|
||||
|
||||
- **任务顺序**：新技能（6 个）→ 扩章（2 个）→ 挂载同步 → 计数同步 → 终审修复波；新技能先于引用它的同步任务
|
||||
- **每任务**：实现 → 技术事实核对 + 红线对照 → `npm test` → commit（只 add 本任务文件）
|
||||
- **终审波**：全库交叉引用去重、计数一致性、死链清零、技术断言复核
|
||||
- **最终验证**：`node validate.mjs` 输出 `OK: 118 skills validated`；`npm test` 全绿（22 单测不受影响）
|
||||
|
||||
## 7. Errata（2026-08-25 实施期修正）
|
||||
|
||||
- **§3.5 CAP 组件数**：初稿「九组件（Header/Directory/Import/ConstantPool/Class/Method/Descriptor/Export/Applet）」有误——Oracle Java Card 3.2 VM 规范为 12 组件（tag 1-12），遗漏 StaticField(8)/ReferenceLocation(9)；正文与 re-javacard SKILL.md 已按规范修正，description 改为「规范 12 组件」。
|
||||
- **§3.5 字节码断言**：初稿「无 invokevirtual 等」有误——JCVM 四类调用指令齐备（invokevirtual 0x8B/invokespecial 0x8C/invokestatic 0x8D/invokeinterface 0x8E），真实 CAP 实证含 invokevirtual；与 JVM 的差异为无 invokedynamic/multianewarray/monitor 等。正文与 SKILL.md 已修正。
|
||||
@@ -0,0 +1,94 @@
|
||||
# DSH 预设就地化（取消独立 bundle 包）设计
|
||||
|
||||
日期：2026-10-12
|
||||
状态：已获用户批准（2026-10-12 逐节确认）
|
||||
|
||||
## 1. 总览
|
||||
|
||||
**目标**：把 rev-skills 的 DSH 独立预设从「仓库内第二个 npm 包」改为「根包自带的 bundle 声明」，去掉重复的包壳与随之而来的同步点；预设行为（预设 id、技能根解析顺序、`bin/dsh.mjs` 子命令）完全不变。
|
||||
|
||||
**来源**：PR #5（`dnfme:feat/dsh-preset`）。本设计在该 PR 的分支上追加提交，就地更新 PR。
|
||||
|
||||
**产出**：新增 1 个文件（`dsh.patch.yml`），删除 `dsh/` 整个目录（4 个文件），其余为常量、断言与文档同步。
|
||||
|
||||
## 2. 实测依据
|
||||
|
||||
下列结论均在本机 dsh 0.2.0-rc.2 上实测得出，非文档推断：
|
||||
|
||||
| 结论 | 证据 |
|
||||
|---|---|
|
||||
| bundle = 任意 npm 包 + `dsh.bundle.patch`；profile 的 `dsh.profile.bundles` 填**包名** | 以根包充当 bundle 搭临时 profile，`dsh --profile t3 --dump-config` 退出 0，`preset-rev-skills` 出现在末层，`customSkillDirs` 表达式解析到该包 `.claude/skills`（122 项） |
|
||||
| patch 文件名任意，路径由 bundle manifest 声明 | 由 `cordis.patch.yml` 改名 `dsh.patch.yml` 后重装并启动，行为不变 |
|
||||
| **patch 文件必须列进该包的 `files`** | 漏列时 `dsh plugin add` 被拒：`failed to read overlay …/node_modules/rev-skills/cordis.patch.yml: ENOENT`，随后还原 package.json / lock / node_modules |
|
||||
| `dsh plugin --profile <p> add <pkg>` 会自动追加 `dsh.profile.bundles` 行 | 实测 manifest 由 `["@deepseek-ai/dsh-base"]` 变为 `["@deepseek-ai/dsh-base", "rev-skills"]` |
|
||||
| bundle 的兼容性校验对无 `@deepseek-ai/*` 依赖的包不构成障碍 | 根包 manifest（含 `bin` / `scripts` / `engines`）直接通过校验并加载 |
|
||||
|
||||
`dsh.bundle.patch` 用 `link:` / `file:` 本地规格与从 registry 安装都走同一套解析（`resolveBundleDir` 先查 dsh 安装锚点，再查 profile 目录）。
|
||||
|
||||
## 3. 新布局
|
||||
|
||||
```
|
||||
rev-skills/
|
||||
dsh.patch.yml ← 新增（唯一新文件，仓库根）
|
||||
package.json ← 增加 dsh.bundle、files 换条目
|
||||
bin/dsh.mjs ← 两个常量
|
||||
docs/dsh-integration.md← 路线二与同步点表重写
|
||||
（删除）dsh/package.json、dsh/LICENSE、dsh/README.md、dsh/cordis.patch.yml
|
||||
```
|
||||
|
||||
`dsh/README.md` 的面向 DSH 侧说明并入 `docs/dsh-integration.md` 第 2 节；`dsh/LICENSE` 不再需要（补丁文件与 `bin/` 同属工具代码一侧，由仓库根 `LICENSE` 覆盖 Apache-2.0）。
|
||||
|
||||
## 4. 根 `package.json`
|
||||
|
||||
- 新增 `"dsh": { "bundle": { "patch": "./dsh.patch.yml" } }`
|
||||
- `files`：删除 `"dsh"`，新增 `"dsh.patch.yml"`（**必需**，见第 2 节第 3 行）
|
||||
- 版本：沿用 PR 的 `0.1.0`，与 `.claude-plugin/marketplace.json` 成对
|
||||
- 不变：`bin` 的 `rev-skills-dsh`、`scripts.dsh`、keywords、description
|
||||
|
||||
## 5. `dsh.patch.yml`
|
||||
|
||||
- 预设行与 18 个子插件配置照旧（补丁内本无包名，`config.id` 仍为 `rev-skills`）
|
||||
- `customSkillDirs` 表达式：删除第 4 候选（`rev-skills-dsh-preset/package.json` 的 `..` join）；原第 3 候选「包目录」即本包自身，语义不变
|
||||
- 头部注释按「本包即 bundle」重写；技能根解析顺序说明保留（`REV_SKILLS_DIR` → `<DSH_HOME>/skills` → 本包）
|
||||
|
||||
## 6. `bin/dsh.mjs`
|
||||
|
||||
- `BUNDLE_DIR`：`join(REPO_ROOT, 'dsh')` → `REPO_ROOT`
|
||||
- `BUNDLE_PACKAGE`：`'rev-skills-dsh-preset'` → `'rev-skills'`
|
||||
- `resolveLocalSkillRoot` 的候选说明文案：`从 rev-skills / rev-skills-dsh-preset 的 package.json 反解` → 单包
|
||||
- 其余逻辑（`check` 与四个 `preset` 子命令、dry-run、备份、原子替换）一行不动
|
||||
|
||||
## 7. 测试
|
||||
|
||||
- `tests/dsh.test.mjs`、`tests/dsh-preset.test.mjs`：导入常量与断言随包名/目录改名同步；夹具里的假 `node_modules/rev-skills-dsh-preset` 改为 `rev-skills`
|
||||
- `dsh/package.json 是合法 bundle 清单` 改为根 manifest 断言：`name` 为 `rev-skills`、`dsh.bundle.patch` 指向存在的文件
|
||||
- **新增回归断言**：`dsh.bundle.patch` 指向的文件必须出现在根 `package.json` 的 `files` 列表中（把第 2 节的坑固化；漏列即测试失败）
|
||||
- CLAUDE.md 的测试计数（`npm test = validate + 202 项测试`）按实际数同步
|
||||
|
||||
## 8. 文档
|
||||
|
||||
- `docs/dsh-integration.md`：第 2 节路线二重写（bundle 名为 `rev-skills`；安装命令 `dsh plugin --profile <p> add rev-skills`，本地路径用 `link:` / `file:`；说明 `add` 会自动登记 `bundles` 行）；技能根候选表删除第 4 行；第 6 节同步点表把「版本号 ↔ `dsh/package.json`」两行替换为「`dsh.bundle.patch` ↔ `dsh.patch.yml` 实际路径 + 该路径必须列进 `files`」
|
||||
- `README.md` / `README_EN.md` / `AGENTS.md` / `CLAUDE.md` 的 DSH 段落同步（涉及 `dsh/` 目录与包名 `rev-skills-dsh-preset` 的表述全部改写）
|
||||
|
||||
## 9. 验证清单
|
||||
|
||||
1. `node validate.mjs` → `OK: 122 skills validated`
|
||||
2. `npm test` → 全绿，计数与 CLAUDE.md 一致
|
||||
3. `node bin/dsh.mjs check` → `OK: 122 skills DSH-compatible (32 warning(s))`
|
||||
4. 临时 profile：`dsh plugin --profile <p> add <本仓绝对路径>` → manifest 自动出现 `rev-skills` bundle 行 → `dsh --profile <p> --dump-config` 退出 0 且含 `preset-rev-skills`
|
||||
5. `node bin/dsh.mjs preset spec|status|install --apply|uninstall --apply` 往返（dry-run 先行、apply 后 status 为 ok、uninstall 后复原）
|
||||
6. `npm pack --dry-run` 输出中包含 `dsh.patch.yml`
|
||||
|
||||
## 10. 不做
|
||||
|
||||
- 不改 `.claude/skills/` 下任何技能内容
|
||||
- 不改 PR 中与该目标无关的改动：`.gitattributes`、`lib/frontmatter.mjs` 的 CRLF 容忍与键文法放宽、`bin/install.mjs` 的 `--target dsh`、新增测试文件
|
||||
- 不删除 `bin/dsh.mjs` 的 `preset` 子命令（用户明确保留，尽管宿主 `dsh plugin add` 已覆盖安装路径）
|
||||
|
||||
## 11. 风险
|
||||
|
||||
| 风险 | 处置 |
|
||||
|---|---|
|
||||
| 根包被当作 bundle 后，兼容性校验要求声明 DSH peer 版本范围 | 实测无 `@deepseek-ai/*` 依赖即通过；若 DSH 后续收紧，退回独立包即可（本设计不改变补丁内容，两形态可互换） |
|
||||
| `files` 漏列 patch 文件 → 安装期才报错 | 测试固化为回归断言（第 7 节） |
|
||||
| 使用 `link:` 安装时 profile 直接引用工作区，改补丁立即生效、改后未重启则不生效 | 文档排错表保留「预设改完没生效」一行，处置改为重载/重启会话 |
|
||||
Reference in New Issue
Block a user