前阵子在给团队做代码评审的时候发现一个很有意思的现象不少同事对单元测试的热情很高覆盖率的数字也做得很好看但一提到 Fuzz Testing眼神就开始飘忽。聊下去才发现很多人对它的认知还停留在“拿随机数乱砸程序”的阶段觉得这东西有点暴力、有点玄学跟“优雅”的 C 开发不太搭。但实际情况恰恰相反对于网络协议栈、序列化反序列化、消息解析这类代码Fuzz Testing 几乎是唯一能系统化挖出隐藏漏洞的手段C 内核开发场景里尤其明显——缓冲区越界、空指针解引用、整数溢出、逻辑错乱这些东西靠人肉 Review 和手写测试用例效率实在太低了。这篇文章我不打算讲那些教科书里才有的理论就把我过去在协议解析、网络报文处理这类 C 代码上做 Fuzz 的实际经验拆开来说。从为什么需要它到工具选型、harness 编写、覆盖率引导、崩溃分析再到那些文档里不会写的坑都过一遍。不管你是刚接触 Fuzz 的新手还是已经在 Intel 里跑过几轮的老手应该都能找到点能直接拿去用的东西。1. Fuzz Testing 到底在解决什么问题先抛个问题你手上有段纯 C 写的消息解析函数输入是网络上传来的字节流内部要做长度校验、字节序转换、指针平移、内存拷贝。团队测试用例也写了边界值也测了覆盖率 85%看起来稳得不行——但线上某个模块还是偶尔出现段错误压测一上来就崩。这时候你再回去翻测试用例就会发现那些用例几乎都是“符合协议规范”的正常包真正能触发崩溃的畸形包一个都没有。1.1 单元测试留下的死角单元测试的本质是“人猜测哪里会出问题然后写用例验证”。但协议解析类的代码输入空间大得离谱。一个最简单的 TLVType-Length-Value格式长度字段是 uint16光这一个字段的合法取值范围就有 65536 种更别提嵌套结构、可选字段、多版本兼容这种情况。你不可能靠人肉穷举把每一条路径都走到。Fuzz Testing 的思路刚好反过来了我不猜哪里会出问题我只负责生成大量输入然后把代码扔进去跑崩溃了就是证据。它不依赖人的想象力而是依赖“覆盖率反馈”和“随机/变异”的组合在几百万次执行里把隐藏在犄角旮旯的 bug 翻出来。打个比方单元测试像你自己下厨每道菜按照菜谱一步步做心里有数Fuzz 像是把你家冰箱里所有能吃的都倒进破壁机转到哪一步出现怪味那一锅就是线索。1.2 覆盖率的真相行覆盖不等于路径覆盖很多人拿到覆盖率报告就安心了但这里有个容易忽略的事实行覆盖是“这段代码被执行过”不是“这段代码的所有分支都被验证过”。一个if (len MAX)分支只要 len 小于 MAX 就被判定为已覆盖但真正危险的是 len 恰好等于 MAX-1、MAX、MAX1、或者因为整数溢出变成了一个巨大值。这些情况普通测试用例很难覆盖到。Fuzz 工具通过编译插桩获取边覆盖率edge coverage记录的是“从 A 点跳到 B 点”这条路径有没有走过。配合覆盖率引导工具会优先保留那些能探索到新路径的输入然后基于这些输入继续变异逐步深入到代码深处。这就是**覆盖率引导 FuzzCoverage-guided Fuzzing**的基本原理也是它能高效发现漏洞的核心。2. 工具选型LibFuzzer、AFL 和 Honggfuzz 怎么选市面上做 Fuzz 的工具不少但在 C 内核开发这个场景里主流就三款LibFuzzer、AFL、Honggfuzz。我这些年基本都摸过简单说说它们各自的特点和适用场景。2.1 三款主流工具横向对比先放个对比表然后逐个展开说。维度LibFuzzerAFLHonggfuzz集成方式直接链接到被测程序进程内执行通常作为外部进程启动被测目标既支持进程内也支持进程外覆盖率反馈编译器插桩必须是 Clang编译器插桩或 QEMU 模式编译器插桩或硬件性能计数器易用程度简单写一个函数即可需要准备输入文件和命令行参数中等多核并行原生支持-jobs支持-M/-S主从模式支持多线程/多进程典型场景库代码、协议解析函数需要跑完整程序的场景硬要测库、也要测完整程序坑点进程内崩溃即进程死需要配合 fork 或子进程模式对复杂输入格式要做好字典和语法配置项多上手略繁琐2.2 我的默认选择LibFuzzer 配 Clang如果让我给一个新项目推荐起步方案我会说LibFuzzer。原因很简单它跟 Clang 绑定写起来最快LLVMFuzzerTestOneInput一个函数就是整个入口不需要构造命令行参数、不需要准备输入文件编译完直接扔给 Fuzzer 跑。对于协议解析、序列化反序列化这类“输入一段内存、输出一个结果”的库函数LibFuzzer 几乎是量身定做。它最大的特点是在进程内执行也就是说每次执行测试输入不需要重新拉起进程吞吐量非常高。但这也带来一个问题一旦被测代码崩溃整个进程就没了。好在 LibFuzzer 支持-forkN和-jobsN可以拉起多个子进程并行跑。我实际使用时一般会让单核吞吐量保持在每秒几千到几万次执行配合多核心并行效果相当可观。2.3 AFL 和 Honggfuzz 的适用场景AFL 更适合被测对象是一个完整可执行程序的场景。比如你有一个守护进程接受文件或 stdin 输入那 AFL 的 fork server 模式就很合适。它的优势是稳定性好、生态成熟、文档多但缺点也比较明显进程间切换成本高吞吐量比 LibFuzzer 低对复杂输入格式如果没有字典变异效率会很差。Honggfuzz 我用的相对少但它在某些场景很能打支持硬件性能计数器做覆盖率反馈不用改代码也能用适合那些编译选项受限的老项目。另外它的多线程模型在某些并发 bug 的挖掘上确实有优势。不过说实话多数情况下 LibFuzzer 就够了没必要为了“工具更多”而上复杂度。3. 编译防护Sanitizer 是 Fuzz 的好搭档Fuzz 跑得再猛如果崩溃信息看不懂等于白干。所以在开始 Fuzz 之前我强烈建议先把 Sanitizer 开起来。这套编译时插桩工具能帮你把“内存错误、未定义行为、数据竞争”这些最容易在协议代码里出现的问题提前暴露出来。3.1 几个常用 Sanitizer 的分工AddressSanitizerASan检测堆越界、栈越界、全局变量越界、释放后使用use-after-free、双重释放等。这是 Fuzz 的标配几乎每个协议解析类的 bug 都能被它抓出来。UndefinedBehaviorSanitizerUBSan检测整数溢出、移位越界、空指针解引用、除零、对齐错误、类型混淆等。C 里很多协议解析bug就是从“看起来无害”的整数溢出开始的。ThreadSanitizerTSan检测数据竞争适合在多线程并发场景下使用。但注意它和 ASan 不能同时开启而且性能开销大一般单独跑。MemorySanitizerMSan检测未初始化内存的读取这个在解析从网络上接收的数据时偶尔会碰到但使用范围较窄性能开销也不小。我在实际项目里最常用的组合是 ASanUBSan。这两个一起开既能抓内存问题又能抓未定义行为性价比非常高。TSan 我一般只在多线程模块中单独做一轮因为它会让执行速度慢到让人抓狂。3.2 编译参数怎么配才合理这里给一个我常用的 CMake 配置参考set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -fsanitizeaddress,undefined -fno-omit-frame-pointer -g -O1) set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -fno-sanitize-recoverall)几个关键点说明一下-fsanitizeaddress,undefined是开 ASan 和 UBSan。-fno-omit-frame-pointer保留栈帧指针崩溃栈回溯才完整。-g加调试信息配合 ASan 的 symbolizer 才能看到具体函数名和行号。-O1是经过权衡的选择-O0跑得太慢-O2偶尔会因为优化产生误报-O1在检测精度和性能之间比较均衡。-fno-sanitize-recoverall是关键中的关键。默认情况下 ASan 遇到某些错误可能只报错不停止这会导致 Fuzz 吞掉真正的崩溃。强制任何错误都直接终止进程让 Fuzzer 把它当成一次 crash 记录下来。注意Sanitizer 需要链接到对应的运行时库。如果项目用了编译缓存或分布式编译要确保链接阶段也能带上-fsanitize标志否则会出现链接错误或者插桩代码没生效的诡异问题。4. 核心实操手把手把一个协议解析函数喂给 Fuzzer理论说完了进入正题。这一步我会用一个简化但真实的例子来讲假设我们有一个网络协议帧的解析函数它从一段原始字节流中提取头部信息包括消息类型、长度、负载数据。这个函数在 C 内核开发里太典型了。4.1 一个存在问题的示例函数先写一个常见风格的消息解析实现我故意留下一两个 bug// 伪代码结构实际项目中长这样 struct MsgHeader { uint16_t type; uint16_t length; uint32_t reserved; }; bool ParseMessage(const uint8_t* data, size_t size) { if (size sizeof(MsgHeader)) { return false; } MsgHeader header; memcpy(header, data, sizeof(header)); // 注意没有做字节序转换直接按主机序解释 uint16_t payload_len header.length; if (payload_len kMaxPayload) { // 超过了最大负载长度但不一定返回 false return false; } const uint8_t* payload data sizeof(MsgHeader); if (size - sizeof(MsgHeader) payload_len) { return false; } // 这里有一个潜在问题如果 size 小于 sizeof(MsgHeader)payload_len // 但前面的判断只检查了 size - sizeof(MsgHeader) payload_len // 实际还是要小心 data sizeof(MsgHeader) payload_len 越界访问 // 真实代码里可能还会有其他逻辑比如把 payload 里的字段拷贝到本地变量 return true; }这段代码表面上看是做了长度校验的但熟悉 C 的人应该能嗅到几个风险点字节序问题、size_t与uint16_t比较时的隐式类型提升、以及data sizeof(MsgHeader) payload_len的潜在越界。我不在文章里直接指出具体是哪一行触发崩溃留给你用 Fuzz 自己跑出来这样记忆更深刻。4.2 编写 Fuzz HarnessFuzz Harness 就是把被测函数包一层薄薄的入口让 Fuzzer 能调用它。LibFuzzer 的写法非常固定#include cstddef #include cstdint #include message_parser.h extern C int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size) { // 对输入数据做一层适配因为协议帧通常以固定魔数开头 // 如果测试 API 需要以 null 结尾的字符串要在这里拷贝到 vector std::vectoruint8_t input(data, data size); // 建议把 ParseMessage 的调用放在局部函数中避免编译器把整个调用优化掉 ParseMessage(input.data(), input.size()); return 0; }这里有三个容易踩的坑不要返回值代表错误LLVMFuzzerTestOneInput的返回值必须是 0否则 LibFuzzer 会认为该输入导致“错误终止”影响判断。注意输入 data 不一定是合法指针开头有些内部解析函数可能会对传入指针做对齐访问若担心对齐问题可以先拷贝到std::vectoruint8_t里再取data()或者使用std::aligned_storage保证对齐。避免在 harness 里做过多无关操作比如写日志、初始化全局变量这会让吞吐量下降也会干扰 Fuzzer 对路径的反馈。4.3 种子语料库Corpus的准备很多人拿到工具第一步就开跑结果 Fuzzer 在完全随机的字节流里疯狂撞墙半天找不到一条有意义的路径。种子语料库就是解决这个问题的关键。原则很简单给 Fuzzer 一组“合法”的输入当起点。对于协议解析代码我的习惯是去抓一两百个真实流量包把每个包存成独立文件作为种子。手动构造那些“边界合法”的样本length 字段刚好等于负载长度、刚好小于负载长度、等于 0、等于0xFFFF、等于kMaxPayload等。不需要多几十个到一两百个就够重点是多样性而不是数量。这些种子文件会被 Fuzzer 变异基于它们生成大量新的输入。没有种子的 Fuzz 是盲人摸象有种子的 Fuzz 才是积极探索。4.4 编译并启动 Fuzz假设被测代码在src/message_parser.cppharness 在tests/fuzz/message_fuzzer.cpp用 Clang 编译clang -stdc17 -O1 -g -fsanitizeaddress,undefined \ -fno-omit-frame-pointer -fno-sanitize-recoverall \ -fsanitizefuzzer \ src/message_parser.cpp tests/fuzz/message_fuzzer.cpp \ -o message_fuzzer编译完成后直接运行./message_fuzzer -max_len4096 -rss_limit_mb4096 \ -timeout10 -max_total_time600 \ corpus/几个参数解释一下-max_len4096限制输入最大长度很多协议帧不会超过这个值太大反而降低变异效率。-rss_limit_mb4096内存限制防止单次执行泄漏涨爆。-timeout10单条输入超过 10 秒直接判定为超时并终止。-max_total_time600跑 10 分钟自动停止适合先看效果。corpus/种子目录也是 Fuzzer 保存新发现输入的地方。跑起来之后注意看这行关键信息#... DONE cov: 12944 ft: 1824132 corp: 521/1.2MB lim: 4096 execs: 0/s其中cov是当前覆盖到的边数ft是 feature 总数corp是语料库大小。cov的增长速度是最直观的指标——如果跑了几分钟cov纹丝不动说明 Fuzzer 卡在某个状态进不去深层路径需要调种子或字典。4.5 内核态 vs 用户态的取舍标题里提到了“C 内核开发”这里多说一句。很多真正的内核协议代码没法直接在用户态用 LibFuzzer 跑因为它依赖内核 API、内核锁、内存分配器。常见的做法有两种把协议解析核心抽出来做成独立的纯函数不依赖内核基础设施然后在用户态编译 Fuzz。这也是一种设计上的解耦顺便提升了代码可测试性。用 Linux 内核自带的 Fuzz 基础设施比如针对网络栈可以使用syzkaller但那是另外一套系统门槛高很多而且主要面向系统调用层面。多数情况下我会先争取第一种方案。把一个协议解析函数从内核代码里剥离出来定义好输入输出接口不仅方便 Fuzz也让代码的职责边界更清晰。5. 协议状态机与复杂输入的 Fuzz 难题如果只是解析单个消息帧Fuzz 相对简单。但现实中的协议往往是会话式的先握手、再认证、再数据交换每一步对输入结构都有不同要求。直接用纯随机变异去跑这种代码Fuzzer 会卡在最开始的手握阶段根本摸不到深层逻辑。5.1 把状态机拆开分阶段 Fuzz我的做法是把一个完整的协议状态机拆成几个独立阶段然后对每个阶段单独写一个 harness。比如一个从连接建立到数据交换的协议可以拆成握手解析器输入是该阶段的握手帧。认证解析器假设握手已完成直接喂认证帧。数据消息解析器假设已进入数据交换状态喂数据帧。每个 harness 内部可以直接把被测对象“预置”到对应状态。这样做的好处是 Fuzzer 不会在无关状态间瞎撞能集中火力在自己负责的解析逻辑上。5.2 结构感知变异让 Fuzzer 学会“按语法生成”纯字节级随机变异对复杂格式效率很低因为协议里的魔数、长度字段、校验和字段只要有一个字节不对解析就会提前失败根本到不了深层。这时候要做的是结构感知变异。LibFuzzer 对这个场景有很好的支持可以自定义LLVMFuzzerCustomMutator函数自己控制怎么变。也可以借助开源方案比如libprotobuf-mutator先用 Protobuf 定义协议的“结构化描述”然后让 Fuzzer 在合法的结构空间里做变异再把结构化数据序列化成字节流喂给被测代码。这个思路听起来复杂但收益极大。我做过一次对比对一个带 CRC 校验的通信协议纯字节变异大概要跑几小时才能碰到合法的 CRC 组合结构感知变异号称“每次生成都是合法帧”几分钟就把深层路径全翻了出来。5.3 字典告诉 Fuzzer 哪些字节是“魔数”字典这个功能经常被忽略但它极其好用。协议解析代码里大量充斥着魔数、命令字、状态码比如0xAA55、0x0102、HELO之类的。Fuzzer 随机变异很难自己撞出这些值于是我们可以提前告诉它。LibFuzzer 的字典文件格式很简单每行一个 token\xAA\x55 \x01\x02 HELO 0xFFFFFFFF启动时加上-dictmyprotocol.dict即可。字典不会直接让 Fuzzer 按语法生成但会显著提高变异命中关键常量的概率。对于内核网络协议这种充满魔数的领域字典几乎是必需品。6. 崩溃分析从 ”段错误“ 到 “修复方案”Fuzz 跑起来之后最刺激的时刻就是屏幕开始滚动崩溃信息。但找到了崩溃不代表可以立刻修还要做去重、复现、定位根因最后才能写修复方案。6.1 崩溃去重用堆栈说话Fuzzer 可能会连续爆出几十个 crash 文件但其中很多其实是同一个 bug 的不同触发输入。判断是否同一个 bug我一般不看输入内容而是看崩溃的栈回溯stack trace。LibFuzzer 运行目录下会生成crash-*文件每个对应一个导致崩溃的输入。用-print_final_stats1或者在启动时加-artifact_prefixcrash/可以更好的分类。去重的技巧是用llvm-symbolizer把地址解析成符号比较栈顶几层的关键函数。比如三个 crash 文件栈回溯都停在ParseMessage() - CopyPayload() - __asan_memcpy基本就能断定是同一个位置的问题。这时候保留最小复现文件其他可以清掉。6.2 最小化输入别拿大文件复现Fuzz 发现的崩溃输入往往长得无法理解动辄几千字节。直接拿它去调试会让问题定位变得困难。LibFuzzer 内置了自动化精简工具./message_fuzzer -minimize_crashminimized.bin crash-1 -max_len4096这个命令会把导致崩溃的输入逐步简化得到一个尽可能小的“最小复现样本”。我从一个 512 字节的崩溃输入简化到过 12 字节调试起来高效太多了。注意精简后的输入一定要再次跑一遍确认仍能复现崩溃因为某些 bug 可能依赖特定的大输入行为精简后可能就不崩了。6.3 用 ASan 输出缩小根因范围实际操作时ASan 的报错信息非常重要。举一个常见的输出样例来解读9425ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000e0f4 at pc... READ of size 2 at 0x60200000e0f4 thread T0 #0 0x4a6d1c in ParsePayload /src/message_parser.cpp:45:25 #1 0x4a7408 in ParseMessage /src/message_parser.cpp:38:9 #2 0x4a7a2b in LLVMFuzzerTestOneInput /tests/fuzz/message_fuzzer.cpp:12:3 #3 0x4b3a86 in fuzzer::Fuzzer::ExecuteCallback(...) 0x60200000e0f4 is located 0 bytes to the right of 2-byte region几个关键信息提取heap-buffer-overflow越界类型这里是堆缓冲区溢出。READ of size 2 at ...越界读 2 字节。#0 ParsePayload /src/message_parser.cpp:45:25具体文件行号指向真正的越界指令。基本流程就是先看 ASan 给出的第一层栈帧确认越界点再往上翻调用栈找到谁调用了它、输入数据是否合法。到这一步往往已经能大致确定是哪个字段导致的了。接下来用 gdb 带上的复现样本跑一次gdb --args ./message_fuzzer minimized.bin在报错点打断点检查关键变量的值基本就能定位根因。我在自己项目上做过一次最后发现是长度字段没有做字节序转换被解释成了超大值绕过校验触发了越界拷贝。这个 bug 如果靠人工 review得对字节序极其敏感才能看出来Fuzz 一分钟就翻出来了。7. 日常维护与避坑真正影响效能的细节最后聊几个我踩过好几次坑的运维和效率问题。这些东西文档上写得少但实际工程里极大影响 Fuzz 的实效。7.1 假覆盖率哈希表的陷阱覆盖率引导的核心是记录每条边是否被覆盖。但如果被测代码里有std::unordered_map这类基于哈希表的容器覆盖率信息容易被扰乱——因为每次插入/查找的路由取决于哈希值的取模而取模对输入太敏感导致 Fuzzer 误以为自己在探索新路径实际上只是在同一个逻辑分支里打转。解决办法是在插桩时排除哈希相关的代码或者配置编译选项忽略标准库内部的插桩。LibFuzzer 可以通过-ignore_remaining_args1传递参数给被测程序也可以使用 ASan 的__asan_default_options屏蔽容器内部的 sanitizer但最省事的做法是尽量在模块边界处 Fuzz而不是直接 Fuzz 到容器内部。7.2 超时与死循环不是 crash 但比 crash 更烦有些 bug 不会导致段错误而是让解析函数陷入死循环或者时间复杂度过高一条输入要跑几十秒甚至几分钟。Fuzzer 会把它标记为 timeout但不等于它没有价值。我用-timeout10默认值超时文件也会被存下来但需要人工判定有些超时是因为输入长度过大导致的正常慢路径有些则是逻辑 bug。排查超时文件我会先看是不是死循环——在 gdb 中跑一次几秒后 CtrlC看当前在哪个函数。如果长时间停在同一行循环里基本可以判定是循环边界条件出了问题。7.3 语料库膨胀隔段时间就要清理Fuzzer 会不断往 corpus 目录里写新发现的有趣输入时间长了可能膨胀到几千甚至几万个文件。文件越多后续变异时扫描开销越大吞吐量反而下降。所以我的习惯是每跑完一轮或每跑几千次发现就手动清理一轮保留能触发新覆盖的输入Fuzzer 自己会根据cov变化判断但我们只能靠目录文件时间戳和大小粗略判断。删除明显重复的、覆盖没有增益的输入。用-merge1参数让 Fuzzer 做一次 corpus 合并和去重。7.4 跑多久才有意义这个问题没有标准答案但根据我的经验可以给个参考对一个中等复杂度的协议解析模块单核 8~12 小时、多核并行比如 8 个核3~6 小时一般是能发现明显问题的“甜点区”。如果跑了 24 小时还没有任何新覆盖增长大概率是 harness 写歪了或者种子语料库质量太差这时候应该回头检查代码而不是继续烧 CPU。另外Fuzz 不是跑一次就完事。每次对代码做了修改、加了对新协议版本的支持都建议重新跑一轮。把 Fuzz 纳入 CI持续集成里每天跑固定时长的回归是我认为最理想的做法——不过这需要一定的基础设施投入小团队可以先用定时任务代替。8. 最后的一点个人经验写到这里我想起一个很直观的对比。之前我负责过一个通信协议栈的重构老代码写了一堆防御性判断逻辑复杂得像迷宫。重构之后单元测试全绿覆盖率 90% 以上结果让 Fuzzer 跑了不到五分钟就翻出一个老代码根本没有的越界漏洞——原因是新代码里引入了一个优雅的抽象层但抽象层背后的std::vector在特定拼接顺序下没保住边界。这件事给我最大的启发是代码越抽象越需要 Fuzz 来兜底因为人眼在多层抽象面前真的不够用了。另一个小技巧是做 Fuzz 的机器一定要保留崩溃现场建议直接把crash-*文件命名成带时间戳的文件名方便回溯。我吃过一次亏某次跑了整晚的 Fuzz 发现了一个很关键的崩溃但第二天清理目录时不小心把 crash 文件删了再也复现不出来后来只能重新跑了几十个小时才再次撞上。从那之后我凡是crash-*文件一律先备份绝不手软。如果你准备在自己项目里引入 Fuzz建议从最简单的 LibFuzzer 加一个解析函数开始别一上来就追求复杂的结构感知。先把流程走通体验一遍从“编译-种子准备-跑起来-看到崩溃-分析-修复”的完整闭环后面再逐步上字典、custom mutator、多核并行。这套东西不是银弹但它是协议类代码最值得投入的测试手段之一——没有之一。
