关于Fuzz 入门的三个误解

崩溃必须去重，同一个空指针解引用能产出几千条重复样本

误解通常来自把「工具的输出」当成「结论」。

先说结论

保护只提高成本，反编译不等于源码。

• 保护：提高成本而非阻断
• 反编译：丢类型与意图
• 逆向：建模 + 验证
• 看运行时数据
• 先假设再取证

误解一：加了保护就没法看

进程内 fuzz 每秒能跑上万次，fork 模式通常只有一千次左右，这个差距决定单位时间产出，能进程内就别 fork。

保护提升的是成本，不是绝对阻断；运行时的数据是真的。

误解二：反编译结果等于源码

种子语料的质量比变异策略更影响前期覆盖率，喂错种子等于白跑，语料要覆盖格式各分支，也要按格式分层。

反编译丢的是类型、命名和意图，这三样恰恰最费时间。

误解三：读懂汇编就会逆向

崩溃必须去重，同一个空指针解引用能产出几千条重复样本。

逆向的核心是建模：猜出原来的设计，再验证。

几个具体事实

下面这些是相对确定的细节：

• 崩溃必须去重，同一个空指针解引用能产出几千条重复样本

怎么少走弯路

先建立「它应该怎么写」的假设，再去找证据。Fuzz 的产出不是崩溃数量，是覆盖率还能不能继续往上走。

还有几处容易忽略的

这些细节不影响入门，但影响你判断的准确度。

• 没有覆盖反馈的随机测试，命中深层路径的概率低到可以忽略，除非解析逻辑只有两三层分支，这类目标本来也少
• sanitizer 能把静默的越界读写变成可见崩溃，是 fuzz 的放大器
• 跑满 24 小时再看覆盖率曲线，前两个小时的结论通常不准，排期按天算而不是按小时
• 只跑一小时就下结论说没有漏洞，样本量远远不够
• 用生产数据当种子，把敏感信息带进语料库
• 不做去重，报告里几千条崩溃全是同一个

把工具输出当结论，是最贵的误解。