Avoiding unsigned class filter driver hassles

I’ve written a KMDF USB device class lower filter driver to patch broken
class-specific descriptors for a particular USB audio device that were
causing incompatibility with Microsoft’s USBAUDIO.SYS in Vista and
Windows 7 (same device worked OK in 2000 and XP due to a bug in previous
versions of USBAUDIO.SYS). My driver installs as a lower filter to the
USB device class, and its DeviceAdd attaches the filter only to
instances of my specific device (as determined by inspecting the
DevicePropertyHardwareID).

I wrote this driver out of personal need and as a favor to fellow owners
of the device (the manufacturer has abandoned it), and so I really don’t
have the resources to provide a signed version of it.

The unsigned 32-bit version works fine in Vista and Windows 7, and the
64-bit version works fine as long as the user manually disables driver
signature enforcement by pressing F8 at Windows startup. Unfortunately,
if the user forgets to do that, Windows leaves the rejected filter
driver in the stack and so communication with all USB devices is
blocked. It would be nice if Windows could automatically bypass filter
drivers that were not permitted to start.

Does anyone have suggestions for improving the situation?

It seems wrong that I should have to install the filter on the USB
device class as a whole. However, my testing a while back seemed to
indicate that this is where I have the opportunity to intercept Windows’
first descriptor reads from the actual hardware. Beyond that point,
after a USB device has been detected and offered to higher-level
drivers, it looked like Windows was using cached copies of the
descriptors for subsequent reads and my filter was not seeing the
traffic.

Thanks,
Mark Fontana

Mark Fontana wrote:

I’ve written a KMDF USB device class lower filter driver to patch broken
class-specific descriptors for a particular USB audio device that were
causing incompatibility with Microsoft’s USBAUDIO.SYS in Vista and
Windows 7 (same device worked OK in 2000 and XP due to a bug in previous
versions of USBAUDIO.SYS). My driver installs as a lower filter to the
USB device class, and its DeviceAdd attaches the filter only to
instances of my specific device (as determined by inspecting the
DevicePropertyHardwareID).

I wrote this driver out of personal need and as a favor to fellow owners
of the device (the manufacturer has abandoned it), and so I really don’t
have the resources to provide a signed version of it.

You (or they) can get a workable KMCS code signing certificate for $299
per year.

The unsigned 32-bit version works fine in Vista and Windows 7, and the
64-bit version works fine as long as the user manually disables driver
signature enforcement by pressing F8 at Windows startup. Unfortunately,
if the user forgets to do that, Windows leaves the rejected filter
driver in the stack and so communication with all USB devices is
blocked. It would be nice if Windows could automatically bypass filter
drivers that were not permitted to start.

Does anyone have suggestions for improving the situation?

There is no solution You either sign the filter, disable signature
enforcement, or attach a kernel debugger.

It seems wrong that I should have to install the filter on the USB
device class as a whole. However, my testing a while back seemed to
indicate that this is where I have the opportunity to intercept Windows’
first descriptor reads from the actual hardware. Beyond that point,
after a USB device has been detected and offered to higher-level
drivers, it looked like Windows was using cached copies of the
descriptors for subsequent reads and my filter was not seeing the
traffic.

Exactly what do you need to change? If you only need to change the
audio-class parts of the configuration descriptor, you can do that in a
lower filter to usbaudio.sys for your specific device. If you need to
change the device descriptor to fix a bad device class, that’s harder.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.