diff --git "a/2024/AFLplusplus\346\272\220\347\240\201\345\210\206\346\236\220\342\200\224\342\200\224\350\246\206\347\233\226\347\216\207/index.html" "b/2024/AFLplusplus\346\272\220\347\240\201\345\210\206\346\236\220\342\200\224\342\200\224\350\246\206\347\233\226\347\216\207/index.html"
index d9d9414..98b26cd 100644
--- "a/2024/AFLplusplus\346\272\220\347\240\201\345\210\206\346\236\220\342\200\224\342\200\224\350\246\206\347\233\226\347\216\207/index.html"
+++ "b/2024/AFLplusplus\346\272\220\347\240\201\345\210\206\346\236\220\342\200\224\342\200\224\350\246\206\347\233\226\347\216\207/index.html"
@@ -14,7 +14,7 @@
     
     
     
-    <script type="application/ld+json">{"@context":"http://schema.org","@type":"BlogPosting","author":{"@type":"Person","name":"一瓢清浅","sameAs":["#about","https://github.com/jiliguluss"],"image":"photo.jpg"},"articleBody":"````\n\n前文 AFL++ 同步机制 提到，执行同步函数 sync_fuzzers 会调用函数 save_if_interesting。顾名思义，这个save_if_interesting 函数是用来保存 interesting 的 corpus。\nAFL++ 认为 corpus 是否 interesting，是基于 corpus 对 binary 的代码覆盖率来判断。在分析 save_if_interesting 的源码之前，有必要了解一下 AFL++ 的覆盖率统计机制。\n一、原理简介  在AFL++ 白皮书  中，对覆盖率的计算有简要说明。\n首先，通过插桩，来跟踪 corpus 在 binary 中走过的路径，并将路径转换为一系列 (branch_src, branch_dst) 元组的集合。例如：\n12corpus 1: A -&gt; B -&gt; C -&gt; D -&gt; E  =&gt;  (AB, BC, CD, DE)corpus 2: A -&gt; B -&gt; D -&gt; C -&gt; E  =&gt;  (AB, BD, DC, CE)\n\n其次，通过一个共享数组 shared_mem 来记录 (branch_src, branch_dst) 元组（可以看作是 CFG 中的 edge 的表示）被命中的次数，伪代码为：\n123cur_location = &lt;COMPILE_TIME_RANDOM&gt;;shared_mem[cur_location ^ prev_location]++; prev_location = cur_location &gt;&gt; 1;\n当 corpus 从 branch_src 走到 branch_dst 时，将 branch_dst 与branch_src进行异或运算的结果作为 shared_mem 的索引，并给索引指向的元素进行加一操作，表示多命中一次(branch_src, branch_dst)。\n值得注意的是最后一行的右移操作。当从 branch_dst 开始找下一个 edge 时，并没有直接把 cur_location 赋值给 pre_location，而是先对cur_location 进行了一次右移操作，再赋值给pre_location。这样处理的好处有两个：\n\n区分 AB 和 BA。如果没有进行右移，那么 A^B 算出的索引，和 B^A 算出的索引，二者是相等的，也就是把 AB 和 BA 看做是同一个 edge。实际上 CFG 中 edge 都是有向边，方向性是一个很重要的信息。\n区分 AA 和 BB。在循环体中，如果 prev_location 与cur_location相等，那么 cur_location^prev_location 的结果将恒等于 0。导致循环体执行不同的 basic block 时，在 shared_mem 中无法得到有效区分。\n\n这种统计方式也是有一定局限性的，例如：\n123corpus 1: A -&gt; B -&gt; C -&gt; D -&gt; E  =&gt;  (AB, BC, CD, DE)corpus 2: A -&gt; B -&gt; C -&gt; A -&gt; E  =&gt;  (AB, BC, CA, AE)corpus 3: A -&gt; B -&gt; C -&gt; A -&gt; B -&gt; C -&gt; A -&gt; B -&gt; C -&gt; D -&gt; E  =&gt;  (AB, BC, CD, DE)\ncorpus 2 与 corpus 1 相比，增加了新的 edge 元组 CA 和 AE。因此 AFL++ 认为 corpus 2 找到一条新的路径。corpus 3 与 corpus 1 相比，没有增加新的 edge 元组。即使 corpus 3 的真实路径与 corpus 1 的真实路径有明显区别，但在 AFL++ 看来，corpus 3 并没有找到一条新路径。\nAFL++ 在判断一个 corpus 是否 interesting 时，除了考虑 corpus 有没有找到新路径（命中新 edge），也会考虑 edge 的命中次数。为了简化命中次数的比较，AFL++ 对次数进行分桶处理，将命中次数分为如下 8 个桶（以 2 的幂次来分割）。当 corpus 使得 edge 的命中次数从一个桶变到另一个桶时，它也会被认为是 interesting。\n11, 2, 3, 4-7, 8-15, 16-31, 32-127, 128+\n此处有个疑问：3 作为单独一个桶有点乱入的感觉，为什么不是 2-3 作为一个桶，且为什么没有 0 这个桶呢？\n总结一下，AFL++ 认为一个 corpus 是 interesting，当且仅当 corpus 至少满足以下条件之一：\n\ncorpus 找到了一个新的 edge。\ncorpus 使某个 edge 的命中次数从一个 bucket 转移到另一个 bucket。\n\n二、源码分析 1. save_if_interestingsave_if_interesting 函数位于afl-fuzz-bitmap.c，其签名为：\n1u8 save_if_interesting(afl_state_t *afl, void *mem, u32 len, u8 fault);\n\n在 sync_fuzzers 中调用 save_if_interesting 的代码如下：\n123456789101112131415161718192021222324if (st.st_size &amp;&amp; st.st_size &lt;= MAX_FILE) &#123;    u8  fault;    u8 *mem = mmap(0, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);        if (mem == MAP_FAILED) &#123; PFATAL(&quot;Unable to mmap &#x27;%s&#x27;&quot;, path); &#125;        /* See what happens. We rely on save_if_interesting() to catch major       errors and save the test case. */        u32 new_len = write_to_testcase(afl, (void **)&amp;mem, st.st_size, 1);        fault = fuzz_run_target(afl, &amp;afl-&gt;fsrv, afl-&gt;fsrv.exec_tmout);        if (afl-&gt;stop_soon) &#123; goto close_sync; &#125;        afl-&gt;syncing_party = sd_ent-&gt;d_name;    afl-&gt;queued_imported += save_if_interesting(afl, mem, new_len, fault);    show_stats(afl);    afl-&gt;syncing_party = 0;        munmap(mem, st.st_size);&#125;\n\n可以看到 save_if_interesting 函数的入参分别为：\n1234afl: AFL++ 的全局状态mem: corpus 的内容len: corpus 的长度fault: fuzz_run_target 的执行结果，0 表示正常结束，1 表示运行超时，2 表示出现 crash\n\n在 save_if_interesting 函数体内，主要执行了如下流程：\nsequenceDiagram\n    save_if_interesting ->> has_new_bits: 检查 corpus 是否能更新 bitmap\n    has_new_bits ->> discover_word: 检查 bitmap 是否有变化\n    discover_word -->> has_new_bits: 返回检查结果\n    has_new_bits -->> save_if_interesting: 返回 0 表示无变化，返回 1 表示命中次数的 bucket 有变化，返回 2 表示找到了一个新 edge\n    save_if_interesting ->> describe_op: 创建 corpus 文件名\n    describe_op -->> save_if_interesting: 返回 corpus 文件名\n    save_if_interesting ->> ck_write: 将 corpus 保存为文件\n    save_if_interesting ->> add_to_queue: 将 corpus 添加到 AFL++ 的队列中\n\n2. has_new_bits负责检查整个 bitmap 是否有变化的是 has_new_bits 函数，其代码为：\n123456789101112131415161718192021222324252627282930313233343536373839404142/* Check if the current execution path brings anything new to the table.   Update virgin bits to reflect the finds. Returns 1 if the only change is   the hit-count for a particular tuple; 2 if there are new tuples seen.   Updates the map, so subsequent calls will always return 0.   This function is called after every exec() on a fairly large buffer, so   it needs to be fast. We do this in 32-bit and 64-bit flavors. */inline u8 has_new_bits(afl_state_t *afl, u8 *virgin_map) &#123;#ifdef WORD_SIZE_64  u64 *current = (u64 *)afl-&gt;fsrv.trace_bits;  u64 *virgin = (u64 *)virgin_map;  u32 i = ((afl-&gt;fsrv.real_map_size + 7) &gt;&gt; 3);#else  u32 *current = (u32 *)afl-&gt;fsrv.trace_bits;  u32 *virgin = (u32 *)virgin_map;  u32 i = ((afl-&gt;fsrv.real_map_size + 3) &gt;&gt; 2);#endif                                                     /* ^WORD_SIZE_64 */  u8 ret = 0;  while (i--) &#123;    if (unlikely(*current)) discover_word(&amp;ret, current, virgin);    current++;    virgin++;  &#125;  if (unlikely(ret) &amp;&amp; likely(virgin_map == afl-&gt;virgin_bits))    afl-&gt;bitmap_changed = 1;  return ret;&#125;\n首先在宏定义中，计算整个 binary 的 bitmap 的长度i（可以理解为 edge 的个数）。\n然后在 while 循环中，依次循环每个 edge，调用 discover_word 函数来完成实际比对操作。\ncurrent和 virgin 分别表示当前 corpus 覆盖路径对应的 bitmap，以及整个 AFL++ 已走过的路径所对应的 bitmap。\n需要理解它们的数据结构，current和 virgin 是长度相等的一维数组，每个元素的有效数据是一个字节，即 8 个 bits 构成的 bit 数组，在 64 位和 32 位系统中，分别用 u64 指针和 u32 指针来指示。\n在第一部分介绍 AFL++ 统计覆盖率的原理时有讲，AFL++ 讲每个 edge 的命中频次进行分桶处理，分成了 8 个桶，每个桶实际上是以一个 bit 位来表示。\n在 AFL++ 初始化 virgin 时，将所有的 bit 位都设为 1，因此 1 表示没有落在这个桶，0 表示落在这个桶。但在 current 中，bit 为 1 表示落在这个桶，0 表示没有落在这个桶。需要注意 bit 为 1 的含义相反！\n以 virgin 为例，若virgin[12345]=0b10110110，表示 AFL++ 产生的所有 corpus 在 12345 这个 edge 上，有命中 2 次、8-15 次、128+ 次三种情况。\n3. discover_word具体完成某个 edge 的 bitmap 对比的是 discover_word 函数，其代码为：\n123456789101112131415161718192021222324252627282930313233/* Updates the virgin bits, then reflects whether a new count or a new tuple is * seen in ret. */inline void discover_word(u8 *ret, u64 *current, u64 *virgin) &#123;  /* Optimize for (*current &amp; *virgin) == 0 - i.e., no bits in current bitmap     that have not been already cleared from the virgin map - since this will     almost always be the case. */  if (*current &amp; *virgin) &#123;    if (likely(*ret &lt; 2)) &#123;      u8 *cur = (u8 *)current;      u8 *vir = (u8 *)virgin;      /* Looks like we have not found any new bytes yet; see if any non-zero         bytes in current[] are pristine in virgin[]. */      if ((cur[0] &amp;&amp; vir[0] == 0xff) || (cur[1] &amp;&amp; vir[1] == 0xff) ||          (cur[2] &amp;&amp; vir[2] == 0xff) || (cur[3] &amp;&amp; vir[3] == 0xff) ||          (cur[4] &amp;&amp; vir[4] == 0xff) || (cur[5] &amp;&amp; vir[5] == 0xff) ||          (cur[6] &amp;&amp; vir[6] == 0xff) || (cur[7] &amp;&amp; vir[7] == 0xff))        *ret = 2;      else        *ret = 1;    &#125;    *virgin &amp;= ~*current;  &#125;&#125;\n首先，计算 *current &amp; *virgin，即将current 指向的 8 个 bits 与 virgin 指向的 8 个 bits 进行按位与运算。\n前面说到 bit=1 在current与 virgin 中的含义是相反的，那么 current 与virgin按位与的结果为 1，说明至少有一个桶，virgin是没到过的，而 current 到了。\n接着，判断 likely(*ret &lt; 2)，在 AFL++ 看来*ret &lt; 2 是一个很可能出现的情况，current找到一个新的 edge，才会将设置*ret=2。\n判断 current 是否找到一个新的 edge，是通过依次比较 (cur[k] &amp;&amp; vir[k] == 0xff), k=0...7 来实现的。vir[k]==0xff表示所有桶的 bit 位为 1，即这个 edge 从来没到过。而 cur[k]==1 表示当前 corpus 到了这个 edge，从而认为 corpus 找到了新 edge。\n此处有个疑问：k 从 0 到 7 要怎么理解？从代码来看，current 和 virgin 的每个元素用 64 个 bit 来存储，分 8 次读取，某一次读取的 8 个 bit 是全为 1 就可以。那为什么不直接用 8 个 bit 来存储？\n4. describe_op在 AFL++ 获得一个 interesting 的 corpus 之后，会将其保存为文件。在保存之前，通过 describe_op 函数来生成文件名，在文件名中记录一些关键信息：\n1234567id: 记录 corpus 的 id 编号sync: 从哪个目录同步过来src: 从哪个 corpus 演化而来，记录来源 corpus 的 idtime: AFL++ 的运行时间execs: AFL++ 的运行次数+cov: 当前 corpus 找到了新 edge，即 has_new_bits 返回 2+tout: 当前 corpus 运行超时\n\n三、参考资料\nAFL 源码阅读（六）：队列、变异、同步\nAFL++ 白皮书和源码阅读\n","dateCreated":"2024-08-15T17:28:52+08:00","dateModified":"2024-08-21T15:01:30+08:00","datePublished":"2024-08-15T17:28:52+08:00","description":"分析 AFL++ 度量覆盖率的相关代码","headline":"AFL++ 源码分析——覆盖率","image":[],"mainEntityOfPage":{"@type":"WebPage","@id":"https://www.stepbystep.asia/2024/AFLplusplus%E6%BA%90%E7%A0%81%E5%88%86%E6%9E%90%E2%80%94%E2%80%94%E8%A6%86%E7%9B%96%E7%8E%87/"},"publisher":{"@type":"Organization","name":"一瓢清浅","sameAs":["#about","https://github.com/jiliguluss"],"image":"photo.jpg","logo":{"@type":"ImageObject","url":"photo.jpg"}},"url":"https://www.stepbystep.asia/2024/AFLplusplus%E6%BA%90%E7%A0%81%E5%88%86%E6%9E%90%E2%80%94%E2%80%94%E8%A6%86%E7%9B%96%E7%8E%87/","keywords":"AFL++, Fuzz, 安全, 工具"}</script>
+    <script type="application/ld+json">{"@context":"http://schema.org","@type":"BlogPosting","author":{"@type":"Person","name":"一瓢清浅","sameAs":["#about","https://github.com/jiliguluss"],"image":"photo.jpg"},"articleBody":"\n\n前文 AFL++ 同步机制 提到，执行同步函数 sync_fuzzers 会调用函数 save_if_interesting。顾名思义，这个save_if_interesting 函数是用来保存 interesting 的 corpus。\nAFL++ 认为 corpus 是否 interesting，是基于 corpus 对 binary 的代码覆盖率来判断。在分析 save_if_interesting 的源码之前，有必要了解一下 AFL++ 的覆盖率统计机制。\n一、原理简介  在AFL++ 白皮书  中，对覆盖率的计算有简要说明。\n首先，通过插桩，来跟踪 corpus 在 binary 中走过的路径，并将路径转换为一系列 (branch_src, branch_dst) 元组的集合。例如：\n12corpus 1: A -&gt; B -&gt; C -&gt; D -&gt; E  =&gt;  (AB, BC, CD, DE)corpus 2: A -&gt; B -&gt; D -&gt; C -&gt; E  =&gt;  (AB, BD, DC, CE)\n\n其次，通过一个共享数组 shared_mem 来记录 (branch_src, branch_dst) 元组（可以看作是 CFG 中的 edge 的表示）被命中的次数，伪代码为：\n123cur_location = &lt;COMPILE_TIME_RANDOM&gt;;shared_mem[cur_location ^ prev_location]++; prev_location = cur_location &gt;&gt; 1;\n当 corpus 从 branch_src 走到 branch_dst 时，将 branch_dst 与branch_src进行异或运算的结果作为 shared_mem 的索引，并给索引指向的元素进行加一操作，表示多命中一次(branch_src, branch_dst)。\n值得注意的是最后一行的右移操作。当从 branch_dst 开始找下一个 edge 时，并没有直接把 cur_location 赋值给 pre_location，而是先对cur_location 进行了一次右移操作，再赋值给pre_location。这样处理的好处有两个：\n\n区分 AB 和 BA。如果没有进行右移，那么 A^B 算出的索引，和 B^A 算出的索引，二者是相等的，也就是把 AB 和 BA 看做是同一个 edge。实际上 CFG 中 edge 都是有向边，方向性是一个很重要的信息。\n区分 AA 和 BB。在循环体中，如果 prev_location 与cur_location相等，那么 cur_location^prev_location 的结果将恒等于 0。导致循环体执行不同的 basic block 时，在 shared_mem 中无法得到有效区分。\n\n这种统计方式也是有一定局限性的，例如：\n123corpus 1: A -&gt; B -&gt; C -&gt; D -&gt; E  =&gt;  (AB, BC, CD, DE)corpus 2: A -&gt; B -&gt; C -&gt; A -&gt; E  =&gt;  (AB, BC, CA, AE)corpus 3: A -&gt; B -&gt; C -&gt; A -&gt; B -&gt; C -&gt; A -&gt; B -&gt; C -&gt; D -&gt; E  =&gt;  (AB, BC, CD, DE)\ncorpus 2 与 corpus 1 相比，增加了新的 edge 元组 CA 和 AE。因此 AFL++ 认为 corpus 2 找到一条新的路径。corpus 3 与 corpus 1 相比，没有增加新的 edge 元组。即使 corpus 3 的真实路径与 corpus 1 的真实路径有明显区别，但在 AFL++ 看来，corpus 3 并没有找到一条新路径。\nAFL++ 在判断一个 corpus 是否 interesting 时，除了考虑 corpus 有没有找到新路径（命中新 edge），也会考虑 edge 的命中次数。为了简化命中次数的比较，AFL++ 对次数进行分桶处理，将命中次数分为如下 8 个桶（以 2 的幂次来分割）。当 corpus 使得 edge 的命中次数从一个桶变到另一个桶时，它也会被认为是 interesting。\n11, 2, 3, 4-7, 8-15, 16-31, 32-127, 128+\n此处有个疑问：3 作为单独一个桶有点乱入的感觉，为什么不是 2-3 作为一个桶，且为什么没有 0 这个桶呢？\n总结一下，AFL++ 认为一个 corpus 是 interesting，当且仅当 corpus 至少满足以下条件之一：\n\ncorpus 找到了一个新的 edge。\ncorpus 使某个 edge 的命中次数从一个 bucket 转移到另一个 bucket。\n\n二、源码分析 1. save_if_interestingsave_if_interesting 函数位于afl-fuzz-bitmap.c，其签名为：\n1u8 save_if_interesting(afl_state_t *afl, void *mem, u32 len, u8 fault);\n\n在 sync_fuzzers 中调用 save_if_interesting 的代码如下：\n123456789101112131415161718192021222324if (st.st_size &amp;&amp; st.st_size &lt;= MAX_FILE) &#123;    u8  fault;    u8 *mem = mmap(0, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);        if (mem == MAP_FAILED) &#123; PFATAL(&quot;Unable to mmap &#x27;%s&#x27;&quot;, path); &#125;        /* See what happens. We rely on save_if_interesting() to catch major       errors and save the test case. */        u32 new_len = write_to_testcase(afl, (void **)&amp;mem, st.st_size, 1);        fault = fuzz_run_target(afl, &amp;afl-&gt;fsrv, afl-&gt;fsrv.exec_tmout);        if (afl-&gt;stop_soon) &#123; goto close_sync; &#125;        afl-&gt;syncing_party = sd_ent-&gt;d_name;    afl-&gt;queued_imported += save_if_interesting(afl, mem, new_len, fault);    show_stats(afl);    afl-&gt;syncing_party = 0;        munmap(mem, st.st_size);&#125;\n\n可以看到 save_if_interesting 函数的入参分别为：\n1234afl: AFL++ 的全局状态mem: corpus 的内容len: corpus 的长度fault: fuzz_run_target 的执行结果，0 表示正常结束，1 表示运行超时，2 表示出现 crash\n\n在 save_if_interesting 函数体内，主要执行了如下流程：\nsequenceDiagram\n    save_if_interesting ->> has_new_bits: 检查 corpus 是否能更新 bitmap\n    has_new_bits ->> discover_word: 检查 bitmap 是否有变化\n    discover_word -->> has_new_bits: 返回检查结果\n    has_new_bits -->> save_if_interesting: 返回 0 表示无变化，返回 1 表示命中次数的 bucket 有变化，返回 2 表示找到了一个新 edge\n    save_if_interesting ->> describe_op: 创建 corpus 文件名\n    describe_op -->> save_if_interesting: 返回 corpus 文件名\n    save_if_interesting ->> ck_write: 将 corpus 保存为文件\n    save_if_interesting ->> add_to_queue: 将 corpus 添加到 AFL++ 的队列中\n\n2. has_new_bits负责检查整个 bitmap 是否有变化的是 has_new_bits 函数，其代码为：\n123456789101112131415161718192021222324252627282930313233343536373839404142/* Check if the current execution path brings anything new to the table.   Update virgin bits to reflect the finds. Returns 1 if the only change is   the hit-count for a particular tuple; 2 if there are new tuples seen.   Updates the map, so subsequent calls will always return 0.   This function is called after every exec() on a fairly large buffer, so   it needs to be fast. We do this in 32-bit and 64-bit flavors. */inline u8 has_new_bits(afl_state_t *afl, u8 *virgin_map) &#123;#ifdef WORD_SIZE_64  u64 *current = (u64 *)afl-&gt;fsrv.trace_bits;  u64 *virgin = (u64 *)virgin_map;  u32 i = ((afl-&gt;fsrv.real_map_size + 7) &gt;&gt; 3);#else  u32 *current = (u32 *)afl-&gt;fsrv.trace_bits;  u32 *virgin = (u32 *)virgin_map;  u32 i = ((afl-&gt;fsrv.real_map_size + 3) &gt;&gt; 2);#endif                                                     /* ^WORD_SIZE_64 */  u8 ret = 0;  while (i--) &#123;    if (unlikely(*current)) discover_word(&amp;ret, current, virgin);    current++;    virgin++;  &#125;  if (unlikely(ret) &amp;&amp; likely(virgin_map == afl-&gt;virgin_bits))    afl-&gt;bitmap_changed = 1;  return ret;&#125;\n首先在宏定义中，计算整个 binary 的 bitmap 的长度i（可以理解为 edge 的个数）。\n然后在 while 循环中，依次循环每个 edge，调用 discover_word 函数来完成实际比对操作。\ncurrent和 virgin 分别表示当前 corpus 覆盖路径对应的 bitmap，以及整个 AFL++ 已走过的路径所对应的 bitmap。\n需要理解它们的数据结构，current和 virgin 是长度相等的一维数组，每个元素的有效数据是一个字节，即 8 个 bits 构成的 bit 数组，在 64 位和 32 位系统中，分别用 u64 指针和 u32 指针来指示。\n在第一部分介绍 AFL++ 统计覆盖率的原理时有讲，AFL++ 讲每个 edge 的命中频次进行分桶处理，分成了 8 个桶，每个桶实际上是以一个 bit 位来表示。\n在 AFL++ 初始化 virgin 时，将所有的 bit 位都设为 1，因此 1 表示没有落在这个桶，0 表示落在这个桶。但在 current 中，bit 为 1 表示落在这个桶，0 表示没有落在这个桶。需要注意 bit 为 1 的含义相反！\n以 virgin 为例，若virgin[12345]=0b10110110，表示 AFL++ 产生的所有 corpus 在 12345 这个 edge 上，有命中 2 次、8-15 次、128+ 次三种情况。\n3. discover_word具体完成某个 edge 的 bitmap 对比的是 discover_word 函数，其代码为：\n123456789101112131415161718192021222324252627282930313233/* Updates the virgin bits, then reflects whether a new count or a new tuple is * seen in ret. */inline void discover_word(u8 *ret, u64 *current, u64 *virgin) &#123;  /* Optimize for (*current &amp; *virgin) == 0 - i.e., no bits in current bitmap     that have not been already cleared from the virgin map - since this will     almost always be the case. */  if (*current &amp; *virgin) &#123;    if (likely(*ret &lt; 2)) &#123;      u8 *cur = (u8 *)current;      u8 *vir = (u8 *)virgin;      /* Looks like we have not found any new bytes yet; see if any non-zero         bytes in current[] are pristine in virgin[]. */      if ((cur[0] &amp;&amp; vir[0] == 0xff) || (cur[1] &amp;&amp; vir[1] == 0xff) ||          (cur[2] &amp;&amp; vir[2] == 0xff) || (cur[3] &amp;&amp; vir[3] == 0xff) ||          (cur[4] &amp;&amp; vir[4] == 0xff) || (cur[5] &amp;&amp; vir[5] == 0xff) ||          (cur[6] &amp;&amp; vir[6] == 0xff) || (cur[7] &amp;&amp; vir[7] == 0xff))        *ret = 2;      else        *ret = 1;    &#125;    *virgin &amp;= ~*current;  &#125;&#125;\n首先，计算 *current &amp; *virgin，即将current 指向的 8 个 bits 与 virgin 指向的 8 个 bits 进行按位与运算。\n前面说到 bit=1 在current与 virgin 中的含义是相反的，那么 current 与virgin按位与的结果为 1，说明至少有一个桶，virgin是没到过的，而 current 到了。\n接着，判断 likely(*ret &lt; 2)，在 AFL++ 看来*ret &lt; 2 是一个很可能出现的情况，current找到一个新的 edge，才会将设置*ret=2。\n判断 current 是否找到一个新的 edge，是通过依次比较 (cur[k] &amp;&amp; vir[k] == 0xff), k=0...7 来实现的。vir[k]==0xff表示所有桶的 bit 位为 1，即这个 edge 从来没到过。而 cur[k]==1 表示当前 corpus 到了这个 edge，从而认为 corpus 找到了新 edge。\n此处有个疑问：k 从 0 到 7 要怎么理解？从代码来看，current 和 virgin 的每个元素用 64 个 bit 来存储，分 8 次读取，某一次读取的 8 个 bit 是全为 1 就可以。那为什么不直接用 8 个 bit 来存储？\n4. describe_op在 AFL++ 获得一个 interesting 的 corpus 之后，会将其保存为文件。在保存之前，通过 describe_op 函数来生成文件名，在文件名中记录一些关键信息：\n1234567id: 记录 corpus 的 id 编号sync: 从哪个目录同步过来src: 从哪个 corpus 演化而来，记录来源 corpus 的 idtime: AFL++ 的运行时间execs: AFL++ 的运行次数+cov: 当前 corpus 找到了新 edge，即 has_new_bits 返回 2+tout: 当前 corpus 运行超时\n\n三、参考资料\nAFL 源码阅读（六）：队列、变异、同步\nAFL++ 白皮书和源码阅读\n","dateCreated":"2024-08-15T17:28:52+08:00","dateModified":"2024-09-13T15:11:29+08:00","datePublished":"2024-08-15T17:28:52+08:00","description":"分析 AFL++ 度量覆盖率的相关代码","headline":"AFL++ 源码分析——覆盖率","image":[],"mainEntityOfPage":{"@type":"WebPage","@id":"https://www.stepbystep.asia/2024/AFLplusplus%E6%BA%90%E7%A0%81%E5%88%86%E6%9E%90%E2%80%94%E2%80%94%E8%A6%86%E7%9B%96%E7%8E%87/"},"publisher":{"@type":"Organization","name":"一瓢清浅","sameAs":["#about","https://github.com/jiliguluss"],"image":"photo.jpg","logo":{"@type":"ImageObject","url":"photo.jpg"}},"url":"https://www.stepbystep.asia/2024/AFLplusplus%E6%BA%90%E7%A0%81%E5%88%86%E6%9E%90%E2%80%94%E2%80%94%E8%A6%86%E7%9B%96%E7%8E%87/","keywords":"AFL++, Fuzz, 安全, 工具"}</script>
     <meta name="description" content="分析 AFL++ 度量覆盖率的相关代码">
 <meta property="og:type" content="blog">
 <meta property="og:title" content="AFL++ 源码分析——覆盖率">
@@ -23,7 +23,7 @@
 <meta property="og:description" content="分析 AFL++ 度量覆盖率的相关代码">
 <meta property="og:locale" content="zh_CN">
 <meta property="article:published_time" content="2024-08-15T09:28:52.000Z">
-<meta property="article:modified_time" content="2024-08-21T07:01:30.207Z">
+<meta property="article:modified_time" content="2024-09-13T07:11:29.738Z">
 <meta property="article:author" content="一瓢清浅">
 <meta property="article:tag" content="AFL++">
 <meta property="article:tag" content="Fuzz">
@@ -249,7 +249,7 @@ <h1 class="post-title">
     
     <div class="post-content markdown">
         <div class="main-content-wrap">
-            <!--excerpt-->````
+            <!--excerpt-->
 
 <p>前文 <a href="../AFLplusplus%E6%BA%90%E7%A0%81%E5%88%86%E6%9E%90%E2%80%94%E2%80%94%E5%90%8C%E6%AD%A5%E6%9C%BA%E5%88%B6/index.html">AFL++ 同步机制</a> 提到，执行同步函数 <code>sync_fuzzers</code> 会调用函数 <code>save_if_interesting</code>。顾名思义，这个<code>save_if_interesting</code> 函数是用来保存 interesting 的 corpus。</p>
 <p>AFL++ 认为 corpus 是否 interesting，是基于 corpus 对 binary 的代码覆盖率来判断。在分析 <code>save_if_interesting</code> 的源码之前，有必要了解一下 AFL++ 的覆盖率统计机制。</p>
diff --git a/baidusitemap.xml b/baidusitemap.xml
index 9c0d40a..940dd9f 100644
--- a/baidusitemap.xml
+++ b/baidusitemap.xml
@@ -1,11 +1,11 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
   <url>
-    <loc>https://www.stepbystep.asia/2024/Python%E8%BF%9B%E9%98%B6%E2%80%94%E2%80%94%E5%B9%B6%E5%8F%91%E7%BC%96%E7%A8%8B/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <loc>https://www.stepbystep.asia/2024/AFLplusplus%E6%BA%90%E7%A0%81%E5%88%86%E6%9E%90%E2%80%94%E2%80%94%E8%A6%86%E7%9B%96%E7%8E%87/</loc>
+    <lastmod>2024-09-13</lastmod>
   </url>
   <url>
-    <loc>https://www.stepbystep.asia/2024/AFLplusplus%E6%BA%90%E7%A0%81%E5%88%86%E6%9E%90%E2%80%94%E2%80%94%E8%A6%86%E7%9B%96%E7%8E%87/</loc>
+    <loc>https://www.stepbystep.asia/2024/Python%E8%BF%9B%E9%98%B6%E2%80%94%E2%80%94%E5%B9%B6%E5%8F%91%E7%BC%96%E7%A8%8B/</loc>
     <lastmod>2024-08-21</lastmod>
   </url>
   <url>
diff --git a/sitemap.xml b/sitemap.xml
index 6d2ada2..2ece7d1 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -2,16 +2,16 @@
 <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
   
   <url>
-    <loc>https://www.stepbystep.asia/2024/Python%E8%BF%9B%E9%98%B6%E2%80%94%E2%80%94%E5%B9%B6%E5%8F%91%E7%BC%96%E7%A8%8B/</loc>
+    <loc>https://www.stepbystep.asia/2024/AFLplusplus%E6%BA%90%E7%A0%81%E5%88%86%E6%9E%90%E2%80%94%E2%80%94%E8%A6%86%E7%9B%96%E7%8E%87/</loc>
     
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     
     <changefreq>monthly</changefreq>
     <priority>0.6</priority>
   </url>
   
   <url>
-    <loc>https://www.stepbystep.asia/2024/AFLplusplus%E6%BA%90%E7%A0%81%E5%88%86%E6%9E%90%E2%80%94%E2%80%94%E8%A6%86%E7%9B%96%E7%8E%87/</loc>
+    <loc>https://www.stepbystep.asia/2024/Python%E8%BF%9B%E9%98%B6%E2%80%94%E2%80%94%E5%B9%B6%E5%8F%91%E7%BC%96%E7%A8%8B/</loc>
     
     <lastmod>2024-08-21</lastmod>
     
@@ -220,7 +220,7 @@
 
   <url>
     <loc>https://www.stepbystep.asia/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>daily</changefreq>
     <priority>1.0</priority>
   </url>
@@ -228,175 +228,175 @@
   
   <url>
     <loc>https://www.stepbystep.asia/tags/AFL/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/tags/Fuzz/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/tags/%E5%AE%89%E5%85%A8/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/tags/%E5%B7%A5%E5%85%B7/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/tags/%E7%AC%A6%E5%8F%B7%E6%89%A7%E8%A1%8C/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/tags/AFL/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/tags/C/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/tags/%E7%BC%96%E7%A8%8B/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/tags/%E5%BC%80%E5%8F%91/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/tags/Docker/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/tags/%E5%AE%B9%E5%99%A8/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/tags/Hexo/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/tags/%E5%8D%9A%E5%AE%A2/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/tags/%E7%BD%91%E7%AB%99/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/tags/tranquilpeak/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/tags/Linux/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/tags/%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/tags/%E5%91%BD%E4%BB%A4/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/tags/LibFuzzer/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/tags/Web/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/tags/%E7%88%AC%E8%99%AB/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/tags/python/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/tags/Python/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/tags/IntelPin/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/tags/%E6%B1%A1%E7%82%B9%E5%88%86%E6%9E%90/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
@@ -405,91 +405,91 @@
   
   <url>
     <loc>https://www.stepbystep.asia/categories/%E5%AE%89%E5%85%A8/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/categories/%E5%AE%89%E5%85%A8/%E6%A8%A1%E7%B3%8A%E6%B5%8B%E8%AF%95/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/categories/%E7%BC%96%E7%A8%8B%E8%AF%AD%E8%A8%80/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/categories/%E5%AE%89%E5%85%A8/%E7%AC%A6%E5%8F%B7%E6%89%A7%E8%A1%8C/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/categories/%E5%BC%80%E5%8F%91/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/categories/%E7%BC%96%E7%A8%8B%E8%AF%AD%E8%A8%80/C/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/categories/%E5%BC%80%E5%8F%91/Docker/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/categories/web/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/categories/%E5%BC%80%E5%8F%91/Linux/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/categories/web/%E4%B8%AA%E4%BA%BA%E5%8D%9A%E5%AE%A2/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/categories/%E5%BC%80%E5%8F%91/%E7%88%AC%E8%99%AB/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/categories/%E7%BC%96%E7%A8%8B%E8%AF%AD%E8%A8%80/Python/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
     <loc>https://www.stepbystep.asia/categories/%E5%AE%89%E5%85%A8/%E6%B1%A1%E7%82%B9%E5%88%86%E6%9E%90/</loc>
-    <lastmod>2024-08-21</lastmod>
+    <lastmod>2024-09-13</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>