If you’ve done any development on USB hardware, you’ve probably wished you could peek at the bits and bytes as they pass through the data lines. Sometimes, it’s the only way to properly understand what’s going on. [ataradov]’s USB sniffer is built to do just that.
To sniff high-speed USB communications, the device relies on a Lattice LCMXO2 FPGA and a Cypress CY7C68013A microcontroller, paired with a Microchip USB3343 USB PHY. This setup is capable of operating at data rates of up to 40-50 MB/s, more than enough to debug the vast majority of USB peripherals on the market.
The device is built specifically for use with Wireshark. Most commonly used for network packet sniffing, Wireshark can also be used with a wide variety of other capture hardware for other debugging tasks, as seen here. In addition to live sniffing, it also allows captured data to be saved for later analysis.
If you need this tool, spinning up your own is straightforward. Gerber files are available and the required components can be bought off the shelf. Once assembled, you can program the chips via USB, with no external hardware programmer required.
We’ve seen some other similar hardware before. Meanwhile, if you’re whipping up your own useful debug tools, don’t hesitate to drop us a line!
USB is as bad as transitting data over Cascading interface used in older Macs. Hopefully it’ll be replaced by something that’s open like DB9 serial port.
not sure if trolling
Sniffma balls. lmao
Good luck getting 480Mbps or even more over an UART… However i agree that USB is quite difficult to master for hackers; and even for users all this naming stuff with USB3 is confusing.
Fair point but tbh that all depends on the assisted parallelized data propagation mechanism. I had a Hyperspectral Superbus interface which achieved asynchronous data compression and transmission, enabling ultra-low latency USB connectivity with multidirectional quantum coherence.
Has anyone tried using a Raspberry PI 4 with software like https://github.com/blegas78/usb-sniffify for usb sniffing?
I remember a similar project for Beaglebone Black back in the day.
usb-proxy?
https://hackaday.com/2015/12/23/usb-proxy-rats-out-your-devices-secrets/
https://github.com/usb-tools/USBProxy-legacy
The above are old, obsolete, abandoned.
This one seems to be relatively new, and may be more useful: https://github.com/AristoChen/usb-proxy
The CY7C68013A’s only “kindof” a microcontroller. I mean, it has a microcontroller in it, but it’s really a USB interface chip. The USB-to-custom interface runs completely independent of the actual 8051 microcontroller in it.
And it looks like the USB pair’s run straight from the connector to it without any ESD diodes? If so that’s a *really* bad idea. Those chips are wacko sensitive to stress on their USB lines: I literally have an entire drawer full of dead FX2 chips. It’s a pain in the neck because they seem fine for like *years* – and then they lose their ability to do high-speed USB, and then they just go deaf on the USB interface.
I’ve used knock-off logic analyzers based on that chip for years without killing a single one. This overall design is also quite old and I’ve used it for a while without any issues.
This just evolved from quick prototypes, and ESD protection was omitted n the process. I will be adding ESD protection if there are revisions. I debated changing the project before the release, but decided against that.
And it is probably much more necessary on the target side where potentially faulty devices may be plugged in.
Yeah, I *cannot* figure out why there’s such a huge variation in success rates with those chips. I’ve known plenty of people who say they’ve used them a ton and never had a problem, and I’ve just watched multiple designs slowly die one-by-one in the field over the past decade. Cypress (well, Infineon now) failure analysis always responds the same way: electrical over-stress, damaged transceivers.
Then again it’s not like you typically leave a cheap logic analyzer plugged in for multiple years, so who knows. It’s definitely not a short-term issue, they all worked for multiple years continuously before I even saw one fail.
Even extremely expensive National Semi boards compatible with LabView don’t have any protection on USB. Yes, we have a pile of dead ones.
Yeah, I was convinced I was doing something weird in the design I have until I ended up with a failed FX2 on a TI development board that was in a long-term test setup have the exact same symptoms and eventually went dead. I can’t even say that adding TVS diodes would necessarily make a difference, but at least then I’d be able to tell Cypress/Infineon that there’s something else going on.
We just added USB2.0 high speed isolator and that has resolved out problems. But beware of full speed isolators. LabView tends to fall apart with these if it can’t transfer a burst of data in time.
I’m not a digital signal expert here, but isn’t a bus pirate better in that it can do what this does, and can also do a lot more?
Bus pirate can’t do this. A lot of logic analysers can handle low speed and full speed, but are a bit ungainly. High speed (USB 2.0) requires some more expensive hardware, though ~$100 devices have been coming available recently. USB 3.0+ still is the domain of ~$5k+ devices from vendors like Total Phase and Ellisys.
Personally I would encourage folks to wait for Cynthion, which is also open source with more capabilities and a growing open source ecosystem, but more people playing with USB and making tools is not a bad thing.
Bus Pirate can’t manage 480 Mbit/sec speed. Even just its uplink to your PC is only 12 Mbit/sec speed. The documentation says “Max speed is 12MBPS, but a realistic limit is 1MBPS”.
There’s also the matter of phase locking to the sync field which begins the transmission of each USB packet, so you can actually capture the bits within that packet. With today’s technology, this is the realm of dedicated hardware. To do it with a software defined interface, you’d need to sustain sampling of the signal at several GHz.
Signal level at 480 Mbit/sec is fully differential, nominally ±400mV. Normally 3.3V or 1.8V single-ended logic input won’t work. Even if Bus Pirate were hundreds of times faster, you’d also need to add a differential receiver circuit.
Thanks guys, I had a hunch I was missing something. When I checked the bus pirate specs, it claimed to do 40mbps, but obviously I missed something. That also explains why this seems to use much more expensive chips!
How does this differ from just using the USB features built into wireshark? Surely that’s an easier way as it is just a piece of software, you just plug the device into your PC and record all USB communications and then filter it to find the device you want.
Does this do something that wireshark can’t already do?
This device captures on the packet level. Software USB adapter capture transaction level. They will not show individual tokens, just high level data payload. They will also not show anything before device enumeration, so all the setup tokens would be missing.
And they will also not show if you have signal quality issues and a packets are dropped and retries are happening. And they will not show line signalling, like bus resets and K/JK-chirps.
USB capture on your PC is usually good enough for the common uses of reverse engineering USB devices or troubleshooting code running on a USB device microcontroller.
But Wireshark using your PC’s USB port can’t help if the communication is between a USB device and some USB host other that your PC. For example, when I wrote the USBHost_t36 library for Teensy 3.6 and 4.1, I leaned heavily on a Total Phase Beagle 480 analyzer to see what communication was actually happening between Teensy and USB device, or USB hubs and then downstream devices. You also can’t observe communication such as between an Apple iPad and a SD card using the camera connection kit. They wires simply don’t connect to your PC, unless you use dedicated USB capture hardware.
USB capture with your PC’s hardware also can’t show you finer details of the actual USB communication, which are handled automatically in the USB host controller hardware on your PC. For example, when communicating with a 12 Mbit/sec USB device which is plugged into a USB hub, you can’t observe the split-start and split-complete tokens exchanged between your PC and the hub. Other fine details, like the number of NAK tokens or whether a high speed device replies with ACK or NYET token are also handled automatically by PC hardware and generally not visible to software on your PC.
USB capture devices usually provide precise time stamps on every captured token. Some of them offer digital input signals which can be captured alongside the USB communication. When accurate timing matters, USB capture devices also allow you to use a separate computer to capture and display the data, so you’re observing the accurate timing without placing additional burden on the PC acting as the USB host.
Admittedly, these are pretty niche usage cases. For the most common uses of reverse engineering communication of commodity USB device, or troubleshooting USB device (not host mode) code running on known-good microcontroller hardware, software capture on your PC is good enough. But you did ask what wireshark running on your PC can’t do. These are the special and more detailed USB capture scenarios where you really need dedicated USB capture hardware.
You reminded me of some gear we had for analysing Networks (Net XRay?).
Plug in a cable that was going to a router, add second cable to router, and monitor all traffic. Ethernet and optic fibre modules, for your choice of PHY. In our case (from memory), it detected excess traffic to a port, so we changed the network layout to compensate.
Bus Pirate can’t capture USB. Not USB HS for sure. This is closer to TotalPhase Beagle USB480 Analyzer, but much much cheaper without sacrificing major functionality.
Thanks, never heard of TotalPhase before, but as IO said, I’m not a digital signal analyst.
Does that then mean that you could this in lieu of a bus pirate? I’m not sure if bus pirate is multi channel, and I assume this is single channel.
This reminds me of the Openvizsla project from a few years ago.
It is similar, but OpenVizsla is more complicated than it needs to be. The FPGA they are using alone is close to the cost of the full BOM here.
And another feature that was important to me that even TotalPhase analyzer does not have is detection of the line levels. This lets you see when one or both sides have enabled HS termination, This lets you debug HS enumeration process without having to guess if termination was enabled.
I wonder if Sigrock [1], plus the PulseView front end [2] would work with this device instead of Wireshark?[3] Sigrock already works with a bunch of logic analyzer hardware.[4]
* References:
1. Sigrock
https://www.sigrok.org/wiki/Main_Page
2. PulseView
https://www.sigrok.org/wiki/PulseView
3. Wireshark
https://www.wireshark.org/
4. Sigrock Compatible Logic Analyzers
https://www.sigrok.org/wiki/Supported_hardware#Logic_analyzers
This is not a logic analyzer, it does not capture waveforms, it captures processed data. It is possible to roughly extrapolate the line levels from that information, but there is no practical use for that. And the amount of information captured would make it miserable to work with in PulseView anyway.
Wireshark-like interface is ideal for this use.
I’m still looking for an affordable USB and/or SATA filter/firewall device. I really want to be able to block disk writes at a near-hardware level, and similarly authorize _specific_ USB device types rather than risking the widget having undeclared functions, benign or otherwise. The products I’ve seen for that purpose are sold to security and forensic companies for prices suitable when you’re going to bill customers for your services; I want something I could afford to slap on a number of small machines in my home network and/or add to my USB travel kit.
Logging is a great debugging tool, but I want to control the traffic.
Actually this “cheap USB sniffer” works exactly the same as expensive commercial products like the TotalPhase Beagle USB 480 and the ellisys USB Explorer 200.
Now do the same with a USB 3 phy and a cheap USB 3 bridge like the CH569W or the FT601.
Well, ok, the expensive commercial products might have a RAM chip for buffering.
Looks great, good job! Those commercial analyzers are crazy expensive…
Looks like a good project to try out…
IC8, how big does this EEPROM need to be? There is no part number for it… my guess is a 24LC32 4K device, based on .bin size and the Address strapping.
Part recommendations for J1, J2 and J3 (eg. footprints)?
I use 128Kbit for the full supported 16Kbyte, but 24LC32 and up should work. But EEPROMs are cheap, better to just put the full size and forget about it.
Type-C connectors are https://www.lcsc.com/product-detail/_XUNPU-_C2835315.html But they are very generic and the footprint is standard, basically if it has 12 pins and looks about like that, it is likely to fit.
Type-A footprint was designed with this connector in mind https://www.lcsc.com/product-detail/_Shenzhen-Kinghelm-Elec-_C2979055.html But I would not recommend this specific one. It is a bit flimsy and there is a lot of contact bounce. It does not matter for actual device use, but on a sniffer you will see all that bounce in the log.
The footprint itself is also very generic, it would work with all connectors of this style https://www.mouser.com/ProductDetail/Wurth-Elektronik/614004190021?qs=DvsTirrhYfPiiHUeEQNGBQ%3D%3D But if you get one with bent mounting pins (like 99% of them), then you may need to straighten the legs for them to fit into the slots. There are versions with straight mounting legs, but they are harder to find. I would get the best USB-A you can find, don’t skimp on it.
Trying one more time. Automod here seems to have blocked me, it probably does not like links.
I’ve created a discussion on the GitHub project page with suggestions.
What would you guys use to try to sniff the communication between an industrial HP series 4200 3D printer and his build unit?
If it uses USB, I would start with plugging it into a PC and checking how it enumerates. But generally it is not a trivial process.
Hi, I have 2 questions related to the topic, if anybody knows the answers:
1) do you know any dev kit ready to buy with Xilinx FPGA and the same USB3343 chip?
2) any FPGA source code in VHDL to manage implement USB SIE with ULPI interface?