RE: What happened to IOCTL_SEND_USB_REQUEST in WMP11 wpdusb.sys?

NTDEV
1

Awhile back, I wrote:

Back in the WMP10 days, we would open a handle to our device
using the {f33fdc04-d1ac-4e8e-9a30-19bbd4b108ae} interface
class, and then issue IOCTL_SEND_USB_REQUEST to wpdusb.sys
in order to send some custom data to our device.

In WMP11, wpdusb.sys doesn’t seem to export this IOCTL any
more. Further, I’ve looked through the WPD development
guide, but it’s not obvious that doing this (I just want to
send an eight-byte setup packet) is still possible.

After hearing back (well, sort of) from someone at MS support on this issue, I thought I would share my experience.

First, to my surprise, the support engineer told us that even though the MSDN documentation on IOCTL_SEND_USB_REQUEST says “Sends a vendor-defined request to a USB device, using the control pipe,” using it in exactly this manner was not an officially supported method and it was “never designed for such purpose”. Further attempts to clarify this statement with the support engineer were ignored.

So, my next plan was to load a filter driver on the stack and expose a control device through which we could send USB control requests through a custom IOCTL. However, whenever I tried to bring up the stack with my filter driver loaded (either as an upper or lower filter), the device would bang out in Device Manager. I assumed this was some sort of (easily subverted, of course) DRM measure, or maybe you can’t use filter drivers on a UMDF stack??..but don’t really know.

So, plan C (which we ended up using) was to use our generic parent bus driver to create a virtual MTP device from the one USB MTP interface exposed by our device. The virtual MTP device’s stack doesn’t have any filters, and then I just loaded my custom driver as a filter on the bus driver’s stack.

2

I spoke with the MTP devs about this. They don’t see any reason why you wouldn’t be able to put a filter driver into the device stack. You wouldn’t be able to create an upper filter that exposed a control device (UMDF doesn?t support control devices, and kernel drivers have to be below UM drivers in the stack), but you should be able to make a lower filter that does the right thing.

As to why the command “isn’t supported” - the command that you’re talking was in place for scanner applications to talk to their device. The MTP folks reused the same transport driver but closed off this route because there were a number of security concerns about an arbitrary application being able to send direct USB commands to a device which may well contain personal information. Perhaps not the best approach, but security is one area where it’s better to piss people off because we *don’t* allow something potentially dangerous :slight_smile:

It worked in WMP10 because no one thought to shut it off then.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, February 08, 2007 9:53 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] What happened to IOCTL_SEND_USB_REQUEST in WMP11 wpdusb.sys?

Awhile back, I wrote:

Back in the WMP10 days, we would open a handle to our device
using the {f33fdc04-d1ac-4e8e-9a30-19bbd4b108ae} interface
class, and then issue IOCTL_SEND_USB_REQUEST to wpdusb.sys
in order to send some custom data to our device.

In WMP11, wpdusb.sys doesn’t seem to export this IOCTL any
more. Further, I’ve looked through the WPD development
guide, but it’s not obvious that doing this (I just want to
send an eight-byte setup packet) is still possible.

After hearing back (well, sort of) from someone at MS support on this issue, I thought I would share my experience.

First, to my surprise, the support engineer told us that even though the MSDN documentation on IOCTL_SEND_USB_REQUEST says “Sends a vendor-defined request to a USB device, using the control pipe,” using it in exactly this manner was not an officially supported method and it was “never designed for such purpose”. Further attempts to clarify this statement with the support engineer were ignored.

So, my next plan was to load a filter driver on the stack and expose a control device through which we could send USB control requests through a custom IOCTL. However, whenever I tried to bring up the stack with my filter driver loaded (either as an upper or lower filter), the device would bang out in Device Manager. I assumed this was some sort of (easily subverted, of course) DRM measure, or maybe you can’t use filter drivers on a UMDF stack??..but don’t really know.

So, plan C (which we ended up using) was to use our generic parent bus driver to create a virtual MTP device from the one USB MTP interface exposed by our device. The virtual MTP device’s stack doesn’t have any filters, and then I just loaded my custom driver as a filter on the bus driver’s stack.

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

3

Did they actually *try* to make a LowerFilter and put it on the WPD stack? Or is this just a hypothesis?

I created a KMDF filter driver that did absolutely nothing (except call WdfFdoSetFilter()), added it as a LowerFilter on the devnode, and reenabled the device in Device Manager. The device came up banged out.

If there was some sort of paranoia about doing arbitrary traffic to a personal device, I can see “let’s not allow any filter drivers!” as another way to try to achieve this.

I’m not sure what they thought they achieved by shutting off that IOCTL. I was able to subvert it fairly easily, and I’m sure there are other ways as well.