驱动入门科普从WRK理解IRPIRPStack之实践篇-看雪安全论坛.DOCVIP

驱动入门科普：从WRK理解IRP IRP Stack之实践篇 By AntBean 昨天通过WRK的代码对IRP和IRP Stack的概念作出了一个比较深的理解。但显然这样还不够。对程序员而言，没有比光说不练更坏的恶习了。这次，我们将通过一个文件过滤驱动来实现文件保护。 恩，是的，我们想写一个文件过滤驱动。而且我们也知道所谓文件过滤驱动也就是将自己的设备加到要过滤的设备栈的最顶端。说白了不就是IoAttachDeviceToDeviceStack嘛。 我们准备动手了，可是问题来了，我到底该Attach到哪个Device Stack上呢？ 楚狂人在文件过滤驱动二一书中提到，就是要Attach到相应的Volume上。我晕了。为啥子就是要Attach到相应的Volume上了？谁说的？即使Attach到相应的Volume上了，获得到的IRP到底都有啥参数呢，我该怎么检查获得的IRP以决定是否拒绝该IRP呢？难道我就只能对着他的代码从头敲到尾么？ 如果我知道CreateFile的整个操作流程，显然CreateFile最终都是分配了一个IRP发送给文件系统的，那么我不就知道了该Attach的Device Stack么？ CreateFile的整个流程 与 文件过滤驱动的Attach对象问题 显然，我们知道CreateFile在内核中调用的是NtCreateFile。 直接阅读NtCreateFile，可以看到NtCreateFile的请求最终是通过ObOpenObjectByName实现的。这里就不贴代码了。而最难找的应该是ObOpenObjectByName中到底是哪个函数调用实现的创建IRP并发送IRP。 在ObOpenObjectByName中，对象管理器会获得该Name对应的Object，之后它会调用该Object的Parse Routine，在Parse Routine中完成IRP的构造和发送。这一点你可以在深入解析windows操作系统一书的系统机制一章中的对象管理器获得比较深的了解。 也就是说，当系统获得C:\\a.txt这个名字的时候，它调用ObOpenObjectByName打开该名称对应的对象。而ObOpenObjectByName则是调用ObpLookupObjectName查找该名字对应的对象，在ObpLookupObjectName中，调用该对象的Parse Routine。 如下： 正如深入解析windows操作系统一书中提到的，这里对对象的管理类似于C++。这些对象都有一个差不多的基类，该基类定义了统一的接口方法，有Open，Close，Delete，Query name和Parse等。 突然，我们跟踪的线索断掉了，我们得找到文件对象的Parse Routine到底是啥。这样我们才能知道具体的IRP创建和目的设备是啥。 在WRK中的一番搜索，得到了IopParseFile即文件对象的Parse Routine。 在IopParseFile中，通过IoGetRelatedDeviceObject获得该Parse Object对应的DeviceObject，然后调用IopParseDevice完成整个操作。 当你读到IopParseDevice时，你震惊了。。。你想要的直接分配IRP的代码不就在这个地方么？ 图一 看完了这些，你想要的都在这儿了，只是那个目的Device还是不大清楚。静态分析只能做到这个地步了，下面要干啥，常在看雪论坛混的你懂的。 上windbg，在该函数中下断点，看看断下来是目标Device到底是啥，是\\Driver\\FtDisk的对象\\Device\\HarddiskVolumeX呢？还是文件系统\\FileSystem\\xx的unname对象呢？ 下面是我在系统登陆前在windbg中下的一个断点的情况。 到底那个Driver是啥，你调试下就知道了。 实际上是Attach到相应的文件系统创建的对象的设备栈上。 解决了Attach的目的设备栈的问题和处理参数问题，下面到了完成整个文件过滤驱动了。 文件过滤驱动\\Device\\HarddiskVolumeX 与 \\FileSystem\\xx的unname对象 我们已经知道了，我们要Attach到\\FileSystem\\xx的unname对象上，那么我们的IRP到了该\\FileSystem\\xx对象后，它最终还是要转化成对卷的IO。可是它怎么知道应该将自己处理过的IRP发送给哪个卷呢？换句话说，\\Device\\HarddiskVolumeX和\\FileSystem\\xx的unname对象是怎样联系起来的？ 老习惯，看代码。首先我们知道硬盘上的一个分区被文件系统识别的过程叫Mount。实际上是给文件系统控制对象发送