Files

baradok609hecl1pq6qi da24c2bd20 reverse-skills-max: initial public release (restored, redacted, hardened)

2026-10-20 02:17:15 +03:00

158 KiB

Raw Blame History

事实性缺陷审查记录

日期：2026-09-13 来源：批 1——外部 AI 审查清单（覆盖约几十个技能，非 121 全量穷尽）+ 本库逐条独立核验；批 2——独立监控（每日核对事实/技术/逻辑/命令错误）+ 本库自查补充用途：为「增量审查机制」（TODO.md）提供 finding 与核验结论

状态机：open（已记录待修）→ fixed（已修）→ verified（复核通过）

核验方法：本库原文 grep 定位（确认审查引文与文件一致）+ 上游权威源比对（AOSP 源码 / onnx.proto / can-utils 源码 / QEMU 源码 / HF safetensors 规范 / PyPI 元数据）。只有"原文与权威源直接冲突"才记为确认；术语与措辞类问题按"是否会导致错误推理"定级。

结论汇总：批 1（高 11 / 中 5）、批 2（高 1 / 中 4）、批 3（高 9 / 中-高 2 / 中 5）、批 3 补充（工具链 1）累计 38 项 finding——35 项技能缺陷 + 1 项工程性问题（历史文档污染）+ 1 项工具链一致性问题确认，1 项误报（见批 3 #37）；需澄清 2 点（见文末）。已确认缺陷全部修复（状态 fixed，待复核——见文末修复记录）。

高严重度（11 项，会直接导致错误操作）

#	技能	位置	现状（原文）	问题	修正方向	核验依据
1	re-android-crypto	SKILL.md:69	`const alias = ks.getKeyAlias(key);`	API 不存在。`java.security.KeyStore` 无 `getKeyAlias(Key)`（只有 `getCertificateAlias(Certificate)`，且只对证书条目有效）	hook `KeyStore.getKey(alias, …)` 时直接记录 alias；或枚举 `aliases()` 建 Key→alias 映射；或经 `SecretKeyFactory…getKeySpec(key, KeyInfo.class)` 取 `KeyInfo.getKeystoreAlias()`（AOSP 定义为 public，SDK 暴露面以官方 API 列表为准）	JDK KeyStore API + AOSP KeyInfo.java
2	re-android-crypto	SKILL.md:58, 96	"TEE 与 StrongBox 区分需 `isStrongBoxBacked`（API 28+）"	类搞错。`KeyInfo` 无此方法；`isStrongBoxBacked()` 在 `KeyGenParameterSpec`/`KeyProtection.Builder` 上（生成侧）	已生成 Key 的判定：API 31+ 用 `KeyInfo.getSecurityLevel()`（`SECURITY_LEVEL_STRONGBOX`/`TRUSTED_ENVIRONMENT`/`SOFTWARE`）；API 23–30 只能 `isInsideSecureHardware()` 粗判（TEE 与 StrongBox 同为 secure hardware，无法区分）	AOSP KeyInfo.java（无 isStrongBoxBacked，有 getSecurityLevel/isInsideSecureHardware）
3	re-macos	SKILL.md:79	"Secure Enclave 密钥：`SecKeyCreateWithData` 带 `kSecAttrTokenIDSecureEnclave`"	API 用错。`SecKeyCreateWithData` 是从外部 key data 导入/恢复，不是 SE 密钥生成；SE 密钥不能导入（只能设备内生成）	`SecKeyCreateRandomKey`（属性含 `kSecAttrTokenID: kSecAttrTokenIDSecureEnclave`），或旧 API `SecKeyGeneratePair`	Apple 文档语义（SecKeyCreateWithData = 外部数据导入；SE 绑定走随机生成）
4	re-ai-model	SKILL.md:70	"Safetensors：前 8 字节 = 大端 u64 头长度"	字节序反了，实为小端	`struct.unpack("<Q", data[:8])`	HF safetensors README 原文："8 bytes: `N`, an unsigned little-endian 64-bit integer"
5	re-mobile-forensics	SKILL.md:70, 72	"Manifest.plist（文件映射表：domain/相对路径 → 哈希文件名）"	文件搞错。现代备份（iOS 10+）的文件索引是 `Manifest.db`（SQLite `Files` 表：fileID/domain/relativePath/flags/file）；`Manifest.plist` 存备份元数据（Version/Date/IsEncrypted/BackupKeyBag/ManifestKey/Lockdown 设备信息等）。旧版 iOS（<10）索引才是 `Manifest.mbdb`	映射表指向 `Manifest.db`；`Manifest.plist` 改述为元数据与密钥材料载体	iOS 备份结构（Manifest.plist 元数据 / Manifest.db 索引）；本库 gotchas 与 decision-tree 方向一致，SKILL.md 与二者冲突
6	re-mobile-forensics	SKILL.md:72	"文件按内容哈希命名"	不是内容哈希。fileID = SHA1(domain + "-" + relativePath)，由路径派生，与文件内容无关——不能拿它当完整性校验	明确写 path-derived fileID；与 gotchas.md:13 的既有正确表述对齐	同上（库内 gotchas:13 已写对，SKILL.md 与之矛盾）
7	re-mobile-forensics	SKILL.md:74	"加密备份判定：Manifest.plist 无法明文读取而 Info.plist/Status.plist 正常"	判定反了。`Manifest.plist` 在加密备份中仍可明文读取（`IsEncrypted`/`BackupKeyBag`/`ManifestKey` 就在其中）；被加密的是 `Manifest.db` 与各文件内容	改为：读 `Manifest.plist` 的 `IsEncrypted` 键判定；再按备份密码/keybag 解 `Manifest.db`	同上（加密备份的密钥材料存放位置）
8	re-riscv	SKILL.md:76	"reset 向量（QEMU virt 机器 0x80000000…）"	地址语义混淆。virt 的 MROM（reset 向量所在）在 `0x1000`；`0x80000000` 是 DRAM 基址，即 reset stub 跳转的默认目标	写作：CPU 从 `0x1000` 的 MROM reset stub 起，stub 跳 `start_addr`（默认 DRAM `0x80000000`；pflash 固件场景为 `0x20000000`）	QEMU `hw/riscv/virt.c`：`VIRT_MROM=0x1000`、`VIRT_DRAM=0x80000000`、`riscv_setup_rom_reset_vec(…, start_addr, MROM.base, …)`
9	re-dotnet	SKILL.md:72	"EntryPoint RVA（0=DLL）"	不总是 RVA。该字段是 union（ECMA-335 II.25.3.3 EntryPointToken）：未置 `COMIMAGE_FLAGS_NATIVE_ENTRYPOINT` 时为 metadata token（MethodDef/File），置位时才是 native code RVA；"0 = 无入口"成立	写作 EntryPointToken / EntryPointRVA union，按 `COMIMAGE_FLAGS_NATIVE_ENTRYPOINT` 决定解释	ECMA-335 II.25.3.3 CLI header 字段定义
10	re-automotive	SKILL.md:89, 149	`candump can0 -f 0x7E0:0x7FF`（注释作 ID 过滤）	命令错。`-f <fname>` 是把日志写入文件（这条命令会生成名为 `0x7E0:0x7FF` 的日志文件）。过滤语法在接口名后的逗号位：`candump can0,7E0:7FF`（`can_id:can_mask`，匹配条件 `received & mask == can_id & mask`）	两条命令拆开：过滤 `candump can0,7E0:7FF`；写文件 `candump -f <file> can0`	can-utils 源码 `candump.c` usage（`-f <fname> (log CAN-frames into file <fname>)`）+ Debian manpage 过滤语法节
11	re-forensics	SKILL.md:15	"转储来源：…没有则按 re-memdump 转一份（`gcore -o out <pid>`…）；已有 .raw/.mem/.core 直接进入下一步"	与子技能自相矛盾且工作流错误。gateway 把 gcore 产物当取证默认来源；但 re-mem-forensics:52 与 re-memdump:73 明确 gcore 是单进程 ELF core（无内核结构/页表），Volatility 整机插件不可解析	分流：gcore → gdb/eu-stack 进程级复盘；整机镜像（LiME/AVML/崩溃转储等）→ Volatility	库内三处原文对照（re-forensics / re-mem-forensics / re-memdump）

中严重度（5 项，会导致错误推理）

#	技能	位置	现状（原文）	问题	修正方向	核验依据
12	re-ai-model	SKILL.md:69	"起始字节形如 `08 08 12 <len> ...`"	不能当识别 signature：第二字节是 ir_version 的值，随 ONNX 版本递增（当前已发布 13 = `0x0D`，main 分支枚举已到 14），不是固定 8；`producer_name` 为 SHOULD present，不保证出现	保留"protobuf 无固定魔数"，把 `08 08 12…` 降为"部分旧样本的形态举例"，并说明首字段是 ir_version（tag `0x08` + 变长值）	onnx.proto `Version` 枚举（IR 1…13 已发布，14 待发布）
13	re-dotnet	SKILL.md:73	"版本串（"v4.0.30319"，.NET Framework/.NET Core/.NET 10 产物恒定）"	常见默认值≠不变量。`MetadataRootBuilder` 默认确为 v4.0.30319，但参数可指定其他串；ECMA-335 允许 vendor-specific 版本串	改为"典型默认值（Roslyn/MetadataRootBuilder 产物常见）"，不作恒定断言	ECMA-335（版本串为自由格式）+ MetadataRootBuilder 默认值语义
14	re-macos	SKILL.md:78	"钥匙串条目类型…与 ACL（`kSecAttrAccessible` 可访问性类）"	术语不准。`kSecAttrAccessible` 管"设备处于什么状态时条目可读"（可访问性）；访问控制是 `kSecAttrAccessControl`/`SecAccessControl`（生物识别/密码门槛），macOS 传统 ACL 另有 `SecAccess`/`kSecAttrAccess`	SKILL.md 与 gotchas.md:30 的既有正确区分对齐（ACL 与可访问性分开表述）	Apple 钥匙串属性语义；库内 gotchas:30 已正确区分
15	re-mem-forensics	SKILL.md:21 vs :23	标题"（Python 3.8-3.11）"，正文"官方要求 Python 3.8+…3.14 可安装"	标题与正文矛盾：官方只要求 `Python >=3.8.0`，无 3.11 上限	标题去掉上限（"Python 3.8+"）	PyPI volatility3 元数据（Requires Python >=3.8.0）
16	re-ransomware	SKILL.md:65	"熵（>7.0 已加密）"	高熵≠加密：压缩数据、媒体文件、随机填充、压缩 section 同样高熵；此处把证据写成了判定	改为"高熵（>7.0）→ 加密/压缩/高随机性候选，需结合文件头与上下文佐证"	方法论（本库 re-anti-analysis:199、re-binary-core R24 已写"高熵≠加密"）

#16 范围补充：库内多数位置措辞正确（"可疑加壳/加密""密文/压缩候选""提示加壳/加密"），硬化表述目前定位到 2 处——re-ransomware:65 与 re-proto-rev:136（">7.5 几乎肯定加密"）。修复时一并收敛。

批 2（2026-09-13，独立监控 + 本库自查）

#	严重度	技能	位置	现状（原文）	问题	修正方向	核验依据
17	高	re-frida 等 9 文件	re-frida/SKILL.md:76,90,113,136；re-frida/references/frida-scripts.md:33-34；re-android-native/SKILL.md:115；re-android-native/references/probes.md:26；re-crypto-id/SKILL.md:111；re-ios-jb/SKILL.md:86；re-flutter/SKILL.md:114；re-address-space/SKILL.md:26,72,80	`Module.findExportByName(...)` / `Module.getExportByName(...)` / `Module.enumerateExports(...)` / `Module.findBaseAddress(...)` 等静态调用	Frida 17.0.0 移除了全部静态查找/枚举 API（静态仅存 `Module.load` / `findGlobalExportByName` / `getGlobalExportByName`）——安装指引给的是 `pip install frida-tools`，用户拿到 17+ 后示例报 `is not a function`；属横向污染（多技能共享旧模板）	迁移为模块实例调用：`Process.getModuleByName("libfoo.so").findExportByName("func")`、`.base`、`.enumerateExports()`；全局符号（原 null 模块参数）用 `Module.findGlobalExportByName(...)`；re-frida 补迁移条目，其余技能就地改写	Frida 17.0.0 发布公告（静态 API 移除清单与替代写法）+ 官方 JavaScript API 文档（Module 静态/实例方法现行清单）
18	中	re-frida-script-author	SKILL.md:73	"`Interceptor.attach` 的 onEnter/onLeave 里 `this.context` 读寄存器、`this.returnValue` 改返回值"	`this.returnValue` 不存在：`this` 上只有 returnAddress/context/errno/lastError/threadId/depth；改返回值必须用 onLeave 参数 `retval.replace(...)`——脚本生成方法论技能写错会系统性复制进新脚本	改为 onLeave `retval.replace(...)`；注明 retval 跨调用复用、需留存时先复制	官方文档 Interceptor 节（onLeave(retval)、replace()、`this` 属性清单无 returnValue）
19	中	re-ics	SKILL.md:87	`ModbusPDU03ReadHoldingRegistersRequest(start_addr=0, quantity=10)`	字段名错：scapy 定义为 camelCase `startAddr`（`XShortField("startAddr", 0x0000)`），可直接复现	改 `startAddr=`	scapy 源码 `scapy/contrib/modbus.py` 字段定义
20	中	re-angr	SKILL.md:25,122；references/gotchas.md:5	"angr 9.2.x 支持 Python 3.8–3.11"	9.2.x 不是固定区间：下限随补丁版本抬高（9.2.91 要求 ≥3.8 → 9.2.203 要求 ≥3.10）；"9.3.0 起 3.12+" 半句正确	改为"9.2.x 下限随补丁版本抬高，装前以目标版本 PyPI `requires-python` 为准"	PyPI 元数据：9.2.91（≥3.8，2024-02）、9.2.203（≥3.10，2026-02）、9.3.4（≥3.12）
21	中	re-ios-jb	SKILL.md:88	`Memory.readCString(a[0])`	`Memory` 下无 readCString（Memory 静态仅 scan/alloc/copy/dup/protect/patchCode/queryProtection/allocUtf8String 等）；读 C 字符串是 NativePointer 实例方法（本库自查发现，与 #17 同类）	改 `a[0].readCString()`	官方文档 Memory 节方法清单 + NativePointer 节

说明：re-frida-script-author 的 gotchas.md 与 SKILL.md 坑节此前已正确记载 Frida 17 迁移写法——说明问题不在知识缺失，而在"迁移只写进了说明、没落到示例"；本次修复即把示例与说明对齐。

批 3（2026-09-13，独立监控第二轮）

覆盖 8 个技能，16 项——15 项确认并修复，1 项误报（#37）。

#	严重度	技能	位置	现状（原文）	问题	修正方向	核验依据
22	高	re-automotive	SKILL.md:96	`candump -c can0 # 每 ID 帧计数`	`-c` 是颜色模式（increment color mode level），不计数——照抄得到彩色输出而非统计	改 `candump can0 \| awk '{print $2}' \| sort \| uniq -c`；坑节同步	can-utils 源码 `candump.c` usage
23	中	re-automotive	SKILL.md:87	"落盘日志（自动轮转…）"	无轮转：源码只一次 `fopen(logname,"w")`，无大小/时间触发；默认文件名带时间戳	改述为"默认文件名带时间戳；无轮转，需要轮转交给 logrotate/外部脚本"	can-utils 源码 `candump.c` 日志处理段
24	高	re-disk-forensics	SKILL.md:89	`tsk_recover -e … # 批量恢复全部已删除文件`	语义反了：默认行为才是只导未分配（已删除）文件；`-e` 是已分配+未分配全部文件（`-a` 只导已分配）	默认命令去掉 `-e`；`-e` 单列一行注明"全部文件"	sleuthkit `tsk_recover(1)` man page
25	中-高	re-disk-forensics	SKILL.md:115	`dd … skip=<A_end> count=<B_start-A_end>`	off-by-one：mmls 的 End 是含端点的末扇区（源码 `part->start + part->len - 1`，即 Length=End-Start+1）；真正的 gap 从 A_end+1 起	改 `skip=$((A_end+1)) count=$((B_start-A_end-1))`；提示直接用 mmls 的 Unallocated 项 Start/Length	sleuthkit 源码 `tools/vstools/mmls.cpp`（printf 与算术）
26	高	re-format-pe	SKILL.md:102	`for cid, count, off in rh['values']:`	必然报错：pefile 的 `values` 是扁平整数数组 `[compid, count, …]`（源码 `headervalues += [.., ..]`），无三元组、无 `off`，且已按 key 解密	改 `vals=rh['values']; zip(vals[0::2], vals[1::2])`	本地装 pefile 读 `parse_rich_header` 源码
27	高	re-format-pe	SKILL.md:86	`ptr_size = 8 if pe.FILE_HEADER.Machine == 0x8664 else 4`	判据错：位宽由 Optional Header Magic 决定（0x10b=PE32 / 0x20b=PE32+）；ARM64(0xAA64) 也是 PE32+，会被按 4 字节读	改按 `pe.OPTIONAL_HEADER.Magic == 0x20b` 判定	PE/COFF 规范（Machine 与 Magic 语义分离）
28	高	re-format-elf	SKILL.md:91	"`DT_BIND_NOW`/FLAGS 出现 = 全 RELRO、GOT 只读"	把两个独立条件写成等价：BIND_NOW 只表示启动时完成绑定；只读重定位区由 `PT_GNU_RELRO` 建立	全 RELRO = `PT_GNU_RELRO` + BIND_NOW；仅 RELRO = Partial；仅 BIND_NOW 推不出 RELRO	GNU ld 文档（`-z now` 与 `-z relro` 分列定义）
29	中	re-format-elf	SKILL.md:73	`objdump -d -j .init_array` "逐条反汇编回调地址"	-d 不处理数据节：.init_array 是函数指针数组，-d 只反汇编被标记为指令的节，实际无输出	改 `objdump -s` 取指针，再按指针地址反汇编目标函数	objdump 语义（节标志决定 -d 范围）
30	高	re-format-elf/references/layout.md	:32,:34,:132	e_phnum/e_shnum 扩展编号写成同一套（"同上 PN_XNUM 溢出处理"）	混了三套独立规则：e_phnum==PN_XNUM → `shdr[0].sh_info`；e_shnum==0 → `shdr[0].sh_size`；e_shstrndx==SHN_XINDEX → `shdr[0].sh_link`	三条分别写清，并建议配 parser fixture 验证	ELF 规范（扩展编号三规则）
31	中	re-format-elf/references/layout.md	:29	e_flags "MIPS 的字节序/ABI 位"	无字节序位：MIPS e_flags 是 ABI/ISA/PIC/NaN 等；字节序始终由 `e_ident[EI_DATA]` 决定	改述为 ABI/ISA/PIC/NaN，并注明字节序看 EI_DATA	ELF/LLVM 的 EF_MIPS_* 定义
32	高	re-format-macho	SKILL.md:70,:130；references/layout.md:89	`__LINKEDIT` "无映射内容""运行时不可访问"	错：它是正常段（有 vmaddr/vmsize），通常映射为只读区域（vmmap 可见）；只是 shared cache 场景链接元数据驻留方式不同	改述为"只读映射段；shared cache 影响驻留方式"，并提示按 LC_SYMTAB 用 nm/dyldinfo 定位而非照抄文件偏移	Mach-O 段语义 + dyld shared cache 行为
33	中	re-macos	SKILL.md:56	"看 `com.apple.quarantine`（…来源 URL）"	quarantine 记录隔离标志/时间戳/责任方，不含来源 URL；来源信息在 Spotlight 属性	来源改用 `mdls -name kMDItemWhereFroms`	Apple quarantine 与 kMDItemWhereFroms 语义
34	中	re-address-space	SKILL.md:55	"PIE = 0（所有地址是相对偏移）"当不变量	格式无此要求：ET_DYN 的最低 p_vaddr 不必为 0；load_bias 应按最低 PT_LOAD p_vaddr 与运行时映射求差	改为"取最低 PT_LOAD 的 p_vaddr，别假设 PIE 必为 0"	ELF GABI（base / load bias 定义）
35	高	re-hypervisor	SKILL.md:68	VMCS 编码"索引在 bits 9:0"	漏 bit0 语义：bit0=访问类型（full/high），索引在 bits 9:1（9 位）；类型 bits 11:10、宽度 bits 14:13	写全四段位域并给解码式 `index=(enc>>1)&0x1ff` 等	Intel SDM VMCS 字段编码（示例 0x400C/0x681E 复核通过）
36	高	re-hypervisor	SKILL.md:87	`echo 1 \| sudo tee /sys/module/kvm_intel/parameters/nested`	当前内核写不进去：`module_param(nested, bool, 0444)` 只读，sysfs 写入失败	改 `modprobe -r kvm_intel && modprobe kvm_intel nested=1`，`/etc/modprobe.d` 持久化，读参数验证	内核 commit 801d3424（`module_param(nested, bool, S_IRUGO)`，S_IRUGO=0444 只读）+ RHEL/Fedora/SUSE 文档均以 modprobe 重新加载开启
37	误报	re-uefi	——	监控称仓库有 `uefifind fw.bin all list <GUID>` 并把 GUID 文本当 pattern	仓库不存在该写法：`uefifind` 全文仅 2 处且都正确（位置参数语法 + 紧邻一行已指向 UEFIExtract 的 GUID 模式）	不修；记录为误报	全仓 grep + `uefifind(1)` man page 复核

工程性问题：历史文档污染（本轮记录，已缓解）

现象：docs/superpowers/{plans,specs}/ 是历史存档、不随技能修订同步——grep 确认 2 处保留已修正的旧错误（plans/2026-08-18-six-skills.md:239 的 SecKeyCreateWithData；plans/2026-08-18-six-skills-v2.md:449 的"内容哈希 + manifest.plist 映射"）
风险：不在人读，而在 Agent/RAG 全仓检索时把已修错误重新召回
缓解（已实施）：① 新增 docs/superpowers/README.md 声明本目录为历史存档、当前事实以 .claude/skills/ 为准；② 两处旧错误就地标注"已于 2026-09-13 修正 + 现文位置"（保留原文，不重写历史）；③ CLAUDE.md 开发工作流节加注：历史存档不得当现行指引检索
待定：是否给全部 27 个历史文档统一加头部横幅（当前只处理了含已知错误的 2 个文件）

批 3 补充：工具链一致性问题（#38，用户报告，已修）

#	严重度	位置	现象	问题	修正方向	核验依据
38	高（工具链）	`validate.mjs` vs `bin/convert.mjs`	规范（`docs/skill-template.md`）写「frontmatter 标准 YAML」，但 `validate.mjs` 是逐行解析、不支持块标量；`bin/convert.mjs` 另有一套支持块标量的实现	同一仓库两个解析器对同一批文件结果不同：104/121 个技能的 `description` 用 `>` 折叠块，validate 侧解析成字面量 `">"`（非空 → 恒过），「description 非空」校验对 86% 的技能是空转；且名称/描述一致性无从校验	抽出单一实现 `lib/frontmatter.mjs`（支持简单 scalar / 块标量 `>` `	`/ 内联 flow list 与 JSON；其余 YAML 特性显式不支持并写明扩展流程），`validate.mjs`与`bin/convert.mjs` 改为共用；补回归测试
38-fix	——	新增 `lib/frontmatter.mjs`、`tests/frontmatter.test.mjs`；改 `validate.mjs`、`bin/convert.mjs`	——	——	6 条新测试：折叠/字面块标量、空块标量报错、块标量不吞并同级键、`splitFrontmatter` 行为、全技能跨解析器一致性回归（直接编码被破坏的那条不变量）	`npm test` 31 项通过（原 25 + 新 6）；修复后 `description` 不一致 0 个、空描述 0 个

批 3 补充 2：触发词双语校验（#39，用户要求，已实施）

背景：#38 修复前 validate 看不到块标量里的真实 description，AGENTS.md 的「description 含中英触发词」约定从未被 CI 兜住
实施：validate.mjs 的 checkSkillDir 增加断言——description 须同时含 CJK（U+3400–4DBF / 4E00–9FFF / 3040–30FF / AC00–D7AF）与拉丁字母；规格同步 docs/skill-template.md、AGENTS.md、CLAUDE.md
存量核查：实施前全量检查 121 个技能——双语俱全 121、缺 CJK 0、缺拉丁 0，规则不误伤存量
测试：新增 1 条（双语通过 / 仅中文报错 / 仅英文报错）；4 个测试夹具与 2 处内联 description 同步补英文（夹具只应暴露其目标缺陷，不叠加无关错误）
结果：npm test 32 项通过（原 31 + 新 1）

批 3 补充 3：能力层未闭环（#40，用户报告，部分闭环）

核查（三处断点）：
1. 声明覆盖：仅 23/121 技能声明 capabilities（网关 11/12、原子 12/108、入口 0/1）
2. 消费：0——全仓 grep capabilit 在 re-analyze/ 下只命中注册表自身；triage/rerouting 仍按领域名与关键词路由
3. 完整性：只有"标签须在注册表内"一条检查；注册表 52 个标签中 15 个无人声明（悬空）
本次闭环（元数据 → 索引 → 可查询 → CI 防漂移）：
- 悬空清零：为 15 个悬空标签补声明（14 个技能，均为技能名与标签语义一一对应者，如 tracing→re-tracing、tee-analysis→re-tee、binary-diffing→re-variant）——现 标签 52/52 有声明
- 新增查询表 re-analyze/references/capability-index.md（lib/capability-index.mjs 渲染、bin/capindex.mjs 生成）：「能力 → 技能」反查 + 未声明清单 + 覆盖率计数（标签口径 + 技能口径），路由/检索首次有消费入口
- CI 两条新检查：注册表标签悬空 → 报错；索引过期 → 报错（提示 node bin/capindex.mjs）
- 测试 +5（注册表解析 / 标签反查 / 悬空检出与消失 / 索引三态（缺失·过期·同步）/ 渲染内容）
仍未闭环（需定策略）：
- 技能覆盖 37/121——按注册表既定的「渐进策略」，剩余 84 个技能未标注；本次只补悬空项，未做全量标注（避免与既定策略冲突）
- 路由仍按领域名——triage/rerouting 未改为「输入特征 → 需要能力 → 技能」，索引已就绪，属设计级改造
结果：npm test 37 项通过；OK: 121 skills validated

批 3 补充 4：全局数据契约偏文件域（#41，用户报告，已修）

现象：re-analyze/references/analysis-contract.md 的 §一上下文清单与 §三数据契约只有一套文件域字段（sha256 / arch / format / entropy / sections / imports_exports / strings_refs / base_addr / symbols_known），除 sha256 外均为 PE/ELF 视角——SDR、CAN、AI 模型、TEE、取证等域无字段可用
影响面：81 个文件引用 [[analysis-contract]]；点名具体字段的仅 2 处（re-triage 输出契约、re-address-space 的 base_addr）；其余为非文件域技能的泛引（只引 §四复核格式，域中立）——故改动以契约结构为主
修复：改为两层结构——核心字段（所有域必带：target_id / sha256 / evidence / findings / unverified，与 §四复核格式对齐）+ 域扩展字段（10 个域组：文件/二进制、网络/协议、总线/车载、射频/SDR、AI 模型文件级、AI 模型行为级、移动/托管、TEE、取证/情报、沙箱/行为）；§一上下文清单改按域展开；新增 §3.3 传递规则（核心必带、域字段选填不要求跨域填充、只增不改）
核验：用户点名的 5 个域（SDR / CAN / AI model / TEE / 取证）均有字段组；契约内 [[链接]] 全部解析通过；非文件域技能无硬套文件域字段的表述（逐条 grep 确认）
结果：npm test 37 项通过；OK: 121 skills validated

批 3 补充 5：能力层剩余缺口闭环（#42，用户要求，已闭环）

技能覆盖：84 个未声明技能全部标注——原子技能 108/108（入口 re-analyze 与元网关 re-feedback 按策略省略，索引显示 119/121）
标签缺口：全量标注暴露注册表缺口——12 类能力此前无标签可表达（架构相关、语言运行时产物、磁盘取证、eBPF、Electron、虚拟化、越狱、跨平台框架、利用开发、二进制补丁、插件开发、沙箱搭建），补齐（52→64）
路由按能力匹配：triage.md 目标表（19→30 行）与 rerouting.md A 表（23→33 行）全部加「需要能力」列，技能列改为索引反查结果；A 表同时补齐此前缺行的域（语言产物、RISC-V/MIPS、hypervisor、eBPF、磁盘/整机取证、越狱、白盒、内核驱动、HarmonyOS、TLS、变体对比）
CI 防漂移（累计 4 条）：原子技能必须声明能力｜路由能力列标签须在注册表内｜路由标称能力须被本行技能声明｜索引须与声明同步（+ 此前的注册表标签不得悬空）
反向验证：故意改错 A 表一行能力 → validate 精确报出 rerouting.md:15 路由标称能力 'tls-analysis'，但本行技能（re-packer-id / re-anti-analysis）均未声明该能力；还原后 OK
结果：npm test 39 项通过（+2：原子技能必须声明、路由一致性）；OK: 121 skills validated
遗留（可选）：网关内部选择树未加能力列——网关内调度仍按输入形态判定树，属网关层设计，未纳入本轮

批 3 补充 6：网关选择树能力标注（#43，用户要求，已完成）

范围：11 个有选择树的网关（re-binary-core 与 re-anti-analysis 无独立选择树，走「完整工作流」段）+ 各网关完整工作流段
产出：336 处链接标注能力（选择树段 100% 覆盖，11 个网关全部 0 遗漏）；网关内调度可直接读「输入形态 → 技能（能力：tag）」
约定：[[re-xxx]]（能力：tag1、tag2）——显式「能力：」前缀。标注过程中发现原格式 （tag） 与「链接 + 反引号代码」不可区分：re-memdump 的 [[re-x64dbg]]（minidump 命令） 被误判成能力标注（minidump 非注册标签），故加前缀消歧；无前缀括号一律视为普通说明
CI：选择树段内技能链接必须带标注；标注的能力须在注册表内且被被标注技能真的声明；非技能链接（references 文档如 platform-tips）豁免
反向验证：删掉 re-mobile 一处标注 → FAIL: re-mobile: 选择树内 [[re-apk]] 缺少能力标注（形如 [[re-apk]]（能力：\能力`））`；还原后 OK
过程中修正的检查器缺陷 2 处：① 括号嵌套时把内层 [[子技能]]（能力：…） 的标签算到外层（改为只取链接括号开头的连续标签段）；② references 链接被误要求能力标注（改为只校验技能链接）
结果：npm test 40 项通过（+1：选择树标注一致性）；OK: 121 skills validated

批 3 补充 7：新增 re-sample-acquire（#44，用户要求，已落地）

缺口（用户发现）："只有现象描述、没有样本"时缺一个采集环节——现有零件都以前提"样本已在手"开头（re-memdump 需已知 PID、re-netcap 需能抓包、re-fileless / re-loader 需已有样本、re-triage 需已有文件）；入口输入类型表也无"现象描述/无样本"这一档
形态：新增原子技能 re-sample-acquire（能力标签 sample-acquisition；原子 108→109，总数 121→122）= SKILL.md（141 行）+ 4 份平台分支 references/platform-{windows,linux,macos,sel4}.md（共 248 行）
核心方法论（用户提供 + 社区实践核验）：
- CORE RULE：不猜进程名、不依赖"用了哪个注入 API"——找「异常执行内存 + 到达该内存的执行上下文」；先问 provenance（这块可执行内存是谁创建的、经什么路径进来）
- 两特征 + 一补充：内存被改成可执行（W→X / RWX）；无背书区域在执行；线程起点/RIP/调用栈归属
- 漏检点（本轮重点补的）：只查 MEM_PRIVATE 会漏 module stomping（MEM_IMAGE + COW，需查 Working Set .Shared 位）；只看线程起点会漏 trampoline / SetThreadContext / jmp rcx / Win11 _beginthreadex 等绕过（要 PC + 调用栈一起看）；只按 MZ/PE 头找载荷会漏擦头 implant（保存整区再分类）；JIT/Wine/浏览器/安全软件本身就产生同类 artifact →评分制而非二元判定
- trigger 与 ground truth 分工：事件源只回答"何时 dump"，内存扫描回答"dump 什么"（直系统调用/共享段/覆盖已有 RX 区都能绕过用户态 hook）
四平台观测模型不同（用户要求不得机械翻译）：
- Windows：VAD/region + 线程 + 模块链；Sysmon 8/10/25、ETW-TI、内核回调三件套
- Linux：VMA（/proc/<pid>/maps，perms/pathname 语义；6.11+ PROCMAP_QUERY ioctl）；tracepoint/kprobe 与 BPF LSM（内核 BPF LSM 文档即以 file_mprotect 为示例，SEC("lsm/file_mprotect")）；process_vm_readv/ptrace 读取（受 ptrace access check）
- macOS：Mach task + VM region（vm_region_recurse_64/mach_vm_region*、mach_vm_read*）；Endpoint Security（NOTIFY_MMAP/NOTIFY_MPROTECT/NOTIFY_REMOTE_THREAD_CREATE/NOTIFY_GET_TASK，AUTH_* 可拦截）；权限现实——SIP 下 task_for_pid 对受保护进程 EPERM、Hardened Runtime 默认吊销内存读取、get-task-allow 可恢复（"不是 root 就能读"）
- seL4：capability 制，不存在"root 全读"模型；路线是构造期由 monitor 记录 provenance（TCB/frame/VSpace caps → execution provenance graph），TCB debug API 与 fault endpoint 作事件源；提问从"代码藏在哪个进程"改为"哪个 capability flow 授予了 executable authority"
挂载：入口输入类型表 + triage 路由行 + rerouting A 表 2 行 + re-malware 网关（子技能清单与选择树）；re-memdump 跨域反向指向（"未定转什么"时先走采集）
核验：各平台事实逐条对上游（内核 proc.rst / bpf_lsm.rst、Apple ES 与 SIP/Hardened Runtime 文档、seL4 debug API、PE-sieve 选项与 wiki）；npm test 40 项通过；OK: 122 skills validated；计数五处 + README 导航同步
备注：本技能是新的审查面（监控下一轮会按同样标准核验其 API/命令/判据）；采集动作本身留痕，技能内已写明授权边界与停止条件

批 3 补充 8：内核覆盖扩到跨平台（#45，用户要求，已落地）

缺口（用户发现）：内核态载荷覆盖只有 Windows——re-kernel 标题/触发词写死 Windows，且「何时不用」原文把 Linux 推给零散技能；全库关键词扫描 LKM / System Extension / kmod / insmod 0 命中，kext 仅 2 处顺带提及
形态：re-kernel 重构为跨平台 = SKILL.md（92 行主干）+ 4 份平台分支（windows-kernel 76 / linux-kernel 74 / macos-kernel 55 / android-kernel 42）；原 Windows 内容原样迁入 windows-kernel.md；两个纯 Windows 的旧 references 更名（gotchas.md→windows-gotchas.md、decision-tree.md→windows-decision-tree.md，git mv 保留历史）以免与新范围混淆
结构核心（按用户要求）：失败模式决策表——六类症状（struct offset 全错 / 符号解析怪异 / 文件与运行行为不一致 / 模块"消失" / driver IPC 调不通 / 异常 ELF section）→ 优先怀疑项（按顺序）→ 处理方向。要点是"观察与预期冲突时先怀疑什么"，而不是工具清单
macOS 按要求拆两代：KEXT（Info.plist 先行 → selector map 优先 → AuxKC 版本坑 → codeless kext → arm64e PAC）与 System Extension / DriverKit（用户态进程模型、激活与 entitlement 排错顺序：activated? → service? → entitlement/Team ID/sandbox → 才轮到 selector）
Linux 收录失败模式：.ko 是 ET_REL（relocation 即信息）；四类"看着像坏"的合法形态（签名尾 / BTF 与 split BTF+.BTF.base / RANDSTRUCT / livepatch .klp.rela）；5.7 起 kallsyms_lookup_name() 不再导出给模块；rootkit cross-view（lsmod 干净 ≠ 没有 + hook 落点不止 syscall table）
Android：GKI vs vendor module、protected symbol（KMI 白名单：构建期检查 check_buildtime_symbol_protection.py + 运行期拒绝加载）、KMI 分支不可互换（android12-5.10 ≠ android13-5.10）、模块位置与 modules.load 计划
采集侧同步（re-sample-acquire）：Linux 分支加"内核态载荷采集"（cross-view、内核 text 与磁盘副本 diff、hook 落点、采集时机、授权边界）；macOS 分支加"KEXT/DEXT 采集"（DEXT 按用户态进程处理、kext 先对齐 AuxKC 运行版本、内核内存读取的 SIP 现实）
核验（8 项上游）：kprobes 文档（"通常由 kernel module 注册"）、5.7 unexport 提交、CONFIG_DEBUG_INFO_BTF_MODULES 与 distilled .BTF.base（仅外置模块生成）、TAINT_RANDSTRUCT 与配置名、livepatch 节格式与 SHN_LIVEPATCH、AuxKC 与 LocalPolicy 字段、Android protected symbol/KMI 分支、dext 安装路径与 userclient entitlement。两处口径修正：① 5.7 的变化是"停止导出"而非 kallsyms 格式变更；② RANDSTRUCT 的配置名是 CONFIG_GCC_PLUGIN_RANDSTRUCT（T 是 taint 字符）
结果：npm test 40 项通过；OK: 122 skills validated
顺带发现（系统性问题，未修）：references 同名文件普遍——gotchas.md 33 个、decision-tree.md 13 个，导致 [[gotchas]] 一类链接在多技能间歧义（validate 只检查"存在"不检查"唯一"）。候选规则：references basename 全局唯一，或链接限定技能前缀——待定

批 3 补充 9：seL4 分析分支（#46，用户提供，已落地）

背景：用户指出 seL4 的经验更特殊——核心不是"内核模块怎么逆"，而是"如何不把 capability 系统的行为误判成普通 OS 行为"；此前 seL4 只落在采集侧（re-sample-acquire 的 monitor 视角），分析侧无覆盖
形态：re-kernel 新增第五个平台分支 references/sel4-kernel.md（201 行，五个分支中最大，印证"特殊情况密度可能高于 Linux LKM"）；SKILL.md 平台差异表加 seL4 行、失败模式决策表加 3 行（CPtr 本地地址 / MCS 卡住 / IRQ 只来一次）；re-sample-acquire 的 platform-sel4.md 加"方法侧入口"互链
内容（16 节 + 压缩决策树）：先识别运行模型（root task / 裸 libsel4 app / capDL / CAmkES / MCS / VM）→ CPtr 是 CSpace 本地地址不是全局 ID（跨 component 必须按 kernel object 对齐）→ capDL-loaded 不照搬 root-task slot 语义 → CAmkES glue 折叠 → badge（身份 vs bit 聚合事件）→ CSpace guard/depth 与 FailedLookup 四分类 → 错误码即诊断（DeleteFirst=目标非空 / RevokeFirst=有派生 / FailedLookup=index·depth·类型）→ Untyped 非 malloc（2^n 对齐、Revoke 父 untyped 才可重用）→ device untyped 只能变 Frame → IRQ 走用户态（未 ack 不再送）→ DMA 旁路不在 isolation proof 内 → fault 是 IPC（反复同一 fault = handler 没修）→ MCS（SC/budget/passive server/reply object/捐赠链被打断）→ capDL snapshot cross-view → capability 图必须带 rights
核验（上游）：seL4 manual（CSpace 与 CNode guard/depth 语义、错误码定义、"device untyped 只能 retype 成 frame 或子 untyped" 及附加限制）；MCS 发布说明与提交（SC = budget/period、passive server 依赖 client 捐赠、reply object 取代 SaveCaller 并跟踪捐赠、timeout fault、链中 reply object 被撤销则 SC 回不到发起者）；debug API（seL4_DebugSnapshot 输出 capDL、seL4_DebugCapIdentify 返回 cap 类型号）；capDL loader 与 root task 初始环境（slot 2/3 语义、初始 CNode guard 恰好解析 32 位）
核验中的三处精化：① seL4_DebugSnapshot 据 devel 列表是二进制命令/响应协议（等命令字 0xa0–0xff、回传二进制），不是人类可读文本转储；② device untyped 的限制不止"只能变 Frame"——device frame 还不能作 IPC buffer、不能建 ASID pool、ARM 上不能做可执行 frame，且 device 属性会被子 untyped 继承；③ Linux 侧同批核验中确认 5.7 的变化是 kallsyms_lookup_name() 停止导出（非格式变更）
结果：npm test 40 项通过；OK: 122 skills validated

批 3 补充 10：references 同名歧义治理（#47，用户决策，已落地）

决策：[[gotchas]] 这类跨技能裸链有歧义（gotchas.md 33 个、decision-tree.md 13 个）——用户在"basename 全局唯一"与"链接限技能前缀"之间选了后者
规则：技能链接 [[re-xxx]]；裸 references 链接 [[文件名]] 必须落在本技能 references/ 内；跨技能引用必须写 [[re-xxx/文件名]]（validate.mjs 强制，references 文件内同样校验——此前只查 SKILL.md 正文）
迁移：471 处跨技能裸引用加前缀（platform-tips 347、analysis-contract 104、anti-dynamic-workflow 10、frida-scripts 8、rerouting 1、sel4-kernel 1）；287 处本技能内引用保持裸链；2 处重命名遗留（re-kernel 的 gotchas/decision-tree）改为指向同技能新名
校验器改动：链接检查重写为三态判别（技能 / 跨技能 references / 本技能 references），并把校验范围从 SKILL.md 正文扩展到 references/*.md（跨技能引用多在这边）
占位符约定：文档里写示例用尖括号形式 [[re-<技能名>]] / [[<文件名>]]——不会被解析成真链接（改动过程中 capabilities.md 的格式说明自己触发过一次断链报错，即此问题）
反向验证：在 re-kernel/references/windows-gotchas.md 里写裸 [[platform-tips]] → FAIL: re-kernel/references/windows-gotchas.md: broken [[platform-tips]] link（裸 references 链接须在本技能 references/ 内；跨技能请写 [[re-xxx/platform-tips]]）；还原后 OK
结果：npm test 41 项通过（改 1 条链接规则用例 + 新增 1 条跨技能限定用例）；OK: 122 skills validated

批 3 补充 11：技能计数同步不完整（#48，用户发现，已修）

现象：新增 re-sample-acquire 后，计数只在"记得的 5 处"同步（README/README_EN/AGENTS/package.json/marketplace.json + README 网关行），漏了 5 处：CLAUDE.md 3 处（技能总数、OK: 121 skills validated 示例、架构图"原子技能 108 个"）、README/README_EN 前言"12 大类网关 → 108 原子技能"
根因：① 同步清单本身是记忆产物，没有"计数出现点"的全量来源；② 自查 grep 用了"旧数+单位"的复合模式，对全角括号与措辞差异过敏 → 首轮扫描报"零命中"的假阴性（真正的发现来自换用"数词散扫 + 逐文件人工核"）
修法：5 处改为 122/109；历史记录（TODO.md、docs/audit/、lib/frontmatter.mjs 注释里的"104/121"等）保留原值——它们是当时事实
固化：CLAUDE.md 的「新增/修改技能的标准流程」第 4 步从"同步 5 处"改为逐处清单（README 4 处 / README_EN 4 处 / AGENTS 2 处 / package.json / marketplace.json / CLAUDE.md 3 处），并写明自查方式与"不要用复合模式"的教训
核对：实际结构 122 = 1 entry + 12 gateway + 109 atomic，与文档现值一致
结果：npm test 41 项通过；OK: 122 skills validated

批 3 补充 13：macOS 低层分支加深（#49，用户提供，已落地）

背景：用户补充 macOS 低层逆向的失败模式——macOS 的坑在于三套完全不同的模型混在一起（KEXT+IOKit 内核态 / DriverKit·DEXT 用户态 / System Extension 框架），且四个事实最容易让整条分析链跑偏：① codeless KEXT 可能根本没代码 ② 磁盘 KEXT 与当前运行的可能不是同一版本（AuxKC）③ arm64e 指针不能当普通 64 位指针（PAC）④ IOServiceOpen 失败可能停在 entitlement/activation 层，根本没走到 UserClient
形态：macos-kernel.md 从 55 行扩到 286 行（现为该技能最大分支）；主干平台表 macOS 行改为「三套模型」，失败模式决策表加 3 行（符号化偏移 / kext 加载不了的完整条件 / UserClient 与 dispatch）
新增要点（相对旧版）：Info.plist 的 IOKitPersonalities 匹配键全集与"Info.plist 先行"顺序；IOKit class graph 优先于 call graph（OSMetaClass/vtable；unresolved virtual calls 常因缺 kernel/superclass type universe）；dispatch 字段的 check 前缀与 kIOReturnBadArgument 可能是框架层拒绝（含 completion 需要有效通知 Mach port）；dext 的停手信号与按用户态调试；System Extension ≠ DriverKit 同义词；Host app 与 dext 两边都要逆；六态生命周期（bundle→registered→approved→activated→matched→started）；Rosetta 不翻译 kext（KMErrorDomain Code=71）；Kernel Collection；panic 符号化的 __TEXT_EXEC.vmaddr 偏移与 UUID/KDK build 匹配；UAKL / Reduced Security / AuxKC / SIP 与签名校验的关系；KIP 机制；rootkit 的年代差异（10.x Intel → 11+ Apple Silicon）；KEXT 双机调试 vs DEXT 本机调试
核验（6 项上游）：Apple 文档的 dispatch 字段名（确认带 check 前缀，与 arguments 字段区分）、kIOReturnBadArgument 的端口成因（StackOverflow 实例为 checkCompletionExists=true + 错误端口）、panic 符号化 __TEXT_EXEC（Apple 开发者论坛 DTS 工程师答复，含 otool/atos 完整命令）、AuxKC/UAKL/1TR/签名校验（Apple 平台安全指南）、KIP 机制（内核初始化后启用、内存控制器拒写受保护区、MMU 双向限制、使能硬件启动后锁定）、Rosetta 不翻译 kernel extension（官方 Rosetta 文档 + Incompatible architecture 报错）
结果：npm test 41 项通过；OK: 122 skills validated
体量备注：re-kernel 现 1094 行 / 8 文件（主干 105 + 七份 references），已达"平台分支各自可成技能"的规模——是否拆分由用户判断，本轮未动

批 3 补充 14：Windows 驱动分支加深（#50，用户提供，已落地）

背景：用户补充 Windows 驱动分析的失败模式（33 点 + 决策树），核心是"先识别 driver model，再恢复 callback / 设备栈 / I/O 路径"，并点名七个最易产生事实性错误的点（把所有 .sys 当 WDM / GsDriverEntry 当入口 / MajorFunction 空当"无 I/O" / 不知道 KMDF·NDIS·minifilter 的 callback registration / 不知道 IRP completion 是异步控制流 / 不知道 IOCTL 的 Method 决定 buffer 语义 / 2026 年仍用旧签名假设）
形态：windows-kernel.md 从 76 行扩到 501 行（技能内最大文件）；同时接回两个旧 Windows reference 的链路（windows-gotchas / windows-decision-tree 在重写后一度成为孤儿——它们含独占内容：版本差异组与证据分级，故补链而非删除）
新增要点：驱动模型分类（WDM/KMDF/UMDF/minifilter/NDIS/StorPort/PortCls/AVStream）；GsDriverEntry；WDM 的 DRIVER_OBJECT 赋值图；KMDF 的 Evt* 与 WDF_*_CONFIG dataflow（!drvobj 指 Wdf01000.sys 属正常）；miniport 架构与 NDIS callback 图（网卡驱动无 READ/WRITE 正常）；device stack 与 INF 的栈位置（UpperFilters/LowerFilters/AddFilter）；minifilter 的 altitude 与 pre/post 流水线；CTL_CODE/METHOD_* 语义与 NEITHER 用户指针；completion edge 与 STATUS_PENDING；PAGE section 的 IRQL 语义与偶发 0xD1；Driver Verifier 的故障注入与 0xC9 的追链法；PE relocation；PDB public≠private 与 signature+age；!analyze -v 只是入口；UMDF/Wudfhost（!wdfkd.wdfumdevstacks、%ProgramData%\Microsoft\WDF）；2026 驱动签名策略；HVCI 兼容要求与 Test Mode 仍需签名；x64 patching 禁忌；callback-registration graph；IRP flow graph；minifilter unload 四态
核验（3 项上游，均带时间点）：① Microsoft Windows Driver Policy——2026-04 安全更新后旧 cross-signed 驱动默认不再受信，默认只认 WHCP 签名（另有 curated allow list）；先行评估模式（约 100 小时运行 + 2–3 次启动相关条件才转强制；期间发现不合规驱动则继续评估并重置计数）；企业可用 Application Control for Business 覆盖（须由 Secure Boot PK/KEK 权威签名）；适用 Win11 24H2/25H2/26H1 + Server 2025。② HVCI 官方 checklist（NX 默认、NonPagedPoolNx、不用 W+X 段、不直接改可执行系统内存、内核不用动态代码、数据不当代码、0x1000 对齐）+ Test Mode 在 HVCI 下仍要求签名（失败码 0xC0000428 / CodeIntegrity 219）+ Microsoft 计划 2026-10-13 起在符合条件设备默认启用 Memory Integrity。③ UMDF（!wdfkd.wdfumdevstacks 的 !process→.process /P→命令工作流；dump 路径 %ProgramData%\Microsoft\WDF，UMDF 2.15/Win10 1507 起；WER 三类事件 WUDFHostProblem/UnhandledException/VerifierFailure；wdfumtriage/wdfldr/wdfumirps/wdflogdump）
结果：npm test 41 项通过；OK: 122 skills validated；re-kernel 全部 references 均可达（孤儿检查通过）
体量：re-kernel 现 1522 行 / 8 文件（windows-kernel 501 / macos 286 / linux 277 / sel4 201 / android 42 + 主干 108 + 两份 Windows 附录）——拆分与否待用户决定

需澄清（非误报，但审查表述需修正）

candump -f 确实存在：上游 can-utils 当前版本有 -f <fname>（写日志文件），Debian bookworm 打包的 manpage（can-utils 2020.11.0）尚未收录该选项——核验时以源码为准。#10 的结论（原命令会写文件而非过滤）成立。
re-mobile-forensics 是局部不一致而非全错：gotchas.md:13 与 decision-tree 已含正确表述（SHA1(domain+relativePath)），缺陷集中在 SKILL.md 正文与 references 互相矛盾——修复时以 gotchas 为准并消除分歧。

未覆盖范围（局限）

批 1 为外部 AI 抽查（约几十个技能）结果、本库核验其列出的 16 项；批 2 为独立监控首轮 4 项 + 本库自查 1 项——均非 121 技能全量逐条审计
#17 同类风险面：本轮已 grep 排查 Memory.read*/write* 型访问器与 legacy 回调式枚举（Process.enumerateModules({...})），未见残留——但属关键字排查，未做全量语义校验
未核验的外部结论一律未入库；后续批次沿用本文档状态机续记

核验来源清单

来源	用途
AOSP `KeyInfo.java`（frameworks/base/keystore）	#1 #2 方法列表
JDK `java.security.KeyStore` API	#1
Apple Security 框架文档语义	#3 #14
HF `safetensors` README（Format 节）	#4
iOS 备份结构（Manifest.plist / Manifest.db）	#5 #6 #7
QEMU `hw/riscv/virt.c`	#8
ECMA-335 II.25.3.3（CLI header）	#9 #13
can-utils `candump.c` + Debian manpage	#10
库内原文三处对照	#11
onnx.proto `Version` 枚举	#12
PyPI volatility3 元数据	#15
库内既有正确表述（re-anti-analysis / re-binary-core）	#16

修复记录（2026-09-13）

批 1（#1–#16）、批 2（#17–#21）、批 3（#22–#36）共 36 项已全部修复，状态 fixed（待复核）；#37 为误报未改；工程性问题（历史文档污染）已按上述三层缓解处理。

涉及文件 28 个（技能 SKILL.md 21 + references 7），其中 Frida 17 横向迁移覆盖 9 个文件（批 1+2）；批 3 另改 10 个技能文件（含 2 个 references）+ 历史存档 2 处 + docs/superpowers/README.md + CLAUDE.md
校验：npm test 通过（OK: 121 skills validated + 25 项单测）；grep 复核确认已移除 API 无残留（保留的"旧写法"文字均为迁移说明性注释）
复核入口（后续波次）：按状态机 fixed → verified 逐项复核；重点复核两处语义选择——① Frida 迁移中 find*（返 null）与 get*（抛异常）在各示例语境下是否选得恰当；② re-forensics 转储分流的表述是否与实际 re-mem-forensics / re-memdump 边界完全一致

后续机制建议（来自同一审查，待评估）

审查提出把验证体系分四层：Syntax → API/CLI validity → Format/spec assertion → behavior fixture，即对 API 名做静态符号表比对、对 CLI 示例跑 --help、对格式常量做 spec 断言、对关键结论建最小 fixture（如生成最小 safetensors 验证前 8 字节、起 -S -s QEMU 验证 $pc、用脱敏备份验证 fileID 派生）。

可选落点：与 TODO「增量审查机制」合并设计——finding 记录（本文档格式）+ 高风险技能的 fixture 子集，先覆盖 ABI/offset/格式字段/API 名四类断言。

补充 15：特殊系统深化波次（2026-09-13，QNX / Fuchsia-Zircon / UEFI-PI / VxWorks / Zephyr / RTEMS / FreeBSD / illumos）

来源为外部整理的特殊系统调研（8 个系统的"核心模型 + 最危险误判"），按每一条具体机制先核验上游、再入库处理。本波次不是缺陷修复（原文无事实性错误），而是事实补全与边界条件补足，性质同"补充 1–14"。

落地位置（8 → 3 个技能，不新增技能）

系统	落点	形态
QNX Neutrino	`re-rtos/references/qnx.md`	新增分支（该技能原为单文件）
VxWorks	`re-rtos/references/vxworks.md`	新增分支
Zephyr	`re-rtos/references/zephyr.md`	新增分支
RTEMS	`re-rtos/references/rtems.md`	新增分支
UEFI / PI / EDK2	`re-uefi/references/pi-stages.md`	新增分支（该技能原为单文件）
Fuchsia / Zircon	`re-kernel/references/zircon-kernel.md`	新增分支（与 sel4-kernel 并列为 capability 系统）
FreeBSD	`re-kernel/references/freebsd-kernel.md`	新增分支
illumos / Solaris	`re-kernel/references/illumos-kernel.md`	新增分支

挂载点：re-rtos / re-uefi / re-kernel 的 SKILL.md（运行模型差异表 / 阶段判定表 / 失败模式决策表 / 分支指针）；re-analyze/references/rerouting.md A 表新增 9 条"异常信号 → 换路"行。

核验中发现并写入的边界条件修正（通行说法不完整之处）

#	常见说法	核验后的准确表述	依据
1	FreeBSD linker set 是 `struct linker_set {ls_length, ls_items[]}`，以 NULL 结尾	那是 a.out 时代的结构；现代 ELF 由 `__start_set_<名>` / `__stop_set_<名>` 定界，列表不再以 NULL 结尾——按结尾 NULL 扫描会越界；且 2001 年起宏已隐藏实现	freebsd-src 提交 f10fa038（"gensetdefs past its use-by date"）+ `sys/linker_set.h` 语义
2	illumos `attach()` 的命令值包含 `DDI_PM_RESUME`	现行文档命令值为 `DDI_ATTACH` / `DDI_RESUME`；`DDI_PM_RESUME` 属已废弃的 PM 接口（配套 `DDI_PM_SUSPEND`），是年代线索而非标准写法	`attach(9E)`（illumos/Oracle 现行页）+ `pm(9P)` 声明原 PM 接口过时
3	QNX 服务端"继承客户端优先级"	提升可发生在发送时刻（不等 server 收到）；回复后不自动恢复（直到被新消息/pulse 改变或显式设置）；另有 server boost（无 RECEIVE-blocked 线程时）；`ChannelCreate()` 的 `_NTO_CHF_FIXED_PRIORITY` 可关闭继承	QNX《Priority inheritance and messages》《Server boost》+ `MsgSend()`/`ChannelCreate()` 参考页
4	`zx_channel_write` 失败时 handle 归还原主	失败也会消费（handle 被丢弃而非归还）——改动后语义为"始终消费"；另：`channel_write_etc` 的 `ZX_HANDLE_OP_MOVE`/`DUPLICATE`、rights 只能收窄、in-transit handle 随 channel 销毁而关闭	Zircon `docs/handles.md`、`channel_write`（含 ZX-2204 语义变更）、`channel_write_etc`
5	`dlopen` 的 `RTLD_LAZY` 会推迟符号解析	RTEMS 上两者行为相同：`dlopen` 返回前全部重定位已完成；且未解析符号不导致失败（需 `dlinfo(RTLD_DI_UNRESOLVED)` 查）、重名符号判错、不支持符号版本	RTEMS `cpukit/libdl`（`rtl.h`）与 RTEMS C User's Manual 的 runtime link editor 章节
6	DXE 侧"不应修改 HOB"是约定	HOB 构造调用在 DXE 阶段会断言失败（PEI HOB 对 DXE 只读）；DXE 跨阶段状态只能走复位调用	PI Spec Vol.1 §9（PEI to DXE Handoff）+ EDK2 `HobLib.h` 注释
7	Zephyr 的 early init"不调用内核服务"是弱约定	`PRE_KERNEL_1/2` 运行于中断栈的内核初始化上下文，服务本就不可用——符合设计；反之出现线程/互斥/睡眠应先怀疑阶段判错	Zephyr `include/zephyr/init.h` 的 level 语义 + 设备/`SYS_INIT` init 基础设施拆分
8	VxWorks 模块"链接不完整"即损坏	DKM（`.out`）动态链接到内核符号表，独立观察必然大量 unresolved；`undefined symbol` 的真实成因是 VIP 未包含该组件；同版本 ≠ 同 ABI 环境（随 VSB/VIP 变化）	VxWorks 7 SDK Application Developer Guide + VSB/VIP 构建说明

其余事实（QNX dispatch_create/resmgr_attach/iofunc_* 序列、io-pkt 的 devnp-*.so 与 devnp-shim.so、单线程栈上下文与 nw_pthread_create；DFv2 的 driver manager/host/index/runtime 与同驻本地通道；PI 阶段与 DXE_RUNTIME_DRIVER 生命周期、EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE/ConvertPointer；Zephyr iterable sections 与 LLEXT/llext_add_domain；RTEMS confdefs.h/CONFIGURE_INIT 唯一性与 rtems_driver_address_table 的 major=表索引；FreeBSD SYSINIT 排序键与 SI_SUB_KLD 合并时机；illumos nulldev/nodev 语义差异）均按上游文档或官方头文件核验后写入，逐条依据见各分支文末"工具与验证"。

本轮校验

node validate.mjs：OK: 122 skills validated（含新分支的链接规则与路由能力校验）
npm test：41 项全过；node bin/capindex.mjs 重生成后无差异（本波次未增删能力标签）
未做：行为 fixture（LLEXT 装载、io-pkt 加载、OVMF 阶段切换等需真实目标或构建环境）——沿用"后续机制建议"的四层体系，先落在可选层

补充 16：特殊系统第二批（2026-09-13，分层 hypervisor / 分区 RTOS / 组件 OS，18 类）

来源为同源的外部整编（"再往外一层"两批：10 类 + 8 类）。处理方式同补充 15：逐条机制先核验上游再入库，属事实补全与边界条件补足，非缺陷修复。

落地位置（18 → 4 个技能，不新增技能）

类别	系统	落点
分区/嵌入式 hypervisor	Xen、QNX Hypervisor、Jailhouse、ACRN、Bao	`re-hypervisor/references/{xen,qnx-hypervisor,jailhouse,acrn,bao}.md`
RTOS 家族	NuttX、eCos、ThreadX Modules、FreeRTOS 上下文、INTEGRITY/ARINC 653/VxWorks 653/PikeOS	`re-rtos/references/{nuttx,ecos,threadx-modules,freertos-context,partitioned-rtos}.md`
通用 OS 内核	OpenBSD、NetBSD、Genode、MINIX 3、Plan 9·9front	`re-kernel/references/{openbsd-kernel,netbsd-kernel,genode,minix3,plan9}.md`
汽车软件	AUTOSAR Classic	`re-automotive/references/autosar-classic.md`

挂载：4 个 SKILL.md（平台差异/运行模型表 + 失败模式决策表 + 分支节 + description），rerouting.md A 表新增 15 行。

核验中确认的关键边界条件（写入时以这些为准）

#	主题	准确表述	依据
1	OpenBSD KARL	变的是内核内部布局，不是加载基址（与 KASLR 区分）；启动代码可被 unmap 或"trash"；手工把内核拷到 `/` 会使重链接脱开（分析环境≠生产环境）	KARL 原始设计公开讨论 + locore 固定/其余 `.o` 随机重排的实现描述
2	OpenBSD pledge	违规是不可捕获的 SIGABRT（非可捕获错误）；promise 只能削减不能恢复，提升尝试返回 `EPERM`（继承 execpromises 场景下被忽略并返回成功）；"不调用 pledge" ≠ `pledge("everything")`；`error` promise 改为返回 `ENOSYS`；线索为 `ps` 状态 `p` 与 `lastcomm` 的 `P` 标志	`pledge(2)` 手册页与其 ERRORS/承诺表
3	NetBSD 模块路径	`KERNEL_DIR` 是 2025-04-28 起（UPDATING 20250427）的可选构建选项，仅 i386/amd64；旧 `/stand/<arch>/<版本>/modules` 与新 `<内核目录>/modules` 并存；另有 kern/59394（内核仍以文件形式放在 `/netbsd` 时 `kern.module.path` 报错）	NetBSD UPDATING、`wiki.netbsd.org/kernel_dir/`、kern/59394
4	Xen grant 撤销	映射期间 Xen 不支持撤销：结束外来访问只阻止后续映射，须等 `GTF_reading`/`GTF_writing` 清零；grant reference = 本域 grant table 条目下标（条目含 flags/domid/frame-MFN）	Xen `docs/misc/grant-tables.txt` + 接口文档
5	Xen event port	端口整数绑定到每 guest `shared_info` 的位掩码（32 位 guest 1024 位、64 位 guest 4096 位）；迁移/重连时稳定的是 remote port，本地端口重新分配，且解绑后可被重用	相关提交（save remote evtchn port, not local port）+ event channel 文档
6	QNX Hypervisor shmem	工厂页写 `size` 才触发创建（首次使用时创建 → 各 guest 启动顺序无关）；共享区可表现为 MMIO 或 PCI（默认 PCI）；直通设备同一时刻只允许一个 resident 访问	QNX 8 文档：shmem vdev、factory/control pages、configuring guests
7	Jailhouse loadable	`JAILHOUSE_MEM_LOADABLE`（0x20）区域的映射在 cell 启动时被撤销；重装走 Cell Set Loadable（错误码 `-EPERM`/`-ENOENT`/`-EINVAL`，root cell 不可设为 loadable）	jailhouse `cell-config.h` + `control.c`（`cell_start`/`cell_set_loadable`）
8	Jailhouse ivshmem	设备不维护 pending 语义：MSI-X 的 Pending Bit Array 恒返回 0，INTx 的 Interrupt Status 位从不置位；事件状态应从共享内存协议推导；one-shot 模式下中断投递会清 Interrupt Control 的 bit 0；Doorbell 只写、读未定义	`ivshmem-v2-specification.md`
9	ACRN ivshmem	dm-land 与 hv-land 可同时存在但永不互通；前缀 `dm:/`（早期 `sos:/`）与 `hv:/`；通知只在 hv-land 支持（dm-land 无 doorbell）；dm-land 下 guest 重编程 BAR2 会使共享内存不可用	ACRN ivshmem HLD 与 enable_ivshmem 指南
10	Bao 共享 identity	identity 是配置里的 `shmem_id`（IPC 的 `base` 只是本 VM 映射地址，不应据地址相等/不等推断）；IPC `size ≤ 对应 shmem 大小`；cache coloring 默认未启用、随平台可用颜色数截断、代价是丧失大页并抬高 TLB 压力	Bao README/config 结构与 cache coloring 评估材料
11	NuttX 双堆	两个具体配置项（`CONFIG_MM_MULTIHEAP` + `CONFIG_MM_KERNEL_HEAP`），`MM_KERNEL_HEAP` 在 flat 构建下默认关闭；PROTECTED 的用户 API 由 `syscall/syscall.csv` 经 `tools/mksyscalls` 自动生成；驱动 upper half 在 `drivers/`，lower half 在 `arch/` 或 `boards/`	NuttX `mm/Kconfig`、Protected Build 指南、Device Drivers 文档
12	FreeRTOS 细节	`pxHigherPriorityTaskWoken` 自 V7.3.0 起可选（可传 NULL），但取舍不同；`portYIELD_FROM_ISR` 通常是 pend（Cortex-M 走 PendSV），真正切换在中断退出后；MPU 区域大小与对齐必须是同一个 2 的幂；降权到用户模式不可回退	FreeRTOS 官方 API 参考（队列/MPU）与端口文档
13	ThreadX Modules	preamble 必在模块第一个地址；properties 位区分特权/用户模式与 MPU/共享内存，并编码编译器 ID；ARM 上非特权模块经 SVC 陷入；支持 XIP（指令在 Flash、数据在 RAM）；模块线程栈顶有线程入口信息结构需计入栈用量	eclipse-threadx/rtos-docs 的 threadx-modules 第 1/2 章
14	eCos 三层	ISR 返回 `CYG_ISR_CALL_DSR` 时调度 DSR；DSR 会被调度器锁推迟；ISR 不允许使用 DSR 级锁；DSR 可 signal 条件变量但不能 wait	eCos 参考手册：同步与驱动接口章节
15	ARINC 653 / PikeOS	COLD_START 与 WARM_START 的差别是是否需要从非易失存储器拷代码到 RAM；初始化模式（COLD/WARM）下只有主进程可调度；refresh（周期）只对采样模式的接收有意义；PikeOS 的 APEX 服务经链接在固定地址的 API table 进入，POSIX 内核把用户线程映射到每核一个 system thread，分区支持 256 优先级	ARINC 653 分区模式状态机材料、SYSGO POSIX/ARINC 653 产品文档
16	INTEGRITY	内核空间不做动态内存分配，且内核内存不用于消息/信号量等由进程请求创建的对象；启动表定义资源归属、连接静态分配且不可绕过；多核共享资源争用可使 WCET 增加 8–13 倍	Green Hills INTEGRITY / INTEGRITY-178 tuMP 产品与安全材料
17	AUTOSAR `E_OS_ACCESS`	确切条件：对象未在配置时授予访问权，或对象属于另一个不处于可访问状态的 OS-Application；trusted 与非 trusted 一视同仁（默认拒绝）；例外是检查类服务（`CheckObjectAccess` 等）	AUTOSAR OS SWS（SWS_Os_00056 / OS448 / OS509）与 RTE SWS
18	MINIX 3	消息载荷定长 56 字节，超出部分走 grants；`EPERM` = grant 无效（含"页表走查失败也报 EPERM，以免 grantee 探测 granter 地址空间"），`EFAULT` = 未映射；live update 的授权方向是内核（仅）授予新进程对旧进程地址空间的只读访问，且可回滚、旧/新实例可能同时存在；活跃 direct grants 会使更新复杂化	`minix/include/minix/ipc.h` 与 `safecopies.h`、MINIX 3 消息传递 wiki、live update 指南与相关论文
19	Genode	quota 捐赠沿 session 路径被逐级扣减（"系统还剩内存"与"该 child OOM"不矛盾）；ROM session 在生命周期内可更新（配置可动态改变）；服务名只在局部 parent 层级成立、label 可被重写	Genode 架构文档（Interfaces and Mechanisms）、Foundations 手册
20	Plan 9	union 只有单层叠加（查找返回第一个匹配，上层不存在的名字不会落到下层深树）；`bind` 的 `new` 在 bind 时求值；`/srv` 是服务注册表；9P 的 fid 是 session 内 client 侧句柄（walk 绑给 newfid，库层拒绝重用已存在 fid）	`bind(1)`、`9p(2)`/`9p(3)`、`srv(3)` 手册页与 lib9p 文档

本轮校验

node validate.mjs：OK: 122 skills validated；npm test：41 项全过
分支挂载完整性检查：re-rtos 9 / re-hypervisor 5 / re-automotive 1 个 references 文件均有 SKILL.md 入链（re-kernel 的 windows-gotchas / windows-decision-tree 由同目录 windows-kernel.md 互链，非孤儿）
未做：行为 fixture（KARL 重链接、Xen 迁移端口、MINIX live update 等需真实环境）

补充 17：跨系统误判总表 + 第三批特殊系统（2026-09-13）

来源为同源的外部整编"合并后完整版本"：前半部分是跨系统的总原则（十类高频误判、共同规律、异常处理树），后半部分是更多冷门系统。两类内容分别处理。

一、跨系统总原则 → 新的入口级控制文件

新建 re-analyze/references/cross-system-models.md（跨系统运行模型与误判总表），内容：

十类高频误判表（现象 → 不要直接推断 → 必须先排除）
共同规律 A–E：本地句柄≠全局标识、ready≠有资格运行、无内核入口≠无 I/O、无 CFG 边/syscall≠没发生、磁盘≠运行
跨系统异常处理树（函数无 caller / 地址不一致 / 驱动无内核入口 / 线程不执行 / IPC 无 syscall / 内存访问故障 / binary 存在但不运行 / runtime≠disk）
使用方式：核对手段统一为 cross-view + configuration + runtime verification

挂载：re-analyze/SKILL.md 第三步加入「跨系统误判表（判定前强制前置）」——任何要写 hook / dead code / loader bug / 恶意的时刻，先逐项排除该运行模型允许的正常机制，未排除完不写结论。

二、新增系统（22 类）的落地位置

类别	系统	落点
通用 OS 内核	HelenOS、Redox、Haiku、z/OS、IBM i、OpenVMS、Unikraft·MirageOS	`re-kernel/references/{helenos,redox,haiku,zos,ibmi,openvms,unikraft-mirageos}.md`
RTOS	µC/OS、SYS/BIOS、SAFERTOS、CMSIS-RTX5、T-Kernel、TOPPERS、OSE·OSEck、Nucleus、Deos	`re-rtos/references/{ucos-sysbios,safertos-rtx5,tkernel-toppers,ose-oseck}.md`；Deos 并入 `partitioned-rtos.md`；Nucleus 入 SKILL.md 运行模型表（内容量不足以成篇）
Hypervisor	Hyper-V·VMBus、XtratuM、LynxSecure、Quest-V	`re-hypervisor/references/{hyperv-vmbus,xtratum,lynxsecure-questv}.md`
汽车	AUTOSAR Adaptive	`re-automotive/references/autosar-adaptive.md`

rerouting.md A 表新增 13 行。

三、核验后的关键事实（写入依据）

主题	核验后的表述
HelenOS fibril	fibril 由用户态库协作调度，内核完全不知道其存在；devman 在用户态按 match id 评分匹配并启动驱动，`driver_ops` 由通用连接处理器在来连接时调用
Redox 句柄	内核把文件操作转成 SQE/CQE 消息；scheme 侧 handle 描述符与客户端 fd 不是同一个（内核在 `(进程, fd)` 与 `(进程, handle)` 间映射）；provider 初始化后常进入 null namespace（安全设计）
Haiku 两层模块	driver module（`driver_v1`，绑定节点、认领 I/O 资源）与 device module（`device_v1`，暴露 `/dev` 接口）；`B_FIND_CHILD_ON_DEMAND` 决定按需搜索；`suspend`/`resume` 从不被调用
Hyper-V GPADL	GPADL 是描述并映射客户机缓冲区的句柄；宿主对经 GPADL 共享的内存总量有上限（WS2019+ 约 1280 MB，更早约 384 MB）
Hyper-V SR-IOV	VF 数据面不经过 VMBus 与 hypervisor，而 VF 控制面仍走 VMBus 回到 PF 驱动；拆除时 NetVSC 从 VF 解绑并迁回软件合成路径
SAFERTOS ESM	ACP（限制可调 API）与 OACP（限制可访问对象）各自独立；间接对象 ID + 交叉引用表取代指针式句柄；per-task 区域大小须为 32 字节倍数、基址 32 字节对齐，每次上下文切换重新编程
CMSIS-RTX5	Safety Class 的动机：RTOS 对象经"以数字 ID 为参数、在 handler 模式执行"的系统调用访问，单靠 MPU 可被"用别的对象 ID 调 API"绕过；中断处理程序绕过 MPU 保护；ISR FIFO 溢出时系统状态已不一致，对策是增大对象尺寸
µC/OS	`OSIntEnter`/`OSIntExit` 必须成对且前者不得由任务级代码调用；只有最后一个嵌套 ISR 退出时才判断切换；Cortex-M 上切换仅触发 PendSV；直接递增计数只在"递增时中断已关闭"的架构安全
SYS/BIOS	`Swi_disable()` 会连带禁用 Task 调度器；Swi 调度器禁用期间绝不能调用阻塞 API（会不可恢复地损坏 Task 调度器状态）；Hwi 与 Swi 共用系统中断栈（默认 4096 字节）
T-Kernel	三种上下文（任务/准任务/任务独立）合法性由规范规定；设备驱动的六个处理函数以准任务部分运行、必须可重入、且不保证互斥；`tk_wai_dev` 只等待调用时刻正在处理的请求，超时后处理仍在继续
TOPPERS	四家族（ASP3/HRP3/FMP3/HRMP3）规范分开规定；HRMP3 就绪队列按保护域 + 按处理器；内核内不做动态内存管理
AUTOSAR Adaptive	Modelled Process ≠ OS 进程，不可 1:1 比较；状态是"键"、清单是"表"、进程集合是"查表结果"；EM 启动后不再自行发起状态切换
Deos	同一系统内三类调度模型并存（ARINC 653 APEX / RMS / POSIX），多核用 BMP + 缓存分区
XtratuM	Plan 0 保留给初始化、Plan 1 保留作维护；计划切换在当前计划剩余槽执行完之后；IPVI 每分区最多 8 个；固定优先级数值 0 最高
LynxSecure	官方表述为静态配置 + 固定资源分配 + 无中央管理内核 + 无共享内存 + 无集中调度；（"初始化划分的 setup code 被移除"一说未获公开资料证实，未写入）
Quest-V	每个 sandbox 一个 monitor（而非一个中央 hypervisor）；monitor 只在引导、故障恢复、建通道、初始化影子页表时介入；设备中断直接投递给 sandbox kernel；无全局时钟，跨 sandbox 时间戳不可直接比较
Unikraft	native（API 兼容，syscall 变廉价函数调用）与 binary-compatible（捕获 Linux ELF 的 syscall）两条路线；非 PIE 决定地址布局且限单应用
MirageOS	同一份源码换目标，差别只在一个被替换的平台主模块 + 目标包集合
OpenVMS	完成顺序为写 IOSB → 置事件标志 → 触发 AST；AST 不中止进行中的系统调用；进程等待时 AST 投递后原等待会被重新执行
z/OS	SRB 不能调用 SVC（除 ABEND）或 WAIT；home 地址空间在整个执行期不变，`PSAAOLD` 总指向 home；跨地址空间使用 TCB 指针是经典 S0C4-11 成因
IBM i	内存与辅存构成单一 64 位地址空间；对象按名字而非硬件地址访问
OSE / OSEck	LINX 统一核内/处理器间/板间通信，支持共享内存/DMA/RapidIO/以太网/PCI，零拷贝共享内存；（其 XIP 能力本次未获证实，已在文件中标注"不要断言"）
Nucleus	MMU（Cortex-A）/MPU（Cortex-M）子系统隔离 + 线性内存映射 + 动态 reload/restart/update 而不停机

四、本轮校验

node validate.mjs：OK: 122 skills validated；npm test：41 项全过
分支入链检查：re-kernel 22 / re-rtos 13 / re-hypervisor 8 / re-automotive 2 个分支文件均有 SKILL.md 入链（windows-gotchas/windows-decision-tree 由同目录互链）
两处未证实内容已明确标注而非照写：OSE 的 XIP、LynxSecure 的"setup code 被移除"
未做：行为 fixture（fibril 调度、SR-IOV 切换、AST 投递等需真实环境）

补充 18：14 个分支的深度展开 + Nucleus 新增 + 入口速查表（2026-09-13）

来源为同源外部整编的第三份材料：对 14 个系统的机制级展开（心智模型 → 特殊情况 → 下一步查什么）与一张汇总速查表。处理方式：逐条核验后并入对应分支，不新增技能（Nucleus 内容量已足以成篇，新增 1 个分支文件）。

一、落地位置

动作	对象
新增分支	`re-rtos/references/nucleus.md`（线性映射 + entitlement / 固定块内存池 / 动态模块生命周期）
深度展开	`autosar-adaptive`（清单三件套 / 服务发现 / PHM / UCM / Persistency）、`xen`（通知抑制 / 睡前再检查 / FIFO 事件 ABI / 迁移身份）、`hyperv-vmbus`（GPADL 删除阻塞 / packet 生命周期 / 外部数据待决）、`partitioned-rtos`（Deos 两级调度 / slack / SafeMC / 排错顺序）、`ucos-sysbios`（调度器锁嵌套 / 信号量与互斥量 / 定时器任务上下文 / PendAbort）、`safertos-rtx5`（权限模型 / ESM 拒绝语义）、`xtratum`（两种切换时机 / 采样刷新 / 掩蔽扩展中断）、`acrn`（MSI-X trap 路径三态 / 设备归属迁移）、`lynxsecure-questv`（LynxSecure 官方表述）、`unikraft-mirageos`（启动表 / shim 三层符号 / Lwt / 目标指纹）
入口级扩充	`re-analyze/references/cross-system-models.md` 新增异常速查表（约 40 行，按现象直查）与版本/代际提示节

rerouting.md A 表新增 7 行。

二、本轮核验后的关键事实

主题	核验后的表述
AUTOSAR PHM	以进程粒度监督（不是任务级）；三类监督 Alive（周期内检查点数量）/ Deadline（起止检查点耗时区间）/ Logical（检查点顺序符合监督图，与时间无关）；本地状态含 EXPIRED（终态）；监督模式 = `<machine state, function group state>`；恢复动作含"请求看门狗驱动复位"；PHM 自身不启停进程；PHM 还监督 EM 守护进程存活，其失败升级为看门狗/机器复位
AUTOSAR Persistency	`keepExisting` / `overwrite` / `delete` 三策略 + 清单约束（前两者要求存在初始值，`delete` 要求不存在）；版本比较：清单版本更低时回滚（存在有效备份时）
AUTOSAR 服务发现	`FindService` 允许返回空；可用性变化时重新回调且实现负责串行化同一 handler；handle 可指向远端 service instance
Xen 通知抑制	推送宏只有越过对端设置的 `req_event` 阈值时才通知；消费侧"无工作 → 设阈值 → 全屏障 → 再查"是防丢唤醒的协议核心（并附已知的索引回绕副作用与 NAPI 场景副作用）
Xen FIFO 事件 ABI	优先级 0 最高 / 15 最低（默认 7），每 VCPU 16 个队列；事件字含 PENDING / MASKED / LINKED / BUSY；unmask 在 PENDING 时必须投递通知；存在 2-level 与 FIFO 两套 ABI，记账布局不同；初始化控制块不会重投当前 pending 事件（会丢），应在绑定事件之前完成
Hyper-V GPADL	删除在 GPADL 仍被 server 映射时会阻塞直到解除；从 buffer 创建时该 buffer 被 probe 并锁定直到 GPADL 销毁
Hyper-V packet 生命周期	完成调用可立即也可稍后发起，直到它被调用才清理映射/释放缓冲/（按需）发送完成 packet——回调返回不是释放边界
Hyper-V 外部数据	需要分页时返回 STATUS_PENDING，必须从回调返回，之后可能在不同 IRQL 再次回调；返回的 MDL 已锁定、不带任何虚拟地址、在完成调用时失效且由内核库释放
Nucleus	线性内存映射 + 受保护区域 + entitlement（Cortex-A 用 MMU、Cortex-M 用 MPU）；`NU_PARTITION_POOL` 是固定大小块分配器（与"空间隔离域"同名的术语坑）；分配是 O(1)、不可能碎片化，唯一失败模式是池耗尽；`NU_SUSPEND` 下池空则任务挂起；非任务线程只能用 `NU_NO_SUSPEND`
µC/OS 定时器	回调在内部定时器任务上下文中执行（不是中断、不是创建者任务）、使用定时器任务的栈、且绝不能阻塞/等待（回调串行执行，阻塞会卡住整个定时器子系统）
µC/OS PendAbort	中止等待是让任务就绪而非正常投递；只能由任务调用；被唤醒任务带"等待被中止"的错误码返回
Deos SafeMC	两级调度：Level 1 是跨核对齐的执行窗口，Level 2 为每个核/window 指派 scheduler（ARINC 653 / Deos RMA / POSIX）；Slack 通过滑动时间窗实现（窗口可压缩/扩张/滑动）；cache partitioning 为软件实现、做到应用/分区级、免去分区切换的 cache flush，与内存池互补
XtratuM	普通 plan 切换要等当前计划槽跑完，而健康监控切维护计划可立即发生（终止当前槽）；同 MAF 内多次请求可最后一次生效；采样端口刷新周期决定新鲜度、旧数据可标无效；扩展中断在分区启动时默认掩蔽
ACRN MSI-X	三类 VM 的 trap 路径不同（Service VM → hypervisor handler；post-launched → Device Model handler 再涉及 hypervisor；pre-launched → hypervisor handler）；设备所有权在 Service VM 与 post-launched VM 之间双向迁移
Unikraft 启动表	三类表（早期 / 构造 / 初始化）+ 七级顺序（构造→早期→平台→库→rootfs→系统→晚期）、每级 10 个优先级、条目在按名字排序的专用链接段中
MirageOS Lwt	协作式轻量线程 + 事件循环；不让出会饿死整个事件循环（不需要互斥量或内核死锁）；后台异常交给 async 异常处理器，行为取决于其配置

三、未证实 / 未直接命中的内容（已按此处理）

内容	处理
LynxSecure"用于初始配置的特权 setup code 随后被丢弃"	未证实——改为写入官方明确表述的部分（不可变 boot 分区、内核功能仅限分区/数据流/状态调解、I/O 全导出到 guest、无管理控制台登录、无动态系统修改），并标注该机制未被证实
TI SYS/BIOS 的"中断禁用期间多次发生、恢复后只服务一次"	未命中上游——未写入
Deos 的外部时钟同步	未直接命中上游——以"候选解释之一，需在具体型号文档确认"的措辞写入
Hyper-V `GPADL_READ_ONLY` 非安全措施	未命中——未写入（只写了已证实的删除阻塞与 buffer 锁定语义）

四、版本/代际提示（已写入入口文件）

某平台规范公开版本已推进（如 R25-11）而多数细节来自上一完整公开版（R24-11）——核心模型适用，条目前先做版本指纹
某 hypervisor 最完整公开手册属于特定代际（如 XM-4）——不要无条件套到其他代际
同一系统的安全认证产品线与基础产品线不是同一份二进制/内核，可选机制不同

五、本轮校验

node validate.mjs：OK: 122 skills validated；npm test：41 项全过
re-rtos 分支数 13 → 14，re-analyze/references/cross-system-models.md 新增速查表与版本提示节

补充 19：HIC 入库与"信任边界"通用规则（2026-09-13）

一、落地

新增分支：re-kernel/references/hic.md —— capability + 物理沙箱 + 多版本驱动系统（re-kernel 分支数 22 → 23）
入口级规则：re-analyze/references/cross-system-models.md 新增「共同规律 E：信任边界不能从指令形态推导」（四条推论表：直接 call / 直接 MMIO / 同特权级 / 整数句柄各自可能是什么），并写明配套要求（内存取证区分 VA/PA/frame/capability/owner domain/mapped domain；共享内存指针带域语义）
挂载：re-kernel SKILL.md（平台差异表行 + 4 条决策表行 + 分支指针 + description 触发词）、rerouting.md A 表 1 行

二、触发条件设计（用户明确要求"不能误触"）

hic.md 内专设「触发条件（命中 / 不要命中）」一节：

命中要求组合证据：同特权级 + MMU 隔离的模型、模块自描述元数据、入口页 IPC 形态、两种 capability 记账模型并存、旧新实例并行的滚动更新
不命中逐条列出该走哪里的对照表：仅"驱动在用户态"→ 用户态驱动各分支；仅"capability/handle 本地标识"→ seL4/Zircon/Genode 等；仅"共享内存+通知"→ Xen/VMBus；仅"有滚动更新"→ MINIX/NetBSD；仅"看到直接 MMIO"→ 不足以说明任何事
判据写明：本分支的标志是那一组组合，而不是其中任何单独一条

三、命名决策（记录在案）

初版按本库红线 2（禁止具体到某个项目/产品，暗示也不行）做了机制类脱敏——起因是检索发现公开 OSDev 线程的作者 handle 与本仓库 git 身份一致，点名会同时构成"项目名 + 作者身份"的双重指向。用户明确要求点名（该项目为公开项目），遂按用户决定改为具体系统条目。

先例：此类"是否点名"的判断以用户对自身项目公开性的判断为准；默认仍按红线 2 脱敏，用户明确要求时点名。

四、核验

HIC 的公开信息（OSDev 线程：物理沙箱、1:1 连续物理映射、同特权级直接调用快路径、capability 管控与未授权记录、Privileged-1 官方模块审计/签名模型、大页与页表层数、KPTI-like 跨边界隔离）与用户提供的设计描述一致，分支内容以用户提供的设计文档为准（本库对第一方设计文档无需外部转述）
跨系统对照表的 11 条来源（Fuchsia DFv2 / crash recovery / bind metadata、seL4-CAmkES、Xen 前后端与 grant table、Genode、QNX、Barrelfish、MINIX live update 与协议静止）中，除 Barrelfish 外均已在本库其他分支有独立记录；Barrelfish 仅作为对照经验写入，未单独立分支
链接修复：初版 [[xen]] / [[hyperv-vmbus]] 跨技能裸引用被校验拦下（应为 [[re-hypervisor/xen]] 形式），已修正

五、本轮校验

node validate.mjs：OK: 122 skills validated；npm test：41 项全过
re-kernel 分支 23，全部有 SKILL.md 入链

补充 20：8 个分支的"操作层"补深 + LynxSecure/Quest-V 拆分（2026-09-13）

来源为同源外部整编的深度审计：指出部分分支"概念正确且稀有，但宽度只有一根很深的井"，并逐一列出该补的操作层内容。本轮按其给出的优先级处理。

一、评估维度（记入审查方法）

该审计提出一个二维评估，值得作为后续审查的固定视角：

深度（某一机制的资料质量）  ×  平台覆盖度（拿一个真实样本进来能走多远）

据此的定位：OpenVMS / z/OS = A+ 深度、C 覆盖度（深的是某个异常机制，不是整个平台）；eCos = 深度集中在一个切面；Haiku / Redox = 某一层很深、换一层突然变浅；Nucleus 已超出预期（不再列最高优先级）。

二、落地

动作	对象
拆分	`lynxsecure-questv.md` → `lynxsecure.md` + `questv.md`（两者各拆一份）
操作层补深	`ibmi`、`zos`、`openvms`、`redox`、`haiku`、`ecos`、`ose-oseck`
挂载同步	`re-kernel` / `re-rtos` / `re-hypervisor` SKILL.md 的分支指针与决策表、`rerouting.md` 新增 6 行、`partitioned-rtos.md` 的同族链接改指两个新分支

三、补进去的操作层要点

分支	新增的操作层内容
IBM i	层次边界（MI / TIMI / SLIC / PASE，PASE 绕过 TIMI）；程序模型（OPM/EPM/ILE；`MOD` 不可执行且绑定后常被丢弃、`PGM` 是 bind-by-copy、`SRVPGM` 是 bind-by-reference 且激活时解析签名）；activation group（PSSA/PASA/堆 + 覆盖作用域 + 存储模型相容约束）；两套指针（系统指针 16 字节 tagged 指向对象 / 空间指针指向偏移）与两种存储模型（single-level vs teraspace 的 job 边界、mmap 支持、跨 job 共享方式）；space addressing violation 的异常数据（对象系统指针 + 空间偏移 + 空间类别）与 tagged 指针的 fork/共享内存限制；产物识别*（DMPOBJ / DBGVIEW 编译清单 / 压缩态 / 时间戳必然差异）
z/OS	可执行材料（load module / program object / PDS vs PDSE）；AMODE/RMODE（程序对象与运行中程序各有属性）；XPLINK 与非 XPLINK 的栈行为相反（栈方向、GPR4 带 0x800 偏置、BACKCHAIN vs 展开信息、参数传递方式、转换仅限 31 位）；SVC/PC 表；dump 类型与 IPCS（XPLINK 下控制块更少 → 依赖 LEDATA 视图）；EBCDIC 与记录模型
OpenVMS	第二条控制流：条件处理（处理器的继续/重投递/展开三种去向、第二次异常跳过已搜索帧、经异常向量建立的处理器每次都被调用）；建立处理器的两种方式与语言差异（栈帧字段 vs 过程描述符/展开信息块；I64 运行时没有该入口；C 必须用运行时专有接口，否则与 setjmp/longjmp 同用是未定义行为）；镜像启动时建立的三个默认处理器（traceback / catchall / last-chance）；镜像激活与共享镜像（逻辑名重定向机制、默认目录、特权/仅执行镜像只认可信逻辑名且被引用镜像必须安装）；节（全局/私有/消息）与调用标准；RMS 文件规格解析规则（已知镜像查找忽略版本号）
Redox	启动链（引导器 → 极小 ELF 加载器 bootstrap → initfs 两级启动；内核参数携带硬件描述来源：ACPI vs 设备树）；syscall ABI 刻意不稳定，稳定层在用户态运行时；relibc 与辅助向量（静态/动态可从 auxv 判断、线程用 fd 承载、可重启语义与 errno 映射）；scheme 的两种匹配方式（路径前缀 vs 记住打开时的 scheme）与调度分类；驱动两遍构建（initfs 体积优化 + panic-abort vs 主系统标准 release）
Haiku	系统侧对象模型（team/thread/area/port/semaphore + 信号量的扩展标志：可中断、释放全部、仅在等待时递减）；KDL（栈回溯/线程/内存/切换 CPU/系统日志）与调试 API 细节（消息头含线程与 team ID、team 调试标志含 image 事件与 syscall 前追踪、64 位下参数缓冲区被扩大）；BeOS 兼容是单向的且调试接口与文件系统 API 属于不兼容部分；用户态服务边界
eCos	CDL 配置系统（通道/调试/构建目标等选项决定编入项；用 ROM 监视器时通道选项通常失效）；HAL 与向量表（位置由内存布局决定、默认异常向量、ROM 监视器加载的应用异常默认进监视器）；虚拟向量（静态地址表、服务清单、保留字节与间接层代价）；启动顺序（复位入口 → 平台设置 → HAL 启动 → 构造函数 → 主启动）；构造函数被向量表覆盖的真实坑；调试桩与 GDB 去向
OSE / OSEck	信号号不唯一（多个端口可共享同一信号号 → 需次级 id 与解析函数）；先注册后发送否则丢、一次事件可能关联多个信号要取空；域/块/段/池的所有权（只能在自己的池里分配、跨域发送会被拷贝）；进程类型与静态/动态类别；监督（链路级 + 平台级、DSP 监督信号、看门狗）与错误处理器；错误检测的能力边界（结尾标记能检出越界写，检不出不改标记的指针访问/泄漏/未初始化读取）；系统信息接口（信号空间、保存的寄存器与栈）；OSE 与 OSEck 的差异与异构边界
LynxSecure	明确区分【官方表述】与【该恢复什么】：官方表述（不可变 boot 分区、内核功能仅限资源分区/数据流控制/状态变更调解、I/O 全导出到 guest、无管理登录、无动态系统修改、hypervisor 自身也不能访问 guest 资源）用于判断"缺什么算正常"；操作层按方法论给（配置优先于代码、启动阶段是唯一能看到配置生效的窗口、用三项职责反查内核边界、跨分区找受控通道而非共享页、用官方约束验证 DMA 隔离、"8 MB 里哪一段是核心"的定位法）
Quest-V	monitor 的四个介入时机、EPT 用于内存隔离而非 CPU 虚拟化、中断直接投递与早期解复用、显式消息 + 共享内存通道（缓存行大小）+ IPI、故障路径（EPT violation → VM-exit；必要时强制触发陷入；抢占超时把检测逻辑放进 monitor）、本地/远程在线恢复（换实现靠改 EPT 激活）、以及"哪一段是 monitor"的四条判据

四、未获证实 / 未写入

LynxSecure 的配置 artifact、启动阶段细节、partition 描述结构：公开资料缺失（检索无结果）。未编造；改用"该恢复什么"的方法论表述，并在文件开头明确标注【官方表述】/【该恢复什么】两类内容的分野
OSE 的 XIP：仍未证实，文件中保留"不要断言"的措辞
OSE 的 attach 语义细节、signal pool 监督的内部设计：本次检索只确认了 hunt/attach 属于信号 API 与池的所有权规则，更细的内部机制未获证实，未写入

五、本轮校验

node validate.mjs：OK: 122 skills validated；npm test：41 项全过
re-hypervisor 分支 8 → 9（拆分后），re-rtos 14、re-kernel 23；全部有 SKILL.md 入链
措辞检查：新写内容经"最 X"筛查并改写（questv / ose-oseck 各一处）

补充 21：系统识别指纹表（2026-09-13）

一、缺口与落地

缺口：库里有"运行模型 + 误判表 + 异常速查表"，但**没有"怎么认出这是哪个系统"**这一层——rerouting A 表要求你已经知道目标是什么。

落地：新增入口级控制文件 re-analyze/references/system-fingerprints.md（199 行），覆盖本库全部 55 个系统（脚本自检：按显示名逐个核，55/55 命中）。

二、结构：五层流程

① 载体与格式（PE / ELF 是否 ET_REL / Mach-O / 无容器镜像 / 配置 / 转储 / 流量）
② 超家族收敛（几条问题归到某一族）
③ 家族内指认（9 张表：UNIX 与 Windows 系内核驱动 / capability 与用户态驱动型 /
   RTOS / 分区与安全 RTOS / Hypervisor / 固件引导 / 主机大型机 / 车载 / unikernel）
④ 易混淆对（15 组专项判据）
⑤ 负判据（"看到 X 就不是 Y"）

判据强度分级：[强]（唯一判据，可单独定案）与 [弱]（需组合）——文件里明确写了"弱判据单独使用会把无关系统卷进来"，并给出例子（"有 Kconfig"无法区分 Zephyr 与 NuttX）。

三、本轮新核验的事实地基

事实	核验结果
ELF note 段标识	NetBSD：`.note.netbsd.ident`，note 名 `"NetBSD"`，`NT_NETBSD_IDENT` = 1；OpenBSD：`.note.openbsd.ident`，note 名 `"OpenBSD"`，`NT_OPENBSD_IDENT` = 1；FreeBSD：`.note.ABI-tag`，note 名 `"FreeBSD"`，`NT_FREEBSD_ABI_TAG` = 1（GNU ABI 标签里另有 FREEBSD=3、NETBSD=4、SOLARIS=2、LINUX=0、HURD=1）
`EI_OSABI` 现行取值	NONE=0、HPUX=1、NETBSD=2、LINUX=3、HURD=4、86OPEN=5、SOLARIS=6、AIX=7、IRIX=8、FREEBSD=9、TRU64=10、MODESTO=11、OPENBSD=12、OPENVMS=13、NSK=14、ARM=97、STANDALONE=255。（注意：2000 年曾有 FREEBSD=4/NETBSD=5/OPENBSD=6 的提案，与现行值不同；本表按现行值写）
OpenBSD note 的强制程度	讨论中一度写作"通常包含"后改为移除该措辞；无 note 的二进制会执行失败，但最终未写成"必须"——本表据此只把它当强判据之一而非唯一依据

四、处理原则（重要）

判据全部取自本库已核验的分支（各分支文末"工具与验证"节），本文件不引入新断言；文中已写明这一来源约定
两处检索未命中（hypervisor 配置产物特征、RTOS 识别串）未改用外部猜测，而是改用库内已核验内容（如 ACRN 的 IVSHMEM_ENABLED、Jailhouse 的 .cell 与控制台串、Bao 的 struct config、RTOS 的对象头魔数与 API 前缀）
判据薄的两个系统（LynxSecure / Quest-V）在表中明确标注"不要靠字符串定案"，改为结构性与行为判据
新增了维护约定：新增系统分支时须同步往本表加一行（载体/强判据/结构线索三列必填）

五、挂载

位置	内容
`re-analyze/SKILL.md` 第二步	"先认目标"段（含"判不出不要硬判"）
`triage.md` 前置	认系统先于查表；家族已定系统未定时按家族级分支推进
`cross-system-models.md`	互为前后置：先定身份、再查该身份允许哪些"正常异常"
`CLAUDE.md` 控制文件表	新增两行（fingerprints / cross-system-models）
5 个技能	re-kernel / re-rtos / re-hypervisor / re-uefi / re-automotive 的「何时使用」各加一条前置回链

六、本轮校验

node validate.mjs：OK: 122 skills validated；npm test：41 项全过
覆盖度自检：按 55 个系统显示名逐个核对，55/55 命中（脚本核对方式记于本节，后续加系统时可复用）

补充 22：对 d4a5348 的抽样审查——2 处事实 + 4 处元规则（2026-09-13）

来源为同源外部审查（针对当前 HEAD 抽样）。审查自身给出的定位值得记下："不是内容事实性质量崩了，更像是扩张得很快以后，少量表述过强 + 元规则开始比具体知识更容易制造误判。" 本轮 6 条全部处理。

一、事实性修正（2 条）

#	位置	原文	问题	修正	核验
1	`analysis-contract.md` constants 步	"有语义的 magic number（如 ELF 头 0x202）"	ELF 魔数是 `\x7fELF`，`0x202` 与 ELF 无关	改为 `ELF 魔数 \x7fELF（小端读作 0x7f454c46）`	定义级事实
2	`system-fingerprints.md` §二	"`.note.ABI-tag`(FreeBSD)"	把 note type 与 section name 混了	改为 `.note.tag`（note 名 `"FreeBSD"`、`NT_FREEBSD_ABI_TAG`=1），并注明早年版本曾用 `.note.ABI-tag`，识别时应两者都看	FreeBSD `lib/csu/common/crtbrand.S`：`.section .note.tag,"aG",%note,.freebsd.noteG,comdat`；note 名 `NOTE_FREEBSD_VENDOR`；描述符为 `__FreeBSD_version`。上一次搜索之所以出错：官方头文件的注释写的是 "Values for FreeBSD .note.ABI-tag notes"，而实际生成的 section 是 `.note.tag`——注释与实现不一致

二、元规则修正（4 条）

#	位置	问题	修正
3	`system-fingerprints.md` 判据标注	[强] 混了两个独立概念——"对某系统高度特异"与"这个东西通常一定能观察到"	拆成二维：特异度（`独有`/`高`/`弱`）× 可观测性（`稳定`/`视构建`/`仅运行期`），标注形如 `独有·稳定`；并写明典型误用：把 `独有·视构建` 当"一定能看到"，于是对 strip 过的产物得出"不是该系统"的错误结论（举 Haiku `driver_v1`/`device_v1` 为例）。全文 62 处标注完成
4	`system-fingerprints.md` §二	"ELF + ET_REL → [强] Linux 内核模块"过强——ET_REL 只说明"可重定位 ELF"，后半句"或同类可重定位模块"已自认这一点	降为 [弱·稳定]：ET_REL 仅指示"可重定位 ELF"；需再命中 `.modinfo` / `__this_module` / `vermagic` 才升到 Linux 可加载内核模块
5	`system-fingerprints.md` 缺证据归属维度	固件里可能同时有 Linux rootfs、MCU blob、guest 镜像、编译期 sysroot——*找到 `procnto`/ARXML/`seL4_`/FreeRTOS 特征串中的任何一个，都不能回答"主体是哪个系统"**。指纹表越丰富，这类假命中越多	新增第 ⓪ 层 `evidence_scope`（`container` / `executable` / `embedded payload` / `guest` / `dependency` / `toolchain artifact` / `documentation`），规则：先判证据属于谁，再判它是哪个系统；跨 scope 命中只记"存在性"，不作主体身份依据。同步改流程图（五层 → ⓪+四层）与入口 SKILL.md 的"先认目标"段
6	`analysis-contract.md` 两条规则过硬	① "每目标不超过 8 次工具调用"当全局硬上限——大型固件/内核/协议/混淆程序会被强行截断；② "五步严格顺序、不可跳步、禁止先反编译再倒推"与真实 RE 的迭代性质冲突（类型恢复常常要先粗反编译拿 field-use / call-shape / switch / allocation size 才有线索）	① 改软预算：8 次为一档，到档必须重新评估（继续 / 换路 / 收束三选一，结论记录在案），评估通过进入下一档；② 改收敛循环：`初次反编译 → 四类信息交替恢复 → 重新反编译 → 定点`，并把"decompilation"从终步改为收敛判据（四条同时满足才算定点：类型全解析 / 常量有名 / 虚调用目标已识别 / 签名带参数名）。保留的约束是"禁止只反编译不复核就交付"

三、审查确认无问题的两处（本轮无需改动）

Haiku driver_v1/device_v1 后缀：得到官方文档支持（本库此条早已如此写）
ThreadX TX_THREAD_ID = 0x54485244('THRD')：与当前 upstream 一致（本库此前已纠正过旧资料的 TIMR/EVEN 写法）

四、本轮校验

node validate.mjs：OK: 122 skills validated；npm test：41 项全过
二维标注落地自检：独有· / 高· / 弱· 共 62 处

补充 23：对 22a76dc 的抽样审查——网络隔离 / 工具生命周期 / ABI（2026-09-13）

来源为同源外部审查（第二批，抽查 re-netcap / re-proto-rev / re-android-native / re-angr / re-ai-model / re-malware / re-mem-forensics + validate.mjs 与测试）。10 条全部处理，其中 1 条核验后与审查意见相反。

一、P0：两处操作级 bug

#	位置	问题	修正
1	`re-netcap` 步骤 5 与坑表	沙箱断网验证不成立——把"断网 / fake DNS / INetSim"并列，并用 `ping 8.8.8.8` 不通作为"无真实外联"的验证。ICMP 被阻断 ≠ TCP/UDP 被阻断；fake DNS 挡不住硬编码 IP 的 C2；纯断网又抓不到 C2	改为默认拒绝出站（default-deny egress）+ 白名单到分析基础设施，并给出 iptables 落地示例；验证改为三条独立验证（TCP / UDP / 硬编码 IP 直连），明确写"`ping 不通`不构成任何一条"。坑表同步改写
1b	`re-sandbox` 步骤 1 与 `re-malware`	"VM 快照 > 容器 > firejail"的排序容易被当作"容器是一般恶意样本的后备隔离层"，但容器与 firejail 都共享宿主内核	在层级说明处明确：中低两档只适用于已知低风险样本；样本存在内核攻击面（提权/内核漏洞/驱动载荷）时这两档不构成隔离边界；默认承载未知高威胁样本的是 VM 快照
2	`re-netcap` 步骤 5	mitmproxy 透明代理规则只重定向了 80——上下文在处理 HTTPS/TLS，但 PREROUTING/OUTPUT 两条都是 `--dport 80`，目标访问 443 时根本不会进入 mitmproxy	改为 `-m multiport --dports 80,443`，并注明"只写 80 是最常见的失误"；补充非标准 TLS 端口（8443 等）需按实际观测补齐

二、P1：工具操作层（Volatility 3 三连）

#	问题	核验与修正
5	符号获取机制混了 Windows 与 Linux/macOS	核验：Windows 按 PDB GUID/age 在 `symbols/windows/` 找 ISF，找不到时自动从 Microsoft 符号服务器下载 PDB 并转换；Linux/macOS 靠 kernel banner 精确匹配（banner 编码在 ISF 内、文件名不重要），获取途径是社区预构建包或自行构建（`dwarf2json` 需调试内核 / `btf2json` 用 `vmlinuz` BTF + `System.map`）。原文"首次运行从 volatilityfoundation.org 下载、Linux 也是对应内核版本"两侧都错，已按上述改写并补"先跑 `banners` 拿 banner"的工作流
6	插件命名漂移	核验：`windows.hashdump` / `lsadump` / `cachedump` *确已迁到 `windows.registry.`，旧名为弃用别名（v2.27 标记 2026-09-25 移除——距今 12 天），已改命令与坑表。但审查关于 malfind 的部分与核验相反：malfind 的源码目录在 `windows/malware/` 下，命令行调用名仍是 `windows.malfind`（`malware` 不进入调用名）——照"迁到 windows.malware.malfind"改会引入新错误**，故未改；并把这条区别写进了坑表（"源码目录变了 ≠ 调用名变了"）
7	凭据来源统一写成"LSASS 内存"不准确	核验：三个插件都是 registry-hive 派生——hashdump ← SAM + SYSTEM（boot key）、lsadump/cachedump ← SECURITY（cachedump 用 NL$KM 解 MS-CACHEv2）。已改为分开记录：registry-hive-derived vs LSASS process-memory 两条路径，并写明取证报告里 provenance 写错后果较重

三、P1：ABI 两处

#	位置	问题	修正
3	`re-android-native`	JNI 字符串语义写反（`GetStringUTFChars` 写成"C 串→UTF-8"）+ `JNINativeMethod` 三个字段被硬编码成各 8 字节	语义改为 jstring → Modified UTF-8 / Modified UTF-8 → Java String，并补"是 Modified UTF-8 不是标准 UTF-8"（空字符 `0xC0 0x80`、增补字符代理对上不同）；字段宽度改为"各为一个指针：64 位 8 字节、32 位（armeabi-v7a/x86）4 字节，数组步长 12 字节"。两处出现处均已改
4	`re-angr`	recv/read hook 的 ABI 错误——写成"或 hook 返回符号指针"，而 POSIX `recv`/`read` 的返回值是 ssize_t 字节数	改为：按调用约定取 buf 参数（x86-64 SysV：RSI=buf、RDX=len）→ 写符号字节到该地址 → 返回符号长度；并写明照原文实现会让 `if (recv(...) > 0)` 一类控制流全部建歪

四、P2：两处内容错误

#	位置	问题	修正
8	`re-ai-model`	"流式提取"名不副实——`to_array()` 对 external data 张量会完整 materialize，且 `base_dir` 默认空字符串（权重不在 CWD 时直接失败）	标题改为"逐 tensor 惰性落地"，代码里加 `base_dir="."` 与 `del arr`，并注明不是流式、峰值取决于最大张量；坑表同步
9	`re-proto-rev`	Ethernet FCS 诊断错——"帧短 14 字节"归因到 FCS，但 FCS 是 4 字节、14 字节是典型以太网头部长度	重写为"先量实际少了几字节"：缺 4 字节查 FCS 剥离，缺 14 字节查以太网头/注入层；并删去"Scapy 不保留尾部"这类笼统断言（帧抽象随版本与配置而异）

五、结构性结论（写入 TODO）

审查指出：41 项测试与 validate.mjs 主要校验 schema 与路由图，不执行 Markdown 里的 shell/Python 示例，也不验证第三方 API/CLI 是否仍存在——所以"122 skills validated / 41 tests pass"的准确含义是结构与路由图健康，而非"技能内容可执行"。本轮 Volatility 的过期命令即典型漏网类型。

趋势判断（记录）：领域知识已比工具操作层稳定，新的主要缺陷来源转为「命令/API 生命周期」与「示例代码没真正 smoke-test」——与此前以事实性错误为主不同。

已在 TODO.md 新增「工具 CLI/API 生命周期审查」条目，含最小方案（第三方命令/API 清单 + 版本漂移检查 + 示例可执行性 + 与增量审查机制合并设计）。

六、本轮校验

node validate.mjs：OK: 122 skills validated；npm test：41 项全过
涉及文件 7 个：re-netcap / re-sandbox / re-mem-forensics / re-android-native / re-angr / re-ai-model / re-proto-rev

补充 24：工具 CLI/API 生命周期机制落地（2026-09-13）

上一节把"命令/API 生命周期"定为新的主要缺陷来源，本节实现其最小骨架。

一、交付物

文件	作用
`docs/audit/tool-register.json`	登记表（140 项）：`name` / `kind` / `where`（引用它的技能） / `last_verified` / `source` + 一份 `ignore` 名单
`lib/tool-register.mjs`	抽取（`extractCommands`）、扫描（`collectFromSkills`）、比对与时效（`checkRegister`）、探测（`smokeProbe`）
`bin/toollife.mjs`	CLI：`check` / `candidates` / `stale` / `smoke`（与 `bin/capindex.mjs` 同构：lib 放逻辑、bin 做壳）
`tests/toollife.test.mjs`	10 项：抽取器各类边界 + 死条目/候选/时效/非法日期 + 仓库自身一致性

package.json 增加 npm run toollife；npm test 通过 tests/*.test.mjs 自动纳入一致性检查。

二、设计取舍（记录判断依据）

抽取只认显式标注为 shell 的代码块（sh / bash / console / shell）。先按"所有代码块"试过一版：去重候选 717 个，其中大量是 python 体与结构体字段名（print / import / onLoad / simgr.*）；限定标注后降到 159，治理成本量级下降
不做"每个命令都必须登记"的硬门——那会把 ls/cat/grep 一类基础工具也拖进来。登记表只管有生命周期风险的第三方工具，基础工具在 BASE_UTILS 里直接过滤
last_verified: null 是一等状态：表示"已登记、尚未核验当前 CLI/API 形态"。当前 140 项里只有 1 项已核验（vol，本会话核过插件路径与符号机制），其余 139 项是明确的待核验积压——这不是缺陷，而是把真实状态显性化；check 三档统计（已核验 / 超期 / 待核验积压）
超期与积压分开：stale 只统计已核验且超过 180 天的项（避免把"从未核验"混进"该复核了"）；pending 单独列，供下一轮审查波分批消化
smoke 不进 CI：探测本机是否装某工具，在 CI 机器上必然大量缺失，只作本地报告
死条目即失败：登记为"在用"但技能里已找不到该命令 → check 报错。这是唯一做成硬门的检查——它无歧义、不会因正常编辑误报

三、防漂移闭环

新增技能引用新第三方工具
  → check 把该命令列为"未登记候选"
  → 仓库自身一致性测试失败（npm test 红）
  → 登记（或放入 ignore 并写明理由）
  → 绿

同理，删掉某工具的全部引用而不清理登记表也会红（死条目）。

四、未做（保留在 TODO）

示例可执行性：把技能里的 shell/Python 示例抽成最小可跑片段。需要权衡 fixture 与网络/工具依赖，单独评估
逐项回填 last_verified：按 stale 输出分批核验。当前积压 139 项

五、本轮校验

npm test：OK: 122 skills validated + 51 项测试全过（原 41 + 新增 10）
npm run toollife：登记 140 项｜已核验 1｜超期 0｜待核验积压 139，无错误、无未登记候选

补充 25：示例可执行性 + 增量审查机制 + 登记表风险分层（2026-09-13）

上一节遗留的三项，本节一并落地。

一、示例可执行性（`lib/skill-examples.mjs` + `bin/examplecheck.mjs`）

定位：validate.mjs 校验结构、不执行示例；本检查补"示例至少语法正确"这一层——抓不到"命令过期"，但能抓到"照抄会立刻报错"。只做语法检查：不联网、不装依赖、不运行程序。

首轮测量与规范化（每一步都是必要的，否则误报淹没真错）：

阶段	python 块	shell 块	说明
原始 `compile` / `bash -n`	51 错	26 错	绝大多数是假阳：块缩进在列表项下、`(gdb)` 提示符行、`<pid>` 被 shell 当重定向
去缩进 + 提示符规范化	3 错	22 错	python 的 3 处是真错
占位符中和 + 会话记录识别 + heredoc 拆分	0	0	剩余 22 处全部是 `<占位符>`

抓到的真问题（已修）：

3 处 python 语法错：simgr.explore(find=0x4011xx, ...) —— 0x4011xx 不是合法 Python（invalid hexadecimal literal），照抄即报错。改为合法地址 + # 示意地址：按目标实际入口/分支替换
2 处语言标错：re-fp-runtime / re-nim 把 Haskell / Nim 源码与构建命令塞在同一个 ```sh 块里——已拆成 haskell / nim 代码块 + sh 命令块

两个刻意的设计决定：

调试器会话块不按 shell 检查：含 (gdb)/(jdb) 提示符，或"交互式工具启动行 + > 命令"的块是会话记录，行内容是喂给调试器的，不是 shell 语句——丢弃提示符行后再检查，避免把 jdb 转录当 shell 脚本报错
sh 块里嵌的 python heredoc 单独按 python 检查（python3 - <<'PY' 在技能里很常见）——否则这些代码完全在检查视野之外

CI 取舍：需要 python3 / bash，缺失时跳过而非失败；接入 npm test（有解释器时生效），成本约 8 秒（391 块，每块一次解释器调用）。

二、增量审查机制（`lib/review-state.mjs` + `bin/auditstate.mjs`）

docs/audit/review-state.json   122 技能 × { hash, last_reviewed, note }
node bin/auditstate.mjs status → changed / unreviewed / ok 三态
node bin/auditstate.mjs update <技能...> → 回填当前 hash + 日期

审查波的工作流变为：status 列出"内容在复核之后又变了"的技能 = 工作集 → 只审这些 → update 回填。成本从 O(技能总数) 降到 O(变更数)。

hash 口径：技能目录下全部 .md/.sh 按相对路径排序后逐个喂入（路径 + 内容），任一文件变化即触发
last_reviewed: null 是一等状态：存量技能尚未按本机制复核——当前 122 项中 120 项已复核（本会话审查波覆盖）、2 项（re-ai-triage / re-feedback）从未复核
初始播种规则：本会话被改动过的技能视为已复核（内容正是审查的产物）
已删除技能自动从状态清理并在 status 告警；有测试断言状态文件覆盖全部技能

与增量审查机制原方案的一处偏离：原计划"扩展 validate.mjs"，实际改为独立脚本 + 一条测试断言——审查状态需要写盘与日期，与 validate.mjs 的纯读校验性质不同，混在一起会破坏其单一职责。

三、登记表风险分层（`deriveRisk`）

原 stale 只按"距上次核验的时长"排序，但 134 项积压里不同条目的漂移风险差异极大。新增按断言类型分层（不落盘，随内容实时派生）：

写死了层级路径（如 windows.registry.hashdump）或版本号 → 高风险（+2 各）
写出命令行开关                                → 中（+1）
只点名工具名                                  → 低
出现面（多少个技能引用）                        → 仅作严重度排序，不计入风险等级

第一版把"出现次数"也算进分数，结果 readelf 得 130 分——那是频率不是具体度，已改正为按断言类型。

当前：待核验 134｜高风险 40｜低风险 94，npm run toollife 按影响面给出建议顺序（lldb / tshark / rizin / adb / binwalk …）。

首批回填 6 项（均为本会话审查波中确实核验过 CLI/API 形态的）：vol、frida、candump、mmls、tsk_recover、readelf。

四、本轮校验

npm test：OK: 122 skills validated + 67 项测试全过（上轮 51 + 新增 16）
npm run examples：代码块 913 个｜已检查 391 个，通过
npm run audit:status：已复核未变 120｜待复核 0｜从未复核 2
npm run toollife：登记 140 项｜已核验 6｜超期 0｜待核验 134（高风险 40）

补充 26：把"约定"变成检查——四类收尾（2026-09-14）

前面几轮反复出现同一个模式：多副本信息 + 无单一事实源（frontmatter 解析两套、能力声明无消费端、计数散落六处、references 同名、审查历史泄漏）。这一轮把当时还是"人工约定"的四类也收成检查。

一、probe.sh 工具清单（登记表 → 生成）

probe.sh 硬编码 19 个工具，而登记表已有 137——RE_TOOLS 是 agent 判断"环境里装了什么、优先用什么"的依据，硬编码清单会让已装的工具不被使用。

做法与能力索引同构：登记表是源，probe.sh 里的清单是生成物（lib/probe-tools.mjs + bin/probelist.mjs，--check 校验新鲜度并入 npm test）。

顺带修掉两处真问题：

MEM_GB 恒为空：free 的输出被本地化（内存： 而非 Mem:），awk '/^Mem:/' 匹配不到——固定 LC_ALL=C。与 readelf 同一类坑（本轮 fixture 也踩到）
dd / hexdump 混进登记表：属基础工具，已归入 BASE_UTILS 并从登记表移除（否则会被死条目检查打回）

二、计数同步（人工清单 → 检查）

CLAUDE.md 里的"按清单逐处核对"一直是人工的（历史上漏过 5 处）。tests/counts.test.mjs 把 13 处计数点变成断言，另加两条：README 引用的技能必须存在、每个技能都必须在 README 出现一次。

后者当场抓到一个真缺口：README 用简写 re-format-pe/elf/macho，导致 re-format-elf / re-format-macho 从未以全名出现（简写既不可 grep 也不利于检索）——已改为全名。

三、指纹表覆盖（文档约定 → 检查）

system-fingerprints.md 写着"新增系统分支须同步加行"，但无检查。tests/fingerprints.test.mjs 用 MAPPED / EXEMPT 两张表断言：新增分支若两处都没登记即失败，并要求豁免项写明理由、映射表不得残留已删文件。

四、复核 = 回归断言（`tests/audit-regressions.test.mjs`）

"fixed → verified"原计划是人工复核一遍。改为把已修事实写成永久断言——22 条，覆盖 #1–#21 与补充 22/23。一次完成复核与防回归：日后有人重写技能时，错的说法写回去会直接红。

复核中发现的新问题：三条断言失败，查下去全是技能里刻意保留的迁移对照说明（"旧写法 Module.findExportByName(null, n) 已移除"、"KeyStore 无 getKeyAlias"、"this 上没有 returnValue"）——即文档写对了，是断言太粗。据此给 absent 加了否定语境识别（已移除/已废弃/弃用/无此/没有/不再/不是/勿用/不携带/不支持/不存在/旧写法/过时）。这条规则本身值得记：断言与文档的区别在于，"提到错误"不等于"主张错误"。

五、行为 fixture（四层验证体系的最上层，首次落地）

tests/format-fixtures.test.mjs：对字节布局类断言用纯代码构造最小样本验证，不依赖网络与外部样本。首个 fixture 覆盖 re-format-elf/references/layout.md 的扩展编号三套规则——该处原文即注明"建议配 parser fixture 验证这三条路径"。

这一层立刻证明了价值：fixture 抓出当天早些时候由"修复"引入的新错误——补充 22 里把 ELF 魔数写成"\x7fELF（小端读作 0x7f454c46）"，而 7f 45 4c 46 按小端读是 0x464c457f，0x7f454c46 是大端读法。已改为给出字节序列 + 两种读法（同一文件里另有 free/readelf 的本地化坑，说明这类"看起来对"的细节最需要 fixture）。

六、SKILL.md 预算（re-kernel 拆分问题的结论）

结论：不拆。 实测口径错了——技能是按需加载的库，常驻成本只有 SKILL.md（re-kernel 177 行，与 re-rtos 197 / re-hypervisor 169 / re-analyze 117 同量级），分支用到才读。拆分反而要新增 5+ 技能（计数同步六处）并割裂最有价值的失败模式决策表。

真正要防的是 SKILL.md 膨胀，已加 tests/skill-budget.test.mjs（SKILL.md ≤240、单分支 ≤600、必备章节仍在——最后一条防的是"为了满足预算而削壳"）。顺带发现 re-kernel 用「## 通用主线」代替模板规定的「## 操作步骤」，已对齐。

七、本轮校验

npm test：OK: 122 skills validated + 103 项测试全过（上轮 67 + 新增 36）
新增测试文件 5 个：counts / fingerprints / format-fixtures / audit-regressions / skill-budget
新增脚本：bin/probelist.mjs（npm test 已含 --check）

补充 27：Dart/Flutter 格式错误 + 三处版本漂移（2026-09-15）

来源为外部监控的第三批。6 条全部处理（3 条格式错误 + 3 条版本漂移）。

一、明确错误：re-flutter 的 Dart 格式（两条高影响 + 一条中影响）

#	原文	核验	修正
1	`kernel_blob.bin` 头部是 ASCII `"KERNEL"` magic	错。`runtime/vm/kernel_binary.h` 定义 `kMagicProgramFile = 0x90abcdefu`——是数值，文件里为小端字节 `ef cd ab 90`	识别改为按 4 字节魔数；并补上同源事实：header 共 8 字节 = magic + formatVersion（格式版本可作版本判别）。明确写"不要用字符串 grep 判断 kernel 格式"
2	快照头 = magic `"SNAPSHOT"` 8B + 版本串 12B + 长度 8B LE；用 `data.find(b'SNAPSHOT')` 搜索	错。真实头部是 magic `0xdcdcf5f5`(4B) + length(8B) + kind(8B) = 20 字节基础头；不存在 ASCII `SNAPSHOT`，也没有固定 12 字节版本串	解析代码改为按 `0xdcdcf5f5` 定位 + `struct.unpack('<qq', data[off+4:off+20])`；删去写死的子 blob 分区表，改为"版本相关的内部序列化布局，要精确解析就对着目标 SDK 的 `runtime/vm/snapshot.h` 与序列化器实现"；顺带修掉依赖该错误 magic 的 `strings \| grep SNAPSHOT` 判据（改用 ELF 段符号 `_kDartIsolateSnapshot*`）
3	`kernel_blob` 只在 debug/Profile 构建存在	错。Profile 与 Release 都是 AOT（构建系统对 profile/release 都走 AOT 编译）	执行模型改为 Debug → JIT/Kernel；Profile 与 Release → AOT；两者差别是 profiling/service/优化配置，不是执行模型

两条已固化为回归断言 + 格式 fixture（tests/format-fixtures.test.mjs）：断言 0x90abcdef 的 LE 字节是 ef cd ab 90、0xdcdcf5f5 的是 f5 f5 dc dc、20 字节基础头的三段布局——同时锁定"这两个 magic 不是可 grep 的 ASCII 串"，日后写回去会直接红。

二、版本漂移（三条）

#	位置	原文	修正
4	`re-analyze/references/preferences.md`	IDA Free"当前 8.x"	已过时（2025 年已发布 9.x 线）→ 删掉版本代际的写死，只留能力矩阵（x86/x86-64 限定、无 SDK/IDAPython、非商用），需要时以官方发布为准
5	`re-netcap/SKILL.md`	mitmproxy"（Python 3.10+）"	核验后比审查意见更早：v12.0.0 的 pyproject 就已 `requires-python >=3.12`（不限于 12.1.0）→ 改为"当前 12.x 要求 Python >=3.12；旧环境需 pin 对应旧版"。因 re-tls / re-drm 把安装委托给本技能，只改一处
6	`re-exploit/SKILL.md`	"9.x 支持 Python 3.9–3.11 系"	与 re-angr 已修正的表述直接冲突（angr 9.3.0 起要求 3.12+）→ 删掉 re-exploit 自维护的版本矩阵，改为"兼容性以 re-angr 工具准备为准"——同一事实只维护一份

三、一条"尚未过时但即将过时"的记录

监控同时核验了 Ghidra 的 JDK 21 描述并判定暂不报：当前最新正式 release 仍是 12.1.3（2026-08-18），master 已进入 12.2 文档并改为 JDK 25，但 12.2 尚未正式发布。12.2 发布后该条会立刻成为高优先级过时项——这类"预告式"结论值得保留，它说明版本监控不只在事后抓。

四、本轮校验

npm test：OK: 122 skills validated + 110 项测试全过（上轮 103 + 新增 7）
登记表回填 mitmproxy（现 7 项已核验）；审查状态：已复核 120 / 待复核 0
初版新断言有一条误报（把"kernel magic 0x90abcdef"这种带正确数值的用法也拦下）——已收紧为只禁 "KERNEL" magic 这一旧表述

补充 28：Mach-O 基础常量层（2026-09-15）

一、性质：不是措辞问题，是解析层常量错误

re-format-macho/references/layout.md 在 CPU subtype、header flags、symbol type、fat header 四个基础解析层都有确定性常量错误——依赖该 reference 的 Mach-O / iOS / Swift 分析会被系统性带偏。

核验来源：本机 LLVM BinaryFormat/MachO.h（Apple loader.h/machine.h 的忠实移植，含数值）+ Apple fat.h 文档。未使用搜索摘要中的二手描述（那几轮搜索只给了名字没给数值）。

#	原文	核验后	修正
1	`0x0100000C=arm64`、`0x0100000B=arm64e`	arm64 与 arm64e 的 cputype 相同（都是 `CPU_TYPE_ARM(12) \| CPU_ARCH_ABI64(0x01000000)` = 0x0100000C）；区别在 cpusubtype = `CPU_SUBTYPE_ARM64E`(2)	表格改为"arm64e 靠 cpusubtype 区分，不要用 cputype 判"
2	`3=x86_64`、`0x80000003=x86_64h`	`CPU_SUBTYPE_X86_64_ALL=3`、`CPU_SUBTYPE_X86_64_H=8`；`0x80000000` 是 capability 位（`CPU_SUBTYPE_LIB64`），不把 3 变成 x86_64h	补全 arm64 侧 subtype（0/1/2）与 x86_64 侧（3/8），并把 capability 位单独解释；arm64e 另有 `0x80000000` 作 versioned-ptrauth-ABI 掩码
3	`1=NOUNDEFS 2=DYLDLINK 4=TWOLEVEL … 0x800000=LAZY_INIT`	实际是位值：`0x1` NOUNDEFS、`0x2` INCRLINK、`0x4` DYLDLINK、`0x8` BINDATLOAD、`0x10` PREBOUND、`0x20` SPLIT_SEGS、`0x40` LAZY_INIT（已废弃）、`0x80` TWOLEVEL、`0x100` FORCE_FLAT、`0x200` NOMULTIDEFS、`0x200000` PIE、`0x800000` HAS_TLV_DESCRIPTORS	按 Apple 位值列出，明确"不要手工精简成连续编号"——原表整体错位，还把现代 TLS 描述符标志标成了已废弃的 lazy init
4	`0x0E=N_SECT 0x0F=N_UNDF`	`N_TYPE=0x0e` 是掩码：`N_UNDF=0x0`、`N_ABS=0x2`、`N_SECT=0xE`、`N_INDR=0xA`；`N_EXT=0x01`/`N_PEXT=0x10` 是可 OR 的属性位。`0x0f` = `N_SECT\|N_EXT`（外部节定义符号）	改为分层读（`n_type & N_TYPE` + 属性位单独判），明确"不要把组合值当基础类型"
5	`FAT_MAGIC 0xCAFEBABE（LE 文件字节 be ba fe ca）`；`offset 为 4 字节对齐`	fat 结构在磁盘上恒为大端（Apple fat.h 明述，与宿主无关）→ 正常 FAT 文件开头就是 `CA FE BA BE`；小端读得 `0xbebafeca`（=`FAT_CIGAM`）是同一份字节被小端解释；`fat_arch.align` 是"对齐的 2 的幂"（slice 需 `2^align` 对齐）	两者都改写，并加"别用宿主端序猜文件端序"

二、udsoncan：示例缺少 DID codec 配置

re-automotive 的 VIN 示例直接 Client(conn, request_timeout=2) 后 read_data_by_identifier(DataIdentifier.VIN)，缺 config——而 read_data_by_identifier 依赖 config['data_identifiers']（DID → codec 映射）来解码响应载荷，没有 codec 就无从解码。

修正：示例补上 config['data_identifiers'] = {0xF190: …}（VIN 的标准 DID，17 字节 ASCII codec）并传入 Client(..., config=config)；同时在步骤里加了"读/写 DID 必须先配 codec"的说明与"只想看原始载荷就走不做解码的低层接口"的出路。

一处刻意的克制：data_identifiers 机制与 DidCodec 概念已核验，但具体的 codec 辅助类名未获证实，因此示例里用 ... 占位并注明"用库自带的类型，或自定义 DidCodec 子类"——不能用另一个未经核验的 API 去替换一个错的 API。

三、固化

格式 fixture（tests/format-fixtures.test.mjs）新增 4 条：cputype/cpusubtype 的推导与 arm64e 判别、header flags 的位值（含"按连续编号抄会全错位"的反证）、n_type 的分层读法、fat 的大端与 2^align
回归断言（tests/audit-regressions.test.mjs）新增 2 条：常量表不得复现旧值 + udsoncan 示例必须带 config
写 fixture 时踩到一个跨语言坑并顺手记进断言：JS 的位运算是有符号 32 位，0x80000000 | 3 得 -2147483645，要 >>> 0 才是 0x80000003——与 C 里 uint32_t/有符号的区分同源

四、重复报告说明

本轮报告的 IDA Free "当前 8.x" 已在补充 27 修复（并已有回归断言）；Ghidra JDK 21 的"暂不过时、12.2 发布后即过时"也已记录在补充 27。两条不重复处理。

五、本轮校验

npm test：OK: 122 skills validated + 116 项测试全过（上轮 110 + 新增 6）
初版两条断言失败均为测试自身的 bug（把修正行里的"而不是固定 4 字节对齐"当成旧表述；JS 有符号位运算），已修正

补充 29：Apktool 版本模型落后一个大版本（2026-09-16）

一、性质：不是措辞过时，是整代 CLI 不兼容

re-apk 仍把 apktool 描述为「2.x 系列」，并围绕 2.x 的 --use-aapt2（aapt1/aapt2 二选一）组织回编译流程。但 3.x 已是当前主线、2.x 退为维护线，而 3.x 有一批会让 2.x 命令直接报错的 breaking changes——照仓内现有写法执行会被工具拒绝。

二、核验来源（四路交叉，全部一手）

来源	拿到什么
GitHub Releases（`gh release view v3.0.1`）	3.0.1/3.0.2/3.0.3 的发布说明与 PR 列表；「v3.0.0 因缺 .jar 被撤回，3.0.1 与之等同」
`apktool-cli/src/main/java/brut/apktool/Main.java` @ v3.0.1（源码）	选项定义全集——短参数、长参数、移除项的唯一事实源
官方安装页 `apktool.org/docs/install`（标 "Version: 3.x"）	「A minimum of Java 8 is required to run Apktool」；文档分 3.x / 2.x 两轨
`prebuilt/` 目录里的实际二进制（取回后 `file`）	32 位支持的存在与否——见下

三、逐条核验结果

#	原表述	核验后	依据
1	「apktool：2.x 系列」	3.x 为当前主线、2.x 为维护线，两线命令不完全兼容	Releases 页 3.0.1/3.0.2/3.0.3；官网首页显示 3.0.3 且文档分两轨
2	`--use-aapt2` 可强制 aapt2 回编译	aapt1 整体移除，`--use-aapt2` 这个"二选一开关"随之不存在；换 aapt2 二进制改用 `--aapt <file>`，且传入 aapt1 会被显式拒绝	发布说明 `[v3] Remove aapt1 testing`（PR #3883）；`Main.java:571` — `if (getBinaryVersion(...) == 1) throw new AndrolibException("Legacy aapt is no longer supported.")`
3	（原文未涉及）	不再提供 32 位构建	见下「最有分量的一条」
4	（原文未涉及）	`--api-level` 移除（`Main.java` 中 `api.level`/`apiLevel` 命中 0 处）	源码全文检索
5	（原文未涉及）	`--only-main-classes` 由 `-a`/`--all-src` 取代，且语义相反：前者只解主 dex，后者「Decode all sources in the apk (includes unknown dex files)」	发布说明 `replace --only-main-classes with -a/--all-src`（PR #4069）+ `Main.java` 的 `decodeAllSrcOption` 描述串
6	（原文未涉及）	高级选项只认长参数：v3.0.1 的短参数全集为 `-a -f -j -l -o -p -q -r -s -t -v`，`-m`/`-k` 一类旧短参报 `Unrecognized option`	源码里 `Option.builder("<短参>")` 穷举；佐证：Debian #1140015 — diffoscope 因 `Unrecognized option: -k`/`-m` 改用 `--keep-broken-res`/`--match-original` 才修好

仓内旧调用扫描（按报告的清单全查）：只有 --use-aapt2 命中 4 处（gotchas.md ×2、commands.md ×2）；--api-level、--only-main-classes、-api、-m、-k、-resm、-b 均为 0 处。其余 apktool 调用（d -r、d -s、b -o）在 3.x 下仍然有效，未做无谓改动。

四、最有分量的一条：32 位支持是拿二进制本身证的

官方文档页没有任何架构说明，发布说明也只提了 aapt1。所以这条不能靠转述。改用直接证据——把两个 tag 的 prebuilt/linux/ 二进制取回来自查：

文件	`file` 结果
2.12.1 `prebuilt/linux/aapt2`（无后缀）	ELF 32-bit LSB executable, Intel i386
2.12.1 `prebuilt/linux/aapt2_64`	ELF 64-bit LSB executable, x86-64
3.0.1 `prebuilt/linux/aapt2`（唯一一个）	ELF 64-bit LSB executable, x86-64

2.x 的命名规则由此坐实：无后缀 = 32 位，_64 后缀 = 64 位。3.x 每个平台只剩一个二进制、_64 后缀消失、且实测为 64 位——32 位支持确实没了。这同时解释了命名变化的原因：32 位一去，_64 后缀就没有存在意义。目录结构也同步印证 aapt1 的消失：2.12.1 的 prebuilt/ 带 aapt/aapt_64/aapt2/aapt2_64，3.0.1 只剩 aapt2。

五、刻意没写的两处

Java 要求不动：官方安装页明写「minimum of Java 8」，构建脚本也是 --release 8——原文「依赖 Java 8+」成立，不加戏
--debug → --debuggable 未写入：源码里确见 buildDebuggableOption/longOpt("debuggable")，但 2.x 侧的对应用法是第三方 changelog 转述，未证实的旧名不写
-a 归入 decode 步骤：发布说明另有「promote -a/--all-src to a common option」表明它已是通用选项，仓内按主用途（解包）举例，未对 build 侧下断言

六、Ghidra 12.2 / JDK 25 临界项：本轮复核仍不转为过时

官方 master 的 12.2 文档要求最低 JDK 25，但正式 release 仍为 12.1.3（2026-08-18），12.2 未发布。且仓内现有表述已经把两套要求分开写——re-ghidra/SKILL.md 与 gotchas.md 均为「运行官方 release 需 JDK 21，从源码构建 Ghidra 自身需 JDK 25 + Gradle 9.1+，别混」。这正是不提前报错的原因：JDK 25 要求属于"从源码构建"，不属于"运行正式版"。维持现状，待 12.2 正式发布再转为过时项。

七、固化

tests/audit-regressions.test.mjs 新增 4 条：版本模型存在、「apktool 调用行」不得残留 2.x 专有选项、--api-level 不得写成可用选项、32 位表述与 _64 命名一致
断言只查"像命令一样写出来"的行——迁移说明会刻意引用旧写法（「--use-aapt2 已随 aapt1 一并移除」），按"提到错误 ≠ 主张错误"给迁移语境豁免
变异测试验证非空转：注入 apktool b out/ --use-aapt2 -o x.apk 与 apktool d --api-level 34 ... 后，两条断言精准失败；还原后全过。（第一次注入失败是因为样本里带了「旧写法」三个字、正好落进豁免词表——是样本没造好，不是断言失效，重造后确认有效）
npm test：OK: 122 skills validated + 120 项测试全过（上轮 116 + 新增 4）

补充 30：ELF 段语义 2 项（采纳）+ 一次被驳回的报告（2026-09-17）

一、采纳：`PT_LOAD` 的"唯一被映射"表述错误

原文「PT_LOAD：唯一被映射的段类型」把 loadable segment 与「运行时内存映像里可能出现的东西」混成了一件事。elf(5)（Linux man-pages，内容源自 gABI）原文即是反证：

PT_LOAD："The array element specifies a loadable segment, described by p_filesz and p_memsz. The bytes from the file are mapped to the beginning of the memory segment."
PT_PHDR："specifies the location and size of the program header table itself, both in the file and in the memory image of the program." ← 与"唯一被映射"直接矛盾
PT_TLS 等同样带运行时内存语义

改法：改为「定义需要装载进进程内存映像的 loadable segment（按 p_filesz/p_memsz 建立常规文件→内存映射）」，并显式写上"不要表述成唯一被映射的段类型"+ PT_PHDR 这条反证。

二、采纳：`PT_GNU_STACK` 缺失的默认策略不能一律推断

原文「无 X 标志 = NX；缺失 = 假定可执行栈」——后半句是把一条架构相关的默认当成了跨架构规则。elf(5) 对 PT_GNU_STACK 只规定存在时的行为（"used by the Linux kernel to control the state of the stack via the flags set in the p_flags member"），对缺失不作规定。内核侧 fs/binfmt_elf.c 的 elf_read_implies_exec() 才是决定项，而它是架构相关的：

	缺 NX 的 CPU	有 NX，ia32	有 NX，x86_64
缺 PT_GNU_STACK	需要 RIE	需要 RIE	不需要 RIE
GNU_STACK == RWX	需要 RIE	不需要 RIE：栈 X	不需要 RIE：栈 X

即：x86-64 上缺失按不可执行处理，ia32 上缺失才走 READ_IMPLIES_EXEC。仓内另有一条独立佐证（re-format-elf/SKILL.md 的 dlopen 坑）：glibc 对缺该段的对象是直接拒绝而不是假定可执行——已在 layout.md 加交叉引用。

改法：拆成「存在时 / 缺失时」两种情形，缺失一侧指明依目标 ABI/内核而异并给出 x86-64 与 ia32 的差别。对逆向固件与跨架构 ELF 有实际意义。

三、驳回：udsoncan 的 `ClientConfig` 报告（附实测）

报告称 from udsoncan.client import Client, ClientConfig 执行到 import 就会出问题，ClientConfig 不是供用户实例化的配置类，因此示例在建连前就失败，定为高影响操作级错误。实测三条主张全部不成立：

报告主张	实测结果
import 会失败	`udsoncan/client.py:17` 有 `from udsoncan.typing import ClientConfig`——该名字已绑定在模块命名空间，import 成功
`ClientConfig` 不可实例化	它是 `TypedDict`（`typing.py:29`）；TypedDict 运行时实例化返回空 dict，实测 `ClientConfig()` → `{}`，不抛错
照抄示例会失败	`Client.__init__` 先 `self.config = dict(config)`，紧接着 `refresh_config()` —— 后者 `for k in default_client_config: if k not in self.config: self.config[k] = default_client_config[k]` 把所有缺键补齐

实跑记录（udsoncan 1.26.1，master 2026-08-09，源码 clone 到本地直接执行）：

第 1 步 from udsoncan.client import Client, ClientConfig   → OK
第 2 步 config = ClientConfig()                            → {}（不抛错）
第 3 步 Client(Dummy(), request_timeout=2, config=config)  → OK，最终 19 个键，关键键无缺失
        request_timeout = 2 | data_identifiers = {0xf190: ...}
对照   dict(default_client_config) 写法                    → OK，同样 19 个键、同样结果

结论：示例可运行，不做"修复"。 报告建议的 dict(default_client_config) 本身没错、也是官方 README 的用法，但它不是修正——改成它不会改变任何行为。若照报告去"修"，属于为不存在的问题改动已正确的代码。

四、报告方向仍有价值：顺手把注释从"笼统"换成"实测签名"

既然实跑了一遍，把原文那句过于笼统的「udsoncan 会直接以配置错误终止」换成实测到的精确签名：

该 DID 不在映射里 → 发送请求之前抛 ConfigError：Actual data identifier configuration contains no definition for data identifier 0xf190
映射里有、但 codec 不是 DidCodec 实例 → ValueError：Given codec of type <class 'NoneType'> is not a valid DidCodec
并写明：配置只需给出要覆盖的键，其余由 default_client_config 补齐——这正是驳倒报告的那条事实，值得让读者也知道

这三条都是跑出来的，不是推的。

五、方法教训

读代码推断不能替代实跑：ClientConfig() 的真实结果、refresh_config 的补齐行为，都在源码里，但分散在三处（typing.py / client.py:114 / client.py:156）；不跑一遍就只能停在"看起来会坏"，分不清"看起来会坏"与"实际会坏"
报告的价值不等于报告的正确性：这一条报告判错了，但它促成的实测把原本笼统的注释换成了精确的失败签名——错误报告的净收益仍为正，所以驳回也要给证据链，而不是简单回一句"不成立"

六、固化

回归断言 +3：PT_LOAD 表述、PT_GNU_STACK 缺失默认、udsoncan 已实测事实（第三条的注释里写明了它对应一次被驳回的报告，防止日后有人"照报告的思路"把正确的例子改错）
变异测试：把两条 ELF 表述写回旧文本后，两条断言精准失败；还原后全过
npm test：OK: 122 skills validated + 123 项测试全过（上轮 120 + 新增 3）

补充 31：RISC-V Float ABI 判定错误（+ 扫出 ARM 同型实例）+ pwntools 迁移窗口（2026-09-18）

一、RISC-V：把 ISA 扩展与调用约定混为一谈，并假设软硬可混编

原文：「判定：readelf -h Flags 浮点 ABI 位 + 反汇编浮点指令密度（flw/fadd/fmv 等）佐证；混编软/硬浮点编译单元时按单元确认（同 ARM 场景）」。两处都错：

错误	实测反证
用浮点指令密度反推参数 ABI	`-march=rv64ifd -mabi=lp64` 合法：产物照用硬件浮点指令，参数却仍走整数寄存器
软/硬浮点编译单元可混编	链接器直接拒绝：`cannot link object files with different floating-point ABI`

实验记录（clang --target=riscv64，-march=rv64ifd，同一份 double mul(double,double){return x*y;}）：

-mabi=lp64   → readelf -h: Flags: 0x0            （软浮点 ABI）
                disasm: fmv.d.x fa5, a1 / fmv.d.x fa5, a0   ← 从整型 a0/a1 搬进浮点寄存器
-mabi=lp64d  → readelf -h: Flags: 0x4, double-float ABI
                disasm: fsd fa0, ... / fsd fa1, ...          ← 参数直接在浮点寄存器 fa0/fa1

ld.lld a_lp64.o b_lp64d.o → error: cannot link object files with different floating-point ABI
对照 两个都是 lp64d      → 链接成功（产出 1344 字节）

fmv.d.x fa5, a1 这一行就是全部要害：浮点指令在场，参数却从整型寄存器来。所以浮点指令密度只能佐证「ISA 含 F/D/Q 扩展」，不能佐证参数 ABI。

e_flags 编码（本机 /usr/include/elf.h）：EF_RISCV_FLOAT_ABI = 0x0006 是掩码，SOFT=0x0 / SINGLE=0x2 / DOUBLE=0x4 / QUAD=0x6。仓内 readelf -h 那一行的原始描述本来就对，未改动——错的是把它和"指令密度"并列当判据。

改动：判定改为以 e_flags & EF_RISCV_FLOAT_ABI 为准，写明 ISA 扩展与调用约定是两件事，并补上链接器的硬约束与"观察到局部约定不同时"的替代解释（手写汇编、非标准 ABI、STO_RISCV_VARIANT_CC、FFI/thunk、函数边界识别错误）。

二、扫全仓扫出的同型实例：re-arm

原文 RISC-V 那句末尾写着「同 ARM 场景」，而 re-arm/SKILL.md 的对应条目确实是同一缺陷：

「同一固件可能混编硬浮点（走 s0）与软浮点（走 r0）编译单元」
「vcmp/vcvt 等浮点指令出现频率佐证」← 同上，用指令反推调用约定

已实测的部分：-mfloat-abi=softfp 是「软浮点调用约定 + 允许 VFP 指令」——反汇编为 vmov s0, r1 / vmov s2, r0，从整数寄存器 r1/r0 搬进浮点寄存器 s0/s2，与 RISC-V 的 lp64 完全同型。它照样发射 vmov/vadd/vcmp，所以"浮点指令频率佐证 float ABI"在这里同样不成立。

刻意没写的部分：ARM 侧「硬浮点与软浮点能否混编」我没能证实——LLD 在 -r 下对 soft+softfp、hard+soft、hard+softfp 三种组合全部放行（GNU ld 在此处更严格，但我没有 ARM 版 GNU ld 可验）；并且 clang 产物三种 ABI 的 e_flags 完全相同（都是 0x5000000），EF_ARM_ABI_FLOAT_HARD/SOFT(0x400/0x200) 未被设置。这两点都可能只是"LLD 宽松 / clang 不设位"，不足以推翻仓库现有表述，因此只改掉已确证的那半句（指令频率不能作判据），并写明 softfp 的定位；链接兼容性保持原样不动。

三、pwntools：进入迁移窗口（当前仍可用，故不标过时）

官方 4.15.0 release 说明首行即："This is the last release supporting Python 2 and Python <3.10." 而 4.15.0 至今仍是最新 tag（无 4.16）。所以 pip install pwntools 本身现在没坏——但 4.15.x 已是这条兼容线的末班车，继续维护成无版本限定的「Python 3.8+」会误导到"永远成立"。

改动（含结构收敛）：照 re-angr 已有的先例，把 Python 兼容矩阵只留在 re-pwn 一处，re-exploit 改为引用：

re-pwn：写明当前正式版 4.15.0、支持 3.8+、官方已声明是最后一个支持 <3.10 的版本、后续按 >=3.10 准备、旧环境需 pin pwntools==4.15.0
re-exploit：pip install 命令保留，版本兼容性改为「以 re-pwn 的工具准备为准」——单一事实源，避免重演 angr 那种两处矩阵漂移

四、本轮报告中被核验为"仍然有效"的两项：不动

Frida：官方 Python binding 仍声明 Python >=3.7，pip install frida-tools 仍是官方推荐——仓内「Python 3.8+」不构成过时项
Volatility 3：当前 PyPI 版本仍要求 Python >=3.8——re-mem-forensics 该项保持有效

两条都不做改动。

五、固化

回归断言 +3：RISC-V 判定（e_flags 为准 + 链接器行为 + mabi=lp64 反例）、re-arm（softfp 定位 + 不得用指令频率佐证）、pwntools 矩阵单点维护（re-exploit 不得出现 Python 3.8+、须指向 [[re-pwn]]）
变异测试：把三处写回旧表述后三条断言全部失败，还原后全过
npm test：OK: 122 skills validated + 126 项测试全过（上轮 123 + 新增 3）

补充 32：8 项事实修正（2026-09-23）

本轮报告条目多，按「版本类 / 机制类」分组。版本类全部以 PyPI 的 requires-python 元数据为准（直接查元数据，不用二手转述）；机制类尽量上机实测。

一、版本类 4 项：Python 下限已抬高，无 pin 的安装说明不再成立

技能	原表述	PyPI 元数据（本轮实测）	修正
re-ai-model	torch「Python 3.9+」	`torch 2.14.0` → `>=3.10`；`torchvision 0.29.0` → `!=3.14.1,>=3.10`	标题改 `Python >=3.10`，补版本下限说明与「3.9 需 pin 2.8.x 及更早」
re-ai-model	protobuf「Python 3.8+」	`protobuf 7.36.2` → `>=3.10`	改 `>=3.10`，注明 3.8/3.9 需 pin 旧版
re-blockchain	web3.py「Python 3.8+」	`web3 8.0.0` → `<4,>=3.10`	改 `>=3.10`，注明 7.x 才支持 3.8
re-crypto-decrypt	angr「Python 3.8+」	`angr 10.0.0` → `>=3.12`	删除本地副本，改为「以 re-angr 的『工具准备』为准」

re-crypto-decrypt 的处理方式与报告建议一致：re-angr 早已维护正确的矩阵（9.3.0+ 要求 3.12+），re-exploit 也已改为引用——本次把最后一处副本收掉，angr 的 Python 矩阵现在全库只有一份
web3 的 8.0 major release 影响面已核：全仓搜 web3. 只有安装命令、import 验证与一句「经 RPC 只读」的描述，没有任何 API 示例，因此不存在「示例按 7.x 写」的迁移问题——只改版本文字即可
提交层面的一致性：torch / protobuf / web3 三处的共同形态是「泛化的 X.Y+ 与新版本元数据冲突」，此前的 protobuf 与 web3.py 已在本轮一并处理，不再留同类表述

同时核验为「仍有效、不动」的两项（避免误报）：frida 17.18.0 → >=3.7；volatility3 2.28.2 → >=3.8.0。仓内相关表述保持原样。

二、机制类 4 项：都是「把特例当通则」

这四项形态相同——用一个窄机制的结论去覆盖整个类别，因此都按「拆开两种情形 + 给出判定方法」修正。

1. re-anti-cheat：attach 失败 ≠ PPL；内核调试 ≠ 唯一手段（高影响）

原文三处主张需要拆开：

原文	问题
「反作弊驱动用 PPL 保护游戏与自身进程」	PPL 是 Windows 自身的进程保护机制，不是反作弊"设定"的
「受保护进程（PPL）直接 attach 不可行」	把 attach 失败当成 PPL 的证据
「内核调试是分析反作弊驱动的唯一动态手段」	把"驱动内核侧"等同于"整个反作弊系统"

核验来源：Microsoft PROCESS_PROTECTION_LEVEL_INFORMATION 文档——该结构有明确的 protection level 枚举（PROTECTION_LEVEL_NONE = "The process is not protected"、PROTECTION_LEVEL_PPL_APP = "The process is a third party app that is using process protection" 等），文档中不存在任何「加载某类驱动即成为 PPL」的规则。反作弊当然可以在内核侧做访问过滤、对象回调、完整性校验与反调试而不把目标设成 PPL。

修正：流程改为先查真实 protection level（GetProcessInformation(..., ProcessProtectionLevelInfo, ...) / Process Explorer / WinDbg 读 EPROCESS.Protection），只有非 PROTECTION_LEVEL_NONE 才判 PPL；普通进程 attach 失败时分别排查句柄访问过滤/对象回调（ObRegisterCallbacks）、用户态反调试、自终止、调试器检测。原「唯一手段」条目改写为两个坑：一个专讲「把 attach 失败判成 PPL」，一个专讲「把内核调试当唯一手段」并列出用户态仍可观测的面（service/launcher、IPC、文件与注册表、ETW、网络交互、进程与模块生命周期）。

2. re-zig：普通 Zig 函数不是默认 C ABI（高影响）

原文（主技能与 references/layout.md 各一处）：「调用约定：默认 C ABI（callconv(.c) 为默认）」→ 并由此推出「反编译时无特殊约定负担」。

核验来源 = 本机 Zig 编译器自带的语言定义（0.17.0-dev，lib/std/lang.zig 的 CallingConvention 枚举，注释即官方定义）：

c：「This is an alias for the default C calling convention for this target. Functions marked as extern or export are given this calling convention by default.」
auto：「The default Zig calling convention when neither export nor inline is specified. This calling convention makes no guarantees about stack alignment, registers, etc. It can only be used within this Zig compilation unit.」

即 c 与 auto 是两个不同的枚举成员：普通 fn 走 auto，只有 extern/export 才默认拿 c。callconv(.c) 恰恰是显式要求 C 约定，不是普通函数的默认值。

修正：两处统一改为「C ABI 只在 extern/export 或显式 callconv(.c) 的边界上假定」，并明确「恢复纯 Zig 内部函数原型时不能无条件套 C ABI 的寄存器/聚合传参/返回值规则」；原「C 库调用点参数布局直接按 ABI 读」的作用域收窄到已确认的 C ABI 边界。

3. re-ics：DNP3 组 3 是静态双位输入，不是「事件」（中高影响）

原文速查「组 1 二进制输入 / 组 3 事件 / 组 10 二进制输出 / 组 30 模拟输入」——把 Object Group 3 当成了泛化的"事件"。

核验来源：Wireshark DNP3 解析器（epan/dissectors/packet-dnp.c，IEEE 1815 的独立实现）的对象定义表：

定义	注释原文	组号
`AL_OBJ_BI_*`	Binary Input / Binary Input With Status	1
`AL_OBJ_BIC_*`	Binary Input Change（事件）	2
`AL_OBJ_2BI_*`	Double-bit Input / With Status	3
`AL_OBJ_2BIC_*`	Double-bit Input Change（事件）	4
`AL_OBJ_BO_` / `AL_OBJ_BOC_`	Binary Output Status / Change	10 / 11
`AL_OBJ_AI_` / `AL_OBJ_AIC_`	Analog Input / Analog Input Change	30 / 32

组 3 是静态双位量，它的事件对象是组 4。

修正：按报告建议，把单编号速查扩展成 static/event 成对映射（1↔2、3↔4、10↔11、30↔32），并写明「别把静态量组当事件组」——按静态/事件成对建模正是恢复点表时实际需要的对象模型。

4. re-arm：AArch32 的 8 项向量表被泛化成了整个 Cortex-A（高影响）

原文「Cortex-A 启动代码：复位向量 0x00000000（或高端向量 0xFFFF0000），异常向量表 8 项（Reset/Undef/SWI/…）」——这是 AArch32/Armv7-A 的异常模型，而该技能同时覆盖 AArch64（提供 qemu-aarch64、AAPCS64 路径），会实际误导 Armv8-A 固件入口识别。

核验来源：Linux arch/arm64/kernel/entry.S（部署中的 AArch64 实现）：

SYM_CODE_START(vectors)
	kernel_ventry	1, t, 64, sync		// Synchronous EL1t
	... (共 16 条：EL1t×4 + EL1h×4 + EL0-64×4 + EL0-32×4)
	.org .Lventry_start\@ + 128	// Did we overflow the ventry slot?
...
	msr	vbar_el1, x30			// install vector table

kernel_ventry 宏以 .align 7 + .org +128 固定 0x80 步长，全表 16 项，按当前 EL/低 EL × SP_EL0/SP_ELx × AArch64/AArch32 来源 × sync/irq/fiq/error 分类；基址来自 VBAR_EL1。AArch64 下不存在"固定 8 项 Reset/Undef/SWI 表"。

修正：拆成 AArch32 与 AArch64 两个子项——AArch32 保留 8 项表（注明 low/high vectors 与架构版本控制位相关）；AArch64 写明 VBAR_ELx + 16×0x80 布局，并给出定位线索（msr vbar_el1/el2/el3, Xt 序列），同时提示 reset entry 由实现/SoC 配置决定、不能假定固定在 0。

三、Ghidra 12.2 / JDK 25 临界项：本轮仍不变

官方 Releases 最新正式版仍是 12.1.3（2026-08-18），12.2 未发布，仓内「正式 release 用 JDK 21」继续成立，不改。

四、方法教训：变异测试的样本本身会被设计缺陷骗过

ARM 那条断言我做了两次变异才测通：

第一次把 8 项表改写成简短形式，但该行仍留在 AArch32 项目符号内——它确实是被正确限定的，断言放行是对的，是我的样本没造好
第二次直接把 AArch32 那一行删掉——结果连 needle 一起消失了，断言「无违规」成了空真（存在性检查被 AArch32 出现在别处满足）

只有第三次完整还原成原始通用表述才精准失败。教训：变异测试要复现缺陷形态本身，而不是"看起来相近的改动"；否则会得到"断言通过"的假信号，反过来掩盖断言的空转。

五、固化

回归断言 +6：Python 下限四项、angr 矩阵单点维护、PPL/内核调试、Zig 调用约定、DNP3 对象组、AArch32 向量表
变异测试：六处写回旧表述后对应断言全部失败（ARM 那条按上文重做后失败），还原后全过
npm test：OK: 122 skills validated + 132 项测试全过（上轮 126 + 新增 6）

补充 33：监控报告对账波——95 条逐条判定（2026-09-30）

一、本轮不是修，是判

2026-09-12 至 09-29 的外部监控累计报出 121 条。对账：30 条已修、91 条未修，未修部分自 09-24 起再未进入审查流程（补充 32 是上一波，止于 09-23）。本轮把其中 95 条（91 未修 + 5 已修交叉验证） 逐条判定「报告本身对不对」，产出判定表 docs/audit/2026-09-30-adjudication.md。

判定	条数
采纳（报告成立）	70
部分成立（改措辞不推翻原文）	9
驳回（报告不成立，不改）	11
已修（无需判定）	5

驳回率 11.6%——若不设这道闸口而直接照报告修，会把 11 处正确内容改错。

二、驳回的 11 条及其形态

5 条属「把可辩护的措辞当成事实错误」，且都集中在两处公式类指控上：

ET_DYN 的 e_entry（F036/F047/F069/F110，同句重复上报 4 次）：报告称「相对基址的偏移」是把 VA 写成 RVA 的事实错误。反证：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 的值，仓库措辞与该模型一致，且从未称其为文件偏移。
LC_MAIN.entryoff 入口公式（F034）：反证为 Apple loader.h 注释、dyld MachOAnalyzer.cpp:627 startAddress = preferredLoadAddress() + mainCmd->entryoff，并用 ld64.lld 造样本实测命中。

其余 6 条：pwntools 与 Capstone（把开发线/预发行当成已发行——PyPI 分别仍是 4.15.0 与 5.0.9）、 re-riscv 入口（该句本身已写明「动态链接程序先经 ld.so（PT_INTERP）」，gdb starti 实测证实）、 re-exploit 栈对齐（仓库「call 时 $rsp % 16 == 0」与 psABI 原文逐字对应，探针实测 ==8 触发 movaps SIGSEGV）、udsoncan ClientConfig（补充 30 已驳回，本轮 venv 独立复跑再次确认）。

三、部分成立 9 条：事实层成立、定性偏高

共同形态是报告给出的影响面大于实际，改法为加限定语而非推翻原文。其中两条修正了报告未察觉的方向：

re-format-elf 的 PT_GNU_STACK：报告只说「缺失 ⇒ dlopen EINVAL」过强；实测发现更准确的分层是 glibc dl-load.c 在缺 header 时取 DEFAULT_STACK_PROT_PERMS（x86/x86-64/arm32 为 RWX、aarch64 等为 RW），且 workaround 应为 glibc.rtld.execstack=2 而仓库写的 =1 实测失败
Canary 判定：报告主张的假阴性不成立（grep 为子串匹配，strip 后仍命中），但假阳性成立（-static -fno-stack-protector 的程序因 libc 自带 SSP 仍出现该符号）——报告建议的 -Ws 改法无效

四、采纳 70 条中的高影响项

QEMU 默认网络（re-fw-emulate）：仓库把「不加网络参数」当作完全断网，实测 QEMU 11.1.1 默认创建 type=user,net=10.0.2.0,restrict=off + e1000 网卡。安全基线必须反转——不可信固件须显式 -nic none。传播 8 处，其中 references/commands.md:33 最危险
IDA 9.x（F083）：本机 9.4 安装目录无 ida64/idat64，64 后缀已取消，影响 15 处 / 5 文件
JNI 函数表（F120）：解析 6 份头文件（JDK 8/11/17/27、GraalVM 21、NDK 30），RegisterNatives 恒为 index 215，表项只追加不重排；仓库 probes.md 的「槽号会漂移」与 experience.md 已写死的 0x6b8(槽215) 自相矛盾
TCP 流重组（F060）：re-proto-rev 全流程把 segment payload 当应用层 message；实测 3 次连续 send() 在接收端合并为 1 个 chunk
binwalk（F005 等 4 条）：PyPI 停在 2015 年的 2.1.0，upstream 已转 Rust 重写（v3.1.0）， README 安装走 Docker/Cargo/源码——仓库却把 pip 版写成「跨平台、版本新，推荐」

五、顺带实测出的、报告未提的两处

re-arm 的变体误选判据：armv6m 下 movw/movt 报 armv8m.base、clz/udiv 报 thumb2，armv7m 正常
re-mips 的 R6 描述：「MIPS32r6 起取消延迟槽」不准——R6 仍保留 BEQ/BNE/JALR/JR 的延迟槽，删的是 branch-likely、新增的是 compact 无延迟槽形式

六、方法教训

「未修」≠「是缺陷」：本轮 91 条未修项里 11 条经实测为报告错误。审查波若不设判定闸口、直接按报告改，等于引入新缺陷
公式类指控需要三方交叉：规范原文 + 上游实现源码 + 本机实测。两条公式类驳回都是这样定的，单看规范措辞会误判
实跑不可替代：构造 PNG 验证 IEND 搜索、连发 3 次 send() 看接收端合并、解析 6 份 jni.h 数槽位——这三条若只看报告措辞都会得出相反结论

补充 34：监控报告对账波落地（2026-10-05）

补充 33 的判定表把 95 条报告逐条定案（采纳 70 / 部分成立 9 / 驳回 11 / 已修 5）。本补充记录落地：按 docs/superpowers/plans/2026-09-30-factual-audit-wave.md 的 17 个任务执行，改动落在 55 个技能上。

一、高影响修正

主题	原表述	改后
QEMU 网络（安全基线）	「qemu-user 无网络；qemu-system 默认 `-net none`」	实测 QEMU 11.1.1 不带网络参数会自建 `type=user,restrict=off` + e1000 网卡；改为「不可信固件必须显式 `-nic none`」，并补 qemu-user 不是网络沙箱。传播 8 处
IDA 9.x	`idat`/`idat64` 分 32/64 位	9.x 已取消 64 后缀（本机 9.4 安装目录无该二进制），统一 `idat`，保留 ≤8.x 分支。传播 15 处 / 5 文件
JNI 函数表	「槽号随 jni.h/NDK/ART 漂移」	固定 index 215（解析 6 份头文件：JDK 8/11/17/27、GraalVM 21、NDK 30，表项只追加不重排）；与同技能已写死的 `0x6b8(槽215)` 归一
TCP 流重组	把 segment payload 当应用层 message	在流程中插入强制阶段「流重建 → framing」，示例改为 buffer parser；UDP 单独说明
binwalk	pip 版「跨平台、版本新、推荐」	PyPI 停在 2015 年的 2.1.0，upstream 已转 Rust v3；pip/发行版包标 legacy v2，v3 走官方 Docker/Cargo/源码

二、驳回项的守护

11 条驳回（e_entry / LC_MAIN 公式、SysV 栈对齐、RISC-V 入口、pwntools、Capstone、udsoncan）未做任何修改，并在测试里加了反向守护断言——照报告去"修"会立刻红。

三、固化

回归断言 +33（tests/audit-regressions.test.mjs 78 项），覆盖采纳与部分成立的条目
变异测试：抽查 4 条（Armv6-M 指令宽度、LC_DYLD_INFO 五组、unc0ver 版本、SysV 栈对齐守护），写回旧表述后全部精准失败，还原后全过——断言不空转
补上测试计数的自校验：CLAUDE.md 此前写「validate + 103 项测试」而实际已 168 项，与技能计数不同，这一处无人看管。新增 tests/counts.test.mjs 的检查（顶层 test( 静态计数 == node --test 报告的 tests 数），把这份人工清单也变成检查
npm test：OK: 122 skills validated + 169 项测试全过；capindex --check / toollife check / probelist --check 均 OK；auditstate 回填 55 项后为「已复核未变 120｜待复核 0」

四、方法教训：并行 agent 共用工作区的代价

本波用多个 subagent 并行执行 17 个任务，全部在同一个工作区与 git index 上操作，暴露了几类问题：

裸 git commit 会卷走他人暂存的文件——git add <自己的文件> 后直接 commit，会把并行 agent 已暂存的文件一并提交，造成提交信息与内容不符。改用 git commit -m "..." -- <paths> 后消除。
git reset --soft 差点造成数据丢失——有一次连续两次 reset --soft HEAD~1，把恰好夹在中间的、 另一个 agent 已完成的提交一起摘掉了。内容靠 index 里残留的暂存态侥幸保住，靠 git reflog 定位并恢复。教训：共享工作区里禁止任何历史改写操作，rebase/amend/reset 一律不许。
状态台账（review-state.json）是共享文件，并行任务各自 auditstate update 会互相卷入；收尾统一回填一次才是正确做法。

净结论：并行提速有效，但代价是协调开销与上述三类风险；若再来一轮，应给每个 agent 独立 worktree，或把提交动作串行化到单一执行者。

158 KiB Raw Blame History Unescape Escape

事实性缺陷审查记录

高严重度（11 项，会直接导致错误操作）

中严重度（5 项，会导致错误推理）

批 2（2026-09-13，独立监控 + 本库自查）

批 3（2026-09-13，独立监控第二轮）

工程性问题：历史文档污染（本轮记录，已缓解）

批 3 补充：工具链一致性问题（#38，用户报告，已修）

批 3 补充 2：触发词双语校验（#39，用户要求，已实施）

批 3 补充 3：能力层未闭环（#40，用户报告，部分闭环）

批 3 补充 4：全局数据契约偏文件域（#41，用户报告，已修）

批 3 补充 5：能力层剩余缺口闭环（#42，用户要求，已闭环）

批 3 补充 6：网关选择树能力标注（#43，用户要求，已完成）

批 3 补充 7：新增 re-sample-acquire（#44，用户要求，已落地）

批 3 补充 8：内核覆盖扩到跨平台（#45，用户要求，已落地）

批 3 补充 9：seL4 分析分支（#46，用户提供，已落地）

批 3 补充 10：references 同名歧义治理（#47，用户决策，已落地）

批 3 补充 11：技能计数同步不完整（#48，用户发现，已修）

批 3 补充 13：macOS 低层分支加深（#49，用户提供，已落地）

批 3 补充 14：Windows 驱动分支加深（#50，用户提供，已落地）

需澄清（非误报，但审查表述需修正）

未覆盖范围（局限）

核验来源清单

修复记录（2026-09-13）

后续机制建议（来自同一审查，待评估）

补充 15：特殊系统深化波次（2026-09-13，QNX / Fuchsia-Zircon / UEFI-PI / VxWorks / Zephyr / RTEMS / FreeBSD / illumos）

落地位置（8 → 3 个技能，不新增技能）

核验中发现并写入的边界条件修正（通行说法不完整之处）

本轮校验

补充 16：特殊系统第二批（2026-09-13，分层 hypervisor / 分区 RTOS / 组件 OS，18 类）

落地位置（18 → 4 个技能，不新增技能）

核验中确认的关键边界条件（写入时以这些为准）

本轮校验

补充 17：跨系统误判总表 + 第三批特殊系统（2026-09-13）

一、跨系统总原则 → 新的入口级控制文件

二、新增系统（22 类）的落地位置

三、核验后的关键事实（写入依据）

四、本轮校验

补充 18：14 个分支的深度展开 + Nucleus 新增 + 入口速查表（2026-09-13）

一、落地位置

二、本轮核验后的关键事实

三、未证实 / 未直接命中的内容（已按此处理）

四、版本/代际提示（已写入入口文件）

五、本轮校验

补充 19：HIC 入库与"信任边界"通用规则（2026-09-13）

一、落地

二、触发条件设计（用户明确要求"不能误触"）

三、命名决策（记录在案）

四、核验

五、本轮校验

补充 20：8 个分支的"操作层"补深 + LynxSecure/Quest-V 拆分（2026-09-13）

一、评估维度（记入审查方法）

二、落地

三、补进去的操作层要点

四、未获证实 / 未写入

五、本轮校验

补充 21：系统识别指纹表（2026-09-13）

一、缺口与落地

二、结构：五层流程

三、本轮新核验的事实地基

四、处理原则（重要）

五、挂载

六、本轮校验

补充 22：对 d4a5348 的抽样审查——2 处事实 + 4 处元规则（2026-09-13）

一、事实性修正（2 条）

二、元规则修正（4 条）

三、审查确认无问题的两处（本轮无需改动）

四、本轮校验

补充 23：对 22a76dc 的抽样审查——网络隔离 / 工具生命周期 / ABI（2026-09-13）

一、P0：两处操作级 bug

二、P1：工具操作层（Volatility 3 三连）

三、P1：ABI 两处

四、P2：两处内容错误

五、结构性结论（写入 TODO）

六、本轮校验

补充 24：工具 CLI/API 生命周期机制落地（2026-09-13）

一、交付物

二、设计取舍（记录判断依据）

三、防漂移闭环

四、未做（保留在 TODO）

158 KiB

Raw Blame History

一、示例可执行性（`lib/skill-examples.mjs` + `bin/examplecheck.mjs`）

二、增量审查机制（`lib/review-state.mjs` + `bin/auditstate.mjs`）

三、登记表风险分层（`deriveRisk`）

四、复核 = 回归断言（`tests/audit-regressions.test.mjs`）

一、采纳：`PT_LOAD` 的"唯一被映射"表述错误

二、采纳：`PT_GNU_STACK` 缺失的默认策略不能一律推断

三、驳回：udsoncan 的 `ClientConfig` 报告（附实测）