[Lazarus] Decoding USB sniff data

[Henry Vermaak]

On 4 June 2010 23:18, Henry Vermaak <henry.vermaak at gmail.com> wrote:
> On 4 June 2010 22:27, waldo kitty <wkitty42 at windstream.net> wrote:
>> On 6/4/2010 05:36, Mark Morgan Lloyd wrote:
>>>
>>> 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.
>>
>> right but one should be able to note the vid:pid (did i get that right?)
>> attached to a particular USB port and note that it changes within a specific
>> time period to a secondary and then within another certain time frame to a
>> tertiary vid:pid... as these will occur within a (presumably) very short
>> time period (guessing less than 2 or 3 seconds), it would appear to be "not
>> a human plugging, unplugging and switching devices" because a human won't be
>> able to do that in that short a time frame... plus there that if a human
>> /did/ try to do that, it would likely (?) result in the sequence starting
>> all over and running thru the three steps...
>
> It may be tricky to note the change, but you're only really interested
> in seeing with what vid/pid it ends up with.  Device manager shows you
> this.  As I've noted, you can look in the inf file, since that should
> have all the vid/pid combinations in it already.

What could be tricky is when you need to run the device in linux and
you need to upload the firmware manually, since you may have to do it
transfer by transfer.  I've never had to do this, luckily.

Anyway, this is a bit off topic now, since Adem's device just shows up
as a serial port (we actually use one of these ftdi chips in one of
our products).

Henry