AFL模糊测试实验

软件系统安全的第二次实验是基于 google 的 AFL 框架下的 Fuzzing 模糊测试。属于实战应用型实验，依然是搭建环境最折磨的那种实验。

实验环境

Ubuntu 22.04-64bit 虚拟机

Python 2.7及以上版本

实验准备

下载安装AFL，在github下载的源码，make之后可以正常使用 afl-fuzz 和 afl-gcc
在qemu_mode目录下构建AFL-Qemu.这一步出现了很多问题，解决方法参考文献。
下载本次实验的目标程序集 coreutils-9.1 （GNU核心实用程序）

实验步骤

实验大体分为两个模块，分别是基于编译器和AFL-Qemu的目标程序动态插桩。

基于编译器的目标程序插桩

第一步：使用afl-gcc，生成coreutils的每个二进制程序

进入coreutils的目录，带参数 CC = afl-gcc 执行。

$ ./configure CC=afl-gcc

然后原地make，生成coreutils的二进制程序集，结果都放在src目录下。

第二步，为coreutils其中的特定程序确定输入种子

coreutils包含的二进制程序很多，从其中任选3个，这里选择的是最常用的其中三个：cat、echo 和 ls。

用来输入的种子列表，这里是使用了AFL自带的字典，放在 /AFL/dictionaries/ 目录下。拷贝到 input 目录下，作为构造的种子输入。

第三步，在 src 目录下，使用 “afl-fuzz -i input -o output ./程序名 @@” 进行fuzzing，一段时间之后终止fuzzing，在 coreutils-9.1/src/output 目录下查看测试结果。

如图所示，一开始出现了程序崩溃被识别成超时的错误，sudo su之后改一下core_pattern就行。

OK，这样fuzzing就跑起来了。

问题来了，由于选择的二进制程序实在是太常用了，出现crash的概率非常小，执行了10分钟后仍然没有crash，于是选择更换程序，尽量选择不那么常用的。

经过将近半个小时的fuzz，仍然没有任何crash，看来确实非常坚固。

基于AFL-Qemu的目标程序动态插桩

第一步，重新生成coreutils的每个二进制程序，不使用afl-gcc

中间遇到了 afl-qemu-trace 无法定位的问题，只需要把AFL下的同名文件复制到 afl-fuzz 目录下即可。

相比较而言，afl-qemu的动态插桩就慢一些了，也没有什么成果。

问题探究

两种种子输入的构造方法，对于fuzzing结果是否有影响？

答案是有影响的。AFL可以通过启发式算法自动确定输入，但是如果直接随即构造，最开始之只能适应一般情况，而对特定程序的针对性不强。根据程序输入构建一个高质量的语料库，能够更好的指导变异生成的随即输入，发现更多路径数目，路径增长越快，就能获得更快的fuzzing速度。

基于编译插桩的fuzzing和基于Qemu的动态插桩fuzzing有多大差异？

就基本原理而言：

插桩分为动态插桩和静态插桩。基于编译插桩的 fuzzing 就是静态插桩，静态插桩发生在编译之前，PREPROCESS 这个阶段；基于 Qemu 插桩的 fuzzing 是动态插桩，在程序运行的时候发生，也就是每个 INPUTEVAL 阶段。因此，静态插桩相较于动态插桩有更优的开销，而动态插桩则更加容易对DLL进行插桩。除了基于源码的插桩，还有基于二进制文件的插桩，即未知源码的插桩技术。常见的动态插桩工具有DynInst 、Dynamo、RIOPIN、Valgrind、QEMU等。

就实验效果而言：

基于编译插桩的fuzzing速度远快于基于Qemu的动态插桩fuzzing。但是基于Qemu的动态插桩不需要程序源码，只需要可执行文件——这是它的优势。