Large Language Model guided Protocol Fuzzing

Ruijie Meng∗, Martin Mirchev∗, Marcel BÖhme†and Abhik Roychoudhury∗

∗National University of Singapore

MPI-SP and Monash University

引用

Meng R, Mirchev M, Böhme M, et al. Large language model guided protocol fuzzing[C]//Proceedings of the 31st Annual Network and Distributed System Security Symposium (NDSS). 2024.

论文：https://www.ndss-symposium.org/ndss-paper/large-language-model-guided-protocol-fuzzing/

仓库：https://github.com/ChatAFLndss/ChatAFL

摘要

在互联网领域中，协议实现（protocol implemention）是一种对安全要求极高的软件系统，这种系统的输入需要严格遵循特定的结构和顺序，输入格式通常以自然语言的格式记录在长达数百页的文档（RFC）中。但是在测试协议的过程中，因为没有机器可读的协议版本，所以很难自动生成符合所需结构和顺序的有效测试输入来进行测试。目前借助突变模糊测试（mutational fuzzing）可以通过变异一组记录下来的的消息序列进行稍微解决这个难题。然而，可用的种子集通常相当有限，很难覆盖所有的协议状态和输入结构。

本文探讨了如何与预训练的大语言模型（LLM，Large Language Model）系统地交互，这些模型已经学习了数百万页人类可读的协议规范来提取出机器可读的协议信息，这些信息可以在协议模糊测试中使用。作者利用LLMs对于协议的消息类型知识，通过生成消息序列与预测响应代码检验了LLMs在检测具有状态的协议实现的“状态”方面的能力。

基于这些结果，作者开发了一种LLM引导的协议模糊测试引擎，名为CHATAFL。CHATAFL为协议中的每个消息类型构建语法，然后通过与LLMs的交互来变异消息或预测消息序列中的下一条消息。作者对来自PROFUZZBENCH中的实际协议进行了实验，结果显示CHATAFL在提升状态覆盖和代码覆盖率方面效果显著。CHATAFL与目前最先进的模糊器AFLNET和NSFUZZ相比，CHATAFL分别比AFLNET和NSFUZZ多覆盖了47.60%和42.69%的状态转换（state translation），29.55%和25.75%的状态（state），以及分别多覆盖了5.81%和6.74%的代码。除此之外，CHATAFL在目前广泛使用的协议实现中发现了九个独特且以前未知的漏洞，而AFLNET和NSFUZZ只发现了其中的三个和四个。

1 引言

无论是在实际生产还是在科学研究层面，开发一种自动发现协议实现中的漏洞的工具都是具有意义的。从生产的角度来看，协议是每个直接或间接连接到互联网的软件系统中最容易受到攻击的组件。因此，协议是必须自动且持续摆脱安全漏洞的关键点。即使在最安全的软件系统中，一个简单代码执行漏洞也会使其可能受到恶意远程攻击的威胁。从研究的角度来看，协议实现构成了难以测试的有状态系统。相同的输入执行两次可能都会产生不同的输出。要在特定协议状态中找到漏洞，需要按正确的顺序发送正确的输入。然而，默认情况下，研究者既不知道这些消息的正确结构，也不知道它们的正确顺序。

基于变异的协议模糊测试（Mutation-based protocol fuzzing）通过对记录下来的消息序列进行模糊测试，降低了对机器可读的消息结构与顺序的依赖。简单的变异通常会保留所需的协议结构，同时足以使消息序列发生足够的变化以暴露错误。然而，基于变异的协议模糊器的效果受到记录的种子消息序列的质量和多样性的限制，并且简单变异也不能有效覆盖数量庞大的输入或状态空间。

本文探讨了使用大语言模型（LLMs）指导协议模糊测试过程的实用性。LLMs从互联网上的网站和文件中获取了大量的数据，目前已经能准确地回答很多领域的具体问题。像ChatGPT 4.0这样的LLMs也学习了自然语言协议规范。LLMs的最近巨大成功为研究者提供了开发协议模糊测试系统的机会，该系统将协议模糊器与LLM进行系统化交互，在此过程中，模糊器可以向LLM提出非常具体的任务。

作者将这种方法称为LLM引导的协议模糊测试，并提出了三个具体的组成部分。首先，模糊器使用LLM提取协议的机器可读语法，用于结构感知变异（structure-aware mutation）。其次，模糊器使用LLM增加了记录的消息序列中消息的多样性，这些消息序列被用作初始种子。最后，模糊器使用LLM打破了覆盖率平台期，作者向提示生成信息LLM来达到新的状态。作者在PROFUZZBENCH协议模糊测试基准中的所有基于文本的协议上进行了测试，结果显示了LLM引导方法的有效性：与基线（AFLNET）相比，CHATAFL多覆盖了约50%的状态转换，30%的状态和6%的代码。CHATAFL在与最先进的NSFUZZ相比也显示了类似的改进。在消融研究中，从基线开始，作者发现分别启用（i）语法提取、（ii）种子丰富化和（iii）覆盖平台处理，使得CHATAFL在24小时内达到的相同代码覆盖率的速度分别比基线快2.0倍、4.6倍和6.1倍。此外CHATAFL也能十分有效地发现协议实现中的关键安全问题。在实验中，CHATAFL发现了九个独立的以前未知的且广泛测试的协议实现中的漏洞。

综上，作者做出了以下贡献：

2 案例研究

为了探究LLMS帮助实现协议模糊测试的能力，作者进行了一次案例研究。作者选择了实时流媒体协议（RTSP），以及其实现LIVE555，这是来自PROFUZZBENCH的一部分。RTSP是一个应用层协议，用于控制具有实时特性的数据传输。LIVE555按照RFC 2326实现了RTSP，在娱乐和通信系统中充当流媒体服务器，用于管理流媒体服务器。PROFUZZBENCH是一个广泛使用的用于网络协议有状态模糊器的基准。因此，对LIVE555的研究结果将强烈表明LLM是否能够有效地引导协议模糊测试。

2.1 提取消息语法：质量和多样性

作者需要LLM提供关于消息结构（即语法）的机器可读信息，并评估生成的语法的质量以及相对于基准的消息类型的多样性。为了建立基准语法，作者阅读RFC 2326文档，并手动提取了相应的语法，图1显示了RTSP协议的状态机结构。最终，作者提取了RTSP协议特定的10种客户端请求的基准语法，每种请求包含大约2到5个头字段。图2显示了PLAY消息的语法。PLAY语法包括4个基本头字段：CSeq、User-Agent、Session和Range。

图1：RTSP协议的状态机结构

为了获取LLM对RTSP协议的分析语法，作者随机采样了50个来自LLM的回复，并将它们合并成一个答案集。如图:3所示，LLM为十种消息类型生成了语法。此外，作者还检查了LLM生成的语法质量。在生成的消息当中，LLM为大多数消息生成了与RFC中提取的基准语法完全相同的语法。这些发现证明了LLM生成高度准确的消息语法的能力。综上，LLM为所有类型的RTSP客户端请求的结构生成了机器可读信息。

图2：PLAY语法的结构

图3：LLM生成的消息类型

2.2 丰富种子语料库：多样性和有效性

作者需要LLM向给定的种子消息序列添加一个随机消息，并评估消息序列的多样性和有效性。在PROFUZZBENCH中，LIVE555的初始种子语料库仅包括10个基准语法中的4种客户端请求类型：DESCRIBE、SETUP、PLAY和TEARDOWN。其余6种客户端请求类型的缺失导致了RTSP状态机的一大部分未被探索。虽然模糊器可以生成缺失的六种客户端请求类型，但可能性很低。为验证这一观察结果，作者检查了由AFLNet和NSfuzz生成的种子，但没有生成这些缺失的消息类型中的任何一种。为了调查LLM丰富种子语料库的能力，作者要求LLM为每种客户端请求类型生成10条消息，共计100条客户端请求。随后验证了客户端请求是否被放置在给定客户端请求序列的适当位置上。

研究结果表明，LLM能够生成准确的消息并丰富初始种子。99%的收集到的客户端请求被放置在准确的位置。综上，作者开发了两种方法来提高LLM在提供额外上下文信息时纳入正确会话ID的能力。作者首先在提示中包含服务器的响应，然后请求LLM生成相同类型的消息。这时，生成的客户端请求将直接被服务器接受。此外，作者还尝试将会话ID加入到给定的客户端请求序列中，然后LLM也准确地将相同的值插入到这些消息中，并产生了正确的结果。这表明LLM能够生成准确的消息，并且具备丰富初始种子的能力。

2.3 引发有趣的状态转换

作者将消息交换与模糊器和协议实现之间的消息交换提供给LLM，并要求它返回一个会导致新状态的消息，并评估消息引发新状态的可能性。图4展示了结果。每个饼图展示了每个状态的结果。每个饼图中的每个部分代表了一个不同类型的客户端请求。灰色部分代表能够导致状态更改的客户端请求类型的百分比。橙色部分代表出现在适当状态中但不触发任何状态转换（因此没有状态更改）的消息类型。蓝色部分代表出现在不适当状态中且直接被服务器拒绝的类型。有81％、74％、89％和69％的客户端请求，分别可以引发到不同的状态转换。此外，大约有17％、16％、10％和30％的客户端请求仍然可以被服务器接受和处理，尽管它们不会触发状态更改。这些消息仍然有可能用于覆盖更多的代码分支，尽管它们未能覆盖更多的状态。这些结果进一步证明了LLM引导模糊的潜力，使其能够超越覆盖平台并探索各种状态转换。从LLM生成的客户端请求中，有69％到89％引发了到不同状态的转换，覆盖了每个单独状态的所有状态转换。

图4：LLM在每个状态下生成的下一种客户端请求类型。

3 方法实现

基于上文的研究结果，作者开发了LLM引导的协议模糊器(LLMPF)来解决现有基于变异的协议模糊(EMPF)的问题。

算法1指定了经典EMPF方法的一般过程。输入是待测试的协议服务器P0，对应的协议p，初始种子语料库C，以及总模糊时间T。输出包括最终种子语料库C和导致服务器崩溃的种子C%。对于LLMPF方法，作者加入灰色组件来增强EMPF的基线逻辑：（1）通过提示LLM提取语法（第2行）并利用语法指导模糊变异（第12-14行），（2）查询LLM以丰富初始种子（第3行），和（3）利用LLM的能力跨越覆盖平台（第4、19-21、26、30和32行）。

算法1：LLM引导的协议模糊测试算法框架

3.1 语法引导的变异

本节将介绍从LLM中提取语法的方法，然后利用语法指导结构感知变异。

1) 语法提取：在让模糊器可以要求LLM生成用于结构感知变异的语法之前，需要解决一个问题：如何为模糊器获取一个机器可读的语法？模糊器在单个机器上运行，并且只能解析预先确定的格式。并且LLM生成的响应通常是以自然语言结构呈现的，并且具有相当大的灵活性。如果模糊器要理解LLM的响应，LLM应该始终以预定格式回答模糊器的查询。另一种选择是手动将LLM的响应转换为所需的格式。然而，这种方法会损害模糊器的高自动化特性。因此，当前的问题是如何使LLM以所需的格式回答问题。

一个常见的方法是微调。这是因为LLM可以通过提供自然语言提示来执行特定任务，而无需额外的训练或硬编码。因此，模糊器提示LLM生成测试中的协议的消息语法。然而提示微调的范围相当广泛。为了使LLM生成可读的语法，作者采用了在提示工程领域内的情境少样本学习（in-context few-shot learning）。情境少样本学习作为微调模型的有效方法，通过少量期望输入和输出的示例来增强上下文。这使得LLM能够识别输入提示语法和输出模式。通过情境少样本学习，作者用一些示例提示LLM以所需的格式提取协议语法。

通过这些方法，模糊器能够有效地从LLM中获取各种协议的准确语法。图5中的模型输出展示了从LLM派生的RTSP语法的一部分。

图5：用于提取RTSP语法的模型提示和响应的示例

在开始模糊测试活动之前（参见概述中算法1的第2行），LLMPF方法与LLM进行交互，以获取语法。随后，这个语法被保存到语法语料库中，该语法语料库在整个活动过程中被用于结构感知的变异。这种设计能够最大程度减少与LLM的交互开销，同时确保最佳的模糊测试性能。

2) 基于语法的变异：使用从LLM提取的语法语料库，LLMPF对种子消息序列进行结构感知的变异。在先前的工作中，研究人员利用LLM生成给定输入的变体，通过利用其理解输入语法的能力。然而，由于交互开销的限制，限制了与LLM的交互频率。本文作者采取了不同的方式来让LLMPF利用提取的语法来指导变异。模糊器只提取一次语法，使其能够在整个模糊测试活动中应用语法。基于语法指导的变异方法如图7所示，它展示了对单个RTSP PLAY客户端请求进行变异的工作流程。如图，在面对PLAY客户端请求时，LLMPF首先将其与相应的语法进行匹配。为了加快匹配过程，将语法语料库保持为映射格式：G = {类型→语法}。这里，类型表示客户端请求的类型。LLMPF使用每个语法的第一行作为消息类型的标签。语法对应具体的消息语法。使用消息类型，LLMPF检索相应的语法。随后使用正则表达式（Regex）将消息中的每个头字段与语法进行匹配。在图6中，已识别的可变区域用蓝色突出显示。在变异过程中，LLMPF仅选择这些区域，确保消息保持有效格式。如果没有找到语法匹配，则考虑所有区域可变。为了保留模糊器探索一些边缘情况的能力，作者继续采用经典EMPF中的结构不可知变异方法（structure-unaware mutation），如算法1的第16行所示。尽管如此，LLMPF以更高的概率进行结构感知的变异，考虑到有效的消息具有更大的潜力来探索更大的状态空间。

图6：基于语法的突变的工作流程

3.2 丰富初始种子

案例研究显示LLM能够生成新消息并将它们插入到提供的消息序列中的适当位置（参见第III-B节），作者提出了丰富用于模糊测试的初始种子语料库的想法（算法1的第3行）。然而这个方法首先必须解决几个问题：(i) 如何生成携带正确上下文信息的新消息（例如，RTSP协议中的正确会话ID）？(ii) 如何最大程度地增加生成序列的多样性？(iii) 如何提示LLM生成给定种子消息序列的整个修改消息序列？

对于问题(i)，作者发现LLM可以从提供的消息序列中自动学习所需的上下文信息。例如，PROFUZZBENCH已经具有一些消息序列作为初始种子。这些初始种子包含了来自服务器的正确且充分的上下文信息。因此，在提示LLM时，作者加入了来自PROFUZZBENCH的初始种子，以便获取所需的上下文信息。

对于问题(ii)，模糊器确定了初始种子中缺少哪些类型的客户端请求，即LLM应该生成哪些类型的消息来丰富初始种子。前文已经获取了所有类型的客户端请求的语法；因此，识别初始种子中缺少的类型并不难。作者利用这些信息来维护一组消息类型：AllTypes = {messageType}，并且一个从语法到相应类型的映射：G2T = {grammar → type}。在检测缺失的消息类型时，首先利用在3.1节中获取的语法语料库G和语法到类型映射G2T来获取现有的消息类型并将它们维护到一个集合中（ExistingTypes）。因此，缺失的消息类型在补集中：MissingTypes = (AllTypes - ExistingTypes)。然后再指示LLM生成缺失的消息类型并将它们插入到初始种子中。

对于问题（iii），为了确保生成的消息序列的有效性，作者使用续写格式设计提示词（如“客户端请求的修改序列是：”）。获取到的回复可以直接用作种子输入。

3.3 跨越覆盖平台

有状态的模糊器很难探索未知的状态。以图1的RTSP状态机为例，假设服务器在接受了一系列客户端请求之后当前处于READY状态。如果服务器打算过渡到不同的状态（例如PLAY或RECORD状态），则客户端必须发送相应的PLAY或RECORD请求。在模糊测试设计中，模糊器扮演客户端的角色。虽然模糊器具有生成诱发状态转换的消息的能力，但它需要探索大量的种子才能完成状态转换，甚至它可能无法生成适当的消息顺序以覆盖所需的状态转换。所以，有很大一部分的状态是无法被探索到的，但是为了完全覆盖有状态的服务器，就需要探索其他未被覆盖的状态，但这对目前的有状态的模糊器来说实在太过困难。

本文将模糊器无法探索到新的覆盖这种情况称为模糊器进入覆盖平台。在第2.3节的研究结果的启发下，作者利用LLM帮助模糊器跨越覆盖平台。当模糊器无法在给定的时间内生成合适的的种子时，就会发生这种情况。作者根据模糊器连续生成的无趣种子数量来量化这个持续时间。根据PlateauLen的值确定模糊器是否进入了覆盖平台。如果PlateauLen没有超过MaxPlateau，即覆盖平台的预定义最大长度（第11行），LLMPF会对消息进行变异。MaxPlateau的值由用户指定并提供给模糊器。然而，当PlateauLen超过MaxPlateau时，则认为模糊器已经进入了覆盖平台。在这种情况下，LLMPF将利用LLM来跨越覆盖平台（第19-21行）。为了实现这一点，作者利用LLM生成可能引发状态转换到其他状态的下一个合适的客户端请求。

作者向LLM提供了服务器和客户端之间的通信历史，即客户端请求和相应的服务器响应。为了确保LLM生成一个真实的消息而不是消息类型或描述，作者通过从初始种子语料库中提取任何消息来展示所需的格式。随后，LLM推断当前状态并生成下一个客户端请求M2'。这个请求充当原始M2的变异，并插入到消息序列M'中，然后发送到服务器。这些消息导致服务器转移到不同的状态，从而跨越了覆盖平台。

基于上述研究，作者实现了由LLM引导的协议模糊测试器CHATAFL，用于测试用C/ C++编写的协议。它维护一个推断状态机，并使用状态和代码反馈来指导模糊测试活动。当前状态的识别涉及解析来自服务器响应消息的响应代码。如果种子增加了状态或代码覆盖率，那么它就是有趣的。

4 实验评估

4.1 实验设置

为了评估大语言模型(LLM)在应对基于文本的网络协议的基于突变的协议模糊化挑战方面的效用，作者试图回答以下问题:

RQ.1状态覆盖。与基线相比，CHATAFL的状态覆盖率增加了多少?

RQ.2代码覆盖率。与基线相比，CHATAFL的代码覆盖率增加了多少?

RQ.3消融。每个组件对CHATAFL性能的影响是什么?

RQ.4 bug查找能力。CHATAFL能在目前广泛使用的协议中找到bug吗?

为了回答这些问题，作者按照推荐的实验设计进行模糊实验，实验对象为5个广泛使用的网络协议(即RTSP、FTP、SIP、SMTP和DAAP)。这些协议涵盖了PROFUZZBENCH中所有基于文本的网络协议，PROFUZZBENCH是一个被广泛于评估有状态协议模糊器的基准。对于每个协议，作者选择了适合在实际应用程序中使用的实现。

表1：实验评估中使用的主题程序

基线工具。作者选择了AFLNET和NSFUZZ-v作为基线工具。AFLNET是一个流行的开源、最先进、基于突变、代码和状态引导的协议模糊器。由于CHATAFL是基于AFLNET实现的，因此CHATAFL和AFLNET之间观察到的每一个差异都可以归跟于为实现LLM指导而进行的更改。NSFUZZ-v扩展了AFLNET，以更好地处理协议状态空间。它通过静态分析来识别状态变量，并使用状态变量值作为模糊器反馈来最大化状态空间的覆盖范围。

评估指标。为了评估CHATAFL与基线模糊器的有效性，需要测量协议模糊器覆盖协议状态空间和协议实现代码的程度。关键思想是协议模糊器不能在未覆盖的代码或状态中找到错误。然而，覆盖率只是fuzzer发现bug能力的一个代理度量。因此，作者加入了bug查找结果来补充覆盖率结果。

评估方法。为了评估代码覆盖率，作者使用基准测试平台PROFUZZBENCH[33]提供的自动化工具来测量分支覆盖率。为了评估状态空间的覆盖率，作者使用基准测试平台提供的自动工具测量不同状态的数量(状态覆盖率)和这些状态之间的转换数量(转换覆盖率)。为了识别错误，作者在地址消毒器(ASAN)下执行测试过的程序。CHATAFL存储崩溃消息序列，然后使用AFLNET提供的AFLNetreplay实用程序来重现崩溃并调试潜在原因。最后通过分析ASAN报告的堆栈跟踪来区分不同的bug。

4.2 RQ1 状态覆盖比较

表2 显示了CHATAFL 与两个基线 AFLNET 和 NSFUZZ-v 相比所覆盖的平均状态转换次数。为了量化 CHATAFL 相对基线的改进，作者报告了在 24 小时内达到的状态转换覆盖的改进百分比（Improv）、CHATAFL 在 24 小时内实现与基线相同状态转换覆盖所需时间的加速比（Speedup），以及 CHATAFL 的随机测试活动优于基线的概率（Vargha-Delaney 效果量度）。

表2：CHATAFL与AFLNET和NSFUZZ在10次24小时运行中的平均状态转换次数与两个基线相比，CHATAFL 执行了更多的状态转换，并且明显加速了状态探索过程。

CHATAFL执行的状态转换 比 AFLNET高 48%。，在 LIVE555 主题中，CHATAFL的状态转换次数比 AFLNET 高91%。此外，探索相同数量的状态转换时CHATAFL 平均比 AFLNET 快 48 倍。与 NSFUZZ 相比，CHATAFL 平均覆盖了更多的状态转换，探索相同数量的状态转换的速度也快16倍。此外Vargha-Delaney 效果量度的结果也表明 CHATAFL 在探索状态转换方面比 AFLNET 和 NSFUZZ 更加有效。

表 3 显示了CHATAFL 与两个基线 AFLNET 和 NSFUZZ-v 相比所覆盖的平均状态数以及相应的增幅百分比。CHATAFL 比 AFLNET 多覆盖了 30% 的状态，比 NSFUZZ 多覆盖了 26% 的状态。为了将覆盖的状态数量放在可达状态的总数的背景下，表 IV 的最后一列显示了任何工具在任何 10 次 24 小时运行中已经覆盖的状态总数。可以看到，CHATAFL 的平均模糊活动几乎覆盖了所有可达状态。只有在 Kamailio 中，CHATAFL 覆盖的可达状态空间比例较小（平均 17；最大为 20，23 个状态）。尽管如此，CHATAFL 在状态覆盖方面仍然胜过了基线。

表3：CHATAFL的平均状态数和与AFLNET和NSFUZZ相比的增幅。

就状态覆盖而言，CHATAFL 平均覆盖的状态转换次数比 AFLNET 和 NSFUZZ 多 48% 和 43%，分别比基线快了 48 倍和 16 倍。此外，CHATAFL 还探索了比 AFLNET 和 NSFUZZ 更大比例的可达状态空间。

4.3 RQ2 代码覆盖比较

表4显示了 CHATAFL 和基线 AFLNET 以及 NSFUZZ 在 10 次 24 小时的模糊测试活动中所达到的平均分支覆盖率。为了量化 CHATAFL 相对于基线的改进，作者报告了在 24 小时内分支覆盖率的增幅百分比（Improv）、CHATAFL 在 24 小时内实现与基线相同分支覆盖率所需时间的加速比（Speed-up），以及 CHATAFL 的随机测试活动优于基线的概率。

表4：CHATAFL、AFLNET 以及 NSFUZZ 在 10 次 24 小时的模糊测试平均分支覆盖率

正如表中所示，对于所有主题，CHATAFL 覆盖的分支比两个基线都多。CHATAFL 比 AFLNET 多覆盖了 5.8% 的分支，范围从 2.4% 到 8.0% 不等。与 NSFUZZ 相比，CHATAFL 覆盖了多出 6.7% 的分支。此外，CHATAFL达到相同数量的分支覆盖的速度比 AFLNET 快 6 倍，比 NSFUZZ 快10倍。对于所有协议实现，Vargha-Delaney 效果量度大于0.70 表明 CHATAFL 在代码覆盖方面比两个基线都具有显著优势。

就代码覆盖而言，平均而言，CHATAFL 比 AFLNET 和 NSFUZZ 分别多覆盖了 5.8% 和 6.7% 的分支。此外，CHATAFL 达到相同数量的分支覆盖比 AFLNET 和 NSFUZZ 分别快了6倍和10倍。

4.4 RQ3 消融研究

CHATAFL实现了三种策略与LLM交互来解决协议模糊测试的问题：基于语法的变异、丰富初始种子、跨越覆盖平台。为了评估每种策略对覆盖率增加的贡献，作者进行了消融研究。为此，作者开发了四种工具：CL0: AFLNET，即所有策略均已禁用， CL1: AFLNET加上基于语法的变异（SA）， CL2: AFLNET加上基于语法的变异（SA）和丰富的初始种子（SB），以及CL3: AFLNET加上所有策略（SA + SB + SC），即CHATAFL。

表5 展示了分支覆盖率结果（改进、加速和 Vargha-Delaney 效果量度）。例如，对于 ProFTPD，配置 CL3（即 CHATAFL）比基线配置 CL0（即 AFLNET）的分支覆盖率增加了 8%。两个相邻配置之间的改进差异（以括号表示）量化了启用的策略的影响。例如，对于 ProFTPD，配置 CL2 仅实现了 5.3% 的改进，比 CL3 少了 2.7 个百分点（pp），表明了从 CL2 到 CL3 启用的策略 SC 的有效性。

表5：分别启用策略的覆盖率结果

总体而言。所有策略都对分支覆盖率的提高做出了贡献，没有任何策略对分支覆盖率产生了负面影响。具体而言，CL1 相比 CL0 平均增加了 3.04% 的分支覆盖率。CL2平均增加了 3.9%，而 CL3平均增加了5.9%。此外，CL1 达到相同的分支覆盖率比 CL0 快 2 倍，CL2 比 CL0 快 5 倍，而 CL3 则快6倍。

4.5 RQ4 发现新的漏洞

作者最后评估了CHATAFL的效用，检查它是否能够在程序中发现零日漏洞。为此，作者在项目的最新版本上使用了CHATAFL，在24小时内运行了10次重复实验。在实验过程中，CHATAFL展现了优异的结果，如表VII 所示。

CHATAFL共发现了九个独特且以前未知的漏洞，尽管AFLNET和NSFUZZ进行了大量测试。这些漏洞在六个测试实现中发现，并涵盖各种类型的内存漏洞，包括使用后释放、缓冲区溢出和内存泄漏。此外，这些漏洞具有潜在的安全影响，可能导致远程代码执行或内存泄漏。在这9个漏洞中，有7个已被开发人员确认，其中3个已经在提交论文时修复了。

作者利用AFLNET和NSFUZZ来检测这9个漏洞。AFLNET和NSFUZZ配置为使用相同的主题版本运行相同持续时间（即24小时内的10次重复），与CHATAFL相同。然而，AFLNET只能发现其中三个，而NSFUZZ则能够发现其中四个。此外，AFLNET和NSFUZZ没有发现任何其他漏洞。

5 总结

由于协议的动态和交互性质，协议模糊测试确实面临这一些难题。与文件处理应用程序不同，文件处理应用程序的输入是静态文件，而协议涉及系统与环境之间持续的交互，因此很难发现问题。其中一个难点在于生成复杂的有效事件序列，这能帮助探索导致崩溃的深层行为。此外，协议是有状态的，这也隐含着在模糊测试过程中需要即时状态推断的挑战（因为并非每个动作在每个状态下都可用），并且模糊测试的有效性在很大程度上取决于初始种子的质量，因为它们构成了模糊测试生成的基础。

在这项工作中，作者展示了对于具有公开可用RFC的协议，大语言模型在丰富初始种子、启用结构感知变异和帮助状态推断方面是有效的。作者在广泛使用的PROFUZZBENCH套件中评估了CHATAFL，得到了优异的结果：与基准工具相比，CHATAFL在更短的时间内覆盖了更多的代码并了更大的状态空间。此外，CHATAFL发现了9个零日漏洞，而基准工具只探索发现了其中的3个或4个。

转述：李顺