basic block(基本块)、edge(边)、代码覆盖率

edge就被用来表示在基本块之间的跳转，知道了每个基本块和跳转的执行次数，就可以知道程序中的每个语句和分支的执行次数，从而获得比记录BB更细粒度的覆盖率信息

代码覆盖率是一种度量代码的覆盖程度的方式，也就是指源代码中的某行代码是否已执行；对二进制程序，还可将此概念理解为汇编代码中的某条指令是否已执行。

覆盖率劫持：

劫持汇编器（afl-gcc、afl-clang、afl-g++），通过识别跳转指令，然后在其中插入一段汇编用于与AFL之间的通信(__afl_maybe_log)

clang内置，LLVM 内置了一个简单的代码覆盖率检测 （SanitizerCoverage），它在函数、基本块和边缘级别插入对用户定义函数的调用。提供了这些回调的默认实现，并实现了简单的覆盖率报告和可视化

编译器将在 -fsanitize-coverage=trace-pc-guard 每个边缘插入以下代码：

每条边都有自己的 guard_variable，每当对应的edge被执行到时，都会向共享内存中对list[*guard_variable]进行++操作

这个函数会在可执行文件开始执行时会调用一次，每一个有向边对应一个*guard值，参数start是第一个guard指针，代表第一条边；stop是最后一个guard指针，代表最后一条边，遍历start到stop就可以给每个guard指针指向的值初始化一个随机数（但是实际上这个值可以由用户来决定）

但是不可避免的，会有概率出现冲突的情况，因此Sakura师傅对其进行了替换：

要想对每条edge进行插桩，需要先在make afl时传入AFL_TRACE_PC=1来定义DUSE_TRACE_PC宏（make AFL_TRACE_PC=1），然后在执行afl-clang-fast的时候传入-fsanitize-coverage=trace-pc-guard参数即可。正常make会启用afl-llvm-pass而非afl-llvm-rt

GCOV、LCOV

覆盖率记录的实现除了前两种方式之外还可以使用GCOV、LCOV这两个东西可视化展示代码覆盖率，但是不能使用到fuzzer上。

一些fuzz的覆盖率反馈和引导变异的一些概念：

fuzz有生成式fuzz和变异式fuzz两种，生成式fuzz就是一开始什么种子也没有，纯根据fuzzer的逻辑来生成种子（输入），fuzz过程中没有任何的反馈，也不会根据某时某刻的代码覆盖率来把interesting case变异发现新的路径。 AFL采用的是变异式fuzz

进行fuzz时，对样本进行变异，然后在找到新的路径时，将当前变异后数据当成一个新的样本继续变异。经过逐代的变异杂交选优，直到达到一个局部最优解为止（已发现的路径达到max），这就是所谓的**遗传算法**。

因为遗传算法的特征总是来自于初始种子样本和变异策略，所以改进也主要在这两方面。种子也可以是一些代码语句：

如果变异器不会引入新的token（特征），那永远就只会生成select这一种特征，而不会生成如SQL语句中的insert、delete等。所以种子的变异策略也十分的重要，它极大的影响着fuzz的代码覆盖率。

除了对种子的不断变异，我们还需要了解AFL如何将自动或半自动生成的随机数据输入到被fuzzer的程序中并监视如崩溃，断言（assertion）等程序异常这个过程，也就是进行输入和捕获crash。AFL采用的是fork server这种机制，具体方式如下：

进程关系：fuzzer进程 -> fork server -> 被fuzz的程序

常用的AFL魔改技巧有哪些？

write_to_testcase函数会将变异生成的新样本写入到.cur_input隐藏文件夹中，所以我们在文件写入之前可以在外面套上一层函数以便让AFL的原始字节码的变异适用于更多的场景。afl-fuzz适合基于字节粒度变异的fuzz（如fuzz一个简单的输入输出程序），但并不是所有目标都可以直接进行字节粒度的fuzz。有些是因为文件解析部分的代码不能单独抽出来，有些是因为文件解析仅仅是逻辑的开始。那么为变异器加层就是在这方面扩展afl-fuzz的最简单方法，最经典的例子如webassembly。

为了fuzz这些结构化的东西（类似SQL）我们需要进行结构感知（structure-aware），即针对特定输入类型的语法进行感知

如何使用AFL fuzz client-server模式的程序，或者如何使用AFL去fuzz网络协议呢？

lient-server模式中的client -> server大致流程如下：

这篇文章值得参考：05eK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6%4N6%4N6Q4x3X3g2X3j5i4y4@1L8s2W2Q4x3X3g2U0L8$3#2Q4x3V1k6T1L8r3!0Y4i4K6u0r3K9r3!0%4i4K6u0V1k6Y4g2*7P5W2)9J5k6s2y4W2M7Y4k6W2M7W2)9J5k6r3q4E0k6i4u0A6j5$3q4F1i4K6u0V1k6Y4g2*7P5Y4W2Q4x3X3c8D9L8%4l9`.

文章中提到一个为Persistent mode（持久模式）的概念，如果要向AFL集成这种功能，我们可以按照如下流程编写自己的代码：

该方法需要用afl直接启动server程序，patch server程序接收请求包的代码，改为直接从标准输入里读取，server执行足够多次请求后退出，AFL再启动一个新的server再次fuzz。

fuzz要真正解决的问题和一些Sakura师傅的建议

Address Sanitizer又名ASan，是一个快速的C/C++内存错误检查器。它可以检测到：UAF、Heap buffer overflow、Stack buffer overflow、Global buffer overflow、Use after return、Use after scpoe、Initialization order bugs、Memory leak等漏洞类型。asan可以简单理解成对malloc和free以及存取指令等的hook，从而在发现分配出来的内存的大小，小于要存取的index的大小时，检测出越界读写问题。

要理解被测试程序的代码，并不是说随便拿到一个程序拿fuzz跑起来是有意义的，例如传入数据的parser（解析器、语法分析器），必要时通过逆向来单独取出一部分代码来测试功能。比如Windows的media player，这是一个图形化的应用程序，我们不能通过命令行窗口来对该程序进行流程的控制与输入，但是这些功能的实现肯定都是存在于某一个dll（动态链接库）中的，所以可以利用dlopen函数写harness来加载dll：

harness作用：如果我们想fuzz dll (加载的库)中的函数输入，因为没有定义入口点，我们需要编写测试工具来将输入从命令行传递到 DLL 函数。

善于根据场景改进fuzz，以将只用与文件格式fuzz的AFL利用加层或映射让其扩展到更多的场景中，实现自己的自定义编译。

根据不同的目标掌握不同的知识，找到主流使用的fuzzer并进行改进

自定义检测工具

Address Sanitizer又名ASan，是一个快速的C/C++内存错误检查器。它可以检测到：UAF、Heap buffer overflow、Stack buffer overflow、Global buffer overflow、Use after return、Use after scpoe、Initialization order bugs、Memory leak等漏洞类型。asan可以简单理解成对malloc和free以及存取指令等的hook，从而在发现分配出来的内存的大小，小于要存取的index的大小时，检测出越界读写问题。

asan是对malloc、free等指令的hook，但是如果像js引擎这种直接mmap一块大内存然后自己来管理内存的情况，那么如何检测出潜在的越界读写问题呢？这种时候就需要理解代码，然后自己实现一套针对性的自定义asan了。

调用find_as命令，argv[0]是afl-gcc的路径

这个宏定义实现了一个动态内存分配的格式化字符串函数，类似于 sprintf，但它会自动分配足够的内存来存储格式化后的字符串，其中调用ck_alloc函数

此处要求DEBUG_BUILD为假

接下来还有这个定义

因此得到：

非调试模式下的执行流程：

调试模式下的执行流程：

主要看DFL_ck_alloc函数

在对应位置写了magic token以及size：

DFL_ck_alloc_nozero函数返回后会调用memset将堆内存清零，说白了DFL_ck_alloc就是外面包了一个memset得到了DFL_ck_alloc_nozero

主要的还是DFL_ck_alloc函数

然后调用TRK_alloc_buf函数

首先看到以下的数据结构：

TRK_obj结构体：

哈希桶系统：

哈希函数：

查找空闲槽位：

动态扩容（如果没有足够的空间）：

内存布局大致如下：

释放前的内存布局：

释放后的内存布局：

说白了就是在free外面套一层wrapper

宏AFL_PATH（非环境变量AFL_PATH）在编译时由Makefile文件确定，值默认为/usr/local/lib/afl/，拼接后就有：/usr/local/lib/afl/as

该函数会按照一定的规则在系统中寻找afl-as汇编器的位置：

edit_params是AFL编译器包装器的核心函数，负责处理和修改编译参数，将用户的编译命令转换为带有AFL插桩功能的编译命令。

功能：

初始化状态标志变量

分配参数数组内存（原参数数 + 128个额外槽位）

使用AFL的安全内存分配函数

编译器选择逻辑：

原因：在macOS上，gcc通常是clang的别名，需要明确指定编译器路径。

参数处理策略：

跳过的参数：-B, -integrated-as, -pipe

检测的参数：-fsanitize=*, FORTIFY_SOURCE

特殊标记：FreeBSD x64下的-m32

保留的参数：其他所有参数

功能：

强制使用AFL的汇编器包装器

Clang模式下禁用集成汇编器

加固措施：

启用栈保护：-fstack-protector-all

启用FORTIFY_SOURCE：-D_FORTIFY_SOURCE=2（如果未设置）

互斥性检查：

ASAN与MSAN不能同时使用

ASAN/MSAN与AFL_HARDEN不能同时使用

默认优化设置：

启用调试信息：-g

高级优化：-O3

循环展开：-funroll-loops

定义模糊测试宏

FreeBSD特殊处理：在64位FreeBSD系统上，clang -g -m32有bug，需要特殊处理。

目的：

禁用字符串比较函数的编译器优化

确保这些函数调用能被AFL的插桩捕获

就是执行编译相应的源文件

至此afl-gcc就分析完毕

这里用cyberangel师傅提供的例子做一个记录

会发现最后execvp的命令是这一串，我们可以通过-B来指定我们自己的as（汇编器）

gcc编译大多都认为是以下四个步骤：

会发现上述的gcc只指定了特殊的as（即汇编器），因此可以猜测出是通过劫持汇编器来达到在特殊位置插入特殊函数的结果，因此接下来看一手afl的as源码

核心数据结构和全局变量：

功能：

解析命令行参数，准备传递给真实汇编器的参数

检测目标架构（32位/64位）

处理 macOS 特殊情况（使用 clang 而不是 as）

确定临时文件路径

环境变量TEMP和TMP的使用均需要用户在执行afl-as前手动设置，如果均不存在则默认设置tmp_dir变量为/tmp目录

生成临时文件名：/tmp/.afl-<pid>-<timestamp>.s

以下是核心数据结构：

插桩注入，这是程序的核心函数：

文件打开和初始化

这是延迟插桩的机制，fgets的第一个参数line被定义为static u8 line[MAX_LINE];，宏MAX_LINE在config.h中被默认定义为8192。将line展开，可以得到static uint8_t line[8192]，也就是说fgets函数会读取input_file的一行代码存放到line数组（最多读取MAX_LINE个字符）：

触发条件：

如果满足以上所有条件，就会直接将插桩代码写入outf变量，然后再通过fputs函数写入对应文件中

如果是直通模式就会直接将汇编写入进入下一行了

段类型处理：

假设当前是.text段，那么会标记instr_ok=1，说明当前段是可以插桩的代码，那么continue之后，接下来的片段就是.text段即代码段的内容了，就可以进行插桩了

接下来就是特殊情况的处理：

OpenBSD的特殊性：

OpenBSD 将跳转表（jump tables）直接内联在代码中

跳转表是编译器生成的用于 switch 语句优化的数据结构

这些表被放在 .text 段中，但不应该被当作普通代码插桩

例如：

如果不进行特殊处理，会出现以下情况：

会破坏p2align指令的对齐效果；跳转表是数据，不是代码，不应该被插桩；错误的插桩会导致跳转表寻址错误

混合架构代码：

同一个汇编文件可能包含32位和64位代码段（比如armv8向前兼容）

在调试器（如GDB）中经常遇到

需要根据当前编译目标跳过不匹配的代码段

由于gcc本身默认使用AT&T语法，AFL的插桩代码也是用AT&T语法写的

或许我可以写一个patch来兼容这部分（）

例子：

内联汇编一般都是

因为内联汇编一般都是程序员手写的，不符合编译器生成代码的模式；同时#还检测了注释

接下来就是一个流程图：

然后回到main函数

fork一个子进程执行as --64 -o /home/cyberangel/Desktop/test/exec_obj.o /tmp/.afl-27115-1673249415.s命令

传播安全知识、拓宽行业人脉——看雪讲师团队等你加入！