Can you suggest a better USB-sniffer for WindowsXP?

[DiTBho]

hi
I am reverse engineering a USB device that only works on Windows XP; the idea is to understand the protocol for creating a Linux program (C-only).

The USB talks via Endpoint, a number representing a source and sink for data, the device I am hacking talks to three different Endpoints, and it's a USB2 device, which also uses { control, Bulk } types of transfer mechanisms, each with varying characteristics.

The Isochronous transfer mechanism is not used, I need the USB sniffer to show this information clearly.

Code: [Select]

Packet#      EndPoint      transfer_mechanisms      data_len      data (hex)

I am currently using the program Sniffbin-v1.8, which is good on Windows-XP, but not exactly handy to be used.


I'm slowly making things work, the program is already able to correctly initialize the device - which hey? It's "first things first: wiggle your big toe, start small and work your way up!" (quote, "Kill Bill" movie) - but the current USB-Sniffer is making things uncomfortable -

s there anything better, guys? a want a better and sharper sword 

[dave_k]

Wireshark with USBpcap

[DiTBho]

Wireshark with USBpcap

It's great on Linux, but it doesn't work properly on Windows

[DiTBho]

(I like Carcharodon Photoshopia sharks, my favorite shark  )

[AndyBeez]

Wireshark XP is a bit ancient

I do not recall exactly how this is done but I've seen a Linux PC used as an inline hardware USB packet sniffer by connecting one of it's USB ports to the target device and another USB port to the 'host' PC. There's some dev/usb voodoo which makes the Linux PC 'transparent' to traffic - it is seen as a hub to the upstream PC and as the host to the USB device's endpoints. USB traffic is a pipeline that is captured on the Linux machine and 'sharked' later. But this might be a waste of time if the upstream driver is expecting a specific VID-PID combination.

[DiTBho]

I used SysNucleus USBTrace v2.x

it looks nice, and it shows packets exactly as I need. It costs 150 euro, not too much. Is the license node-locked to the PC or can I move to a second computer? 

At the moment I need to use it on a Windows XP laptop only because the software I need to sniff only runs on Windows XP, and I would like to re-use the USBsniffer on my Windows10 laptop in the future.

[SiliconWizard]

https://freeusbanalyzer.com/

[oPossum]

https://github.com/SnoopWare/usbsnoop

https://www.darknet.org.uk/2015/02/snoopypro-windows-usb-sniffer-tool/

[DiTBho]

https://freeusbanalyzer.com/

Doesn't support Windows XP

[DiTBho]

https://github.com/SnoopWare/usbsnoop

Before opening this topic I had already tried it and I didn't work 

[DiTBho]

I am currently using this one (usbsnoop, v1., which somehow works, but it doesn't show packets like I need.

Too messy and too verbose logs

[SiliconWizard]

https://freeusbanalyzer.com/

Doesn't support Windows XP

It's listed.

[Whales]

Another possible option: Run Linux or Win10 as host, then Windows XP inside Virtualbox with USB redirection.  Sniff USB packets using Wireshark on your host whilst operating the program on the WinXP guest.

WinXP guests run really fast in VMs on modern devices   Very little hassle.

[DiTBho]

It's listed.

I downloaded the package, it doesn't install saying the OS is not supported.
It seems like Windows XP SP3 isn't good enough for its taste

[DiTBho]

Windows XP inside Virtualbox with USB redirection

Umm, the USB device I have to smell is really bad.
It initially presents itself as VID: PID1 to get a large bit stream on an FPGA, then re-configures itself and re-presents itself as VID: PID2 for operations.

PID1 != PID2

This is exactly what makes VirtualBox crazy about USB redirection and I don't want to have any more problems.

[DiTBho]

Ok, bought a license for SysNucleus USBTrace v2-something from a dude.
Paid only 20 euro for it. It's good enough for what I need to do.

Let's go hacking.

Thanks everyone 

[voltsandjolts]

It initially presents itself as VID: PID1 to get a large bit stream on an FPGA, then re-configures itself and re-presents itself as VID: PID2 for operations.

PID1 != PID2

This is exactly what makes VirtualBox crazy about USB redirection and I don't want to have any more problems.

Sounds like a Cypress EZUSB device I rev eng'd. I seem to remember there was a setting in Virtualbox like 'always grab this usb device automatically' and once I had done that for both identities, it was usable. It also had a large FPGA bitstream download but that was after the Cypress device had enumerated on its second and final identity.

[voltsandjolts]

I've used Eltima USB Analyzer and it was good, nice UI.
I see it lists XP as supported [Windows (32-bit and 64-bit): XP/2003/2008/], and has a 14 day free trial.

https://www.eltima.com/products/usb-port-monitor/

[SiliconWizard]

It's listed.

I downloaded the package, it doesn't install saying the OS is not supported.
It seems like Windows XP SP3 isn't good enough for its taste

OK, that's too bad. Maybe you could let them know.
I've used a sniffer years ago on Windows (that was Win 2000 I think), but I can't remember the name...

[DiTBho]

A problem I have at the moment it that I need to export things in a way I can automatically build C filled structures.

CVS? XML? Somehow they look better than exporting as HTML: o: o: o
Seriously, USBtrace exported to "log.html", which is about 35 Mb and Firefox crashed trying to open it.

USBtrace can be configured to export XML. This helps 
 

[DiTBho]

I mean .XML + Python(XLM_parser) = C auto filled structures 

[Bassman59]

It initially presents itself as VID: PID1 to get a large bit stream on an FPGA, then re-configures itself and re-presents itself as VID: PID2 for operations.

PID1 != PID2

This is exactly what makes VirtualBox crazy about USB redirection and I don't want to have any more problems.

Sounds like a Cypress EZUSB device I rev eng'd. I seem to remember there was a setting in Virtualbox like 'always grab this usb device automatically' and once I had done that for both identities, it was usable. It also had a large FPGA bitstream download but that was after the Cypress device had enumerated on its second and final identity.

EZ-USB was famous (haha) for its "re-enumeration" feature, which did just what you describe. Why they thought that was important or useful remains a mystery.

[SiliconWizard]

It initially presents itself as VID: PID1 to get a large bit stream on an FPGA, then re-configures itself and re-presents itself as VID: PID2 for operations.

PID1 != PID2

This is exactly what makes VirtualBox crazy about USB redirection and I don't want to have any more problems.

Sounds like a Cypress EZUSB device I rev eng'd. I seem to remember there was a setting in Virtualbox like 'always grab this usb device automatically' and once I had done that for both identities, it was usable. It also had a large FPGA bitstream download but that was after the Cypress device had enumerated on its second and final identity.

EZ-USB was famous (haha) for its "re-enumeration" feature, which did just what you describe. Why they thought that was important or useful remains a mystery.

They had some kind of USB bootloader allowing to download the firmware in internal RAM from the host, and then restart with the new firmware, which would typically reeunumerate as a different device.
While sometimes a bit annoying for the user, it was an early form of DFU not requiring "flashing" the device (it ran entirely from RAM) and making firmware updates as easy as providing a new driver. Devices built with that scheme could never get "bricked".

[DiTBho]

They had some kind of USB bootloader allowing to download the firmware in internal RAM from the host, and then restart with the new firmware, which would typically reeunumerate as a different device.
While sometimes a bit annoying for the user, it was an early form of DFU not requiring "flashing" the device (it ran entirely from RAM) and making firmware updates as easy as providing a new driver. Devices built with that scheme could never get "bricked".

Yup, you love it when you develop something, you hate it when you have to use a VM to hack something.

[SiliconWizard]

They had some kind of USB bootloader allowing to download the firmware in internal RAM from the host, and then restart with the new firmware, which would typically reeunumerate as a different device.
While sometimes a bit annoying for the user, it was an early form of DFU not requiring "flashing" the device (it ran entirely from RAM) and making firmware updates as easy as providing a new driver. Devices built with that scheme could never get "bricked".

Yup, you love it when you develop something, you hate it when you have to use a VM to hack something.

Yes.

Note that if using some MCU with enough RAM and capable of executing code from RAM (many would fit these days), that's something you can still do (and more elegantly), while I've seen it done relatively rarely, if the device you design is a USB device which isn't supposed to function when not connected to a host.

You can just implement a set of well tested base routines and put them in Flash, and then have most of the firmware downloaded from the host to the device in RAM through USB. Can be a very flexible scheme.

[cgroen]

I use the "Beagle 480" from totalphase:
https://www.totalphase.com/products/beagle-usb480/

worth every penny!