企业官网建设流程全解析

前阵子一个朋友给我看了段解析数据的代码，说自己写了七八个单元测试，边界值也都照顾到了，可每次改动还是心慌。我说你别在用例上死磕了，把它丢给LibFuzzer跑一晚上试试。第二天早上他发来消息：凌晨三点崩了，一个很隐蔽的数组越界被揪了出来。这就是我写这篇入门文的由来——Fuzzing（模糊测试）听起来很专业，实际门槛没有想象中高，尤其在LibFuzzer这种工具的帮助下，新手完全可以在一个下午跑通全流程，甚至复现出“自动找Bug”的效果。

这篇文章我会用大白话讲清楚Fuzzing的核心原理，从零开始带你在虚拟机里搭好实验环境（标题承诺的虚拟机教程绝不敷衍），装好编译链，写出第一个fuzz target，再故意埋一个Bug，把“发现崩溃、定位根因、修复验证”整条链路走一遍。最后还会聊聊语料库、字典、并行控制这些能直接提升效率的进阶手法。全文不依赖图形界面点来点去，但尽量照顾到纯小白，所有命令都有逐行解释——你只要跟着敲，基本都能跑通。

1. 为什么入门Fuzzing，我首推LibFuzzer

1.1 Fuzzing到底在做什么：用海量“刁钻输入”逼程序现形

我们平时写测试用例，本质上是在替程序“提问”：这个输入合理吗？那个输入越界了吗？但人的想象力有限，尤其面对复杂的格式解析、网络协议、文件读取这类代码，边界情况多到根本枚举不完。Fuzzing的思路恰恰相反——它不靠人想，而是靠程序自动生成海量输入，喂给目标函数，观察程序会不会崩溃、断言失败、内存越界或者超时。

LibFuzzer的战略可以用一句话概括：不按套路出牌，用机器最擅长的方式去试错。它会随机生成大量输入，也会在已有输入上做变异，比如翻转几个字节、插入一段数据、拼接已知的“危险片段”。这些看起来毫无逻辑的输入，恰恰是手工测试最容易漏掉的“暗角”。

有个很贴切的类比：普通测试像导游带游客走固定路线，Fuzzing则像放一群精力旺盛的野马在草原上乱跑，它们踩到陷阱的概率自然高得多。尤其在解析类代码里，一个字节的错位就可能让后续逻辑彻底失控，这种问题靠眼睛很难看出来，但机器一晚上能试几百万次。

1.2 主流Fuzzing引擎的三条技术路线

圈子里流行的Fuzzing引擎不止一个，常见的还有AFL（及其后继AFL++）和Honggfuzz。它们的目标一致，但实现思路差别很大。

简单解释一下“进程内”和“进程外”的区别。AFL++会在外部反复启动你编译好的程序，每次崩溃都会另起一个进程，隔离性很好，但进程启动开销很大。LibFuzzer则直接把fuzz逻辑和被测代码链接进同一个进程，在内存里反复调用目标函数，吞吐量高一个量级，代价是如果被测代码本身有严重问题，可能把整个进程带垮——所以官方一直建议配合ASAN（AddressSanitizer）一起用，这正好也是新手最好的安全网。

1.3 对新手最友好的几个设计

我推荐LibFuzzer作为入门首选，不是因为AFL++不好，而是因为它把你从一堆琐事里解放了出来：

• 不用管输入通道。AFL++需要程序从stdin或者文件读取输入，你得先为被测代码写一层“文件转内部逻辑”的胶水代码；LibFuzzer直接提供一个入口函数给你，输入以内存指针的方式传进来，少了很多弯路。
• 集成度极高。只要Clang版本足够新，-fsanitize=fuzzer这一个编译参数就能激活全部核心功能，不需要单独安装任何工具。
• 与ASAN天然联动。内存越界、释放后使用、空指针这类Bug，在LibFuzzer环境下几乎都会被ASAN准确拦下来，并输出带堆栈回溯的崩溃现场，定位效率非常高。

我的建议很直接：如果你将来想深入理解覆盖率引导、变异策略这些底层机制，LibFuzzer的源码和LLVM是一体的，学习路径非常顺；如果你需要测试一个已经有完整可执行文件的外部程序，再去研究AFL++也不迟。

2. 虚拟机实验环境搭建：从镜像选择到共享剪贴板全流程

2.1 为什么非要先装虚拟机，而不是直接在宿主机上跑

有读者可能会问：我就想试试Fuzzing，在本地装个Clang直接编译不就行了？行，但我不推荐。

第一，Fuzzing过程中被测代码随时可能崩溃。虽然ASAN能拦截大部分内存错误，但被测试的代码如果出现死锁、极端内存膨胀，甚至直接触发内核级的问题，在虚拟机里发生只影响虚拟环境，重启一个快照就能恢复；在宿主机上则可能把你正在编辑的资料全部带走。

第二，环境是脏的。很多开发机里装了旧版GCC、多种Python版本、各种环境变量，和Clang的插桩工具链混在一起容易出幺蛾子。虚拟机能给你一个干净、可重复的实验环境，将来哪一步搞坏了，删除重来就行。

第三，方便快照回归。我在调试崩溃样本时，经常需要对比“修改前”和“修改后”的行为。虚拟机支持多份快照，一个快照放Bug版本，另一个放修复版本，切换起来非常方便。

对真要拿Fuzzing干活的团队来说，CI上跑Fuzzing也通常使用隔离的容器或虚拟机，现在先在本地把这套思维养起来，后面迁移到自动化流程会平滑很多。

2.2 虚拟机软件选型与关键参数设置

虚拟机软件我推荐VirtualBox，原因是开源免费、跨平台、资料多。如果你公司有VMware的商业授权，VMware也没有问题，操作思路基本一样。

创建虚拟机的时候，有几个参数直接决定后面的体验：

• 操作系统类型：Linux / Ubuntu (64-bit)。
• 内存：建议至少分配4GB，最好8GB。LibFuzzer跑起来后，ASAN需要额外内存开销，默认上限约2GB，如果机器内存太小容易直接被杀。
• CPU：分配2到4个核。后面如果想体验-jobs=4并行Fuzzing，至少要给4个核。
• 磁盘：建议固定或动态分配40GB以上。Ubuntu系统本身占用不大，但Fuzzing会产生大量语料库和崩溃样本，空间充裕一点心里不慌。

系统镜像我建议直接用Ubuntu LTS版本，比如Ubuntu 22.04的桌面版。有人喜欢Server版省资源，但新手在纯命令行里处理网络、挂载、权限问题会多一重心理负担，桌面版能极大降低挫败感。真机跑Fuzzing一般用Server版，但那是后话，入门阶段没必要和自己过不去。

2.3 Ubuntu安装与增强功能配置：少走几个冤枉路

虚拟机创建好后，挂载下载好的Ubuntu ISO镜像，启动进入安装流程。语言、键盘、时区这些按默认走即可，注意在“安装类型”里选择“清除整个磁盘”并安装——这里的“磁盘”是虚拟磁盘，不会影响宿主机。

Ubuntu安装完成后，第一件事是更新软件源并安装基础工具。打开终端执行：

sudo apt update sudo apt upgrade -y sudo apt install -y build-essential git curl

这里提前把build-essential装好，因为后面编译代码和编译VirtualBox增强功能都要用到。

接下来装VirtualBox增强功能（Guest Additions），它主要解决两个问题：让鼠标可以不按特殊键自由进出虚拟机窗口；让虚拟机分辨率跟随窗口自动调整。在虚拟机窗口菜单里点击“设备” -> “安装增强功能”，Ubuntu会挂载一张光盘镜像，然后执行：

sudo mount /dev/cdrom /mnt cd /mnt sudo ./VBoxLinuxAdditions.run --nox11 sudo reboot

我实测中最常见的失败原因是没有提前安装linux-headers-$(uname -r)，增强功能的编译依赖它。如果上述命令报错，先执行sudo apt install linux-headers-$(uname -r) dkms再重试。

增强功能装好后，建议再配置共享文件夹，方便宿主机和虚拟机传代码。在VirtualBox的“设置 -> 共享文件夹”里添加一个目录，比如把宿主机上的~/fuzzshare共享为fuzzshare，在Ubuntu里挂载：

mkdir -p ~/share sudo mount -t vboxsf fuzzshare ~/share

这样你可以在宿主机上下载工具包、写代码，在虚拟机里直接读取，省去来回复制。

2.4 快照规划与性能提醒

虚拟机装好后，趁环境还干净，建议立刻打一个快照。拿VirtualBox来说，在“快照”面板里给当前状态起个名字就行，比如install-done。

**快照是廉价保险，别舍不得打。**后面每完成一个阶段（装好Clang、跑通第一个target、复现崩溃等），都可以补一个快照。万一后续操作把环境搞乱了，几秒钟回到可用状态。

性能上有一个大家容易忽略的点：给虚拟机分配的内存不要超过宿主机物理内存的一半，不然宿主机会开始用交换空间，整机变慢后虚拟机反而跑得更差。LibFuzzer是计算密集型任务，如果发现虚拟机风扇狂转、编译明显变慢，先检查是不是内存分多了，再检查是不是后台同时跑着太多编译任务。

3. 工具链安装与第一个fuzz target：编译命令逐行拆解

3.1 安装Clang：版本对了，问题就少一半

LibFuzzer是LLVM项目的一部分，直接集成在Clang编译器里，所以核心依赖只有Clang一个。Ubuntu 22.04默认软件源的clang版本是14，这个版本对LibFuzzer的日常使用完全够用。

安装命令：

sudo apt install -y clang clang --version

看到类似clang version 14.0.0的输出即安装成功。如果你的发行版较老，apt默认给的是clang 6.0甚至更旧，那LibFuzzer可能没有被集成，需要手动安装新版本，比如clang-14，然后用clang-14命令替代clang。这一点后面避坑章节还会展开说。

顺便把llvm-symbolizer装上，它对ASAN崩溃堆栈的符号化很有帮助：

sudo apt install -y llvm

3.2 一个标准fuzz target长什么样

LibFuzzer要求你提供一个入口函数，名字固定叫LLVMFuzzerTestOneInput，接收const uint8_t *data和size_t size两个参数，输入数据就是Fuzzer不断变异出来的字节流。

下面我用一个简化的“按逗号切分字段”的解析函数做演示，它接收一段字节流，统计逗号数量。代码很简单，但骨架能直接用到真实项目里：

#include <stdint.h> #include <stddef.h> // 被测函数：统计输入数据里逗号的数量 static int CountCommas(const uint8_t *data, size_t size) { int count = 0; for (size_t i = 0; i < size; i++) { if (data[i] == ',') { count++; } } return count; } // LibFuzzer统一入口 int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) { CountCommas(data, size); return 0; }

注意几个要点：

• 入口文件不要写main函数。-fsanitize=fuzzer编译时LibFuzzer会自动生成main，你写了反而报重复定义。
• 被测函数里不要用printf刷屏。Fuzzer每秒调用成千上万次，任何打印都会拖垮速度，还会污染日志。
• 不要依赖全局状态做逻辑判断。同一个进程会被反复调用，全局变量会在多次调用间残留，容易引入“每次都不同”的假Bug，后面避坑章节我会用专门篇幅讲。

3.3 编译命令逐项解释

把上面的代码保存为fuzz_csv.c，然后执行：

clang -fsanitize=fuzzer,address -g -O1 fuzz_csv.c -o fuzz_csv

这一条命令信息量很大，拆开看：

• -fsanitize=fuzzer：这是核心，Clang会自动链接LibFuzzer runtime，并生成一个main函数，这个main负责初始化、循环生成输入、调用LLVMFuzzerTestOneInput、处理崩溃转储。
• -fsanitize=address：开启ASAN。一旦被测代码发生堆越界、栈越界、释放后使用、空指针解引用等问题，ASAN会立即拦截并打印详尽的错误报告。它和fuzzer可以共存，实际项目里几乎必开。
• -g：生成调试信息。没有它，崩溃堆栈里只有函数地址，符号化和定位会麻烦很多。
• -O1：优化级别。官方文档明确建议用-O1或-O2，优化级别太低会导致很多问题模式发生变化，太高则可能让某些错误被编译器优化掉，-O1是覆盖率反馈和错误保真度之间的平衡点。

编译完成后，当前目录会出现一个名为fuzz_csv的可执行文件。

3.4 第一次运行：看懂启动日志

运行它：

./fuzz_csv

你会看到类似这样的输出：

INFO: Running with entropic power schedule (default) INFO: Seed: 3347809551 INFO: Loaded 1 modules INFO: Loaded 0 corpora files

• Seed：本次运行的随机种子。每次运行都会不同，也可以手动指定-seed=12345复现某次运行过程。
• Loaded 0 corpora files：表示还没有提供初始语料库，LibFuzzer会从零开始纯随机生成输入。

随后日志会持续滚动：

#2 NEW cov: 12 ft: 18 corp: 1/1b exec/s: 1200 rss: 28MB #4 NEW cov: 14 ft: 25 corp: 2/3b exec/s: 1500 rss: 29MB

这里cov表示当前代码覆盖率，ft是边数，corp是语料库大小，exec/s是每秒执行次数。这个CountCommas函数足够简单，覆盖很快会饱和。正常情况下让它跑几分钟都不会崩溃，因为代码里没有会导致内存错误的问题——但这就是我们想要的基线行为。

提示：如果你看到ERROR: AddressSanitizer failed to allocate ...类似报错，说明虚拟机的内存或ASAN的内存映射受限，后面避坑章节会专门讲。

4. 故意埋一个Bug，把崩溃定位与修复流程完整走一遍

4.1 制造一个必现的数组越界场景

为了让读者真正看到“发现崩溃”到“修复验证”的全过程，我们现在故意往代码里埋一个经典Bug：用输入数据的第一个字节作为数组索引，并且不做边界检查。这是很多C/C++越界问题的真实写照——开发者想当然地以为输入值一定在某个范围内。

#include <stdint.h> #include <stddef.h> static int ParseByte(const uint8_t *data, size_t size) { if (size < 4) return -1; int table[8] = {0}; // 故意不检查 data[0] 的范围 int idx = data[0]; table[idx] = 1; return size; } int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) { ParseByte(data, size); return 0; }

保存为fuzz_demo.c，编译：

clang -fsanitize=fuzzer,address -g -O1 fuzz_demo.c -o fuzz_demo

运行./fuzz_demo，Fuzzer很快会生成一个data[0]大于等于8的输入。因为uint8_t的取值范围是0到255，越界概率接近97%，用不了多久就会崩。

4.2 崩溃输出的每个字段意味着什么

当我实际跑这个例子时，几秒钟之内就看到类似下面的输出：

==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffd... at pc ... READ of size 4 at 0x7ffd... thread T0 #0 0x... in ParseByte fuzz_demo.c:11:9 #1 0x... in LLVMFuzzerTestOneInput fuzz_demo.c:16 #2 0x... in LLVMFuzzerOutput... ... Test unit written to ./crash-2fd6... Base64: AQAAAAAAAAA=

逐段解读：

• AddressSanitizer: stack-buffer-overflow：ASAN判定这是栈缓冲区越界。如果是堆越界会显示heap-buffer-overflow，释放后访问则显示use-after-free，这个描述基本能让你第一时间知道内存错误类型。
• READ of size 4：程序试图读取4个字节（因为table[idx] = 1读的是int），而目标地址超出了栈缓冲区范围。ASAN精确到读写大小，对判断越界跨度很有帮助。
• #0 ... in ParseByte fuzz_demo.c:11:9：堆栈第一帧直接指向代码文件fuzz_demo.c的第11行第9列。这就是-g调试信息带来的好处，没有它你只能看到一个裸地址。
• Test unit written to ./crash-2fd6...：LibFuzzer把触发崩溃的最小输入样本保存到了当前目录，文件名以crash-开头。这个文件是宝贝，后面复现和回归都靠它。

有一点要强调：崩溃样本的内容只有8个字节（Base64解码后是AQAAAAAAAAA=，也就是第一个字节为1、后面7个字节为0），它短到让人觉得“就这也能崩？”。但这就是Fuzzing的价值——它能用极小的输入精确命中你代码里的弱点。

4.3 手动复现：不看日志也能让程序崩给你看

拿到崩溃样本后，我们可以脱离Fuzzer，直接用可执行文件喂入这个文件来复现：

./fuzz_demo crash-2fd6*

注意，LibFuzzer编译出的程序有一个特殊行为：如果运行时传入文件路径作为参数，它不会进入Fuzzing循环，而是直接把文件内容交给LLVMFuzzerTestOneInput。这相当于一个“单测模式”，对复现和回归非常有用。

执行后你会看到同样的ASAN报错。到这一步，问题已经可以稳定复现，说明崩溃根因不依赖于Fuzzer的随机性，是真实存在的bug。

4.4 修复与回归验证

修复越界很简单，加一个范围检查：

static int ParseByte(const uint8_t *data, size_t size) { if (size < 4) return -1; int table[8] = {0}; int idx = data[0]; if (idx < 0 || idx >= (int)(sizeof(table) / sizeof(table[0]))) { return -1; } table[idx] = 1; return size; }

重新编译并直接传入原来的崩溃样本验证：

clang -fsanitize=fuzzer,address -g -O1 fuzz_demo.c -o fuzz_demo_fixed ./fuzz_demo_fixed crash-2fd6*

此时程序应正常返回，无任何ASAN输出。

再把它拿回Fuzzer里运行，确认不再产生崩溃：

mkdir corpus cp crash-2fd6* corpus/ ./fuzz_demo_fixed corpus/

把崩溃样本放进语料库是一个极其重要的习惯。一方面验证修复是否真的覆盖了该样本，另一方面让Fuzzer在这些“历史上崩溃过的输入”基础上继续变异，防止同类问题换个马甲卷土重来。

5. 让Fuzzing真正高效的三个进阶动作：种子、字典与并行控制

5.1 语料库种子：决定覆盖率起点的第一块拼图

我们前面跑的例子都是“零种子”启动，LibFuzzer只能从头随机生成输入，就像让一个从没见过逗号的机器猜“这是什么”。真实项目里，你手里往往已经有正常流量、合法样本、历史Bug输入，这些都应该做成种子目录，让Fuzzer站在一个更高的起点上。

在项目目录建一个corpus/，把你认为“正常且能走到较深逻辑”的输入放进去。对于CSV解析器，可以放几行正常CSV、带引号的字段、换行符乱飞的边缘样本。LibFuzzer会先读取所有种子，然后从中变异出新样本。

有个经验值：种子文件不要太大，几百字节到几十KB都合适。种子动辄几MB会拖慢变异效率，LibFuzzer还提供了压缩命令：

./fuzz_csv -merge=1 corpus corpus_min

-merge=1会把corpus里所有能增加覆盖率的样本合并进corpus_min，那些冗余的重复样本会被自动剔除。定期做一次语料库最小化，是保持Fuzzer长期高效运行的好习惯。

5.2 字典文件：让变异不再“盲人摸象”

纯随机变异生成的输入，大部分是垃圾字符。对文本格式、协议关键字这类场景，直接告诉Fuzzer“你应该多尝试这些token”能大大提升效率。LibFuzzer的字典文件格式很简单，就是一系列"token"字符串：

"," "\"" "\r" "\n" "0x" "true" "false" "NULL"

保存为csv.dict，运行时用-dict=csv.dict指定：

./fuzz_csv -dict=csv.dict corpus/

字典的价值在于把变异方向从“逐字节瞎改”变成“结构相关词条的组合”。比如HTTP头解析器，字典里可以放Content-Type、Content-Length、Transfer-Encoding这些token；JSON解析器可以放{、}、[]、":这些结构符号。用不用字典，对格式类代码的覆盖率差距可能是成倍的。

5.3 并行与资源控制：跑得久也要跑得稳

Fuzzing默认是单进程，但现代CPU多核不用白不用。LibFuzzer支持-jobs和-workers参数配合工作，比如：

./fuzz_csv -jobs=4 -workers=4 corpus/

这样会并行启动4个Fuzzing worker，各自独立变异，主进程负责任务调度。实测在4核虚拟机上，吞吐量大约能翻三到四倍。不过并行模式对内存的要求也更高，4个ASAN进程同时跑，内存占用轻松超过8GB，虚拟机的内存分配要提前规划好。

资源控制参数，我几乎每次都会带上：

./fuzz_csv -timeout=25 -rss_limit_mb=2048 -max_len=4096 corpus/

• -timeout=25：单个输入执行超过25秒就视为超时，直接终止该输入并记录。
• -rss_limit_mb=2048：进程内存超过2GB就重启，防止内存无限膨胀拖垮系统。
• -max_len=4096：限制单个输入的最大长度，避免Fuzzer生成几十MB的巨型样本，导致解析耗时激增。

这些参数表面是“限制”，实际是“保护环”——它们保证Fuzzer长时间运行时，即使被测代码出现极端资源消耗，也不会让整个虚拟机卡死。

另外一个实用小参数是-print_final_stats=1，运行结束后会输出完整的统计信息，包括覆盖率、语料库大小、崩溃和超时的数量。跑完一阶段后看一眼这个数据，比盯着滚动日志更能判断“这次Fuzz值不值”。

6. 实际动手之后才发现的几个坑与我的最终建议

6.1 工具链相关的三个经典版本坑

第一个坑是最容易被忽略的编译器版本过低。我见过有朋友在旧系统上执行apt install clang，装的是4.9或者6.0的老版本。那个年代的Clang对LibFuzzer的支持要么相当别扭、要么根本编译不出可执行文件。建议装新一点的系统，或者显式安装clang-14。判断标准很简单：clang --version如果低于7，就不要纠结，升级系统或者用官方源安装新版。

第二个坑是遗漏-g导致堆栈不可读。没有调试信息时，ASAN的堆栈全是地址加偏移量，你需要额外跑addr2line才能定位到源码行，非常影响效率。我在实际排查时习惯把-g -O1当作铁律，不写全不要开始Fuzz。

第三个坑是ASAN内存映射问题。在一些比较老的内核或容器环境里，ASAN初始化会报failed to allocate。解决办法是给虚拟机的内存映射放宽限制，或者在编译命令中尝试-fsanitize-address-use-odr-indicator等兼容参数。这个坑最头疼的地方在于它和环境强相关，搜到同样的报错也不一定同一个解法，所以我的建议是：先把Ubuntu 22.04这种主流版本环境跑通，再去折腾其他发行版。

6.2 fuzz target写法相关：三条我踩过的红线

第一，入口函数里不要用stdin读输入。LibFuzzer的输入通道直接走内存指针，你写了从标准输入读数据的逻辑，Fuzzer根本不会喂给那个通道，反而会卡在读入步骤造成“看起来像死循环”的假象。需要读文件类外部程序的逻辑时，提前做一层适配，把文件内容读到内存再传给LLVMFuzzerTestOneInput。

第二，小心全局状态污染。被测代码如果依赖static变量或者全局缓存，第一次调用可能一切正常，第二次、第三次就会因为状态残留走出和在单测里完全不同的路径。某些时候它甚至能掩盖Bug——第一次调用没事，后面调用才开始崩，你很难判断根因。推荐的姿势是：被测函数尽量无状态，真有不可避免的全局状态，也要在每次调用开始处重置。

第三，不要写复杂的main函数来包装。LibFuzzer自动生成的main已经处理好参数解析、语料加载、崩溃保存这些逻辑，你只要一心写好LLVMFuzzerTestOneInput即可。我见过有人为了“定制启动流程”手写main，结果把LibFuzzer内部机制绕得乱七八糟，反而要花几个小时调试。

6.3 工作流建议：不是所有代码都值得砸时间Fuzz

最后说点个人体会。Fuzzing不是万能药，它最适合处理的是“输入直接决定控制流”的代码，比如文件格式解析、网络报文解析、压缩解压、正则引擎、序列化反序列化。而业务逻辑复杂、大量外部依赖、需要复杂前置状态的代码，让Fuzzer从头猜状态非常费劲——那种场景更适合配合结构化语料和自定义mutator去玩，那是进阶话题。

如果你想把LibFuzzer接到真实项目里，我的建议是先挑一个足够小的解析模块下手，比如项目内某个JSON配置解析器或一个自定义协议的decode函数，写好target跑一个晚上，看清覆盖率曲线，再决定要不要扩大范围。拿我自己的经验来说，第一次看到“崩了一个我自己完全没想到的输入”时，那种感觉和看别人演示Demo完全不同——这不是环境配置成功了，而是这套方法论真正开始替你工作了。

另外提醒一句：任何Fuzzing产出都应纳入回归体系。把崩溃样本放进项目的测试用例库里，让每次CI都能自动重放这些历史崩溃输入，这才是Fuzzing价值能持续保持的原因。我在实际项目中就是这么做的：一次Fuzz跑出的10个样本，比一部分手写的单元测试更“值钱”，因为它们每个都代表了一条曾经真实击穿代码边界的路径。

最后一个真诚的建议：入门阶段，千万别追求“跑得久”，先追求“看得懂”。把一次只跑30秒的小Fuzz跑通，把崩溃样本手动复现一次，把ASAN日志从头读到尾，这比挂着Fuzzer跑一整晚但完全不知道日志在说什么有用得多。等你真的看懂了那些日志，LibFuzzer就不再是个黑盒子了——那时候你已经可以把它当工具使，而不是当魔术看。