fuzz测试

第一次跑fuzz测试，测试我把一个解析PNG图片的测试小程序扔进AFL里，三个小时后它吐出来十七个崩溃样本。测试当时我盯着屏幕有点发愣——这玩意儿比我手动找bug快太多了。测试后来我才慢慢摸清楚，测试fuzz测试本质上就是测试让程序在大量畸形输入下暴露自己的脆弱点，它不聪明，测试但足够耐心，测试而且不会累。测试

很多人对fuzz的测试印象还停留在“随机乱敲键盘”。早年的测试fuzz确实挺糙的，比如用`/dev/urandom`生成一堆垃圾数据往程序里灌。测试但现在的测试fuzz工具已经进化得相当精细。拿AFL来说，测试它用遗传算法来引导变异方向：如果一个输入能让程序走到更深的测试代码路径，它就保留这个输入，在它基础上继续变异。这就像养蛊，每一轮都筛选出“最有潜力搞崩程序”的样本。

我印象最深的一次是测一个JSON解析库。正常输入它跑得好好的，但fuzz跑了两天之后，产出了一个只有三个字节的文件：`[{ ]`。就这么个东西，让解析器直接段错误。我拿着这个最小化后的崩溃样本去看源码，发现是嵌套解析时状态机没处理好边界情况。这种bug靠人工review代码很难发现，因为逻辑分支太多了，但fuzz不管这些，它只关心程序会不会挂。

fuzz测试的类型其实分好几种。最基础的是黑盒fuzz，完全不看源码，只管喂数据看结果。灰盒fuzz会插桩，比如AFL的编译模式，能在运行时收集代码覆盖率信息。白盒fuzz更狠，直接做符号执行，像KLEE那种，理论上能穷举路径，但实际用起来受限于路径爆炸问题。我平时用得最多的还是灰盒，性价比最高。

有个细节挺有意思：fuzz的输入语料库（corpus）质量直接决定效率。如果你扔一堆完全随机的文件进去，工具可能要花很久才能摸到有效路径。但如果你给它几个格式正确的样本做种子，它就能很快变异出有意义的边界情况。我曾经偷懒直接拿空目录跑，结果跑了半天覆盖率纹丝不动。后来塞了几个正常JSON进去，半小时就出了崩溃。

当然fuzz也不是万能的。它找的是“能触发崩溃的输入”，不负责判断这个崩溃在真实场景下是否可利用。有时候它报了一堆堆溢出，结果一看是程序自己写的断言触发了，根本不是安全漏洞。还有，fuzz对逻辑漏洞基本无能为力——比如权限绕过、竞态条件这些，它很难通过随机变异构造出来。所以我现在把fuzz当成第一道筛子，筛出来的东西还得人工分析。

工具方面，AFL算是最经典的，但这些年libFuzzer和honggfuzz也用得很多。libFuzzer的好处是直接集成在LLVM里，写个`LLVMFuzzerTestOneInput`函数就能跑，特别适合单元测试级别的fuzz。honggfuzz的反馈机制更细，支持硬件性能计数器，不过配置起来稍微麻烦点。我一般看项目类型选工具，没有哪个是绝对最好的。

最后说个实际感受：fuzz测试跑起来之后，那种“等待崩溃”的感觉有点像钓鱼。你不知道什么时候会咬钩，但一旦有动静，往往就是一条大鱼。而且随着跑的时间越长，新崩溃出现的频率会下降，这时候要么换种子，要么换变异策略，要么就该收竿了——继续挂着也是浪费电。