[Lazarus] Decoding USB sniff data

[Henry Vermaak]

On 4 June 2010 10:36, Mark Morgan Lloyd <markMLl.lazarus at telemetry.co.uk> wrote:
>
> [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]

I'm familiar with this scenario, we use it in our own devices, except
that we keep our vid and pid the same.  The above method abuses the
concept of having a vid and pid (it's the same product, why different
pid?).  In windows, the cypress driver can load a script that writes
the firmware to the device when it is plugged in, then the device
re-enumerates.  In linux, I manually interpret the hex file and upload
the data to the device.

> 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.

You'd very quickly notice this happening.  You can also see from the
driver inf file whether there are any scripts involved.  You can also
learn all the vid and pid combinations from the inf file, so you'd
know what to look for.

Henry