diff --git "a/2023/AFL\345\216\237\347\220\206\344\270\216\345\256\236\350\267\265/index.html" "b/2023/AFL\345\216\237\347\220\206\344\270\216\345\256\236\350\267\265/index.html"
index 6defa8b..6fdfa53 100644
--- "a/2023/AFL\345\216\237\347\220\206\344\270\216\345\256\236\350\267\265/index.html"
+++ "b/2023/AFL\345\216\237\347\220\206\344\270\216\345\256\236\350\267\265/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\n在软件开发的世界里，质量和安全性是评估产品成败的重要指标。模糊测试作为一种高效的自动化测试方法，专门用来发现程序中的错误和安全漏洞。本文旨在详细介绍 AFL（American Fuzzy Lop）的基本原理和使用方法。\n一、AFL 的原理介绍  模糊测试是一种通过向软件输入异常或随机数据的自动化技术，目的是发现程序在处理意外或边缘情况输入时的错误。AFL 是这一测试策略中的杰出代表，它通过不断学习程序反应来改进测试用例，提高测试的覆盖率和发现漏洞的概率。\nAFL 利用遗传算法，不断生成测试用例，并通过动态插桩技术监控程序的行为，特别是程序的代码覆盖情况。当新的输入能触发新的代码路径时，这个输入会被保存以供进一步的测试。该过程可以形成一个反馈循环，不断优化测试用例以探索更多程序状态。\n下面是 AFL 工作流程图，展示了从准备测试用例到监控程序行为的步骤：\ngraph TD\n    A[Compile with afl-gcc] --> B[Initialize seed corpus] --> C[Fuzzing loop] --> D[Select seed from corpus queue]\n    D[Select seed from corpus queue] --> E[Mutate selected seed] --> F[Execute with mutated testcase]\n    F[Execute with mutated testcase] --> G[Monitor for crashes and coverage update] --> H{Check for new coverage}\n    H{Check for new coverage} -- YES --> I[Save mutated testcase to queue] --> D\n    H{Check for new coverage} -- NO --> D\n\n流程图详细展示了 AFL 在模糊测试中的核心步骤：\n\n编译（Compile with afl-gcc） - 使用 AFL 提供的编译器 afl-gcc，对目标程序进行编译，实现程序的动态插桩。\n\n初始化种子库（Initialize seed corpus） - 创建初始测试用例集（种子库），这些测试用例将作为模糊测试的起点。\n\n模糊测试循环（Fuzzing loop） - 一个不断循环的过程，根据测试结果更新种子库，并反复执行下列子步骤：a. 选择种子（Select seed from corpus queue） - 从种子库中选择一个种子文件作为当前测试的输入。b. 突变种子（Mutate selected seed） - 对选中的种子文件应用突变算法，生成新的测试用例。c. 执行测试（Execute with mutated test case） - 将变异后的测试用例作为输入执行已插桩的目标程序。d. 监控结果（Monitor for crashes and coverage update） - 监控程序的执行情况，记录崩溃和代码覆盖率的变化。\n\n覆盖率检查（Check for new coverage） - 判断是否出现新的代码覆盖，如果有，则将其保存为新测试用例。\n\n保存新测试用例（Save new testcase to queue） - 将触发新代码覆盖的测试用例保存到队列中，用于后续的测试。\n\n\nAFL 采用了 fork 的运行模式，这使得当待测程序出现崩溃时，fuzz 进程不会终止，这一点相较于 LibFuzzer 更具优势。然而，频繁的 fork 操作也导致了 AFL 的效率不如 LibFuzzer。\n二、AFL 安装和运行1. 支持的系统和架构AFL 设计之初主要针对 UNIX-like 系统，其在 Linux 系统上有最好的支持。然而，在社区的努力下，也有 Windows 版本的 AFL，如 winafl，其可以在 Windows 进行模糊测试。\nAFL 还支持多种 CPU 架构，其中对 x86 和 x64 架构的支持最好。如果要支持 ARM 架构，则需要使用 AFL 的 QEMU 模式。\n2. 安装步骤AFL 可以通过源码进行安装：\n123apt install git make gccgit clone https://github.com/google/AFL.git cd AFL &amp;&amp; make\n\n3. 运行参数  在安装并编译完 AFL 之后，可以使用 afl-fuzz 命令来启动模糊测试。一个基本的 AFL fuzz 命令如下：\n1afl-fuzz -i input_dir -o output_dir -- /path/to/program [options] @@\n\n这里：\n\nafl-fuzz 是启动 AFL 模糊测试的程序。\n-i input_dir 指定包含初始化测试用例的目录。\n-o output_dir 指定存放的 fuzzing 结果的目录。\n\n-- 之后的部分是运行被测试程序的命令行，其中 /path/to/program 替换为需要进行模糊测试的程序的路径，[options] 是运行该程序的任何选项或参数。\n如果测试程序需要从文件中读取输入，可以在实际输入文件路径的位置使用 @@ 占位符。AFL 将替换 @@ 来插入它正在测试的输入文件。如果省略这个占位符，AFL 将会把模糊测试用例通过 stdin 传递给测试程序。\n三、AFL 的使用示例  本节使用一个简单的示例，演示 AFL 的操作步骤。\n这是待测源码，其功能是接受一行命令行输入，进行四则运算。其中使用了不安全的 gets 函数，可能导致缓冲区溢出：\n1234567891011121314151617181920212223242526272829303132#include &lt;stdio.h&gt;#include &lt;string.h&gt;int calculate(int a, int b, char op) &#123;    switch (op) &#123;        case &#x27;+&#x27;: return a + b;        case &#x27;-&#x27;: return a - b;        case &#x27;x&#x27;: return a * b;        case &#x27;/&#x27;: return b ? a / b : 0;        default: return 0;    &#125;&#125;int main() &#123;    char input[100];    // unsafe method that may cause buffer overflow    gets(input);    int a, b, result;    char op;    if (sscanf(input, &quot;%d %c %d&quot;, &amp;a, &amp;op, &amp;b) != 3)        return 1;    result = calculate(a, b, op);    printf(&quot;Result: %d\\n&quot;, result);    return 0;&#125;\n\n1. 编译源码  使用 AFL 的编译器 afl-gcc 或afl-clang对源文件 hello.c 进行编译，添加所需要的代码覆盖插桩。afl-gcc或 afl-clang 实际上是对常规的 gcc 或clang编译器进行了封装，通过在编译时进行插桩，来统计 fuzz 过程中的代码覆盖率：\n1afl-gcc -o hello hello.c\n\n2. 准备种子语料库  不论程序是从 file 还是从 stdin 获取数据，AFL 都需要一个初始语料库来启动模糊测试过程。输入（无论是来自 file 或 stdin）是 AFL 用来开始探索程序行为的基础。初始语料库（seed corpus）是一组文件，其中包含了各种有效的输入示例，这些输入会被 AFL 用作模糊测试的起始点。\n从 stdin 读取输入时，AFL 会将语料库中的每个文件内容作为输入在每次测试运行时送到程序的标准输入流中。使用 AFL 时，必须要有初始语料库。注意这一点 AFL 与 Libfuzzer 不同，Libfuzzer 只接受 stdin，不接受 file，初始语料库为可选项。\n12mkdir inecho &#x27;abc&#x27; &gt; in/seed\n\n3. 执行测试  在运行 AFL 之前，需要执行下面的系统设置命令，将字符串”core”写入到文件 /proc/sys/kernel/core_pattern 中。\n在 Linux 系统中，/proc/sys/kernel/core_pattern 文件用于指定当程序崩溃时，内核转储文件（core dump）的文件名模式。通过修改这个文件，可以控制内核生成 core 文件的行为。\n通过执行这个命令，生成的核心转储文件将以”core”命名，这使得 AFL 更容易检测和处理目标程序的崩溃情况，从而更好地进行模糊测试。\n1echo core | tee /proc/sys/kernel/core_pattern\n\n在 hello 中使用 gets 函数从 stdin 中读取数据，因此在运行 AFL 时，不需要添加 @@。是否使用@@ 取决于待测程序接受的输入来自 file 还是 stdin。\n1afl-fuzz -i in -o out -- ./hello\n\n4. 结果解读AFL 开始运行后，将会看到如下的界面显示：\n\n\n从这个界面上可以看到 AFL 找到了多少 crash，但还不能直观地显示覆盖率。pythia是一款 AFL 的扩展工具，可以查看代码覆盖率的情况。\nAFL 在运行过程中，会不断地产生输出。输出目录结构如下：\n123456789101112131415161718192021222324out|-- crashes|   |-- README.txt|   |-- id:000000,sig:06,src:000000,op:havoc,rep:64|   |-- id:000001,sig:06,src:000002+000003,op:splice,rep:128|   |-- id:000002,sig:06,src:000003,op:havoc,rep:32|   |-- id:000003,sig:06,src:000002+000003,op:splice,rep:16|   |-- id:000004,sig:06,src:000004,op:havoc,rep:32|   |-- id:000005,sig:11,src:000003+000002,op:splice,rep:64|   `-- id:000006,sig:06,src:000004+000005,op:splice,rep:2|-- fuzz_bitmap|-- fuzzer_stats|-- hangs|-- plot_data`-- queue    |-- id:000000,orig:seed    |-- id:000001,src:000000,op:havoc,rep:16,+cov    |-- id:000002,src:000000+000001,op:splice,rep:4,+cov    |-- id:000003,src:000001,op:arith8,pos:1,val:-5,+cov    |-- id:000004,src:000001,op:arith8,pos:1,val:-9,+cov    `-- id:000005,src:000002+000003,op:splice,rep:4,+cov3 directories, 17 files\n\n\nqueue&#x2F; - 存放 AFL 生成的触发新代码路径的测试样本\n\ncrashes&#x2F; - 存放能触发待测程序崩溃的测试样本\n\nhangs&#x2F; - 存发导致待测程序超时的测试样本\n\nfuzzer_stats - 文本文件，包含了 fuzzer 的实时统计信息，如执行速度、路径覆盖等度量指标。这个文件不断更新以反映当前的 fuzzing 状态。\n\nplot_data - 文本文件，包含了 AFL 执行过程中的统计数据。使用 AFL 的 afl-plot 工具处理 plot_data 文件，可以生成 fuzz 过程的可视化图像。\n\nfuzz_bitmap - 这是用来记录路径覆盖率的位图（coverage bitmap），非人类可读。AFL 使用这个位图来跟踪程序在处理不同输入时执行的不同分支，用来帮助 AFL 识别新的、唯一的代码路径，以便后续生成更具有探索性的测试样本。\n\n\n四、AFL 的 QEMU 模式  前面的例子中，AFL 在对待测程序的源码进行编译时插桩。实际中，我们不一定能拿到待测源码，我们要测的可能是一个已经编译好的二进制文件。这种情况下 Libfuzzer 就无能为力了，但 AFL 还能用，这依赖于 AFL 的 QEMU 模式。\nAFL 的 QEMU 模式，也称为 AFL-QEMU，允许你在二进制模糊测试中使用 AFL，即使源代码不可用。这在对闭源应用进行模糊测试时非常有用。这种模式使用 QEMU 的用户模式仿真，来运行并分析非原生的二进制文件。以下是安装 AFL 的 QEMU 模式和使用步骤的指南：\n1. 编译 QEMU 支持  在 AFL 主目录下有一个专门的 QEMU 模式目录。进入该目录并编译 QEMU 模式，过程中可能缺少依赖项，根据提示进行安装即可：\n12cd qemu_mode./build_qemu_support.sh\n\n2. AFL-QEMU 使用步骤  用法很简单，在 AFL 运行命令中添加 -Q 参数即可：\n1afl-fuzz -i input -o output -Q -- /path/to/binary @@\n\n\n五、AFL 的升级版——AFL++AFL++ 可以看作是原始 AFL 的”增强版”，对 AFL 的调度策略和变异算法进行了很多改进，同时还引入了很多新特性，如 CMPLOG 和持久化这样的特性。\n1. CMPLOGCMPLOG 是 AFL++ 引入的一个新功能，类似于 Libfuzzer 中的 trace-cmp，它可以极大地提高代码覆盖率。CMPLOG 的主要作用是对程序中的所有比较操作进行记录，包括等于、不等于、小于等逻辑比较。当 fuzzer 执行时，CMPLOG 能够捕获比较操作的参数，并将对应的值添加到 fuzzer 的输入测试用例中。这个过程实际上帮助 fuzzer 更好地理解代码中期待的输入，特别是那些用于逻辑分支的字面值和魔法数字。这种理解能够导向更深入的路径覆盖，进而揭露隐藏更深的潜在缺陷。\n2. 持久化模式AFL 的持久化（persistent）模式允许目标程序在单个进程周期内重复执行多次模糊测试用例。这对性能产生了显著的提升，因为它减少了程序启动和终止的开销，特别是当测试的目标程序需要很大的初始化成本时。在 AFL++ 中，持久化模式的执行更为高效，它允许模糊器在目标程序中一次性执行多个测试用例，而非每次执行一个用例都重启目标程序。有了持久化模式，AFL++ 能够在相同的时间内执行更多的测试迭代，从而提高漏洞检测的速度。\n六、小结AFL 是一款强大的模糊测试工具，实践中 AFL++ 的应用非常广泛。相比 Libfuzzer，AFL++ 不局限于源码，并且支持多种 cpu 架构，还有丰富的插件生态可以使用。\n但模糊测试本身存在覆盖率瓶颈的问题，难以探索复杂的程序路径，这时候可以结合其他的技术，如符号执行来突破。","dateCreated":"2023-10-15T11:23:55+08:00","dateModified":"2024-05-30T16:11:03+08:00","datePublished":"2023-10-15T11:23:55+08:00","description":"模糊测试工具 AFL（American Fuzzy Lop）的原理介绍与实践应用","headline":"AFL 原理与实践","image":[],"mainEntityOfPage":{"@type":"WebPage","@id":"https://www.stepbystep.asia/2023/AFL%E5%8E%9F%E7%90%86%E4%B8%8E%E5%AE%9E%E8%B7%B5/"},"publisher":{"@type":"Organization","name":"一瓢清浅","sameAs":["#about","https://github.com/jiliguluss"],"image":"photo.jpg","logo":{"@type":"ImageObject","url":"photo.jpg"}},"url":"https://www.stepbystep.asia/2023/AFL%E5%8E%9F%E7%90%86%E4%B8%8E%E5%AE%9E%E8%B7%B5/","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\n在软件开发的世界里，质量和安全性是评估产品成败的重要指标。模糊测试作为一种高效的自动化测试方法，专门用来发现程序中的错误和安全漏洞。本文旨在详细介绍 AFL（American Fuzzy Lop）的基本原理和使用方法。\n一、AFL 的原理介绍  模糊测试是一种通过向软件输入异常或随机数据的自动化技术，目的是发现程序在处理意外或边缘情况输入时的错误。AFL 是这一测试策略中的杰出代表，它通过不断学习程序反应来改进测试用例，提高测试的覆盖率和发现漏洞的概率。\nAFL 利用遗传算法，不断生成测试用例，并通过动态插桩技术监控程序的行为，特别是程序的代码覆盖情况。当新的输入能触发新的代码路径时，这个输入会被保存以供进一步的测试。该过程可以形成一个反馈循环，不断优化测试用例以探索更多程序状态。\n下面是 AFL 工作流程图，展示了从准备测试用例到监控程序行为的步骤：\ngraph TD\n    A[Compile with afl-gcc] --> B[Initialize seed corpus] --> C[Fuzzing loop] --> D[Select seed from corpus queue]\n    D[Select seed from corpus queue] --> E[Mutate selected seed] --> F[Execute with mutated testcase]\n    F[Execute with mutated testcase] --> G[Monitor for crashes and coverage update] --> H{Check for new coverage}\n    H{Check for new coverage} -- YES --> I[Save mutated testcase to queue] --> D\n    H{Check for new coverage} -- NO --> D\n\n流程图详细展示了 AFL 在模糊测试中的核心步骤：\n\n编译（Compile with afl-gcc） - 使用 AFL 提供的编译器 afl-gcc，对目标程序进行编译，实现程序的动态插桩。\n\n初始化种子库（Initialize seed corpus） - 创建初始测试用例集（种子库），这些测试用例将作为模糊测试的起点。\n\n模糊测试循环（Fuzzing loop） - 一个不断循环的过程，根据测试结果更新种子库，并反复执行下列子步骤：a. 选择种子（Select seed from corpus queue） - 从种子库中选择一个种子文件作为当前测试的输入。b. 突变种子（Mutate selected seed） - 对选中的种子文件应用突变算法，生成新的测试用例。c. 执行测试（Execute with mutated test case） - 将变异后的测试用例作为输入执行已插桩的目标程序。d. 监控结果（Monitor for crashes and coverage update） - 监控程序的执行情况，记录崩溃和代码覆盖率的变化。\n\n覆盖率检查（Check for new coverage） - 判断是否出现新的代码覆盖，如果有，则将其保存为新测试用例。\n\n保存新测试用例（Save new testcase to queue） - 将触发新代码覆盖的测试用例保存到队列中，用于后续的测试。\n\n\nAFL 采用了 fork 的运行模式，这使得当待测程序出现崩溃时，fuzz 进程不会终止，这一点相较于 LibFuzzer 更具优势。然而，频繁的 fork 操作也导致了 AFL 的效率不如 LibFuzzer。\n二、AFL 安装和运行1. 支持的系统和架构AFL 设计之初主要针对 UNIX-like 系统，其在 Linux 系统上有最好的支持。然而，在社区的努力下，也有 Windows 版本的 AFL，如 winafl，其可以在 Windows 进行模糊测试。\nAFL 还支持多种 CPU 架构，其中对 x86 和 x64 架构的支持最好。如果要支持 ARM 架构，则需要使用 AFL 的 QEMU 模式。\n2. 安装步骤AFL 可以通过源码进行安装：\n123apt install git make gccgit clone https://github.com/google/AFL.git cd AFL &amp;&amp; make\n\n3. 运行参数  在安装并编译完 AFL 之后，可以使用 afl-fuzz 命令来启动模糊测试。一个基本的 AFL fuzz 命令如下：\n1afl-fuzz -i input_dir -o output_dir -- /path/to/program [options] @@\n\n这里：\n\nafl-fuzz 是启动 AFL 模糊测试的程序。\n-i input_dir 指定包含初始化测试用例的目录。\n-o output_dir 指定存放的 fuzzing 结果的目录。\n\n-- 之后的部分是运行被测试程序的命令行，其中 /path/to/program 替换为需要进行模糊测试的程序的路径，[options] 是运行该程序的任何选项或参数。\n如果测试程序需要从文件中读取输入，可以在实际输入文件路径的位置使用 @@ 占位符。AFL 将替换 @@ 来插入它正在测试的输入文件。如果省略这个占位符，AFL 将会把模糊测试用例通过 stdin 传递给测试程序。\n三、AFL 的使用示例  本节使用一个简单的示例，演示 AFL 的操作步骤。\n这是待测源码，其功能是接受一行命令行输入，进行四则运算。其中使用了不安全的 gets 函数，可能导致缓冲区溢出：\n1234567891011121314151617181920212223242526272829303132#include &lt;stdio.h&gt;#include &lt;string.h&gt;int calculate(int a, int b, char op) &#123;    switch (op) &#123;        case &#x27;+&#x27;: return a + b;        case &#x27;-&#x27;: return a - b;        case &#x27;x&#x27;: return a * b;        case &#x27;/&#x27;: return b ? a / b : 0;        default: return 0;    &#125;&#125;int main() &#123;    char input[100];    // unsafe method that may cause buffer overflow    gets(input);    int a, b, result;    char op;    if (sscanf(input, &quot;%d %c %d&quot;, &amp;a, &amp;op, &amp;b) != 3)        return 1;    result = calculate(a, b, op);    printf(&quot;Result: %d\\n&quot;, result);    return 0;&#125;\n\n1. 编译源码  使用 AFL 的编译器 afl-gcc 或afl-clang对源文件 hello.c 进行编译，添加所需要的代码覆盖插桩。afl-gcc或 afl-clang 实际上是对常规的 gcc 或clang编译器进行了封装，通过在编译时进行插桩，来统计 fuzz 过程中的代码覆盖率：\n1afl-gcc -o hello hello.c\n\n2. 准备种子语料库  不论程序是从 file 还是从 stdin 获取数据，AFL 都需要一个初始语料库来启动模糊测试过程。输入（无论是来自 file 或 stdin）是 AFL 用来开始探索程序行为的基础。初始语料库（seed corpus）是一组文件，其中包含了各种有效的输入示例，这些输入会被 AFL 用作模糊测试的起始点。\n从 stdin 读取输入时，AFL 会将语料库中的每个文件内容作为输入在每次测试运行时送到程序的标准输入流中。使用 AFL 时，必须要有初始语料库。注意这一点 AFL 与 Libfuzzer 不同，Libfuzzer 只接受 stdin，不接受 file，初始语料库为可选项。\n12mkdir inecho &#x27;abc&#x27; &gt; in/seed\n\n3. 执行测试  在运行 AFL 之前，需要执行下面的系统设置命令，将字符串”core”写入到文件 /proc/sys/kernel/core_pattern 中。\n在 Linux 系统中，/proc/sys/kernel/core_pattern 文件用于指定当程序崩溃时，内核转储文件（core dump）的文件名模式。通过修改这个文件，可以控制内核生成 core 文件的行为。\n通过执行这个命令，生成的核心转储文件将以”core”命名，这使得 AFL 更容易检测和处理目标程序的崩溃情况，从而更好地进行模糊测试。\n1echo core | tee /proc/sys/kernel/core_pattern\n\n在 hello 中使用 gets 函数从 stdin 中读取数据，因此在运行 AFL 时，不需要添加 @@。是否使用@@ 取决于待测程序接受的输入来自 file 还是 stdin。\n1afl-fuzz -i in -o out -- ./hello\n\n4. 结果解读AFL 开始运行后，将会看到如下的界面显示：\n\n\n从这个界面上可以看到 AFL 找到了多少 crash，但还不能直观地显示覆盖率。pythia是一款 AFL 的扩展工具，可以查看代码覆盖率的情况。\nAFL 在运行过程中，会不断地产生输出。输出目录结构如下：\n123456789101112131415161718192021222324out|-- crashes|   |-- README.txt|   |-- id:000000,sig:06,src:000000,op:havoc,rep:64|   |-- id:000001,sig:06,src:000002+000003,op:splice,rep:128|   |-- id:000002,sig:06,src:000003,op:havoc,rep:32|   |-- id:000003,sig:06,src:000002+000003,op:splice,rep:16|   |-- id:000004,sig:06,src:000004,op:havoc,rep:32|   |-- id:000005,sig:11,src:000003+000002,op:splice,rep:64|   `-- id:000006,sig:06,src:000004+000005,op:splice,rep:2|-- fuzz_bitmap|-- fuzzer_stats|-- hangs|-- plot_data`-- queue    |-- id:000000,orig:seed    |-- id:000001,src:000000,op:havoc,rep:16,+cov    |-- id:000002,src:000000+000001,op:splice,rep:4,+cov    |-- id:000003,src:000001,op:arith8,pos:1,val:-5,+cov    |-- id:000004,src:000001,op:arith8,pos:1,val:-9,+cov    `-- id:000005,src:000002+000003,op:splice,rep:4,+cov3 directories, 17 files\n\n\nqueue&#x2F; - 存放 AFL 生成的触发新代码路径的测试样本\n\ncrashes&#x2F; - 存放能触发待测程序崩溃的测试样本\n\nhangs&#x2F; - 存发导致待测程序超时的测试样本\n\nfuzzer_stats - 文本文件，包含了 fuzzer 的实时统计信息，如执行速度、路径覆盖等度量指标。这个文件不断更新以反映当前的 fuzzing 状态。\n\nplot_data - 文本文件，包含了 AFL 执行过程中的统计数据。使用 AFL 的 afl-plot 工具处理 plot_data 文件，可以生成 fuzz 过程的可视化图像。\n\nfuzz_bitmap - 这是用来记录路径覆盖率的位图（coverage bitmap），非人类可读。AFL 使用这个位图来跟踪程序在处理不同输入时执行的不同分支，用来帮助 AFL 识别新的、唯一的代码路径，以便后续生成更具有探索性的测试样本。\n\n\n四、AFL 的 QEMU 模式  前面的例子中，AFL 在对待测程序的源码进行编译时插桩。实际中，我们不一定能拿到待测源码，我们要测的可能是一个已经编译好的二进制文件。这种情况下 Libfuzzer 就无能为力了，但 AFL 还能用，这依赖于 AFL 的 QEMU 模式。\nAFL 的 QEMU 模式，也称为 AFL-QEMU，允许你在二进制模糊测试中使用 AFL，即使源代码不可用。这在对闭源应用进行模糊测试时非常有用。这种模式使用 QEMU 的用户模式仿真，来运行并分析非原生的二进制文件。以下是安装 AFL 的 QEMU 模式和使用步骤的指南：\n1. 编译 QEMU 支持  在 AFL 主目录下有一个专门的 QEMU 模式目录。进入该目录并编译 QEMU 模式，过程中可能缺少依赖项，根据提示进行安装即可：\n12cd qemu_mode./build_qemu_support.sh\n\n2. AFL-QEMU 使用步骤  用法很简单，在 AFL 运行命令中添加 -Q 参数即可：\n1afl-fuzz -i input -o output -Q -- /path/to/binary @@\n\n\n五、AFL 的升级版——AFL++AFL++ 可以看作是原始 AFL 的”增强版”，对 AFL 的调度策略和变异算法进行了很多改进，同时还引入了很多新特性，如 CMPLOG 和持久化这样的特性。\n1. CMPLOGCMPLOG 是 AFL++ 引入的一个新功能，类似于 Libfuzzer 中的 trace-cmp，它可以极大地提高代码覆盖率。CMPLOG 的主要作用是对程序中的所有比较操作进行记录，包括等于、不等于、小于等逻辑比较。当 fuzzer 执行时，CMPLOG 能够捕获比较操作的参数，并将对应的值添加到 fuzzer 的输入测试用例中。这个过程实际上帮助 fuzzer 更好地理解代码中期待的输入，特别是那些用于逻辑分支的字面值和魔法数字。这种理解能够导向更深入的路径覆盖，进而揭露隐藏更深的潜在缺陷。\n2. 持久化模式AFL 的持久化（persistent）模式允许目标程序在单个进程周期内重复执行多次模糊测试用例。这对性能产生了显著的提升，因为它减少了程序启动和终止的开销，特别是当测试的目标程序需要很大的初始化成本时。在 AFL++ 中，持久化模式的执行更为高效，它允许模糊器在目标程序中一次性执行多个测试用例，而非每次执行一个用例都重启目标程序。有了持久化模式，AFL++ 能够在相同的时间内执行更多的测试迭代，从而提高漏洞检测的速度。\n六、小结AFL 是一款强大的模糊测试工具，实践中 AFL++ 的应用非常广泛。相比 Libfuzzer，AFL++ 不局限于源码，并且支持多种 cpu 架构，还有丰富的插件生态可以使用。\n但模糊测试本身存在覆盖率瓶颈的问题，难以探索复杂的程序路径，这时候可以结合其他的技术，如符号执行来突破。","dateCreated":"2023-10-15T11:23:55+08:00","dateModified":"2024-05-30T16:11:03+08:00","datePublished":"2023-10-15T11:23:55+08:00","description":"模糊测试工具 AFL（American Fuzzy Lop）的原理介绍与实践应用","headline":"AFL 原理与实践","image":[],"mainEntityOfPage":{"@type":"WebPage","@id":"https://www.stepbystep.asia/2023/AFL%E5%8E%9F%E7%90%86%E4%B8%8E%E5%AE%9E%E8%B7%B5/"},"publisher":{"@type":"Organization","name":"一瓢清浅","sameAs":["#about","https://github.com/jiliguluss"],"image":"photo.jpg","logo":{"@type":"ImageObject","url":"photo.jpg"}},"url":"https://www.stepbystep.asia/2023/AFL%E5%8E%9F%E7%90%86%E4%B8%8E%E5%AE%9E%E8%B7%B5/","keywords":"Fuzz, 安全, 工具, AFL"}</script>
     <meta name="description" content="模糊测试工具 AFL（American Fuzzy Lop）的原理介绍与实践应用">
 <meta property="og:type" content="blog">
 <meta property="og:title" content="AFL 原理与实践">
@@ -26,10 +26,10 @@
 <meta property="article:published_time" content="2023-10-15T03:23:55.000Z">
 <meta property="article:modified_time" content="2024-05-30T08:11:03.608Z">
 <meta property="article:author" content="一瓢清浅">
-<meta property="article:tag" content="AFL">
 <meta property="article:tag" content="Fuzz">
 <meta property="article:tag" content="安全">
 <meta property="article:tag" content="工具">
+<meta property="article:tag" content="AFL">
 <meta name="twitter:card" content="summary">
 <meta name="twitter:image" content="https://www.stepbystep.asia/2023/AFL%E5%8E%9F%E7%90%86%E4%B8%8E%E5%AE%9E%E8%B7%B5/AFL%E8%BF%90%E8%A1%8C%E7%95%8C%E9%9D%A2.png">
     
diff --git "a/2023/LibAFL\347\256\200\344\273\213/index.html" "b/2023/LibAFL\347\256\200\344\273\213/index.html"
index 41e50c8..6c851f8 100644
--- "a/2023/LibAFL\347\256\200\344\273\213/index.html"
+++ "b/2023/LibAFL\347\256\200\344\273\213/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\n1. 什么是 LibAFLLibAFL 是一款用 Rust 语言开发的开源模糊测试框架，它将模糊测试的组件划分成一组模块文件，用户可以基于这组模块，快速实现自定义的 fuzz 引擎。\n2. 为什么要设计 LibAFL 现有的 Fuzz 引擎很多是基于 AFL 进行改造的，不同的改造之间存在不兼容的情况，比如 Fairfuzz 是基于 AFL 改造的，但是 AFL++ 不支持 Fairfuzz。如果希望把多种 Fuzz 优化技术集合在一起，工程难度很大。\nAFL++ 是 AFL 的进化版，它在 AFL 的基础上集成了很多 Fuzz 优化技术，并支持以插件的方式进行功能扩展，例如可以自定义 mutator。但 AFL++ 还是受限于 AFL 本身的程序设计，与 mutator 无关的优化技术，与 AFL++ 的集成也比较困难。\n3. LibAFL 整体架构 （1）Fuzz 引擎的相关组件 \nInput 指 fuzz 过程中，传递给 target 的输入数据。Libfuzzer 和 AFL 默认的输入格式，都是字节数组。fuzz 的入口函数在以这个字节数组作为入参，然后对字节数组进行切片和类型变换，转换为 target 中待测函数所要求的参数形式，再对待测函数进行调用。\n\nCorpus 指 fuzz 过程中，用来存放有效 input 的语料库。AFL 必须要有初始语料库，Libfuzzer 可以不提供初始语料库。语料库可以存放在磁盘中通过 io 读写，也可以全部加载进内存中。前者效率低，后者内存消耗大。\n\nScheduler 指 fuzz 引擎从语料库中选择 input 的调度机制。语料库中包含大量的 input，fuzz 每轮执行需要挑选一个 input。调度机制决定了 input 的挑选方法，简单的实现包括先入先出、随机挑选等。对调度机制进行优化，也是改进 fuzz 的一个方向。\n\nStagefuzz 的每一轮执行实际上都包含多个步骤，每个步骤都可以理解为一个阶段。比如变异阶段是对 input 进行随机变异操作，分析阶段可以使用污点分析等技术搜集更多信息，语料库精简阶段是对语料库进行筛选操作。一连串的阶段性操作构成了一次完整的 fuzz 执行过程。\n\nObserver 观察器用来收集 fuzz 单词运行过程中的信息。在覆盖率引导的 fuzz 引擎中，观察器会看这次执行过程中，input 所经过的代码路径。AFL 中的 bitmap 就是一个观察器，AFL 将代码路径转化为 branch 或 edge 的集合，并记录在 bitmap 中。\n\nExecutor 执行器负责将 input 喂给 target 开启一次 fuzz 执行。不同的 fuzz 工具，可能有不同的执行方式。Libfuzzer 是一个单进程的执行模式，在一个进程中生成 input 运行 target，并不断循环这个过程；AFL 则通过 fork 模式，每次 input 都会 fork 出一个子进程，在子进程中运行 target。\n\nFeedback 反馈通常是基于观察器收集到的执行结果，来判断这次 fuzz 执行过程中，使用的 input 是不是一个有效的输入，如果是有效输入才会保存到语料库中。在覆盖率引导的 fuzz 引擎中，当一个 input 能命中此前都没有到达的代码区块时，才会被认为是有效的。\n\nMutator 变异器接受一个 input 作为输入，通过修改、插入、删除等变异操作，衍生出一个新的 input。在 AFL 和 Libfuzzer 中，input 为字节数组，变异器通过对字节位和字节块进行改变，进而得到新的 input。在 target 输入需要满足指定格式时，自定义变异器是一条可行的途径。\n\nGenerator 生成器是指从头生成一个 input 作为输入，它不是基于已有的 input 进行修改。常用于基于生成的 fuzz 引擎中，例如 peach 中通过定义 input 的数据模型来指导 input 的生成。\n\n\n（2）LibAFL 的架构设计 LibAFL 的核心架构设计如下图：\n\n\n 其中的一些实体名词含义参见前一部分介绍。在这个架构图中，有三个比较大的组件：\n\nState：负责记录和维护 fuzzer 运行过程中的需要持久化的信息。它包括了各类统计数据、测试用例数据、已发现的漏洞、程序执行的路径等。这些信息用于帮助 fuzzer 做出智能决策，优化测试过程。\n\nFuzzer：负责实际执行模糊测试。它使用各种算法和策略来生成或者变异输入数据，然后将这些数据用于测试目标程序，以期发现潜在的安全漏洞。Fuzzer 需要与状态组件紧密协作，以使用状态信息引导自己的测试过程。\n\nEvent Manager：事件管理器作为 LibAFL 架构中的通信枢纽，它负责协调不同组件间的交互工作。事件管理器处理各种事件，如新发现的错误、状态更新信号等，并确保这些信息及时、正确地在组件间传递。\n\n\n4. LibAFL 使用方法 \n 简单的模糊器实例 - LibAFL 模糊测试库 \nfuzzing-101-with-libafl\n\n5. 参考资料 \nLibAFL: A Framework to Build Modular and Reusable Fuzzers\nLibAFL 学习笔记 \nLibAFL 中文文档 \n","dateCreated":"2023-11-18T10:38:08+08:00","dateModified":"2024-06-27T16:30:08+08:00","datePublished":"2023-11-18T10:38:08+08:00","description":"LibAFL 是用 Rust 开发的一款模糊测试库，支持 Fuzz 各模块的灵活定制 ","headline":"LibAFL 简介","image":[],"mainEntityOfPage":{"@type":"WebPage","@id":"https://www.stepbystep.asia/2023/LibAFL%E7%AE%80%E4%BB%8B/"},"publisher":{"@type":"Organization","name":"一瓢清浅","sameAs":["#about","https://github.com/jiliguluss"],"image":"photo.jpg","logo":{"@type":"ImageObject","url":"photo.jpg"}},"url":"https://www.stepbystep.asia/2023/LibAFL%E7%AE%80%E4%BB%8B/","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\n1. 什么是 LibAFLLibAFL 是一款用 Rust 语言开发的开源模糊测试框架，它将模糊测试的组件划分成一组模块文件，用户可以基于这组模块，快速实现自定义的 fuzz 引擎。\n2. 为什么要设计 LibAFL 现有的 Fuzz 引擎很多是基于 AFL 进行改造的，不同的改造之间存在不兼容的情况，比如 Fairfuzz 是基于 AFL 改造的，但是 AFL++ 不支持 Fairfuzz。如果希望把多种 Fuzz 优化技术集合在一起，工程难度很大。\nAFL++ 是 AFL 的进化版，它在 AFL 的基础上集成了很多 Fuzz 优化技术，并支持以插件的方式进行功能扩展，例如可以自定义 mutator。但 AFL++ 还是受限于 AFL 本身的程序设计，与 mutator 无关的优化技术，与 AFL++ 的集成也比较困难。\n3. LibAFL 整体架构 （1）Fuzz 引擎的相关组件 \nInput 指 fuzz 过程中，传递给 target 的输入数据。Libfuzzer 和 AFL 默认的输入格式，都是字节数组。fuzz 的入口函数在以这个字节数组作为入参，然后对字节数组进行切片和类型变换，转换为 target 中待测函数所要求的参数形式，再对待测函数进行调用。\n\nCorpus 指 fuzz 过程中，用来存放有效 input 的语料库。AFL 必须要有初始语料库，Libfuzzer 可以不提供初始语料库。语料库可以存放在磁盘中通过 io 读写，也可以全部加载进内存中。前者效率低，后者内存消耗大。\n\nScheduler 指 fuzz 引擎从语料库中选择 input 的调度机制。语料库中包含大量的 input，fuzz 每轮执行需要挑选一个 input。调度机制决定了 input 的挑选方法，简单的实现包括先入先出、随机挑选等。对调度机制进行优化，也是改进 fuzz 的一个方向。\n\nStagefuzz 的每一轮执行实际上都包含多个步骤，每个步骤都可以理解为一个阶段。比如变异阶段是对 input 进行随机变异操作，分析阶段可以使用污点分析等技术搜集更多信息，语料库精简阶段是对语料库进行筛选操作。一连串的阶段性操作构成了一次完整的 fuzz 执行过程。\n\nObserver 观察器用来收集 fuzz 单词运行过程中的信息。在覆盖率引导的 fuzz 引擎中，观察器会看这次执行过程中，input 所经过的代码路径。AFL 中的 bitmap 就是一个观察器，AFL 将代码路径转化为 branch 或 edge 的集合，并记录在 bitmap 中。\n\nExecutor 执行器负责将 input 喂给 target 开启一次 fuzz 执行。不同的 fuzz 工具，可能有不同的执行方式。Libfuzzer 是一个单进程的执行模式，在一个进程中生成 input 运行 target，并不断循环这个过程；AFL 则通过 fork 模式，每次 input 都会 fork 出一个子进程，在子进程中运行 target。\n\nFeedback 反馈通常是基于观察器收集到的执行结果，来判断这次 fuzz 执行过程中，使用的 input 是不是一个有效的输入，如果是有效输入才会保存到语料库中。在覆盖率引导的 fuzz 引擎中，当一个 input 能命中此前都没有到达的代码区块时，才会被认为是有效的。\n\nMutator 变异器接受一个 input 作为输入，通过修改、插入、删除等变异操作，衍生出一个新的 input。在 AFL 和 Libfuzzer 中，input 为字节数组，变异器通过对字节位和字节块进行改变，进而得到新的 input。在 target 输入需要满足指定格式时，自定义变异器是一条可行的途径。\n\nGenerator 生成器是指从头生成一个 input 作为输入，它不是基于已有的 input 进行修改。常用于基于生成的 fuzz 引擎中，例如 peach 中通过定义 input 的数据模型来指导 input 的生成。\n\n\n（2）LibAFL 的架构设计 LibAFL 的核心架构设计如下图：\n\n\n 其中的一些实体名词含义参见前一部分介绍。在这个架构图中，有三个比较大的组件：\n\nState：负责记录和维护 fuzzer 运行过程中的需要持久化的信息。它包括了各类统计数据、测试用例数据、已发现的漏洞、程序执行的路径等。这些信息用于帮助 fuzzer 做出智能决策，优化测试过程。\n\nFuzzer：负责实际执行模糊测试。它使用各种算法和策略来生成或者变异输入数据，然后将这些数据用于测试目标程序，以期发现潜在的安全漏洞。Fuzzer 需要与状态组件紧密协作，以使用状态信息引导自己的测试过程。\n\nEvent Manager：事件管理器作为 LibAFL 架构中的通信枢纽，它负责协调不同组件间的交互工作。事件管理器处理各种事件，如新发现的错误、状态更新信号等，并确保这些信息及时、正确地在组件间传递。\n\n\n4. LibAFL 使用方法 \n 简单的模糊器实例 - LibAFL 模糊测试库 \nfuzzing-101-with-libafl\n\n5. 参考资料 \nLibAFL: A Framework to Build Modular and Reusable Fuzzers\nLibAFL 学习笔记 \nLibAFL 中文文档 \n","dateCreated":"2023-11-18T10:38:08+08:00","dateModified":"2024-06-27T16:30:08+08:00","datePublished":"2023-11-18T10:38:08+08:00","description":"LibAFL 是用 Rust 开发的一款模糊测试库，支持 Fuzz 各模块的灵活定制 ","headline":"LibAFL 简介","image":[],"mainEntityOfPage":{"@type":"WebPage","@id":"https://www.stepbystep.asia/2023/LibAFL%E7%AE%80%E4%BB%8B/"},"publisher":{"@type":"Organization","name":"一瓢清浅","sameAs":["#about","https://github.com/jiliguluss"],"image":"photo.jpg","logo":{"@type":"ImageObject","url":"photo.jpg"}},"url":"https://www.stepbystep.asia/2023/LibAFL%E7%AE%80%E4%BB%8B/","keywords":"Fuzz, 安全, 工具, AFL"}</script>
     <meta name="description" content="LibAFL 是用 Rust 开发的一款模糊测试库，支持 Fuzz 各模块的灵活定制">
 <meta property="og:type" content="blog">
 <meta property="og:title" content="LibAFL 简介">
@@ -26,10 +26,10 @@
 <meta property="article:published_time" content="2023-11-18T02:38:08.000Z">
 <meta property="article:modified_time" content="2024-06-27T08:30:08.593Z">
 <meta property="article:author" content="一瓢清浅">
-<meta property="article:tag" content="AFL">
 <meta property="article:tag" content="Fuzz">
 <meta property="article:tag" content="安全">
 <meta property="article:tag" content="工具">
+<meta property="article:tag" content="AFL">
 <meta name="twitter:card" content="summary">
 <meta name="twitter:image" content="https://www.stepbystep.asia/2023/LibAFL%E7%AE%80%E4%BB%8B/LibAFL%E6%9E%B6%E6%9E%84%E8%AE%BE%E8%AE%A1.png">
     
diff --git "a/2024/AFLplusplus\346\272\220\347\240\201\345\210\206\346\236\220\342\200\224\342\200\224\345\220\214\346\255\245\346\234\272\345\210\266/index.html" "b/2024/AFLplusplus\346\272\220\347\240\201\345\210\206\346\236\220\342\200\224\342\200\224\345\220\214\346\255\245\346\234\272\345\210\266/index.html"
index 65520ba..7060cfb 100644
--- "a/2024/AFLplusplus\346\272\220\347\240\201\345\210\206\346\236\220\342\200\224\342\200\224\345\220\214\346\255\245\346\234\272\345\210\266/index.html"
+++ "b/2024/AFLplusplus\346\272\220\347\240\201\345\210\206\346\236\220\342\200\224\342\200\224\345\220\214\346\255\245\346\234\272\345\210\266/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++ 同步 interesting corpus 失败的问题，不得不嗑一嗑 AFL++ 的源码了，该来的躲不掉，虽然 C 代码让我有点头大。\n一、同步机制  常规情况下 AFL++ 是以单实例运行的。三个臭皮匠顶个诸葛亮，多开几个 AFL++ 实例一起跑是可行的，AFL++ 和其他的 Fuzz 工具（LibFuzzer、HonggFuzz）一起跑也是可以的。\n通过 afl-fuzz -h 可以看到 AFL++ 提供了相关的命令参数：\n\nOther stuff:&emsp;-M&#x2F;-S id&emsp;- distributed mode (-M sets -Z and disables trimming)&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;see docs&#x2F;fuzzing_in_depth.md#c-using-multiple-cores&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;for effective recommendations for parallel fuzzing.&emsp;-F path&emsp;- sync to a foreign fuzzer queue directory (requires -M, can&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;be specified up to 32 times)\n\n简而言之，AFL++ 同步相关的几个参数如下：\n\n-M：指定 AFL++ 主实例。主实例会从 -S 指定的从实例、-F 指定的其他 Fuzz 中同步有趣的测试用例。主实例只有一个，负责管理所有的测试用例。\n-S：指定 AFL++ 从实例。从实例产生的有趣测试用例将被同步到 -M 指定的主实例中，从实例也会从 -M 指定的主实例中同步有趣的测试用例。\n-F：指定其他 Fuzz 实例的 corpus 目录。由其他 Fuzz 产生的有趣的测试用例，将会被同步到 -M 指定的主实例中。\n\n可以看到  主实例位于多实例运行模式的核心地位，它负责汇总和分发 AFL++ 的测试用例。\n123456789101112131415  +---------+       +---------+  | Fuzzer 1|       | Fuzzer 2|  |   (F)   |       |   (F)   |  +----+----+       +----+----+       |                 |       v                 v+------+-----------------+------+|           Master (M)          |+-----+---------------+---------+      ^  |            ^  |      |  v            |  v  +---------+      +---------+  | Slave 1 |      | Slave 2 |  |   (S)   |      |   (S)   |  +---------+      +---------+\n\n实际使用时，执行命令参考如下：\n123afl-fuzz -i inputs -o outputs -M master -F /path/to/foreign_fuzzer1/queue -F /path/to/foreign_fuzzer2/queue -- ./targetafl-fuzz -i inputs -o outputs -S slave1 -- ./targetafl-fuzz -i inputs -o outputs -S slave2 -- ./target\n\n二、源码分析 AFL++ 的源码入口为afl_fuzz.c 的main函数。AFL++ 从其他 fuzzer 中同步 corpus，是通过 sync_fuzzers 函数来实现的。\n在 main 函数中，可以看到对 sync_fuzzers 函数的调用。一路跟踪下来，代码调用关系参考如下时序图：\nsequenceDiagram\n    participant main\n    participant sync_fuzzers\n    participant read_foreign_testcases\n    participant update_sync_time\n    participant scandir\n    participant fuzz_run_target\n    participant save_if_interesting\n    participant has_new_bits\n    participant describe_op\n    participant ck_write\n    participant add_to_queue\n\n    main->>sync_fuzzers: 开始同步\n    loop 遍历 AFL++ 的 out 目录中的子目录 d_name\n        sync_fuzzers->>update_sync_time: 更新同步时间\n        sync_fuzzers->>scandir: 读取 d_name/queue 目录中的 corpus 列表\n        loop 遍历新增的 corpus（通过 corpus 的 id 号来识别）\n            sync_fuzzers->>fuzz_run_target: 用 corpus 作为输入运行一次 target\n            fuzz_run_target-->>sync_fuzzers: 返回 target 运行结果\n            sync_fuzzers->>save_if_interesting: 检查并保存 corpus\n            save_if_interesting->>has_new_bits: 检查 corpus 是否为 interesting\n            has_new_bits-->>save_if_interesting: 返回检查结果\n            alt 如果 corpus 是 interesting\n                save_if_interesting->>describe_op: 为 corpus 创建文件名\n                describe_op-->>save_if_interesting: 返回文件名\n                save_if_interesting-->>ck_write: 将 interesting 的 corpus 保存到 AFL++ 的 queue 目录中\n                save_if_interesting->>add_to_queue: 将 interesting 的 corpus 添加到 AFL++ 的队列中\n            end\n        end\n    end\n    alt 如果指定了其他 Fuzz 的 corpus 目录\n        sync_fuzzers->>read_foreign_testcases: 开始同步其他 Fuzz 的 corpus\n        loop 遍历其他 Fuzz 的 corpus 目录\n            read_foreign_testcases->>scandir: 读取其他 Fuzz 的 corpus 列表\n            loop 遍历其他 Fuzz 的 corpus\n                read_foreign_testcases->>fuzz_run_target: 用 corpus 作为输入运行一次 target\n                fuzz_run_target-->>read_foreign_testcases: 返回 target 运行结果\n                read_foreign_testcases->>save_if_interesting: 检查 corpus 是否为 interesting\n                save_if_interesting->>has_new_bits: 检查 corpus 是否为 interesting\n                has_new_bits-->>save_if_interesting: 返回检查结果\n                alt 如果 corpus 是 interesting\n                    save_if_interesting->>describe_op: 为 corpus 创建文件名\n                    describe_op-->>save_if_interesting: 返回文件名\n                    save_if_interesting-->>ck_write: 将 interesting 的 corpus 保存到 AFL++ 的 queue 目录中\n                    save_if_interesting->>add_to_queue: 将 interesting 的 corpus 添加到 AFL++ 的队列中\n                end\n            end\n        end\n        read_foreign_testcases-->>sync_fuzzers: 同步其他 Fuzz 的 corpus 结束\n    end\n    sync_fuzzers-->>main: 同步完毕\n简而言之，主实例同步从实例过程是这样的：\n\nAFL++ 会检查 out 目录下的文件夹（排除 AFL++ 本身的 default 文件夹）\n如果文件夹中没有 queue 子目录，转 1\n如果文件夹中有 queue，则遍历 queue 下的 corpus\n如果 corpus 是处理过的（根据文件名 id 判断），转 4\n如果 corpus 是没有处理过的，那就用这个 corpus 作为输入，执行一次 target\n分析 target 执行结果，判断 corpus 是否为 interesting，如果不是 interesting，转 3\n如果 corpus 是 interesting，则将 corpus 保存为 out&#x2F;default&#x2F;queue 目录下的文件，并将 corpus 添加到 AFL++ 的内存队列中，再转 3\n\n主实例同步其他 Fuzz 的过程与之类似，只是每次同步时，并不会根据 corpus 文件名的 id 编号过滤已经分析过的 corpus，因此从外部 Fuzz 同步 corpus 的性能较差。\n三、实践应用  如果某一款工具能生成 corpus，但是希望以从示例的方式被主实例同步，需要保证这款工具产生的 corpus 的命名符合以下要求：\n\n以 id: 开头，然后是高位补 0 的六位数字\n第一个 corpus 的 id 从 0 开始，随后的 corpus 依次以 1 递增\n\n其原因读一遍 sync_fuzzers 的源码就明白了，源码面前，了无秘密。\n","dateCreated":"2024-07-16T09:02:06+08:00","dateModified":"2024-07-24T11:41:30+08:00","datePublished":"2024-07-16T09:02:06+08:00","description":"分析 AFL++ 同步机制的相关源码","headline":"AFLplusplus 源码分析——同步机制","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%E5%90%8C%E6%AD%A5%E6%9C%BA%E5%88%B6/"},"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%E5%90%8C%E6%AD%A5%E6%9C%BA%E5%88%B6/","keywords":"Fuzz, 安全, 工具, AFL++"}</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++ 同步 interesting corpus 失败的问题，不得不嗑一嗑 AFL++ 的源码了，该来的躲不掉，虽然 C 代码让我有点头大。\n一、同步机制  常规情况下 AFL++ 是以单实例运行的。三个臭皮匠顶个诸葛亮，多开几个 AFL++ 实例一起跑是可行的，AFL++ 和其他的 Fuzz 工具（LibFuzzer、HonggFuzz）一起跑也是可以的。\n通过 afl-fuzz -h 可以看到 AFL++ 提供了相关的命令参数：\n\nOther stuff:&emsp;-M&#x2F;-S id&emsp;- distributed mode (-M sets -Z and disables trimming)&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;see docs&#x2F;fuzzing_in_depth.md#c-using-multiple-cores&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;for effective recommendations for parallel fuzzing.&emsp;-F path&emsp;- sync to a foreign fuzzer queue directory (requires -M, can&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;be specified up to 32 times)\n\n简而言之，AFL++ 同步相关的几个参数如下：\n\n-M：指定 AFL++ 主实例。主实例会从 -S 指定的从实例、-F 指定的其他 Fuzz 中同步有趣的测试用例。主实例只有一个，负责管理所有的测试用例。\n-S：指定 AFL++ 从实例。从实例产生的有趣测试用例将被同步到 -M 指定的主实例中，从实例也会从 -M 指定的主实例中同步有趣的测试用例。\n-F：指定其他 Fuzz 实例的 corpus 目录。由其他 Fuzz 产生的有趣的测试用例，将会被同步到 -M 指定的主实例中。\n\n可以看到  主实例位于多实例运行模式的核心地位，它负责汇总和分发 AFL++ 的测试用例。\n123456789101112131415  +---------+       +---------+  | Fuzzer 1|       | Fuzzer 2|  |   (F)   |       |   (F)   |  +----+----+       +----+----+       |                 |       v                 v+------+-----------------+------+|           Master (M)          |+-----+---------------+---------+      ^  |            ^  |      |  v            |  v  +---------+      +---------+  | Slave 1 |      | Slave 2 |  |   (S)   |      |   (S)   |  +---------+      +---------+\n\n实际使用时，执行命令参考如下：\n123afl-fuzz -i inputs -o outputs -M master -F /path/to/foreign_fuzzer1/queue -F /path/to/foreign_fuzzer2/queue -- ./targetafl-fuzz -i inputs -o outputs -S slave1 -- ./targetafl-fuzz -i inputs -o outputs -S slave2 -- ./target\n\n二、源码分析 AFL++ 的源码入口为afl_fuzz.c 的main函数。AFL++ 从其他 fuzzer 中同步 corpus，是通过 sync_fuzzers 函数来实现的。\n在 main 函数中，可以看到对 sync_fuzzers 函数的调用。一路跟踪下来，代码调用关系参考如下时序图：\nsequenceDiagram\n    participant main\n    participant sync_fuzzers\n    participant read_foreign_testcases\n    participant update_sync_time\n    participant scandir\n    participant fuzz_run_target\n    participant save_if_interesting\n    participant has_new_bits\n    participant describe_op\n    participant ck_write\n    participant add_to_queue\n\n    main->>sync_fuzzers: 开始同步\n    loop 遍历 AFL++ 的 out 目录中的子目录 d_name\n        sync_fuzzers->>update_sync_time: 更新同步时间\n        sync_fuzzers->>scandir: 读取 d_name/queue 目录中的 corpus 列表\n        loop 遍历新增的 corpus（通过 corpus 的 id 号来识别）\n            sync_fuzzers->>fuzz_run_target: 用 corpus 作为输入运行一次 target\n            fuzz_run_target-->>sync_fuzzers: 返回 target 运行结果\n            sync_fuzzers->>save_if_interesting: 检查并保存 corpus\n            save_if_interesting->>has_new_bits: 检查 corpus 是否为 interesting\n            has_new_bits-->>save_if_interesting: 返回检查结果\n            alt 如果 corpus 是 interesting\n                save_if_interesting->>describe_op: 为 corpus 创建文件名\n                describe_op-->>save_if_interesting: 返回文件名\n                save_if_interesting-->>ck_write: 将 interesting 的 corpus 保存到 AFL++ 的 queue 目录中\n                save_if_interesting->>add_to_queue: 将 interesting 的 corpus 添加到 AFL++ 的队列中\n            end\n        end\n    end\n    alt 如果指定了其他 Fuzz 的 corpus 目录\n        sync_fuzzers->>read_foreign_testcases: 开始同步其他 Fuzz 的 corpus\n        loop 遍历其他 Fuzz 的 corpus 目录\n            read_foreign_testcases->>scandir: 读取其他 Fuzz 的 corpus 列表\n            loop 遍历其他 Fuzz 的 corpus\n                read_foreign_testcases->>fuzz_run_target: 用 corpus 作为输入运行一次 target\n                fuzz_run_target-->>read_foreign_testcases: 返回 target 运行结果\n                read_foreign_testcases->>save_if_interesting: 检查 corpus 是否为 interesting\n                save_if_interesting->>has_new_bits: 检查 corpus 是否为 interesting\n                has_new_bits-->>save_if_interesting: 返回检查结果\n                alt 如果 corpus 是 interesting\n                    save_if_interesting->>describe_op: 为 corpus 创建文件名\n                    describe_op-->>save_if_interesting: 返回文件名\n                    save_if_interesting-->>ck_write: 将 interesting 的 corpus 保存到 AFL++ 的 queue 目录中\n                    save_if_interesting->>add_to_queue: 将 interesting 的 corpus 添加到 AFL++ 的队列中\n                end\n            end\n        end\n        read_foreign_testcases-->>sync_fuzzers: 同步其他 Fuzz 的 corpus 结束\n    end\n    sync_fuzzers-->>main: 同步完毕\n简而言之，主实例同步从实例过程是这样的：\n\nAFL++ 会检查 out 目录下的文件夹（排除 AFL++ 本身的 default 文件夹）\n如果文件夹中没有 queue 子目录，转 1\n如果文件夹中有 queue，则遍历 queue 下的 corpus\n如果 corpus 是处理过的（根据文件名 id 判断），转 4\n如果 corpus 是没有处理过的，那就用这个 corpus 作为输入，执行一次 target\n分析 target 执行结果，判断 corpus 是否为 interesting，如果不是 interesting，转 3\n如果 corpus 是 interesting，则将 corpus 保存为 out&#x2F;default&#x2F;queue 目录下的文件，并将 corpus 添加到 AFL++ 的内存队列中，再转 3\n\n主实例同步其他 Fuzz 的过程与之类似，只是每次同步时，并不会根据 corpus 文件名的 id 编号过滤已经分析过的 corpus，因此从外部 Fuzz 同步 corpus 的性能较差。\n三、实践应用  如果某一款工具能生成 corpus，但是希望以从示例的方式被主实例同步，需要保证这款工具产生的 corpus 的命名符合以下要求：\n\n以 id: 开头，然后是高位补 0 的六位数字\n第一个 corpus 的 id 从 0 开始，随后的 corpus 依次以 1 递增\n\n其原因读一遍 sync_fuzzers 的源码就明白了，源码面前，了无秘密。\n","dateCreated":"2024-07-16T09:02:06+08:00","dateModified":"2024-07-24T11:41:30+08:00","datePublished":"2024-07-16T09:02:06+08:00","description":"分析 AFL++ 同步机制的相关源码","headline":"AFLplusplus 源码分析——同步机制","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%E5%90%8C%E6%AD%A5%E6%9C%BA%E5%88%B6/"},"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%E5%90%8C%E6%AD%A5%E6%9C%BA%E5%88%B6/","keywords":"AFL++, Fuzz, 安全, 工具"}</script>
     <meta name="description" content="分析 AFL++ 同步机制的相关源码">
 <meta property="og:type" content="blog">
 <meta property="og:title" content="AFLplusplus 源码分析——同步机制">
@@ -26,10 +26,10 @@
 <meta property="article:published_time" content="2024-07-16T01:02:06.000Z">
 <meta property="article:modified_time" content="2024-07-24T03:41:30.618Z">
 <meta property="article:author" content="一瓢清浅">
+<meta property="article:tag" content="AFL++">
 <meta property="article:tag" content="Fuzz">
 <meta property="article:tag" content="安全">
 <meta property="article:tag" content="工具">
-<meta property="article:tag" content="AFL++">
 <meta name="twitter:card" content="summary">
 <meta name="twitter:image" content="https://www.stepbystep.asia/2024/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/sync_fuzzers%E6%BA%90%E7%A0%81.png">
     
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 c4aac02..e191000 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-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":"Fuzz, 安全, 工具, AFL++"}</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++ 源码分析——覆盖率">
@@ -25,10 +25,10 @@
 <meta property="article:published_time" content="2024-08-15T09:28:52.000Z">
 <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">
 <meta property="article:tag" content="安全">
 <meta property="article:tag" content="工具">
-<meta property="article:tag" content="AFL++">
 <meta name="twitter:card" content="summary">
     
     
diff --git "a/2024/\347\224\261subprocess-PIPE\345\274\225\345\217\221\347\232\204\350\241\200\346\241\210/index.html" "b/2024/\347\224\261subprocess-PIPE\345\274\225\345\217\221\347\232\204\350\241\200\346\241\210/index.html"
index e8f7cff..15b91a5 100644
--- "a/2024/\347\224\261subprocess-PIPE\345\274\225\345\217\221\347\232\204\350\241\200\346\241\210/index.html"
+++ "b/2024/\347\224\261subprocess-PIPE\345\274\225\345\217\221\347\232\204\350\241\200\346\241\210/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一、案发现场  事情是酱滴：\n我写了个 python 脚本，在脚本中通过 subprocess 启动了 AFL++ 的子进程，对 binary 进行测试。\n然后我还在这个 python 脚本中，使用其他的工具生成针对 binary 有效的 corpus。\n参考前文AFL++ 同步机制，正常情况下 AFL++ 会将其他工具生成的 corpus（已确认能覆盖新的代码分支），同步到 AFL++ 的 queue 目录下。\n但是诡异的事情出现了：AFL++ 没有同步！\n二、破案过程 1. 还原现场 这个 AFL++ 不同步的情况不是必现的，非必现的问题真 TM 难调。\n我换了好几个机器，在 host 和 docker 上分别进行了多轮实验，前前后后跑了一两周的时间，排除了环境问题。虽然有的环境概率高，有的环境概率低，但只要跑的次数够多，都会出现 AFL++ 不同步的问题。\n2. 埋 log在反复跑实验的过程中，也有在 AFL++ 源码中埋 log。\n我在 sync_fuzzers 函数体内，以及调用之处加了很多 log。sync_fuzzers在 afl-fuzz.c 的main函数中有四处调用，编号 1~4 表示在代码中的先后顺序，实际调用流程大概如下：\nflowchart TD\n    A[main] --> B[stop_fuzzing]\n    B --> C[sync_fuzzers 4]\n    A --> D[while loop]\n    D --> E[sync_fuzzers 1]\n    E --> F[do-while loop]\n    F --> G[sync_fuzzers 2]\n    F --> H[sync_fuzzers 3]\n    H --> D\n    G --> D\n通过 log 发现，AFL++ 在同步 corpus 时，主要使用过 sync_fuzzers 1 来完成的。而在未同步的场景中，log 会在 do-while loop 里面中断，后续再也没有打印出sync_fuzzers 1。\n3. gdb 追踪  当 log 也印不出来的时候，gdb 看起来是唯一能用的工具了。\n于是我找了个复现概率高的机器，在启动 python 脚本后，用 gdb attach 脚本所启动的 AFL++ 子进程，并在 sync_fuzzers 的 1~4 处调用都打了断点，接着让 AFL++ 继续跑。\n神奇的事情出现了，AFL++ 正常同步的时候，sync_fuzzers 1总是会命中。然而当跑一阵后，sync_fuzzers 1就再也到不了了。此时 ctrl+c 暂停程序，查看调用栈如下：\n\n\n其中 afl-fuzz-one.c 的 420 行的代码如下，只是调用了 flush 库函数而已：\n\n\n我将此行注释掉，重新 gdb 一次，结果发现会在另一个 flush 处卡住。\n在库函数面前，我们要质疑的是自己的代码。\n三、罪魁祸首  我回头检查了自己的 Python 脚本，启动 AFL++ 的代码如下：\n12345678910111213self.fuzzer_popen = sp.Popen(    cmd,    shell=False,    stdout=sp.PIPE,    stderr=sp.PIPE,    env=env,    preexec_fn=os.setsid,)time.sleep(5)if self.fuzzer_popen.poll() is not None:    raise Exception(f&#x27;start fuzz process failed with error: &#123;self.fuzzer_popen.stderr.read().decode(&quot;utf-8&quot;)&#125;&#x27;)else:    logger.info(f&#x27;start fuzz process whose pid is &#123;self.fuzzer_popen.pid&#125;&#x27;)\n\n我又去查了一下 subprocess 的官方文档，赫然写着 注意事项：\n\nNote This will deadlock when using stdout&#x3D;PIPE or stderr&#x3D;PIPE and the child process generates enough output to a pipe such that it blocks waiting for the OS pipe buffer to accept more data. Use Popen.communicate() when using pipes to avoid that.\n\n破案了破案了，我用了 PIPE 来接受 AFL++ 的 stdout 和 stderr，但是我没有通过 communicate 来读取 PIPE，导致PIPE 中积压了大量的数据，阻碍了 AFL++ 继续flush。\n我被自己蠢哭了，也被 subprocess 坑惨了，修改后的代码如下：\n12345678self.fuzzer_popen = sp.Popen(    cmd,    shell=False,    stdout=sp.DEVNULL,    stderr=sp.DEVNULL,    env=env,    preexec_fn=os.setsid,)\n\n去他娘的 stdout 和 stderr，改完后 AFL++ 同步都正常了~~","dateCreated":"2024-07-30T16:19:00+08:00","dateModified":"2024-08-16T17:30:58+08:00","datePublished":"2024-07-30T16:19:00+08:00","description":"找了大半个月 AFL++ 不同步的原因，到头来都是 subprocess 的锅","headline":"由 subprocess.PIPE 引发的血案","image":[],"mainEntityOfPage":{"@type":"WebPage","@id":"https://www.stepbystep.asia/2024/%E7%94%B1subprocess-PIPE%E5%BC%95%E5%8F%91%E7%9A%84%E8%A1%80%E6%A1%88/"},"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/%E7%94%B1subprocess-PIPE%E5%BC%95%E5%8F%91%E7%9A%84%E8%A1%80%E6%A1%88/","keywords":"安全, AFL++, 开发, Python"}</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一、案发现场  事情是酱滴：\n我写了个 python 脚本，在脚本中通过 subprocess 启动了 AFL++ 的子进程，对 binary 进行测试。\n然后我还在这个 python 脚本中，使用其他的工具生成针对 binary 有效的 corpus。\n参考前文AFL++ 同步机制，正常情况下 AFL++ 会将其他工具生成的 corpus（已确认能覆盖新的代码分支），同步到 AFL++ 的 queue 目录下。\n但是诡异的事情出现了：AFL++ 没有同步！\n二、破案过程 1. 还原现场 这个 AFL++ 不同步的情况不是必现的，非必现的问题真 TM 难调。\n我换了好几个机器，在 host 和 docker 上分别进行了多轮实验，前前后后跑了一两周的时间，排除了环境问题。虽然有的环境概率高，有的环境概率低，但只要跑的次数够多，都会出现 AFL++ 不同步的问题。\n2. 埋 log在反复跑实验的过程中，也有在 AFL++ 源码中埋 log。\n我在 sync_fuzzers 函数体内，以及调用之处加了很多 log。sync_fuzzers在 afl-fuzz.c 的main函数中有四处调用，编号 1~4 表示在代码中的先后顺序，实际调用流程大概如下：\nflowchart TD\n    A[main] --> B[stop_fuzzing]\n    B --> C[sync_fuzzers 4]\n    A --> D[while loop]\n    D --> E[sync_fuzzers 1]\n    E --> F[do-while loop]\n    F --> G[sync_fuzzers 2]\n    F --> H[sync_fuzzers 3]\n    H --> D\n    G --> D\n通过 log 发现，AFL++ 在同步 corpus 时，主要使用过 sync_fuzzers 1 来完成的。而在未同步的场景中，log 会在 do-while loop 里面中断，后续再也没有打印出sync_fuzzers 1。\n3. gdb 追踪  当 log 也印不出来的时候，gdb 看起来是唯一能用的工具了。\n于是我找了个复现概率高的机器，在启动 python 脚本后，用 gdb attach 脚本所启动的 AFL++ 子进程，并在 sync_fuzzers 的 1~4 处调用都打了断点，接着让 AFL++ 继续跑。\n神奇的事情出现了，AFL++ 正常同步的时候，sync_fuzzers 1总是会命中。然而当跑一阵后，sync_fuzzers 1就再也到不了了。此时 ctrl+c 暂停程序，查看调用栈如下：\n\n\n其中 afl-fuzz-one.c 的 420 行的代码如下，只是调用了 flush 库函数而已：\n\n\n我将此行注释掉，重新 gdb 一次，结果发现会在另一个 flush 处卡住。\n在库函数面前，我们要质疑的是自己的代码。\n三、罪魁祸首  我回头检查了自己的 Python 脚本，启动 AFL++ 的代码如下：\n12345678910111213self.fuzzer_popen = sp.Popen(    cmd,    shell=False,    stdout=sp.PIPE,    stderr=sp.PIPE,    env=env,    preexec_fn=os.setsid,)time.sleep(5)if self.fuzzer_popen.poll() is not None:    raise Exception(f&#x27;start fuzz process failed with error: &#123;self.fuzzer_popen.stderr.read().decode(&quot;utf-8&quot;)&#125;&#x27;)else:    logger.info(f&#x27;start fuzz process whose pid is &#123;self.fuzzer_popen.pid&#125;&#x27;)\n\n我又去查了一下 subprocess 的官方文档，赫然写着 注意事项：\n\nNote This will deadlock when using stdout&#x3D;PIPE or stderr&#x3D;PIPE and the child process generates enough output to a pipe such that it blocks waiting for the OS pipe buffer to accept more data. Use Popen.communicate() when using pipes to avoid that.\n\n破案了破案了，我用了 PIPE 来接受 AFL++ 的 stdout 和 stderr，但是我没有通过 communicate 来读取 PIPE，导致PIPE 中积压了大量的数据，阻碍了 AFL++ 继续flush。\n我被自己蠢哭了，也被 subprocess 坑惨了，修改后的代码如下：\n12345678self.fuzzer_popen = sp.Popen(    cmd,    shell=False,    stdout=sp.DEVNULL,    stderr=sp.DEVNULL,    env=env,    preexec_fn=os.setsid,)\n\n去他娘的 stdout 和 stderr，改完后 AFL++ 同步都正常了~~","dateCreated":"2024-07-30T16:19:00+08:00","dateModified":"2024-08-16T17:30:58+08:00","datePublished":"2024-07-30T16:19:00+08:00","description":"找了大半个月 AFL++ 不同步的原因，到头来都是 subprocess 的锅","headline":"由 subprocess.PIPE 引发的血案","image":[],"mainEntityOfPage":{"@type":"WebPage","@id":"https://www.stepbystep.asia/2024/%E7%94%B1subprocess-PIPE%E5%BC%95%E5%8F%91%E7%9A%84%E8%A1%80%E6%A1%88/"},"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/%E7%94%B1subprocess-PIPE%E5%BC%95%E5%8F%91%E7%9A%84%E8%A1%80%E6%A1%88/","keywords":"AFL++, 安全, 开发, Python"}</script>
     <meta name="description" content="找了大半个月 AFL++ 不同步的原因，到头来都是 subprocess 的锅">
 <meta property="og:type" content="blog">
 <meta property="og:title" content="由 subprocess.PIPE 引发的血案">
@@ -27,8 +27,8 @@
 <meta property="article:published_time" content="2024-07-30T08:19:00.000Z">
 <meta property="article:modified_time" content="2024-08-16T09:30:58.371Z">
 <meta property="article:author" content="一瓢清浅">
-<meta property="article:tag" content="安全">
 <meta property="article:tag" content="AFL++">
+<meta property="article:tag" content="安全">
 <meta property="article:tag" content="开发">
 <meta property="article:tag" content="Python">
 <meta name="twitter:card" content="summary">
diff --git "a/2024/\350\275\257\350\200\203\346\236\266\346\236\204\342\200\224\342\200\224\346\225\260\346\215\256\345\272\223\350\256\276\350\256\241\344\270\216\345\273\272\346\250\241/index.html" "b/2024/\350\275\257\350\200\203\346\236\266\346\236\204\342\200\224\342\200\224\346\225\260\346\215\256\345\272\223\350\256\276\350\256\241\344\270\216\345\273\272\346\250\241/index.html"
index 12d8ccf..5a373f2 100644
--- "a/2024/\350\275\257\350\200\203\346\236\266\346\236\204\342\200\224\342\200\224\346\225\260\346\215\256\345\272\223\350\256\276\350\256\241\344\270\216\345\273\272\346\250\241/index.html"
+++ "b/2024/\350\275\257\350\200\203\346\236\266\346\236\204\342\200\224\342\200\224\346\225\260\346\215\256\345\272\223\350\256\276\350\256\241\344\270\216\345\273\272\346\250\241/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一、数据库结构  典型的数据库结构可归纳为“三级模式，两级映射”：\n\n\n\n三级模式：\n\n外模式：是数据库用户能看见和使用的局部数据的逻辑结构，与某一应用有关的数据逻辑表示。对应用户视图，面向数据库用户。\n概念（逻辑）模式：是数据库中全体数据的逻辑结构和特征的描述，所有用户的公共数据视图。对应数据库表，面向数据库管理员。\n内模式：是数据物理结构和存储方式的描述，数据在数据库内部的表示方式。对应物理文件，面向系统程序员。\n\n\n两级映射：保证两类独立性，逻辑独立比物理独立更难实现\n\n外模式 - 模式映射：保证  逻辑独立性，即当逻辑模式发生改变时，应用程序不用修改。\n模式 - 内模式映射：保证  物理独立性，即当内模式发生改变时，应用程序不用修改。\n\n\n\n二、数据库理论  关系型数据库中的  关系  是指由行列组成的二维表文件，每行表示一条记录，每列表示一个属性。关系模型  是关系的逻辑描述，可以表示为：关系名(属性 1, 属性 2, …, 属性 N)。\n1. 关系运算  关系代数的基本运算主要有交、并、差、笛卡尔积、选择、投影、连接和除法运算。\n交、并、差、笛卡尔积  跟集合论中的运算是一个意思，就是把每张数据表视为行的集合，然后做运算。\n选择  是指从数据表中找出符合条件的行（记录）。\n投影  是指从数据表中抽取指定的列（属性）。\n连接  分为两种：\n\nθ连接：从两个关系的笛卡尔积中选取属性满足一定条件的元组\n自然连接（⊳⊲连接）：两个关系中进行比较的分量必须是相同的属性，并且在结果中将重复的属性去掉\n\n2. 函数依赖  函数依赖（Functional Dependency）是数据库理论中的一个重要概念，用于描述属性之间的关系。在关系数据库中，如果属性集 X 的值能够唯一地决定属性集 Y 的值，我们就说Y 函数依赖于 X，记作 X→Y。\n函数依赖的定义：\n给定一个关系 R，如果对于关系 R 中的任意两个元组 t1 和 t2，若 t1 和 t2 在属性集 X 上的值相同，则它们在属性集 Y 上的值也必须相同，那么我们就说 Y 函数依赖于 X。\n函数依赖的类型：\n\n平凡函数依赖：如果属性集 Y 是属性集 X 的一个子集，则称 X 决定 Y 的依赖关系为平凡依赖。例如 X→X\n非平凡函数依赖：属性 Y 不是属性 X 的子集，则称 X 决定 Y 的依赖关系为非平凡依赖。可以进一步分类：\n完全函数依赖：如果在一个复合属性集 X 中，Y 仅依赖于 X 的全部属性，而不依赖于 X 的任何真子集。\n部分函数依赖：如果 Y 依赖于 X 的某个真子集。\n传递函数依赖：如果 X 函数依赖于 Y，而 Y 又函数依赖于 Z，那么可以说 X 传递函数依赖于 Z。\n\n\n\n简单点说：左右包含是平凡，左右互斥非平凡，若无子集是完全，若有子集是部分，环环相连是传递。\n3. Armstrong 公理Armstrong 公理是一组用于推导关系数据库中函数依赖的基本规则，通过这些规则，可以推导出任意一组函数依赖的所有隐含依赖。\n\n自反性：若 X⊇Y，则 X→Y。即一个属性集必然决定其子集。\n增广性：若 X→Y，则 XZ→YZ。即如果 X 决定 Y，那么 X 与 Z 的组合也决定 Y 与 Z 的组合。\n传递性：若 X→Y 且 Y→Z，则 X→Z。即如果 X 决定 Y，且 Y 决定 Z，那么 X 也决定 Z。\n合并性：若 X→Y 且 X→Z，则 X→YZ。即如果 X 决定 Y，且 X 也决定 Z，那么 X 决定 YZ。\n分解性：若 X→Y 且 Y⊇Z，则存在 X→Z。即如果 X 决定 Y，而 Z 是 Y 的子集，那么 X 决定 Z。\n\n4. 关系分解  在数据库关系分解中，有两个重要概念：\n(1) 无损连接\n无损链接指的是将一个关系分解成多个子关系后，通过对这些子关系进行自然连接操作，可以无损地恢复原始关系。换句话说，在连接后得到的结果应该与原始关系完全相同，没有任何信息增加或丢失。\n无损连接分解的  判定方法  为：\n设ρ&#x3D;{R1, R2}是 R 的一个分解，F 是 R 上的函数依赖集。那么分解ρ相对于 F 是无损级联分解的充要条件为 (R1∩R2)→(R1−R2) 或 (R1∩R2)→(R2−R1) 。 注意两个条件只要有任意一个条件成立即可。\n(2) 保持依赖\n保持依赖指的是在关系分解后，仍然能够通过子关系中的函数依赖来推导出原始关系中的所有函数依赖。换句话说，分解后的子关系应该能够保持原始关系中的所有重要的依赖关系。\n举例来说，假设有一个关系 R(A, B, C)，并且它有函数依赖：A→B 和 B→C。\n\n如果将关系 R 分解为 R1(A, B)和 R2(B, C):\n通过属性 B 连接 R1 和 R2，可以恢复 R，因此是无损分解。\n关系 R1 保留了 A→B，关系 R2 保留了 B→C，因此是保持依赖。\n\n\n如果将关系 R 分解为 R1(A, B)和 R3(A, C):\n通过属性 A 连接 R1 和 R3，可以恢复 R，因此是无损分解。\n关系 R1 保留了 A→B，关系 R3 保留了 A→C，但是 B→C 丢失，因此不是保持依赖。\n\n\n\n5. 设计范式  数据库设计范式是指在设计数据库时遵循的一系列规范和原则，以确保数据的组织、存储和管理高效、合理。主要范式包括：\n(1) 第一范式（1NF）每个字段的值都是原子值，不能有重复的列或多值字段。\n不符合 1NF 的表：\n\n\n\n学生 ID\n学生姓名\n课程\n\n\n\n1\n张三\n数学, 物理\n\n\n在这个例子中，”课程”属性是个多值字段。需要重新设计成符合 1NF 的表：\n\n\n\n学生 ID\n学生姓名\n课程\n\n\n\n1\n张三\n数学\n\n\n1\n张三\n物理\n\n\n(2) 第二范式（2NF）在满足 1NF 的基础上，要求消除部分依赖，即每个非主键字段必须完全依赖于主键，而不是主键的一部分。\n不符合 2NF 的表：\n\n\n\n学生 ID\n课程\n学生姓名\n\n\n\n1\n数学\n张三\n\n\n1\n物理\n张三\n\n\n2\n语文\n李四\n\n\n在这个例子中，”学生姓名”只依赖于”学生 ID”，而不依赖于”课程”。我们可以分成两个符合 2NF 的表：\n学生表：\n\n\n\n学生 ID\n学生姓名\n\n\n\n1\n张三\n\n\n2\n李四\n\n\n选课表：\n\n\n\n学生 ID\n课程\n\n\n\n1\n数学\n\n\n1\n物理\n\n\n2\n语文\n\n\n(3) 第三范式（3NF）在满足 2NF 的基础上，要求消除传递依赖，即非主键字段不能依赖于其他非主键字段。\n不符合 3NF 的表：\n\n\n\n学生 ID\n学生姓名\n班级\n班主任\n\n\n\n1\n张三\n一班\n王老师\n\n\n2\n李四\n一班\n王老师\n\n\n在这个例子中，”班主任”依赖于”班级”，而不是”学生 ID”。可以进一步分成两个符合 3NF 的表：\n学生表：\n\n\n\n学生 ID\n学生姓名\n班级\n\n\n\n1\n张三\n一班\n\n\n2\n李四\n一班\n\n\n班级表：\n\n\n\n班级\n班主任\n\n\n\n一班\n王老师\n\n\n(4) 博茨 - 科得范式（BCNF）3NF 的强化版本，要求每个决定因素（函数依赖的左侧）必须是超键，进一步消除所有依赖问题。\n不符合 BCNF 的表：\n\n\n\n学生 ID\n课程\n教师\n\n\n\n1\n数学\n李老师\n\n\n1\n物理\n李老师\n\n\n2\n数学\n张老师\n\n\n在这个例子中，”教师”依赖于”课程”，而”课程”不是超键。可以将其分为两个符合 BCNF 的表：\n课程表：\n\n\n\n课程\n教师\n\n\n\n数学\n李老师\n\n\n物理\n李老师\n\n\n语文\n张老师\n\n\n选课表：\n\n\n\n学生 ID\n课程\n\n\n\n1\n数学\n\n\n1\n物理\n\n\n2\n数学\n\n\n(5) 第四范式（4NF）解决多值依赖的问题，要求每个表只能包含一个多值依赖。\n不符合 4NF 的表：\n\n\n\n学生 ID\n课程\n兴趣\n\n\n\n1\n数学\n足球\n\n\n1\n物理\n篮球\n\n\n在这个例子中，”课程”和”兴趣”之间存在多值依赖。可以将其分为两个符合 4NF 的表：\n选课表：\n\n\n\n学生 ID\n课程\n\n\n\n1\n数学\n\n\n1\n物理\n\n\n兴趣表：\n\n\n\n学生 ID\n兴趣\n\n\n\n1\n足球\n\n\n1\n篮球\n\n\n三、数据库设计  数据库设计主要包含如下阶段：\n\n需求分析阶段：通过结构化分析，得到数据流图和数据字典\n概念设计阶段：根据功能模型，创建局部 ER 图，并合并为全局 ER 图（建立外模式）\n逻辑设计阶段：将 ER 图转换为数据库的关系模型（建立逻辑模式）\n物理设计阶段：根据数据逻辑模式，选择高效的存储结构和存储方法（建立内模式）\n\n\n\n（一）概念设计  在结构化分析阶段，我们通过自顶向下的方式建立的系统的功能模型，以数据流图和数据字典表示。数据库的概念设计阶段，实际上就是建立系统的数据模型。\n数据库的概念设计采用  自底向上  的方式，其任务是建立系统的数据模型（通常以 ER 图表示），主要步骤为：\n\n选择局部应用\n设计局部 ER 图\n合并得到全局 ER 图\n优化全局 ER 图\n\n1. ER 图元素ER 图用于描述系统的各种实体及其之间的关系，主要包含三个基本元素：\n\n实体：系统中的对象或概念，用矩形框表示。\n属性：实体具有的特性，用椭圆形表示。\n联系：用菱形框表示，通过连线与有关的实体相连，在连线上注明对应关系\n1:1 表示一对一关系\n1:n 表示一对多关系\nm:n 表示多对多关系\n\n\n\n\n\n2. ER 图合并  在合并 ER 图时，需要解决局部 ER 图之间的冲突问题，与合并之后全局 ER 图的冗余问题。\n冲突有三种类型：\n\n属性冲突：属性名和属性含义相同，但属性的取值类型或取值范围不同。\n命名冲突 ： 异名同义 （不同属性名表示同一种属性含义），或是 同名异义（同一属性名表示不同的属性含义）。\n结构冲突：\n同一对象在不同 ER 图中具有不同的抽象。例如某个对象在一个 ER 图中是实体，在另一个 ER 图中是属性。\n同一实体在不同 ER 图中所包含的属性个数和属性排列次序不完全相同。\n实体之间的关系在不同 ER 图中呈现为不同的联系。\n\n\n\n冗余有两种类型：\n\n冗余属性：可由基本数据导出的属性\n冗余联系：可由其他联系导出的联系\n\n消除冲突通常是结合业务需求，通过讨论与协商来处理。消除冗余通常是以数据流图和数据字典为依据，通过分析数据项之间的逻辑关系来处理。\n（二）逻辑设计  数据库的逻辑设计是指将 ER 图中的实体、属性、联系转换为数据库的关系模型。","dateCreated":"2024-10-23T09:27:29+08:00","dateModified":"2024-10-28T13:54:23+08:00","datePublished":"2024-10-23T09:27:29+08:00","description":"数据库的概念设计和逻辑设计","headline":"软考架构——数据库设计与建模","image":[],"mainEntityOfPage":{"@type":"WebPage","@id":"https://www.stepbystep.asia/2024/%E8%BD%AF%E8%80%83%E6%9E%B6%E6%9E%84%E2%80%94%E2%80%94%E6%95%B0%E6%8D%AE%E5%BA%93%E8%AE%BE%E8%AE%A1%E4%B8%8E%E5%BB%BA%E6%A8%A1/"},"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/%E8%BD%AF%E8%80%83%E6%9E%B6%E6%9E%84%E2%80%94%E2%80%94%E6%95%B0%E6%8D%AE%E5%BA%93%E8%AE%BE%E8%AE%A1%E4%B8%8E%E5%BB%BA%E6%A8%A1/","keywords":"软件工程, 数据库设计, 数据库范式"}</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一、数据库结构  典型的数据库结构可归纳为“三级模式，两级映射”：\n\n\n\n三级模式：\n\n外模式：是数据库用户能看见和使用的局部数据的逻辑结构，与某一应用有关的数据逻辑表示。对应用户视图，面向数据库用户。\n概念（逻辑）模式：是数据库中全体数据的逻辑结构和特征的描述，所有用户的公共数据视图。对应数据库表，面向数据库管理员。\n内模式：是数据物理结构和存储方式的描述，数据在数据库内部的表示方式。对应物理文件，面向系统程序员。\n\n\n两级映射：保证两类独立性，逻辑独立比物理独立更难实现\n\n外模式 - 模式映射：保证  逻辑独立性，即当逻辑模式发生改变时，应用程序不用修改。\n模式 - 内模式映射：保证  物理独立性，即当内模式发生改变时，应用程序不用修改。\n\n\n\n二、数据库理论  关系型数据库中的  关系  是指由行列组成的二维表文件，每行表示一条记录，每列表示一个属性。关系模型  是关系的逻辑描述，可以表示为：关系名(属性 1, 属性 2, …, 属性 N)。\n1. 关系运算  关系代数的基本运算主要有交、并、差、笛卡尔积、选择、投影、连接和除法运算。\n交、并、差、笛卡尔积  跟集合论中的运算是一个意思，就是把每张数据表视为行的集合，然后做运算。\n选择  是指从数据表中找出符合条件的行（记录）。\n投影  是指从数据表中抽取指定的列（属性）。\n连接  分为两种：\n\nθ连接：从两个关系的笛卡尔积中选取属性满足一定条件的元组\n自然连接（⊳⊲连接）：两个关系中进行比较的分量必须是相同的属性，并且在结果中将重复的属性去掉\n\n2. 函数依赖  函数依赖（Functional Dependency）是数据库理论中的一个重要概念，用于描述属性之间的关系。在关系数据库中，如果属性集 X 的值能够唯一地决定属性集 Y 的值，我们就说Y 函数依赖于 X，记作 X→Y。\n函数依赖的定义：\n给定一个关系 R，如果对于关系 R 中的任意两个元组 t1 和 t2，若 t1 和 t2 在属性集 X 上的值相同，则它们在属性集 Y 上的值也必须相同，那么我们就说 Y 函数依赖于 X。\n函数依赖的类型：\n\n平凡函数依赖：如果属性集 Y 是属性集 X 的一个子集，则称 X 决定 Y 的依赖关系为平凡依赖。例如 X→X\n非平凡函数依赖：属性 Y 不是属性 X 的子集，则称 X 决定 Y 的依赖关系为非平凡依赖。可以进一步分类：\n完全函数依赖：如果在一个复合属性集 X 中，Y 仅依赖于 X 的全部属性，而不依赖于 X 的任何真子集。\n部分函数依赖：如果 Y 依赖于 X 的某个真子集。\n传递函数依赖：如果 X 函数依赖于 Y，而 Y 又函数依赖于 Z，那么可以说 X 传递函数依赖于 Z。\n\n\n\n简单点说：左右包含是平凡，左右互斥非平凡，若无子集是完全，若有子集是部分，环环相连是传递。\n3. Armstrong 公理Armstrong 公理是一组用于推导关系数据库中函数依赖的基本规则，通过这些规则，可以推导出任意一组函数依赖的所有隐含依赖。\n\n自反性：若 X⊇Y，则 X→Y。即一个属性集必然决定其子集。\n增广性：若 X→Y，则 XZ→YZ。即如果 X 决定 Y，那么 X 与 Z 的组合也决定 Y 与 Z 的组合。\n传递性：若 X→Y 且 Y→Z，则 X→Z。即如果 X 决定 Y，且 Y 决定 Z，那么 X 也决定 Z。\n合并性：若 X→Y 且 X→Z，则 X→YZ。即如果 X 决定 Y，且 X 也决定 Z，那么 X 决定 YZ。\n分解性：若 X→Y 且 Y⊇Z，则存在 X→Z。即如果 X 决定 Y，而 Z 是 Y 的子集，那么 X 决定 Z。\n\n4. 关系分解  在数据库关系分解中，有两个重要概念：\n(1) 无损连接\n无损链接指的是将一个关系分解成多个子关系后，通过对这些子关系进行自然连接操作，可以无损地恢复原始关系。换句话说，在连接后得到的结果应该与原始关系完全相同，没有任何信息增加或丢失。\n无损连接分解的  判定方法  为：\n设ρ&#x3D;{R1, R2}是 R 的一个分解，F 是 R 上的函数依赖集。那么分解ρ相对于 F 是无损级联分解的充要条件为 (R1∩R2)→(R1−R2) 或 (R1∩R2)→(R2−R1) 。 注意两个条件只要有任意一个条件成立即可。\n(2) 保持依赖\n保持依赖指的是在关系分解后，仍然能够通过子关系中的函数依赖来推导出原始关系中的所有函数依赖。换句话说，分解后的子关系应该能够保持原始关系中的所有重要的依赖关系。\n举例来说，假设有一个关系 R(A, B, C)，并且它有函数依赖：A→B 和 B→C。\n\n如果将关系 R 分解为 R1(A, B)和 R2(B, C):\n通过属性 B 连接 R1 和 R2，可以恢复 R，因此是无损分解。\n关系 R1 保留了 A→B，关系 R2 保留了 B→C，因此是保持依赖。\n\n\n如果将关系 R 分解为 R1(A, B)和 R3(A, C):\n通过属性 A 连接 R1 和 R3，可以恢复 R，因此是无损分解。\n关系 R1 保留了 A→B，关系 R3 保留了 A→C，但是 B→C 丢失，因此不是保持依赖。\n\n\n\n5. 设计范式  数据库设计范式是指在设计数据库时遵循的一系列规范和原则，以确保数据的组织、存储和管理高效、合理。数据库主要范式包括：\n(1) 第一范式（1NF）每个字段的值都是原子值，不能有重复的列或多值字段。\n不符合 1NF 的表：\n\n\n\n学生 ID\n学生姓名\n课程\n\n\n\n1\n张三\n数学, 物理\n\n\n在这个例子中，”课程”属性是个多值字段。需要重新设计成符合 1NF 的表：\n\n\n\n学生 ID\n学生姓名\n课程\n\n\n\n1\n张三\n数学\n\n\n1\n张三\n物理\n\n\n(2) 第二范式（2NF）在满足 1NF 的基础上，要求消除部分依赖，即每个非主键字段必须完全依赖于主键，而不是主键的一部分。\n不符合 2NF 的表：\n\n\n\n学生 ID\n课程\n学生姓名\n\n\n\n1\n数学\n张三\n\n\n1\n物理\n张三\n\n\n2\n语文\n李四\n\n\n在这个例子中，”学生姓名”只依赖于”学生 ID”，而不依赖于”课程”。我们可以分成两个符合 2NF 的表：\n学生表：\n\n\n\n学生 ID\n学生姓名\n\n\n\n1\n张三\n\n\n2\n李四\n\n\n选课表：\n\n\n\n学生 ID\n课程\n\n\n\n1\n数学\n\n\n1\n物理\n\n\n2\n语文\n\n\n(3) 第三范式（3NF）在满足 2NF 的基础上，要求消除传递依赖，即非主键字段不能依赖于其他非主键字段。\n不符合 3NF 的表：\n\n\n\n学生 ID\n学生姓名\n班级\n班主任\n\n\n\n1\n张三\n一班\n王老师\n\n\n2\n李四\n一班\n王老师\n\n\n在这个例子中，”班主任”依赖于”班级”，而不是”学生 ID”。可以进一步分成两个符合 3NF 的表：\n学生表：\n\n\n\n学生 ID\n学生姓名\n班级\n\n\n\n1\n张三\n一班\n\n\n2\n李四\n一班\n\n\n班级表：\n\n\n\n班级\n班主任\n\n\n\n一班\n王老师\n\n\n(4) 博茨 - 科得范式（BCNF）3NF 的强化版本，要求每个决定因素（函数依赖的左侧）必须是超键，进一步消除所有依赖问题。\n不符合 BCNF 的表：\n\n\n\n学生 ID\n课程\n教师\n\n\n\n1\n数学\n李老师\n\n\n1\n物理\n李老师\n\n\n2\n数学\n张老师\n\n\n在这个例子中，”教师”依赖于”课程”，而”课程”不是超键。可以将其分为两个符合 BCNF 的表：\n课程表：\n\n\n\n课程\n教师\n\n\n\n数学\n李老师\n\n\n物理\n李老师\n\n\n语文\n张老师\n\n\n选课表：\n\n\n\n学生 ID\n课程\n\n\n\n1\n数学\n\n\n1\n物理\n\n\n2\n数学\n\n\n(5) 第四范式（4NF）解决多值依赖的问题，要求每个表只能包含一个多值依赖。\n不符合 4NF 的表：\n\n\n\n学生 ID\n课程\n兴趣\n\n\n\n1\n数学\n足球\n\n\n1\n物理\n篮球\n\n\n在这个例子中，”课程”和”兴趣”之间存在多值依赖。可以将其分为两个符合 4NF 的表：\n选课表：\n\n\n\n学生 ID\n课程\n\n\n\n1\n数学\n\n\n1\n物理\n\n\n兴趣表：\n\n\n\n学生 ID\n兴趣\n\n\n\n1\n足球\n\n\n1\n篮球\n\n\n三、数据库设计  数据库设计主要包含如下阶段：\n\n需求分析阶段：通过结构化分析，得到数据流图和数据字典\n概念设计阶段：根据功能模型，创建局部 ER 图，并合并为全局 ER 图（建立外模式）\n逻辑设计阶段：将 ER 图转换为数据库的关系模型（建立逻辑模式）\n物理设计阶段：根据数据逻辑模式，选择高效的存储结构和存储方法（建立内模式）\n\n\n\n（一）概念设计  在结构化分析阶段，我们通过自顶向下的方式建立的系统的功能模型，以数据流图和数据字典表示。数据库的概念设计阶段，实际上就是建立系统的数据模型。\n数据库的概念设计采用  自底向上  的方式，其任务是建立系统的数据模型（通常以 ER 图表示），主要步骤为：\n\n选择局部应用\n设计局部 ER 图\n合并得到全局 ER 图\n优化全局 ER 图\n\n1. ER 图元素ER 图用于描述系统的各种实体及其之间的关系，主要包含三个基本元素：\n\n实体：系统中的对象或概念，用矩形框表示。\n属性：实体具有的特性，用椭圆形表示。\n联系：用菱形框表示，通过连线与有关的实体相连，在连线上注明对应关系\n1:1 表示一对一关系\n1:n 表示一对多关系\nm:n 表示多对多关系\n\n\n\n\n\n2. ER 图合并  在合并 ER 图时，需要解决局部 ER 图之间的冲突问题，与合并之后全局 ER 图的冗余问题。\n冲突有三种类型：\n\n属性冲突：属性名和属性含义相同，但属性的取值类型或取值范围不同。\n命名冲突 ： 异名同义 （不同属性名表示同一种属性含义），或是 同名异义（同一属性名表示不同的属性含义）。\n结构冲突：\n同一对象在不同 ER 图中具有不同的抽象。例如某个对象在一个 ER 图中是实体，在另一个 ER 图中是属性。\n同一实体在不同 ER 图中所包含的属性个数和属性排列次序不完全相同。\n实体之间的关系在不同 ER 图中呈现为不同的联系。\n\n\n\n冗余有两种类型：\n\n冗余属性：可由基本数据导出的属性\n冗余联系：可由其他联系导出的联系\n\n消除冲突通常是结合业务需求，通过讨论与协商来处理。消除冗余通常是以数据流图和数据字典为依据，通过分析数据项之间的逻辑关系来处理。\n（二）逻辑设计  数据库的逻辑设计是指将 ER 图中的实体、属性、联系转换为 DBMS 数据库的关系模式，并进行范式规约。\n1. ER 图转换ER 图中的实体和属性可以直接转换为数据库中的一个关系模式（一张表），主键为实体，其他字段为属性。\nER 图中的联系，根据不同的类型，有不同的转换方式：\n(1) 1:1 联系\n\n\n转换方式：\n\n转换为一个独立的关系模式：联系两端的实体主键作为属性。ER 图转换结果：\n员工(工号，姓名，性别)\n办公电脑(电脑编号，电脑配置)\n使用(工号，电脑编号)\n\n\n与任意一端实体的关系模式合并：将一个实体的主键作为另一个实体的外键。ER 图转换结果：\n员工(工号，姓名，性别，电脑编号)\n办公电脑(电脑编号，电脑配置)\n\n\n\n(2) 1:n 联系\n\n\n转换方式：\n\n转换为一个独立的关系模式：联系两端的实体主键作为属性。ER 图转换结果：\n班级(编号，年级，人数)\n学生(学号，姓名，性别)\n隶属(学号，编号)\n\n\n与多端的实体的关系模式合并：在多端实体关系模式中，添加一端实体主键作为外键。ER 图转换结果：\n班级(编号，年级，人数)\n学生(学号，姓名，性别，编号)\n\n\n\n(3) m:n 联系\n\n\n转换方式：\n\n转换为一个独立的关系模式：联系两端的实体主键作为属性。ER 图转换结果：\n员工(工号，姓名，性别)\n角色(角色编号，角色名称，角色权限)\n使用(工号，角色编号)\n\n\n\n2. 范式规约","dateCreated":"2024-10-23T09:27:29+08:00","dateModified":"2024-10-28T15:17:57+08:00","datePublished":"2024-10-23T09:27:29+08:00","description":"数据库的概念设计和逻辑设计","headline":"软考架构——数据库设计与建模","image":[],"mainEntityOfPage":{"@type":"WebPage","@id":"https://www.stepbystep.asia/2024/%E8%BD%AF%E8%80%83%E6%9E%B6%E6%9E%84%E2%80%94%E2%80%94%E6%95%B0%E6%8D%AE%E5%BA%93%E8%AE%BE%E8%AE%A1%E4%B8%8E%E5%BB%BA%E6%A8%A1/"},"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/%E8%BD%AF%E8%80%83%E6%9E%B6%E6%9E%84%E2%80%94%E2%80%94%E6%95%B0%E6%8D%AE%E5%BA%93%E8%AE%BE%E8%AE%A1%E4%B8%8E%E5%BB%BA%E6%A8%A1/","keywords":"软件工程, 数据库设计, 数据库范式"}</script>
     <meta name="description" content="数据库的概念设计和逻辑设计">
 <meta property="og:type" content="blog">
 <meta property="og:title" content="软考架构——数据库设计与建模">
@@ -25,8 +25,11 @@
 <meta property="og:image" content="https://www.stepbystep.asia/2024/%E8%BD%AF%E8%80%83%E6%9E%B6%E6%9E%84%E2%80%94%E2%80%94%E6%95%B0%E6%8D%AE%E5%BA%93%E8%AE%BE%E8%AE%A1%E4%B8%8E%E5%BB%BA%E6%A8%A1/%E6%95%B0%E6%8D%AE%E5%BA%93%E7%BB%93%E6%9E%84.jpg">
 <meta property="og:image" content="https://www.stepbystep.asia/2024/%E8%BD%AF%E8%80%83%E6%9E%B6%E6%9E%84%E2%80%94%E2%80%94%E6%95%B0%E6%8D%AE%E5%BA%93%E8%AE%BE%E8%AE%A1%E4%B8%8E%E5%BB%BA%E6%A8%A1/%E6%95%B0%E6%8D%AE%E5%BA%93%E8%AE%BE%E8%AE%A1.jpg">
 <meta property="og:image" content="https://www.stepbystep.asia/2024/%E8%BD%AF%E8%80%83%E6%9E%B6%E6%9E%84%E2%80%94%E2%80%94%E6%95%B0%E6%8D%AE%E5%BA%93%E8%AE%BE%E8%AE%A1%E4%B8%8E%E5%BB%BA%E6%A8%A1/ERD.png">
+<meta property="og:image" content="https://www.stepbystep.asia/2024/%E8%BD%AF%E8%80%83%E6%9E%B6%E6%9E%84%E2%80%94%E2%80%94%E6%95%B0%E6%8D%AE%E5%BA%93%E8%AE%BE%E8%AE%A1%E4%B8%8E%E5%BB%BA%E6%A8%A1/%E4%B8%80%E5%AF%B9%E4%B8%80.png">
+<meta property="og:image" content="https://www.stepbystep.asia/2024/%E8%BD%AF%E8%80%83%E6%9E%B6%E6%9E%84%E2%80%94%E2%80%94%E6%95%B0%E6%8D%AE%E5%BA%93%E8%AE%BE%E8%AE%A1%E4%B8%8E%E5%BB%BA%E6%A8%A1/%E4%B8%80%E5%AF%B9%E5%A4%9A.png">
+<meta property="og:image" content="https://www.stepbystep.asia/2024/%E8%BD%AF%E8%80%83%E6%9E%B6%E6%9E%84%E2%80%94%E2%80%94%E6%95%B0%E6%8D%AE%E5%BA%93%E8%AE%BE%E8%AE%A1%E4%B8%8E%E5%BB%BA%E6%A8%A1/%E5%A4%9A%E5%AF%B9%E5%A4%9A.png">
 <meta property="article:published_time" content="2024-10-23T01:27:29.000Z">
-<meta property="article:modified_time" content="2024-10-28T05:54:23.113Z">
+<meta property="article:modified_time" content="2024-10-28T07:17:57.307Z">
 <meta property="article:author" content="一瓢清浅">
 <meta property="article:tag" content="软件工程">
 <meta property="article:tag" content="数据库设计">
@@ -324,7 +327,7 @@ <h3 id="4- 关系分解"><a href="#4- 关系分解" class="headerlink" title="4.
 </ul>
 </li>
 </ul>
-<h3 id="5- 设计范式"><a href="#5- 设计范式" class="headerlink" title="5. 设计范式"></a>5. 设计范式 </h3><p> 数据库设计范式是指在设计数据库时遵循的一系列规范和原则，以确保数据的组织、存储和管理高效、合理。主要范式包括：</p>
+<h3 id="5- 设计范式"><a href="#5- 设计范式" class="headerlink" title="5. 设计范式"></a>5. 设计范式 </h3><p> 数据库设计范式是指在设计数据库时遵循的一系列规范和原则，以确保数据的组织、存储和管理高效、合理。数据库主要范式包括：</p>
 <h4 id="1- 第一范式（1NF）"><a href="#1- 第一范式（1NF）" class="headerlink" title="(1) 第一范式（1NF）"></a>(1) 第一范式（1NF）</h4><p><strong>每个字段的值都是原子值，不能有重复的列或多值字段。</strong></p>
 <p>不符合 1NF 的表：</p>
 <table>
@@ -657,7 +660,56 @@ <h4 id="2-ER 图合并"><a href="#2-ER 图合并" class="headerlink" title="2. E
 <li><strong>冗余联系</strong>：可由其他联系导出的联系</li>
 </ol>
 <p>消除冲突通常是结合业务需求，通过讨论与协商来处理。<br>消除冗余通常是以数据流图和数据字典为依据，通过分析数据项之间的逻辑关系来处理。</p>
-<h3 id="（二）逻辑设计"><a href="#（二）逻辑设计" class="headerlink" title="（二）逻辑设计"></a>（二）逻辑设计 </h3><p> 数据库的逻辑设计是指将 ER 图中的实体、属性、联系转换为数据库的关系模型。</p>
+<h3 id="（二）逻辑设计"><a href="#（二）逻辑设计" class="headerlink" title="（二）逻辑设计"></a>（二）逻辑设计 </h3><p> 数据库的逻辑设计是指将 ER 图中的实体、属性、联系转换为 DBMS 数据库的关系模式，并进行范式规约。</p>
+<h4 id="1-ER 图转换"><a href="#1-ER 图转换" class="headerlink" title="1. ER 图转换"></a>1. ER 图转换</h4><p>ER 图中的实体和属性可以直接转换为数据库中的一个关系模式（一张表），主键为实体，其他字段为属性。</p>
+<p>ER 图中的联系，根据不同的类型，有不同的转换方式：</p>
+<p>(1) 1:1 联系</p>
+<img src="/2024/%E8%BD%AF%E8%80%83%E6%9E%B6%E6%9E%84%E2%80%94%E2%80%94%E6%95%B0%E6%8D%AE%E5%BA%93%E8%AE%BE%E8%AE%A1%E4%B8%8E%E5%BB%BA%E6%A8%A1/%E4%B8%80%E5%AF%B9%E4%B8%80.png" class title=" 一对一 ">
+
+<p>转换方式：</p>
+<ul>
+<li><strong>转换为一个独立的关系模式</strong>：联系两端的实体主键作为属性。ER 图转换结果：<ul>
+<li>员工(工号，姓名，性别)</li>
+<li>办公电脑(电脑编号，电脑配置)</li>
+<li>使用(工号，电脑编号)</li>
+</ul>
+</li>
+<li><strong>与任意一端实体的关系模式合并</strong>：将一个实体的主键作为另一个实体的外键。ER 图转换结果：<ul>
+<li>员工(工号，姓名，性别，电脑编号)</li>
+<li>办公电脑(电脑编号，电脑配置)</li>
+</ul>
+</li>
+</ul>
+<p>(2) 1:n 联系</p>
+<img src="/2024/%E8%BD%AF%E8%80%83%E6%9E%B6%E6%9E%84%E2%80%94%E2%80%94%E6%95%B0%E6%8D%AE%E5%BA%93%E8%AE%BE%E8%AE%A1%E4%B8%8E%E5%BB%BA%E6%A8%A1/%E4%B8%80%E5%AF%B9%E5%A4%9A.png" class title=" 一对多 ">
+
+<p>转换方式：</p>
+<ul>
+<li><strong>转换为一个独立的关系模式</strong>：联系两端的实体主键作为属性。ER 图转换结果：<ul>
+<li>班级(编号，年级，人数)</li>
+<li>学生(学号，姓名，性别)</li>
+<li>隶属(学号，编号)</li>
+</ul>
+</li>
+<li><strong>与多端的实体的关系模式合并</strong>：在多端实体关系模式中，添加一端实体主键作为外键。ER 图转换结果：<ul>
+<li>班级(编号，年级，人数)</li>
+<li>学生(学号，姓名，性别，编号)</li>
+</ul>
+</li>
+</ul>
+<p>(3) m:n 联系</p>
+<img src="/2024/%E8%BD%AF%E8%80%83%E6%9E%B6%E6%9E%84%E2%80%94%E2%80%94%E6%95%B0%E6%8D%AE%E5%BA%93%E8%AE%BE%E8%AE%A1%E4%B8%8E%E5%BB%BA%E6%A8%A1/%E5%A4%9A%E5%AF%B9%E5%A4%9A.png" class title=" 多对多 ">
+
+<p>转换方式：</p>
+<ul>
+<li><strong>转换为一个独立的关系模式</strong>：联系两端的实体主键作为属性。ER 图转换结果：<ul>
+<li>员工(工号，姓名，性别)</li>
+<li>角色(角色编号，角色名称，角色权限)</li>
+<li>使用(工号，角色编号)</li>
+</ul>
+</li>
+</ul>
+<h4 id="2- 范式规约"><a href="#2- 范式规约" class="headerlink" title="2. 范式规约"></a>2. 范式规约</h4>
             
 
 
diff --git "a/2024/\350\275\257\350\200\203\346\236\266\346\236\204\342\200\224\342\200\224\346\225\260\346\215\256\345\272\223\350\256\276\350\256\241\344\270\216\345\273\272\346\250\241/\344\270\200\345\257\271\344\270\200.png" "b/2024/\350\275\257\350\200\203\346\236\266\346\236\204\342\200\224\342\200\224\346\225\260\346\215\256\345\272\223\350\256\276\350\256\241\344\270\216\345\273\272\346\250\241/\344\270\200\345\257\271\344\270\200.png"
new file mode 100644
index 0000000..60b8d3b
Binary files /dev/null and "b/2024/\350\275\257\350\200\203\346\236\266\346\236\204\342\200\224\342\200\224\346\225\260\346\215\256\345\272\223\350\256\276\350\256\241\344\270\216\345\273\272\346\250\241/\344\270\200\345\257\271\344\270\200.png" differ
diff --git "a/2024/\350\275\257\350\200\203\346\236\266\346\236\204\342\200\224\342\200\224\346\225\260\346\215\256\345\272\223\350\256\276\350\256\241\344\270\216\345\273\272\346\250\241/\344\270\200\345\257\271\345\244\232.png" "b/2024/\350\275\257\350\200\203\346\236\266\346\236\204\342\200\224\342\200\224\346\225\260\346\215\256\345\272\223\350\256\276\350\256\241\344\270\216\345\273\272\346\250\241/\344\270\200\345\257\271\345\244\232.png"
new file mode 100644
index 0000000..5acef2b
Binary files /dev/null and "b/2024/\350\275\257\350\200\203\346\236\266\346\236\204\342\200\224\342\200\224\346\225\260\346\215\256\345\272\223\350\256\276\350\256\241\344\270\216\345\273\272\346\250\241/\344\270\200\345\257\271\345\244\232.png" differ
diff --git "a/2024/\350\275\257\350\200\203\346\236\266\346\236\204\342\200\224\342\200\224\346\225\260\346\215\256\345\272\223\350\256\276\350\256\241\344\270\216\345\273\272\346\250\241/\345\244\232\345\257\271\345\244\232.png" "b/2024/\350\275\257\350\200\203\346\236\266\346\236\204\342\200\224\342\200\224\346\225\260\346\215\256\345\272\223\350\256\276\350\256\241\344\270\216\345\273\272\346\250\241/\345\244\232\345\257\271\345\244\232.png"
new file mode 100644
index 0000000..c568af1
Binary files /dev/null and "b/2024/\350\275\257\350\200\203\346\236\266\346\236\204\342\200\224\342\200\224\346\225\260\346\215\256\345\272\223\350\256\276\350\256\241\344\270\216\345\273\272\346\250\241/\345\244\232\345\257\271\345\244\232.png" differ
diff --git a/sitemap.xml b/sitemap.xml
index 51e9865..d219aa6 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -354,49 +354,49 @@
   </url>
   
   <url>
-    <loc>https://www.stepbystep.asia/tags/Linux/</loc>
+    <loc>https://www.stepbystep.asia/tags/Docker/</loc>
     <lastmod>2024-10-28</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>
+    <loc>https://www.stepbystep.asia/tags/%E5%AE%B9%E5%99%A8/</loc>
     <lastmod>2024-10-28</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
-    <loc>https://www.stepbystep.asia/tags/%E5%91%BD%E4%BB%A4/</loc>
+    <loc>https://www.stepbystep.asia/tags/LibFuzzer/</loc>
     <lastmod>2024-10-28</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
-    <loc>https://www.stepbystep.asia/tags/Docker/</loc>
+    <loc>https://www.stepbystep.asia/tags/Python/</loc>
     <lastmod>2024-10-28</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
-    <loc>https://www.stepbystep.asia/tags/%E5%AE%B9%E5%99%A8/</loc>
+    <loc>https://www.stepbystep.asia/tags/Linux/</loc>
     <lastmod>2024-10-28</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
-    <loc>https://www.stepbystep.asia/tags/Python/</loc>
+    <loc>https://www.stepbystep.asia/tags/%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F/</loc>
     <lastmod>2024-10-28</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
-    <loc>https://www.stepbystep.asia/tags/LibFuzzer/</loc>
+    <loc>https://www.stepbystep.asia/tags/%E5%91%BD%E4%BB%A4/</loc>
     <lastmod>2024-10-28</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
@@ -510,42 +510,42 @@
   </url>
   
   <url>
-    <loc>https://www.stepbystep.asia/categories/%E7%BC%96%E7%A8%8B%E8%AF%AD%E8%A8%80/C/</loc>
+    <loc>https://www.stepbystep.asia/categories/web/</loc>
     <lastmod>2024-10-28</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
-    <loc>https://www.stepbystep.asia/categories/web/</loc>
+    <loc>https://www.stepbystep.asia/categories/%E5%BC%80%E5%8F%91/</loc>
     <lastmod>2024-10-28</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
-    <loc>https://www.stepbystep.asia/categories/%E5%BC%80%E5%8F%91/</loc>
+    <loc>https://www.stepbystep.asia/categories/%E7%BC%96%E7%A8%8B%E8%AF%AD%E8%A8%80/C/</loc>
     <lastmod>2024-10-28</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>
+    <loc>https://www.stepbystep.asia/categories/%E5%BC%80%E5%8F%91/Docker/</loc>
     <lastmod>2024-10-28</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
-    <loc>https://www.stepbystep.asia/categories/%E5%BC%80%E5%8F%91/Linux/</loc>
+    <loc>https://www.stepbystep.asia/categories/%E7%BC%96%E7%A8%8B%E8%AF%AD%E8%A8%80/Python/</loc>
     <lastmod>2024-10-28</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
   </url>
   
   <url>
-    <loc>https://www.stepbystep.asia/categories/%E5%BC%80%E5%8F%91/Docker/</loc>
+    <loc>https://www.stepbystep.asia/categories/%E5%BC%80%E5%8F%91/Linux/</loc>
     <lastmod>2024-10-28</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.2</priority>
diff --git a/tags/AFL/index.html b/tags/AFL/index.html
index a03d275..10a2d69 100644
--- a/tags/AFL/index.html
+++ b/tags/AFL/index.html
@@ -7,7 +7,7 @@
     <meta charset="UTF-8">
     <meta name="viewport" content="width=device-width, initial-scale=1">
     <meta name="generator" content="千里之行，始于足下">
-    <title>标签: AFL++ - 千里之行，始于足下</title>
+    <title>标签: AFL - 千里之行，始于足下</title>
     <meta name="author" content="一瓢清浅">
     
         <meta name="keywords" content="python,AI,安全,算法,编程,">
@@ -220,15 +220,15 @@ <h5 class="sidebar-profile-bio"><p>个人技术博客<br>涉猎开发、测试
             <div class="postShorten-header">
                 <h1 class="postShorten-title">
                     
-                        <a class="link-unstyled" href="/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/" aria-label=": AFL++ 源码分析——覆盖率">
-                            AFL++ 源码分析——覆盖率
+                        <a class="link-unstyled" href="/2023/LibAFL%E7%AE%80%E4%BB%8B/" aria-label=": LibAFL 简介">
+                            LibAFL 简介
                         </a>
                     
                 </h1>
                 <div class="postShorten-meta">
-    <time datetime="2024-08-15T17:28:52+08:00">
+    <time datetime="2023-11-18T10:38:08+08:00">
 	
-		    2024 年 8 月 15 日
+		    2023 年 11 月 18 日
     	
     </time>
     
@@ -243,9 +243,9 @@ <h1 class="postShorten-title">
             </div>
             
                 <div class="postShorten-excerpt">
-                    <p>分析 AFL++ 度量覆盖率的相关代码</p>
+                    <p>LibAFL 是用 Rust 开发的一款模糊测试库，支持 Fuzz 各模块的灵活定制 </p>
                     
-                        <a href="/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/" class="postShorten-excerpt_link link" aria-label=": AFL++ 源码分析——覆盖率">
+                        <a href="/2023/LibAFL%E7%AE%80%E4%BB%8B/" class="postShorten-excerpt_link link" aria-label=": LibAFL 简介">
                             阅读全文
                         </a>
                         
@@ -263,58 +263,15 @@ <h1 class="postShorten-title">
             <div class="postShorten-header">
                 <h1 class="postShorten-title">
                     
-                        <a class="link-unstyled" href="/2024/%E7%94%B1subprocess-PIPE%E5%BC%95%E5%8F%91%E7%9A%84%E8%A1%80%E6%A1%88/" aria-label=": 由 subprocess.PIPE 引发的血案">
-                            由 subprocess.PIPE 引发的血案
+                        <a class="link-unstyled" href="/2023/AFL%E5%8E%9F%E7%90%86%E4%B8%8E%E5%AE%9E%E8%B7%B5/" aria-label=": AFL 原理与实践">
+                            AFL 原理与实践
                         </a>
                     
                 </h1>
                 <div class="postShorten-meta">
-    <time datetime="2024-07-30T16:19:00+08:00">
+    <time datetime="2023-10-15T11:23:55+08:00">
 	
-		    2024 年 7 月 30 日
-    	
-    </time>
-    
-        <span>发布在 </span>
-        
-    <a class="category-link" href="/categories/%E7%BC%96%E7%A8%8B%E8%AF%AD%E8%A8%80/">编程语言</a>, <a class="category-link" href="/categories/%E7%BC%96%E7%A8%8B%E8%AF%AD%E8%A8%80/Python/">Python</a>
-
-
-    
-</div>
-
-            </div>
-            
-                <div class="postShorten-excerpt">
-                    <p>找了大半个月 AFL++ 不同步的原因，到头来都是 subprocess 的锅</p>
-                    
-                        <a href="/2024/%E7%94%B1subprocess-PIPE%E5%BC%95%E5%8F%91%E7%9A%84%E8%A1%80%E6%A1%88/" class="postShorten-excerpt_link link" aria-label=": 由 subprocess.PIPE 引发的血案">
-                            阅读全文
-                        </a>
-                        
-                    
-                </div>
-            
-        </div>
-        
-    </article>
-    
-    
-    <article class="postShorten postShorten--thumbnailimg-right">
-        <div class="postShorten-wrap">
-            
-            <div class="postShorten-header">
-                <h1 class="postShorten-title">
-                    
-                        <a class="link-unstyled" href="/2024/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/" aria-label=": AFLplusplus 源码分析——同步机制">
-                            AFLplusplus 源码分析——同步机制
-                        </a>
-                    
-                </h1>
-                <div class="postShorten-meta">
-    <time datetime="2024-07-16T09:02:06+08:00">
-	
-		    2024 年 7 月 16 日
+		    2023 年 10 月 15 日
     	
     </time>
     
@@ -329,9 +286,9 @@ <h1 class="postShorten-title">
             </div>
             
                 <div class="postShorten-excerpt">
-                    <p>分析 AFL++ 同步机制的相关源码</p>
+                    <p>模糊测试工具 AFL（American Fuzzy Lop）的原理介绍与实践应用</p>
                     
-                        <a href="/2024/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/" class="postShorten-excerpt_link link" aria-label=": AFLplusplus 源码分析——同步机制">
+                        <a href="/2023/AFL%E5%8E%9F%E7%90%86%E4%B8%8E%E5%AE%9E%E8%B7%B5/" class="postShorten-excerpt_link link" aria-label=": AFL 原理与实践">
                             阅读全文
                         </a>