深夜十一点CI上那个跑了快半年的随机测试任务突然红了。日志里只有一行ERROR: AddressSanitizer: global-buffer-overflow on address 0x...。我盯着这行字看了三秒然后截图发到测试群里配了一句话概率云又抓到一条鱼。这个任务的代号就叫概率云。它和量子力学里的电子云很像——我们知道bug就在那片输入空间里但没有人能精确指出它藏在哪个角落只能靠不停撒出随机输入去撞击那个极低的、但非零的命中概率。每一次生成的新输入就像把一个程序丢进一个平行宇宙看它在那个世界里是平安无事还是当场炸穿。这篇文章想聊聊一个概率云测试员到底在做什么、怎么从零搭建一套能抓到高价值bug的模糊测试体系以及为什么我认为这套方法值得每一个有稳定产品的团队认真对待。不管你是团队里负责质量的测试开发还是被线上故障按在地上摩擦的后端工程师这篇内容都适用核心思路完全不绑定特定语言或框架。1. 概率云不是玄学模糊测试到底在抓什么1.1 传统测试的盲区bug是一个概率事件而不是确定性事件我见过太多团队对测试的理解停留在功能逻辑验证上需求评审、写用例、功能测试、回归测试、上线。这套流程覆盖的是预期行为也就是我们基于需求文档能想到的所有输入组合。但真实世界的严重bug几乎都不是触发在那些精心设计的用例上。举一个很典型的例子你写了一个函数接收一个配置字符串解析后填充到一张固定大小的表里。你测试了正常填满、填一半、空串、超长字符串全都通过了。但线上某个用户传上来一个负数索引或者一个因为编码问题被截断了一半的畸形值代码直接越界写坏内存。这种bug不会出现在你手工设计的用例里因为它需要的是输入空间中某个狭窄角落的精确组合——这就是为什么管它叫概率事件。你测过的那几十条用例只是从庞大输入空间里抽出的几个点其余那片巨大的概率云根本没有被观测过。传统测试的最大盲区就在这里它默认bug会出现在那些合理的异常路径上但真正致命的bug往往藏在看起来根本不可能发生的输入组合里。1.2 输入空间大到你无法想象穷举从一开始就是死路算一笔账。一个函数如果接收1KB的输入数据这1KB里每个字节都有256种取值组合起来就是256的1024次方种可能。这个数字比可观测宇宙的原子总数还多出无数个数量级。我不需要把平行宇宙这个说法浪漫化——在计算机科学里它就是一个很务实的描述每一个不同的输入都相当于把程序送去一个不同的演化分支程序可能在某个分支崩溃在其他分支正常。这里顺带解释一下为什么量子力学的概率云概念那么贴切。电子云不是电子真的同时出现在所有地方而是说它的存在概率在空间里有特定分布你只能通过大量观测去逼近那个分布。模糊测试也一样我们不知道bug具体在哪但可以根据代码路径的覆盖程度不断调整探测密度——把更多的随机输入撒向那些更有可能藏着bug的代码区域。这本质上就是用一个概率模型去搜索另一个概率分布只是这个搜索过程由机器自动完成。1.3 模糊测试的核心喂入不寻常的输入观察程序是否失稳模糊测试Fuzzing的原理说白了就一句话不断生成半有效甚至完全随机的输入喂给被测程序然后观察它会不会崩溃、卡死、越界、产生未定义行为。如果程序在某个输入下崩溃了就说明那个输入踩中了某个bug的触发条件我们就把这个输入保存下来作为战利品。这套思路单独拿出来其实不新颖上世纪就有人做过。但真正让它从玩具变成生产力工具的是覆盖率引导技术的出现。它不再是闭着眼睛乱撒而是每次执行完程序后把本次执行覆盖到的代码路径记录下来然后优先突变那些探索到新代码路径的输入。换句话说fuzzer在自动绘制一份程序内部地形图并朝着尚未探索的区域前进。bug往往藏在人迹罕至的代码分支里而覆盖率引导的价值就是帮fuzzer主动去找那些人迹罕至的地方。2. 造宇宙的三板斧种子语料、变异引擎和覆盖率反馈现在假设你已经决定要尝试这套方法。我们需要理解三个核心组件它们分别解决从哪儿开始怎么生成新宇宙如何判断该往哪个方向探索三个问题。2.1 种子语料平行宇宙的初始坐标Fuzzer不是凭空生成第一个输入的。绝大多数模糊测试工具都需要你提供一批种子输入seed corpus也就是一批正常且合法的样本。比如你在测试一个JSON解析器那种子语料就应该是几个正常的JSON文件测试一个图片解码器就放几张正常的小图片。种子语料有多重要直接影响命中效率。如果种子太接近真实输入分布fuzzer只需要做少量变异就能踩到新代码路径如果种子完全跑题比如测JSON解析器却放了一堆Excel文件fuzzer的前几分钟基本都在做无用功。我个人的习惯是种子集保持小而多样每个文件尽量独立覆盖一类语法特性。宁可只有几十个文件也不要堆几百个语义重复的大文件——后面你会发现语料库膨胀对fuzzer效率的伤害是悄无声息的这个坑在第5章专门讲。2.2 变异引擎怎么从一条输入长出无数个兄弟宇宙有了种子之后接下来要回答的是怎么从一条宇宙生成另一条宇宙。变异引擎负责这件事。常见的手法定来定去无非那几类位/字节翻转把某个bit或byte改成相反的取值。整数替换把某个四字节区域替换成0、1、0xFFFFFFFF、-1等极端值。字典插入从预设字典里随机挑一个关键词插入到指定位置。拼接/分裂把两条种子输入在随机位置拼接或者切掉一部分。大块删除整块删掉一段数据强制程序进入数据长度异常的分支。你可能觉得这些操作是不是太粗糙了但正是这种粗糙才让fuzzer有机会触达那些看起来合法但语义上不可能的输入组合。真实世界里很多严重bug恰恰是开发者假定了这个字段一定是0到100之间的整数而变异引擎毫不犹豫地给它塞进去一个-2147483648如果代码里没有防御当场就炸了。2.3 覆盖率反馈为什么现代Fuzzer比乱弹琴厉害第三个组件是整个系统的大脑。核心逻辑是每次执行完输入后fuzzer通过插桩技术拿到本次执行的覆盖率数据常见方式是覆盖率计数器和哈希边沿然后把探索到新代码路径的输入加入一个叫做语料库队列的结构下次变异时优先从这些高价值输入里继续突变。这个机制很像一个探洞的人每次发现一个新的岔路口就标记下来然后从那个岔路口继续深入探索。没有覆盖率反馈的fuzzer在巨大输入空间里基本是随机游走可能反复测同一个浅层路径有覆盖率反馈的fuzzer会在几分钟内自动遍历完所有浅层分支然后不断向深层推进。这里我放一个主流工具的对比方便你做选型工具核心机制适合场景上手难度libFuzzer进程内覆盖率引导与Sanitizer天然集成C/C库函数的单元级测试低AFL进程外覆盖率引导支持多种插桩方式命令行工具、网络服务、二进制黑盒中Honggfuzz多线程覆盖率引导支持硬件性能计数器需要大规模并行的场景中我日常用得最多的是libFuzzer因为它编译一次、直接跑函数入口和单元测试的形态最像新人也最容易理解。不过工具选哪个不关键后面讲的核心方法和踩坑经验都是通用的。3. 实操用libFuzzer在自研解析器里抓出一个真实崩溃3.1 目标函数故意留了一个边界漏洞的配置解析器理论聊完必须上手跑一轮。我准备了一个精简到极致的例子用来完整展示从fuzz到定位崩溃的闭环。它的原型是我之前在真实项目里遇到过的一段代码——删除掉所有无关逻辑后保留核心漏洞就是这个样子// config_parser.cpp #include cstdint #include cstddef #include cstring const int kMaxRules 16; int rule_table[kMaxRules]; extern C int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size) { // 每次调用前清空规则表避免状态污染 memset(rule_table, 0, sizeof(rule_table)); if (size 8) { return 0; } int rule_id; int value; memcpy(rule_id, data, 4); memcpy(value, data 4, 4); // 这里模拟生产环境代码先做一堆合法性检查 // 但当年漏掉了一个最关键的边界检查rule_id 是否在 [0, kMaxRules) 范围内。 rule_table[rule_id] value; return 0; }实际生产版本里rule_id不是直接从二进制读出来的而是从一段带格式的文本里解析出来的。但文本解析逻辑对fuzzer来说没有本质区别——最终rule_id落进数组下标这行代码时边界检查缺失的后果是一样的。这个例子我们注入了缺陷rule_table[rule_id] value;没有任何边界检查如果rule_id是负数或超过15就会发生内存越界写。3.2 为什么选libFuzzer编译一下就自带探索能力LLVMFuzzerTestOneInput这个入口函数是libFuzzer的约定。你只需要把被测代码写成一个接收data和size的函数libFuzzer就会不断生成随机字节流来调用它。这里的data就是我们扔进平行宇宙的那组输入参数。编译命令也很简单我用clang自带的fuzzer和AddressSanitizerclang -g -fsanitizeaddress,fuzzer -o config_fuzzer config_parser.cpp-fsanitizeaddress负责把内存越界检测出来-fsanitizefuzzer则把libFuzzer引擎链接进来。编译后你会得到一个名为config_fuzzer的可执行文件它既能跑fuzz又能复现crash。3.3 开始投放看它怎么自己撞上去直接运行我给它限定跑最多30秒./config_fuzzer -max_total_time30libFuzzer启动后会打印实时统计信息每一行都是宇宙探索进度。你会看到类似这样的输出#1048576 pulse cov: 4 ft: 5 corp: 4 exec/s: 34952 rss: 18Mb #2097152 pulse cov: 4 ft: 5 corp: 4 exec/s: 34952 rss: 18Mb这里的cov是覆盖率exec/s是每秒执行次数。在我的机器上这个简单例子每秒能跑几万次——这种执行速度是它是能大规模投放的根本保障。很快大概几秒内它就会抓到崩溃并停止INFO: libFuzzer crashing input found, writing it to: crash-xxxxxxxx...它把那条触发崩溃的输入保存成了一个文件文件名以crash-开头。这个文件就是我们的战利品——一个被验证过确实能让程序崩溃的平行宇宙坐标。3.4 从崩溃现场到根因定位ASAN把问题甩在脸上用同一个二进制直接复现这个crash./config_fuzzer crash-xxxxxxxx运行后AddressSanitizer会打印出一长串报告。最核心的几行长这样ERROR: AddressSanitizer: global-buffer-overflow on address 0x000002a2a900 at pc ... WRITE of size 4 at 0x000002a2a900 thread T0 #0 0x... in LLVMFuzzerTestOneInput config_parser.cpp:27:5 #1 0x... in fuzzer::Fuzzer::ExecuteCallback ... 0x000002a2a900 is located 4 bytes to the left of global variable rule_table defined in config_parser.cpp:6:12这里的信息量很大我来逐行翻译global-buffer-overflow程序发生了全局缓冲区越界写。WRITE of size 4写操作大小是4字节说明写的是int类型变量。config_parser.cpp:27:5崩溃点精确到第27行就是rule_table[rule_id] value;那一行。located 4 bytes to the left of global variable rule_table这条最有价值它直接告诉我们是写到了rule_table左边4字节的位置——也就是说rule_id是-1。这个例子很幸运因为规则表是全局变量ASAN给的信息非常直白。但在真实项目里越界通常发生在堆上ASAN同样能给出精确的偏移量和调用栈。很多时候bug根因就是靠这几行输出直接锁定的不需要你像刑侦一样反复猜测。3.5 最小化与回归不要只当一次性的猎手找到crash之后还有两步关键收尾工作。第一步是最小化测试用例。libFuzzer提供了一个参数./config_fuzzer -minimize_crash1 crash-xxxxxxxx -max_total_time30上面这个命令会把8字节的crash输入进一步缩减到最小的可复现集。最小化不是为了存文件好看而是为了让后续修bug的人能快速看清到底什么输入触发了崩溃。有时候一个几百字节的输入能被压缩到五六字节这对根因分析帮助极大。第二步是把最小化后的输入变成一条回归用例。修复bug后把它加入自动化测试套件保证这个平行宇宙永远不会在代码重构后复活。这一步我会在第6章展开讲但请记住它和找到bug同样重要——没有回归保护的bug修复只是暂时的胜利。4. 什么样的bug才配得上价值千万高价值缺陷的真实分布4.1 高价值bug的共同画像低概率、高影响、藏得深很多人问过我标题里说价值千万的bug是不是噱头真有一个bug值千万吗我的回答是单次直接损失也许没有千万但某些bug一旦被触发综合损失轻松超过八位数。它们通常有三个特征。第一触发概率极低低到常规测试永远碰不到第二影响范围极大出现在被大量复用的底层库或核心链路上一个库崩了上方所有依赖它的应用跟着遭殃第三藏得深不是简单的一行错误而是需要多层数据组合才能踩中的逻辑漏洞。这三个特征恰好和模糊测试的优势完全重叠——搜索低概率输入空间、自动探索深层次代码路径、高效定位隐藏边界问题。为什么金融交易系统、医疗器械、工控协议栈这类领域特别看重fuzzing因为它们一旦出bug可能不是丢失一条数据而是真实世界的事故。在这些领域bug的单次期望损失特别高所以哪怕fuzzer跑一个月才找到一条也是划算的。4.2 一个真实案例OpenSSL心脏出血的启示2014年曝出的OpenSSL心脏出血漏洞Heartbleed是高价值bug的教科书级案例。它触发条件非常特殊客户端发送一个畸形长度的请求服务器在回复时从内存中读取了超出预期长度的数据从而泄露内存中的密钥和用户数据。它难发现吗难。因为它需要两个字段之间的一致性不匹配——攻击者声称我的负载长这么大但实际发送的负载没那么长。这种跨字段的一致性校验恰好是开发者最容易漏掉、也是传统测试用例最不会设计到的边界组合。它的影响范围呢半个互联网都受影响大量线上服务的TLS私钥随时可能被读取。这就是典型的概率云里的bug——它一直存在只是在无数个正常请求的掩盖下没人注意到那个微小的概率不均匀。当时我第一时间想到的就是如果OpenSSL团队在提交代码时配了一个简单的fuzzer专门盯着这个TLS握手的长度字段做变异这类漏洞暴露的时间会大幅提前。事实上后来Google的OSS-Fuzz项目持续对OpenSSL做fuzzing也确实不断报出类似的内存错误。这就是概率云测试员存在的价值——把高风险缺陷的暴露时间从上线之后提前到发布之前。4.3 谁最该养一个概率云测试员不是只有大公司才需要。我的判断标准很简单如果你的代码里存在以下任何一种情况就应该认真考虑引入模糊测试直接解析外部输入比如上传文件、网络报文、命令行参数、配置字符串。使用了不安全的内存操作比如C/C、Rust里的unsafe block、原生库绑定。处于分布式系统的核心链路一个隐藏bug可能引发连锁故障。代码生命周期长会持续迭代好几年。说实话大部分团队的代码至少命中两三条。也就是说概率云测试员不是某个特定岗位的专属职责而应该是每个严肃对待质量的工程师都应该掌握的技能。5. 跑了三天零结果模糊测试的六个典型翻车现场与对策5.1 覆盖率虚高但迟迟不崩溃这个状况最磨人。fuzzer跑起来每秒钟执行几万次覆盖率一路涨到百分之七八十但就是没有crash。很多人的第一反应是是不是fuzzer不灵了。别急这很可能是你的sanitizer没配全。我遇到过太多次这样的情况只开了AddressSanitizer漏了UndefinedBehaviorSanitizer。未定义行为比如有符号整数溢出在不开UBSan的情况下不会崩溃程序会用错误的结果继续跑从而掩盖了真正的根因。我的建议是能开的全开至少-fsanitizeaddress,undefined组合打底。另一个常见原因是目标函数内部有过多的状态检查导致深层代码根本进不去。这时候先检查覆盖率数据看哪几个函数覆盖率为0针对性地补充种子语料。5.2 语料库失控越大不一定越强跑了一段时间corpus目录膨胀到几万个文件fuzzer的启动和同步越来越慢。这是很多团队踩过的最普通的坑语料库只进不出。解决办法是定期做语料库最小化。libFuzzer自带参数./config_fuzzer -merge1 corpus_dir它的作用是把多条输入合并成等价的最小集合只保留那些能带来独特覆盖率的输入。跑完你会发现几万个文件缩水到几百个但覆盖率一条都不少。这个过程相当于在一次宇宙大清洗——把重复的平行宇宙删掉只留下地形独特的那个。5.3 崩溃无法复现忘了记录运行环境我见过最离谱的情况是CI上fuzzer报了个crash但开发用同一个crash文件怎么跑都复现不了。原因往往是编译参数不一致比如CI开了-O1但本地是-O0或者CI用了某个宏定义而本地没有。写进文档的一句话就够crash文件和可执行文件以及对应的源码commit hash必须打包存档。做不到这一点这个crash就废了。5.4 误报与第三方库噪音刚开始跑fuzzer最容易遇到的失望时刻是报了一堆crash一分析全是第三方库的锅——比如某个依赖的正则表达式库遇到超长输入栈溢出你的代码其实没问题。这种情况的对策是在fuzz target里加上输入长度和复杂性限制把第三方库的异常输入提前拦截掉。比如if (size 4096) return 0;这样fuzzer的搜索重点就集中在你真正关心的核心逻辑上而不是在给第三方库找毛病。当然如果你就是想测第三方库那就另当别论。5.5 并行任务与资源博弈Fuzzer是吃CPU的怪物。默认情况下它会把当前机器所有核心拉满这在开发机上会导致其他任务卡顿。解决方法是限制并发度./config_fuzzer -jobs4 -workers4或者干脆放在CI的专用机器上跑。但要记住一个反直觉的点fuzzer并不是线程越多效率越高特别是单次执行数据依赖公共状态时并行可能触发fuzzer内部的协调开销。我通常建议同一块逻辑先用单进程跑通确认覆盖率和执行速度正常再考虑并行。5.6 把fuzzer当成一次性工具跑完就删很多团队把fuzzer当作上线前突击检查的工具跑一个周末发现没崩溃就再也没碰过。这种做法的问题在于软件是持续演化的——重构成持续集成的流水线让fuzzer成为常态化任务。6. 把平行宇宙接进流水线团队持续吃红利的落地姿势6.1 先搭一个最小闭环不要一上来就搞大平台我见过不少团队想把fuzzing平台化做成统一的runner集群、dashboard、自动排单。理念没问题但落地很容易卡在平台还没建好连一个crash都没找到的尴尬期。我的建议是从最小闭环开始第一步挑一个解析复杂外部输入的核心模块用libFuzzer写出LLVMFuzzerTestOneInput第二步在CI上加一个定时任务每天凌晨跑2小时只允许它占2个CPU核第三步配一个专门的crash归档目录谁触发谁负责排查。这套东西半天就能搭完但它已经能持续产出真正有价值的bug。有了第一版crash报告再逐步迭代加更多fuzz target、合并覆盖报告、引入-merge1做语料库优化。以战养战比闭门造车搞平台靠谱得多。6.2 回归语料与防复发机制这是最容易被忽略但价值最高的一环。每抓到一条真实crash、修复通过后把最小化后的输入提交到一个专门的corpus/regression目录并在测试套件里加一条断言运行fuzz target并确认不崩溃。这样当未来某次重构改变了内部数据结构这条输入会第一时间报警——它在说你把我曾经炸穿的那条路又打开了。我个人甚至会把crash输入命名成可读的格式比如bugfix_20250627_rule_overflow.json放在代码库里。除了当回归用例它本身也是一份致后人的文档。6.3 分级响应不是所有crash都值得通宵crash报告会越来越多如果每一条都要当天处理团队迟早被拖垮。需要分级P0可远程利用、影响面大的漏洞比如命令注入、堆越界写导致提权。P1会造成崩溃但不一定能被稳定利用的越界读写。P2功能性错误但不会导致崩溃比如断言失败、逻辑错误。前两类优先修P2攒着定期清。这种分级也方便和产品团队沟通——让他们理解fuzzer找回来的不是垃圾是风险清单。6.4 团队协作的最后一环把概率云文化带到日常最后聊两句文化层面的东西。我只分享个人感受概率云测试员这个角色最需要的能力不是天天跟工具打交道而是对代码里一定存在未知bug这件事保持谦逊。工具只是手段真正重要的是你要相信就算你写了十年高质量代码也不可能覆盖所有可能的输入组合。带着这种信念去建设一套持续探索未知输入空间的体系才是这件事的本质。收尾写在最后一次部署之后这套体系在我负责的模块里跑了两年累计抓到了二十多个真实bug其中两个是会在生产环境引发崩溃级别的问题。每次同事问我你那个随机测试怎么这么神我都会纠正他们不是神是代码在输入空间里的弱点被我换了个方式扫描了一遍。最后分享一个我自己的操作习惯也当作读者上手的起步指引每个fuzzer任务先花30分钟观察一条指标——每秒执行次数exec/s。如果这个数字低于1万赶紧检查是不是函数入口太重、有大量初始化开销或者语料里混进了超大样本。执行速度是所有策略的基础理论上每秒能跑的宇宙数越多你发现稀薄概率云里那些角落的速度就越快。反之什么花哨的策略都比不上优化这个数字来得实在。
深夜十一点CI上那个跑了快半年的随机测试任务突然红了。日志里只有一行ERROR: AddressSanitizer: global-buffer-overflow on address 0x...。我盯着这行字看了三秒然后截图发到测试群里配了一句话概率云又抓到一条鱼。这个任务的代号就叫概率云。它和量子力学里的电子云很像——我们知道bug就在那片输入空间里但没有人能精确指出它藏在哪个角落只能靠不停撒出随机输入去撞击那个极低的、但非零的命中概率。每一次生成的新输入就像把一个程序丢进一个平行宇宙看它在那个世界里是平安无事还是当场炸穿。这篇文章想聊聊一个概率云测试员到底在做什么、怎么从零搭建一套能抓到高价值bug的模糊测试体系以及为什么我认为这套方法值得每一个有稳定产品的团队认真对待。不管你是团队里负责质量的测试开发还是被线上故障按在地上摩擦的后端工程师这篇内容都适用核心思路完全不绑定特定语言或框架。1. 概率云不是玄学模糊测试到底在抓什么1.1 传统测试的盲区bug是一个概率事件而不是确定性事件我见过太多团队对测试的理解停留在功能逻辑验证上需求评审、写用例、功能测试、回归测试、上线。这套流程覆盖的是预期行为也就是我们基于需求文档能想到的所有输入组合。但真实世界的严重bug几乎都不是触发在那些精心设计的用例上。举一个很典型的例子你写了一个函数接收一个配置字符串解析后填充到一张固定大小的表里。你测试了正常填满、填一半、空串、超长字符串全都通过了。但线上某个用户传上来一个负数索引或者一个因为编码问题被截断了一半的畸形值代码直接越界写坏内存。这种bug不会出现在你手工设计的用例里因为它需要的是输入空间中某个狭窄角落的精确组合——这就是为什么管它叫概率事件。你测过的那几十条用例只是从庞大输入空间里抽出的几个点其余那片巨大的概率云根本没有被观测过。传统测试的最大盲区就在这里它默认bug会出现在那些合理的异常路径上但真正致命的bug往往藏在看起来根本不可能发生的输入组合里。1.2 输入空间大到你无法想象穷举从一开始就是死路算一笔账。一个函数如果接收1KB的输入数据这1KB里每个字节都有256种取值组合起来就是256的1024次方种可能。这个数字比可观测宇宙的原子总数还多出无数个数量级。我不需要把平行宇宙这个说法浪漫化——在计算机科学里它就是一个很务实的描述每一个不同的输入都相当于把程序送去一个不同的演化分支程序可能在某个分支崩溃在其他分支正常。这里顺带解释一下为什么量子力学的概率云概念那么贴切。电子云不是电子真的同时出现在所有地方而是说它的存在概率在空间里有特定分布你只能通过大量观测去逼近那个分布。模糊测试也一样我们不知道bug具体在哪但可以根据代码路径的覆盖程度不断调整探测密度——把更多的随机输入撒向那些更有可能藏着bug的代码区域。这本质上就是用一个概率模型去搜索另一个概率分布只是这个搜索过程由机器自动完成。1.3 模糊测试的核心喂入不寻常的输入观察程序是否失稳模糊测试Fuzzing的原理说白了就一句话不断生成半有效甚至完全随机的输入喂给被测程序然后观察它会不会崩溃、卡死、越界、产生未定义行为。如果程序在某个输入下崩溃了就说明那个输入踩中了某个bug的触发条件我们就把这个输入保存下来作为战利品。这套思路单独拿出来其实不新颖上世纪就有人做过。但真正让它从玩具变成生产力工具的是覆盖率引导技术的出现。它不再是闭着眼睛乱撒而是每次执行完程序后把本次执行覆盖到的代码路径记录下来然后优先突变那些探索到新代码路径的输入。换句话说fuzzer在自动绘制一份程序内部地形图并朝着尚未探索的区域前进。bug往往藏在人迹罕至的代码分支里而覆盖率引导的价值就是帮fuzzer主动去找那些人迹罕至的地方。2. 造宇宙的三板斧种子语料、变异引擎和覆盖率反馈现在假设你已经决定要尝试这套方法。我们需要理解三个核心组件它们分别解决从哪儿开始怎么生成新宇宙如何判断该往哪个方向探索三个问题。2.1 种子语料平行宇宙的初始坐标Fuzzer不是凭空生成第一个输入的。绝大多数模糊测试工具都需要你提供一批种子输入seed corpus也就是一批正常且合法的样本。比如你在测试一个JSON解析器那种子语料就应该是几个正常的JSON文件测试一个图片解码器就放几张正常的小图片。种子语料有多重要直接影响命中效率。如果种子太接近真实输入分布fuzzer只需要做少量变异就能踩到新代码路径如果种子完全跑题比如测JSON解析器却放了一堆Excel文件fuzzer的前几分钟基本都在做无用功。我个人的习惯是种子集保持小而多样每个文件尽量独立覆盖一类语法特性。宁可只有几十个文件也不要堆几百个语义重复的大文件——后面你会发现语料库膨胀对fuzzer效率的伤害是悄无声息的这个坑在第5章专门讲。2.2 变异引擎怎么从一条输入长出无数个兄弟宇宙有了种子之后接下来要回答的是怎么从一条宇宙生成另一条宇宙。变异引擎负责这件事。常见的手法定来定去无非那几类位/字节翻转把某个bit或byte改成相反的取值。整数替换把某个四字节区域替换成0、1、0xFFFFFFFF、-1等极端值。字典插入从预设字典里随机挑一个关键词插入到指定位置。拼接/分裂把两条种子输入在随机位置拼接或者切掉一部分。大块删除整块删掉一段数据强制程序进入数据长度异常的分支。你可能觉得这些操作是不是太粗糙了但正是这种粗糙才让fuzzer有机会触达那些看起来合法但语义上不可能的输入组合。真实世界里很多严重bug恰恰是开发者假定了这个字段一定是0到100之间的整数而变异引擎毫不犹豫地给它塞进去一个-2147483648如果代码里没有防御当场就炸了。2.3 覆盖率反馈为什么现代Fuzzer比乱弹琴厉害第三个组件是整个系统的大脑。核心逻辑是每次执行完输入后fuzzer通过插桩技术拿到本次执行的覆盖率数据常见方式是覆盖率计数器和哈希边沿然后把探索到新代码路径的输入加入一个叫做语料库队列的结构下次变异时优先从这些高价值输入里继续突变。这个机制很像一个探洞的人每次发现一个新的岔路口就标记下来然后从那个岔路口继续深入探索。没有覆盖率反馈的fuzzer在巨大输入空间里基本是随机游走可能反复测同一个浅层路径有覆盖率反馈的fuzzer会在几分钟内自动遍历完所有浅层分支然后不断向深层推进。这里我放一个主流工具的对比方便你做选型工具核心机制适合场景上手难度libFuzzer进程内覆盖率引导与Sanitizer天然集成C/C库函数的单元级测试低AFL进程外覆盖率引导支持多种插桩方式命令行工具、网络服务、二进制黑盒中Honggfuzz多线程覆盖率引导支持硬件性能计数器需要大规模并行的场景中我日常用得最多的是libFuzzer因为它编译一次、直接跑函数入口和单元测试的形态最像新人也最容易理解。不过工具选哪个不关键后面讲的核心方法和踩坑经验都是通用的。3. 实操用libFuzzer在自研解析器里抓出一个真实崩溃3.1 目标函数故意留了一个边界漏洞的配置解析器理论聊完必须上手跑一轮。我准备了一个精简到极致的例子用来完整展示从fuzz到定位崩溃的闭环。它的原型是我之前在真实项目里遇到过的一段代码——删除掉所有无关逻辑后保留核心漏洞就是这个样子// config_parser.cpp #include cstdint #include cstddef #include cstring const int kMaxRules 16; int rule_table[kMaxRules]; extern C int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size) { // 每次调用前清空规则表避免状态污染 memset(rule_table, 0, sizeof(rule_table)); if (size 8) { return 0; } int rule_id; int value; memcpy(rule_id, data, 4); memcpy(value, data 4, 4); // 这里模拟生产环境代码先做一堆合法性检查 // 但当年漏掉了一个最关键的边界检查rule_id 是否在 [0, kMaxRules) 范围内。 rule_table[rule_id] value; return 0; }实际生产版本里rule_id不是直接从二进制读出来的而是从一段带格式的文本里解析出来的。但文本解析逻辑对fuzzer来说没有本质区别——最终rule_id落进数组下标这行代码时边界检查缺失的后果是一样的。这个例子我们注入了缺陷rule_table[rule_id] value;没有任何边界检查如果rule_id是负数或超过15就会发生内存越界写。3.2 为什么选libFuzzer编译一下就自带探索能力LLVMFuzzerTestOneInput这个入口函数是libFuzzer的约定。你只需要把被测代码写成一个接收data和size的函数libFuzzer就会不断生成随机字节流来调用它。这里的data就是我们扔进平行宇宙的那组输入参数。编译命令也很简单我用clang自带的fuzzer和AddressSanitizerclang -g -fsanitizeaddress,fuzzer -o config_fuzzer config_parser.cpp-fsanitizeaddress负责把内存越界检测出来-fsanitizefuzzer则把libFuzzer引擎链接进来。编译后你会得到一个名为config_fuzzer的可执行文件它既能跑fuzz又能复现crash。3.3 开始投放看它怎么自己撞上去直接运行我给它限定跑最多30秒./config_fuzzer -max_total_time30libFuzzer启动后会打印实时统计信息每一行都是宇宙探索进度。你会看到类似这样的输出#1048576 pulse cov: 4 ft: 5 corp: 4 exec/s: 34952 rss: 18Mb #2097152 pulse cov: 4 ft: 5 corp: 4 exec/s: 34952 rss: 18Mb这里的cov是覆盖率exec/s是每秒执行次数。在我的机器上这个简单例子每秒能跑几万次——这种执行速度是它是能大规模投放的根本保障。很快大概几秒内它就会抓到崩溃并停止INFO: libFuzzer crashing input found, writing it to: crash-xxxxxxxx...它把那条触发崩溃的输入保存成了一个文件文件名以crash-开头。这个文件就是我们的战利品——一个被验证过确实能让程序崩溃的平行宇宙坐标。3.4 从崩溃现场到根因定位ASAN把问题甩在脸上用同一个二进制直接复现这个crash./config_fuzzer crash-xxxxxxxx运行后AddressSanitizer会打印出一长串报告。最核心的几行长这样ERROR: AddressSanitizer: global-buffer-overflow on address 0x000002a2a900 at pc ... WRITE of size 4 at 0x000002a2a900 thread T0 #0 0x... in LLVMFuzzerTestOneInput config_parser.cpp:27:5 #1 0x... in fuzzer::Fuzzer::ExecuteCallback ... 0x000002a2a900 is located 4 bytes to the left of global variable rule_table defined in config_parser.cpp:6:12这里的信息量很大我来逐行翻译global-buffer-overflow程序发生了全局缓冲区越界写。WRITE of size 4写操作大小是4字节说明写的是int类型变量。config_parser.cpp:27:5崩溃点精确到第27行就是rule_table[rule_id] value;那一行。located 4 bytes to the left of global variable rule_table这条最有价值它直接告诉我们是写到了rule_table左边4字节的位置——也就是说rule_id是-1。这个例子很幸运因为规则表是全局变量ASAN给的信息非常直白。但在真实项目里越界通常发生在堆上ASAN同样能给出精确的偏移量和调用栈。很多时候bug根因就是靠这几行输出直接锁定的不需要你像刑侦一样反复猜测。3.5 最小化与回归不要只当一次性的猎手找到crash之后还有两步关键收尾工作。第一步是最小化测试用例。libFuzzer提供了一个参数./config_fuzzer -minimize_crash1 crash-xxxxxxxx -max_total_time30上面这个命令会把8字节的crash输入进一步缩减到最小的可复现集。最小化不是为了存文件好看而是为了让后续修bug的人能快速看清到底什么输入触发了崩溃。有时候一个几百字节的输入能被压缩到五六字节这对根因分析帮助极大。第二步是把最小化后的输入变成一条回归用例。修复bug后把它加入自动化测试套件保证这个平行宇宙永远不会在代码重构后复活。这一步我会在第6章展开讲但请记住它和找到bug同样重要——没有回归保护的bug修复只是暂时的胜利。4. 什么样的bug才配得上价值千万高价值缺陷的真实分布4.1 高价值bug的共同画像低概率、高影响、藏得深很多人问过我标题里说价值千万的bug是不是噱头真有一个bug值千万吗我的回答是单次直接损失也许没有千万但某些bug一旦被触发综合损失轻松超过八位数。它们通常有三个特征。第一触发概率极低低到常规测试永远碰不到第二影响范围极大出现在被大量复用的底层库或核心链路上一个库崩了上方所有依赖它的应用跟着遭殃第三藏得深不是简单的一行错误而是需要多层数据组合才能踩中的逻辑漏洞。这三个特征恰好和模糊测试的优势完全重叠——搜索低概率输入空间、自动探索深层次代码路径、高效定位隐藏边界问题。为什么金融交易系统、医疗器械、工控协议栈这类领域特别看重fuzzing因为它们一旦出bug可能不是丢失一条数据而是真实世界的事故。在这些领域bug的单次期望损失特别高所以哪怕fuzzer跑一个月才找到一条也是划算的。4.2 一个真实案例OpenSSL心脏出血的启示2014年曝出的OpenSSL心脏出血漏洞Heartbleed是高价值bug的教科书级案例。它触发条件非常特殊客户端发送一个畸形长度的请求服务器在回复时从内存中读取了超出预期长度的数据从而泄露内存中的密钥和用户数据。它难发现吗难。因为它需要两个字段之间的一致性不匹配——攻击者声称我的负载长这么大但实际发送的负载没那么长。这种跨字段的一致性校验恰好是开发者最容易漏掉、也是传统测试用例最不会设计到的边界组合。它的影响范围呢半个互联网都受影响大量线上服务的TLS私钥随时可能被读取。这就是典型的概率云里的bug——它一直存在只是在无数个正常请求的掩盖下没人注意到那个微小的概率不均匀。当时我第一时间想到的就是如果OpenSSL团队在提交代码时配了一个简单的fuzzer专门盯着这个TLS握手的长度字段做变异这类漏洞暴露的时间会大幅提前。事实上后来Google的OSS-Fuzz项目持续对OpenSSL做fuzzing也确实不断报出类似的内存错误。这就是概率云测试员存在的价值——把高风险缺陷的暴露时间从上线之后提前到发布之前。4.3 谁最该养一个概率云测试员不是只有大公司才需要。我的判断标准很简单如果你的代码里存在以下任何一种情况就应该认真考虑引入模糊测试直接解析外部输入比如上传文件、网络报文、命令行参数、配置字符串。使用了不安全的内存操作比如C/C、Rust里的unsafe block、原生库绑定。处于分布式系统的核心链路一个隐藏bug可能引发连锁故障。代码生命周期长会持续迭代好几年。说实话大部分团队的代码至少命中两三条。也就是说概率云测试员不是某个特定岗位的专属职责而应该是每个严肃对待质量的工程师都应该掌握的技能。5. 跑了三天零结果模糊测试的六个典型翻车现场与对策5.1 覆盖率虚高但迟迟不崩溃这个状况最磨人。fuzzer跑起来每秒钟执行几万次覆盖率一路涨到百分之七八十但就是没有crash。很多人的第一反应是是不是fuzzer不灵了。别急这很可能是你的sanitizer没配全。我遇到过太多次这样的情况只开了AddressSanitizer漏了UndefinedBehaviorSanitizer。未定义行为比如有符号整数溢出在不开UBSan的情况下不会崩溃程序会用错误的结果继续跑从而掩盖了真正的根因。我的建议是能开的全开至少-fsanitizeaddress,undefined组合打底。另一个常见原因是目标函数内部有过多的状态检查导致深层代码根本进不去。这时候先检查覆盖率数据看哪几个函数覆盖率为0针对性地补充种子语料。5.2 语料库失控越大不一定越强跑了一段时间corpus目录膨胀到几万个文件fuzzer的启动和同步越来越慢。这是很多团队踩过的最普通的坑语料库只进不出。解决办法是定期做语料库最小化。libFuzzer自带参数./config_fuzzer -merge1 corpus_dir它的作用是把多条输入合并成等价的最小集合只保留那些能带来独特覆盖率的输入。跑完你会发现几万个文件缩水到几百个但覆盖率一条都不少。这个过程相当于在一次宇宙大清洗——把重复的平行宇宙删掉只留下地形独特的那个。5.3 崩溃无法复现忘了记录运行环境我见过最离谱的情况是CI上fuzzer报了个crash但开发用同一个crash文件怎么跑都复现不了。原因往往是编译参数不一致比如CI开了-O1但本地是-O0或者CI用了某个宏定义而本地没有。写进文档的一句话就够crash文件和可执行文件以及对应的源码commit hash必须打包存档。做不到这一点这个crash就废了。5.4 误报与第三方库噪音刚开始跑fuzzer最容易遇到的失望时刻是报了一堆crash一分析全是第三方库的锅——比如某个依赖的正则表达式库遇到超长输入栈溢出你的代码其实没问题。这种情况的对策是在fuzz target里加上输入长度和复杂性限制把第三方库的异常输入提前拦截掉。比如if (size 4096) return 0;这样fuzzer的搜索重点就集中在你真正关心的核心逻辑上而不是在给第三方库找毛病。当然如果你就是想测第三方库那就另当别论。5.5 并行任务与资源博弈Fuzzer是吃CPU的怪物。默认情况下它会把当前机器所有核心拉满这在开发机上会导致其他任务卡顿。解决方法是限制并发度./config_fuzzer -jobs4 -workers4或者干脆放在CI的专用机器上跑。但要记住一个反直觉的点fuzzer并不是线程越多效率越高特别是单次执行数据依赖公共状态时并行可能触发fuzzer内部的协调开销。我通常建议同一块逻辑先用单进程跑通确认覆盖率和执行速度正常再考虑并行。5.6 把fuzzer当成一次性工具跑完就删很多团队把fuzzer当作上线前突击检查的工具跑一个周末发现没崩溃就再也没碰过。这种做法的问题在于软件是持续演化的——重构成持续集成的流水线让fuzzer成为常态化任务。6. 把平行宇宙接进流水线团队持续吃红利的落地姿势6.1 先搭一个最小闭环不要一上来就搞大平台我见过不少团队想把fuzzing平台化做成统一的runner集群、dashboard、自动排单。理念没问题但落地很容易卡在平台还没建好连一个crash都没找到的尴尬期。我的建议是从最小闭环开始第一步挑一个解析复杂外部输入的核心模块用libFuzzer写出LLVMFuzzerTestOneInput第二步在CI上加一个定时任务每天凌晨跑2小时只允许它占2个CPU核第三步配一个专门的crash归档目录谁触发谁负责排查。这套东西半天就能搭完但它已经能持续产出真正有价值的bug。有了第一版crash报告再逐步迭代加更多fuzz target、合并覆盖报告、引入-merge1做语料库优化。以战养战比闭门造车搞平台靠谱得多。6.2 回归语料与防复发机制这是最容易被忽略但价值最高的一环。每抓到一条真实crash、修复通过后把最小化后的输入提交到一个专门的corpus/regression目录并在测试套件里加一条断言运行fuzz target并确认不崩溃。这样当未来某次重构改变了内部数据结构这条输入会第一时间报警——它在说你把我曾经炸穿的那条路又打开了。我个人甚至会把crash输入命名成可读的格式比如bugfix_20250627_rule_overflow.json放在代码库里。除了当回归用例它本身也是一份致后人的文档。6.3 分级响应不是所有crash都值得通宵crash报告会越来越多如果每一条都要当天处理团队迟早被拖垮。需要分级P0可远程利用、影响面大的漏洞比如命令注入、堆越界写导致提权。P1会造成崩溃但不一定能被稳定利用的越界读写。P2功能性错误但不会导致崩溃比如断言失败、逻辑错误。前两类优先修P2攒着定期清。这种分级也方便和产品团队沟通——让他们理解fuzzer找回来的不是垃圾是风险清单。6.4 团队协作的最后一环把概率云文化带到日常最后聊两句文化层面的东西。我只分享个人感受概率云测试员这个角色最需要的能力不是天天跟工具打交道而是对代码里一定存在未知bug这件事保持谦逊。工具只是手段真正重要的是你要相信就算你写了十年高质量代码也不可能覆盖所有可能的输入组合。带着这种信念去建设一套持续探索未知输入空间的体系才是这件事的本质。收尾写在最后一次部署之后这套体系在我负责的模块里跑了两年累计抓到了二十多个真实bug其中两个是会在生产环境引发崩溃级别的问题。每次同事问我你那个随机测试怎么这么神我都会纠正他们不是神是代码在输入空间里的弱点被我换了个方式扫描了一遍。最后分享一个我自己的操作习惯也当作读者上手的起步指引每个fuzzer任务先花30分钟观察一条指标——每秒执行次数exec/s。如果这个数字低于1万赶紧检查是不是函数入口太重、有大量初始化开销或者语料里混进了超大样本。执行速度是所有策略的基础理论上每秒能跑的宇宙数越多你发现稀薄概率云里那些角落的速度就越快。反之什么花哨的策略都比不上优化这个数字来得实在。
