上次我们写博客时，我们有一个简单的模糊测试器，它会测试一个故意有漏洞的程序，该程序会对文件进行一些检查，如果输入文件通过了检查，它会继续进行下一个检查，如果输入通过了所有检查，程序就会发生段错误。我们发现了代码覆盖的重要性，以及它如何帮助将模糊测试过程中指数级罕见的事件减少为线性罕见的事件。让我们直接进入如何改进我们的简单模糊测试器！

特别感谢@gamozolabs的所有内容，让我对这个话题产生了兴趣。

首先，我们的简单模糊测试器非常慢。如果你还记得，我们的简单模糊测试器平均每秒大约进行1,500次模糊测试。在我的测试中，AFL在QEMU模式下（模拟没有可用的源代码进行编译插桩）每秒大约进行1,000次模糊测试。这是有道理的，因为AFL做的事情远比我们的简单模糊测试器多，尤其是在QEMU模式下，我们在模拟CPU并提供代码覆盖。

我们的目标二进制文件（-> 这里 <-）会执行以下操作：

从磁盘上的文件中提取字节到缓冲区
对缓冲区执行3次检查，查看检查的索引是否与硬编码值匹配
如果通过所有检查则发生段错误，如果有一个检查失败则退出
我们的简单模糊测试器会执行以下操作：

从磁盘上的有效jpeg文件中提取字节到字节缓冲区
通过随机字节覆盖变异缓冲区中2%的字节
将变异后的文件写入磁盘
通过在每次模糊测试迭代中执行fork()和execvp()将变异后的文件传递给目标二进制文件
如你所见，这涉及大量的文件系统交互和系统调用。让我们在我们的漏洞二进制文件上使用strace，看看二进制文件发出了哪些系统调用（为了便于测试，在这篇文章中，我已经将.jpeg文件硬编码到漏洞二进制文件中，这样我们就不必使用命令行参数）：

你可以看到，在目标二进制文件的处理过程中，我们在打开输入文件之前运行了大量代码。查看strace的输出，我们甚至在打开输入文件之前已经运行了以下系统调用：

在所有这些系统调用之后，我们终于从磁盘打开文件并读取字节，以下是strace输出中的一行：

所以请记住，我们的简单模糊测试器在每次模糊测试迭代中都会运行这些系统调用。我们的简单模糊测试器（-> 这里 <-）每次迭代都会将一个文件写入磁盘，并通过fork()和execvp()生成目标程序的一个实例。漏洞二进制文件每次迭代都会运行所有的启动系统调用，最终从磁盘读取文件。因此，每次模糊测试迭代都会有几十个系统调用和两次文件系统交互。难怪我们的简单模糊测试器如此之慢。

我开始思考如何在模糊测试这样一个简单的目标二进制文件时节省时间，并认为如果我能找到一种方法在程序从磁盘读取文件并将内容存储在堆中之后拍摄其内存快照，我可以保存该进程状态，并手动插入一个新的模糊测试用例替换目标读取的字节，然后让程序运行直到它到达exit()调用。一旦目标到达exit调用，我会将程序状态倒回到拍摄快照时的状态，并插入一个新的模糊测试用例，然后再重复这一过程。

你可以看到这将如何提高性能。我们将跳过所有目标二进制文件的启动开销，并完全绕过所有文件系统交互。一个巨大的区别是我们只会调用一次fork()，这是一个昂贵的系统调用。假设进行100,000次模糊测试迭代，我们将从200,000次文件系统交互（一次是简单模糊测试器在磁盘上创建一个变异的.jpeg文件，一次是目标读取变异的.jpeg文件）和100,000次fork()调用减少到0次文件系统交互和仅一次初始fork()。

总而言之，我们的模糊测试过程应如下所示：

我们只需要执行步骤1-5一次，所以这个过程不需要非常快。步骤6-9是模糊测试器将花费99%时间的地方，所以我们需要这个过程非常快。

使用Ptrace编写一个简单的调试器
为了实现我们的快照机制，我们需要使用非常直观但显然缓慢且有约束的ptrace()接口。当我几周前开始编写模糊测试器的调试器部分时，我主要参考了Eli Bendersky的这篇博客文章，这是一个很好的ptrace()入门教程，展示了如何创建一个简单的调试器。

我们代码中的调试器部分实际上不需要太多功能，它只需要能够插入和删除断点。使用ptrace()设置和删除断点的方法是覆盖地址处的单字节指令，使用int3操作码\xCC。然而，如果你在设置断点时直接覆盖该值，将无法删除断点，因为你不知道那里原本持有的值是什么，因此你不知道用什么来覆盖\xCC。

要开始使用ptrace()，我们使用fork()生成第二个进程。

现在我们需要让子进程自愿被父进程“跟踪”。这是通过使用PTRACE_TRACEME参数完成的，我们将在execute_debugee函数中使用它：

函数的其余部分不涉及ptrace，但我会继续在这里展示，因为有一个重要的函数可以强制在被调试进程中禁用ASLR（地址空间布局随机化）。这是至关重要的，因为我们将利用静态地址的断点，这些地址不能在不同进程间变化。我们通过调用带有ADDR_NO_RANDOMIZE的personality()来禁用ASLR。另外，我们会将stdout和stderr重定向到/dev/null，这样我们就不会因为目标二进制文件的输出弄乱我们的终端。

所以首先，我们需要一种方法在插入断点之前抓取地址处的单字节值。对于模糊测试器，我开发了一个头文件和源文件，称为ptrace_helpers，以帮助简化使用ptrace()的开发过程。为了抓取该值，我们将抓取地址处的64位值，但只关心最右边的字节。（我使用类型long long unsigned，因为在<sys/user.h>中寄存器值是这样定义的，我希望保持一致）。

所以这个函数将使用PTRACE_PEEKTEXT参数读取子进程（child_pid）中位于地址处的值，这是我们的目标。现在我们有了这个值，可以将其保存并插入我们的断点，代码如下：

你可以看到，这个函数将使用之前函数收集的原始值，并执行两个按位操作来保持前7个字节不变，但将最后一个字节替换为\xCC。注意，我们现在使用的是PTRACE_POKETEXT。ptrace()接口的一个令人沮丧的特点是我们一次只能读取和写入8个字节！

既然我们可以设置断点，最后需要实现的函数是删除断点，这涉及用原始字节值覆盖int3。

同样，使用PTRACE_POKETEXT，我们可以用原始字节值覆盖\xCC。现在我们有能力设置和删除断点了。

最后，我们需要一种方法来恢复被调试进程的执行。这可以通过在ptrace()中使用PTRACE_CONT参数来实现，如下所示：

需要注意的重要一点是，如果我们在地址0x0000000000000000处遇到断点，rip实际上会在0x0000000000000001处。因此，在恢复被覆盖的指令为其先前的值之后，我们还需要在恢复执行之前从rip中减去1，我们将在下一节中学习如何通过ptrace来做到这一点。

现在让我们学习如何利用ptrace和/proc伪文件来创建目标的快照！

ptrace()的另一个很酷的功能是能够捕获和设置被调试进程中的寄存器状态。我们可以分别使用我放在ptrace_helpers.c中的辅助函数来完成这两件事：

结构体user_regs_struct在<sys/user.h>中定义。你可以看到我们分别使用PTRACE_GETREGS和PTRACE_SETREGS来检索寄存器数据和设置寄存器数据。因此，通过这两个函数，我们将能够在‘开始’断点处创建快照寄存器值的struct user_regs_struct，并在到达‘结束’断点时恢复寄存器状态（最重要的是rip）到快照时的状态。

现在我们有了一种捕获寄存器状态的方法，我们还需要一种捕获快照的可写内存状态的方法。我通过与/proc伪文件交互来实现这一点。我使用GDB在vuln中执行检查的第一个函数上断点，重要的是这个函数是在vuln从磁盘读取jpeg之后，将作为我们的‘开始’断点。一旦我们在GDB中在这里断点，我们可以cat /proc/$pid/maps文件来查看进程中的内存映射（请记住，GDB也使用我们调试器中相同的方法强制关闭ASLR）。我们可以在这里看到通过grep筛选出的可写段的输出（即，在我们的模糊测试运行期间可能被覆盖的段）：

所以这是七个不同的内存段。你会注意到堆是其中一个段。重要的是要意识到我们的模糊测试用例将插入到堆中，但存储模糊测试用例的堆地址在我们的模糊测试器中与在GDB中是不一样的。我认为这可能是由于两个调试器之间某种环境变量的差异。如果我们在GDB中查看，当我们在vuln中断在check_one()时，我们看到rax是指向我们输入的开头的指针，在这个例子中是Canon_40D.jpg。

这个指针0x00005555557588b0位于堆中。所以我所要做的就是在我们的调试器/模糊测试器中找到这个指针的位置，只需在相同的位置断点并使用ptrace()检索rax值。

我会在check_one处断点，然后打开/proc/$pid/maps以获取程序中包含可写内存段的偏移量，然后我会打开/proc/$_pid_/_maps_以获取程序中包含可写内存段的偏移量，然后我会打开/_proc_/$pid/mem并从这些偏移量读取到缓冲区以存储可写内存。这段代码存储在一个名为snapshot.c的源文件中，其中包含一些定义和函数，用于捕获快照和恢复快照。对于这一部分，捕获可写内存，我使用了以下定义和函数：

你可以看到我硬编码了所有的偏移量和段的长度。请记住，这不需要很快。我们只需要捕获一次快照，所以与文件系统交互是可以的。因此，我们将遍历这7个偏移量和长度，并将它们全部写入一个名为snapshot_buf的缓冲区中，该缓冲区将存储在我们模糊测试器的堆中。所以现在我们有了进程在开始check_one（我们的‘开始’断点）时的寄存器状态和内存状态。

现在让我们弄清楚如何在到达‘结束’断点时恢复快照。

为了恢复进程的内存状态，我们可以像读取时一样写入/proc/$pid/mem；然而，这部分需要很快，因为我们现在在每次模糊测试迭代中都要这样做。每次模糊测试迭代都与文件系统交互会大大降低我们的速度。幸运的是，自从Linux内核版本3.2以来，支持一种更快的进程间内存读写API，叫做process_vm_writev()。由于这个过程直接与另一个进程交互，不会遍历内核且不涉及文件系统，它将大大提高我们的写入速度。

乍一看有点令人困惑，但man手册中的示例实际上是理解其工作原理所需的全部内容，我选择硬编码所有偏移量，因为这个模糊测试器只是一个POC。我们可以如下恢复可写内存：

对于7个不同的可写段，我们将从包含原始快照数据的snapshot_buf中，在/proc/$pid/maps中定义的偏移量处写入调试进程。这样会非常快！

现在我们已经有能力恢复可写内存了，我们只需要恢复寄存器状态，就可以完成我们的基本快照机制。这很容易，通过使用我们在ptrace_helpers中定义的函数，你可以在模糊测试循环中看到以下两个函数调用：

所以这就是我们的快照过程是如何工作的，在我的测试中，我们比愚蠢的模糊测试器快了大约20-30倍！

此时，我们仍然有一个愚蠢的模糊测试器（尽管现在快了很多）。我们需要能够跟踪代码覆盖率。一个非常简单的方法是在check_one和exit之间的每个“基本块”处放置一个断点，这样如果我们到达新代码，就会触发一个断点，我们可以在那时执行某些操作。

这正是我所做的，只是为了简单起见，我只在check_two和check_three的入口点放置了“动态”（代码覆盖）断点。当触发“动态”断点时，我们将到达该代码的输入保存到一个名为“corpus”的字符指针数组中，现在我们可以开始变异这些保存的输入，而不仅仅是我们原型输入的Canon_40D.jpg。

因此，我们的代码覆盖反馈机制将如下工作：

正如你可能还记得的，代码覆盖对于我们能够使这个测试二进制漏洞崩溃至关重要，因为它执行了3个字节比较，所有这些都必须通过才能崩溃。我们在上次帖子中数学地确定了通过第一个检查的机会大约是1/13,000，通过前两个检查的机会大约是1/170,000,000。因为我们保存了通过check_one的输入并进一步变异它，我们可以将通过check_two的概率降低到接近1/13,000的数字。这也适用于然后通过check_two的输入，因此我们可以轻松地到达并通过check_three。

我们模糊测试器的第一阶段，收集快照数据并设置代码覆盖的“动态断点”，即使它不打算快，也能非常快地完成。这是因为所有的值都是硬编码的，因为我们的目标非常简单。在一个复杂的多线程目标中，我们需要某种方式通过Ghidra或objdump等脚本发现动态断点地址，并且我们需要让该脚本为我们的模糊测试器写一个配置文件，但那是很远的事情。目前，对于一个POC，这样做是可以的。

你可以看到，模糊测试器会有帮助地显示“开始”和“结束”断点，并列出“动态断点”，这样我们可以在模糊测试之前检查它们是否正确。模糊测试器会暂停并等待我们按任意键开始模糊测试。我们还可以看到，快照数据收集已经成功完成，所以现在我们在“开始”处中断，并且拥有了开始模糊测试所需的所有数据。

一旦我们按下回车键，就会得到一个统计输出，显示模糊测试的进展情况：

正如你所看到的，它几乎瞬间找到了两个“动态断点”，并且当前每秒CPU时间运行大约41k次模糊测试迭代（比我们的愚蠢模糊测试器快了大约20-30倍）。

最重要的是，你可以看到我们在仅仅300k次迭代中已经能够使二进制程序崩溃5次！我们以前的模糊测试器是绝对做不到这一点的。

对我来说，从这次实践中最大的收获之一是，只要针对目标自定义模糊测试器，就能大幅提升性能。使用像AFL这样的现成框架非常棒，这些工具都非常令人印象深刻，我希望这个模糊测试器有一天能成长为一个可与之媲美的工具。对于这个非常简单的目标，我们能够比AFL快20-30倍，并且通过一点点逆向工程和自定义几乎瞬间使其崩溃。我认为这非常有趣且具有教育意义。未来，当我将这个模糊测试器适配到一个真实目标时，我应该能够再次超越这些框架。

从哪里开始呢？我们有很多可以改进的地方，但一些可以立即进行的改进包括：

通过重构代码、改变全局变量的位置来优化性能
通过可以通过Python脚本创建的配置文件启用模糊测试器的动态配置
实现更多的变异方法
实现更多的代码覆盖机制
开发模糊测试器，使其能够并行运行多个实例并共享发现的输入/覆盖数据
也许我们会在后续的帖子中看到这些改进，以及使用相同的一般方法对真实目标进行模糊测试的结果。直到那时！

所有与本博文相关的代码都可以在这里找到：https://github.com/h0mbre/Fuzzing/tree/master/Caveman4

本文使用chatGPT-4o翻译，如有错误之处，请斧正
原文链接：https://h0mbre.github.io/Fuzzing-Like-A-Caveman-4/

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！