大概在2013年，Google开始改变内核漏洞挖掘领域的规矩。

为了更好地保护用户，它招聘全球顶尖安全人才组建Project Zero（简称P0）安全团队，去寻找互联网上各种流行软件的安全漏洞。

P0发现的部分漏洞

作为全球最流行软件，Windows自然是P0的头号目标。当时，Windows时常爆出零日漏洞被野外利用，还有众多情报机构虎视眈眈，它的“修修补补”难以对抗国家级别的攻击对手。P0另辟蹊径，使用仿真、Fuzz技术和机器集群打造出漏洞挖掘系统Bochspwn，用机器算力替代人力对系统薄弱点进行集中分析，近5年时间不完全统计向微软报告了近百个Windows内核高危漏洞。其中不少漏洞修复周期较长，还引发了微软和Google关于漏洞披露方面的口水大战。

Bochspwn被认为是Google P0团队的内核零日漏洞挖掘神器。和其它辅助分析工具相比，Bochspwn在操作系统下层监听内存变化，能发现更全面的错误异常信息，因此也更容易找到漏洞。

在Bochspwn之后，业内其它团队也有尝试开发基于虚拟化技术的Windows内核漏洞挖掘工具，不过有成效的不多，360冰刃实验室今年8月公布的DigTool算是里边的佼佼者。DigTool利用硬件虚拟化技术监控内存错误数据，在功能验证阶段已经找出20个Windows内核漏洞、41个杀毒厂商驱动漏洞。

本文将以Bochspwn、Digtool两款工具为主线，介绍自动化漏洞挖掘工具的最新进展。

虚拟化监控

要做自动化漏洞挖掘工具，首先要考虑如何实现内存监控。2012年，在Bochspwn的技术栈选型上，P0团队面临三种选择：

1、修改系统异常处理，利用页面访问权限截取内存引用。该方法对系统内核改动太大，移植很不方便。不过它具备最佳性能优势，并可以在物理硬件层面进行监听。

2、使用轻量级hypervisor去截取内存，侵入性较小，不用对内核做太多修改。但要开发一套具备广泛日志记录功能的hypervisor复杂且耗时。

3、使用CPU仿真虚拟机来运行操作系统，在软件层面监听内存。这样做性能开销非常大，无法测试少数硬件的内核模块；优点是工作量最小、上手最简单快速。

权衡所有优缺点后，P0决定采用第三种方案，使用开源软件Bochs x86仿真器开发了全系统内存监控工具Bochspwn。他们当时表示：“CPU仿真方案具备压倒性的优势”。考虑到那时P0团队应该刚刚筹建，人员不足，这句话大概能理解。

2013年Bochspwn初见成效、发现一大堆Windows内核漏洞后， @j00ru和@gynvael反思，Bochspwn实在太慢太卡了，要给运行时的完整操作系统做分析，使得它很多时候都无法交互。尽管可以对CPU占用再优化，但Bochs本身的低效率让这种优化很难有意义。

另一种选择是，放弃CPU仿真方案，改用Intel和AMD的虚拟化技术来控制操作系统，做轻量级hypervisor。同年8月，@j00ru在BlackHat上公布HyperPwn，一个把操作系统放进hypervisor里作为VMM运行的项目，很遗憾由于在内存处理上碰到难题，这个项目当时没能完成，后来竟没了声音。

@j00ru未竟的项目，在2017年被@PJF（潘剑锋）实现。

@PJF是360冰刃实验室负责人、知名反病毒内核软件冰刃作者，他于2014年开始构思Digtool，使用硬件虚拟化技术（Intel PT）打造漏洞检测框架，2017年初步完成亮相时，同样刷了一大波Windows内核漏洞，并且介绍论文还投中四大国际学术会议之一的USENIX Security。

Digtool的架构

Digtool漏洞检测部分最大亮点在于：@PJF没有用任何现有虚拟机或仿真器软件方案，而是近乎奇迹地独立实现了一套专用于内存监控的轻量级hypervisor。

他认为现有方案都不够完美，例如Driver Verifier没有源码，AddressSanitizer是编译时工具，Patching异常处理会影响系统稳定且无法移植，Pin、DynamoRIO之类难以在内核态运行，PEMU没有内存监控模块，Xenpwn只能跟踪物理内存地址，Bochspwn性能太差…

独立实现hypervisor层监控的Digtool优势明显，支持闭源软件、对系统稳定性没有损伤、性能极佳、可移植性好，并且可以获得最全面的内存监控数据。@PJF说：“Bochspwn跑一次可能要一两天，而Digtool只需要一两小时。”

漏洞发现

现盘古首席科学家王铁磊曾总结过漏洞挖掘研究现状，他把漏洞发现技术分为主动挖掘和被动发现，主动挖掘有手工分析、动态分析、静态分析三类，其中以模糊测试（fuzz）为代表的动态漏洞挖掘技术已经被业界广泛接受，成为软件安全测试的重要手段。

在Github上搜索fuzz，有八千多个项目，里边有大量知名fuzz软件和案例，但最流行的fuzz软件并不在这里，而是在一个个人网站上。它叫american fuzzy lop（AFL），由全球最有影响力的安全专家之一@lcamtuf 打造，是现在许多二进制白帽子fuzz从入门到精通的必备软件。

比如几个月前，腾讯安全研究员@lcatro 使用AFL和网上开源测试样本对图片处理库ImageMagick进行fuzzing，很快就收获20个CVE漏洞。@lcatro 的内存监控工具是AddressSanitizer，上文提过它的缺点，需要被测软件源码在编译时引入才能工作，对Windows等闭源软件没有价值。

Fuzzing ImageMagick的具体效果

回到Bochspwn上来，作为Google P0神器，它最开始的作用是安全研究员发现某类攻击面或姿势后，在内核里对该类漏洞进行“清扫”（fuzz）。2013年首次亮相时，Bochspwn在Windows内核、驱动程序里找到50个double fetch漏洞，对这类漏洞的宣传科普起到了重要作用。

两年后，字体处理漏洞泛滥现象严重，包括超级木马Duqu、comex版iOS越狱、几次Pwn2own比赛都使用了字体处理零日漏洞，安全会议上随处可见相关讨论。从用户安全角度来考虑，情况非常不利。P0团队希望解决这个问题，他们投入数千台机器，先后三次对Windows内核字体部分进行fuzz，整个过程特别复杂，不同阶段、目标、文件格式需要单独配置/定制，最后一年时间发现了16个字体处理严重漏洞，为Windows字体处理安全改进做出了很大贡献。

字体fuzz轻车熟路后，2016年年底P0又盯上Windows文本编码库Uniscribe。Uniscribe此前鲜有人关注，但跑过一轮Bochspwn后“名声”大涨，爆出29个漏洞。Uniscribe的成果表明，fuzz是一种通用性技术，其大部分组件对不同目标都可以重用。

和战果累累的Bochspwn相比，Digtool稍显稚嫩，它的优势是在通用性、性能、效率上做得更好。

Bochspwn公开信息显示支持识别double fetch、内核堆栈泄漏两类漏洞（可能有所保留），Digtool则支持UNPROBE、TOCTTOU、UAF、OOB、参数未检查、信息泄漏六种漏洞识别，并且很快将支持第七种未初始化堆栈；性能方面前文说过；效率上则是前两方面带来的综合差距，Digtool有着碾压式性能体验，可以在运行正常工作任务的同时监控内存、分析识别漏洞，这是Bochspwn所无法做到的。

8月参加USENIX Security会议前，Digtool牛刀小试，在Windows上发现20个内核漏洞、5款杀毒软件上发现41个驱动漏洞。因为监控和分析组件做得足够好，Digtool甚至不用专门的fuzz，仅靠系统运行任务所产生的代码覆盖也能发现漏洞。

最后

经过五年开发和完善，Bochspwn已经成为漏洞挖掘领域的一面旗帜，它代表“人+机器”模式当前所能达到的最高水准。

Digtool还不够成熟，它需要切实的成果来展示证明自己，而它的潜力显然不止于此，未来将是Bochspwn强有力的挑战者和超越者。

限于篇幅，本文仅介绍了Bochspwn、Digtool的部分模块，以后有机会我们会展开讲讲里边的其它部分。

参考资料

嘶吼对@PJF的采访

Digtool: A Virtualization-Based Framework for Detecting Kernel Vulnerabilities（Jianfeng Pan, Guanglu Yan, and Xiaocao Fan, IceSword Lab）

Identifying and Exploiting Windows Kernel Race Conditions via Memory Access Patterns（Mateusz Jurczyk, Gynvael Coldwind）

A year of Windows kernel font fuzzing #1: the results（Mateusz Jurczyk of Google Project Zero）

A year of Windows kernel font fuzzing #2: the techniques（Mateusz Jurczyk of Google Project Zero）

Notes on Windows Uniscribe Fuzzing（Mateusz Jurczyk of Google Project Zero）

Announcing Bochspwn Reloaded and my REcon Montreal 2017 slides

面向二进制程序的漏洞挖掘关键技术研究（王铁磊）

自动化挖掘 windows 内核信息泄漏漏洞（fanxiaocao(@TinySecEx) and @pjf_ of IceSword Lab）