怎么看Fuzz 入门:观察顺序

逆向工程 · 2 分钟阅读· 180 次阅读

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

观察顺序错了,会在一堆细节里迷失。正确的顺序是:每层只问一个问题。

先说结论

每层只回答一个问题,才不会乱。

  • 文件层:做什么
  • 加载层:放哪里
  • 运行层:怎么走
  • 先看字符串与导入
  • 有假设再下断点

三层各问什么

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

层 看什么 回答的问题
文件层 格式、段表、导入表、字符串 它大概做什么
加载层 内存布局、基址、重定位 它被放在哪
运行层 调用、参数、返回值 它实际怎么走

先看字符串和导入

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

字符串和导入表是成本最低的线索,能省掉大量反汇编时间。

几个具体线索

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

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

怎么看Fuzz 入门

什么时候下断点

等你已经能写出「它大概会调用哪个函数」的假设,再下断点验证。Fuzz 的产出不是崩溃数量,是覆盖率还能不能继续往上走。

还有几处容易忽略的

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

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

观察的顺序,决定了效率。

评论 (3)

南
南风

补一句:修完要回归,很多人修一半。

路
路人甲

终于有人讲清楚「为什么」而不是只给命令。

白
白帽小陈

防御那节写得克制,没有教人打站,这点好评。

发表评论

验证码

提交后需站长审核,通过后才会显示。