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]
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
