最新模糊测试-AFL学习笔记之C C++_lcamtuf博客，2024年最新3年C C++开发工程师面试经验分享

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上C C++开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取

这可能是最重要的一步！大型测试用例不仅需要被测试的二进制文件花费更多的时间和内存来解析，而且还使得模糊测试处理的效率大大降低。

为了说明这一点，假设您随机地一次翻转文件中的位。假设如果您翻转＃47位，将会遇到一个安全漏洞；翻转任何其他位只会导致文档无效。

现在，如果您的开始测试用例的长度为100个字节，那么您将有71％的机会在前1,000个exec中触发错误——不错！但是，如果测试用例的长度为1 KB，则我们将在同一时间范围内随机击中正确模式的可能性将降低至11％。而且，如果它具有10 KB的非必需杂物，则几率骤降到1%。

最重要的是，在输入较大的情况下，二进制文件目前的运行速度可能比以前慢5到10倍-因此模糊测试的总体效率可能很容易下降高达500倍左右。

在实践中，这意味着您不应该用假期照片来对图像解析器进行模糊测试。而是生成一张很小的16x16图片，并通过jpegtran或pngcrunch运行该图片以取得良好效果。大多数其他类型的文档也是如此。

…/testcases/*中有很多小型的开始测试用例-试试看或提交新的！

如果要以更大的第三方语料库开头，请首先在该数据集上运行afl-cmin并设置超时时间。

2）使用更简单的目标

考虑在模糊测试中使用更简单的目标二进制文件。例如，对于图像格式，捆绑的实用程序（例如djpeg，readpng或gifhisto）比ImageMagick的转换工具要快（10-20倍）——所有这些都在执行大致相同的库级图像解析代码。

即使您没有针对特定目标的轻量级工具，也请记住，您始终可以使用另一个相关的库来生成语料库，然后将其手动输入到耗费更多资源的程序中。

3）使用LLVM检测

当对缓慢的目标进行模糊处理时，可以使用llvm_mode / README.llvm中介绍的基于LLVM的检测模式，将性能提高2倍。请注意，此模式需要使用clang，不适用于GCC。

LLVM模式还提供了一种“持久”的进程内模糊测试模式，该模式对于某些类型的自包含库可以很好地工作，对于快速目标，可以将性能提高5-10倍；以及“延迟派生服务器”模式，该模式可以为具有高启动开销的程序提供巨大的好处。两种模式都要求您编辑模糊程序的源代码，但这些更改通常只相当于战略性地写一两行代码。。

4）分析并优化二进制文件

检查任何明显改善性能的参数或设置。例如，可以用以下命令调用IJG jpeg和libjpeg-turbo随附的djpeg实用程序：

-dct fast -nosmooth -onepass -dither none -scale 1/4

这将加快速度。解码图像的质量相应下降，但是您可能并不在意。

在某些程序中，可以完全禁用输出，或者至少使用计算上更快的输出格式。例如，使用图像转码工具，转换成BMP文件要比转换成PNG快得多。

对于某些悠闲的解析器，启用“严格”模式（即，在出现首次错误后进行救助）可能会导致文件更小，运行时间更长而又不牺牲覆盖率；例如，对于sqlite，您可能需要指定-bail。

如果程序仍然太慢，则可以使用strace -tt或同等的性能分析工具来查看目标二进制文件是否在做任何愚蠢的事情。有时，您可以通过指定/dev/null作为配置文件来加快速度，或者禁用一些工作中并不需要的编译时功能（尝试./configure --help）。众所周知，消耗资源的事情之一是通过exec *()，popen()，system()或等效调用来调用其他实用程序。例如，当tar确定输入文件是压缩档案时，它可以调用外部解压缩工具。

一些程序还可能故意调用sleep()，usleep()或nanosleep()；vim是一个很好的例子。其他程序可能会尝试fsync()等等，有些第三方库可以很容易地删除此类代码，例如：

https://launchpad.net/libeatmydata

在由于不可避免的初始化开销而导致速度缓慢的程序中，您可能需要尝试LLVM延迟的forkserver模式（请参阅llvm_mode / README.llvm），如上所述，它可以使速度提高多达10倍。

最后但并非最不重要的一点是，如果您正在使用ASAN并且性能不可接受，请考虑暂时将其关闭，然后稍后使用启用了ASAN的二进制文件手动检查生成的语料库。

5）测试你想测试的

仅对您现在实际想要进行压力测试的库进行一次测试。让程序将系统范围内的非仪表库用于您实际上不想模糊的任何功能。例如，在大多数情况下，不应该仅仅因为您要测试依赖于大数数学的加密应用程序而检测libgmp。

谨防奇怪的第三方库附带的与源代码捆绑在一起的程序（Spidermonkey是一个很好的例子）。选中./configure选项以使用非仪器范围的副本。

6）使您的模糊器并行

该模糊器设计为每个作业需要〜1个核心。这意味着，在一个4核系统上，您可以轻松运行四个并行的模糊测试作业，而性能损失相对较小。有关如何执行此操作的提示，请参见parallel_fuzzing.txt。

afl-gotcpu实用程序可以帮助您了解系统上是否还有空闲的CPU容量。（它不会告诉您有关内存带宽，缓存未命中率或类似因素的信息，但不太可能引起您的关注。）

7）检查内存使用情况和超时

如果您增加了-m或-t限制，超出了实际需要，请考虑将其重置。

对于名义上速度非常快但对于某些输入变得缓慢的程序，您也可以尝试设置-t值，该值比afl-fuzz自己敢使用的值更具惩罚性。在快速闲置的机器上，降低到-t 5可能是一个可行的计划。

-m参数也值得一看。当出现病理性输入时，某些程序最终可能会花费大量时间来分配和初始化兆字节的内存。-m值低可以使它们更早放弃并且不浪费CPU时间。

8）检查操作系统配置

有几种操作系统级别的因素可能会影响模糊测试速度：

-高系统负载。尽可能使用闲置的计算机。杀死所有不必要的CPU消耗（空闲的浏览器窗口，媒体播放器，复杂的屏幕保护程序等）。

-网络文件系统，用于模糊器的输入/输出，或由模糊的二进制文件访问以读取配置文件（要特别注意主目录-许多程序在其中搜索点文件）。

-按需CPU缩放。Linux“按需”调控器会按特定的时间表执行分析，并且众所周知，它会低估由afl-fuzz（或任何其他fuzzer）产生的短暂进程的需求。在Linux上，可以通过以下方法解决此问题：

cd /sys/devices/system/cpu

echo performance | tee cpu*/cpufreq/scaling_governor

在其他系统上，CPU扩展的影响将有所不同。在进行模糊测试时，请使用特定于操作系统的工具来确定所有内核是否都在全速运行。

-透明的大页面。在内核中启用透明大页面（THP）时，某些分配器（例如jemalloc）可能会产生大量的模糊测试。您可以通过以下方式禁用此功能：

echo never > /