AFL

现有 fuzz 大多以代码覆盖率为引导指标。以AFL为例,它使用映射至 hashmap 中的基于 edge 的覆盖率信息来引导测试。这种覆盖率信息不太准确,因为只统计至 edge 层面,同时还会产生覆盖 hash 冲突,丢失覆盖率信息,给模糊测试带来一些不良限制。
相关源代码以及构建方式已开源至 github 上。重申一下,该 fuzz 目前处于实验性版本,可能有亿点点不太稳定(笑)。
此文章主要是对AFL仓库中doc目录下的所有文档进行翻译。
本文全文参考了da1234cao师傅的Github仓库https://github.com/da1234cao/translation/tree/master/AFL 的相关内容,我对全文中机翻程度过高以致未正确表达原文语义、异译程度过高以致偏离原文语义、语句不通顺或不合语法的大量文本进行了修改,特此说明。以下文章中的“原译者”即代指da1234cao师傅。
在前两篇文章中,我分析了afl-gcc的相关处理逻辑。简单来说,afl-gcc会将必要的函数以及桩代码插入到我们的源汇编文件中,这样,经过编译的程序将会带有一些外来的函数。但是。这些函数到底是怎样生效的呢,在本篇文章中,我将对AFL的主逻辑,也就是afl-fuzz进行分析。
本文将接续第一篇文章,继续分析afl-gcc向程序中插入的关键代码。
本文只分析能获得目标程序源码、开启forkserver下的AFL的一些内部实现,主要以afl-gcc为例对插桩代码进行解读,涉及到的源文件主要有afl-fuzz.c,afl-as.c,afl-as.h 和 afl-gcc.c。
虽然网上有很多关于AFL源码的分析,但是绝大多数文章都是抽取了部分代码进行分析的,本文则逐行对源码进行了分析,下一篇文章将针对afl-as源码做下一步分析并给出相关实例。
此篇为sakuraのAFL源码全注释系列的第三篇。
此篇为sakuraのAFL源码全注释系列的第二篇。