动态Fuzzing

　　采取动态测试的方式，以已有的二进制文件或者文本模板为基础，对待侧目标的外部接口进行充分检测，可以用下面的图例表示：

　　动态Fuzzing的特点也很明显：优点是不需要源代码，Fuzz出的结果如果出现异常可以立即作为分析使用，对测试目标不需要有深入了解；缺点是受测试样本/模板的局限很大，造成测试的覆盖率很低，对于有校验/压缩等情况，如果Fuzz较弱，可能会做很多的无用功。

　　新进展 - 智能化测试

　　无论是动态Fuzz还是静态代码检测，突出的问题就是分析过程不够智能，没有一个学习与反馈的机制，以测试图片浏览器为例：

　　* 静态代码检测，假如我们手头有这个浏览器的源码，并且也用静态分析工具找到了一个溢出点，这时我们仍然难以得到可以触发漏洞的样本图片。

　　* 动态Fuzzing：从网上找到一些图片样本，并在样本上做少许改动进行Fuzz，这样Fuzz也未必经过溢出点，而且从覆盖率来看，fuzz后的样本和原样本也未必有太大区别。

　　因此，我们需要更智能的方法，用更智能的测试用例来获得触发样本。

　　智能化测试的简单原理如下所示

　　目前的尝试包括：

　　a) SAGE：微软的一个研究项目，基于源代码的分析工具。纯静态分析，可以利用源代码的各种有利信息(如类型信息)，利用符号执行和约束求解来对潜在漏洞触发点进行搜索。目前根据微软给出的论文，其分析结果与实际结果常常有较大差异。

　　b) SmartFuzz/CatchConv：由UC Berkeley的研究人员发起，在Linux平台上采用基于valgrind。纯动态分析，不依赖源代码。相对于zzuf等纯二进制Fuzz工具来说，效率并不高，发现新的路径能力也不够强。

　　c) EXE/KLEE：由斯坦福的研究人员发起(该研究人员也是Coverity的研究者)。基于LLVM生成的中间代码进行分析，覆盖率高，目前只能分析小范围的目标。KLEE最突出的特点，是能直接给出符号解(文件的内容，标准输入等)

　　d) Intscope：由北大研究人员发起，为纯静态检测。基于二进制代码，检查的漏洞类型单一，只有整数溢出类型。根据论文描述，已经检测出多个开源/闭源软件的整数溢出漏洞。是否能直接给出符号解目前还不是很清楚。

　　e) BitBlaze：有UC berkeley的研究人员发起。基于Qemu的动态检测，不能产生新的路径、只能动态跟踪污点数据并给出报警，适用于监控恶意软件。

　　f) Funnywei在最近几年的Xcon和VARA会议上也有一些关于动态检测的议题。

　　不足与展望

　　智能化测试虽然有很多优点，但是也有一些难以解决的问题：

　　* 关于测试规模与覆盖率：对于简单的测试对象(如数千行代码)，智能化测试可以给出所有分支的测试样本，但是对于大规模的商业代码，每个分支都测试到需要大量的资源，由于分支数量是指数级增长，因此需要一些规则对分支进行选取，会带来一定的覆盖率损失。SmartFuzz在测试的时候使用了Amazon的云计算，可见这种方法对资源的要求之大。

　　* 关于适用范围：目前的智能化测试最适合用来测试二进制格式的数据文件解析，尤其像KLEE这种工具，如果规模小，可以直接把所有的分支测试结果样本输出。但是对于文本格式的解析(如HTML/JS)或者基于OpCode的虚拟机平台(如Flash的DOABC Tag)并不适合，这是因为可能的分支数量实在太多(子子孙孙无穷匮也)，智能化测试不可能穷举出所有可能的情况。

　　* 关于检测漏洞的类型：只能以常规漏洞为主，无法检测出逻辑型的漏洞，这是因为逻辑型的漏洞通常难以用规则来定义，个体差异太大。目前这种类型的漏洞还是只能通过人工的方法代码审计或者编写静态分析规则

　　希望不久的将来，会出现更多更好的智能化测试工具供漏洞研究人员使用。