作者：记忆里的纯真

摘要：固件漏洞挖掘的瓶颈不在于「模型看不懂汇编」，而在于没有一套可执行、可复核的工作流。本文介绍一个开源的 IoT 固件审计 Skill：它把资深审计员的工作骨架——流水线、资源分配、证据标准、质量门禁——编码成协议，再用纯标准库脚本把关键判据做成机器可判的形式。文章重点讲三件事：怎么让「审过了」变成可验证的结论；怎么检测跨请求的高阶污点漏洞（并给出对 IEEE S&P'26 论文 Bridge 的实测复现与一处判据修正）；以及怎么用测试守住文档本身。文末附完整实现与自检数据。

它不是又一个「一键挖洞工具」。市面上已经有 FAT、Firmadyne、EMBA、FACT 这类整链工具，它们的价值是交叉验证基线；但它们也把分析路径固定死了——遇到非常规固件（UBIFS 而不是 squashfs、MIPS16e、自研 Web 框架）就在某一环卡住，而卡住之前的结论往往看起来依然完整。

这个 Skill 固化的是三层能力：

工作流是「侦察 → 按判据选路 → 调用能力 → 观察反馈 → 按反馈调整」，而不是「按顺序试工具」。这一点决定了它在异常固件上的表现：失败时先读反馈定位原因，换实现是最后手段。

仓库地址：609K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6p5M7X3!0A6k6p5E0S2L8r3W2Q4x3V1k6A6L8%4c8Q4x3X3c8X3K9i4u0E0N6$3q4J5k6g2)9J5k6s2k6#2L8r3&6Q4x3X3c8Z5N6h3&6@1K9h3&6Y4（Apache-2.0）

把固件丢给任意一个强模型，说「帮我找漏洞」，你会看到这几类问题反复出现：

这九条里，真正致命的只有两条：假装覆盖和CVE 当漏洞。前者让报告失去可信度，后者让厂商直接忽略你的提交。所以 Skill 的设计重心不是「帮模型想得更多」，而是给结论加约束。

关键设计：中间状态全部写文件，不信任模型记忆。任何时刻中断都能从产物恢复；多个 Agent 分工时，交接靠文件而不是靠「我上一轮说过」。

Phase 3 的三层结构值得展开，因为它决定了「广度」和「深度」怎么分工：

固件没有「代码行数」直觉——一个 40 MB 的镜像里可能有 30 MB 是证书、字体和 locale。所以用 ELF .text 段大小（而不是文件大小）乘 Tier 权重来估算认知负荷：

Tier 由 R0–R7 规则引擎判定（先后顺序即优先级）：doc/、字体、静态资源 → SKIP；Layer 1 命中 P0/P1 → 动态提升 T1；监听服务、cgi-bin/*、协议解析器 → T1；etc/init.d/*、*.sh、nvram 默认值 → T1；.so、.ko、非监听守护进程 → T2；未匹配任何规则 → T2（保守兜底，不降级）。

命令层面就是一行：

这里有个诚实标注：EALB 目前是 heuristic。仓库里带了校准脚本（ealb_calib.py：predict / evaluate / fit / check），但状态机是明确的——真实工时样本 ≥20 才进 experimental，≥60 且 MAPE ≤0.30 才进 calibrated。在此之前，EALB 只用于排序和切分 Agent，不能当工期承诺。写这句话比喊「智能估算」有用。

自动化审计最常见的三类假阳性，都不是模型算错，而是流程给了错误信号：

① 空集通过
「漏洞详情」整节缺失时，字段校验器遍历 0 个条目，返回「全部完整」——0 条当然都完整。修复方式很土：先判区块是否存在，缺整节直接失败。

② 未执行算通过
高级检查（入口级覆盖、绕过矩阵、跨请求溯源）只在启用时才进判据表。于是 exit 0 变成「所有检查都过了」，而实际上其中几项根本没跑。修复是把判据改成四态：

SKIPPED 的含义是「本次没有执行」，strict 档位下必需项 SKIPPED 直接判失败。同时落一份 gate-config.json：档位、门禁版本、各项阈值、每项检查状态、全部输入的 sha256——换台机器可以复算同一次判定。

③ 版本命中当漏洞
busybox 1.31 命中几十条 CVE，但这个镜像可能裁掉了相关 applet、可能已 backport 修复、可能漏洞需要编译期未开启的选项。所以 CVE 只能走三态：cve-hit（仅版本落在区间）/ cve-reachable（定位到受影响函数且可达）/ cve-exploitable（动态复现）。门禁会检查：版本命中被写成漏洞断言 → V1 违规；未验证的组件 CVE 被塞进「漏洞统计」表 → V2；同一 CVE 同时出现在「组件风险」和「漏洞详情」→ V4（应移动而非复制）。

七道门禁一览：

从 Phase 0 到 Phase 5 的产物都是纯文本 + JSON，门禁只读文件不读模型的自述。这是整个设计里我最坚持的一点：报告的措辞不能成为证据。

以 D-Link DIR882 为例，它的 Web 请求处理是两段式的：边界二进制 prog.cgi 收请求、按动作关键字（SetNetwork、SetVLAN）分发；需要改系统状态时，通过 IPC 控制消息（notify_rc）交给 rc 进程继续处理。

于是漏洞可以是这样的：

只审请求 2 的人会看到「lan0_management_link 来自 nvram，是设备自己的配置，不可控」；只审请求 1 的人会看到「写进去了，但没人拿它执行命令」。两边都看不出问题，而链是通的。

这类漏洞的定义可以做到完全可判定——写它的请求 ≠ 触发读的请求：

IEEE S&P 2026 的 Bridge 把这个问题拆成三步（我按其开源 artifact 逐行读过实现）：

统计口径上，Bridge 在 44 个固件上报告 1168 个真阳性，其中 566 个高阶。

论文的实现依赖 IDA Pro + angr + 40 核，普通审计机跑不动。所以 Skill 里做的是判据落地，不是复刻工具链：

我在一台 4 核 / 15 GB 的 Ubuntu 上把论文 artifact 的镜像真跑了一遍（DIR878_0day，MIPS32）：

入口点识别结果是 callback_key 形态，前端动作名匹配 128/152；最终 vuln_result.txt 有 1188 个键，其中带 other_get（读发生在另一个二进制）的 35 个。动机样例的输出与论文给定样例逐字一致：

但跑完我改了自己文档里的一条判据。other_get 不等于高阶。 同一个结果文件里还有：

读点同样在 rc，同样带 other_get，但写它和触发读的都是 SetSysLogSettings——一个请求既写完又触发读，这是一阶。

原因很直接：读点几乎总在 rc / librcm.so，从来不在边界二进制里。所以「读在别的进程」根本不能当高阶证据。我在原文档里把「读点宿主」当成了 read.action，这会把所有一阶都算成高阶——一个典型的、靠读论文发现不了、只能靠跑数据发现的错。

修正后的链是五元组：

read.trigger_action 来自 ADG（前端），read.binary:addr 来自 BDG（进程）。两者都写清楚，一阶和高阶才不会混。

这一节是我认为最值得在同类项目里抄的做法。

起因：文档 Phase 2 的示例命令曾把布尔开关 --tier 当成路径参数（--tier fw-audit/.../01-extract），而 --rootfs 才是路径参数。命令照抄必然报错，但所有单元测试是绿的——因为测试根本不读文档。

做法：把文档当成被测对象。自检脚本第 14 组会：

两条断言都用注入式负向测试验证过：把 bug 注回文档，测试必须红；正式版必须绿。

同类守卫还有：安装章节不得引用第三方安装器；徽章数字与实际 git ls-files | wc -l 和 wc -l 对得上；gate-config.json 里记录的检查项数量与判据表一致。

现在的自检规模：202 条断言 / 21 组，纯 Python 标准库，不依赖 binwalk / IDA / angr，任何平台 python scripts/selftest.py 就能跑。这带来一个副作用：改脚本时心里有底——判据被改坏了，自检会先红。

写工具的人最容易犯的错是把 roadmap 写成现状。这个仓库现在的状态是：

我宁可把这些写在 README 第一屏，也不愿意让人装完发现「原来只是个提示词合集」。

一次最短的完整审计：

产物目录 fw-audit/<target>/ 就是全部中间状态，可以直接打包交接给下一个人或下一个 Agent。

做这个 Skill 的过程中最深的体会是：自动化审计的难点不在「让模型多算」，而在「让结论可被否决」。

一个模型说「这里存在命令注入」，价值有限；一份报告能让人在 10 分钟内复核「写点在哪、读点在哪、中间经过哪个控制值、sink 是谁」，才有价值。前者靠能力，后者靠约束——而约束是可以用代码固化的：状态机、门禁、四态判据、输入哈希、图结构。

如果你也在做固件或 Agent 相关工作，欢迎提 issue 或直接开 PR。公开仓库：99eK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6p5M7X3!0A6k6p5E0S2L8r3W2Q4x3V1k6A6L8%4c8Q4x3X3c8X3K9i4u0E0N6$3q4J5k6g2)9J5k6s2k6#2L8r3&6Q4x3X3c8Z5N6h3&6@1K9h3&6Y4