第二部分
我们已经看到了问题的根源。设备驱动并不直接与 Kernel Streaming API（以下简称
KSA）相关联，可以认为它是个“陌生”设备。使用这一术语能够更全面的解释设备驱动并
不是通过 KSA 来创建或者注册的，因此KSA并不会意识到它的存在。这些“陌生”设备与其
它KSA关联设备共享着同一驱动对象，因此默认的KSA IRP handler存在着潜在的漏洞。
场景 1
在驱动编程中的一个常见惯例就是创建设备为用户程序提供接口，这并没有什么新奇
的，但当我们编写WDM音频驱动时情况又会如何呢？先通过KSA 初始化驱动对象和设备，以
保证安装的 IRP handler能够完整，即使独一无二，也能够与KSA相兼容。如果为用户层服
务创建附加设备，并且未向KSA通知此事，那么也可能存在潜在的攻击风险。
场景 2
一些相对比较旧的声卡包含有 Gameport 接口，Game Port 连接器通过操纵杆和其它外
围设备来使用的。

在当今，USB接口是各类现在游戏硬件的首选，因此微软已在Windows Vista上中止对
Game port的支持。但它一直保持着“用户友好性不兼容”的角色，为的就是避免与旧硬件
相冲突。

Vista gameport.inf 
; gameport.inf - Hooks up known gameports with a NULL service.
;   Displays a name so the user can understand the device
;   is not supported out of the box.
; This avoids the '!' in device manager.
;;
Copyright (C) Microsoft Corporation. All rights reserved.

WDM 一直保持着稳定性，向后兼容以及结构一致。因为这样，即使是一个8 年前的写的
驱动，也依然可以在Windows版本下正常运行。但是，一些WDM 驱动运行在Windows Vista  

上还需面临着其它各种问题。Game port不再被其支持，因此这也就导致了一些重要的改变，
这些改变不是发生在驱动行为上，而是在驱动暴露的接口上。看下图3以方便理解这一点：   

 
在蓝色区域“Microsoft Kernel Streaming Related Area”中可以找到所有设备，而
操作系统可识别出声卡，并且FDO(s)驱动将通过与PDOs交互的KSA来创建。假设这些设备
均能够被正确地初始化，因为我们没有理由不这样做（若驱动未以正确的方式绑定到 KS 将
无法正常运行）。换句话说，“Third-Party Driver Area”包括了我们先前提到的“陌生”
设备。启动顺序如下：
Vista 先前的版本
1、 PnP管理器向驱动发送一个Query Relations请求，该驱动用于创建上方的GamePort PDO
以接收请求；
2、 PnP 加载 gameenum.sys，然后创建一个匿名 FDO 与 GamePort PDO 相交互，这一 FDO 附
加到栈上。因此从用户层访问（原始 IRP 处理函数）PDO 是不可能的，尽管 PDO 是一个
已命名的设备。
Windows Vista
1、 PnP管理器向驱动发送一个Query Relations请求，该驱动用于创建上方的GamePort PDO
以接收请求；
2、 PnP 并没有创建任何FDO与GamePort PDO相交互，因为它并不支持GamePort，所以 PDO
一直曝露给用户程序；
3、 如果开发者没有使用正确的方法将IRPs路由给驱动，那么我们可以安装的KSA IRP处

4、 理函数中引用可控制的FsContext指针，使其在内核中执行任意代码；