第7章　串口的过滤

7.1　过滤的概念

有的公司采用技术手段禁止员工使用U盘，是为了防止员工通过U盘将敏感数据带出公司，本质上是禁止敏感数据通过USB接口流出。USB接口比较复杂，本章讨论一个类似的但是简单得多的设备：串口。要禁止使用串口非常容易（给串口贴上封条，或者写一个简单的程序始终占用串口），但是要区别处理，允许非机密数据流出，而禁止机密数据，或者要记录串口上流过的数据，然而又不影响其他的程序使用串口，就有一定难度了。在这一章中，我们通过给串口设备增加一个过滤层来实现这个功能。

而在下一章中，我们则把目标转移到键盘，除了过滤，我们将进一步探讨是否有方法保证从键盘输入的密码不被隐藏的黑客软件通过类似的过滤方式截取。

在Windows系统上与安全软件相关的驱动开发过程中，“过滤”（Flter）是极其重要的一个概念。过滤是在不影响上层和下层接口的情况下，在Windows系统内核中加入新的层，从而不需要修改上层的软件或者下层的真实驱动程序，就加入了新的功能。

举一个比较容易理解的例子：实时监控的反病毒程序。任何高层软件或者Windows的文件系统都没有考虑过应该什么时候去检查文件中是否含有某个病毒的特征码，实际上也不应该要求某个软件或者Windows的文件系统去考虑这些。反病毒程序需要在不改变文件系统上层和下层接口的情况下，在中间加入一个过滤层，这样就可以在上层软件读取文件、下层驱动提供数据时，对这些数据进行扫描，看其中是否含有某个病毒的特征码。这是一个很典型的过滤过程。

本章之所以从串口过滤出发，是因为串口在Windows中是非常简单的设备。对于一个安全软件来说，串口过滤似乎没有什么意义。不过有一些特殊场合的计算机，要求防止“信息外泄”，或者需要知道“哪些信息外泄”。除了网络和可移动存储设备，有时串口也在考虑的范围之内。

此外，使用这种方法也可以绑定键盘，从而截获用户的击键。

7.1.1　设备绑定的内核API之一

进行过滤的最主要方法是对一个设备对象（Device Object）进行绑定。读者可以想象一下，Windows系统之所以可以运作，是因为Windows中已经存在许多提供了各种功能的设备对象。这些设备对象接收请求，并完成实际硬件的功能。

我们可以首先认为：一个真实的设备对应一个设备对象（虽然实际的对应关系可能复杂得多）。通过编程可以生成一个虚拟的设备对象，并“绑定”（Attach）在一个真实的设备上。一旦绑定，则本来操作系统发送给真实设备的请求，就会首先发送到这个虚拟设备上。

下面结合代码进行讲解。读者可能希望编译执行这些代码，初学者请先阅读本书第1章，以学会如何安装开发环境、编译代码和调试程序。

在WDK中，有多个内核API能实现绑定功能。下面是其中一个函数的原型。

IoAttachDevice的参数如下：

SourceDevice是调用者生成的用来过滤的虚拟设备；而TargetDevice是要被绑定的目标设备。请注意这里的TargetDevice并不是一个PDEVICE_OBJECT（DEVICE_OBJECT是设备对象的数据结构，以P开头的是其指针），而是一个字符串（在驱动开发中字符串用UNICODE_STRING来表示）。实际上，这个字符串是要被绑定的设备的名字。

Windows中许多设备对象是有名字的，但并不是所有的设备对象都有名字。只有有名字的设备，才能用这个内核API进行绑定。

这里有一个疑问：假设这个函数绑定一个名字所对应的设备，那么如果这个设备已经被其他的设备绑定了，会怎么样呢？

如果一个设备被其他的设备绑定了，它们在一起的一组设备，被称为设备栈（之所以称为栈，是由于和请求的传递方式有关）。实际上，IoAttachDevice总是会绑定设备栈上最顶层的那个设备。

AttachedDevice是一个用来返回的二级指针。绑定成功后，被绑定的设备指针被返回到这个地址。

下面这个例子绑定串口1。之所以这里绑定很方便，是因为在Windows中，串口设备是有固定名字的。第一个串口名字为“\Device\Serial0”，第二个为“\Device\Serial1”，依次类推。请注意实际编码时C语言中的“\”要写成“\\”。

当然，试图执行这段代码的读者可能会发现，这里没有提供如何生成一个过滤设备的代码。在接下来的第二个API介绍之后，读者会看到完整的例子。

7.1.2　设备绑定的内核API之二

前面已经提到了并不是所有的设备都有名字，所以依靠IoAttachDevice无法绑定没有名字的设备。另外还有两个API：一个是IoAttachDeviceToDeviceStack，另一个是IoAttachDeviceToDeviceStackSafe。这两个函数的功能一样，都是根据设备对象的指针（而不是名字）进行绑定；区别是IoAttachDevice ToDeviceStackSafe更加安全，而且只有在Windows 2000 SP4和Windows XP以上的系统中才有。一般都使用IoAttachDeviceToDeviceStackSafe，但是当试图兼容较低版本的Windows 2000时，应该使用IoAttachDeviceToDeviceStack。

和第一个API类似，只是TargetDevice换成了一个指针。另外，AttachedToDeviceObject同样也是返回最终被绑定的设备，实际上也就是绑定之前设备栈上最顶端的那个设备。

在Windows 2000下应该使用另外一个函数IoAttachDeviceToDeviceStack，这个函数除了缺少最后一个参数（实际上放到返回值里了），其他的和IoAttachDeviceToDeviceStackSafe函数相同。

这个函数返回了最终被绑定的设备指针，这也就导致了它不能返回一个明确的错误码。但是如果为NULL，则表示绑定失败了。

读到这里，读者一定迫不及待地想试试如何绑定一个串口了，但问题是，这里还没有介绍如何打开串口设备（从名字获得设备对象指针）和如何生成一个串口。下面就给出绑定的完整例子。

7.1.3　生成过滤设备并绑定

在绑定一个设备之前，先要知道如何生成一个用于过滤的设备。函数IoCreateDevice被用于生成过滤设备：

这个函数看上去很复杂，但是目前使用时，还无须了解太多。DriverObject是本驱动的驱动对象。这个指针是系统提供的，从DriverEntry中传入，在最后完整的例子中再解释。DeviceExtensionSize是设备扩展，读者请先简单地传入0。DeviceName是设备名字。有一个规则是：过滤设备一般不需要名称，所以传入NULL即可。DeviceType是设备类型，保持和被绑定的设备类型一致即可。DeviceCharacteristics是设备特征，在生成设备对象时笔者总是凭经验直接填0，然后看是否排斥，选择FALSE。

值得注意的是，在绑定一个设备之前，应该把这个设备对象的多个子域设置成和要绑定的目标对象一致，包括标志和特征。下面是一个示例的函数，这个函数可以生成一个设备，然后绑定在另一个设备上。

7.1.4　从名字获得设备对象

在知道一个设备名字的情况下，使用函数IoGetDeviceObjectPointer可以获得这个设备对象的指针。这个函数的原型如下：

其中的ObjectName就是设备的名字。DesiredAccess是期望访问的权限。在实际使用时可以不顾忌那么多，直接填写FILE_ALL_ACCESS即可。FileObject是一个返回参数，即在获得这个设备对象的同时会得到一个文件对象（File Object）。就打开串口设备这件事而言，这个文件对象并没有什么用处。但是必须注意，在使用该函数之后必须把这个文件对象“解除引用”；否则会引起内存泄漏（请注意后面的代码）。

要得到的设备对象就返回在参数DeviceObject中了。示例如下：

7.1.5　绑定所有串口

计算机上到底有多少个串口？笔者提供不出很好的判定方法，只能依次去打开串口0、1、2、3…目前还不知道如果串口2不存在，是否说明串口3、4…肯定不存在。由于没有依据，所以只好全部测试一次。不过有一个好处是，串口是焊死在计算机上的，很少见到能“即插即用”的串口（但是有一种用USB口来虚拟串口的设备，不知道会不会产生动态生成串口的效果，在这里先忽略这一点），那么绑定所有串口，就只需要做一次就可以了，不用去动态地追踪串口的诞生与消亡。

下面是一个简单的函数，实现了绑定本机上所有串口的功能。这个函数用到了前面提供的ccpOpenCom和ccpAttachDevice两个函数。

为了后面的过滤，这里必须把过滤设备和被绑定的设备（后面暂且称为真实设备吧，虽然这些设备未必真实）的设备对象指针保存起来。下面的代码使用两个数组保存。数组应该多大，取决于一台计算机上最多能有多少个串口。读者应该去查阅IBM PC标准，这里笔者随意地写一个自认为足够大的数字。

没有必要关心这个绑定是否成功，就算失败了，看一下s_fltobj即可。在这个数组中不为NULL的成员表示已经绑定了，为NULL的成员则是没有绑定或者绑定失败的。这个函数需要一个DRIVER_OBJECT的指针，这是本驱动的驱动对象，是系统在DriverEntry中传入的。