中间层驱动工作原理

《中间层驱动工作原理》由会员分享，可在线阅读，更多相关《中间层驱动工作原理（4页珍藏版）》请在金锄头文库上搜索。

1、中间层驱动工作原理中间层驱动工作原理作者：作者：noble 联系方式：联系方式：noble _shi 本文如有错误，请联系作者，谢谢。本文如有错误，请联系作者，谢谢。（1）注册表常识：）注册表常识： 1） 、设备数据库所在的注册表健值为：、设备数据库所在的注册表健值为： HKLMSYSTEMCurrentControlSetEnum ENUM 子项中是一个设备数据库，在数据库存放计算机中所有安装的，并且被系统认 识到的设备。 所有的用户（包括管理员）都不能更改 ENUM 项的内容。这是为了保护操作系统和安 装的设备的完整性。为了更改设备的设置，应该使用“设备管理器” 。 为了在设备管理器中现

2、实隐藏的，非即插即用的，以及没有连接到计算机上的所有设 备，你应该首先在命令解释器中敲入命令 set DEVMGR_SHOW_NONPRESENT_DEVICES=1，然后启动设备管理器，就可以在设备管 理器中删除和重新配置这些设备了。2） 、硬件设备类所在的注册表健值为：、硬件设备类所在的注册表健值为： HKLMSYSTEMCurrentControlSetControlClass Class 项下存放硬件设备类的配置信息。在 Class 项下的每个子项都代表一个设备类， 子项的名称使用“唯一全局标识符（GUIS） ” ，这些标识符存放该设备类的配置信息。在每 个类标识符下，还会有以 4 位

3、数命名的子项，他们代表该设备类里的具体设备，其他的配 置数据只应用于该具体设备。 如网卡的设备类是4D36E972-E325-11CE-BFC1-08002BE10318，并假定我们网卡对 应的 4 为数命名子项名为 0005。 其中 HKLMSYSTEMCurrentControlSetClass4D36E972-E325-11CE-BFC1- 08002BE103180005Linkage 中： Export：代表该设备在设备名字空间输出的设备名字。 RootDevice：代表当前设备的 GUID。中间层驱动这里有两个 GUID，第一个是自己的 GUID，第二个是该中间层驱动绑定的下层 M

4、INIPORT 的 GUID。 UpperBind：代表上层绑定它的 NDIS 协议驱动或 NDIS 中间层驱动。当某个协议驱动 绑定该 MINIPORT 设备时，则这个协议驱动的名字必须出现在 UpperBind 健值的字符串中， 否则不能进行绑定。也就是说，UpperBind 健值的字符串决定了那个协议驱动（当然也包 括中间层驱动注册的协议）和当前的 MINIPORT 设备绑定，即，它决定了 NDIS 的上下层 绑定关系。注：一般添加中间层驱动后，中间层驱动只插入到真是网卡和相应协议中间，不会插 入到虚拟网卡（如安装虚拟机后虚拟出来的网卡设备）和相应协议中间。3） 、驱动程序所在的注册表健

5、值为：、驱动程序所在的注册表健值为：HKLMSYSTEMCurrentControlSetServices ENUM 子项 通常如果某个服务下存在 ENUM 子项，表明该服务是用来控制某个设备或者设备交互 的，它的下面存放该设备的实例。用户不要去试图修改该子项的内容，因为每次系统启动 时，都会重写该子项的内容。 LINKAGE 子项值项 Bind 存放该协议所在绑定栈的最低层小端口设备实例（即 MINIPORT） 。值项 Export 存放该服务必须访问的对象，该对象必须已经安装在系统中，并且该服务能够使 用。值项 Route 指定子项 Linkage 从那里获取绑定数据。 Parameter

6、s Adapters子项 这里，我们只解释中间层驱动中该子项的意义。为此，我们假设当前我们讨论的 HKLMSYSTEMCurrentControlSetServicesXXXX 中的 XXXX 为中间层驱动。 对于中间层驱动，该子项下含有一个子项，是以我们当前中间层驱动绑定的下层 MINIPORT 设备的 GUID 命名的，在我的系统中，健值如下： 102454C2-9DB3-42A1-B4CF-6A8B67A516C0 在102454C2-9DB3-42A1-B4CF-6A8B67A516C0子项有个健，名称为 UpperBindings，该健的健值是当前中间层驱动的 MINIPORT 设备

7、名称，在我的系统中为如 下健值： Device 5BF5A311-13E4-4746-8865-339DDD6C73AF（2）中间层驱动）中间层驱动 在我们的函数 NDIS_PROTOCOL_CHARACTERISTICS- BindAdapterHandler（）中， 会调用一系列函数（如 NdisOpenProtocolConfiguration、NdisReadConfiguration）来访问注 册表，其实都是访问 ParametersAdapters102454C2-9DB3-42A1-B4CF-6A8B67A516C0子 项。 注意，函数 NDIS_PROTOCOL_CHARACT

8、ERISTICS- BindAdapterHandler（）的倒数 第二个参数是 SystemSpecific1，如果我们安装的是 XPASSTHRU，则其具体指的是如下字 符串： xfilterParametersAdapters102454C2-9DB3-42A1-B4CF-6A8B67A516C0 其中 xfilter 是 XPASSTHRU 的，而102454C2-9DB3-42A1-B4CF-6A8B67A516C0在 不同的系统中不同。 函数 NdisOpenProtocolConfiguration（）其实只是构造一个查询注册表的 RTL_QUERY _REGISTRY_TABL

9、E 结构（该结构在利用函数 RtlQueryRegistryValues（）查询注册表是使 用） 。并将这个结构封装到 NDIS_WRAPPER_CONFIGURATION_HANDLE 结构中，然后 作为 NdisOpenProtocolConfiguration（）的第二个参数返回。 其实 NdisOpenProtocolConfiguration（）构造的 RTL_QUERY_REGISTRY_TABLE 结 构的含义也就是查询 HKLMSYSTEMCurrentControlSetServices xfilterParametersAdapters 102454C2-9DB3-42A1

10、-B4CF-6A8B67A516C0下的健值（xfilter 会随着安装不同的中间层 驱动而不同，102454C2-9DB3-42A1-B4CF-6A8B67A516C0在不同的系统中不同，下面均省略这些注释） 。 函数 NdisReadConfiguration（）有两个作用，它首先修改在函数 NdisOpenProtocolConf iguration（）构造的 RTL_QUERY_REGISTRY_TABLE 结构。也就是在查询 HKLMSYSTEM CurrentControlSetServices xfilterParametersAdapters102454C2-9DB3-42A1

11、-B4CF-6A8B6 7A516C0的基础上加上了一个健，将其变成 HKLMSYSTEMCurrentControlSetServices xfilterParametersAdapters102454C2-9DB3-42A1-B4CF-6A8B67A516C0UpperBindings。 然后函数 NdisReadConfiguration（）会调用函数 RtlQueryRegistryValues（）查询新构造的 这个注册表，并将结果存储在调用函数 NdisReadConfiguration()时的第二个参数中。在我的 系统中，RtlQueryRegistryValues（）读出的这个新

12、构造的这个注册表的健值是：Device 5BF5A311-13E4-4746-8865-339DDD6C73AF（后面我们称为 RESULT1） ，它其实是我们 注册的中间层驱动（XPASSTHRU）的设备输出（其构造是DeviceGUID） 。 其实我们读出的这个中间层驱动（XPASSTHRU）的设备（即我们刚才读出的那个健 值 RESULT1）只在后面的函数 NdisIMInitializeDeviceInstanceEx（）中才用得着，并且 RESULT1 是作为函数 NdisIMInitializeDeviceInstanceEx（）的第二个参数的。 这里有个地方让人感到迷惑，即在函数

13、 BindAdapterHandler（）我们一旦调用了函数 NdisOpenAdapter（）绑定了一个下层的 MINIPORT，为什么还要调用函数 NdisIMInitializeDeviceInstanceEx（）初始化我们中间层驱动自己的 MINIPORT（因为函数 NdisIMInitializeDeviceInstanceEx（）的参数是 RESULT1，而 RESULT1 代表我们中间层驱 动的 MINIPORT） 。为了解释这个原因，我们先做如下假设。我们假设我们系统安装了一个中间层驱动（假设为 XPASSTRHU） ，在上图中， PROT-IM 和 MINIPORT-IM 分

14、别代表我们中间层驱动的协议驱动程序和小端口驱动程序， PROT-TCPIP 代表真正的协议驱动程序，MINIPORT-NIC 代表真是网卡的小端口驱动程序。当 PROT-TCPIP 需要发送数据时，会调用函数 NdisSend()，其实它会调用 MINIPORT- IM 中的发送数据函数，但是 MINIPORT-IM 和 MINIPORT-NIC 没联系，按照常规是不能 发送数据到 MINIPORT-NIC 的。但是我们可以看到 PROT-IM 是可以和 MINIPORT-NIC 互 相发送数据的，所以我们必须将 MINIPORT-IM 和 PROT-IM 联系起来。 另外当 MINIPORT

15、-NIC 需要将数据提交给 PROT-TCPIP 时，只能首先将数据提交给 PROT-IM，PROT-IM 也只能通过 MINIPORT-IM 才能和 PROT-TCPIP 联系起来。 所以必须将 PROT-IM 和 MINIPORT-IM 联系起来。有人说这两个东西都是我们中间层 驱动注册得，难道还联系不起来吗？不错，但是不管怎样你都得通过你得代码才能将他们 联系起来呀！下面我们就介绍联系得方法。 我们以 XPASSTHRU 为例，在其函数 ProtocolBindAdapter（）中，先分配了一个PROT-IMPROT-TCPIPMINIPORT-NICMINIPORT-IMNDIS_OP

16、EN_BLOCK2NDIS_OPEN_BLOCK1ADAPT 结构（这个结构是自己定义的，可根据用户的需要定义） 。当调用函数 ProtocolBindAdapter（）调用函数 NdisOpenAdapter（）进行绑定时，是以&Adapt- BindingHandle 作为函数 NdisOpenAdapter（）的第三个参数的，这样 Adapt- BindingHandle 就指向了 NDIS_OPEN_BLOCK1（注意，调用函数 NdisOpenAdapter（）时 的第三个参数会返回指向绑定以后的 NDIS_OPEN_BLOCK 指针） 。然后函数 ProtocolBindAdapter（）会调用函数 NdisIMInitializeDeviceInstanceEx（） ，该函数会进一步 调用 XPASSTHRU 的 NDIS_MINIPORT_CHARACTE