AFL二三事 -- 源码分析 3

本文为《AFL二三事》-- 源码分析系列的第三篇，主要阅读AFL的fuzzer部分的源码，学习AFL的fuzz核心。

当别人都要快的时候，你要慢下来。

AFL中最重要的部分便是fuzzer的实现部分——afl_fuzz.c ，其主要作用是通过不断变异测试用例来影响程序的执行路径。该文件代码量在8000行左右，处于篇幅原因，我们不会对每一个函数进行源码级分析，而是按照功能划分，介绍其中的核心函数。该文件属于AFL整个项目的核心中的核心，强烈建议通读该文件。

在介绍源码的同时，会穿插AFL的整体运行过程和设计思路，辅助理解源码的设计思路。

在功能上，可以总体上分为3部分：

我们将按照以上3个功能对其中的关键函数和流程进行分析。

该循环主要通过 getopt 获取各种环境配置、选项参数等。

调用 sigaction ，注册信号处理函数，设置信号句柄。具体的信号内容如下：

读取环境变量 ASAN_OPTIONS 和 MSAN_OPTIONS，做一些必要性检查。

如果通过 -M或者-S指定了 sync_id，则更新 out_dir 和 sync_dir 的值：设置 sync_dir 的值为 out_dir，设置 out_dir 的值为out_dir/sync_id。

copy当前命令行参数，保存。

检查是否在tty终端上面运行：读取环境变量 AFL_NO_UI ，如果存在，设置 not_on_tty 为1，并返回；通过 ioctl 读取window size，如果报错为 ENOTTY，表示当前不在一个tty终端运行，设置 not_on_tty。

该函数用于设置共享内存和 virgin_bits，属于比较重要的函数，这里我们结合源码来解析一下：

这里通过 trace_bits 和 virgin_bits 两个 bitmap 来分别记录当前的 tuple 信息及整体 tuple 信息，其中 trace_bits 位于共享内存上，便于进行进程间通信。通过 virgin_tmout 和 virgin_crash 两个 bitmap 来记录 fuzz 过程中出现的所有目标程序超时以及崩溃的 tuple 信息。

该函数用于准备输出文件夹和文件描述符，结合源码进行解析：

该函数的源码中，开发者对关键位置均做了清楚的注释，很容易理解，不做过多解释。

该函数会将 in_dir 目录下的测试用例扫描到 queue 中，并且区分该文件是否为经过确定性变异的input，如果是的话跳过，以节省时间。
调用函数 add_to_queue() 将测试用例排成queue队列。该函数会在启动时进行调用。

该函数主要用于将新的test case添加到队列，初始化 fname 文件名称，增加cur_depth 深度，增加 queued_paths 测试用例数量等。

首先，queue_entry 结构体定义如下：

然后在函数内部进行的相关操作如下：

在输出目录中为输入测试用例创建硬链接。

变量 timeout_given 没有被设置时，会调用到该函数。该函数主要是在没有指定 -t 选项进行 resuming session 时，避免一次次地自动调整超时时间。

识别参数中是否有“@@”，如果有，则替换为 out_dir/.cur_input ，没有则返回：

检查指定路径要执行的程序是否存在，是否为shell脚本，同时检查elf文件头是否合法及程序是否被插桩。

调用 get_cur_time() 函数获取开始时间，检查是否处于 qemu_mode。

该函数是AFL中的一个关键函数，它会执行 input 文件夹下的预先准备的所有测试用例，生成初始化的 queue 和 bitmap，只对初始输入执行一次。函数控制流程图如下：

下面将结合函数源码进行解析（删除部分非关键代码）：

总结以上流程：

该函数同样为AFL的一个关键函数，用于新测试用例的校准，在处理输入目录时执行，以便在早期就发现有问题的测试用例，并且在发现新路径时，评估新发现的测试用例的是否可变。该函数在 perform_dry_run，save_if_interesting，fuzz_one，pilot_fuzzing，core_fuzzing函数中均有调用。该函数主要用途是初始化并启动fork server，多次运行测试用例，并用 update_bitmap_score 进行初始的byte排序。

函数控制流程图如下：

结合源码进行解读如下：

总结以上过程如下：

AFL的fork server机制避免了多次执行 execve() 函数的多次调用，只需要调用一次然后通过管道发送命令即可。该函数主要用于启动APP和它的fork server。函数整体控制流程图如下：

结合源码梳理一下函数流程：

我们结合fuzzer对该函数的调用来梳理完整的流程如下：

启动目标程序进程后，目标程序会运行一个fork server，fuzzer自身并不负责fork子进程，而是通过管道与fork server通信，由fork server来完成fork以及继续执行目标程序的操作。

对于fuzzer和目标程序之间的通信状态我们可以通过下图来梳理：

结合前面的插桩部分一起来看：

首先，afl-fuzz 会创建两个管道：状态管道和控制管道，然后执行目标程序。此时的目标程序的 main() 函数已经被插桩，程序控制流进入 __afl_maybe_log 中。如果fuzz是第一次执行，则此时的程序就成了fork server们之后的目标程序都由该fork server通过fork生成子进程来运行。fuzz进行过程中，fork server会一直执行fork操作，并将子进程的结束状态通过状态管道传递给 afl-fuzz。

（对于fork server的具体操作，在前面插桩部分时已经根据源码进行了说明，可以回顾一下。）

该函数主要执行目标应用程序，并进行超时监控，返回状态信息，被调用的程序会更新 trace_bits[] 。

结合源码进行解释：

当我们发现一个新路径时，需要判断发现的新路径是否更“favorable”，也就是是否包含最小的路径集合能遍历到所有bitmap中的位，并在之后的fuzz过程中聚焦在这些路径上。

以上过程的第一步是为bitmap中的每个字节维护一个 top_rated[] 的列表，这里会计算究竟哪些位置是更“合适”的，该函数主要实现该过程。

函数的控制流程图如下：

结合源码进行解释：

在前面讨论的关于case的 top_rated 的计算中，还有一个机制是检查所有的 top_rated[] 条目，然后顺序获取之前没有遇到过的byte的对比分数低的“获胜者”进行标记，标记至少会维持到下一次运行之前。在所有的fuzz步骤中，“favorable”的条目会获得更多的执行时间。

函数的控制流程图如下：

结合源码解析如下：

这里根据网上公开的一个例子来理解该过程：

现假设有如下tuple和seed信息：

tuple: t0, t1, t2, t3, t4

seed: s0, s1, s2

将按照如下过程进行筛选和判断：

进入主循环前的准备工作使用的函数之一，主要作用为在处理输入目录的末尾显示统计信息，警告信息以及硬编码的常量；

进入主循环前的准备工作使用的函数之一，主要作用为在resume时，尝试查找要开始的队列的位置。

也是准备工作函数之一，主要作用为更新统计信息文件以进行无人值守的监视。

该函数主要保存自动生成的extras。

这里是seed变异的主循环处理过程，我们将结合流程图和源码进行详细解读。

主循环的控制流程图如下（将while部分单独设置为了一个函数，只看循环部分即可）：

主循环源码：

总结以上内容，该处该过程整体如下：

该函数源码在1000多行，出于篇幅原因，我们简要介绍函数的功能。但强烈建议通读该函数源码，

函数主要是从queue中取出entry进行fuzz，成功返回0，跳过或退出的话返回1。

整体过程：

这里涉及到AFL中的变异策略，不在本次的讨论中，感兴趣的小伙伴可以结合源码自行进行研究。

该函数的主要作用是进行queue同步，先读取有哪些fuzzer文件夹，然后读取其他fuzzer文件夹下的queue文件夹中的测试用例，然后以此执行。如果在执行过程中，发现这些测试用例可以触发新路径，则将测试用例保存到自己的queue文件夹中，并将最后一个同步的测试用例的id写入到 .synced/fuzzer文件夹名 文件中，避免重复运行。

分析完源码，可以感受到，AFL遵循的基本原则是简单有效，没有进行过多的复杂的优化，能够针对fuzz领域的痛点，对症下药，拒绝花里胡哨，给出切实可行的解决方案，在漏洞挖掘领域的意义的确非同凡响。后期的很多先进的fuzz工具基本沿用了AFL的思路，甚至目前为止已基本围绕AFL建立了“生态圈”，涉及到多个平台、多种漏洞挖掘对象，对于安全研究员来说实属利器，值得从事fuzz相关工作的研究员下足功夫去体会AFL的精髓所在。

考虑到篇幅限制，我们没有对AFL中的变异策略进行源码说明，实属遗憾。如果有机会，将新开文章详细介绍AFL的变异策略和源码分析。

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