Using DriverStudio to construct a USB filter driver

This article is divided into three sections to describe how to construct a simple USB filter driver, including "Fundamentals", "Program implementation", "Use INF installation." The purpose of this article is to want readers to understand the rationale, you can use the most popular and most convenient driver development tools other than DDK DriverStudio to implement a own filter driver, and properly installed.

First, the basic principle

As we know, WDM (and KDM) is layered, and when constructing a device stack, the IO Manager can attach a device object to a device object created by another initial driver. The IRP that is determined by the driver associated with the initial device object will also be sent to the driver associated with the attached device object. This add-in driver is the filter driver. As shown on the right, the filter driver can be inserted at any level of the device stack. The IRP issued by the IO Manager will be passed up and down in the order of the right graph. Therefore, we can use the filter driver to check, modify, complete the IRP that it receives, or construct its own IRP.

The above text is very boring, fortunately "predecessors" have written some examples for us to better understand these concepts. Readers of Waltz Oney's programming Windows Driver Mode are probably aware that Waltz offers examples of USB filters (Nineth), and on this basis, the USB design by John Hyde, author of Example (http://www.usb-by-example.com), implemented a USB keyboard filter driver that added an "intercept (Intercept)" to the program function to handle the report of a USB keyboard to achieve a specific function: When the driver intercepts a get_report_descriptor from a USB device to a Irp_mj_internal_device_control setting in the completion routine, The interceptor changes the usage value in this descriptor from "keyboard" to "userdefined" and back to the system.

We can get some inspiration from this example, for example, under Win2K, the keyboard is exclusively accessed by the OS, and we can make it accessible to the user in this way, and we can intercept other report_descriptor and redefine some of the keys to meet special requirements. If you are willing to do a user state program, you can also be intercepted to the key value passed to your user state program, to achieve such as Lenovo, Tatsu and other domestic computer manufacturers produced by the keyboard of the various practical functions.

Second, the realization of the procedure

Examples of Waltz Oney and John Hyde have been written in detail, and readers can compile and generate a filter driver without having to modify a byte. The purpose of this article is to use the DriverStudio component Driverworks to achieve the same functionality.

I believe that when readers read this article, they already have a lot of understanding of DriverStudio. DriverStudio as a "fast" drive development tool based on C + +, it encapsulates basically all DDK function, its integration in VC + + Driverwizard, can guide you to complete the whole process of device driver development easily, can automatically generate the device driver source code according to your hardware type, and provides many example programs. Of course, these examples include a framework for a USB filter driver. Without infringing copyright, it is our usual practice to make full use of the existing shared, free and authorized code. We will make the following changes based on this paradigm.

Our goal is to do a hid small driver hidusb.sys Lower Filter, which is attached to the "human-computer interface Device", by intercepting the USB get_report_descriptor to modify its return value, When it finds that the descriptor usage is "keyboard", it is changed to "userdefined" so that we can completely control the keyboard. The specific approach is to intercept the Irp_mj_internal_device_control and check its IOCTL code and URB if the Ioctrl function code is met Ioctl_internal_usb_submit_ URB and URB function code is the urb_function_get_descriptor_from_interface condition, that is, the upper-drive sends to get_report_descriptor the request, sets a complete routine, in this completion routine, We will judge the value of usage by changing the usage from "6 (keyboard)" to "0 (userdefined)".

Open the C:\Program files\numega\driverstudio\driverworks\examples\wdm\usbfilt directory (depending on the directory installed by your driverstudio), Then open the project file USBFILT.DSW, let's look at the code first.