Reverse Engineering a USB device

NTDEV
1

I have a USB radio that DLink originally put out. A long while back, they
EOL’ed it. Because it is EOL, i have no hopes of getting a 64 bit driver
for it, from them. However, I could write one.

Which brings me to my question, how does one go about reverse engineering
a driver for a USB device? I realize the depth and scope of the project is
potentially enormous, but since it is *just* for me, I figure, what the heck,
itll be a learning experience. Anyone have any tips on this sort of thing?

All i know right now is that it has about 4 IOCTL’s that are sent to it, only
one of which returns any data. Based on the UMDF FAQ it looks like i can write
this in UMDF, which would be a BIG plus. But how does one determine what data
to send down the USB bus as well as what endpoints to send it to?

Asa

2

The best tool you can use is USB analyser (example: http://www.ellisys.com/). The second best and cheaper is some kind of software monitor (example: http://www.hhdsoftware.com/Products/home/usb-monitor-pro.html). OSR IRP tracker can be also helpful to pair IOCTLs to USB traffic.

USB analyser is IMO necessary for any serious USB development but if you need just this project, it is probably too expensive (but it is a nice toy, anyway :slight_smile: The complexity of the task depends on the complexity of the used protocol.

Next tool which can be really helpful is IDA disassembler (http://www.datarescue.com/idabase/). If the protocol is too complex, you could theoretically recover original C sources with help of it and build driver for x64 without understanding the protocol at all. It’d really help if you have driver symbols (check the binary, if the driver is old enough, it is quite possible it contains forgotten debug info).

Personally, I’d start with USB analyser and then combine all approaches.

But wait, don’t skip one important point. Have you tried to ask the company which developed it about some info? If they abandoned product and there are kind people, you could get protocol description and may even driver sources. Also, Google can be your friend. Maybe somebody wrote a Linux driver for it and you could find sources.

(ah, I wish to have time to make something like this just for me :slight_smile:

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 Asa Yeamans[SMTP:xxxxx@rivin.net]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, March 08, 2007 3:21 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Reverse Engineering a USB device

I have a USB radio that DLink originally put out. A long while back, they
EOL’ed it. Because it is EOL, i have no hopes of getting a 64 bit driver
for it, from them. However, I could write one.

Which brings me to my question, how does one go about reverse engineering
a driver for a USB device? I realize the depth and scope of the project is
potentially enormous, but since it is *just* for me, I figure, what the heck,
itll be a learning experience. Anyone have any tips on this sort of thing?

All i know right now is that it has about 4 IOCTL’s that are sent to it, only
one of which returns any data. Based on the UMDF FAQ it looks like i can write
this in UMDF, which would be a BIG plus. But how does one determine what data
to send down the USB bus as well as what endpoints to send it to?

Asa

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

On Wed, Mar 07, 2007 at 08:21:57PM -0600, Asa Yeamans wrote:

I have a USB radio that DLink originally put out. A long while back, they
EOL’ed it. Because it is EOL, i have no hopes of getting a 64 bit driver
for it, from them. However, I could write one.

Which brings me to my question, how does one go about reverse engineering
a driver for a USB device? I realize the depth and scope of the project is
potentially enormous, but since it is *just* for me, I figure, what the heck,
itll be a learning experience. Anyone have any tips on this sort of thing?

Use usbsnoopy:
http://www.wingmanteam.com/usbsnoopy/
and google for other pages with lots of instructions on how to use it.
It’s free and is used by a lot of people who reverse engineer USB
drivers for other operating systems.

Try running the device in 32bit mode and sniff the traffic, that will
help you determine the data stream and the commands and the endpoints to
send it to.

Good luck,

greg k-h

4

> -----Original Message-----

From: xxxxx@lists.osr.com [mailto:bounce-280165-
xxxxx@lists.osr.com] On Behalf Of Greg KH
Sent: Thursday, March 08, 2007 1:32 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Reverse Engineering a USB device

On Wed, Mar 07, 2007 at 08:21:57PM -0600, Asa Yeamans wrote:
> I have a USB radio that DLink originally put out. A long while back,
they
> EOL’ed it. Because it is EOL, i have no hopes of getting a 64 bit driver
> for it, from them. However, I could write one.
>
> Which brings me to my question, how does one go about reverse
engineering
> a driver for a USB device? I realize the depth and scope of the project
is
> potentially enormous, but since it is *just* for me, I figure, what the
heck,
> itll be a learning experience. Anyone have any tips on this sort of
thing?

Use usbsnoopy:
http://www.wingmanteam.com/usbsnoopy/
and google for other pages with lots of instructions on how to use it.
It’s free and is used by a lot of people who reverse engineer USB
drivers for other operating systems.

Try running the device in 32bit mode and sniff the traffic, that will
help you determine the data stream and the commands and the endpoints to
send it to.

Good luck,

greg k-h

FWIW I have made a minor update to SniffUSB/UsbSnoop based on Benoit
Papillault’s work (which was, in turn, based on the wingmanteam
original…).

My contribution is basically to adapt UsbSnoop to allow it to be built using
Visual Studio 2005 and WDK 6000. I don’t claim to have fixed any bugs or
made any significant functional improvements. In addition, I certainly
wouldn’t consider it to be a commercial-grade tool.

Source and executables are at the URL:

https://www.pcausa.com/Utilities/UsbSnoop/default.htm

Use at your own risk.

Thomas F. Divine

5

Determine the device’s USB descriptors - especially device and full
configuration. These will tell you how many endpoints the USB radio has and
what their characteristics are. Full-speed versus hi-speed, packet size,
etc. Get the USB 2.0 spec from http://www.usb.org for details on the layout
of these descriptors.

The easiest way to learn the descriptor set, is to plug-in the device and
watch the enumeration sequence using a tool. You can do this with either a
hardware analyzer or a software analyzer that supports enumeration
monitoring. (My favorite is SourceUSB - http://www.sourcequest.com , the
trial version should be sufficient).

You will be examining a WDM driver, so Walter Oney’s book (Programming the
Microsoft Windows Driver Model) would be essential background - chapter 12
covers USB in a nutshell.

Identify the device-specific portions of the driver (a lot of it will be
generic WDM support). Zero-in on the sections where URBs are generated and
sent to the lower driver in the USB stack. Understand how these interface
with the user-mode ioctls/read/write. Tools that you need here are Windbg, a
disassembler (IDA Pro is my favorite), and a USB traffic monitoring tool.

Good luck!
Stan Mitchell
SourceQuest, Inc.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Asa Yeamans
Sent: Wednesday, March 07, 2007 6:22 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Reverse Engineering a USB device

I have a USB radio that DLink originally put out. A long while back, they
EOL’ed it. Because it is EOL, i have no hopes of getting a 64 bit driver
for it, from them. However, I could write one.

Which brings me to my question, how does one go about reverse engineering
a driver for a USB device? I realize the depth and scope of the project is
potentially enormous, but since it is *just* for me, I figure, what the
heck,
itll be a learning experience. Anyone have any tips on this sort of thing?

All i know right now is that it has about 4 IOCTL’s that are sent to it,
only
one of which returns any data. Based on the UMDF FAQ it looks like i can
write
this in UMDF, which would be a BIG plus. But how does one determine what
data
to send down the USB bus as well as what endpoints to send it to?

Asa

6

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Stan Mitchell[SMTP:xxxxx@yahoo.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, March 08, 2007 4:08 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Reverse Engineering a USB device

The easiest way to learn the descriptor set, is to plug-in the device and
watch the enumeration sequence using a tool. You can do this with either a
hardware analyzer or a software analyzer that supports enumeration
monitoring. (My favorite is SourceUSB - http://www.sourcequest.com , the
trial version should be sufficient).

It seems interesting. Do you have an idea how they log hub, port and miniport interfaces? They claim filter drivers aren’t used. My concern is how it influences normal system behaviour.

Do you know how is the trial version limited?

BTW, it is possible to log enumerations during boot?

Thanks.

Best regards,

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

7

SourceQuest (my company) makes SourceUSB, so I will try to answer your
questions. If you need more detailed help, please direct them to
xxxxx@sourcequest.com

It installs its driver as a USB class filter but it does not create filter
device objects in the target system as a conventional filter driver would
do.

Logging hub and miniport interfaces, is done by hooking the in memory tables
that define these interfaces. Logging hub ports (root and external) is done
by intercepting URB traffic.

The trial version has limited data capture (512KB), log files can not be
saved or exported (as XML), hub interface and miniport logging are disabled
(but some log file samples are included), and it has a 35-day limit.

It is possible to log enumerations during system startup.

Stan Mitchell
SourceQuest, Inc.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, March 08, 2007 12:22 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Reverse Engineering a USB device

From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on
behalf of Stan Mitchell[SMTP:xxxxx@yahoo.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, March 08, 2007 4:08 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Reverse Engineering a USB device

The easiest way to learn the descriptor set, is to plug-in the device and
watch the enumeration sequence using a tool. You can do this with either a
hardware analyzer or a software analyzer that supports enumeration
monitoring. (My favorite is SourceUSB - http://www.sourcequest.com , the
trial version should be sufficient).

It seems interesting. Do you have an idea how they log hub, port and
miniport interfaces? They claim filter drivers aren’t used. My concern is
how it influences normal system behaviour.

Do you know how is the trial version limited?

BTW, it is possible to log enumerations during boot?

Thanks.

Best regards,

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

8

Thanks. It’s a pity trial version disables the most interesting features. For the rest I can use hw USB analysers. Log examples wouldn’t help as I’d like to see if it can help me with Vista USB bugs I encounter with my driver and device.

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 Stan Mitchell[SMTP:xxxxx@yahoo.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, March 08, 2007 11:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Reverse Engineering a USB device

SourceQuest (my company) makes SourceUSB, so I will try to answer your
questions. If you need more detailed help, please direct them to
xxxxx@sourcequest.com

It installs its driver as a USB class filter but it does not create filter
device objects in the target system as a conventional filter driver would
do.

Logging hub and miniport interfaces, is done by hooking the in memory tables
that define these interfaces. Logging hub ports (root and external) is done
by intercepting URB traffic.

The trial version has limited data capture (512KB), log files can not be
saved or exported (as XML), hub interface and miniport logging are disabled
(but some log file samples are included), and it has a 35-day limit.

It is possible to log enumerations during system startup.

Stan Mitchell
SourceQuest, Inc.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, March 08, 2007 12:22 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Reverse Engineering a USB device

> ----------
> From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on
behalf of Stan Mitchell[SMTP:xxxxx@yahoo.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Thursday, March 08, 2007 4:08 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Reverse Engineering a USB device
>
> The easiest way to learn the descriptor set, is to plug-in the device and
> watch the enumeration sequence using a tool. You can do this with either a
> hardware analyzer or a software analyzer that supports enumeration
> monitoring. (My favorite is SourceUSB - http://www.sourcequest.com , the
> trial version should be sufficient).
>
It seems interesting. Do you have an idea how they log hub, port and
miniport interfaces? They claim filter drivers aren’t used. My concern is
how it influences normal system behaviour.

Do you know how is the trial version limited?

BTW, it is possible to log enumerations during boot?

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

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

9

Thanks for the replies everyone, much to my suprise googling this has yielded plenty of results. One
of which was a linux kernel module for interfacing with it, will full source.

Thank you everyone for all the awesome tools. its amazing whats out there, maybe one day when i have
more money than sense ill be able to afford some of them :D.

-----Original Message-----
From: Michal Vodicka [mailto:xxxxx@upek.com]
Sent: Wednesday, March 07, 2007 8:48 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Reverse Engineering a USB device

The best tool you can use is USB analyser (example: http://www.ellisys.com/). The second best and cheaper is some kind of software monitor (example: http://www.hhdsoftware.com/Products/home/usb-monitor-pro.html). OSR IRP tracker can be also helpful to pair IOCTLs to USB traffic.

USB analyser is IMO necessary for any serious USB development but if you need just this project, it is probably too expensive (but it is a nice toy, anyway :slight_smile: The complexity of the task depends on the complexity of the used protocol.

Next tool which can be really helpful is IDA disassembler (http://www.datarescue.com/idabase/). If the protocol is too complex, you could theoretically recover original C sources with help of it and build driver for x64 without understanding the protocol at all. It’d really help if you have driver symbols (check the binary, if the driver is old enough, it is quite possible it contains forgotten debug info).

Personally, I’d start with USB analyser and then combine all approaches.

But wait, don’t skip one important point. Have you tried to ask the company which developed it about some info? If they abandoned product and there are kind people, you could get protocol description and may even driver sources. Also, Google can be your friend. Maybe somebody wrote a Linux driver for it and you could find sources.

(ah, I wish to have time to make something like this just for me :slight_smile:

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 Asa Yeamans[SMTP:xxxxx@rivin.net]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, March 08, 2007 3:21 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Reverse Engineering a USB device

I have a USB radio that DLink originally put out. A long while back, they
EOL’ed it. Because it is EOL, i have no hopes of getting a 64 bit driver
for it, from them. However, I could write one.

Which brings me to my question, how does one go about reverse engineering
a driver for a USB device? I realize the depth and scope of the project is
potentially enormous, but since it is *just* for me, I figure, what the heck,
itll be a learning experience. Anyone have any tips on this sort of thing?

All i know right now is that it has about 4 IOCTL’s that are sent to it, only
one of which returns any data. Based on the UMDF FAQ it looks like i can write
this in UMDF, which would be a BIG plus. But how does one determine what data
to send down the USB bus as well as what endpoints to send it to?

Asa

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

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