[Lazarus] Decoding USB sniff data

[Mark Morgan Lloyd]

Henry Vermaak wrote:

> I don't really know what you mean.  Do you mean that the software can
> do a control transfer to query the model number, then have different
> communications methods depending on that?  Either way you'll always be
> able to see all the messages on the bus, so I don't see how this is a
> problem.

[Notes copied from elsewhere]

Here's something particularly interesting from the Universal Software 
Radio Peripheral (USRP) documentation. Note that the FX2 is an 
8051-derivative acting as the USB slave. My notes in [brackets].

-----8<-----
      The USRP itself contains no ROM-based firmware, merely a few bytes 
that specify the vendor ID (VID), product ID (PID) and revision [I 
presume in a serially-accessed NV device, otherwise the defaults for the 
microcontroller]. When the USRP is plugged in to the USB for the first 
time, the host-side library sees an un-configured USRP. It can tell it's 
un-configured by reading the VID, PID and revision. The first thing the 
library code does is download the 8051 code that defines the behavior of 
the USB peripheral controller. When this code boots, the USRP simulates 
a USB disconnect and reconnect.

     When it reconnects, the host sees a different device: the VID, PID 
and revision are different. The firmware now running [in the 8051] 
defines the USB endpoints, interfaces and command handlers. One of the 
commands the USB controller now understands is load the FPGA. The 
library code, after seeing the USRP reconnect as the new device, goes to 
the next stage of the boot process and downloads the FPGA configuration 
bit stream.

     Once the firmware has been downloaded to the FX2, it sets an 
internal register and reboots itself, this time presenting custom 
product and vendor ID’s, which the host detects as the FX2 disconnecting 
followed by the connection of a custom USB device.
----->8-----

So this third vid:pid pair could then be used to load kernel modules to 
implement a Bluetooth or GPS stack, not to mention more mundane 
applications like an AM or FM radio.

I suspect that several of these steps are common to a large number of 
USB devices with internal firmware. If that is that case then the 
firmware doesn't so much process data being transferred but mediates 
between commands on the USB bus and setup being sent to the 
application-specific chip with data being transferred by hardware when 
available.

[End copied notes]

That's obviously going to complicate things if you're only sniffing a 
single device (small group of endpoints) or a single class. The sniffing 
software (and any decoders) are not going to be able to say "device x:y 
is now killing itself and will be resurrected as z:t" unless somebody's 
already reverse-engineered the loader- not impossible but not very 
likely either.

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]