AFL实战

1. 关于AFL
   American fuzzy lop 号称是当前最高级的Fuzzing 测试工具之一，由谷歌的Michal Zalewski 所开发。通过对源码进行重新编译时进行插桩（简称编译时插桩）的方式自动产生测试用例来探索二进制程序内部新的执行路径。与其他基于插桩技术的fuzzers 相比，afl-fuzz 具有较低的性能消耗，有各种高效的fuzzing 策略和tricks 最小化技巧，不需要先行复杂的配置，能无缝处理复杂的现实中的程序。

安装AFL

查看路径可以看到afl安装的文件

作用分别为
• afl-gcc 和afl-g++ 分别对应的是gcc 和g++ 的封装
• afl-clang 和afl-clang++ 分别对应clang 的c 和c++ 编译器封装À。
• afl-fuzz 是AFL 的主体，用于对目标程序进行fuzz。
• afl-analyze 可以对用例进行分析，通过分析给定的用例，看能否发现用例中有意义的字段。
• afl-qemu-trace 用于qemu-mode，默认不安装，需要手工执行qemu-mode 的编译脚本进行编译，后面会介绍。
• afl-plot 生成测试任务的状态图
• afl-tmin 和afl-cmin 对用例进行简化
• afl-whatsup 用于查看fuzz 任务的状态
• afl-gotcpu 用于查看当前CPU 状态
• afl-showmap 用于对单个用例进行执行路径跟踪
创建本次目录

已经源代码test.c，该代码编译后得到的程序如果被传入“deadbeef”则会终止，如果传入其他字符会原样输出

使用afl的编译器编译，没错，一般我们确实直接使用gcc就可以了，不过使用afl的编译器可以使用模糊测试过程更加高效

编译后会有插桩符号，使用下面的命令可以验证这一点

在linux下编译链接程序，如果不加-o参数，生成的binary代码的名字都是默认的a.out。 a.out是"assembler output"的缩写格式，代表汇编程序输出。 在较早版本的类unix系统中，a.out是一种输出格式，用于可执行文件，目标文件和共享库。当然在本次实验中a.out也是可执行的。不过使用编译链接得到的test也是可以的

进行下一步之前，还需要输入如下命令将指示系统将coredumps输出为文件，而不是将它们发送到特定的崩溃处理程序应用程序

下面还是以a.out为例

通过管道命令传参数个它看看

下图可以看到传入deadbeef时就终止了

如我们预期所料。
接下来介绍afl-showmap
afl-showmap工具将运行给定的二进制文件（将通过stdin接收的任何输入通过stdin传递给检测的二进制文件）并打印其在程序执行期间看到的反馈报告。
还是测试上面这两个例子

这儿稍微提一下signal 6是怎么回事。Signal 6就是SIGABRT。abort（）向调用进程发送SIGABRT信号，abort（）通常由库函数调用，在我们代码里正是满足”Deadbeef”条件时调用abort()所以会出现signal 6.(见代码截图的最后一行)
除了afl-showmap之外，还有afl-cmin,afl-tmin等，afl-cmin一般用于尝试在输入目录中查找仍然触发起始语料库中所见的全部检测数据点的最小文件子集;afl-tmin接收输入文件并尝试尽可能多地删除数据，同时保持二进制处于崩溃状态或产生一致的检测输出;合理利用它们可以在大样本情况下提高工作效率，不过本次实验比较简单，所以两个工具就不演示了，用法可以输入名称进行查看。

现在我们可以开始使用afl-fuzz命令来模糊我们的程序。 但首先我们必须创建测试用例。 通过官方用户指南，我们应该通过一些字符串启动测试用例。
首先创建输入文件夹，顺便把输出文件夹一起创建了

然后在输入文件夹中创建一个包含字符串“hello”的文件。

创建我们的测试用例后，我们可以启动模糊测试过程。 Afl将开始使用in目录中的字符串模糊我们的程序

我们给出的语料是hello，fuzz的目的是为了crash，但是根据源码可以知道只有deadbeef才会有crash，而hello正常情况下是不会编译出deadbeef的，所以我们fuzz得再久也不会出一个crash

布局从左到右，从上到下，依次是：
① Process timing:Fuzzer运行时长、以及距离最近发现的路径、崩溃和挂起经过了多长时间。
② Overall results：Fuzzer当前状态的概述。
③ Cycle progress：我们输入队列的距离。
④ Map coverage：目标二进制文件中的插桩代码所观察到覆盖范围的细节。
⑤ Stage progress：Fuzzer现在正在执行的文件变异策略、执行次数和执行速度。
⑥ Findings in depth：有关我们找到的执行路径，异常和挂起数量的信息。
⑦ Fuzzing strategy yields：关于突变策略产生的最新行为和结果的详细信息。
⑧ Path geometry：有关Fuzzer找到的执行路径的信息。
⑨ CPU load：CPU利用率
不耐烦了就ctrl+c结束吧，我们换语料
要不直接输deadbeef怎么样？

重新输入fuzz的命令

这下好了，都不用跑fuzz程序了直接就crash了，这显然也不是我们的目的，我们的目的是通过语料库的变异触发crash，所以再换

我多加了一个a
再次fuzz

可以看到才运行了4秒就触发了crash
同样ctrl+c结束
来到out文件夹

有三个文件夹
queue文件夹包含每个独特执行路径的测试用例，以及用户给出的所有起始文件。如果你打印出queue /中的文件，你会看到id增加，afl逐渐从init输入“deadbeae”接近“deadbeef”，这将使我们的程序carsh。

hang文件夹包含导致测试程序超时的测试用例，本次为0，所以就不看了
crash文件夹包含导致测试程序接收致命信号的测试用例，进入crashes可以看到触发得到的crash

使用cat查看

可以看到确实就是由deadbeaef变异出的deadbeef触发的

本次是针对有源码情况下进行的，使用afl的编译程序进行插桩，如果是针对二进制文件进行fuzz的话，一般通过编译AFL版本的qemu实现，具体使用请自行学习网上相关资料。
另外在使用afl时有些小tip需要注意：

1. 尽量使测试用例足够小
   大用例不光使得目标进程解析时需要耗费更多CPU 时间和更多内存，也会使得fuzz 进程效率非常低下。举个例子，如果要对一个图片处理程序进行fuzz，就没必要将高分辨率的照片作为用例，一个16x16 分辨率的图片就足矣。再举个例子，从数据上来看，如果一个用例的大小为100 字节，那么fuzz 1000 次，可以有71% 的机会触发到有问题的执行路径；如果用例的大小变为1k 字节，则同样的执行次数，触发有问题的分支的概率降低为%11；如果用例规模进一步增长，变为10k字节，则同样的执行次数，触发问题分支的概率将降低为%1。
2. 确保测试对象足够简单
   有些基本的文件格式处理库被不同的处理程序使用，有些处理程序功能复杂，有些简单，那么，我们应该选择那些功能简单的处理程序来fuzz。举个例子，就图片格式处理程序来说，djpeg、readpng 以及gifhisto 要比ImageMagick 在执行效率上快5 到10 倍，但是他们都用同样的图片格式解析库。
3. 只给需要测的库进行打桩因为AFL
   是在汇编级别对被测程序的源码进行插桩的，也就是说，插桩的点越多，编译出来的程序执行效率就会越低。那么，如果只想对其中某一个库进行fuzz 的话，可以用未插桩的库替换掉被测程序中使用AFL 编译器编译出来的库。
4. 并行
   afl-fuzz 设计成只给工作进程分配一个核，现在的机器都具备多个CPU，每个CPU 又有多个核，所以我们可以最大地发挥硬件效率，同时执行多个afl-fuzz。

8 参考资源

1. 台湾国立交通大学的一个大佬写的入门教程http://spencerwuwu-blog.logdown.com/posts/1366733-a-simple-guide-of-afl-fuzzer
2. 看雪一篇结合gdb分析crash的关于afl的教程https://bbs.pediy.com/thread-249179.htm
3. 多种afl工具使用及多种情况下afl处理的文章https://0x00sec.org/t/fuzzing-projects-with-american-fuzzy-lop-afl/6498
4. 使用afl来fuzz binutils的例子 https://www.evilsocket.net/2015/04/30/fuzzing-with-afl-fuzz-a-practical-example-afl-vs-binutils/
5. 使用afl挖imagemagick的cve的文章https://github.com/lcatro/Fuzzing-ImageMagick/blob/master/%E5%A6%82%E4%BD%95%E4%BD%BF%E7%94%A8Fuzzing%E6%8C%96%E6%8E%98ImageMagick%E7%9A%84%E6%BC%8F%E6%B4%9E.md
6. 天融信阿尔法实验介绍afl的文章https://www.freebuf.com/articles/system/191536.html