NSFuzz: Towards Eficient and State-Aware Network Service Fuzzing

作为负责通信的重要组成部分，网络服务是安全的关键，因此发现其中的漏洞至关重要。模糊法是目前最流行的软件漏洞发现技术之一，由于其高有效性和低误报率而被广泛采用。然而，现有的覆盖引导型模糊测试主要针对无状态的本地应用程序，而对有状态的网络服务则没有进行充分的探索。最近，一些针对网络服务的模糊器被提出来，但有一定的局限性，例如，状态表示不充分或不准确以及测试效率低。在本文中，我们提出了一种新的针对有状态网络服务的模糊测试方案NSF。具体来说，我们研究了网络服务程序的典型实现，并确定了它们如何表示状态和与客户交互。因此，我们提出了（1）一种基于程序变量的状态表示方案和（2）一种有效的交互同步机制来提高模糊处理的效率。我们已经实现了NSFuzz的原型，它使用静态分析和注释API来识别服务中的同步点和状态变量，然后实现快速的I/O同步和准确的服务状态跟踪，通过轻量级的编译时工具来进行有效的状态感知模糊测试。评估结果显示，与其他网络服务模糊器（包括AFLnet和StateAFL）相比，我们的解决方案NSFuzz可以在模糊过程中推断出更准确的状态模型，并将模糊处理的吞吐量提高了200倍。此外，NSFuzz可以提高25%的代码覆盖率，并在更短的时间内触发更多的崩溃。此外，我们还对目标服务的最新版本进行了摸索，发现了8个零日漏洞，这些漏洞都是由NSFuzz发现的。

1 介绍

挑战：

然而，传统的灰箱模糊化方法不能直接很好地应用于网络服务，这是由于两个主要挑战 (1)服务状态表示。 大多数现有的灰盒模糊器主要是为无状态的本地应用程序设计的。对于基于协议的网络服务，一方面，当接收到相同的输入消息时，网络服务根据当前的会话状态做出不同的响应；另一方面，大多数bug是有状态的，只能由一系列特定的消息触发。因此，不知道服务状态的灰箱模糊解不能获得完整的反馈，这将误导遗传算法的进化方向。(2)测试效率。 网络服务程序通常被设计为C/S架构，动作通常涉及多个网络I/O交互，这意味着一个有效的fuzzer需要与目标服务进行多次交互。因此，fuzzers应该及时将每个消息发送给目标服务，以节省测试时间和提高测试吞吐量。

现状

值得注意的是，最近的一些研究工作已经为网络服务引入了灰盒模糊化。AFLnet [39]首先提出了针对有状态协议实现的灰盒模糊化解决方案。它从响应消息中提取响应代码来表示服务状态，然后使用响应代码序列来推断协议实现的状态模型，并进一步利用推断的模型来指导模糊化过程。StateAFL [33]试图使用程序的内存状态来表示服务状态，然后通过检测被测服务来执行状态收集和状态模型推断。在每一轮网络交互中，StateAFL将程序变量转储到一个分析队列中，并执行执行后分析来更新状态模型。

问题

然而，现有的作品仍然面临着上述两个挑战。至于状态表示挑战，AFLnet提出的响应代码方案假设协议将在响应消息中嵌入特殊代码，但情况并非总是如此。此外，如StateAFL中所指出的，由响应代码提供的网络服务状态的指示是不健壮的。为了克服基于响应代码的方法的局限性，StateAFL使用程序在内存中的状态来表示服务状态。但是由于程序内存状态的复杂性，将这样的内容直接映射到服务状态是不现实的。因此，StateAFL使用对位置敏感的散列来近似状态映射，引入了不太精确的状态表示。SGFuzz [18]提出用状态变量来表示网络服务的状态。它自动识别所谓的状态变量，并使用它们来构建状态转移树(STT ),该树被认为代表服务程序的探索状态空间。但是，SGFuzz可能会在状态表示中引入误报，因为SGFuzz直接使用枚举类型的变量作为状态变量，而不进行过滤。关于测试效率的挑战，由于没有明确的信号表明SUT的消息处理，AFLnet和StateAFL都使用固定的定时器来控制fuzzer向SUT发送消息，但是定时器的时间窗口要么太短(在这种情况下SUT会错过fuzzer发送的消息)，要么太长(在这种情况下fuzzer会浪费太多时间等待)。此外，StateAFL需要对状态序列收集和状态模型推断进行执行后分析，这引入了额外的运行时开销，并进一步降低了测试吞吐量。

本文工作

在本文中，我们提出了NSFuzz，一种有效的状态感知灰盒模糊解决方案。我们研究了许多有代表性的网络服务程序，以了解它们的典型实现。我们发现这样的程序总是使用程序变量来直接描述服务状态。此外，我们还注意到网络服务总是带有一个网络事件循环，它负责连续处理传入的消息。因此，为了解决第一个挑战，我们提出了一个轻量级的基于变量的状态表示方案来表示网络服务状态。 我们将表示服务状态的变量称为状态变量。由于状态变量包含了服务程序的内在语义信息，基于变量的状态表示方案能够以更高的准确性和可解释性来表示服务状态。至于第二个挑战，网络服务的内在事件循环可以产生适当的信号反馈，从而在网络服务和fuzzer之间实现event loop同步。我们将事件循环中可以产生信号反馈的位置称为I/O同步点，因为它负责同步I/O与引信的交互。基于信号的同步可以促进模糊器发送新消息以减少等待时间开销。 此外，这种机制还可以使fuzzer能够收集状态转换序列并主动推断状态模型，从而避免StateAFL使用的繁重的执行后分析。
具体来说，我们使用静态分析和注释API从SUT的源代码中识别I/O同步点和状态变量。然后，我们进行轻量级编译时检测，以使服务具有基于信号的快速I/O同步和基于变量的服务状态跟踪功能。最后，我们使用插装的目标服务来执行有效的状态感知网络服务模糊化。 目前，我们已经实现了NSFuzz的原型。
评估结果表明，NSFuzz能够在模糊化过程中推断出更加准确的状态模型，并且具有明显高于AFLnet和StateAFL的模糊化吞吐量。此外，NSFuzz可以达到更高的代码覆盖率，并在更短的时间内触发更多的崩溃。
综上所述，本文做出了以下贡献:
• 我们提出了一种基于变量的状态表示方案来表示网络服务的状态，并在模糊化过程中推断出更精确的状态模型。基于SUT的网络事件环设计了一种高效的I/O同步机制，为网络服务模糊化提供了更高的吞吐量。
• 我们提出了NSFuzz，一个有效的和状态感知的网络服务模糊化解决方案。我们使用静态分析和注释API来识别SUT中的同步点和状态变量，然后通过编译时工具为其提供信号反馈和状态反馈功能，以实现高效的状态感知模糊化。
• 我们已经实现了NSFuzz的原型，并在提供的几个真实网络服务上对其进行了评估
由ProfuzzBench[34].评估结果表明，NSFuzz可以推断出更准确的状态模型，并获得比最新网络模糊器更好的模糊吞吐量。因此，在大多数目标上，NSFuzz的总体模糊化效果优于其他解决方案，包括更高的代码覆盖率和在更短的时间内触发更多的崩溃。除此之外，NSFuzz在三个流行的网络服务的最新版本中发现了8个零日漏洞，这表明了它发现现实世界漏洞的能力。

2 相关著作

2.1 黑盒网络模糊化
2.2 灰箱网络模糊化
2.3 程序状态模型推理

3 网络服务研究

4 方法学

4.1 概述设计

图一。NSFuzz的工作流程。它首先在源代码上使用静态分析和注释API来识别I/O同步点和状态变量。然后，它向目标网络服务发送指令，以启用信号反馈和状态跟踪。最后，NSFuzz执行快速I/O同步，并推断基于变量的服务状态模型，以实现高效的状态感知模糊循环。
1 描述了NSFuzz的工作流程。在高层次上，NSFuzz有四个主要组件:静态分析、注释API、编译时工具和模糊循环。首先，NSFuzz将网络服务源代码作为输入，并执行静态分析来识别潜在的网络事件循环(参见4.2.1)和状态变量(参见一节)4.2.2). 此外，NSFuzz引入了注释API，它允许用户从静态分析的潜在结果中进行选择，以准确地注释I/O同步点(参见4.3.1) 和状态变量(参见一节)4.3.2). 对于静态分析无法适配的目标，用户也可以手动分析目标服务的源代码，直接标注SUT的同步和状态信息。然后，NSFuzz使用注释信息的解析结果(参见4.3.3) 进行编译时检测(参见4.4), 使目标服务具有信号反馈和状态跟踪的能力。在fuzzing循环中，NSFuzz以初始种子为输入，在代码覆盖和状态模型的指导下进行种子选择和消息变异，生成测试用例。在测试用例执行期间，当请求消息被发送时，NSFuzz将等待来自SUT的反馈信号，以执行快速I/O同步(参见4.5.1) 以实现有效的服务模糊化。每次NSFuzz收到信号时，它都会跟踪基于变量的服务状态，并收集状态转换序列来更新状态模型(参见4.5.2), 从而执行状态感知模糊化(参见一节)4.5.3). NSFuzz会重复这个过程来查找程序崩溃，直到模糊循环停止。

4.2 静态分析

NSFuzz使用静态分析在被测服务中找到两种类型的信息。第一个是网络事件循环，它负责在服务处理阶段处理传入的请求消息。第二个是代表程序实现中服务状态的关键状态变量。如中所述3.2, 网络事件循环是消息处理的自然指示器。因此，它可以在每次循环中向模糊器提供及时的反馈，以避免时间浪费。与基于响应码的状态表示方案相比，基于变量的状态表示方案能够更真实地反映网络服务的状态，从而推断出更准确的状态模型。此外，与StateAFL需要执行后在线分析来识别状态变量不同，NSFuzz通过使用在线分析的预执行来提取状态变量，并在编译期间检测被测服务以实现实时状态映射。从而进一步提高起毛效率。

4.2.1 循环结构标识。事件循环最常见的实现是使用单个循环结构进行连续消息处理，循环结构的入口可以用作I/O同步点。识别这种循环结构的主要挑战是将它与网络服务程序中的其他循环区分开，因为在实现中可能存在各种循环。一个典型的例子是，在服务初始化阶段，许多服务可能使用文件I/O循环来读取配置。此外，事件循环本身也可能包含嵌套循环，这也给静态分析器准确识别目标循环带来了困难。因此，我们在服务处理阶段跟踪网络I/O操作，并通过回溯来区分外部循环以解决问题。
首先，我们在与输入相关的系统调用上设置断点，比如read、recv、recvmsg等。当网络服务完成初始化并进入服务处理阶段时。然后，fuzzer建立到SUT的套接字连接，并发送探测消息。当断点被命中时，SUT保存函数调用堆栈的回溯。最后，我们将回溯作为静态分析器的辅助输入来识别目标循环结构。静态分析器首先将服务中包含I/O操作的所有循环记录为候选循环，并从底部扫描回溯调用堆栈(例如libc_start_main)以匹配包含I/O循环的第一个函数(外部的那个)，然后将其视为目标循环。这是因为在服务处理阶段，回溯仅包含事件循环中的调用堆栈，匹配包含I/O循环的外部函数也可以避免嵌套循环。NSFuzz将记录所标识的目标循环条目的位置，以供后续使用。

4.2.2 状态变量提取。在识别出SUT的循环结构后，静态分析器将提取状态变量。因为不是服务程序中的所有变量都可以用来表示服务状态，所以静态分析需要关注目标服务中的状态变量。因此，基于我们对网络服务实现的观察和我们对服务程序中状态变量的特征的分析，我们使用以下启发式规则来过滤静态分析器的识别结果，以提取更可能的状态变量。
• 网络服务中与状态变量相关的操作总是在网络事件循环中执行。因此，静态分析器仅在网络事件循环中执行分析，以缩小分析范围。
• 网络服务中的状态变量总是在中读取(用于状态检查)或写入(用于状态更新)
循环或消息处理程序。因此，静态分析器只提取加载和存储的变量。
• 网络服务的状态变量往往是数据结构中的全局枚举变量或整数成员变量，它们只是被赋以常数来表示一个特定的状态。因此，静态分析器只保留全局整数变量或用户定义的结构成员，在它们的存储操作中分配常量值。
基于上述启发式规则，静态分析器可以提取SUT中的潜在状态变量。

4.3 注释API

除了自动静态分析之外，NSFuzz还为用户提供了注释API，用于手动注释SUT中的I/O同步点和状态变量。对于通过多级循环或事件驱动库实现事件循环的服务，超出了静态分析器的能力，用户可以使用注释API直接准确地注释SUT的I/O同步点，从而使更多的网络服务目标适应NSFuzz解决方案，以实现高效的模糊化。另一方面，当提取SUT中的状态变量时，由于缺少服务运行时信息，静态分析器仍然可能遇到误报。因此，这样的注释API可以用来改进状态变量的自动分析结果，以帮助建立更精确的状态模型。此外，用户可以在模糊化过程中只标注他们想要跟踪的状态变量，以实现不同粒度的状态模型推理。

4.3.1 同步点注释。NSFuzz提供的同步点注释API使用户能够在SUT. Listing的源代码中定位和注释I/O同步点2 展示了一个使用API _NSFUZZ_SYNC来注释真实网络服务程序中的I/O同步点的示例。
在清单所示的例子中2, I/O同步点注释API放在事件循环的入口。每次服务访问这个点时，它都会发送一个信号反馈来指示fuzzer服务已经处理了前面的消息。此外，对于具有多级或事件驱动型事件循环的服务程序，用户也可以使用该API来注释源代码中的多个适当位置。具体来说，当有多个同步点时，用户可以使用这个API来指定同步点，以确保每条消息只发送一个同步信号。对于没有检测到循环的对象，用户也可以使用这个API来指定同步点。在这种情况下，状态变量也使用注释API进行注释(参见。4.3.2). 这样，SUT可以确保在每个请求消息被处理之后，同步信号反馈总是被发送，从而执行快速I/O同步以实现高效的模糊化。

4.3.2 状态变量注释。NSFuzz提供的状态变量注释API使用户能够手工注释关键的状态变量，这些变量用于表示SUT. Listing中的服务状态3 展示了在实际网络服务程序中使用_NSFUZZ_STATE API注释两种状态变量的示例。
在网络服务程序中，状态变量注释API可用于在全局变量的定义和结构成员变量的声明中注释状态变量(列表3). 这种基于API的人工标注可以让用户避免静态分析中的误报带来的冗余变量，并在模糊化过程中构建一个适当粒度的状态模型。
4.3.3 注释解析。完成手动注释后，NSFuzz将解析这些注释以生成用于检测的输出。具体来说，对于代码中用_NSFUZZ_SYNC标记的所有I/O同步点，注释解析引擎会输出源代码中I/O同步点的位置。对于所有用_NSFUZZ_STATE标记的变量，注释解析引擎会为每个变量分配一个惟一的字符串ID，并输出ID列表。

4.4 编译时检测

在通过静态分析和注释API获得I/O同步点和状态变量列表之后，NSFuzz在编译时对目标网络服务执行两种类型的检测。一方面，NSFuzz在I/O同步点插入raise (SIGSTOP)语句。因此，SUT可以在处理完每个请求消息后向模糊器发出信号反馈，以表明它已准备好接收下一个请求消息。另一方面，为了将服务状态实时传递给fuzzer引擎，NSFuzz检测每个状态变量的存储操作。每次写入任何状态变量时，服务都会使用新值来更新SUT和模糊器共享的状态相关内存中的相应项。为了区别于记录代码覆盖率的共享内存，我们将记录状态信息的共享内存表示为shared_state。具体的状态映射方法如下:
shared _ state[hash(var _ id)]= cur _ store _ val；(1)
NSFuzz散列每个状态变量的唯一字符串ID (var_id)并将散列结果用作索引，然后在相应区域中fuzzing期间用每个状态变量的新存储值更新shared_state。编译完成后，NSFuzz生成了插装程序，作为真正模糊化的最终测试服务。

4.5 模糊回路

在使用静态分析和注释API获得两种类型的信息并为目标服务提供工具之后，NSFuzz开始模糊测试中的工具服务。与传统的覆盖引导的灰箱fuzzer相比，NSFuzz引入了信号反馈来控制服务I/O交互，因此fuzzer还需要与插装服务协作，以实现测试用例执行过程中的快速I/O同步。此外，状态变量的存储操作处的插装使得NSFuzz还需要在适当的时间检查shared_state，并收集状态转换序列以帮助推断状态模型。
4.5.1 快速I/O同步。为了提高模糊化的效率，AFL引入了FORKSERVER来负责被测程序的fork创建和回收。由于AFLnet和StateAFL都是基于AFL实现的，它们都继承了AFL的FORKSERVER来进行网络服务模糊化。当它们执行一个测试用例时，首先通知FORKSERVER创建一个要fuzzed的流程，然后以手动指定的时间间隔依次发送每个请求消息，最后在服务结束后等待FORKSERVER通过通信管道写入执行结果。
NSFuzz实现NET_FORKSERVER配合被测服务的信号反馈，实现快速I/O同步，从而避免手动指定时间等待间隔。在这种情况下，每次NSFuzz的fuzzer发送请求消息时，它都会通过管道等待来自NET_FORKSERVER的反馈。

作为模糊化网络服务的父进程，NET_FORKSERVER直接等待被测服务发出的信号，根据信号类型判断目标是完成了一轮I/O交互还是刚刚崩溃，然后将这些信息传回模糊化器。数字2 展示了在NSFuzz框架中测试的fuzzer、NET_FORKSERVER和服务之间的I/O同步。
4.5.2 服务状态跟踪。每当fuzzer通过通信管道从NET_FORKSERVER接收到消息处理结果时，它都会计算shared_state缓冲区的hash。这个哈希可以用来表示SUT的当前状态，原因如下。如果消息导致状态转换，服务将更新某些状态变量的值，然后shared_state缓冲区也将立即更新。因此，在处理此消息后，fuzzer将获得一个shared_state缓冲区的哈希，该哈希与此消息之前的哈希不同。虽然在网络服务程序中可能有多个状态变量，但是不同的变量对应于由它们的唯一ID散列计算的不同索引。因此，每个状态变量的变化不会干扰其他变量。所有状态变量的当前值的组合代表服务的综合状态。因此，每当SUT的任何状态变量改变时，shared_state的散列值也将改变。数字3 显示了服务发生状态转换时shared_state的更新过程。
因此，模糊化器可以使用缓冲区的散列来收集状态转换序列，以便在每次同步后推断状态模型。与StateAFL在每个消息处理期间将所有变量值连续转储到分析队列并执行执行后分析来进行状态推断相比，NSFuzz使用shared_state哈希来更充分地表示状态。这可以充分利用基于变量的状态表示方案，从而实现更有效的状态收集。
4.5.3 状态感知模糊化。除了新的代码覆盖率，NSFuzz还将使用状态反馈信息来更新服务状态转换模型。然后NSFuzz会进行类似AFLnet的状态引导的种子选择和消息变异，进行网络服务模糊化。

5 评估

我们已经建造了NSFuzz的原型。NSFuzz的实现大概是4.5k行C/C++代码，100行左右Python脚本。具体来说，我们实现了静态分析器、注释解析引擎和基于LLVM的编译时插装11]框架，fuzzer引擎基于AFL net(2021年1月起修订版0f51f9e)实现。为了详细说明对NSFuzz的评估，我们进行了几个实验来回答以下研究问题:
**

• RQ1：NSFuzz的模糊测试能力： NSFuzz能否在模糊化过程中基于有效的I/O同步机制带来更高的模糊化效率？
• 问题2：NSFuzz推断出的状态模型的准确性： 在模糊处理过程中，NSFuzz能否基于基于变量的状态表示方案推断出相对更准确的状态模型？
• RQ3：NSFuzz的整体效果：NSFuzz的状态感知模糊法： NSFuzz能否取得比其他现有方法更好的整体模糊结果？
• RQ4：NSFuzz的状态空间探索能力： NSFuzz能否比其他方法获得更高的状态空间覆盖率？
• RQ5：NSFuzz的现实世界错误识别能力： NSFuzz能否持续地发现现实世界中的协议服务的错误？**

5.1 实验设置

我们从网络协议fuzzing基准中选择fuzzing目标，即ProFuzzBench [34]，来评价NSFuzz。ProFuzzBench是有状态协议模糊化的基准。它包含了来自10个网络协议(包括FTP、SMTP、SIP等)的13个网络服务实现。)，涵盖了基于TCP和UDP的各种网络协议，全部用C/C++实现。此外，ProFuzzBench为这些网络服务应用必要的补丁(如去随机化)以确保模糊化评估的可靠性。为了进行更全面的评估，我们选择了ProFuzzBench中的所有13个网络服务作为评估目标。桌子1 显示目标服务的信息。
为了进行比较，我们选择了两个最先进的灰箱网络模糊器，AFLnet1(从2021年1月起恢复)和StateAFL2 (2021年10月起恢复c1b2aee)和AFL的另一个网络版AFLnwe3 38作为基线模糊器来评估NSFuzz。AFLnet使用消息响应代码来表示服务状态，并推导出状态模型，然后在模糊循环中基于该模型进行状态引导模糊。StateAFL在网络I/O循环期间收集已更改的变量。然后提取状态变量并通过后执行分析推断状态模型。AFLnwe是AFLnet的作者提出的另一个网络服务fuzzer。它只是将文件I/O接口从原来的AFL改为基于socket的网络I/O，实现网络服务模糊化。为了评估NSFuzz的各个组件在模糊化过程中的效果，我们还提出了一个模糊化器NSFuzz-V，它只启用了基于变量的状态表示方案，而没有I/O同步机制。然后，我们对模糊化实验的总体效率评估(RQ3)和状态空间覆盖评估(RQ4)进行了消融研究。
在评估期间，所有实验都在同一台测试机上运行，该测试机包含128个英特尔至强白金8358 CPUs和384GB内存以及SSD磁盘。我们在不同的docker容器中设置了每个带有fuzzer的目标服务，并使用相同的计算资源进行实验评估。我们用不同的模糊器对每个目标服务进行了24小时的模糊处理，每次重复4次，总共进行了6240个CPU小时的模糊评估。

5.6 真实世界缺陷发现评估(RQ5)

为了评估NSFuzz在现实世界的网络协议服务中发现漏洞的能力，我们部署了一个长期的模糊化活动来寻找13个协议的最新版本中的漏洞。我们已经运行fuzzing活动大约两个星期了，并在2个目标服务中发现了几个崩溃。详细信息如表所示9.

6 讨论

6.1 状态空间探索

为了在模糊化过程中充分探索目标的状态空间，我们不仅需要一个更合理的状态表示，还需要更好地利用状态反馈来指导模糊化器。目前，我们使用状态变量来表示被测服务的状态信息，我们认为这样更符合服务状态的本质含义。然而，我们还没有深入研究如何使用状态反馈信息来指导fuzzer更好地变异测试用例。当前的突变程序遵循AFLnet的方法。对于每一轮fuzzing，AFLnet都会选择一个可以将服务引向有趣状态的种子，然后在到达目标状态后对消息进行变异，以尝试触发更多未被发现的状态和边缘。目前，NSFuzz仍然面临着不足的指导机制来充分探索被测服务的状态空间，这为未来的工作留下了重要的方向。

6.2 快照模糊

SnapFuzz [15]是目前最先进的网络协议模糊工具之一。Snapfuzz要解决的问题与NSFuzz有交集，即加速网络协议服务fuzzing。SnapFuzz和NSFuzz的本质思想是一样的，都是为了消除不必要的等待时间。NSFuzz使用静态分析和手动注释相结合的方式向fuzzer发送被测服务的同步信号，以显著减少时间浪费。另一方面，SnapFuzz基于一组用于加速的二进制重写解决方案。这个健壮的二进制重写子系统动态地拦截系统调用，然后将它们重定向到定制的处理函数。基于二进制重写，SanpFuzz实现了几个加速模糊化的方案。
SnapFuzz的一些解决方案与NSFuzz不兼容。例如，NSFuzz使用同步点技术向fuzzing工具发送消息，而SnapFuzz则提出了一个定制的SnapFuzz协议来跟踪目标的后续操作，并通知fuzzer。SnapFuzz协议包括一组规则，这些规则定义了fuzzer和被测程序之间的交互流，以避免手动设置时间延迟的需要。此外，SnapFuzz还使用内存文件系统来避免编写清理脚本，并提出了一种自动识别可能分叉点的方法。然而，由于缺少自定义SnapFuzz协议的使用，这些技术仍然不能直接应用于NSFuzz的设计。

6.3 未来的工作

如第节所述6.1, 目前我们还没有深入研究如何更好地利用状态反馈信息来指导种子选择和变异过程。在未来，我们将探索如何使用状态空间覆盖来指导fuzzer在有状态目标上更有效地执行模糊测试。此外，由于协议通信期间的消息交换是高度格式化的，在接下来的步骤中，我们将研究如何实现更智能的格式感知消息变异以提高模糊化效率。

7 结论

本文分析了现有网络服务模糊器的测试效率和状态表示问题。根据我们对网络服务实现的研究，结合基于变量的状态表示方案和I/O同步机制，我们提出了一个高效的状态感知模糊化框架。然后，我们通过使用静态分析、注释API和轻量级编译时插装来实现NSFuzz的原型，以生成被测服务的信号反馈和状态跟踪，从而实现状态感知模糊化。最后，我们在ProFuzzBench的13个目标上对NSFuzz进行了评估，结果表明NSFuzz能够获得更高的模糊吞吐量，同时推断出相对更精确的状态模型来指导模糊。此外，NSFuzz可以达到更高的代码覆盖率并触发更多在模糊化过程中，崩溃的时间比其他网络模糊化器短。此外，NSFuzz可以不断地在现实世界的网络协议服务中发现漏洞，并且已经发现了8个零日漏洞。