介绍
这篇博文介绍了关于模糊测试的基础知识，以及几种模糊测试工具，并由以下三个部分阐述一些最新的关于fuzzing技术的资讯。

第一部分主要介绍高级模糊测试技术。简要地讨论了使用模糊测试的情景，并进一步解释了开启模糊测试场景以及经典的模糊测试工具的架构。

第二部分主要描述模糊测试入门的过程，并介绍几种通俗易懂，易于理解和使用的模糊测试工具。虽然，通常情况下直接使用现有的fuzzer更为简便，但是由用户自己编写的fuzzer或调整现有的fuzzer可能会产生更好的效果。本文提供的不是一个足够全面完整的列表，而是一系列不同模糊测试技术的示例。

第三部分主要阐述了最近发表的关于模糊测试技术的研究。它将重点关注新型模糊测试技术和经过测试用例已生成技术的公开研究结果。
0 – Fuzzing 101


介绍


本章节将介绍高级模糊测试技术，并简要地讨论了使用模糊测试技术的理由。我将会进一步解释你需要如何开始进行模糊测试以及典型的模糊测试工具的架构。
什么是模糊测试？


Fuzzing或模糊测试是一种自动化的软件测试技术，通常用于识别程序中的潜在漏洞。对程序进行模糊测试是通过向其提供随机输入语句并记录导致程序中的崩溃或非崩溃的内存损坏的测试用例来完成的。在某种意义上，模糊测试就是通过蛮力搜索漏洞。几乎所有需要某种输入的软件都可以进行模糊测试，比如——浏览器，通过查看或编辑文件的应用程序，系统内核，大多数API和其他程序接口，驱动程序，网络守护程序，Web应用程序等等都可以对其进行fuzzing。中国菜刀




简单的模糊测试不需要任何有关程序的信息，因此，这是一种黑盒测试技术。但是，有一些先进的模糊测试技术可以分析或检测源代码或二进制文件，以便将生成的输入定制到模糊程序，这将是本系列的下一篇博文介绍的内容之一。

为什么选择模糊测试？

Fuzzing 是一种自动发现 bug 的方法; 理想情况下，Fuzzing 可以简单地在机器上运行并且不受干扰。 因为它不需要太多的手动交互，所以它可以是一种廉价的测试技术。另一方面，手工测试非常耗费资源，它揭示的错误数量取决于测试人员的技能。模糊测试和手动测试的结合是最佳的一种做法，因为这两种技术通常会发现不同类型的错误，并且它们可以互补。

应用程序越复杂，就会有越多的 bug，随着复杂性的增加，攻击面也会增加。 对非常复杂的应用程序进行手工测试需要花费大量时间，并且需要良好的测试技能。 例如，如果一个公司决定只手动测试一个浏览器，那么在下一个版本完成之前，就需要很多技能熟练的测试人员来测试整个应用程序。一个fuzzer可以简单的永久运行并且可以在软件发布之前完成测试。 大多数fuzzer的规模相当不错，所以如果需要测试的更快，找到更多的bug，那么你可以只是增加更多的测试机器或更多的CPU内核。也可以使用 Fuzzing 回归测试来确保不会再次引入任何已知的 bug。

作为一个安全研究人员， fuzzing 的确是伟大的，因为一旦一个fuzzer设置好并运行后，你可以解放双手去做其他的事情。
模糊测试的常见问题

虽然 fuzzing 是一个发现bug的伟大且廉价的方法，但它并不总是最佳的选择。这取决于应用程序和期望的缺陷类型，fuzzer 可能需要大量的时间来进行设置才能找到更多的缺陷。特别是那些能够意识到输入结构的可自编写的智能fuzzer的设置将会花费一些工作，直到它产生可用的结果。

一个fuzzer是不能替代其他安全措施的。虽然你有最强大的fuzzer，发现了大量的漏洞，但它不太可能找到一个程序中的每一个漏洞。所以如果你的 fuzzer 没有发现更多的漏洞，这并不意味着你的程序是完全安全的。模糊测试只是对其他安全措施(如定期代码审计和其他安全开发原则)的一个很好的补充。

Fuzzer可以产生许多误报，无法利用的bug以及重复的结果。因此，评审过程是强制性的，无论是手动的还是自动的，这是需要资源的。输入越复杂，评审过程就越复杂。

最大限度地提高Fuzzer的效率是模糊测试最困难的部分之一。一个Fuzzer的价值通常取决于它发现了多少以前未知的bug或漏洞。为了找到更多的 bug，fuzzer 需要有一个高崩溃率的测试用例，这高度依赖于生成的测试用例的质量。通过管道/dev/urandom 到你的目标很容易，但是每个测试用例的崩溃率可能太低，无法在适当的时间窗口中找到任何内容。同时，单个测试用例的执行时间应该尽可能的短。
模糊测试需要什么？

要开始模糊测试，你需要一个接受输入的目标。应用程序越复杂，就越有可能使用fuzzer找到bug。它可以是内部软件，也可以是第三方软件，这取决于你的测试用例。你需要考虑你想要捕捉的bug的类型。一个 fuzzer 需要知道什么时候它发现了一个 bug，所以最容易发现的 bug 是那些导致崩溃的 bug，因为这将表明一个潜在的安全漏洞。

当你清楚你想模糊测试的应用程序和bug类型，那么你有必要思考情况使用什么样的fuzzer。如果你不想从头开始编写模糊测试工具，那么你可以选择许多不同的模糊测试工具。其中一些需要工具一些工作来进行设置，其他的工作则可以迅速完成。因为正确选择模糊测试工具既重要又困难，本系列的下一篇博客文章将介绍一些最重要的 模糊测试工具。天空彩​​​​​​​
一个fuzzer可以找到什么类型的bug？

理论上，通过模糊测试工具可以找到所有可能的 bug 类型。fuzzer需要一种检测机制来将程序的行为分类为无意的或恶意的。因此，有些 bug 的类比其他 bug 的类在代码中更容易找到，因为它们会产生明显的错误行为。例如，内存损坏bug在触发时导致崩溃是很容易检测到的。另一方面，逻辑错误可能非常难以检测，因为程序没有明显的不正常行为，而且预先定义检测逻辑错误的规则可能比较棘手。
一个典型的fuzzer架构

一个典型的fuzzer由三个不同的部分组成。 一个测试用例生成器生成输入，输入到被测试的程序; 一个worker程序执行给定的输入，并识别意外的行为; 一个日志记录器记录有趣的测试用例以及分析 bug 所需的一切。大多数fuzzer还包括一个服务器或主机，它协调其他三个部分并管理它们之间的通信。



测试用例生成器

测试用例生成器主要负责创建新的测试用例。为了创建新的测试用例，它可以自己识别出输入的结构，这被称为智能fuzzer。相反，不知道输入结构的测试用例生成器被称为愚蠢fuzzer。测试用例可以从头开始生成，也可以从现有的测试用例中变异。复杂的fuzzer也可以将生成和变异结合从而生成测试用例。
模糊测试的导向类型

由测试用例生成器创建的测试用例在质量上有很大的不同。因此，测试用例生成器需要某种指导来决定变更或生成哪些测试用例。最常见的启发式指导是代码覆盖率。理论上，代码覆盖的越多，模糊测试就能发现更多的错误。测试用例生成器可以配置为创建类似于发现新覆盖率测试用例的测试用例。与覆盖率导向的模糊测试类似，基本上所有与发现更多bug相关的指标都可以用作测试用例生成器的指导，例如数据流指导。
愚蠢fuzzer

不需要输入结构模型来生成新测试用例的测试用例生成器称为愚蠢fuzzer。愚蠢fuzzer的优点是它不需要输入结构的信息，因此适合对很多不同的程序进行模糊测试而不需要太多的调整。使用愚蠢fuzzer的最大缺点是，大多数输入需要预定义的结构或包含校验和，fuzzer将很难生成有效的输入，因此主要是测试应用程序的解析代码。
智能fuzzer

与愚蠢fuzzer相反的是一个智能fuzzer，它的测试用例生成器能够理解输入文件的结构。输入文件的结构称为输入模型。例如，输入模型可以是编程语言的语法或数据格式模型。智能fuzzer的优点是它主要创建有效的输入文件，这将导致实际程序中更高的代码覆盖率。然而，一个智能fuzzer通常是高度专业化的特定类型的输入，它需要一个好的输入模型才能够创建测试用例，从而可能触发bug。
基于变异的模糊测试

基于变异的fuzzer是通过变异已知的测试用例来创建新的测试用例。常见的变异技术包括位翻转，即将输入中的随机位进行翻转，或移动、删除、重复输入中的数据块。一个基于变异的fuzzer的主要优点是它需要较少的worker来设置。基于变异的fuzzer的关键部分是选择有趣的测试用例进行变异。这些测试用例需要尽可能不同，使模糊测试达到尽可能多的代码覆盖率，使其更有可能发现bug。例如，如果目标是一个查看和编辑图片的应用程序，并且所选择的测试用例只是 PNG 格式的，那么fuzzer就不太可能覆盖到处理其他文件类型的代码。
基于生成的模糊测试

基于生成的fuzzer会从头开始生成新的测试用例。基于生成的fuzzer需要知道输入文件的结构，否则它们只会生成随机的字节。通常它们需要worker来进行设置，并且专门用于特定的输入类型。 然而，一旦启动并运行之后，它们往往能比基于变异的fuzzer产生更多的代码覆盖率，因此更有可能发现不同的bug。
测试用例最小化

随着时间的推移，由变异创建的测试用例在规模和复杂性上都趋向于增长。这会导致更长的执行时间，并且使得分析有趣的测试用例变得更加困难。较小的测试用例也可以更好地将模糊测试集中在被模糊测试的软件的有趣部分上。因此，fuzzer的测试用例生成引擎也应该能够最小化测试用例。最小化测试用例的目标是找到尽可能小的测试用例，同时触发初始测试用例触发的相同行为。 在这种情况下，相同的行为意味着要么触发相同的崩溃代码，要么满足相同的指导要求。例如，对于覆盖率导向的模糊测试是否意味着在最小化测试用例中命中相同的有趣代码块。这可以通过删除测试用例的某些部分、向目标提供修改后的输入并观察其行为是否仍然满足相同的要求来实现。

最近在做Fuzzing测试，使用Peach v3测试框架，期间在编写pit脚本遇见一些问题，搜寻好长时间才找到解决办法。
网络上关于pit语法解释不够详细，对when属性讲解的更少。
我测试的时候想使用pit文件的when属性，找了好多资料，最后在官网找到相关介绍，如下（地址：http://community.peachfuzzer.com/v3/Action.html）

<DataModel name="InputModel">
        <Number name="Type" size="32" />
</DataModel>

<DataModel name="OutputModelA">
        <Number name="Type" size="32" value="11 22 33 44" valueType="hex" />
</DataModel>

<DataModel name="OutputModelB">
        <Number name="Type" size="32" value="AA BB CC DD" valueType="hex" />
</DataModel>

<StateModel name="StateModel" initialState="InitialState">
        <State name="InitialState">
                <Action type="input">
                        <DataModel ref="InputModel" />
                </Action>

                <Action type="changeState" ref="State2" when="int(StateModel.states['InitialState'].actions[0].dataModel['Type'].InternalValue) == 2"/>

                <Action type="changeState" ref="State3" when="int(StateModel.states['InitialState'].actions[0].dataModel['Type'].InternalValue) == 3"/>

        </State>

        <State name="State2">
                <Action type="output">
                        <DataModel ref="OutputModelA" />
                </Action>
        </State>

        <State name="State3">
                <Action type="output">
                        <DataModel ref="OutputModelB" />
                </Action>
        </State>
</TheStateModel>


when属性的表达式是ture时转跳转执行。
该行语句就是when属性用法，但是它这里是接受到（整数型的2）状态发生转变，我想接受指定字符串时状态发生改变，例如接受到220 Server Welcome !找了好多办法，一直没成功，主要精力放在["Type"]、InternaValue、浪费很多时间
<Action type="changeState" ref="State2" when="int(StateModel.states['InitialState'].actions[0].dataModel['Type'].InternalValue) == 2"/>


很明显，StateModel.states['InitialState'].actions[0].dataModel['Type']含义是初始状态第一个动作接受的数据：
<Number name="Type" size="32" />
的值
peach官网同样老兄提出问题“How can I change state by receive data of socket”地址：https://forums.peachfuzzer.com/forum/peach-community-edition/general-support/3924-how-can-i-change-state-by-receive-data-of-socket
问题没人解释。
使用Peach -1 --debug命令结果如下：
红色圈的地方很明显是解决接受数据即是220 ftp0.99server，但是就是无法使用when属性中使用表达式
后来我找到解决办法是：

<DataModel name="InputModel">
        <Number name="Type" size="32" />
</DataModel>
更改为如下
<DataModel name="InputModel">
        <String name="Type" size="32" />
</DataModel>

就是原整数类型改为String类型

when属性更改：
<Action type="changeState" ref="State2" when="str(StateModel.states['InitialState'].actions[0].dataModel['Type'].DefaultValue) == '***期望字符串'"/>

解决办法很简单，但是不太懂xml的我中间遇见很多坑，包括引号问题（注意字符串需要引号），还有str、int问题

需要再说明一下：DefaultValue 可以使用 int(), str(), etc.、InternalValue、Value - binary value written out (is a BitStream type)

写的不是很详细，还有其他pit格式规范后续更新，欢迎交流peach。

声明
本文内数据是本人自己的数据库（内数据是已知的过载数据30w条）云服务器是最低配置4G➕20w访问限度/月，以保证数据足够可以用来进行模拟测试，测试主要工具是websocker

由于官方已经对此已经有过了声明

db.RegExp官方介绍

当然会有人问既然官方已经给出了相关声明为什么我们还要再进行测试呢？当然对于数据量较小（10w-15w）来说不会有太多的性能误差，但公司内给你了一个数据量在20w-25w数据只能在已知30w数据量之下却并不知道是否对查询性能产生影响，因此需要测试出模糊查询的最高指标到底在哪？
db.RegExp构造器使用方法
依照官方提供的案例，首先db.RegExp构造器的基础库适用版本最低是2.3.2（wx-server-sdk最低为0.0.23）且在使用后可知，小程序使用构造器时并不像JavaScript那样可以支持正则符号进行匹配而是官方提出使用flag"i"、"m"、"s" （因为曾经我也在此被坑过，在此对大家进行警告不要使用正则符号）一起准备完毕后开始展示代码：
 \\调用数据库
 const db = wx.cloud.database(),
 db.colloction('database').where({
     word_value : db.RegExp({ //字段内匹配值 ：构造器 再次声明基础库要更新为最新版本
            regexp : search.detail.value, //与输入内容进行匹配
            opinions : "i",     //flag不区分大小写       
   }).get({
      success : res =>{
         this.setData({
            data : res.data
            })  
          console.log(res)
           }
         })
})

使用websocker进行模拟测试
在使用模糊查询构造器后进行模拟测试，首先查询数据量小于15w大于10w的数据，并每次以5w次数据累加测试，在数据累加到25w左右后，明显在使用模糊查询构造器后性能有所降低并出现少许的加载速率延迟，虽然云端检索器内没有命中记录，但却已经开始对系统性能有了明显的影响，再当数据量达到28.7w时系统性能已经有了明显的影响，可知在数据量达到29w后，已经不能再次进行进一层的深度查询了，在此可以粗略计算在小程序推广以后，假设平均每天访问量共有10w人次，数据量为2w，根据模拟测试的结果得知，最大不得超过5千人次/s。
结论
在使用构造器时，首先需要看数据量的大小，如果数据量较小，则不必考虑系统性能的影响，当数据量非常大的情况下，可以尝试使用分块储存为静态文件以减小系统负担。

先简单介绍一下.
刚接触模糊测试肯定是要从现在最为流行的AFL开始，现在很多关于AFL的改进都是针对AFL的，而且AFL本身因为其遗传算法、高吞吐量而得到很好的应用，在一些AFL变异版本（如AFLGO、PFuzz、CollAFL、ENFuzz等）、混合模糊测试（结合模糊测试和符号化执行）在实验对比中都拿AFL当作baseline。我们就一步一步从AFL本身学起，对模糊测试进行深入学习吧。
对一个程序进行模糊测试我们需要做到以下几点：
1、能够变异很多的测试样例，把种子（测试样例）进行自生产
2、在程序以一个种子作为输入后，能够观察程序是否会走新的路径。
这样一来就可以把能触发不同执行路径的种子进行收集，当有种子是程序运行产生错误或者延迟的时候进行记录，就可以利用工具看程序在哪存在问题。
拿到AFL源码后进行make，make install编译安装后就可以用了。Make过程中会出现缺少什么依赖之类的，该安装就安装，就可以编译成功了。为了获得对一个程序执行路径的掌握，需要插桩，有程序源码的话用内置的afl-gcc进行源码插桩，插桩后就可以进行模糊测试了，命令行为./afl-fuzz -i testcase_dir -o findings_dir /path/to/program @@（@@表示程序执行的时候会把indir里面的测试样例当作参数放在命令行中，-i后面是存放测试样例的文件夹，-o后面是存放输出结果的文件夹，./后面是插桩过的二进制程序）。
但是如果只有二进制程序的话，使用QEMU模式进行插桩（速度会慢二到五倍）。在之后会进行讲解。
使用afl-gcc插桩
我们先看一下afl-gcc的源码，其实afl-gcc就是对gcc的一个封装，会在gcc的基础上调用afl-as。

afl-as是对.s文件进行插桩操作，在其中有跳转的的位置插入汇编码，实现在程序跳转时能够通过在跳转处的插桩掌握程序的执行路径。在函数add_instrumentation（）中对输入的汇编代码.s文件进行操作，下列代码将识别跳转（je，jnz之类）。
if (line[0] == '\t') {

if (line[1] == 'j' && line[2] != 'm' && R(100) < inst_ratio) {

   fprintf(outf, use_64bit ? trampoline_fmt_64 : trampoline_fmt_32， R(MAP_SIZE));

   ins_lines++;

 }

 continue;

}

其中R（MAP_SIZE)为随机值，修改了rcx中的值，调用__afl_maybe_log。我们可以在使用afl-gcc编译后的二进制程序反汇编，看到跳转处有插桩。拿一个简单的例子为例
int main(int argc, char *argv[])

{

	 if(argc>1)
	
	     printf("yes");
	
	 else
	
	     printf("no");
	
	 return 0;

}

把编译好的文件反汇编可以看到插入的汇编代码：

之前提到过，在跳转处插入了调用random封装而成的R（MAP_SIZE）函数生成一个随机值存入rcx寄存器，再进入堆栈成为_afl_maybe_log的参数。那么当AFL在选择输入种子之后就会运行程序，没到一个基本块就会执行一次_afl_maybe_log，这样一来，每个基本块相当于有了自己的id，afl执行了哪些基本块就会记录id，从而得到执行路径。关于AFL怎么记录基本块ID，怎么比对不同种子下的执行路径，我们会在第三节AFL的运行中详细讲。