3

I am developing a USB-based peripheral device for use on Windows desktop systems and would prefer to avoid a driver installation step. In part, due to the resources required to develop and sign custom drivers, and in part as third party drivers have proved a significant stumbling block for users.

This suggests the use of a standard USB device class. HID is straightforward and flexible but has poor throughput aggrevated by MCU-specific limitations. Instead I am evaluating a scheme of impersonating a mass-storage device.

The trick being to report the metadata for a FAT filesystem containing a hidden device I/O file, which the interface application then employs raw file unbuffered I/O to communicate through. All data outside of the hard-wired I/O file sectors is reloaded into RAM at enumeration and ignored.

Thus far, this has worked surprisingly smoothly, with fast I/O and enumeration through what is presumably well-optimized path on all systems tested and no privilege elevation. However, this is clearly an abuse of the system and may fall over if Windows decides to, say, detect that the I/O data is being read back inconsistently, to defragment the cluster chain, reformat as exFAT, etc.

My question is whether such a scenario is known to occur in practice, or likely to occur in the near future? Has such a scheme been attempted the past? Will the quantity of dodgy USB mass storage devices out there form an effective shield against the operating system getting fancy?

Finally, are there any other standard USB classes or approaches which I might consider as a more reliable alternative? Windows 10 has finally added standard CDC support yet supporting earlier versions would involve bypassing signed driver installation (plus a history of BSODs, random disconnects and enumeration failures has left me wary of virtual serial devices.)

doynax
  • 4,285
  • 3
  • 23
  • 19
  • Maybe consider a CDC class/VCOM device? Pretty sure all the major OSes support this by default (though win7 may need an .inf file) – Russ Schultz Feb 15 '17 at 14:19
  • 1
    @Russ Schultz: Thank you, I shall take a closer look. Alas my understanding from the last time I experimented with this is that prior to Windows 10 a signed INF file is required, even while referencing the built-in driver (see https://msdn.microsoft.com/en-us/library/windows/hardware/dn707976(v=vs.85).aspx). – doynax Feb 15 '17 at 14:27
  • It's my understanding that the .sys file is signed, but the .inf is just a plain text file – Russ Schultz Feb 15 '17 at 14:31
  • @Russ Schultz: I ran a quick experiment on a random INF file lying around on my system (`JLinkCDC.inf`) and after tweaking a comment I'm afraid that the installation now reports a hash failure. A bit of googling appears to suggest that `inf2cat` is used to generate the certificate based on a specific INF file and therefore tying it to the device VID/PID it specifies, though admittedly I have never gone through the certification process. – doynax Feb 15 '17 at 14:52
  • to be honest, I've never really done it myself, so it's likely you are correct w/regards to the inf file needing to be part of the signature. Supposedly win10 includes a generic .inf file for VCOM so it would behave like HID or USBMS – Russ Schultz Feb 15 '17 at 15:26

1 Answers1

1

Consider using MS OS 2.0 Descriptors. Basically, you can add some special requests and descriptors to your USB device that tell Windows 8.1 and later to automatically use WinUSB for the device. Once WinUSB is installed, you can use libraries like libusb and libusbp to access the device, or just use the WinUSB API directly.

For users who are on Windows 7 or below, you could supply a signed INF-only driver, which is not too hard or expensive. See the document I wrote about it. Or you could just tell them to use a utility like Zadig to install WinUSB. Zadig gets around the driver singing requirement by inventing its own root certificate and installing it as a trusted root certificate on the user's machine.

David Grayson
  • 84,103
  • 24
  • 152
  • 189
  • Thank you! Access to proprietary USB communication via WinUSB sounds _very_ appealing and I shall have to try it out. The handling of previous Windows releases is still up in the air but the potential for true _plug-and-play_, that is reliable automatic enumeration and usage without a manual installation step or elevation, is too good to pass up. If nothing else a fallback transport layer would certainly be prudent. – doynax Feb 16 '17 at 06:46