文章总结： 安全研究员利用100美元谷歌云额度构建自动化漏洞挖掘管道DeepZero，结合LangChain智能体和Ghidra从1.2万个Windows内核驱动中筛选出华硕驱动的零日漏洞。管道通过PE文件解析、反编译调度处理器、Semgrep模式匹配及Gemini2.5智能分析实现漏洞识别，并开源代码供社区使用。目前漏洞已提交华硕安全团队进行负贵披露。
综合评分： 87
文章分类： 漏洞分析,自动化工具,二进制安全,安全开发,红队
用100美元谷歌云额度，我找到了华硕驱动的零日漏洞
幻泉之洲
2026年4月8日 09:22
北京
一个安全研究员利用周末时间，把100美元的谷歌云积分变成了一个自动化漏洞挖掘管道。这个结合LangChain智能体和Ghidra的工具，从1.2万个Windows内核驱动里筛出了一个华硕驱动的零日安全漏洞。
我谷歌云账户里还剩100美元的积分，不用就浪费了。正巧有个长周末，我琢磨着干点有意思的。
结果折腾出一个能自动扫描几千个Windows内核驱动、寻找可用漏洞的管道。它专找那些能用在BYOVD攻击（自带漏洞驱动程序攻击）里的驱动。第一次对一个大驱动包进行实战扫描，它就成功标记出了一个华硕驱动的零日漏洞。
这个管道是怎么工作的
我已经不手动反转驱动了。这个管道能自动扫描成千上万的驱动，标出那些看起来能利用的。流程是这样的：
┌──────────────────────────────────────────────────┐
│ DeepZero │
│ │
│ Triage ──▶ Ghidra ──▶ Semgrep ──▶ Gemini 2.5 │
│ (.sys) (headless) (rules) (Vertex AI) │
│ │ │
│ ▼ │
│ VULNERABLE / │
│ SAFE report │
└──────────────────────────────────────────────────┘
一个有漏洞的驱动经过这个管道时，它的导入表会触发风险启发式规则，反编译出来的调度处理器会通过精确的源码映射确认漏洞。最后一步交给Gemini 2.5生成报告，之后就可以进行手动分析和验证了。
从LOLDrivers开始的基准
起点是LOLDrivers[1]数据库。里面有509个已知有漏洞的驱动和1822个哈希值。我把整个JSON文件喂给Gemini，问它这些驱动有什么共同点。
结果发现，大部分都导入了同一组危险API：比如MmMapIoSpace, MmAllocateContiguousMemory, IoAllocateMdl, MmMapLockedPages, __readmsr, __writemsr这些东西。而且它们都创建了一个用户模式可以与之通信的设备。
这成了我的过滤器。
初步筛选
我把一个包含大约1万2千个.sys文件的整个大驱动包扔给了筛选引擎。这个SDI_RUS[2]包里的每个PE文件头都会被解析，检查导入表，看它是不是内核驱动，检查它是否创建设备，如果符合LOLDrivers的模式，就给它打上标记。
那些在不同驱动文件夹里、文件名不同但实际相同的驱动，会通过SHA256哈希值去重，这样我就不用为分析同一个驱动付两次钱了。从最初的1万2千个文件里，最终有7463个独特的候选驱动被标记为“具有可访问的IOCTL接口”。然后我让管道优先处理那些明确声明兼容Windows 10/11的驱动，这样最现代的候选驱动会被先分析。
反编译核心：Ghidra
所有大约7500个候选驱动都由Ghidra[3]进行无头模式反编译。这是管道主要的计算瓶颈——每个驱动解构其调度逻辑大约需要1到3分钟，取决于复杂程度。好在用线程池并发处理，时间能大大缩短。在我机器上，扫描这个庞大的7.5K候选包一晚上就能跑完。
我写了一个Jython[4]脚本，用来找到DriverEntry，跟踪调度表分配以找到IOCTL处理器，反编译它，并深入跟踪几层内部函数。输出是驱动处理的所有IOCTL对应的、清晰可读的C语言代码。
模式匹配：Semgrep
用Semgrep[5]的自定义规则扫描反编译出来的C代码，寻找看起来像已知漏洞的模式。比如参数由用户控制的MmMapIoSpace、长度由用户控制的memcpy、没有ProbeForRead的METHOD_NEITHER等等。
完全没匹配到任何规则的驱动会被丢弃。这步很关键，因为在此之前所有步骤都是免费的。从这步开始之后，才要花钱。
智能体分析：Gemini 2.5
幸存下来的驱动会被发送到Vertex AI[6]上的Gemini 2.5 Pro[7]。
整个管道深度整合了LangChain DeepAgents[8]框架。如果你想了解技术细节，可以在DeepZero Pipeline源代码里找到这个基于Python的筛选器、Ghidra提取脚本、Semgrep规则和LangChain智能体推理循环。
智能体有两个工具：
- triage_drivers，运行PE分析和导入表评分
- batch_analyze_candidates，驱动Ghidra + Semgrep流程
对于每个驱动，大语言模型会收到完整的反编译调度处理器代码，外加Semgrep的发现结果。它会追踪从IOCTL输入缓冲区到危险接收点的数据流，然后判断到底是真的可利用，还是只是个误报。它会为每个驱动输出一份报告，标明[VULNERABLE]或[SAFE]，并附上证据。
花了多少钱
分析每个驱动会消耗5万到20万个tokens，取决于调度处理器有多大。按Vertex AI的定价，这大约是每个驱动2-3美元。我首次运行得到了9份报告，花了大概20美元。这里要说明一下，这个价格反映的是管道在实施任何优化之前的成本。在实际优化了提示格式化、上下文裁剪和提示缓存之后，现在的成本已经低很多了，早期的数字已经不再反映当前应有的成本。
大语言模型分析之前的管道都在本地运行，不花钱。所以整个游戏的关键在于，确保只有真正的候选对象才能进入这个昂贵的步骤。
管道之后的手动工作
管道会给你一份针对每个驱动的报告，说明是VULNERABLE还是SAFE，并给出证据。但这还没完。
我仍然手动检查了每一份标记为“存在漏洞”的报告，确保数据流的走向没问题，确认大语言模型没有臆造出一个根本不存在的漏洞。
对于那些被标记为真实零日漏洞的报告，内容非常清晰。大语言模型通过追踪Ghidra的输出，在数学上证明了数据从IOCTL用户缓冲区流入危险接收点的路径，逻辑严谨。我通过WinDbg连接到测试虚拟机，动态验证了这个漏洞，接下来就需要一个能工作的概念验证程序。
我把反编译出来的调度处理器代码和漏洞报告交给Claude 3.7[9]，让它写一个概念验证脚本。它生成了C代码，我编译好，在我Windows 11测试镜像里加载了那个驱动，运行脚本，确认了漏洞利用成功。
整个管道用Python[10]写成，用pefile[11]进行PE文件解析，用Ghidra无头模式进行反编译，用Semgrep做模式匹配，把一切都串了起来。
所以完整的工作流是：管道找到候选漏洞 -> 我手动验证报告 -> Claude写出底层的概念验证程序 -> 我在真实硬件上进行测试。
下一步
这个管道在华硕的一个驱动里找到了一个干净的零日漏洞。由于目前正在与华硕产品安全事件响应团队进行负责任的漏洞披露流程，在华硕发布修复补丁之前，我不会透露具体的驱动名称、IOCTL细节或概念验证代码。
不过，如果你想用这个工具在自己的硬件或数据库里去挖掘漏洞，我已经把整个DeepZero管道的代码开源在GitHub上了。
项目地址在这里：https://github.com/416rehman/deepzero。
时间线
| 日期 | 事件 |
| — | — |
| 2026-04-06 | 发现漏洞 |
| 2026-04-06 | 在Windows 11 24H2上匿名确认了概念验证程序 |
| 2026-04-06 | 报告提交给华硕产品安全事件响应团队 |
参考资料
[1] https://www.loldrivers.io/
[2] https://sdi-tool.org/download/
[3] https://ghidra-sre.org/
[4] https://www.jython.org/
[5] https://semgrep.dev/
[6] https://cloud.google.com/vertex-ai
[7] https://deepmind.google/technologies/gemini/
[8] https://github.com/langchain-ai/deepagents
[9] https://claude.ai/
[10] https://www.python.org/
[11] https://github.com/erocarrera/pefile
[12] https://blog.ahmadz.ai/automated-deepagents-langchain-pipeline-for-zero-days/
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：幻泉之洲 《用100美元谷歌云额度，我找到了华硕驱动的零日漏洞》