none
KMDF: Filter driver, attach to any device in runtime RRS feed

  • Question

  • Hi, everybody.

    For the filter drivers on the WDM technology there was a possibility of attach the filter driver to the desirable device in runtime and detach from it.

    For example, earlier I could by means of WDM in the filter driver create some control-device, and through some MY_IOCTL code to command to it to attach to the desirable device (for example to COM port or to the specific USB device) or detach from it and/or attach to other device and so forth, i.e. on runtime!

    So, I need to solve the problem of creation of some application (something like a sniffer) by means of which I could do attach to any device of specific type (for example to COM ports, etc.) and to catch all I/O calls which go to target device (e.g. COM port) and to display them.

    It "easy" could be made on WDM, on a internet there are many examples, etc, But I want to make it by means of KMDF!

    Q: Whether it is possible to solve this problem on KMDF: and if YES - that please what is way? if is NOT - that why?

    Best regards, Denis

    Friday, August 30, 2013 8:08 AM

Answers

  • First the examples I have seen doing this are not very good.  The claim you can detach is bogus since it is only true if the stack of drivers above you does not grow.  On the attaching side, the situation can be as bad since you are attaching at a random point (for instance try doing this on a disk).

    KMDF does not support this model, what you need to do instead is have the driver's INF indicate the classes it want to support.  Now this is reasonable, since if you are going to say be a sniffer you need to know something about the device classes you are going to sniff.   Then you can ignore the calls as they go through if the class is not being sniffed.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Friday, August 30, 2013 11:26 AM

All replies

  • First the examples I have seen doing this are not very good.  The claim you can detach is bogus since it is only true if the stack of drivers above you does not grow.  On the attaching side, the situation can be as bad since you are attaching at a random point (for instance try doing this on a disk).

    KMDF does not support this model, what you need to do instead is have the driver's INF indicate the classes it want to support.  Now this is reasonable, since if you are going to say be a sniffer you need to know something about the device classes you are going to sniff.   Then you can ignore the calls as they go through if the class is not being sniffed.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Friday, August 30, 2013 11:26 AM
  • Dear Don

    I am also start to write  filter driver in KMDF.  my aim is to catch the all I/o  calls in usb device. I am new to KMDF and WDM. this is my hobby project to learn KMDF  .  If it is not possible , give me good concept to write filter driver.


    Ranjith

    Friday, August 30, 2013 12:19 PM
  • For a USB device of a given class, use a class filter for that class.  USB has a complex stack see http://msdn.microsoft.com/en-us/library/windows/hardware/hh406256(v=VS.85).aspx  so depending on where you are looking to collect data you are in undocumented territory.

    I would look at a class driver for a well known class of device.

     

    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Friday, August 30, 2013 1:05 PM
  • Thanks Don Burn  for your Reply..I have one more clarification.Is it possible to catch I/O calls for Usb2.0 driver stack using filter driver.

    Ranjith

    Friday, August 30, 2013 3:22 PM
  • Yes you should be able to do it, but there could be problems.  First the USB class is reserved for Microsoft, see http://msdn.microsoft.com/en-us/library/windows/hardware/ff553428(v=vs.85).aspx there may be problems with the tools and the INF file. 

    Second, if I remember correctly a number of the capabilities of USB are provided by device interfaces,  these can be somewhat tricky to filter, and are not filtered as part of the normal KMDF filter model.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Friday, August 30, 2013 3:33 PM
  • Mr. Don,many thanks for your explanation.

    I too the beginner, and me some moments are unclear..

    1 . The filter driver is attached to desired device (stack) only once, in case of its installation (I mean installation of driver)?

    2. The target device (stack) to which we wish to be attached and from which we want to intercept/catch data, is hardcoded into INF file?

    3. What is meant a class of device? It is Setup Class GUID?

    4. If my OS have, for example, two serial ports COM1 and COM2 how to specify information in the INF file, what I want, for example, attach to COM2 to catch I/O?

    5. Or it is meant, what the filter driver attached to an enumerator of serial devices, and do catching of requests from all serial devices directly? And then I should just manually detect a owner of each request and filter it?

    I is confused and tangled. Please, help me understand an base concept.. :(

    Friday, August 30, 2013 3:49 PM
  • Answers to the questions:

    1 . The filter driver is attached to desired device (stack) only once, in case of its installation (I mean installation of driver)?

    Normally this is true.  You need to distinguish device from driver.  A driver can support multiple devices, and it is possible to design a driver to be called to create a device in more than one location in the device stack.

    2. The target device (stack) to which we wish to be attached and from which we want to intercept/catch data, is hardcoded into INF file?

    The device class is specified in the INF file.  It is possible to have multipe INF files point to a single driver.

    3. What is meant a class of device? It is Setup Class GUID?

    Yes the Setup Class GUID is the class.  Take a look at the Toaster Filter INX file for an example INX file.

    4. If my OS have, for example, two serial ports COM1 and COM2 how to specify information in the INF file, what I want, for example, attach to COM2 to catch I/O?

    You can provide a device specific installer for a filter.  Or you can use a class filter and check which device it is and do differing actions.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Friday, August 30, 2013 4:00 PM
  • Mr, Don,

    So, I need know a name of the target driver which provides implementation of appropriate COM port?

    E.g.

    1. if COM1 and COM2 are on-board ports (e.g. PNP0501) which are provided by means of the standard MS driver, then in the INF file of the My filter-driver I need specify as the target - the MS driver?

    2. if COM3 and COM4 are USB-serial ports which are provided by means of the some vendor driver (e.g. FTDI), then in the INF file of the My filter-driver I need specify as the target - the FTDI driver?

    3. if COM5 and COM6 are USB-serial ports which are provided by means of the some vendor driver (e.g. Prolific), then in the INF file of the My filter-driver I need specify as the target - the Prolific driver?

    and so on?

    Friday, August 30, 2013 6:02 PM
  • No you don't need to know a thing about other drivers.  The INF file says if the device class is Ports you will be attached to all serial and com ports.

    What you need to know is what device object you are attached to.  There are a number of approaches to this, depending on what you are looking to do.  For example IoGetDeviceProperty can be used to get the bus type or the friendly name which can indicate the comX value.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Friday, August 30, 2013 6:13 PM
  • Ahh, Don, many many thanks, now, seems, I see light on end of tunnel... :)
    Friday, August 30, 2013 6:28 PM