AIJon: Automated Generation of Annotations for Fuzzing

本文由 paper-daily 使用 DeepSeek 自动生成，仅供快速了解论文；关键结论请以原文为准。

【一句话总结】本文提出 AIJON，利用大语言模型自动生成模糊测试注解，验证了 LLM 注解与人类注解性能相当，并揭示了注解对模糊测试能量分配的关键影响。

基本信息

属性	内容
作者	Jayakrishna Menon Vadayath, Hulin Wang, Moritz Schloegel, Jie Hu, Wil Gibbs, Tiffany Bao, Adam Doupé, Ruoyu "Fish" Wang, Yan Shoshitaishvili
来源	arXiv:2609.18457
发布日期	2026-09-16
抓取领域	软件工程 · 分析/测试/合成
学科方向	安全加密 · 软件工程
arXiv 分类	cs.CR, cs.SE
适用层次	进阶
标签	【标签】模糊测试, 大语言模型, 注解生成, 漏洞检测, 能量分配
PDF	在线阅读
代码仓库	暂无

问题的初衷（Why - 为什么要做这个研究）

【问题的初衷】现代模糊测试（Fuzzing）工具普遍采用代码覆盖率（Code Coverage）作为反馈信号来指导探索过程，这一策略已被证明在驱动程序探索方面非常有效。然而，这种策略存在一个根本性的盲区：它完全忽略了那些虽然不会触发新代码路径、但对目标程序而言仍然具有特殊意义的输入。例如，某些输入可能触发特定的数值边界条件、特定的状态转换或特定的语义行为，但由于不增加覆盖率，模糊测试器会将其视为无价值的输入而丢弃。IJON 等先前研究已经表明，由人类领域专家手工编写的注解（Annotation）可以提供额外的反馈信号，引导模糊测试器探索程序中更有趣的部分。然而，手工注解的生成需要深厚的领域专业知识，这严重限制了该方法在大规模真实世界漏洞检测中的可扩展性。因此，本文的核心动机是：能否利用大语言模型（Large Language Model, LLM）自动生成高质量的注解，从而在不需要人类专家介入的情况下，将注解驱动的模糊测试推广到大规模应用场景中？

问题的解决（What - 提出了什么方案）

【问题的解决】本文提出了 AIJON，一个利用大语言模型自动生成 IJON 风格注解的系统。其核心思路是：将目标程序的源代码提供给 LLM，由 LLM 分析代码语义并自动生成注解，这些注解随后被注入到模糊测试器中作为额外的反馈信号。本文首先复现了 IJON 的实验，并将其扩展到大规模真实世界漏洞检测场景。为了验证 LLM 生成注解的可行性，作者进行了初步实验，发现 LLM 生成的注解在性能上与人类专家生成的注解相当。基于这一发现，作者设计了 AIJON 系统，并在 Magma 基准测试集上进行了评估。与预期不同的是，实验结果显示基于注解的模糊测试并不严格优于 AFL++。作者随后进行了多项实验来探究这一结果的原因，并识别出关于注解对模糊测试活动影响的关键洞察，特别是注解对模糊测试器能量分配（Energy Distribution）的影响。本文的本质创新在于：首次系统性地探索了 LLM 自动生成模糊测试注解的可行性，并揭示了注解驱动模糊测试在实际应用中的复杂性和局限性。

技术方法详解（How - 怎么实现的）

【技术方法详解】

注解生成流程：AIJON 首先从目标程序的源代码中提取关键代码片段，构造提示词（Prompt）发送给 LLM，要求 LLM 生成 IJON 风格的注解。注解的形式包括在特定代码位置插入 IJON_MAX、IJON_MIN、IJON_SET、IJON_STATE 等宏调用，用于向模糊测试器传递额外的语义反馈。
IJON 注解机制：IJON 是嵌入在目标程序中的宏，通过共享内存与模糊测试器通信。例如，IJON_MAX(x) 告诉模糊测试器当前执行中 $x$ 的最大值是重要的，模糊测试器会优先保留使 $x$ 增大的输入。IJON_STATE(n) 则定义了一个 $n$ 位的状态空间，模糊测试器会尝试探索所有 $2^{n}$ 个状态。
LLM 提示工程：作者设计了特定的提示模板，包含目标函数的源代码、IJON 注解的语法说明以及注解语义的解释。LLM 被要求识别代码中可能受益于注解的变量和状态，并生成相应的注解插入位置和参数。
注解注入与模糊测试：生成的注解通过源代码插桩（Instrumentation）注入到目标程序中。编译后的二进制文件与 AFL++ 配合运行，注解通过共享内存将额外反馈传递给模糊测试器，影响其种子调度和能量分配策略。
能量分配分析：作者深入分析了注解如何影响模糊测试器的能量分配。在 AFL++ 中，能量分配决定了每个种子被变异和执行的次数。注解的引入会改变种子的优先级，可能导致某些种子获得过多或过少的能量，从而影响整体探索效率。
实验评估方法：在 Magma 基准测试集上，作者对比了 AIJON、原始 IJON、AFL++ 以及 LLM 注解与人类注解的混合方案。评估指标包括漏洞发现数量、代码覆盖率、时间到首次漏洞发现（Time to First Bug）等。

系统架构图

方法流程图

核心公式与算法

【核心公式】

注解反馈的能量分配调整公式：

E_{a d j u s t e d} (s) = E_{b a s e} (s) \cdot \prod_{i = 1}^{n} f_{i} (a_{i} (s))

其中 $E_{b a s e} (s)$ 是种子 $s$ 的基础能量， $a_{i} (s)$ 是第 $i$ 个注解在种子 $s$ 执行中的值， $f_{i}$ 是注解 $i$ 对应的能量调整函数。

IJON 状态空间探索的覆盖率度量：

C_{s t a t e} = \frac{| {s \in S : state (s) \neq \emptyset} |}{2^{n}}

其中 $n$ 是 IJON_STATE(n) 定义的状态位数， $S$ 是所有执行过的输入集合。

注解有效性的评估指标：

Effectiveness = \frac{{Bugs}_{a n n o t a t e d} - {Bugs}_{b a s e l i n e}}{{Bugs}_{b a s e l i n e}} \times 100 %

用于衡量注解驱动模糊测试相对于基线模糊测试的漏洞发现提升百分比。

应用场景（Where - 在哪落地）

【应用场景】

大规模开源软件漏洞挖掘：在开源软件生态中，大量项目需要持续的安全审计。AIJON 可以自动分析项目源代码，生成注解并集成到持续集成/持续部署（CI/CD）流水线中，实现自动化的模糊测试。例如，对于一个包含数百万行代码的操作系统内核项目，AIJON 可以自动识别关键的安全敏感函数（如内存分配、权限检查等），生成相应的注解，引导模糊测试器优先探索这些区域。预期效果是显著降低人工审计成本，同时提高漏洞发现的效率。
嵌入式系统固件安全测试：嵌入式设备固件通常包含大量专有代码，缺乏公开的漏洞数据库和测试用例。AIJON 可以利用 LLM 对固件二进制或反编译代码进行分析，生成语义注解，指导模糊测试器探索固件中的关键状态机（如通信协议解析、加密模块等）。由于嵌入式系统资源受限，注解可以帮助模糊测试器更高效地利用有限的计算资源，优先探索最可能包含漏洞的代码区域。
协议实现的安全性验证：网络协议实现（如 TLS、HTTP/2 等）通常包含复杂的状态机，传统的覆盖率引导模糊测试难以有效探索所有状态转换。AIJON 可以自动识别协议实现中的状态变量和转换条件，生成 IJON_STATE 注解，引导模糊测试器系统地探索协议状态空间。预期效果是发现更多与协议状态相关的深层漏洞，如状态混淆、重放攻击等。

具体技术细节示例（How in Action - 算法如何执行）

【具体技术细节示例】假设目标程序是一个简单的 JSON 解析器，其中包含一个函数 parse_number，负责解析 JSON 中的数字。该函数有一个局部变量 depth 表示嵌套深度，以及一个变量 value 表示当前解析的数值。

步骤 1：代码分析与片段提取。AIJON 提取 parse_number 函数的源代码，包括变量声明、循环结构和条件分支。

步骤 2：LLM 提示词构造。提示词包含以下内容：函数源代码、IJON 注解语法说明、以及要求 LLM 识别可能受益于注解的变量。

步骤 3：LLM 生成注解。LLM 分析后可能生成以下注解：在 depth 更新后插入 IJON_MAX(depth)，表示模糊测试器应优先保留使嵌套深度增大的输入；在 value 赋值后插入 IJON_MAX(value)，表示应优先保留使数值增大的输入。

步骤 4：注解注入与编译。将 IJON_MAX(depth) 和 IJON_MAX(value) 插入到源代码的相应位置，然后编译程序。

步骤 5：模糊测试执行。假设初始种子输入为 {"a": 1}，执行后 depth=1，value=1。模糊测试器记录这些值。下一次变异产生输入 {"a": {"b": 2}}，执行后 depth=2，value=2。由于 depth 和 value 都增大了，模糊测试器给予该种子更高的能量，使其被更频繁地变异。

步骤 6：能量分配调整。假设基础能量 $E_{b a s e} = 100$ ，IJON_MAX 注解将能量乘以 1.5 倍，则调整后能量 $E_{a d j u s t e d} = 100 \times 1.5 \times 1.5 = 225$ 。这意味着该种子将被执行 225 次，而不是 100 次。

步骤 7：结果分析。如果注解引导模糊测试器发现了深层嵌套导致的栈溢出漏洞，则注解有效；但如果注解导致模糊测试器过度关注数值大小而忽略了其他类型的漏洞（如字符串处理漏洞），则注解可能产生负面影响。

实验结果（Results - 效果如何）

【实验结果】论文在 Magma 基准测试集上进行了评估，Magma 是一个包含真实世界漏洞的模糊测试基准，涵盖了多个开源项目（如 libpng、libtiff、openssl 等）。对比方法包括：原始 AFL++、人类注解驱动的 IJON、AIJON（LLM 自动生成注解）以及 LLM 与人类注解的混合方案。实验结果显示，出乎意料的是，基于注解的模糊测试并不严格优于 AFL++。在某些目标程序上，注解驱动的模糊测试表现更好，但在另一些目标上则表现更差。作者通过多项实验分析了原因，发现注解会显著改变模糊测试器的能量分配，导致某些种子获得过多能量而其他种子被忽视。值得注意的是，LLM 生成的注解在性能上与人类专家生成的注解相当，这表明 LLM 在注解生成任务上具有实际可用性。这一发现为未来大规模研究注解对模糊测试的影响打开了大门。

实验结果可视化

优势与不足

【优势与不足】

优势：

首次系统性地探索了利用 LLM 自动生成模糊测试注解的可行性，验证了 LLM 在此任务上可以达到与人类专家相当的水平，具有重要的开创性意义。
对注解驱动模糊测试进行了深入的实证分析，特别是揭示了注解对模糊测试器能量分配的影响机制，为后续研究提供了关键洞察。
实验设计严谨，不仅复现了 IJON 的实验，还将其扩展到了大规模真实世界漏洞检测场景，增强了结论的可信度。
坦诚地报告了负面结果（注解不严格优于 AFL++），这种学术诚实有助于推动领域对注解机制的深入理解。

不足：

实验仅在 Magma 基准测试集上进行，该基准虽然包含真实漏洞，但规模仍然有限，结论的泛化性有待验证。
LLM 生成注解的质量高度依赖于提示词设计和模型选择，论文未深入探讨不同 LLM 或提示策略对注解质量的影响。
注解对能量分配的负面影响机制虽然被识别，但论文未提出有效的缓解方案或自适应策略来优化注解的使用。
缺乏对注解生成成本（如 LLM 调用费用、时间开销）的详细分析，这在实际大规模应用中是一个重要考量因素。

未来研究方向

【未来方向】

自适应注解策略：研究如何根据模糊测试的实时进展动态调整注解的权重和优先级，避免注解导致的能量分配失衡问题。例如，可以设计一种反馈控制机制，在注解引导效果下降时自动降低其影响。
多模态注解生成：探索结合源代码、二进制分析和运行时信息的多模态输入，提升 LLM 生成注解的准确性和覆盖面。例如，利用动态分析获得的执行轨迹来辅助 LLM 识别关键状态变量。
注解效果的理论建模：建立注解对模糊测试探索行为的理论模型，从信息论或搜索优化的角度分析注解何时有益、何时有害，为注解的设计和使用提供理论指导。
跨语言与跨平台注解生成：将 AIJON 的方法扩展到更多编程语言（如 Rust、Go）和平台（如 WebAssembly、移动端），验证其泛化能力。

一句话总结

【一句话总结】本文提出 AIJON，利用大语言模型自动生成模糊测试注解，验证了 LLM 注解与人类注解性能相当，并揭示了注解对模糊测试能量分配的关键影响。

本解读由 DeepSeek AI 自动生成，仅供参考。

AIJon: Automated Generation of Annotations for Fuzzing ​

基本信息 ​

问题的初衷（Why - 为什么要做这个研究） ​

问题的解决（What - 提出了什么方案） ​

技术方法详解（How - 怎么实现的） ​

系统架构图 ​

方法流程图 ​

核心公式与算法 ​

应用场景（Where - 在哪落地） ​

具体技术细节示例（How in Action - 算法如何执行） ​

实验结果（Results - 效果如何） ​

实验结果可视化 ​

优势与不足 ​

相关工作 ​

未来研究方向 ​

一句话总结 ​