信息量太大回头再写。。
# 一天后更新
不想写了差不多就下面这些内容吧。。
fuzzing的核心算法
initSeedCorpus：初始化新的输入
isDone：决定fuzzing是否停止
choose：从队列中选择至少一个种子输入进行变异
mutate：从至少一个种子输入和观察到的现象中产生新的候选种子
eval：评价程序的种子产生观察现象
isInteresting：根据观察到的现象决定种子是否保留
fuzzer的最终目标是生成输入使程序crash。其他类型的观察现象也是需要的，比如用例运行的时间，可以用来指示算法复杂度漏洞的存在。
本文研究对象是2012至2018这7年顶会上32篇相关论文。其中25篇是2016年以来的成果。
这里总结了32篇论文评价时的相关信息。
这里通过文章的主题将这些文章分类：
initSeedCorpus:
mutate:
eval:
isInteresting:
有意思的行为如：长运行时间，有差异的行为等
choose:
评价模糊测试算法的步骤
实验设置：
fuzzers. AFL 2.43b作为baseline B，AFLFast作为advanced算法。同时使用AFL的-n选项（关闭了覆盖率跟踪），称为AFLNaive。
benchmark. nm, objdump, cxxfilt, gif2png, FFmpeg。这些程序都在最近的成果评价时用来评价工具性能。
Performance measure. unique crashes，uniqueness由AFL能覆盖的路径数决定。
platform and configuration. 每次测试跑24小时，每种测试至少跑30次。同时也尝试了多样的种子输入文件：空文件，随机选择正确类型，人工写得文件。
大部分已有研究（18/32）没有提及测试的次数。这些论文可能认为随机性是均匀的，即如果测试跑了足够长时间，不同的随机会收敛，所有fuzzer会发现相同数量的crash。对于gif2png进行30次24小时的实验，AFLFast找到51个crash（中位数），AFL找到39个crash（中位数），使用Mann Whitney U-test进行显著性检验发现p-value>0.05。
讨论：最好的检验方法
两个可行的方法：
这两个方法与Mann Whitney相比是否合适不得而知，所以本文采取Arcuri和Briand的方法。从实验结果可知方法A比B好，但是好多少不知道，所以通过比较中位数的绝对差异来隐含地回答这个问题。
大多数工作（27/32）改进fuzzing loop。30/32使用非空的种子集合。
一个普遍的观点就是种子输入应该well-formed（valid）而且small。
可能初始语料库的细节并不重要，也就是说，不论种子如何初始，都能从算法的改进上体现出来。
本文使用不同种子输入测试FFmpeg，包括已有video files和randomly-generated videos。
总结来说，fuzzers在同个程序上针对不同输入的性能表现各不同。本文建议应该更谨慎地考虑，应该使用各类输入评价fuzzer的算法。论文应该写明种子输入如何收集，且最好给出实验用到的种子输入。而且empty seed应该考虑到，因为这是最简单的输入，可以被任意系统使用。
比较常用的是24小时（10/32），和5或6小时（7/32）。6/32超过一天。
而且不同超时设置会影响实验的结果，如上图。timeout=6h时，AFL没找到crash但是AFLFast找到4个，差异是显著的；然而若timeout=24h，AFL找到14个crash而AFLFast只找到8个，这个差异也是显著的。
较短的timeout更符合实际场景。
*讨论：*也可以计算AUC作为报告找bug能力的度量。但是如果一个fuzzer A一开始就发现5个crash，另一个fuzzer B在最后才发现了10个crash，直觉来说B的找bug能力大于A，但是AUC较小，所以AUC度量不适用于基于时间绘图。
能找到bug是检验fuzzers性能的第一标准！
一句话，代码覆盖率作为第二度量是讲得通的，但是最主要的评价指标还是找到的bug数（distinct bugs）。
这里涉及benchmark选择的问题。
主要分为两类：
使用真实程序作为benchmark的问题：
Google Fuzzer Suite比较好地解决了这个问题：
有时不关心特定的程序集合，而是程序中反模式的有代表性的集合。
有两个著名的suite：CGC和LAVA-M
已有工作：
本文建议，模糊测试效果评价应该包含以下元素：
timeout≥24h未来工作的三条线：