How to communicate with USB drive firmware?

Michal_Vodicka-2 · December 2, 2004, 9:03pm

We’re trying to find some method how to send to and receive data from firmware at USB drive. IOCTL_SCSI_PASS_THROUGH would be suitable but it needs R/W access to drive device and in turn admin rights. It’s a pity because our software has to be usable for ordinal users, too. Moreover, it should be usable without any additional sw installation; user should be able to plug USB drive in and start our app from it. It means helper driver or service with necessary rights also can’t be used because installation needs admin rights (Catch 22 :).

We’re already considering crazy solutions as reading/writing to specific areas of drive interpreted as commands. Does anybody have an another idea?

(Sorry for repost; I haven’t received my original question via mail after more than 3.5 hours and it isn’t available via news. Other mails to the list I posted later were delivered so I guess this one is lost somewhere in the cyberspace

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Michal_Vodicka-2 · December 3, 2004, 4:58am

We’re trying to find some method how to send to and receive data from firmware at USB drive. IOCTL_SCSI_PASS_THROUGH would be suitable but it needs R/W access to drive device and in turn admin rights. It’s a pity because our software has to be usable for ordinal users, too. Moreover, it should be usable without any additional sw installation; user should be able to plug USB drive in and start our app from it. It means helper driver or service with necessary rights also can’t be used because installation needs admin rights (Catch 22 :).

We’re already considering crazy solutions as reading/writing to specific areas of drive interpreted as commands. Does anybody have an another idea?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

OSR_Community_User · December 3, 2004, 8:21am

Hi, Michal.

One technique we’ve used for updating firmware on some of our USB devices
was to add an HID endpoint that has “vendor-specific” reports. We have an
8-byte report for “erase sectors” (4-byte start address and 4-byte end
address), a 4-byte report for “set read/write address”, and 64-byte reports
for “read” and “write”. It’s not very fast, but it does work and only the
“in the box” HID drivers are required.

Good luck!

-Dan

----- Original Message -----

Subject: How to communicate with USB drive firmware?
From: “Michal Vodicka”
> Date: Fri, 3 Dec 2004 03:02:51 +0100
> X-Message-Number: 29
>
> We’re trying to find some method how to send to and receive data from =
> firmware at USB drive. IOCTL_SCSI_PASS_THROUGH would be suitable but it =
> needs R/W access to drive device and in turn admin rights. It’s a pity =
> because our software has to be usable for ordinal users, too. Moreover, =
> it should be usable without any additional sw installation; user should =
> be able to plug USB drive in and start our app from it. It means helper =
> driver or service with necessary rights also can’t be used because =
> installation needs admin rights (Catch 22 :).
>
> We’re already considering crazy solutions as reading/writing to specific =
> areas of drive interpreted as commands. Does anybody have an another =
> idea?
>
> (Sorry for repost; I haven’t received my original question via mail =
> after more than 3.5 hours and it isn’t available via news. Other mails =
> to the list I posted later were delivered so I guess this one is lost =
> somewhere in the cyberspace
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]

OSR_Community_User · December 3, 2004, 10:56am

You want to bypass system security and let any user upload arbitrary
code to a USB storage device? Can I upload code that will cause your
device to hose the USB bus? Can I upload code that will cause your
device to return different data when I launch your application, thus
inserting a back-door when someone with admin privs tries to use the
device?

Magic sectors are a horrible, horrible idea regardless of why you need
them. You’re simply ensuring that any software which tries to use your
device as a disk will fail utterly and will probably corrupt your
firmware. What happens the first time someone tries doing a block-level
copy to or from your device?

You need to go back and examine some of your project goals.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, December 02, 2004 2:31 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] How to communicate with USB drive firmware?

We’re trying to find some method how to send to and receive
data from firmware at USB drive. IOCTL_SCSI_PASS_THROUGH
would be suitable but it needs R/W access to drive device and
in turn admin rights. It’s a pity because our software has to
be usable for ordinal users, too. Moreover, it should be
usable without any additional sw installation; user should be
able to plug USB drive in and start our app from it. It means
helper driver or service with necessary rights also can’t be
used because installation needs admin rights (Catch 22 :).

We’re already considering crazy solutions as reading/writing
to specific areas of drive interpreted as commands. Does
anybody have an another idea?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

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

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Norbert_Kawulski · December 3, 2004, 2:09pm

Why isn’t there a USB class where the devices bring with them their
drivers/apps. The device should be the installation media itself.
Something like:

Plug-In
System reads device-desc.
device is ‘bootstrap’-Class…
Class driver takes over.
System reads a class specific desc. telling what systems are
supported. ( Each systems gets an ID made by usb.org).
Class driver gets drivers/apps from device and does a driver-install.
Class-driver gives command ‘re-identify’ to device.
Device comes back with VID/PID or Class for just installed drivers.

Norbert.

“Compromise makes a good umbrella but a poor roof; it is a temporary
expedient. - James Russell Lowell”
---- snip ----

Mark_Roddy · December 3, 2004, 4:11pm

Not a bad idea.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
Norbert Kawulski
Sent: Friday, December 03, 2004 12:42 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] How to communicate with USB drive firmware?

Why isn’t there a USB class where the devices bring with them
their drivers/apps. The device should be the installation
media itself.
Something like:

Plug-In

System reads device-desc.
device is ‘bootstrap’-Class…

Class driver takes over.

System reads a class specific desc. telling what systems are
supported. ( Each systems gets an ID made by usb.org).

Class driver gets drivers/apps from device and does a
driver-install.

Class-driver gives command ‘re-identify’ to device.

Device comes back with VID/PID or Class for just installed drivers.

Norbert.

“Compromise makes a good umbrella but a poor roof; it is a
temporary expedient. - James Russell Lowell”
---- snip ----

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

You are currently subscribed to ntdev as:
xxxxx@hollistech.com To unsubscribe send a blank email to
xxxxx@lists.osr.com

OSR_Community_User · December 3, 2004, 5:14pm

What you’re really asking for is the ability to send arbitrary commands
to the device, which is provided (as you say) by IOCTL_SCSI_PASS_THROUGH
(SPT). However, you want to avoid security, which SPT doesn’t work
around.

Is this device always going to be USB (allows consideration of USB-only
solution)?

Approximately how much data will be transferred each way (2 bytes? 16
bytes? 4k? 64k?)?

Which Windows NT OS do you care about (winnt, win2k, winxp, srv03)?

What type of device is this USB drive (HDD, SD, CD/DVD, …)?

Thanks,
.

-----Original Message-----
From: Michal Vodicka [mailto:xxxxx@upek.com]
Sent: Thursday, December 02, 2004 6:03 PM
Subject: How to communicate with USB drive firmware?

We’re trying to find some method how to send to and receive data from
firmware at USB drive. IOCTL_SCSI_PASS_THROUGH would be suitable but it
needs R/W access to drive device and in turn admin rights. It’s a pity
because our software has to be usable for ordinal users, too. Moreover,
it should be usable without any additional sw installation; user should
be able to plug USB drive in and start our app from it. It means helper
driver or service with necessary rights also can’t be used because
installation needs admin rights (Catch 22 :).

We’re already considering crazy solutions as reading/writing to specific
areas of drive interpreted as commands. Does anybody have an another
idea?

(Sorry for repost; I haven’t received my original question via mail
after more than 3.5 hours and it isn’t available via news. Other mails
to the list I posted later were delivered so I guess this one is lost
somewhere in the cyberspace

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Michal_Vodicka-2 · December 3, 2004, 8:16pm

Yes, I like it, too. It would have to be limited to MS signed drivers to avoid security hole.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Mark Roddy[SMTP:xxxxx@hollistech.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, December 03, 2004 10:03 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to communicate with USB drive firmware?

Not a bad idea.

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> Norbert Kawulski
> Sent: Friday, December 03, 2004 12:42 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] How to communicate with USB drive firmware?
>
> Why isn’t there a USB class where the devices bring with them
> their drivers/apps. The device should be the installation
> media itself.
> Something like:
>
> 1. Plug-In
> 2. System reads device-desc.
> device is ‘bootstrap’-Class…
> 3. Class driver takes over.
> 4. System reads a class specific desc. telling what systems are
> supported. ( Each systems gets an ID made by usb.org).
> 5. Class driver gets drivers/apps from device and does a
> driver-install.
> 6. Class-driver gives command ‘re-identify’ to device.
> 7. Device comes back with VID/PID or Class for just installed drivers.
>
> Norbert.
> --------
> “Compromise makes a good umbrella but a poor roof; it is a
> temporary expedient. - James Russell Lowell”
> ---- snip ----
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@hollistech.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>

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

You are currently subscribed to ntdev as: xxxxx@upek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Michal_Vodicka-2 · December 3, 2004, 8:29pm

Daniel,

it is interesting idea. I’m not sure if we can add HID endpoint to USB flash drive but I’ll surely check it. Thanks.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Daniel E. Germann[SMTP:xxxxx@visi.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, December 03, 2004 2:15 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] How to communicate with USB drive firmware?

Hi, Michal.

One technique we’ve used for updating firmware on some of our USB devices
was to add an HID endpoint that has “vendor-specific” reports. We have an
8-byte report for “erase sectors” (4-byte start address and 4-byte end
address), a 4-byte report for “set read/write address”, and 64-byte reports
for “read” and “write”. It’s not very fast, but it does work and only the
“in the box” HID drivers are required.

Good luck!

-Dan

----- Original Message -----
> Subject: How to communicate with USB drive firmware?
> From: “Michal Vodicka”
> > Date: Fri, 3 Dec 2004 03:02:51 +0100
> > X-Message-Number: 29
> >
> > We’re trying to find some method how to send to and receive data from =
> > firmware at USB drive. IOCTL_SCSI_PASS_THROUGH would be suitable but it =
> > needs R/W access to drive device and in turn admin rights. It’s a pity =
> > because our software has to be usable for ordinal users, too. Moreover, =
> > it should be usable without any additional sw installation; user should =
> > be able to plug USB drive in and start our app from it. It means helper =
> > driver or service with necessary rights also can’t be used because =
> > installation needs admin rights (Catch 22 :).
> >
> > We’re already considering crazy solutions as reading/writing to specific =
> > areas of drive interpreted as commands. Does anybody have an another =
> > idea?
> >
> > (Sorry for repost; I haven’t received my original question via mail =
> > after more than 3.5 hours and it isn’t available via news. Other mails =
> > to the list I posted later were delivered so I guess this one is lost =
> > somewhere in the cyberspace
> >
> > Best regards,
> >
> > Michal Vodicka
> > UPEK, Inc.
> > [xxxxx@upek.com, http://www.upek.com]
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@upek.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

Michal_Vodicka-2 · December 3, 2004, 8:49pm

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Peter Wieland[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, December 03, 2004 4:52 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to communicate with USB drive firmware?

You want to bypass system security and let any user upload arbitrary
code to a USB storage device?

No code but data.

Can I upload code that will cause your
device to hose the USB bus?

Nope. I didn’t say we want to upload firmware that way. We want to communicate with it i.e. send requests and read replies. Please read my reply to Henry Gabryjelski for details. I’m sorry to not explain it completely in the initial question.

Can I upload code that will cause your
device to return different data when I launch your application, thus
inserting a back-door when someone with admin privs tries to use the
device?

No. Even if we’re able to change fw this way, it would be possible only if there is a bug in our application which causes buffer overflow with bad data. Hardly to imagine; we work with fingerprint images of different quality, signatures, position data i.e. application has to be prepared for arbitrary data. The probability is near to zero but yes, non-zero.

Magic sectors are a horrible, horrible idea regardless of why you need
them. You’re simply ensuring that any software which tries to use your
device as a disk will fail utterly and will probably corrupt your
firmware. What happens the first time someone tries doing a block-level
copy to or from your device?

I agree such a solution is ugly and we take is as last resort. We’re aware about problems. However, above can be avoided. Imagine flash drive fw understands file system and there is one file (rsh attribs) reserved for this purpose. Application would open it in exclusive, non-cached access. Writes would have to have special format (header, CRC etc.) to be taken as data to be sent to our sensor. Everything else would be taken as data for flash drive. In the best case we’d like to start passthrough mode with some special command to flash drive so it would check written data only after such command (IOCTL?). Reads are possible only after writes (our commucation protocol is naturally synchronous) so accidental reads would read real data from the file.

Again, no way how to corrupt firmware; it the worst case sensor would receive bad data and replied that it doesn’t understand.

Yes, there are problems remaining. What if somebody deletes or moves file, formats drive etc. As I said, this is last resort solution.

You need to go back and examine some of your project goals.

The goal is to have USB flash drive with built-in fingerprint sensor and application able to communicate with sensor through flash drive the same way as if the sensor is connected directly via USB or serial line (note: no change in security). The limitation is it should work for arbitrary user with OS supplied drivers only.

We’re trying to find if the goal is achievable.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Michal_Vodicka-2 · December 3, 2004, 10:23pm

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Henry Gabryjelski[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, December 03, 2004 9:58 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to communicate with USB drive firmware?

What you’re really asking for is the ability to send arbitrary commands
to the device, which is provided (as you say) by IOCTL_SCSI_PASS_THROUGH
(SPT). However, you want to avoid security, which SPT doesn’t work
around.

Exactly. But these arbitrary commands would be carefully checked by device and can cause no harm. Below I’ll explain how it should work.

Is this device always going to be USB (allows consideration of USB-only
solution)?

Yes.

Approximately how much data will be transferred each way (2 bytes? 16
bytes? 4k? 64k?)?

Max 2 kB per request in both directions. In practice, requests in host -> device direction are usually shorter; tens or hundreths bytes.

On the other hand, one high level command can consist from many requests. We’re using communication protocol with which is limited to 2 kB per frame at link layer (i.e. at request level) but allows up to 256 kB transfers at transport layer. Currently the maximal amount of data transferred from device to host is at once about 80 kB. Speed isn’t a big problem; we’re able to use serial line at 9600 when necessary.

If necessary, our protocol allows to reduce maximal link layer frame size. The shortest usable size is 8 bytes; the protocol overhead would be enormous but we’d live with it. More is better, of course. AFAIK the shortest size used by real application now is 256 bytes per frame.

Which Windows NT OS do you care about (winnt, win2k, winxp, srv03)?

w2k and above. Maybe it could be limited to XP and above.

What type of device is this USB drive (HDD, SD, CD/DVD, …)?

USB drive only. Let me explain what we really want. We have a fingerprint sensor with built-in firmware which is able to communicate using our protocol with PC or other device. Normally the device is connected directly to PC via serial line or USB. In the case I mention, sensor is built-in on USB flash drive and connected with it internally via serial connection. There is no direct sensor connection with PC. Flash drive firmware can be used in pass-through mode and it will carry data from PC to sensor and back. This way we would be able to communicate with sensor fw the same way as if it is connected directly. The problem is how to transfer data using OS supplied drivers (i.e. USBSTOR) and how to distinguish our data from data for flash drive which has to work usual way. We can do necessary changes in flash drive firmware.

I’m aware that our design leads to composite device instead. But this is what we don’t want to do. The goal is “no additional drivers installation, everything has to work automagically without user intervention”.

Thanks.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

OSR_Community_User · December 4, 2004, 2:37am

Why not make the scanner look like a USB COM Port and run a command
protocol over that? You could probably combine that with USB Mass
Storage in a composite device.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Friday, December 03, 2004 5:02 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to communicate with USB drive firmware?

From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Henry Gabryjelski[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, December 03, 2004 9:58 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to communicate with USB drive firmware?

What you’re really asking for is the ability to send arbitrary
commands to the device, which is provided (as you say) by
IOCTL_SCSI_PASS_THROUGH (SPT). However, you want to avoid security,
which SPT doesn’t work around.

Exactly. But these arbitrary commands would be carefully checked by
device and can cause no harm. Below I’ll explain how it should work.

Is this device always going to be USB (allows consideration of
USB-only solution)?

Yes.

Approximately how much data will be transferred each way (2 bytes? 16
bytes? 4k? 64k?)?

Max 2 kB per request in both directions. In practice, requests in host
-> device direction are usually shorter; tens or hundreths bytes.

On the other hand, one high level command can consist from many
requests. We’re using communication protocol with which is limited to 2
kB per frame at link layer (i.e. at request level) but allows up to 256
kB transfers at transport layer. Currently the maximal amount of data
transferred from device to host is at once about 80 kB. Speed isn’t a
big problem; we’re able to use serial line at 9600 when necessary.

If necessary, our protocol allows to reduce maximal link layer frame
size. The shortest usable size is 8 bytes; the protocol overhead would
be enormous but we’d live with it. More is better, of course. AFAIK the
shortest size used by real application now is 256 bytes per frame.

Which Windows NT OS do you care about (winnt, win2k, winxp, srv03)?

w2k and above. Maybe it could be limited to XP and above.

What type of device is this USB drive (HDD, SD, CD/DVD, …)?

USB drive only. Let me explain what we really want. We have a
fingerprint sensor with built-in firmware which is able to communicate
using our protocol with PC or other device. Normally the device is
connected directly to PC via serial line or USB. In the case I mention,
sensor is built-in on USB flash drive and connected with it internally
via serial connection. There is no direct sensor connection with PC.
Flash drive firmware can be used in pass-through mode and it will carry
data from PC to sensor and back. This way we would be able to
communicate with sensor fw the same way as if it is connected directly.
The problem is how to transfer data using OS supplied drivers (i.e.
USBSTOR) and how to distinguish our data from data for flash drive which
has to work usual way. We can do necessary changes in flash drive
firmware.

I’m aware that our design leads to composite device instead. But this is
what we don’t want to do. The goal is “no additional drivers
installation, everything has to work automagically without user
intervention”.

Thanks.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Michal_Vodicka-2 · December 4, 2004, 3:05am

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Peter Wieland[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Saturday, December 04, 2004 8:18 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to communicate with USB drive firmware?

Why not make the scanner look like a USB COM Port and run a command
protocol over that? You could probably combine that with USB Mass
Storage in a composite device.

Would it work with OS supplied drivers? The same way as USBSTOR is installed when you plug-in flash drive the first time? If so, which driver is installed for USB COM port? The only USB/serial converter I ever used had its own drivers but I haven’t studied this area. Could you tell me what to read? Thanks.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Mark_Roddy · December 4, 2004, 8:16am

And there would have to be a mechanism to have it be ‘once per machine’
rather than ‘everytime I get plugged in’. Some sort of inquiry mechanism
would have to take place to see if the driver upload was actually needed.
The signed driver part is a given, and if it worked with online updates it
would be way cool, especially if it was intelligent enough to get an upgrade
itself. Of course there is the small problem that usb devices tend to be
totally cheaped out and having enough sdram to hold the driver install
package would be a challenge for many such devices.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Friday, December 03, 2004 8:03 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to communicate with USB drive firmware?

Yes, I like it, too. It would have to be limited to MS signed
drivers to avoid security hole.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

> ----------
> From:
xxxxx@lists.osr.com[SMTP:xxxxx@lis
ts.osr.com] on behalf of Mark Roddy[SMTP:xxxxx@hollistech.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Friday, December 03, 2004 10:03 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] How to communicate with USB drive firmware?
>
> Not a bad idea.
>
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Norbert
> > Kawulski
> > Sent: Friday, December 03, 2004 12:42 PM
> > To: Windows System Software Devs Interest List
> > Subject: Re:[ntdev] How to communicate with USB drive firmware?
> >
> > Why isn’t there a USB class where the devices bring with
them their
> > drivers/apps. The device should be the installation media itself.
> > Something like:
> >
> > 1. Plug-In
> > 2. System reads device-desc.
> > device is ‘bootstrap’-Class…
> > 3. Class driver takes over.
> > 4. System reads a class specific desc. telling what systems are
> > supported. ( Each systems gets an ID made by usb.org).
> > 5. Class driver gets drivers/apps from device and does a
> > driver-install.
> > 6. Class-driver gives command ‘re-identify’ to device.
> > 7. Device comes back with VID/PID or Class for just
installed drivers.
> >
> > Norbert.
> > --------
> > “Compromise makes a good umbrella but a poor roof; it is
a temporary
> > expedient. - James Russell Lowell”
> > ---- snip ----
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> > xxxxx@hollistech.com To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
xxxxx@upek.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>

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

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Cliff_Russell · December 4, 2004, 4:59pm

It would also have to support multiple platforms (or at least allow
venders the option to include drivers multiple platforms). This would
really strain the space available on the “totally cheaped out” devices.
Maybe something like FCode for PCI device for Open Firmware machines
(ie. one driver for all platforms/OS’s)

The only problem I see with a system like this is, I usually like to
grab the latest drivers off the 'net rather than use drivers that
shipped with hardware (sometimes at my own peril, I end up trading old
bugs for new bugs). The question is, would enough people use the
built-in driver that venders would feel it’s worthwhile to include
them?

My $0.02,

–

Cliff

On 4-Dec-04, at 5:13 AM, Mark Roddy wrote:

And there would have to be a mechanism to have it be ‘once per machine’
rather than ‘everytime I get plugged in’. Some sort of inquiry
mechanism
would have to take place to see if the driver upload was actually
needed.
The signed driver part is a given, and if it worked with online
updates it
would be way cool, especially if it was intelligent enough to get an
upgrade
itself. Of course there is the small problem that usb devices tend to
be
totally cheaped out and having enough sdram to hold the driver install
package would be a challenge for many such devices.

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
> Sent: Friday, December 03, 2004 8:03 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] How to communicate with USB drive firmware?
>
> Yes, I like it, too. It would have to be limited to MS signed
> drivers to avoid security hole.
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
>> ----------
>> From:
> xxxxx@lists.osr.com[SMTP:xxxxx@lis
> ts.osr.com] on behalf of Mark Roddy[SMTP:xxxxx@hollistech.com]
>> Reply To: Windows System Software Devs Interest List
>> Sent: Friday, December 03, 2004 10:03 PM
>> To: Windows System Software Devs Interest List
>> Subject: RE: [ntdev] How to communicate with USB drive firmware?
>>
>> Not a bad idea.
>>
>>
>>> -----Original Message-----
>>> From: xxxxx@lists.osr.com
>>> [mailto:xxxxx@lists.osr.com] On Behalf Of Norbert
>>> Kawulski
>>> Sent: Friday, December 03, 2004 12:42 PM
>>> To: Windows System Software Devs Interest List
>>> Subject: Re:[ntdev] How to communicate with USB drive firmware?
>>>
>>> Why isn’t there a USB class where the devices bring with
> them their
>>> drivers/apps. The device should be the installation media itself.
>>> Something like:
>>>
>>> 1. Plug-In
>>> 2. System reads device-desc.
>>> device is ‘bootstrap’-Class…
>>> 3. Class driver takes over.
>>> 4. System reads a class specific desc. telling what systems are
>>> supported. ( Each systems gets an ID made by usb.org).
>>> 5. Class driver gets drivers/apps from device and does a
>>> driver-install.
>>> 6. Class-driver gives command ‘re-identify’ to device.
>>> 7. Device comes back with VID/PID or Class for just
> installed drivers.
>>>
>>> Norbert.
>>> --------
>>> “Compromise makes a good umbrella but a poor roof; it is
> a temporary
>>> expedient. - James Russell Lowell”
>>> ---- snip ----
>>>
>>>
>>>
>>> —
>>> Questions? First check the Kernel Driver FAQ at
>>> http://www.osronline.com/article.cfm?id=256
>>>
>>> You are currently subscribed to ntdev as:
>>> xxxxx@hollistech.com To unsubscribe send a blank email to
>>> xxxxx@lists.osr.com
>>>
>>
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as:
> xxxxx@upek.com To
>> unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
> argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

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

You are currently subscribed to ntdev as: xxxxx@telus.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

Loren_Wilton · December 5, 2004, 1:35am

> USB drive only. Let me explain what we really want. We have a fingerprint
sensor with built-in firmware which is able to communicate using our
protocol with PC or other device. Normally the device is connected directly
to PC via serial line or USB. In the case I mention, sensor is built-in on
USB flash drive and connected with it internally via serial connection.
There is no direct sensor connection with PC. Flash drive firmware can be
used in pass-through mode and it will carry data from PC to sensor and back.

In this sort of case I’d recomend the HID endpoint solution if you can
manage it in the drive hardware/firmware.

While not exactly the same case as yours, I have a security dongle from
another company that uses a HID interface to a vendor-supplied DLL for
communications. It works very well, and has the huge advantage that there
are no drivers to load, since it uses the standard HID drivers from MS (or
Linux, or whatever). It simply locates its device by VID/PID, and then
opens it appropriately. It can handle multiple devices on the same hub.

Loren

Michal_Vodicka-2 · December 6, 2004, 2:50pm

Thanks. It seems can probably afford to add HID endpoint to flashdrive hw at least in some cases. The solution is very promising. I’d like to ask few additional question; please forgive my ignorance as I never worked with HID endpoints before.

I hope there is no need for both driver and INF file; is it correct? If so, how it looks like when user plugs device in the first time? I mean if there are some dialogs, questions etc. Next, I’d like to know how much data can be transferred in both directions. From Daniel Germann’s reply it seems the number is 64 bytes; is it “clean” data size i.e. can be completely used or does it contain some mandatory data as headers etc.? Are there any problems I should know about?

Thanks.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Loren Wilton[SMTP:xxxxx@earthlink.net]
Reply To: Windows System Software Devs Interest List
Sent: Sunday, December 05, 2004 7:08 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] How to communicate with USB drive firmware?

> USB drive only. Let me explain what we really want. We have a fingerprint
sensor with built-in firmware which is able to communicate using our
protocol with PC or other device. Normally the device is connected directly
to PC via serial line or USB. In the case I mention, sensor is built-in on
USB flash drive and connected with it internally via serial connection.
There is no direct sensor connection with PC. Flash drive firmware can be
used in pass-through mode and it will carry data from PC to sensor and back.

In this sort of case I’d recomend the HID endpoint solution if you can
manage it in the drive hardware/firmware.

While not exactly the same case as yours, I have a security dongle from
another company that uses a HID interface to a vendor-supplied DLL for
communications. It works very well, and has the huge advantage that there
are no drivers to load, since it uses the standard HID drivers from MS (or
Linux, or whatever). It simply locates its device by VID/PID, and then
opens it appropriately. It can handle multiple devices on the same hub.

Loren

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

You are currently subscribed to ntdev as: xxxxx@upek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · December 6, 2004, 3:23pm

Actually, putting device drivers onto a device could be a very bad idea.
There was one company which tried this long ago, and the drivers they
put onto the media were just a “little” bit buggy. Oh, and then their
OS changed. The end result is that they had a nightmare trying to force
these drivers to *not* install in the future.

Some key questions:

Do you want your device to work on future OS versions? How will you
deal with this?
How sure are you that your driver is bug-free, and won’t cause a
bugcheck on some customer machine just by plugging in the device?
How will you check for an updated driver?

A better solution would be to have a basic device with in-box drivers
(say emulate a floppy or very small disk) and put an autorun.inf file
that launches to a web site that lists the drivers available for the
device. Since the original poster was doing a USB flash device, this
shouldn’t be a problem to pre-load this onto the flash drive (the user
can always delete it after they use it the first time, of course…)

.

-----Original Message-----
From: Mark Roddy [mailto:xxxxx@hollistech.com]
Sent: Friday, December 03, 2004 1:03 PM
Subject: RE: How to communicate with USB drive firmware?

Not a bad idea.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Norbert
Kawulski
Sent: Friday, December 03, 2004 12:42 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] How to communicate with USB drive firmware?

Why isn’t there a USB class where the devices bring with them their
drivers/apps. The device should be the installation media itself.
Something like:

Plug-In

System reads device-desc.
device is ‘bootstrap’-Class…

Class driver takes over.

System reads a class specific desc. telling what systems are
supported. ( Each systems gets an ID made by usb.org).

Class driver gets drivers/apps from device and does a
driver-install.

Class-driver gives command ‘re-identify’ to device.

Device comes back with VID/PID or Class for just installed drivers.

Norbert.

“Compromise makes a good umbrella but a poor roof; it is a temporary
expedient. - James Russell Lowell”
---- snip ----

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

You are currently subscribed to ntdev as:
xxxxx@hollistech.com To unsubscribe send a blank email to
xxxxx@lists.osr.com

OSR_Community_User · December 6, 2004, 3:23pm

OK, this is a much easier problem to understand. I would definitely
suggest making the fingerprint reader a separate USB device (HID was
suggested in earlier thread). This allows you to send commands to your
device without any of the following concerns:

How to differentiate between “normal” data and “special” data.
Careful thought will show this can be made statistically unlikely, but
never foolproof.
How to “work around” security that NT sets up. Without a service
(preferred) or filter driver (less nice), any “work around” is generally
frowned upon by those on this list.
How to ensure the user has the most up-to-date, robust driver/service
for the device (presuming one is required).

Let us know if the HID device solution ends up working well for you.

.

-----Original Message-----
From: Michal Vodicka [mailto:xxxxx@upek.com]
Sent: Friday, December 03, 2004 5:02 PM
Subject: RE: How to communicate with USB drive firmware?

From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Henry Gabryjelski[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, December 03, 2004 9:58 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to communicate with USB drive firmware?

What you’re really asking for is the ability to send arbitrary
commands to the device, which is provided (as you say) by
IOCTL_SCSI_PASS_THROUGH (SPT). However, you want to avoid security,
which SPT doesn’t work around.

Exactly. But these arbitrary commands would be carefully checked by
device and can cause no harm. Below I’ll explain how it should work.

Is this device always going to be USB (allows consideration of
USB-only solution)?

Yes.

Approximately how much data will be transferred each way (2 bytes? 16
bytes? 4k? 64k?)?

Max 2 kB per request in both directions. In practice, requests in host
-> device direction are usually shorter; tens or hundreths bytes.

On the other hand, one high level command can consist from many
requests. We’re using communication protocol with which is limited to 2
kB per frame at link layer (i.e. at request level) but allows up to 256
kB transfers at transport layer. Currently the maximal amount of data
transferred from device to host is at once about 80 kB. Speed isn’t a
big problem; we’re able to use serial line at 9600 when necessary.

If necessary, our protocol allows to reduce maximal link layer frame
size. The shortest usable size is 8 bytes; the protocol overhead would
be enormous but we’d live with it. More is better, of course. AFAIK the
shortest size used by real application now is 256 bytes per frame.

Which Windows NT OS do you care about (winnt, win2k, winxp, srv03)?

w2k and above. Maybe it could be limited to XP and above.

What type of device is this USB drive (HDD, SD, CD/DVD, …)?

USB drive only. Let me explain what we really want. We have a
fingerprint sensor with built-in firmware which is able to communicate
using our protocol with PC or other device. Normally the device is
connected directly to PC via serial line or USB. In the case I mention,
sensor is built-in on USB flash drive and connected with it internally
via serial connection. There is no direct sensor connection with PC.
Flash drive firmware can be used in pass-through mode and it will carry
data from PC to sensor and back. This way we would be able to
communicate with sensor fw the same way as if it is connected directly.
The problem is how to transfer data using OS supplied drivers (i.e.
USBSTOR) and how to distinguish our data from data for flash drive which
has to work usual way. We can do necessary changes in flash drive
firmware.

I’m aware that our design leads to composite device instead. But this is
what we don’t want to do. The goal is “no additional drivers
installation, everything has to work automagically without user
intervention”.

Thanks.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Michal_Vodicka-2 · December 6, 2004, 4:06pm

Unfortunately, we can’t make reader separate USB device. This is firmware design limitation; it supports both serial and USB connection but they can’t be used at once. Reader has to be connected to flash drive hw because it communicates directly with it; it controls access to flash drive data without host OS intervention. Serial connection is used for this purpose so USB can’t be used.

In some cases we can add HID endpoint to flash drive hw instead which should solve the problem. Flash drive fw would transfer data between OS and reader.

However, we probably can’t afford it in all cases as flash drives are 3rd party products. For these cases I’d still need some solution. If service or driver can be used, I wouldn’t ask So if you or anyone else knows about yet another ugly workaround, I’d like to know about

BTW, isn’t Windows Update an answer to your point 3?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Henry Gabryjelski[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Monday, December 06, 2004 9:22 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to communicate with USB drive firmware?

OK, this is a much easier problem to understand. I would definitely
suggest making the fingerprint reader a separate USB device (HID was
suggested in earlier thread). This allows you to send commands to your
device without any of the following concerns:

How to differentiate between “normal” data and “special” data.
Careful thought will show this can be made statistically unlikely, but
never foolproof.

How to “work around” security that NT sets up. Without a service
(preferred) or filter driver (less nice), any “work around” is generally
frowned upon by those on this list.

How to ensure the user has the most up-to-date, robust driver/service
for the device (presuming one is required).

Let us know if the HID device solution ends up working well for you.

.

-----Original Message-----
From: Michal Vodicka [mailto:xxxxx@upek.com]
Sent: Friday, December 03, 2004 5:02 PM
Subject: RE: How to communicate with USB drive firmware?

> ----------
> From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Henry Gabryjelski[SMTP:xxxxx@windows.microsoft.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Friday, December 03, 2004 9:58 PM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] How to communicate with USB drive firmware?
>
> What you’re really asking for is the ability to send arbitrary
> commands to the device, which is provided (as you say) by
> IOCTL_SCSI_PASS_THROUGH (SPT). However, you want to avoid security,
> which SPT doesn’t work around.
>
Exactly. But these arbitrary commands would be carefully checked by
device and can cause no harm. Below I’ll explain how it should work.

> Is this device always going to be USB (allows consideration of
> USB-only solution)?
>
Yes.

> Approximately how much data will be transferred each way (2 bytes? 16
> bytes? 4k? 64k?)?
>
Max 2 kB per request in both directions. In practice, requests in host
-> device direction are usually shorter; tens or hundreths bytes.

On the other hand, one high level command can consist from many
requests. We’re using communication protocol with which is limited to 2
kB per frame at link layer (i.e. at request level) but allows up to 256
kB transfers at transport layer. Currently the maximal amount of data
transferred from device to host is at once about 80 kB. Speed isn’t a
big problem; we’re able to use serial line at 9600 when necessary.>

If necessary, our protocol allows to reduce maximal link layer frame
size. The shortest usable size is 8 bytes; the protocol overhead would
be enormous but we’d live with it. More is better, of course. AFAIK the
shortest size used by real application now is 256 bytes per frame.

> Which Windows NT OS do you care about (winnt, win2k, winxp, srv03)?
>
w2k and above. Maybe it could be limited to XP and above.

> What type of device is this USB drive (HDD, SD, CD/DVD, …)?
>
USB drive only. Let me explain what we really want. We have a
fingerprint sensor with built-in firmware which is able to communicate
using our protocol with PC or other device. Normally the device is
connected directly to PC via serial line or USB. In the case I mention,
sensor is built-in on USB flash drive and connected with it internally
via serial connection. There is no direct sensor connection with PC.
Flash drive firmware can be used in pass-through mode and it will carry
data from PC to sensor and back. This way we would be able to
communicate with sensor fw the same way as if it is connected directly.
The problem is how to transfer data using OS supplied drivers (i.e.
USBSTOR) and how to distinguish our data from data for flash drive which
has to work usual way. We can do necessary changes in flash drive
firmware.

I’m aware that our design leads to composite device instead. But this is
what we don’t want to do. The goal is “no additional drivers
installation, everything has to work automagically without user
intervention”.

Thanks.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com