概括整理协议fuzz相关的工具，针对其实现原理和过程进行总结，分析各工具优势和不足，进行横向和纵向的对比。
因为有些论文工具暂时没有包括进来，所以会长期更新完善，争取覆盖掉所有的主流协议fuzz工具。而且针对论文性质的工具，后续会出论文解读的详细内容，该文章中只做工具的整理。

source：https://github.com/MozillaSecurity/peach

​ https://github.com/asudhak/peachfuzz-code

peach是第一款综合的遵守MIT开源许可的fuzz框架，包括数据模型（数据类型、变异器接口等）、状态模型（数据模型接口、状态、动作-输入输出等）、代理（本地调试器和网络监视器）、测试引擎（代理接口、状态模型接口、Publisher、日志记录等）等，其中创建fuzzer由XML语言实现。支持对文件格式、ActiveX、网络协议、API等进行fuzz测试。peach属于基于生成的fuzz工具，使用peach进行fuzz工作的关键是编写peach pit配置文件。

peach首发于2004年，起初使用python开发；2013年发布peach3，转用C#开发。工具开发时间较久，目前已停止维护。

peach框架的体系结构可以简化如下：

对以上各部分做简要说明：

目前官方仓库已清空所有release，所以目前只能使用网上公开的版本。在后续的测试中我们使用Windows版本，其他系统下的使用基本相同。

在Windows下使用peach3需要预先安装Microsoft.NET4运行时和windbg调试工具。在Windows下，解压完成压缩包后，直接使用即可：

使用peach进行fuzz的主要步骤如下：

我们将在后续的样例中详细介绍完整的实战使用过程。

Peach 中定义数据的文件称为 Peach pit file，文件格式为 xml，可以理解成 Peach 根据这个 xml 模板来生成对应的数据进行 fuzz。一个 pit 文件的基本构成如下：

整个文件被<Peach></Peach>大标签包裹；文件中的第二级标签包括 Include 、 DataModel、SatateModel 、Agent、 Test、 Run 总计 6 种；

Include： 包含的外部文件，其中 defaults.xml 和 PeachTypes.xml 是必须的，这俩文件中包含 Peach 的基本方法、类、数据类型等。引用被包含的 Pit 文件时， 使用名称空间前缀和冒号的格式来命名，格式为 name:DataMpdel ，如下所示：

说明： ns，必须，名称空间前缀；src，必须，源码 URL，使用 “file: ” 前缀来命名文件名。

DataModel 用于定义数据结构，标签下还可以有若干级、若干种下级标签。使用子标签可以容易地定义数据类型、大小、数据块之间的关系、CRC 校验和等，也可以定义多个 DataModel ，多个 DataModel 之间可以存在关系也可以不存在。 pit 文件中至少包含 一个 DataModel 元素，其描述的数据包括类型信息、关系信息（大小、数目、偏移）和其他让 fuzzer 执行智能变异的信息。

属性：

子元素

DataModel 中可以包含的子元素有：Block、Choice、Custom、Flag、Flags、Number、Padding、String、XmlAttribute、XmlElement、Relation、Fixup、Transformer、Placement

一个 DataModel 简单的例子如下：

上面例子中，第二个 DataModel 会填充第一个的相关内容，然后进行输出。

StateModel 用于定义测试的逻辑，本质上相当于一个状态机，下级标签包括 State ，每个 State 中又可以包含若干个 Action 。State 表示一个状态，不同的 State 之间可以根据一些判断进行跳转，Action 用于执行打开文件，发送数据包之类的命令，Action 是发送命令给 Publisher 的一种主要方式，它能发送输出，接收输入或打开一个连接。

一个 SateModel 简单的例子如下：

Test 指定使用哪个 Agent 、StateModel 以及发送数据的方法等；

一个常见的 Test 如下：

Run ，指定当前这次 Fuzz 使用哪个 Test 。

Peach 3 的变异器包括元素增、删、改、交换、逐位、双字等。

部分支持的变异器列表如下：

Peach 会输出 fuzz 的目标、使用的变异器、使用的变异的数据等等：

在 Peach 的可执行文件的同级目录下的 log.txt 文件夹中会保存运行日志：

搭建一个简易的 cms 来实践对 http 协议的 fuzz。

按照源码的官方文档搭建即可。

我们使用 Burp 抓一下管理端登录流量：

然后以此请求为基础，开发 pit 文件如下：

我们直接开始运行 Peach 即可：

因为只是说明样例，所以并没有产生实际的 crash 。我们可以在终端和 wireshark 中看到每次的 fuzz 的详细信息：

每次的 response 大部分都是 400 ，说明是没有意义的，我们需要对 pit 文件进行更精确的定制才有可能发现漏洞。

Peach 的核心是 pit 文件的高度定制化，使用者需要根据自己的实际需求进行 pit 文件开发，这种开发越精确，fuzz 的成功率越高。其 fuzz 对象可以是文件、协议等，这需要使用者对文件格式、协议格式十分熟悉，才能写出高质量的 pit 文件。所以，该工具的思路比工具本身更重要。

写在前面

由于 Sulley 在多年之前已经停止维护，且其继承者为后续将介绍的 BooFuzz，所以我们此处只对其原理等理论知识做说明，不再进行实践，详细的实践内容我们会在 BooFuzz 工具中进行展开测试。

Sulley 是一个可开发的 fuzzer 和多个可扩展组件组成的 fuzz 框架，其相对当时其他工具的优势是简化了数据传输、表示和目标监控。其几个显著特点为：

Sulley 的安装可以参考其官方 wiki（Windows） ：https://github.com/OpenRCE/sulley/wiki/Windows-Installation。对于 *nix 平台下的安装，官方至今未发布安装流程，估计此生无缘了。

Sulley 的总体用法分解如下：

这里给出 Sulley 的使用手册，感兴趣的小伙伴可自行翻阅：Sulley使用手册，其中对上面提到的概念、原理和流程均有详细的介绍。

Sulley 的核心是对请求的拆解，然后链接成 session，本质上与 Peach 一样，需要使用者明确 fuzz 的目标和需求，根据实际情况进行定制。

source：https://github.com/aflnet/aflnet

AFLNet是一款灰盒协议fuzz工具，采用了代码覆盖率反馈、种子变异以及状态反馈等技术。

与传统的基于生成的协议fuzz工具，它采用了server和client之间的通信消息数据作为种子，无需任何的协议规范。本质上是模拟一个client来发送一系列消息到server，并保留可以触发新的代码执行路径或者响应状态的变异数据。

AFLNet使用server端的响应码来识别消息序列触发的不同状态，根据这种反馈，AFLNet可以尽可能得向有效的状态区域靠近。

system：Ubuntu 20.04 64-bit

dependencies：clang, graphviz-dev

（对于环境要求，只要支持AFL和graphviz工具即可，对版本没有特殊要求。）

下载源码，并编译，最后设置环境变量：

样例：

选项说明：

Fuzzing Live555流媒体服务器

Live555是一个为流媒体提供解决方案的跨平台的C++开源项目，它实现了标准流媒体传输，是一个为流媒体提供解决方案的跨平台的C++开源项目，实现了对标准流媒体传输协议如RTP/RTCP、RTSP、SIP等的支持。

Live555实现了对多种音视频编码格式的音视频数据的流化、接收和处理等支持，包括MPEG、H.263+ 、DV、JPEG视频和多种音频编码。同时由于良好的设计，Live555非常容易扩展对其他格式的支持。Live555已经被用于多款播放器的流媒体播放功能的实现，如VLC(VideoLan)、MPlayer。

为了展示fuzz成果，这里使用的Live555为2018年的一个旧版本，在这个版本中，AFLNet发现了4个漏洞，其中2个是0day。Live555的编译和安装如下：

在上述命令中，使用了一个patch来使得目标更容易被fuzz。patch文件的主要功能是设置编译器为afl-clang-fast\fast++以实现覆盖反馈：

禁用Live555中的随机会话id生成：

这里的随机会话id主要是在原生的Live555版本中，会为每个连接生成一个session id，该id会用在从以连接的client发送的后续的request中，如果没有合法的id则会被server拒绝，这样就会导致fuzz过程中即使是相同的消息序列也会产生不同的执行路径，不同部分主要是session id部分的更改，所以这里就直接硬编码session id来消除这种干扰变量。

Live555编译成功后，在testProgs目录下会看到server端testOnDemandRTSPServer和client端testRTSPClient。可以执行以下命令进行测试：

client能成功发送reqeust并接收从server发来的数据即可。

AFLNet使用发送的消息序列作为种子输入，所以需要先获取消息序列。基本方法就是首先捕获一些testRTSPClient和server之间的交互数据作为种子输入，这里以请求一个wav格式的音频文件为例：

首先启动server：

使用tcpdump捕获8554端口的所有流量并保存到pcap文件：

运行client发起请求：

交互完成后，停下tcpdump，对抓到的流量进行分析。直接跟踪TCP流查看所有发往server的数据：

这就是在整个的交互过程中，client发出的所有的request消息序列，将它作为种子即可（需要使用的是原始数据二进制格式）。种子路径为$AFLNET/tutorials/live555/in-rtsp：

触发crash的消息序列的测试用例会放在crashes或replayable-hangs目录中。在fuzz过程中，AFLNet状态机会不断推断server的已实现状态，并相应地更新.dot文件，可以查看该文件来监控AFLNet在协议推理过程中的情况。

（备注：不做任何修改的话，这个fuzz速度慢到令人发指，具体原因暂时还未深入研究。）

AFLNet自带重现工具：afl-replay

（备注：官方并没有说明命令执行完成后会怎么样，反正我执行完没有任何反应，目标程序也没有发生crash）

获取更多的crash信息可以使用GDB调试工具调试server，或者加上Address Sanitizer-Enabled patch。

沿用AFL的基本思路，但是提升了代码覆盖率，并且寻求最大化协议状态覆盖。StateAFl会自动推测server的当前协议状态。在编译阶段，会想目标server的内存分配和网络I/O操作插入探针；在运行阶段，会为每个协议迭代拍摄进程内存中长期驻留的数据的快照，并使用fuzzy hashing将内存状态映射到唯一的协议状态。

（感觉本质上还是AFLNet的思路，发送请求序列，只不过在状态监控上做了另外一种方案。）

与AFLNet的安装方式基本相同：

与AFLNet一毛一样。

测试环境与AFLNet的一样，这里直接执行fuzz，看看效果如何：

速度上比AFLNet会快一丢丢，在覆盖率上也会高一点。

（自带的语料库没法触发漏洞，忽略这个吧，真实场景下的语料库需要精心设计和构造。）

。。。 。。。

这是一个对于网络协议相关fuzz工具的测试集合，可以方便地对流行的几款协议fuzz工具进行使用测试。

ProFuzzBench是一个有状态的网络协议测试的基准，包含了多个用于测试流行网络协议（TLS, SSH, SMTP, FTP, SIP等）的server。

ProFuzzBench提供了自动化执行fuzz的脚本，截止目前包含的fuzz工具有：AFLnwe（基于网络的AFL版本，使用TCP/IP sockets替代文件作为输入）、AFLNet（一款针对有状态网络协议的fuzz工具），而StateAFL（另一款针对有状态网络协议的fuzz工具）尚未提供自动化执行脚本，可直接使用原生的StateAFL进行fuzz。

其项目结构如下：

接下来以LightFTP为例进行fuzz。

首先，下载ProFuzzBench的源码并设置环境变量：

然后，创建lightFTP server的docker image：

执行profuzzbench_exec_common.sh脚本开启环境，这里涉及到8个参数：

以下指令就是在10分钟内执行4个AFLNet实例和4个AFLnwe实例来对LightFTP进行fuzz：

AFLNet的fuzz结果如下：

输出结果保存在了`results-lightftp目录中：

一个fuzzer实例产生一个.tar.gz文件，每个.tar.gz文件包含了这次fuzz过程产生的所有数据。

类似的，AFLnwe的输出一样：

这两个工具对比起来，fuzz效果都一般般，但AFLNet的速度会快一些，相对而言，比AFLnwe效果也好一些。cov_over_time数据对比如下：

对于覆盖率信息（也就是上面的表格）的处理，ProFuzzBench提供了处理覆盖率的自动化工具profuzzbench_generate_cssv.sh，参数说明如下：

可以使用下面的命令来处理fuzzer跑出来的覆盖率信息文件：

输出结果为results.csv文件：

文件中的第一列为时间戳，第二列为目标程序，第三列为fuzzer，第四列为运行的index，第五列为coverage type，第六列为type的值。文件包含了随时间变化的line coverage和branch coverage信息，每个coverage type都包含两个值：百分比 (_per) 和绝对数量 (_abs)。

前面生成的results.csv文件可以进一步进行绘图显示，使用脚本profuzzbench_plot.py:

处理完成后，可以看到处理结果：

从这里也能看出AFLNet比AFLnwe的效果要好太多。其实这个脚本的实现也不难，python中有很多成熟的库。

该工具支持添加自定义的fuzzer，按照stateafl的添加方式来进行添加即可，但是个人感觉以docker模式运行，速度上肯定要变慢。该工具值得肯定的是将常见的几个网络协议的fuzz环境能实现自动化搭建，可以节省一定的环境搭建时间成本。看个人需求吧，侧重效率的话还是要自行根据需求搭建独立环境。

该工具目前支持的协议环境有：

支持自定义添加协议，官方的开发文档也算完善，还是比较值得尝试的（毕竟也没有其他更好的选择了-。-）。

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！