On Friday, May 17th, 2024 at 14:10, Ethin Probst <ethindp@xxxxx> wrote: > On Thursday, May 16th, 2024 at 05:09, Lars Melin larsm17@xxxxxxxxx wrote: > > > On 2024-05-16 12:56, Ethin Probst wrote: > > > > > On Thursday, May 16th, 2024 at 00:19, Lars Melin larsm17@xxxxxxxxx wrote: > > > > > > > On 2024-05-16 05:12, Ethin Probst wrote: > > > > > > I can also not find such a transition in your other two captures, all > > > > descriptor readouts that includes USB Id are 2b5a:000c. > > > > > > This is what puzzles me as well. If I'm missing something it's at a > > > level that USB Pcap can't capture. When I begin the capture, plug in > > > the device and power it on, the second packet is always the right > > > descriptor (pid 000d). There is no indicator in the capture that > > > commands are sent before that pid is received. As for the other > > > problem, yeah, that confused me too; I would've thought that another > > > get descriptor request would've been sent, but apparently not, because > > > when I remove the device from the VM and reattach it to the host, the > > > pid is correct. > > > > You can set up a USBPCap filter on id.Vendor and id.Product (2b5a:000c) > > so that the capture will not start until you connect your device. > > It will stop capture (logging on screen will stop) when the device > > transition into 2b5a:000d so you can then close the pcap file. > > The cmd making the transition should be near the end of your capture. :-) > > > You would think so, but I can't seem to capture it. Live capture doesn't seem to be working for me, and I just tried again, starting usbpcapcmd on the proper USBPcap device (\\.\USBPcap1) before plugging in the device and turning it on. I waited for the drivers to do their thing, then disconnected the device, and when I checked the capture file the first VID/PID was the 2b5a:000D one and not 000C. I'm not sure what I'm doing wrong but for whatever reason my USBPcap setup is unable to capture whatever is being transmitted. > > > Your IDA-disassembly is probably on the wrong file, I'd guess that the > > .sys file in the driver directory corresponding to the .inf file for > > the firmware loading Id is what handles firmware loading/checking. > > > I'm not positive if this one (dump attached) is the right one but maybe it is? It's the only one that reasonably makes sense in my mind for the firmware loader part of things. I'm uncertain what other ones would be the right driver to try. I'm sorry I don't have more readable code, I don't have IDA home or pro and the decompiler won't let me produce C code. If there's any other debugging you'd like me to do feel free to ask. :) As an aside, apologies if the mailing list screwed up the attachment. Looking at the archive it looks as though it just dumped it all into the main message body which was not what I was going for. Sorry about that! :-( I'll be sure to just use links in the future.
Attachment:
publickey - ethindp@pm.me - 0x846BFA7B.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
