Windows Filesystem Filter Driver

Reference: Http://www.codeproject.com/Articles/43586/File-System-Filter-Driver-Tutorial

Key points:

To perform attaching, we create a new device object with the device extension (call IoCreateDevice ) and the propagate device object Flags from the device object we is trying to attach to ( DO_BUFFERED_IO , DO_DIRECT_IO , FILE_DEVICE_SECURE_OPEN ). Then, we call in a loop with a delay in the case of IoAttachDeviceToDeviceStackSafe failure. It is possible for this attachment request to fail because the device object have not finished initialization. This situation can occur if we try to mount the filter is loaded as the volume only. When attaching is finished, we save the ' attached to ' device object to the device extension and clear the DO_DEVICE_INITIALIZING flag. The device extension is shown below:

First create a hookdevice that specifies the driver that we are working on to serve it;

Then use Ioattachdevicebypointer or IoAttachDeviceToDeviceStack to place the Hookdevice on top of the dev stack where TargetDevice is located, so that when an IRP comes in, Will go through the Hookdevice first, that is, call our driver for processing, and then passed to the next layer of driver for processing.

　　

The following example illustrates

Kd>!drvobj Atapidriver Object (867ce610) is for: \driver\atapidriver Extension List: (ID, addr) (F744e8d8 867d2430) 
   device Object list:86758b00  8675ab00  86790b00  

　　

kd> DT _driver_object 0x867ce610ntdll!_driver_object   +0x000 Type             : 0n4   +0x002 Size             : 0n168   + 0x004 deviceobject     : 0x86758b00 _device_object   +0x008 Flags            : 0x12   +0x00c driverstart      : 0xf743a000 void   +0x010 driversize       : 0x17480   +0x014 driversection    : 0x867ebbc0 void   +0x018 Driverextension  : 0x867ce6b8 _driver_extension   +0x01c drivername       : _unicode_string "\driver\atapi"   +0x024 hardwaredatabase:0x80670260 _unicode_string "\registry\machine\hardware\description\system"   + 0x028 fastiodispatch   : (null)    +0x02c driverinit       : 0xf744f5f7     long  atapi! Gsdriverentry+0   +0x030 driverstartio    : 0xf74417c6     void  atapi! Ideportstartio+0   +0x034 driverunload     : 0xf744b204     void  atapi! Ideportunload+0   +0x038 majorfunction    : [] 0xf7444572     long  atapi! Ideportalwaysstatussuccessirp+0

　　

The

Indicates that the driver name is APAPI, which provides a total of 5 device services, so let's take a look at one of the first device object

kd> DT _device_object 0x86758b00ntdll!_device_object +0x000 type:0n3 +0x002 size:0x234 +0x004 referencecount:0n0 +0x008 driverobject:0x867ce610 _driver_object +0x00c nextdevice:0x8675ab             XX _device_object +0x010 attacheddevice:0x8678f030 _device_object +0x014 currentirp: (null) +0x018 Timer : (null) +0x01c flags:0x5050 +0x020 characteristics:0x101 +0x024 Vpb: (nu ll) +0x028 Deviceextension:0x86758bb8 Void +0x02c devicetype:2 +0x030 stacksize:1 ' +0x034 Q              Ueue: __unnamed +0x05c alignmentrequirement:1 +0x060 devicequeue: _kdevice_queue +0x074 Dpc : _kdpc +0x094 activethreadcount:0 +0x098 securitydescriptor:0xe100cf70 Void +0x09c devicelock: _kevent +0x0ac sectorsize:0 +0x0ae spare1:1 +0x0b0 deviceobjectextension:0x86758d38 _DEVOBJ_EX Tension +0X0B4 ReserveD: (NULL)  

　　

+0x008 driverobject:0x867ce610 _driver_object "point to the DRIVER for which you are serving, that is, ATAPI"
+0x00c nextdevice:0x8675ab00 _device_object "points to the next item in the DEVICE list in ATAPI and is validated in!drvobj ATAPI results"
+0x010 attacheddevice:0x8678f030 _device_object "points to the next item in the device stack where the device OBJECT is located, or more closely to the top level"

We've been traversing the device stack down the path:

kd> DT _device_object 0x8678f030 ntdll!_device_object +0x000 type:0n3 +0x002 size:0x47c    +0x004 referencecount:0n0 +0x008 driverobject:0x867d0970 _driver_object +0x00c nextdevice: (NULL)   +0x010 Attacheddevice: (null) +0x014 CURRENTIRP: (null) +0x018 timer:0x8679a548 _io_timer +0x01c flags:0x2050 +0x020 characteristics:0x101 +0x024 vpb:0x867bebe0 _VPB +0x028            Deviceextension:0x8678f0e8 Void +0x02c devicetype:2 +0x030 stacksize:3 ' +0x034 Queue : __unnamed +0x05c alignmentrequirement:1 +0x060 devicequeue: _kdevice_queue +0x074 Dpc: _KD PC +0x094 activethreadcount:0 +0x098 securitydescriptor:0xe100cf70 Void +0x09c devicelock: _KEVENT +0x0 AC sectorsize:0 +0x0ae spare1:0 +0x0b0 deviceobjectextension:0x8678f4b0 _devobj_extension +0x0 B4 Reserved: (nUll  

kd>!devstack 0x8678f030   ! Devobj   ! Drvobj            ! Devext   objectname> 8678f030  \driver\cdrom      8678f0e8  CdRom0  86758b00  \driver\atapi      86758bb8  idedevicep1t0l0-17! Devnode 8678F9B8:  deviceinst is "ide\cdromvbox_cd-rom_____________________________1.0_____\ 42562d3231303037333036372020202020202020 "  ServiceName is" cdrom "

　　

As can be seen, the device stack is actually a single-linked list that is concatenated by the Attacheddevice pointer in _device_object, and when IoAttachDeviceToDeviceStack is called, the device Add our own device object to the top of the stack.

Then, when an IRP comes over, regardless of which device object in this device object is used as a parameter, it is passed to the driver of the top device of the stack.

Therefore, this is why IoAttachDeviceToDeviceStack can create the file system filter driver.

　　

Windows Filesystem Filter Driver