首先我们来看一下这篇论文的基本信息：

这篇论文来自安全领域的顶会 NDSS 2026，作者团队来自于清华大学网络科学与网络空间研究院。论文题目是 FirmAgent: Leveraging Fuzzing to Assist LLM Agents with IoT Firmware Vulnerability Discovery，各位可以在清华大学官网读到这篇论文（125K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6F1k6i4c8K6k6h3y4Q4x3X3g2U0j5$3g2J5N6q4)9J5k6h3g2V1N6g2)9J5k6h3y4F1i4K6u0r3k6X3W2D9k6i4y4Q4x3V1k6H3j5i4m8W2M7Y4y4Q4x3V1k6F1k6s2y4K6x3U0k6Q4x3X3c8X3K9i4u0E0j5h3N6W2L8Y4c8Q4x3X3g2H3k6r3j5`.）这篇论文的中文可以理解为利用模糊测试来辅助大语言模型进行 IoT 固件漏洞发现。

结论在前

该论文提出的方法，在 14 款真实的 IoT 路由器固件上，一共发现了 182 个漏洞，精度达到了惊人的 91%。其中 140 个为此前未知的 0day 漏洞，17 个已获得 CVE 编号。笔者看到这个数据的时候也很震惊，这是一个非常大的数字。对比同类型的 SOTA 工具，EmTaint 的精度为37%，HermeScan 为 33%，动态分析工具 Greenhouse 为 40%。而 FirmAgent，也就是本文所提出的系统，发现的漏洞集合则完全包含了上述所有工具的结果。

可见论文提出的方法几乎刷新了传统工具在 IoT 设备固件自动化漏洞检测领域上的历史。

研究背景

IoT 设备的固件安全分析，本质上在于找到可控的外部输入，也就是 source，并以此为源头，追踪其流动路径能否到达敏感操作（也就是 sink）附近，比如说 system()、sprintf() 等函数附近。

目前主流的分析方法同恶意软件检测一致，主要分为静态分析与动态分析两大类：

（1）静态分析（ EmTaint、HermeScan 等等 ）：该种方法无需运行固件本身，直接在二进制层面进行逆向分析，其覆盖率广，但误报率也高，原因在于这类方法对于 source 的识别主要依靠字符串匹配，而反汇编的变量命名还原不精准就会导致产生大量无效的分析路径，从而产生性能和准确性问题。同时这类方法对于函数指针形式的间接调用几乎无效，就例如 Paper 里的这个例子：

source 进来以后，Func_Pointer 通过 httpd_struct[4] 拿到函数地址。然后 source 传进 Func_Pointer 继续传播。常规静态分析工具在Func_Pointer 调用这一步就已经断开了，导致找不到最后 system(v5) 的sink。

（2）动态分析（ 例如 fuzzing ）：而动态分析则顾名思义，通过环境模拟，让固件在环境当中跑起来，通过该种分析方式，能够产出可直接验证的 crash，但问题在于 IoT 固件里面大量的 sink 都藏在复杂的条件校验后面，而像 fuzzing 这种的随机变异满足不了这些条件约束，从而导致代码覆盖率受限，漏报问题就由此产生。我们还是来看 Paper 里的这幅图：

虽然在这个例子里，source、sink 组成的完整 taint（也就是污点流） 已经很清晰了。但是问题就在于 acosNvramConfig_match 方法。它读取并判断的的并非 http 传进来的参数，而是本地 Nvram 的固件本地配置，这就导致在模拟环境下，流程可能无法进入到最终的 sink。导致fuzzer 漏掉该 taint 的传播路径。

不难发现，上述的两大类分析方法各有其优缺点，而有趣的是其短板刚好互补，这也正是本篇论文 FirmAgent 的核心出发点。

核心思想

FirmAgent 的核心思路在于他们发现了，基于动态分析的 fuzzing，其虽然容易漏掉具备条件校验等形式的 taint 传播路径，但其对于 source 的识别率却相当的高。在实测过程中，fuzzing 平均能覆盖约 90% 的 source 点，而 sink 只有 25%。由此发现，团队就提出了这样一种方案：

使用 fuzzing 定位 source，

用 LLM 负责从 source 到 sink 的污点传播分析。

因此，整个 FirmAgent 的核心流程就分为了两个 Phase：

【 Phase 1 】：Fuzzing 驱动的信息收集，而该阶段又分为以下两个步骤：

（1）Pre-fuzzing Analysis ：该阶段首先需要找出固件所有 HTTP handler，确认哪些入口可以接受请求。接着需要收集危险函数名与参数名，建立关键词典。接着通过静态分析找到所有 sink，比如 system() 等调用点。最后由 sink 出发反向 BFS 得到 DistMap（也就是距离图，其中记录了每一块距离真实 sink 的层数，也就是所谓的距离），并在调用图上记录距离标签。

（2）Fuzzing-Driven Collection ：第二阶段首先需要对每个 handler 构造对应 URI 的 HTTP 请求模板。然后对于每个关键词，注入请求并在输入中打上标记。接着查 DistMap，计算当前输入所得到的距离分数，并按照分数的高低来引导变异。变异后重新模拟执行，并更新分数，最后检测其是否到达了sink 附近，若到达，则记录测试用例与传播路径即可。

【 Phase 2 】Taint-to-PoC Agent ：在最后一个阶段，拿到 Phase 1 中得出的每一条测试用例与传播路径后，创建两个 Agent。

Taint Propagation Agent 负责分析从 source 到 sink 的完整 taint 链条。而PoC Generation Agent 则根据 taint 链生成可利用的攻击请求，并输出最终的 PoC。例如笔者复现实验的过程中，就产生了如下格式的结果：

结语

笔者在复现这篇 Paper 的过程中也踩了不少坑，在这里一并记录下，希望能帮到同样想复现这篇工作的朋友们。

环境搭建上，Greenhouse 需要从源码编译，直接使用安装脚本会遇到 angr 库的版本兼容的问题，安装过程中会报错，需要手动处理依赖版本。

而在实际运行中，笔者遇到了一个 NoneType 的错误，最后看下来是 backend/QemuRunner.py 里的问题。Docker 容器内 host 网络模式下，IPAM 的 Config 字段为 null，直接遍历会出这个错。修复方式是将里面的：

for conf in configs:

改为：

for conf in(configs or[]):

此外还遇到了 NVRAM 相关的错误，这些问题本质上都是 rehosting 方面的局限，因为固件运行依赖于硬件配置，

而 Greenhouse 的模拟环境里缺少对应的上下文，所以复现的时候要留一下这方面的问题。

另外，Paper 在 Linux 里使用 IDA Pro 做反编译，笔者在复现的时候将其替换为了 Ghidra，整体流程是没问题的可以跑通，但是要改不少后续的脚本文件做格式对齐，而且其反汇编质量可能和 IDA 也还是有一定差距的。

总的来说呢，这篇论文，其核心思想与设计在于其综合了两种分析类型的利弊，实现了扬长避短，用 fuzzing 来定位 source，用具备语义分析优势的 LLM 做污点传播，从而实现了非常好的分析效果。大家感兴趣的可以前往开源仓库自行探索：d5bK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6$3N6h3H3K6x3K6N6Q4x3V1k6r3K9i4u0E0b7h3N6W2L8Y4c8Q4x3X3g2Y4K9i4b7`.

最后欢迎大家关注，后续还有很多好康的哦！若各位有任何的反馈与建议，也欢迎反馈至邮箱 llmsecbook@163.com。

传播安全知识、拓宽行业人脉——看雪讲师团队等你加入！