因为认识的师傅们都开始卷 fuzz 了，迫于生活压力，于是也开始看这方面的内容了。由于 AFL 作为一个现在仍然适用且比较经典的 fuzzer，因此笔者也打算从它开始。

本来，本篇博文叫做 《AFL 源代码阅读笔记》，结果跟着大佬们的笔记去读（sakura师傅的笔记确实是神中神，本文也有很多地方照搬了师傅的原文，因为说实话我觉得自己也写不到那么详细），囫囵吞枣般速通了，前前后后三天时间这样，但感觉自己尚且没有自己实现的能力，还是比较令人失望的（我怎么这么菜）

首先，一般我们用 afl 去 fuzz 一些项目的时候都需要用 afl-gcc 去代替 gcc 进行编译。先说结论，这一步的目的其实是为了向代码中插桩，完成插桩后其实还是调用原生的 gcc 进行编译。

首先需要说明的是，gcc 对代码的编译流程的分层次的：

源代码-->预编译后的源代码-->汇编代码-->机器码-->链接后的二进制文件

其中，从源代码到汇编代码的步骤由 gcc 完成；而汇编代码到机器码的部分由 as 完成。

而 afl-gcc 的源代码如下：

挺长的，不过逻辑基本上都是重复的，主要做两件事：

在完成了汇编以后，接下来会使用 afl-as 对生成的汇编代码进行插桩：

在 afl-as 中，仍然使用 edit_params 编辑和修改参数，并使用 add_instrumentation 来对生成的汇编代码进行插桩。完成插桩后，用 fork 生成子进程，并调用原生的 as 进行编译。

插桩逻辑也很朴素：

简单来说就是一个循环读取每行汇编代码，并对特定的汇编代码进行插桩：

插桩的具体代码保存在 afl-as.h 中，在最后一节中笔者会另外介绍，这里我们可以暂时忽略它的实现细节继续往下。

按照顺序，现在程序是编译好了，接下来就要用 afl-fuzz 对它进行模糊测试了。

一般来说，我们会用 afl-fuzz -i input -o output -- programe 启动 fuzzer，对应的，afl-fuzz.c 中的前半部分都在做参数解析的工作：

这部分我们大致看一下就行了，主要的关注点自然不在参数解析部分。

设置一些信号处理函数，比如说退出信号时要主动释放子进程、窗口大小调整时要跟踪变化等。

读取环境变量ASAN_OPTIONS和MSAN_OPTIONS，做一些检查

略

保存当前的命令

创建一个 banner

检查是否在tty终端上面运行。

计数logical CPU cores。

检查崩溃处理函数，确保崩溃后不会进入程序。

笔者在 Ubuntu20 上跑 AFL 就会遇到这个问题，因为在默认情况下，系统会将崩溃信息通过管道发送给外部程序，由于这会影响到效率，因此通过 echo core >/proc/sys/kernel/core_pattern 修改保存崩溃信息的方式，将它保存为本地文件。

检查cpu的调节器，来使得cpu可以处于高效的运行状态。

如果用户指定了环境变量 AFL_POST_LIBRARY ，那么就会从对应的路径下加载动态库并加载 afl_postprocess 函数并保存在 post_handler 中。

初始化 virgin_bits 数组用于保存后续模糊测试中覆盖的路径，virgin_tmout 保存超时的路径，virgin_crash 保存崩溃的路径。

同时建立共享内存 trace_bits，该变量用于储存样例运行时的路径。

同时将共享内存的唯一标识符 shm_id 转为字符串后保存在环境变量 SHM_ENV_VAR 中。

初始化count_class_lookup16数组，帮助快速归类统计路径覆盖的数量。

创建输出目录。

读取测试样例。

afl-fuzz 维护一个 queue_entry 的链表，该链表用来保存测试样例，每次调用 add_to_queue 都会将新样例储存到链表头部。

另外还有一个 q_prev100 也是 queue_entry 的链表，但它每 100 个测试样例保存一次。

尝试在输入目录下寻找自动生成的字典文件，调用 maybe_add_auto 将相应的字典加入到全局变量 a_extras 中，用于后续字典模式的变异当中。

在输出文件夹中创建与输入样例间的硬链接，称之为 orignal 。

如果指定了 -x 参数（字典模式），加载对应的字典到全局变量extras当中，用于后续字典模式的变异当中。

如果指定了 resuming_fuzz ，即从输出目录当中恢复模糊测试状态，会从之前的模糊测试状态 fuzzer_stats 文件中计算中 timeout 值，保存在 exec_tmout 中。

检测输入的命令行中是否包含@@参数，如果包含的话需要将 @@ 替换成目录文件 "%s/.cur_input", out_dir ，使得模糊测试目标程序的命令完整；同时将目录文件 "%s/.cur_input" 路径保存在 out_file 当中，后续变异的内容保存在该文件路径中，用于运行测试目标文件。

如果目标程序的输入不是来源于文件而是来源于标准输入的话，则将目录文件 "%s/.cur_input" 文件打开保存在 out_fd 文件句柄中，后续将标准输入重定向到该文件中；结合 detect_file_args 函数实现了将变异的内容保存在 "%s/.cur_input" 文件中，运行目标测试文件并进行模糊测试。

检查二进制文件是否合法。

将每个测试样例作为输入去运行目标程序，检查程序是否能够正常工作：

对每个测试样例使用 calibrate_case 进行测试，并返回运行结果，然后处理其中异常的情况，比如说程序崩溃或运行超时等。

该函数用以对样例进行测试，在后续的测试过程中也会反复调用。此处，其主要的工作是：

fork server 是 AFL 中一个重要的机制。

afl-fuzz 主动建立一个子进程为 fork server，而模糊测试则是通过 fork server 调用 fork 建立子进程来进行测试。

参考在源代码注释中的这篇文章可以有更加深入的理解：
https://lcamtuf.blogspot.com/2014/10/fuzzing-binaries-without-execve.html

之所以需要设计它，笔者在这里给出一个比较概括的理由：

一般来说，如果我们想要测试输入样例，就需要用 fork+execve 去执行相关的二进制程序，但是执行程序是需要加载代码、动态库、符号解析等各种耗时的行为，这会让 AFL 不够效率。

但是这个过程其实是存在浪费的，可以注意到，如果我们要对相同的二进制程序进行多次不同的输入样本进行测试，那按照原本的操作，我们应该多次执行 fork+execve ，而浪费就出现在这，因为我们明明已经加载好了一切，却又要因此重复加载释放。

因此 fork server 的设计主要就是为了解决这个浪费。它通过向代码中进行插桩的方式，使得在二进制程序中去建立一个 fork server（对，它实际上是由目标程序去建立的），然后这个 fork server 会在完成一切初始化后，停止在某一个地方（往往设定在 main 函数）等待 fuzzer 去喊开始执行。

一旦 fuzzer 喊了开始，就会由这个 fork server 去调用 fork 然后往下执行。而我们知道，fork 由于写时复制的机制存在，它其实并没有过多的开销，可以完全继承原有的所有上下文信息，从而避开了多次 execve 的加载开销。

摘抄一段这部分插桩的内容：

fork server 主要是通过管道和 afl-fuzz 中的 fork server 进行通信的，但他们其实不做过多的事情，往往只是通知一下程序运行的状态。因为真正的反馈信息，包括路径的发现等这部分功能是通过共享内存去实现的，它们不需要用 fork server 这种效率较低的方案去记录数据。

剩下的就是关闭一些不需要的文件或管道了，代码姑且贴在这里，以备未来有需要时可以现查：

将运行过的种子根据运行的效果进行排序，后续模糊测试根据排序的结果来挑选样例进行模糊测试。

初始化 UI 。

如果是恢复运行，则调用该函数来寻找到对应的样例的位置。

更新统计信息文件以进行无人值守的监视。

保存自动提取的 token ，用于后续字典模式的 fuzz 。

从测试样例的队列中取出 current_entry 进行测试，成功则返回 0 ，否则返回 1。这里主要是对该函数主要内容进行记录，不做细节的代码分析。

缩减的思路是这样的：如果对一个样本进行缩减后，它所覆盖的路径并未发生变化，那么就说明缩减的这部分内容是可有可无的，因此可以删除。

具体策略如下：

这个阶段读起来感觉比较抽象。首先定义了这么一个宏：

这个宏的操作是对一个 bit 进行反转。

而接下来首先有一个循环：

stage_max 是输入的总 bit 数，然后分别对每个 bit 进行翻转后用 common_fuzz_stuff 进行测试，然后再将其翻转回来。

而如果对某个字节的最后一个 bit 翻转后测试，发现路径并未增加，就能够将其认为是一个 token 。

然后在后面的一个循环中又做类似的事，但每次会翻转两个 bit：

然后进入 bitflip 16/8 部分，按对每两个字节进行一次翻转然后测试：

最后是 bitflip 32/8 阶段，每 4 个字节进行翻转然后测试：

此处展示 arith 8/8 部分代码：

此处给出 interest 8/8 部分代码：

此处给出 auto extras (over) 部分的源代码：

该部分使用一个巨大的 switch ，通过随机数进行跳转，并在每个分支中使用随机数来完成随机性的行为：

最后一个阶段，它会随机选择出另外一个输入样例，然后对当前的输入样例和另外一个样例都选择出合适的偏移量，然后从该处将他们拼接起来，然后重新进入到 RANDOM HAVOC 阶段。

读取其他 sync 文件夹下的 queue 文件，然后保存到自己的 queue 里。

总结来说，这个函数就是先读取有哪些 fuzzer 文件夹，然后读取其他 fuzzer 文件夹下的 queue 文件夹里的 case，并依次执行，如果发现了新 path，就保存到自己的 queue 文件夹里，而且将最后一个 sync 的 case id 写入到 .synced/其他fuzzer文件夹名 文件里，以避免重复运行。

因为 fuzz_one 部分过于庞大，而这个函数又不是那么特殊，因此把它拉出来做一个简短的说明。

执行结果是否发现了新路径，决定是否保存或跳过。如果保存了这个 case，则返回 1，否则返回 0。

其实插桩已经叙述过一部分了，在上文中的 fork server 部分，笔者就介绍过该机制就是通过插桩实现的。

但还有一部分内容没有涉及，新路径是如何在发现的同时被通知给 fuzzer 的？

在插桩阶段，我们为每个分支跳转都添加了一小段代码，这里笔者以 64 位的情况进行说明：

它首先保存了一部分将要被破坏的寄存器，然后调用了 __afl_maybe_log 来记录路径的发现。该函数同样是由汇编编写的，但我们可以用一些其他工具来反编译它：

前面的一大段代码其实都是为了去建立我们在上文所说的“共享内存”，在完成初始化后调用最后这么一小段代码进行记录：

此处 v6 即为共享内存的地址，而 a4 为 cur_location ，因此 v7=cur_location ^ prev_location ，它将作为索引，使得共享内存中的对应偏移处的值增加。而在 fuzzer 部分就可以通过检查这块内存来发现是否有新路径被得到了。

另外，_afl_prev_loc = _afl_prev_loc >> 1; 的目的是为了避开 A->A 和 B->B 以及 A->B 和 B->A 被识别为相同路径的情况。

sakuraのAFL源码全注释
https://eternalsakura13.com/2020/08/23/afl/

fuzzer AFL 源码分析
https://tttang.com/user/f1tao

AFL二三事——源码分析
https://paper.seebug.org/1732/#afl-afl-asc

AFL漏洞挖掘技术漫谈（一）：用AFL开始你的第一次Fuzzing
https://paper.seebug.org/841/

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课