A couple of months ago I stumbled upon a post on Hackaday about an inexpensive open-source USB 2.0 sniffer created by Alex Taradov. This is a really cool project! Normally, USB sniffers like this can cost thousands of dollars, especially if you’re paying for fancy protocol decoding and also want high-speed 480 Mbps support. This one costs about $50 in parts to assemble yourself, although it will take hours to solder and you will need some experience with hot air (or reflow oven) soldering since the USB PHY is a QFN chip with an exposed pad underneath.
I actually have an Ellisys USB Tracker 110b that I bought on eBay many years ago, but it only does low-/full-speed decoding. I thought this would be a good opportunity to upgrade my capabilities to also be able to handle high-speed USB sniffing, while also providing some good soldering practice.
Here’s my (very long) video about the process of building up one of these and programming it. I left in all the mistakes I made along the way. Why not show the world that it’s normal to make dumb mistakes when you build stuff?
I thought I’d use this post to explain in a little more detail what exactly a USB sniffer is. Why would I buy (or make) a hardware USB sniffer when Wireshark already has software USBPcap support in Windows?
The answer to that question is complicated, but the bottom line is that for many needs, USB packet capture inside your operating system works perfectly fine and you don’t have to buy a hardware sniffer. People use software USB packet capture methods to reverse-engineer USB drivers all the time.
Where hardware sniffers come in handy is if you’re a firmware developer who is diagnosing a problem with a USB device or host you’re creating, or maybe you’re a driver developer working on a driver for a USB host controller. You need to see exactly what’s happening on the USB data wires to make sure that every packet looks correct. Perhaps you suspect your device’s firmware has a bug where the DATA0/1 toggle isn’t behaving as it should. Or maybe you just want to learn more about USB and how it works under the hood. Software USB capture mechanisms like USBPcap don’t show you every individual low-level packet, but you really need to see them in the situations I described above.
You could always just hook an oscilloscope or logic analyzer up to the D+ and D- lines and decode the packets yourself by looking at the waveform:
I guarantee that would get old really fast. You would also need a pretty fancy oscilloscope or logic analyzer in order to decode 480 Mbps high-speed traffic while also having enough memory to record everything you want to see. Nobody actually does that though.
This is exactly where hardware USB sniffers come into play. They are essentially specialized logic analyzers that only know how to decode USB traffic. They do one thing, and they do that one thing very well: record raw USB traffic and stream it to your computer as fast as possible.
The other thing that’s nice about hardware USB sniffers is you can sniff a different USB host’s traffic. Let’s say I want to figure out how a TiVo talks to its USB to Wi-Fi adapter. OK, that might be a bit of a dated reference. What am I thinking? It’s the 2020s. Let me try coming up with a more modern scenario instead: maybe I want to see how a Nintendo Switch talks to a keyboard I’ve plugged in. Or how an iPhone talks to a USB-Ethernet adapter. Hardware sniffers, including Alex’s, are capable of doing this because the computer capturing the sniffed data can be different from the computer/device that is actually performing the USB communication.
The really cool thing about this sniffer is that it integrates with Wireshark. You can make use of protocol decoders already built into Wireshark for interpreting USB packets, as well as its fancy filtering capability. Ellisys devices, in comparison, use a proprietary USB analysis program. Protocol decoding is unlocked for an extra charge of thousands of dollars.
I’m not here to criticize Ellisys, Total Phase, and Teledyne LeCroy though. I get it. These are very fancy tools and the cost is probably not a big deal to a company that can already afford to build USB devices and go through all of the necessary certifications. Heck, the cost of one of those analyzers is likely worth it just for the support you get from the company. However, I want everyone else to know that there are cheaper alternatives out there. If you’re making USB devices for fun on your own time as a hobbyist, you probably already know how to solder anyway, and there are solutions out there that won’t break the bank. Thanks for making such a cool project and releasing it as open source, Alex!
[…] Doug Brown ☛ Building Alex Taradov’s open-source USB sniffer […]
Nice video with a good focus on details that might seem uninterresting at first.
I wonder why you get more low level information with this device than e.g. sniffing with wireshark on a linux local usb port, though…
Thanks! Yes, I certainly wouldn’t expect people to watch the whole thing from start to finish unless they’re interested in seeing the whole build process and learning how to solder it. Otherwise, they might fall asleep while I build it!
The reason it gives you more information is because software capture methods that Wireshark uses (USBPcap on Windows, usbmon on Linux) don’t have access to all of the raw protocol details. At the operating system level, you just request to read/write USB data and the OS gets back to you with the final result, regardless of how it was split between packets or how many times the device “NAK”ed a packet because it wasn’t ready to provide data yet. These higher-level transactions are what Wireshark by itself is capable of recording. There’s no way to get the raw USB packet info directly with that capture method, so you need an external device that directly records them.
Another example is the USB address assignment process. xHCI controllers automatically assign an address to a device, so even though the SET_ADDRESS request gets sent to the device, you can’t capture it on a local USB port with usbmon in Wireshark because the host controller does it automatically when the device is first attached. So on newer host controllers like this, you need a hardware sniffer to capture the SET_ADDRESS request.
Basically it comes down to: you likely don’t need a hardware sniffer unless you are developing firmware for a device or are trying to learn about how USB works.
To elaborate a little more, the host controller is handling a lot of the low-level communication under the hood such as checking checksums and combining multiple transactions into a transfer. That low-level info would be useless for normal device drivers because they can trust that the host controller has performed the high-level operation that was requested.
[…] See the video below and more in the post here. […]
Awesome! I was so excited that I’m going to assemble some pieces for myself. Could you inform which partnumbers of the IC6 and IC10 components you used in the assembly? The models reported in the BOM are obsolete.
Very cool Marcos!
For IC6, I was actually able to get the original DSC6101CI2A-026.0000 component from Digi-Key before they were out of stock.
For IC10, I used ECS-3225MVLC-240-CN-TR. It’s not a MEMS oscillator like the original but it seems to work fine.
You should be able to use a similar oscillator for IC6 as well. To find the IC10 substitute, I looked for 24 MHz oscillators with the same package size (3.2×2.5mm), voltage range (1.8-3.3V), and frequency stability (+/-25ppm). I would assume ECS-3225MVLC-260-CN-TR would work fine for IC6, since the 24 MHz version worked fine for IC10.
Alex touched on this on a closed GitHub issue too: https://github.com/ataradov/usb-sniffer/issues/7
There’s also Great Scott Gadgets (makers of the HackRF) and their FPGA-powered Cynthion, f.k.a. Luna:
https://greatscottgadgets.com/cynthion/