网上afl-fuzz的资料比较少，大多是解释afl带的技术白皮书，介绍afl的原理和使用到的技术，但对于想要了解afl内部实现并加以利用和改进还是远远不够的。所以本人在学习afl过程中，把一些重要的东西记录下来，方便阅读和理解afl的代码。如果有写的不对的地方，欢迎指证。
1. afl的fuzz工作流程
1. main函数先进行初始化和选项处理；
2. 执行input文件夹下的预先准备的所有testcase（perform_dry_run），生成初始化的queue和bitmap；
3. 通过cull_queue对queue进行精选，减小input的量；
4. 然后进行while(1)循环不断进行fuzz。其中while(1)循环包括以下流程，每fuzz一个queue，就会重新进入while(1)，并重新cull_queue()精选队列。
1. cull_queue()对queue进行精选，选出favored。
2. 判断queue_cur是否为NULL，如果是，则表示已经完成对队列的遍历，queue_cycle++,初始化相关参数，重新开始遍历队列；
3. fuzz queue_cur对应的input文件，**fuzz_one()**;
4. 判断是否结束，并更新queue_cur和current_entry注：当队列中的所有文件都经过变异测试了，则完成一次”cycle done”;
整个队列又会从第一个文件开始，再次进行变异，不过与第一次变异不同的是，这一次就不需要再进行deterministic fuzzing了。
1.1 预料删选 cull_queue()
为了优化模糊工作，AFL使用快速算法定期重新评估队列，该算法选择一个较小的测试用例子集，该子集仍覆盖到目前为止所看到的每个元组，并且其特征使它们对Fuzzing特别有利。该算法通过为每个队列条目分配与其执行延迟和文件大小成正比的分数来工作;然后为每个tuples选择最低得分候选者。
cull_queue()遍历top_rated[]中的queue，然后提取出发现新的edge的entry，并标记为favored，使得在下次遍历queue时，这些entry能获得更多执行fuzz的机会。
这里本质上采用了贪婪算法，如果top_rated[i]存在，且对应temp_v[]中对应bit位还没抹去，即这一轮选出的queue还没覆盖bit_map[i]对应的边，则取出这个top_rated[i]。抹去temp_v中top_rated[i]能访问到的位。最后将这个top_rated[i]标记为favored,如果这个queue还没fuzzed，pending_favored++.
cull_queue()函数核心代码如下:
/* line 1309 - 1328*/注：需要结合下面2节进行理解。
1.1.1 trace_bits[]与top_rated[]
一个queue经过run之后，会生成新的trace_bits来记录这个queue的trace情况，也就是这个queue访问了那些edge。
通过遍历trace_bits[]，可以访问到每个edge。
top_rate[]数组维护的是所有边的访问情况。其对应关系为，top_rated[i]选取出所有访问到bit_map[i]所代表边的queue中代价（执行时间*文件长度）最小的一个queue。
1.1.2 bitmap更新 update_bitmap_score()
update_bitmap_socre()函数在每次run_target()之后调用，根据上述规则更新top_rate[].如果一个queue入选top_rate[]，被替换掉queue的tc_ref–, 新queue的tc_ref++，并生成简化的trace_mini。
如果有发生新的queue入选top_rate[],score_changed置一，在cull_queue()时，会先判断score_changed是否为1，如果不为1，就不用进行cull_queue()了。
trace_mini的组织方式：trace_mini的大小为MAP_SIZE / 8，即每个bit对应了bit_map中的一个byte；如果这个queue访问了bit_map中的一个byte(即访问了一个edge)，trace_mini中对应的bit位就置一。
1.2 变异测试用例 fuzz_one()
对当前选出的queue_cur执行fuzz操作，fuzz_one()的具体步骤为：
1. 按照是否有pending_favored和queue_cur的情况（was_fuzzed, favored）选择是否跳过分析，具体跳过的规则见1.2.1；
2. 加载test case
3. CALIBRATION
4. 输入文件修剪，减小input文件大小 trim_case()
5. case打分performance score()，如果该queue已经完成deterministic阶段，则直接跳到havoc阶段
6. bitfilp: 位翻转，同时自动检测token（识别IHDR），生成effector map中
7. arithmetic： 算术变异，加上或者减去一个整数
8. interest：对比特位进行替换，替换为interest的数据（提前定义好的，通常为数据类型的边界）
9. dictionary：字典替换或插入，来源用户提供的token、自动检测生成的token。
10. havoc：大破坏！多种变异方式的组合
11. splice：拼接，2个seed进行拼接，并进行havoc注：havoc之前的变异为deterministic fuzzing，即每次执行，变异过程和结果都一样。
1.2.1 queue跳过规则
1. 如果有pending_favored, 则99%跳过fuzzed或者不是favored的queue；
2. 如果没有如果有pending_favored，则95%跳过已经fuzzed的不是favored的queue,75%跳过没有fuzzed的不是favored的queue，不跳过favored的queue。1.2.2 calilbrate_case()
多次执行这个case，并通过update_bitmap_score()更新bitmap。
在save_if_interesting()/perform_dry_run()/fuzz_one()中被调用。
不是很懂这个函数的意义？？？
1.2.3 输入文件修剪 trim_case()
文件大小对模糊性能有很大影响，这是因为大文件使目标二进制文件变得更慢，并且因为它们减少了突变将触及重要的格式控制结构而不是冗余数据块的可能性。这在perf_tips.txt中有更详细的讨论。
用户可能会提供低质量的起始语料库，某些类型的突变可能会产生迭代地增加生成文件的大小的效果，因此应对这一趋势是很重要的。
幸运的是，插装反馈提供了一种简单的方法来自动删除输入文件，同时确保对文件的更改不会对执行路径产生影响。
在afl-fuzz中内置的修边器试图按可变长度和stepover顺序删除数据块;任何不影响跟踪映射校验和的删除都被提交到磁盘。修剪器的设计并不是特别彻底;相反，它试图在精度和在进程上花费的execve（）调用的数量之间取得平衡，选择块大小和stepover来匹配。每个文件的平均增益大约在5%到20%之间。
独立的afl-tmin工具使用了更详尽的迭代算法，并尝试在修剪过的文件上执行字母标准化。afl-tmin的操作如下。
首先，工具自动选择操作模式。如果初始输入崩溃了目标二进制文件，afl-tmin将以非插装模式运行，只需保留任何能产生更简单文件但仍然会使目标崩溃的调整。如果目标是非崩溃的，那么这个工具使用一个插装的模式，并且只保留那些产生完全相同的执行路径的微调。
实际的最小化算法是：
1.尝试将大块数据与大量的步骤归零。从经验上看，这可以通过在以后的时间内抢先进行更细粒度的工作来减少执行的次数。
2.执行块删除过程，减少块大小和stepovers，二进制搜索式(binary-search-style)。
3.通过计算唯一字符并尝试用零值批量替换每个字符来执行字母表规范化。
4.作为最后的结果，对非零字节执行逐字节标准化。1.2.4 case打分 calculate_score()
根据case的执行速度/bitmap的大小/case产生时间/路径深度等因素给case进行打分，用来调整在havoc阶段的用时。
使得执行时间短，代码覆盖高，新发现的，路径深度深的case拥有更多havoc变异的机会。
1.2.5 bitflip 阶段
基本原理：bitflip，按位翻转，1变为0，0变为1。
拿到一个原始文件，打头阵的就是bitflip，而且还会根据翻转量/步长进行多种不同的翻转，按照顺序依次为：
- bitflip 1/1，每次翻转1个bit，按照每1个bit的步长从头开始
- bitflip 2/1，每次翻转相邻的2个bit，按照每1个bit的步长从头开始
- bitflip 4/1，每次翻转相邻的4个bit，按照每1个bit的步长从头开始
- bitflip 8/8，每次翻转相邻的8个bit，按照每8个bit的步长从头开始，即依次对每个byte做翻转
- bitflip 16/8，每次翻转相邻的16个bit，按照每8个bit的步长从头开始，即依次对每个word做翻转
- bitflip 32/8，每次翻转相邻的32个bit，按照每8个bit的步长从头开始，即依次对每个dword做翻转
作为精妙构思的fuzzer，AFL不会放过每一个获取文件信息的机会。这一点在bitflip过程中就体现的淋漓尽致。具体地，在上述过程中，AFL巧妙地嵌入了一些对文件格式的启发式判断。包括自动检测token和生成effector map。
自动检测token
在进行bitflip 1/1变异时，对于每个byte的最低位(least significant bit)翻转还进行了额外的处理：如果连续多个bytes的最低位被翻转后，程序的执行路径都未变化，而且与原始执行路径不一致(检测程序执行路径的方式可见上篇文章中“分支信息的分析”一节)，那么就把这一段连续的bytes判断是一条token。
例如，PNG文件中用IHDR作为起始块的标识，那么就会存在类似于以下的内容：
........IHDR........当翻转到字符I的最高位时，因为IHDR被破坏，此时程序的执行路径肯定与处理正常文件的路径是不同的；随后，在翻转接下来3个字符的最高位时，IHDR标识同样被破坏，程序应该会采取同样的执行路径。由此，AFL就判断得到一个可能的token：IHDR，并将其记录下来为后面的变异提供备选。
AFL采取的这种方式是非常巧妙的：就本质而言，这实际上是对每个byte进行修改并检查执行路径；但集成到bitflip后，就不需要再浪费额外的执行资源了。此外，为了控制这样自动生成的token的大小和数量，AFL还在config.h中通过宏定义了限制：
/* Length limits for auto-detected dictionary tokens: */
#define MIN_AUTO_EXTRA 3 #define MAX_AUTO_EXTRA 32
/* Maximum number of auto-extracted dictionary tokens to actually use in fuzzing (first value), and to keep in memory as candidates. The latter should be much higher than the former. */
#define USE_AUTO_EXTRAS 10
#define MAX_AUTO_EXTRAS (USE_AUTO_EXTRAS * 10)对于一些文件来说，我们已知其格式中出现的token长度不会超过4，那么我们就可以修改MAX_AUTO_EXTRA为4并重新编译AFL，以排除一些明显不会是token的情况。遗憾的是，这些设置是通过宏定义来实现，所以不能做到运行时指定，每次修改后必须重新编译AFL。
生成effector map
在进行bitflip 8/8变异时，AFL还生成了一个非常重要的信息：effector map。这个effector map几乎贯穿了整个deterministic fuzzing的始终。
具体地，在对每个byte进行翻转时，如果其造成执行路径与原始路径不一致，就将该byte在effector map中标记为1，即“有效”的，否则标记为0，即“无效”的。
这样做的逻辑是：如果一个byte完全翻转，都无法带来执行路径的变化，那么这个byte很有可能是属于”data”，而非”metadata”（例如size, flag等），对整个fuzzing的意义不大。所以，在随后的一些变异中，会参考effector map，跳过那些“无效”的byte，从而节省了执行资源。
由此，通过极小的开销（没有增加额外的执行次数），AFL又一次对文件格式进行了启发式的判断。看到这里，不得不叹服于AFL实现上的精妙。
不过，在某些情况下并不会检测有效字符。第一种情况就是dumb mode或者从fuzzer，此时文件所有的字符都有可能被变异。第二、第三种情况与文件本身有关：
/* Minimum input file length at which the effector logic kicks in: */
#define EFF_MIN_LEN 128
/* Maximum effector density past which everything is just fuzzed unconditionally (%): */
#define EFF_MAX_PERC 90即默认情况下，如果文件小于128 bytes，那么所有字符都是“有效”的；同样地，如果AFL发现一个文件有超过90%的bytes都是“有效”的，那么也不差那10%了，大笔一挥，干脆把所有字符都划归为“有效”。
1.2.6 arithmetic
在bitflip变异全部进行完成后，便进入下一个阶段：arithmetic。与bitflip类似的是，arithmetic根据目标大小的不同，也分为了多个子阶段：
- arith 8/8，每次对8个bit进行加减运算，按照每8个bit的步长从头开始，即对文件的每个byte进行整数加减变异
- arith 16/8，每次对16个bit进行加减运算，按照每8个bit的步长从头开始，即对文件的每个word进行整数加减变异
- arith 32/8，每次对32个bit进行加减运算，按照每8个bit的步长从头开始，即对文件的每个dword进行整数加减变异
加减变异的上限，在config.h中的宏ARITH_MAX定义，默认为35。所以，对目标整数会进行+1, +2, …, +35, -1, -2, …, -35的变异。特别地，由于整数存在大端序和小端序两种表示方式，AFL会贴心地对这两种整数表示方式都进行变异。
此外，AFL还会智能地跳过某些arithmetic变异。第一种情况就是前面提到的effector map：如果一个整数的所有bytes都被判断为“无效”，那么就跳过对整数的变异。第二种情况是之前bitflip已经生成过的变异：如果加/减某个数后，其效果与之前的某种bitflip相同，那么这次变异肯定在上一个阶段已经执行过了，此次便不会再执行。
interest
下一个阶段是interest，具体可分为：
- interest 8/8，每次对8个bit进替换，按照每8个bit的步长从头开始，即对文件的每个byte进行替换
- interest 16/8，每次对16个bit进替换，按照每8个bit的步长从头开始，即对文件的每个word进行替换
- interest 32/8，每次对32个bit进替换，按照每8个bit的步长从头开始，即对文件的每个dword进行替换
而用于替换的”interesting values”，是AFL预设的一些比较特殊的数：
static s8 interesting_8[] = { INTERESTING_8 };
static s16 interesting_16[] = { INTERESTING_8, INTERESTING_16 };
static s32 interesting_32[] = { INTERESTING_8, INTERESTING_16, INTERESTING_32 };这些数的定义在config.h文件中：
/* List of interesting values to use in fuzzing. */
#define INTERESTING_8 \ -128, /* Overflow signed 8-bit when decremented */ \ -1, /* */ \ 0, /* */ \ 1, /* */ \ 16, /* One-off with common buffer size */ \ 32, /* One-off with common buffer size */ \ 64, /* One-off with common buffer size */ \ 100, /* One-off with common buffer size */ \ 127 /* Overflow signed 8-bit when incremented */
#define INTERESTING_16 \ -32768, /* Overflow signed 16-bit when decremented */ \ -129, /* Overflow signed 8-bit */ \ 128, /* Overflow signed 8-bit */ \ 255, /* Overflow unsig 8-bit when incremented */ \ 256, /* Overflow unsig 8-bit */ \ 512, /* One-off with common buffer size */ \ 1000, /* One-off with common buffer size */ \ 1024, /* One-off with common buffer size */ \ 4096, /* One-off with common buffer size */ \ 32767 /* Overflow signed 16-bit when incremented */
#define INTERESTING_32 \ -2147483648LL, /* Overflow signed 32-bit when decremented */ \ -100663046, /* Large negative number (endian-agnostic) */ \ -32769, /* Overflow signed 16-bit */ \ 32768, /* Overflow signed 16-bit */ \ 65535, /* Overflow unsig 16-bit when incremented */ \ 65536, /* Overflow unsig 16 bit */ \ 100663045, /* Large positive number (endian-agnostic) */ \ 2147483647 /* Overflow signed 32-bit when incremented */可以看到，用于替换的基本都是可能会造成溢出的数。
与之前类似，effector map仍然会用于判断是否需要变异；此外，如果某个interesting value，是可以通过bitflip或者arithmetic变异达到，那么这样的重复性变异也是会跳过的。
1.2.7 dictionary
进入到这个阶段，就接近deterministic fuzzing的尾声了。具体有以下子阶段：
- user extras (over)，从头开始，将用户提供的tokens依次替换到原文件中
- user extras (insert)，从头开始，将用户提供的tokens依次插入到原文件中
- auto extras (over)，从头开始，将自动检测的tokens依次替换到原文件中
其中，用户提供的tokens，是在词典文件中设置并通过-x选项指定的，如果没有则跳过相应的子阶段。
1.2.8 user extras (over)
对于用户提供的tokens，AFL先按照长度从小到大进行排序。这样做的好处是，只要按照顺序使用排序后的tokens，那么后面的token不会比之前的短，从而每次覆盖替换后不需要再恢复到原状。
随后，AFL会检查tokens的数量，如果数量大于预设的MAX_DET_EXTRAS（默认值为200），那么对每个token会根据概率来决定是否进行替换：
for (j = 0; j < extras_cnt; j++) {
/* Skip extras probabilistically if extras_cnt > MAX_DET_EXTRAS. Also skip them if there's no room to insert the payload, if the token is redundant, or if its entire span has no bytes set in the effector map. */
if ((extras_cnt > MAX_DET_EXTRAS && UR(extras_cnt) >= MAX_DET_EXTRAS) ||
extras[j].len > len - i ||
!memcmp(extras[j].data, out_buf + i, extras[j].len) ||
!memchr(eff_map + EFF_APOS(i), 1, EFF_SPAN_ALEN(i, extras[j].len))) {
stage_max--;
continue;
}这里的UR(extras_cnt)是运行时生成的一个0到extras_cnt之间的随机数。所以，如果用户词典中一共有400个tokens，那么每个token就有200/400=50%的概率执行替换变异。我们可以修改MAX_DET_EXTRAS的大小来调整这一概率。
由上述代码也可以看到，effector map在这里同样被使用了：如果要替换的目标bytes全部是“无效”的，那么就跳过这一段，对下一段目标执行替换。
user extras (insert)
这一子阶段是对用户提供的tokens执行插入变异。不过与上一个子阶段不同的是，此时并没有对tokens数量的限制，所以全部tokens都会从原文件的第1个byte开始，依次向后插入；此外，由于原文件并未发生替换，所以effector map不会被使用。
这一子阶段最特别的地方，就是变异不能简单地恢复。之前每次变异完，在变异位置处简单取逆即可，例如bitflip后，再进行一次同样的bitflip就恢复为原文件。正因为如此，之前的变异总体运算量并不大。
但是，对于插入这种变异方式，恢复起来则复杂的多，所以AFL采取的方式是：将原文件分割为插入前和插入后的部分，再加上插入的内容，将这3部分依次复制到目标缓冲区中（当然这里还有一些小的优化，具体可阅读代码）。而对每个token的每处插入，都需要进行上述过程。所以，如果用户提供了大量tokens，或者原文件很大，那么这一阶段的运算量就会非常的多。直观表现上，就是AFL的执行状态栏中，”user extras (insert)”的总执行量很大，执行时间很长。如果出现了这种情况，那么就可以考虑适当删减一些tokens。
1.2.9 auto extras (over)
这一项与”user extras (over)”很类似，区别在于，这里的tokens是最开始bitflip阶段自动生成的。另外，自动生成的tokens总量会由USE_AUTO_EXTRAS限制（默认为10）。
1.2.10 havoc
对于非dumb mode的主fuzzer来说，完成了上述deterministic fuzzing后，便进入了充满随机性的这一阶段；对于dumb mode或者从fuzzer来说，则是直接从这一阶段开始。
havoc，顾名思义，是充满了各种随机生成的变异，是对原文件的“大破坏”。具体来说，havoc包含了对原文件的多轮变异，每一轮都是将多种方式组合（stacked）而成：
- 随机选取某个bit进行翻转
- 随机选取某个byte，将其设置为随机的interesting value
- 随机选取某个word，并随机选取大、小端序，将其设置为随机的interesting value
- 随机选取某个dword，并随机选取大、小端序，将其设置为随机的interesting value
- 随机选取某个byte，对其减去一个随机数
- 随机选取某个byte，对其加上一个随机数
- 随机选取某个word，并随机选取大、小端序，对其减去一个随机数
- 随机选取某个word，并随机选取大、小端序，对其加上一个随机数
- 随机选取某个dword，并随机选取大、小端序，对其减去一个随机数
- 随机选取某个dword，并随机选取大、小端序，对其加上一个随机数
- 随机选取某个byte，将其设置为随机数
- 随机删除一段bytes
- 随机选取一个位置，插入一段随机长度的内容，其中75%的概率是插入原文中随机位置的内容，25%的概率是插入一段随机选取的数
- 随机选取一个位置，替换为一段随机长度的内容，其中75%的概率是替换成原文中随机位置的内容，25%的概率是替换成一段随机选取的数
- 随机选取一个位置，用随机选取的token（用户提供的或自动生成的）替换
- 随机选取一个位置，用随机选取的token（用户提供的或自动生成的）插入
怎么样，看完上面这么多的“随机”，有没有觉得晕？还没完，AFL会生成一个随机数，作为变异组合的数量，并根据这个数量，每次从上面那些方式中随机选取一个（可以参考高中数学的有放回摸球），依次作用到文件上。如此这般丧心病狂的变异，原文件就大概率面目全非了，而这么多的随机性，也就成了fuzzing过程中的不可控因素，即所谓的“看天吃饭”了。
1.2.11 splice
历经了如此多的考验，文件的变异也进入到了最后的阶段：splice。如其意思所说，splice是将两个seed文件拼接得到新的文件，并对这个新文件继续执行havoc变异。
具体地，AFL在seed文件队列中随机选取一个，与当前的seed文件做对比。如果两者差别不大，就再重新随机选一个；如果两者相差比较明显，那么就随机选取一个位置，将两者都分割为头部和尾部。最后，将当前文件的头部与随机文件的尾部拼接起来，就得到了新的文件。在这里，AFL还会过滤掉拼接文件未发生变化的情况。
cycle
于是乎，一个seed文件，在上述的全部变异都执行完成后，就…抱歉，还没结束。
上面的变异完成后，AFL会对文件队列的下一个进行变异处理。当队列中的全部文件都变异测试后，就完成了一个”cycle”，这个就是AFL状态栏右上角的”cycles done”。而正如cycle的意思所说，整个队列又会从第一个文件开始，再次进行变异，不过与第一次变异不同的是，这一次就不需要再进行deterministic fuzzing了。
当然，如果用户不停止AFL，那么seed文件将会一遍遍的变异下去。
1.2.x fuzz_one()的abandon_entry流程：
queue的was_fuzzed为置1，pending_not_fuzzed全局变量减一
if (!stop_soon && !queue_cur->cal_failed && !queue_cur->was_fuzzed) {
queue_cur->was_fuzzed = 1;
pending_not_fuzzed--;
if (queue_cur->favored) pending_favored--;
}1.3 其他重要函数
1.3.1 has_new_bits() 新bit发现函数
has_new_bits():检查本次执行得到的path是否产生新的tuple。返回0，没有新的tuple；返回1，tuple的访问次数变化；返回2，发现新的tuple；
1.3.2 common_fuzz_stuff() 变异后执行的fuzz函数
将out_buf中的变异内容输出到文件(write_to_testcase)，并执行(run_target)，并判断这个变异是否为一个感兴趣的变异(save_if_interesting)。
1.3.3 save_if_interesting() 判断是否为感兴趣的输入
判断一个文件是否是感兴趣的输入(has_new_bits)，即是否访问了新的tuple或者tuple访问次数发生变化，如果是则保存输入文件（放到队列queue中）。
附. 重要的全局数据结构和变量：
bitmap相关：
EXP_ST u8* trace_bits; /* SHM with instrumentation bitmap */
EXP_ST u8 virgin_bits[MAP_SIZE], /* Regions yet untouched by fuzzing */
virgin_tmout[MAP_SIZE], /* Bits we haven't seen in tmouts */
virgin_crash[MAP_SIZE]; /* Bits we haven't seen in crashes */队列相关全局计数：
EXP_ST u32 queued_paths, /* Total number of queued testcases */
queued_variable, /* Testcases with variable behavior */
queued_at_start, /* Total number of initial inputs */
queued_discovered, /* Items discovered during this run */
queued_imported, /* Items imported via -S */
queued_favored, /* Paths deemed favorable */
queued_with_cov, /* Paths with new coverage bytes */
pending_not_fuzzed, /* Queued but not done yet */
pending_favored, /* Pending favored paths */
cur_skipped_paths, /* Abandoned inputs in cur cycle */
cur_depth, /* Current path depth */
max_depth, /* Max path depth */
useless_at_start, /* Number of useless starting paths */
var_byte_count, /* Bitmap bytes with var behavior */
current_entry, /* Current queue entry ID */
havoc_div = 1; /* Cycle count divisor for havoc */队列：
static struct queue_entry *queue, /* Fuzzing queue (linked list) */
*queue_cur, /* Current offset within the queue */
*queue_top, /* Top of the list */
*q_prev100; /* Previous 100 marker */
static struct queue_entry* top_rated[MAP_SIZE]; /* Top entries for bitmap bytes */队列结构体：
struct queue_entry {
u8* fname; /* File name for the test case */
u32 len; /* Input length */
u8 cal_failed, /* Calibration failed? */
trim_done, /* Trimmed? */
was_fuzzed, /* Had any fuzzing done yet? */
passed_det, /* Deterministic stages passed? */
has_new_cov, /* Triggers new coverage? */
var_behavior, /* Variable behavior? */
favored, /* Currently favored? */
fs_redundant; /* Marked as redundant in the fs? */
u32 bitmap_size, /* Number of bits set in bitmap */
exec_cksum; /* Checksum of the execution trace */
u64 exec_us, /* Execution time (us) */
handicap, /* Number of queue cycles behind */
depth; /* Path depth */
u8* trace_mini; /* Trace bytes, if kept */
u32 tc_ref; /* Trace bytes ref count */
struct queue_entry *next, /* Next element, if any */
*next_100; /* 100 elements ahead */
};参考资料
- AFL内部实现细节小记等3篇
写的很详细，并结合了部分代码，很有参考价值，包括forkserver/插桩代码/共享信息/变异方法/改进等。 - AFL官网主页
下载代码，查看doc等，重点可以看下 README 和 Technical Whitepaper. - 使用Afl-fuzz (American Fuzzy Lop) 进行fuzzing测试（一）-（四）
介绍了afl的操作步骤，翻译了README和技术白皮书。 - 模糊测试工具 American Fuzzy Lop (一)
写了一个简单的case，并演示了怎么用 - AFL技术实现分析
结合参考1和其他资料写的一个文档，比较系统易懂 - 翻译afl-fuzz白皮书