FirmAgent: Leveraging Fuzzing to Assist LLM Agents with IoT Firmware Vulnerability Discovery

发表于 分类于 本文字数： 6.9k

摘要

Intro

论文题目： FirmAgent: Leveraging Fuzzing to Assist LLM Agents with IoT Firmware Vulnerability Discovery

期刊：NDSS 2026

团队：清华大学网络科学与网络空间研究院及计算机系和信息工程大学

方向：关注 IoT 固件漏洞挖掘，尤其是 Linux-based IoT 设备中的 Web 服务漏洞。

核心定位是：用 fuzzing 先动态确认真实外部输入点，再让 LLM Agent 做静态语义级污点传播和 PoC 生成，解决传统静态分析误报高、传统 fuzzing 漏报高的问题。论文声称在 14 个真实 IoT 固件上发现 182 个漏洞，精度 91%，其中 140 个为未知漏洞，17 个获得 CVE。

各节主要内容分析

Abstract 摘要

摘要直接给出问题、方法和结果。作者认为现有静态分析，包括 LLM 静态分析，容易高误报且不能自动生成 PoC；动态分析如 fuzzing 能产生可触发样例，但覆盖不足、漏报高。FirmAgent 的关键观察是：fuzzing 更擅长找到真实输入相关代码点，静态分析更擅长从这些点出发探索潜在路径。因此：

  1. 先用 fuzzing 收集运行时输入点 (即污点源) 并重建潜在的漏洞路径
  2. 一个 LLM Agent 沿着潜在路径执行上下文感知污点分析
  3. 另一个LLM Agent 来细化模糊生成的测试用例以生成PoC测试用例。

适合汇报时作为开场的一句话是：FirmAgent 不是“用 LLM 指导 fuzzing”，而是“用 fuzzing 给 LLM 提供可信分析锚点”。

I. Introduction 引言

引言先解释 IoT 固件漏洞挖掘的背景：

物联网设备大量应用，大量 Linux-based IoT 固件暴露 Web 服务，Web 接口扩大攻击面。

作者随后对比两类方法：

  • 动态 fuzzing 能触发漏洞并给出样例，但代码覆盖率有限，在 IoT 固件中容易受 URI、参数、配置状态、复杂分支限制；
  • 静态分析覆盖更广，但 source 识别、alias 分析、语义理解不足导致误报高。

混合技术：将动态模糊测试与符号执行或LLM相结合，以绕过复杂的条件检查并达到更深的执行路径。由于需要在模糊测试期间记录执行路径和解决约束，这些方法经常遭受显著的开销。此外，基于Linux的IoT固件的混合模糊测试仍然特别具有挑战性，因为难以在仿真环境中收集精确的运行时约束并使用它们来指导种子突变。

作者进行的实证研究：

  • 模糊测试在覆盖固件内广泛的输入源点方面非常有效。然而，由于严格的参数检查和复杂的控制逻辑，假阴性（漏报）
  • 静态分析可以绕过输入约束，并执行从源到接收器的全面数据流跟踪。然而，经由静态分析识别源点通常具有高误报，这可能将良性流标记为脆弱的。

这一节提出三个挑战：

  • C1: 有限的代码覆盖率。在IoT固件中，关键的web服务逻辑通常在只能通过特定uri访问的单个服务处理程序功能中实现。如果不了解这些uri，模糊测试将无法有效地到达它们。
  • C2: source点识别的准确性和效率。在模糊测试期间监视整个程序地址空间上的污点源可能会导致大量冗余源并显着降低性能。
  • C3: 静态污点分析精度与人工验证成本高。即使有准确的来源，传统的污点分析也会遇到混叠问题和理解代码语义的能力有限，从而导致高误报。此外，它也无法为报告的潜在漏洞 (警报) 生成PoC，从而导致繁重的手动验证负担。

提出FirmAgent：

专门为物联网固件中的漏洞检测而设计的新型混合解决方案。与基于LLM的混合模糊器 [13] 在模糊测试期间调用LLM以生成满足复杂约束的输入不同，FirmAgent利用在模糊测试期间收集的动态信息来帮助LLM推理代码并识别潜在漏洞。

此设计消除了模糊期间频繁LLM调用的开销，并减轻了IoT模糊场景中常见的崩溃引发的中断。FirmAgent要求目标固件可以使用单服务重新托管框架 [5] 进行重新托管，确保感兴趣的网络服务可以成功启动和交互。为了克服在固件中达到不同服务处理程序功能的困难并增加模糊测试的代码覆盖率，FirmAgent从模糊测试前分析开始，以提取服务处理程序功能，关键字以及宿点和基本块之间的距离度量，从而指导模糊测试过程以最大程度地覆盖潜在的源点。为了解决模糊测试过程中与污点源识别相关的低效率问题，我们使用QEMU [18] 实现了一种基于内存的轻量级检测机制，该机制可以有效地识别外部输入并动态完成调用图。因此，它有助于生成准确且完整的潜在漏洞路径。给定这些源和潜在路径，我们合并了两个LLM代理: 执行精确的污点传播分析的污点传播代理模块和自动化PoC生成的PoC生成代理模块。这些组件共同验证了漏洞的存在，从而大大减少了传统上进行漏洞验证所需的手动工作。

作者强调 FirmAgent 与 LLM-guided fuzzing 不同，它不是在 fuzzing 过程中频繁调用 LLM 生成输入，而是用 fuzzing 收集运行时信息，辅助 LLM 对反编译代码做后续推理，从而避免频繁调用 LLM 的开销。

实证研究

表2：静态分析方法 source 识别准确性

说明静态 source guessing 误报高

传统静态 source identification 误报高。它本身并不能证明“静态分析适合做 source-to-sink？

![image-20260623153332733](FirmAgent Leveraging Fuzzing to Assist LLM Agents with IoT Firmware Vulnerability Discovery/image-20260623153332733.png)

表3：fuzzing 可达性

说明 fuzzing 到 source 容易，到 sink 困难

![image-20260623105913117](FirmAgent Leveraging Fuzzing to Assist LLM Agents with IoT Firmware Vulnerability Discovery/image-20260623105913117.png)

II. Background and Motivation 背景与动机

这一节是论文最适合做“问题动机”的部分。作者对现有工具做了横向比较：SaTC、EmTaint、HermeScan、Mango、Lara、OctopusTaint、Greenhouse 等分别在 source 识别、污点传播、PoC 生成方面存在短板，而 FirmAgent 的组合是 Fuzzing 识别 source、LLM 做 taint propagation、Fuzzing + LLM 生成 PoC。

A. IoT Vulnerability Discovery Techniques

![image-20260623105152516](FirmAgent Leveraging Fuzzing to Assist LLM Agents with IoT Firmware Vulnerability Discovery/image-20260623105152516.png)

表I: 基于源识别方法、污点传播方法和PoC生成的SOTA工具的比较。DSE表示动态符号执行，SSE表示结构化符号表达，AST表示抽象语法树，RDA表示到达定义分析。

源识别：前端-后端字符串匹配仍然是静态分析中源识别的最广泛采用和经验有效的方法。

污点传播：通常采用传统的静态技术，例如符号执行 [6]，基于结构化符号表达式的按需别名分析 [7]，到达定义分析 [8] 和抽象语法树 [20] 遍历。尽管正在努力增强这些方法并减少误报，但传统方法中缺乏语义理解限制了它们准确处理上下文敏感结构 (如净化功能) 的能力，从而导致持续的不准确性。

PoC生成：当前的静态分析工具面临基本限制，因为它们可以识别潜在的漏洞位置，但缺乏自动验证它们的能力。

B. Limitations of Existing Approaches

静态分析：通常采用共享关键字匹配来确定候选源函数。作者用实验说明传统静态 source 识别不准：以 HermeScan 为例，候选 source function 中平均只有 21.6% 真的是实际接收外部输入的 source function，候选漏洞调用链中估计约 70% 是误报。

动态分析：特别是模糊测试，通常受到其绕过复杂条件检查的有限能力的限制，从而使代码库的大部分未被探索。这一挑战在物联网固件中变得更加明显，其中许多条件分支依赖于硬件状态或配置值，使得模糊突变很难单独满足

另一边，fuzzing 能到达大部分 source 点，但很难到达 sink 点。表 III 显示 fuzzing 平均能覆盖约 89.7% 的 source 点，但只能覆盖约 25% 的 sink 点和 28% 的潜在漏洞路径。

源点通常位于处理程序函数内的浅层执行路径上。因此，模糊测试实现了较高的源覆盖率。

![image-20260623105913117](FirmAgent Leveraging Fuzzing to Assist LLM Agents with IoT Firmware Vulnerability Discovery/image-20260623105913117.png)

实证研究：如表III所示，模糊测试平均能够到达大约90% 个源点，而仅覆盖25% 个汇点。

作者据此提出核心洞察：fuzzing 适合确认“输入从哪里进入”，但不适合完整走到漏洞 sink；静态/LLM 分析适合从真实 source 出发向 sink 推理。

III. Challenges 挑战

这一节把方法设计动机抽象成三个挑战。

第一，Limited Code Coverage：IoT 固件中许多 source 点藏在不同 service handler 内，如果 fuzzing 不知道对应 URI 和参数，就无法调用 handler，自然无法覆盖相应 source。

第二，准确且高效识别 source 点：如果 fuzzing 过程中记录所有被外部输入污染的变量，会产生大量冗余 source 和路径，带来计算负担；如果从 fuzzing 初始阶段持续追踪所有 taint，又会显著降低 fuzzing 效率。

第三，静态污点传播精度和验证成本：传统 taint 分析容易受指针别名、sanitize 识别、语义理解不足影响，并且通常只报告 alert，不能自动构造 PoC，导致人工验证成本高。

IV. Methodology 方法

这是汇报主体。作者把系统分成两个阶段：Fuzzing-driven Information Collection 和 Taint-to-PoC Agent。第一阶段结合静态预分析和动态运行时监控，收集可信 source 点、间接调用关系和潜在路径；第二阶段由 LLM Agent 做语义级污点传播，并基于 fuzzing 产生的可达 testcase 生成 PoC。

Overview

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
Firmware Image
    ↓
binwalk 解包
    ↓
识别 Web binary
    ↓
IDA 静态预分析
    ├── handler detection
    ├── keyword dictionary
    ├── sink extraction
    └── distance-to-sink calculation
    ↓
Greenhouse / QEMU 重宿主运行
    ↓
guided fuzzing
    ├── 生成有效请求
    ├── 动态污点跟踪
    ├── 识别 Csource
    └── 解析 indirect call
    ↓
构造 Csource-to-sink potential paths
    ↓
Taint Propagation Agent
    ├── 修正反编译代码
    ├── 分析函数内污点传播
    ├── 分析跨函数污点传播
    ├── 判断 sanitizer 是否有效
    └── 输出 vulnerability alert
    ↓
PoC Generation Agent
    ├── 使用 reachable testcase
    ├── 使用路径约束
    ├── 补全参数值
    └── 生成 PoC
    ↓
验证漏洞

Fuzzing-driven 部分包括预 fuzzing 分析和运行时监控。预分析提取三类知识：service handler、输入 keyword 字典、sink scope 与距离。sink distance 用于指导 fuzzing 更靠近安全敏感代码，降低无关 instrumentation 开销。

运行时监控部分通过用户态重宿主运行 Web 服务，再结合字典变异、距离引导变异和 QEMU 插桩收集信息。它只监控预计算的 sink scope 中的指令，并在内存状态从 untainted 变成 tainted 时记录 Csource；同时动态解析 indirect call target，补全 call graph，为后续路径构造服务。

Taint-to-PoC Agent 部分有两个 Agent：Taint Propagation Agent 对反编译代码做函数级、跨函数污点传播判断；PoC Generation Agent 利用污点分析中提取的约束和 fuzzing 产生的 reachable testcase，补全参数值，生成能够触发漏洞的 PoC。

![image-20260623112317037](FirmAgent Leveraging Fuzzing to Assist LLM Agents with IoT Firmware Vulnerability Discovery/image-20260623112317037.png)

Fuzzing-Driven Information Collection

![image-20260623112713138](FirmAgent Leveraging Fuzzing to Assist LLM Agents with IoT Firmware Vulnerability Discovery/image-20260623112713138.png)

Pre-fuzzing Analysis:

作用：为后续分析提供基础信息

  1. Service Handler Detection识别服务处理函数：识别路由注册逻辑中的handler函数。解决的是论文挑战 C1：fuzzing 覆盖率有限。

    问题：文档不完整、前后端不一致以及存在遗留或隐蔽的代码路径

    首先从暴露的接口中提取初始请求模式，例如Web服务器配置、SOAP定义和API文档，通过字符串引用和控制流分析定位处理程序代码块。利用大语言模型学习通用的请求处理模式，通过识别代码中的结构相似性来发现未被记录的处理程序。

  2. Keyword Dictionary Analysis关键字字典分析，提取输入参数字典，后续 fuzzing 可以生成更像真实请求的输入。

    网络流量和程序分析：从观测到的网络流量中提取初始种子，在binary中定位与其交互的函数，按调用频率进行排序，并过滤掉通用的字符串操作（例如strcpy、strcmp），再提取传递给候选处理函数的所有参数。硬编码的直接提取，其他反向数据流分析：

    1. 由字符串常量直接赋值：若变量直接被赋予一个硬编码的字符串，反向分析即可获取该字符串值，并将其记录为关键字。
    2. 从.data数据段进行初始化：如果该变量源自存储在.的全局变量或静态变量。在数据段中，我们确定其基地址，并提取所有相关字符串值作为潜在的关键词。
    3. 动态字符串构造: 在变量是通过字符串连接函数 (例如sprintf，strcat) 生成的情况下，我们在向后分析期间识别此类操作，并继续跟踪构造中涉及的所有字符串组件的来源。

    现实中可能存在其他类型的来源：.rodata 段中的字符串常量
    .bss / 全局结构体运行时填充后的字符串
    堆上动态生成的字符串
    配置文件中的参数名
    NVRAM key 列表
    环境变量名
    HTML / JS / XML / SOAP / API 文档中的参数名
    URL route table / handler table 中的参数字段
    加密或压缩资源解包后的字符串
    自定义 parser 中通过状态机拼出的字段名

    ![image-20260623121422739](FirmAgent Leveraging Fuzzing to Assist LLM Agents with IoT Firmware Vulnerability Discovery/image-20260623121422739.png)

  3. Sink Scope and Distance Calculation计算危险函数范围和距离，以优先考虑导致安全关键操作的代码路径（直接监控所有代码开销太大）。基于污点的漏洞相关的敏感api

    1. Sink Scope（作用域）：在控制流图 / 调用图上反向分析，找出哪些 basic block 可能到达 sink，这些区域才是后续插桩和监控的重点

    2. Distance Calculation：在反向 CFG 上用dijkstra最短路径算法计算每个 basic block 到最近 sink 的距离。距离越近，说明当前 testcase 越接近危险操作。

      打分：score(n) = depth(n) + w · distance_to_sink(n)

      深度 (n) 表示CFG中块n的结构深度，dis(s) 表示到可到达汇点s的最短距离，并且w是平衡探测深度和汇点定向焦点的权重参数。

Runtime Monitoring

预分析完成后，FirmAgent 开始 fuzzing。
但它的 fuzzing 目标不是传统意义上的“找 crash”，而是：

  1. 找到真实外部输入进入程序的位置；
  2. 收集能够到达这些位置的 testcase；
  3. 收集 indirect call 等运行时信息；
  4. 为后续 LLM 分析提供动态事实。
Firmware Rehosting：固件重宿主运行

IoT 固件不能直接像普通 Linux 程序一样跑。FirmAgent 需要先把固件中的 Web 服务组件重宿主起来。论文实现中使用的是 Greenhouse 这类 user-space rehosting 框架。它会尝试模拟固件运行所需的文件系统、环境变量、NVRAM、网络接口等。

运行前提：

1
2
3
4
5
6
7
firmware image
   ↓ binwalk 解包
root filesystem
   ↓ 找到 web binary
user-space rehosting
   ↓
可以接受 fuzzing 请求

为什么选择Greenhouse：

Greenhouse 对 FirmAgent 来说是一个工程上可用的用户态服务重宿主底座，能让目标 Web service binary 在可控环境中启动、接受 fuzzing 请求，并结合 QEMU plugin 监控 indirect call 和 memory state transition。论文实现部分也说，FirmAgent 采用 Greenhouse 来 enable firmware emulation，并用自定义 QEMU plugin 捕获间接调用关系和内存状态变化。

但这不是说 Greenhouse 是最理想选择。它只是当前系统实现中比较实际的选择。

Mutation Strategy：基于 keyword 和 distance 的输入变异

FirmAgent 的 fuzzing 输入不是完全随机的，而是由两个信息指导：

  1. keyword dictionary
  2. distance-to-sink score。FirmAgent 会优先保留和变异靠近sink的case

这比普通 fuzzing 更适合 IoT Web 固件，因为这类程序往往要求请求格式、URL、参数名都比较准确

Taint Tag：给不同输入参数分配不同的 taint tag，用于识别真实的 source point。

FirmAgent 的目标不是尽快 crash，而是尽快观察到更多真实 Csource？

Information Collection 信息收集

  1. 内存状态检测：（传统静态分析通常通过关键词匹配猜 source）在QEMU的TCG (Tiny Code Generator) 执行阶段，监视sink范围内的指令，当某个内存位置从 untainted 变成 tainted 时，FirmAgent 会记录导致这个变化的指令地址，把它作为 Csource

  2. 收集动态控制流信息：静态分析很难确定 handler 到底指向哪个函数。如果调用图断掉，后续 taint analysis 也会断掉。FirmAgent 在 fuzzing 过程中动态记录 indirect call 的真实目标，然后把这些动态解析出来的调用边补回 call graph

Taint-to-PoC Agent

第一阶段得到了sink、Csource、补全的调用图等，但是不等同于漏洞，中间可能有sanitize等。所以 FirmAgent 第二阶段使用 LLM agent 做更细粒度的语义分析。

基于LLM的污点分析 [16]，[17] 在减少假阳性和假阴性方面显示出显着的优势。传统的污点分析也缺乏自动生成PoC来验证漏洞的能力，而LLMs使用构建有效PoC测试用例所需的特定数据来增强模糊生成的输入。

包括两个agent

Taint Propagation Agent

LLM-driven refinement ：应用LLM驱动的细化过程来增强提取的反编译代码的质量

进行精确的数据流分析，以确定源自Csource点的受污染数据是否可以通过有效的执行路径到达敏感的接收器位置。

输入：反编译函数、相关 Csource 和 sink

要求LLM确定给定的Csource和sink之间是否存在污染流。如果跨函数传播，迭代分析（进入下一个函数，每次分析是函数级别的），直到到达sink

![image-20260623143056103](FirmAgent Leveraging Fuzzing to Assist LLM Agents with IoT Firmware Vulnerability Discovery/image-20260623143056103.png)

由于LLM对固件污点分析的理解不足，会出现某些误报。通过我们的分析，我们发现这些误报主要源于三种情况: 对清理逻辑的不当处理，对间接数据依赖关系的误解以及对从系统文件中读取的值作为污点源的错误处理。->警报验证模块

减少跨多个调用链对同一函数的冗余分析->函数级缓存机制

PoC Generation Agent

输入：模糊测试用例，污点分析期间获得的约束（分支、过滤、输入格式），反编译代码

关注 source 到 sink 之间的参数约束，确定请求体中每个参数应该填什么值。并相应地增加原始测试用例，最终产生完整有效的PoC输入。

![image-20260623143348016](FirmAgent Leveraging Fuzzing to Assist LLM Agents with IoT Firmware Vulnerability Discovery/image-20260623143348016.png)

V. Implementation 实现

实现部分说明原型由 4000 多行 Python 和 1000 多行 C 组成。流程上先用 binwalk 解包固件根文件系统并定位 Web binary；预分析使用 IDAPython 脚本在 IDA Pro 中提取函数调用模式、keyword 字典和距离指标；固件仿真使用 Greenhouse 用户态 rehosting；fuzzing 过程中用自定义 QEMU 插件捕获间接调用关系和内存状态转换；LLM 使用 DeepSeek-R1，温度设置为 0.7。

仓库地址：https://github.com/vul337/FirmAgent.git

VI. Evaluation 实验评估

环境

实验围绕四个 RQ：与 SOTA 工具相比漏洞发现能力如何；Csource 识别是否准确完整；各模块贡献如何；PoC 生成是否实用。

数据集是 14 个可成功 emulated 的真实 IoT 固件，来自 Netgear、D-Link、Tenda、Trendnet、Linksys、ASUS、TOTOLINK 等厂商。

对比工具包括 EmTaint、HermeScan、Greenhouse 和 Hy-FirmFuzz。

Comparison with the SOTA Tools

主要结果很强：FirmAgent 报告 200 个 alert，确认 182 个真实漏洞，precision 为 91%；相比之下 EmTaint、HermeScan、Greenhouse、Hy-FirmFuzz 分别确认 10、71、8、13 个真实漏洞。FirmAgent 发现数量分别是这些工具的 18.2x、2.6x、22.8x、14x。

Csource 识别方面，FirmAgent 平均识别 94.2% 的真实外部输入点，并且所有识别出的 Csource 都是真实可外部控制 source，消除了传统静态 source 识别常见误报。

![image-20260623151439417](FirmAgent Leveraging Fuzzing to Assist LLM Agents with IoT Firmware Vulnerability Discovery/image-20260623151439417.png)

![image-20260623151452092](FirmAgent Leveraging Fuzzing to Assist LLM Agents with IoT Firmware Vulnerability Discovery/image-20260623151452092.png)

Source Point Identified by Fuzzing

FirmAgent 识别出的 source 点 全部都是真实外部可控 source，准确率 100%；平均来看，覆盖了 94.2% 的 All-Source

![image-20260623151515518](FirmAgent Leveraging Fuzzing to Assist LLM Agents with IoT Firmware Vulnerability Discovery/image-20260623151515518.png)

  • 一些源点驻留在由于固件中的遗留或死代码中，由于这些函数在执行过程中从不被调用，因此从分析中排除它们实际上有助于减少误报。
  • 某些源点位于复杂的过程间路径上，其中到达对应的汇点需要在较早的执行阶段中满足特定的输入条件。结果，fuzz可能无法触发这些路径，从而使某些源点无法观察到。

Ablation Study消融实验

Csource and Taint Propagation Agent

Directed Fuzzing Strategy

Indirect Call Resolution

LLM Refinement and Verification Modules

![image-20260623180327998](FirmAgent Leveraging Fuzzing to Assist LLM Agents with IoT Firmware Vulnerability Discovery/image-20260623180327998.png)

TABLE VI: Ablation Study on the Contribution of Each Component in FirmAgent to Vulnerability Detection. Firm-Directed removes the directed strategy; Firm-Indirect disables the use of indirect call information collected during dynamic execution; Firm-Cut removes the LLM-based decompiled code refinement and alert verification components; FirmEmt and Firm-Her replace FirmAgent taint propagation module with Emtaint and HermeScan, respectively.

PoC Effectiveness

![image-20260623180419949](FirmAgent Leveraging Fuzzing to Assist LLM Agents with IoT Firmware Vulnerability Discovery/image-20260623180419949.png)

E-poc：直接可用

H-poc：需要人工微调

F-poc：纯假阳性

PoC 生成方面，182 个真实漏洞中 167 个 PoC 可直接自动触发，15 个需要少量人工调整，整体有效 PoC 生成率为 91.8%。失败或需要调整的主要集中在命令注入，因为不同执行上下文下 payload 约束差异大，LLM 很难稳定生成完全正确的利用输入。

与传统的静态分析工具相比，大大减少了漏洞验证所需的人工工作量

VII. Discussion 讨论

讨论部分主要承认两个局限。

第一，FirmAgent 依赖 firmware rehosting 框架。它使用 Greenhouse 做用户态单服务 rehosting，因此只能分析成功重宿主的单个服务 binary，成功率仍然很低，可能漏掉跨 binary 或需要完整系统仿真的漏洞。通过集成多种重新托管策略来提高我们系统的通用性，以支持多二进制和更全面的固件仿真。

第二，FirmAgent 仍有误报，尤其是 buffer overflow。原因是 LLM 有时不能准确理解输入数据与目标 buffer 大小之间的真实关系，从而把实际上不可溢出的代码误判为漏洞。作者提出未来可通过更精确的数据建模、RAG 或 fine-tuning 改善 LLM 对内存语义和 size constraint 的理解。

相关工作分成 firmware rehosting/fuzzing、IoT 固件静态分析、LLM 辅助漏洞检测等方向。作者把 FirmAgent 放在这些工作的交叉点上：它继承 Greenhouse/FirmAFL/FirmFuzz 等动态分析与 rehosting 思路，也借鉴 SaTC、EmTaint、HermeScan、Mango、OctopusTaint 等静态 taint analysis 经验，但区别在于它用运行时信息增强 LLM taint analysis，而不是单纯静态匹配或传统数据流分析。

在 LLM 相关工作对比中，作者指出已有方法多是纯静态，缺少面向固件污点分析的运行时辅助信息；FirmAgent 则通过 fuzzing 收集 source 点和 indirect call 信息，再结合反编译代码 refinement、函数内/函数间分析和 alert verification 提升准确性。

IX. Conclusion 结论

结论回到核心互补性：动态分析能到达大量 source，但难以把 taint 推到 sink；静态分析能探索 source-to-sink 路径，但 source 识别不准。FirmAgent 用轻量 fuzzing 动态识别 Csource，再用 taint propagation agent 追踪到 sink，最后用 PoC generation agent 验证 alert 是否可利用。最终在 14 个真实固件中发现 182 个漏洞，precision 91%。

2. 方法部分总结

可以把 FirmAgent 的方法概括为一条主线：

固件解包与重宿主 → 静态预分析 → guided fuzzing 收集可信运行时信息 → 构建 Csource-to-sink 潜在路径 → LLM Agent 做语义级 taint propagation → LLM Agent 基于 testcase 和约束生成 PoC → 自动验证漏洞。

更细一点，方法有四个关键设计。

第一，用 fuzzing 识别可信 Csource，而不是用静态关键词猜 source。传统静态方法靠 keyword、env、source function list 找输入点，容易把大量非外部可控点误认为 source。FirmAgent 通过运行时 taint 影响观察，只把实际被外部输入影响的代码点记录为 Csource，因此 source 的真实性更高。

第二，用预 fuzzing 分析提升 fuzzing 覆盖。它先静态提取 service handler、keyword dictionary、sink scope 和基本块到 sink 的距离。这样 fuzzing 不再盲目 bit flip，而是根据 URI、参数名、keyword 和 sink 距离进行字典化、距离引导变异。

第三，用 QEMU 选择性插桩收集运行时信息。为了避免全程序 taint tracking 过重，它只在 sink scope 内监控关键指令和内存状态变化，记录 tainted memory transition，得到 Csource；同时动态记录 indirect call target，补全静态 CFG/call graph 缺失的间接调用边。

第四，用两个 LLM Agent 完成“从告警到可验证漏洞”的闭环。Taint Propagation Agent 读取反编译代码、source 和 sink，判断 taint 是否能传播，并处理函数内、函数间、sanitize、alias、反编译不准确等问题；PoC Generation Agent 则把 taint 分析得到的语义约束和 fuzzing 生成的 reachable testcase 结合起来，补全参数值，生成可触发漏洞的输入。

这篇工作的创新点不在于单独提出新的 fuzzing 或新的 LLM 模型，而在于重新分配 fuzzing 与 LLM 的职责：fuzzing 负责提供动态真实性和可达输入样例，LLM 负责做语义推理和约束补全。这个设计比“让 LLM 直接审计整个固件”更可控，也比“让 fuzzing 独自撞到 sink”更容易覆盖深层漏洞。

总结

贡献

先动态找 source，后静态扩展到 sink

提出了新的混合分析思路：重新划分llm和fuzz两者的职责，fuzz找source，llm推到sink（并且有实验说明哪个更适合做什么）

提出 Csource 思路：只有 fuzzing 运行时真正观察到外部输入污染内存，才把这个位置作为 source

形成从 taint alert 到 PoC 的闭环，减少人工验证工作

局限

依赖 firmware rehosting，需要Greenhouse

单服务分析，漏掉跨组件漏洞

LLM 对 buffer overflow 的精确判断仍然不足

PoC generation 对命令注入 payload 的上下文理解仍有限

对 LLM 的可重复性和稳定性讨论不足。没有说明不同模型、提示词影响，多次运行结果是否稳定

漏洞类型覆盖相对集中，主要关注命令注入和缓冲区溢出两类