If you work with USB, Android, IoT, or any type of connected hardware, sooner or later you'll have to deal with communication failures, incomplete enumerations, or drivers that provide no cluesAt that point, going in blind is hell: you need to see what's really happening "on the cable" and in the operating system.
The good news is that today we have a very mature ecosystem of Utilities for USB debugging, traffic capture, and error diagnosticsFrom open-source hardware sniffers to Wireshark, ETW on Windows, ADB on Android, and specific tools for USB 3.x, we'll bring them all together and shape them into a coherent guide so you can choose the right tool for the problem you're dealing with.
USB hardware sniffers: Seeing the bus as it is
When the problem is at the lowest layer, what you need is a team that intercept USB traffic without relying on the operating system, drivers, or APIsThat's where dedicated hardware sniffers come in.
One of the most interesting projects of recent years is the pocket-sized USB 2.0 sniffer designed by Alex Taradov, a device that completely open hardware which allows capturing High Speed traffic (480 Mbps) and dumping it directly into PcapNG format for analysis with Wireshark.
The core of the design is based on a Cypress CY7C68013A microcontroller, very popular as a generic USB interface, working at 48 MHz, to which is added a FPGA Lattice MachXO2-2000HC responsible for reconstructing the NRZI signal and managing synchronization, plus a USB3343 transceiver which physically connects to the D+ and D- lines of the USB bus. Together they form a pipeline in which the PHY captures the signal, the FPGA reassembles the packets, and the microcontroller packages them into PcapNG blocks with precise timestamps.
Thanks to this architecture without an intermediate operating system, the device is able to maintain sustained rates in the range of 40-50 MB/sIt approaches the practical limits of USB 2.0 High Speed, with a capture fidelity difficult to achieve with software alone. The entire project, including firmware, Verilog code, and schematics, is available in the author's repository, making it easy to study, modify, or even have the board manufactured.
Another strong point is its size: the board is small enough to fit in a pocket and doesn't require an SBC or a second dedicated computer. Unlike previous projects based on mini PCs (like tinySniffer with a NanoPi NEO Air), here The FPGA does the processing work, the microcontroller is limited to ordering and sending data, and the PC only receives and displays it.This greatly reduces the risk of losses due to CPU load, latency, or jitter in timestamps.
Wireshark as a natural companion for USB and network debugging
Most modern hardware sniffers, including Taradov's, dump traffic to PcapNG files so you can open them directly with WiresharkThis makes perfect sense: Wireshark is the de facto standard for dissecting protocols, both network and USB.
Wireshark is a A protocol analyzer that lets you see, packet by packet, what is being exchanged between devicesIt supports Ethernet, Wi-Fi, Bluetooth, ATM, USB, Token Ring, Frame Relay, and FDDI, and understands hundreds of physical, data link, network, transport, and application layer protocols. You can capture in real time or save captures and analyze them offline whenever you want.
In addition to the graphical interface, Wireshark features TShark, its command-line versionThis is very useful for automating analysis, working via SSH, or integrating it into scripts. Both share the same powerful filters, which is where much of the magic lies: you can keep only what interests you (an endpoint, a PID, a specific IP, a TLS flow, etc.) and forget about the rest of the noise.
In the context of USB, when the capture comes from a physical sniffer, Wireshark is not limited by system drivers: it sees control, bulk, interrupt, and isochronous transactions exactly as they travel along the bus. The specific plugin interprets fields such as PID, device address, endpoint, data lengths, flags, and hardware timestampsThis is key to debugging why a device is not enumerating, why a descriptor is wrong, or why an endpoint is not responding when it should.
Wireshark can read and write multiple capture formats, such as libpcap/tcpdump, pcapng and othersand even compress on the fly with GZIP. It supports various technologies (Ethernet, 802.11, PPP/HDLC, Bluetooth, USB, etc.) and, when the appropriate keys are available, it is capable of decrypting IPsec, ISAKMP, Kerberos, SNMPv3, SSL/TLS, WEP, WPA/WPA2 and more, greatly expanding its reach in encrypted and Zero Trust environments.
Wireshark in cybersecurity and Zero Trust environments
Although more and more traffic is encrypted, Wireshark remains a central piece in any blue team's toolboxEncryption hides the content, but not the metadata: IPs, ports, connection patterns, packet sizes, timings, sudden changes in behavior, etc.
In Zero Trust architectures, where everything is encrypted even within the internal network, Wireshark is often combined with tools such as Fiddler or mitmproxy Wireshark can authoritatively inspect HTTPS traffic using its own certificates or controlled TLS termination. Additionally, Wireshark can use TLS key files (SSLKEYLOGFILE) generated by modern browsers to... selectively decrypt TLS 1.3, HTTP/2, or even parts of QUIC/HTTP/3 traffic when the session keys are available.
In practice, a hybrid model ends up being used: SIEM/SOAR platforms (Sentinel, Elastic, Splunk, etc.) and sensors such as Zeek or Suricata generate high-level alerts and logsWireshark, on the other hand, is used to delve into the details of a specific incident, view actual packets, reconstruct flows, and validate hypotheses. This combination reduces false positives and greatly accelerates incident response.
Wireshark is also highly regarded in the world of incident response related to SSH, RDP or VPNsEven if the content is encrypted, you can distinguish successful sessions from failed attempts by the flow duration, packet sizes, time between messages, or number of authentication attempts. This is a fairly sophisticated way to detect credential stuffing attacks or massive remote access scans.
On the offensive side, red teams and pentesters use TShark and tcpdump a lot to spying on traffic, identifying services and protocols in use, observing how defenses behave, or whether there is deep perimeter inspectionComplemented with Scapy, it is possible to generate and inject custom packets and see the network reaction live.
USB debugging and diagnostics in Windows with ETW and specific tools
In the Windows ecosystem, in addition to the classic packet analyzer, you have a very powerful infrastructure based on Event Tracing for Windows (ETW) which allows recording in great detail what happens in the USB stack: enumeration, port status changes, power failures, device startup problems, etc.
The USB hub controller emits ETW events with various tasks that you can capture and view with tools like Netmon or its modern replacement, Microsoft Message Analyzer (now discontinued, but still used in many environments) or with more current ETW viewers. By filtering for the “USB hub enumeration” task (Task 2), you can focus only on events relevant to plugging in a device, consulting USB port diagnostic guides in Windows.
For example, when searching for events like “Start Enumeration of Port” or “Port Enumeration Completed”You can measure how long the system takes to enumerate a device, at what step it gets stuck, or if there are electrical bounces during detection (debounce). The idea is to measure the intervals between events such as:
- Start Enumeration of Port → Port Enumeration Completed: total enumeration time.
- IoInvalidateDeviceRelations → IRP_MN_QUERY_DEVICE_RELATIONS: time it takes PnP to start the device query.
- IRP_MN_QUERY_DEVICE_RELATIONS completed → IRP_MN_START_DEVICE dispatched: delay between detection of the new PDO and the effective start-up of the device.
There are also specific ETW tasks for the power cycle, such as resuming the device from sleep (D0), selectively suspending hubs, and processing device startup IRPs. Measuring between events “USB Device Set D0 Device Power IRP Dispatched” and “…Completed” You can tell if the bottleneck is in the device itself, in the driver, or in... USB power problems.
In Windows 8 and later, Microsoft also added USB 3.0-specific debugger extensions and new debugging tools in Visual Studio/WinDbg geared towards the xHCI ecosystem. These extensions display controller status, transfer queues, endpoints, port status, and low-level details that, combined with ETW and traffic captures, greatly facilitate locating subtle faults in drivers and firmware. Guides are also available for identify the version of the USB ports when there are doubts about compatibility.
Android Debug Bridge (ADB): Debugging and USB/Network traffic in Android
If you're into mobile phones and tablets, the equivalent of having a diagnostic "Swiss Army knife" is Android Debug Bridge (adb)It is a client-server tool that allows your development machine to communicate with Android devices via both USB and Wi-Fi.
The adb architecture consists of three parts: client (adb) that you run on your PC, daemon (adbd) that runs on the device, and server which resides on your machine and acts as an intermediary between you. The server opens TCP port 5037 and, if there are emulators, searches for them in the port range 5555-5585 to connect to each instance.
To enable USB debugging, you must activate the Developer options and USB debugging on the device; if you have problems connecting, consult What to do if your phone doesn't recognize the USBStarting with Android 4.2.2, each connected PC must be explicitly authorized via a dialog displaying an RSA key, to prevent any unknown device from controlling the mobile device simply by plugging it in.
In Android 11 and later, Google added the wireless debuggingThis allows you to pair your device and workstation via Wi-Fi using a QR code or pairing code, without needing a cable. From Android Studio, you can use the "Pair Devices Using Wi-Fi" option or do it from the command line with adb pair ip:puerto y adb connect ip:puerto.
Once the device is connected, adb offers you a huge catalog of options for Diagnose app, system, and network problems:
- Install and uninstall APKs (
adb install,adb uninstall), also multiple APKs by split. - Port forwarding (
adb forward tcp:host tcp:deviceoa local sockets), very useful for debugging internal services. - Copy files inside and outside the device (
adb pull,adb push). - Open an interactive shell (
adb shelland execute Unix commands and tools such astoyboxologcat.
In addition, adb integrates quick access to key subsystems through utilities such as am (Activity Manager), pm (Package Manager) or dpm (Device Policy Manager)With them you can launch activities, restart services, kill problematic processes, force heap dumps, control profiles, manipulate permissions, create or delete users, configure device/profile owners in corporate environments, etc.
For visual debugging, you have commands like screencap y screenrecordwhich allow you to capture screenshots or record video of what is happening on the device and then extract it via adb pullIdeal for documenting UI bugs or flows where traffic capture needs to be contextualized with what the user is seeing.
Serial sniffing and industrial buses: when not everything is USB or Ethernet
In industrial automation environments, CNC, PLCs or embedded electronics, it is very common to find communications based on UART/TTL, RS-232 or RS-485 with protocols such as Modbus RTU or ASCII, proprietary communications of industrial equipment, etc. To debug them, a classic and very effective technique is the physical sniffing in passive mode.
The idea is to set up a "sniffing PC" with two USB-to-serial adapters whose RX inputs are connected in parallel to the TX inputs of the Master PC and the Target Device, sharing a ground but without connecting the adapters' TX inputs to avoid interference. This can be done using software such as SerialTool or any advanced terminal, open two ports (for example, COM5 and COM6) and adjust speed and format (typically 115200-8N1, but you can try different settings or measure with an oscilloscope).
The asynchronous serial protocol (start bit, 7/8 LSB data bits first, optional parity, and stop bits) is the same whether you're working at TTL, RS-232, or RS-485 levels; what changes are the Electrical levels and physical topology (single-ended vs differential)That's why you need the right adapter: USB-TTL, USB-RS-232 or USB-RS-485.
Tools like SerialTool not only display the flow in HEX and ASCII, but also integrate Modbus clients for reading/writing registers, monitors with timestamps and datalogger functions that save the entire session for later analysis, even exporting to formats that you can then open with Wireshark or your own scripts.
This approach is very powerful for reverse engineering of protocolsIf you only have proprietary software that talks to a machine, you can "sniff" the conversation, document frames, addresses, CRCs, timings, and then replicate the behavior with your own IoT application or gateway.
IoT and radio: Bluetooth, ZigBee, UART, JTAG and more
In the IoT world, things get a little more complicated, because other factors come into play. wireless protocols and internal debugging busesAnalyzing these channels makes it possible to detect security flaws, serious vulnerabilities, or simply implementation bugs.
For Bluetooth and BLE, one of the references is the project UbertoothUbertooth ONE is an open-source hardware and software package that allows you to capture and inject both Bluetooth Classic (Basic Rate) and BLE traffic. It includes an Ubertooth ONE antenna (which you can buy or build yourself) and Linux/macOS tools that communicate with it and enable... sniff, decode, and export traffic, including support for analyzing it with Wireshark via an integrated BLE plugin from relatively old versions.
Analyzing Bluetooth traffic is not trivial, as the protocol is complex and relies on frequency hopping and pairing procedures. Ubertooth, however, comes with extensive documentation, wiki and forums covering everything from the fundamentals of the protocol to practical examples of capture and analysis.
When you have physical access to the IoT device, another essential tool is Attify BadgeA small, multipurpose board for interfacing with UART, SPI, I2C, JTAG, GPIO, and other typical embedded hardware interfaces. With it, you can sniff UART traffic. Gain root access via serial console, perform memory dumps via JTAG, manipulate GPIO pins and, in general, to have a legitimate backdoor to the equipment's electronics.
For ZigBee and 802.15.4 networks, the project KillerBee It's the equivalent of Ubertooth: a software framework (mainly in Python) plus compatible hardware (like the Atmel RZ RAVEN USB Stick) that allows Capture, inject, and analyze ZigBee trafficLaunching denial-of-service attacks, wardriving home automation networks, etc., with packet generation support using Scapy.
To avoid going crazy installing tools and dependencies, there is also Attify OSIt's an Ubuntu-based distribution pre-configured with everything needed for IoT auditing: support for Ubertooth, Attify Badge, KillerBee, GNU Radio, HackRF, JADx, IDA (if you have a license), Firmware Analysis Toolkit for emulating firmware, and much more. The drawback is that it's distributed as a virtualized image (for VMware, VirtualBox, etc.), which sometimes complicates things a bit with USB passthrough, but for many labs it's a very convenient and quick deployment solution.
Legality, good practices and complementary alternatives
Capturing network or USB traffic is technically simple nowadays, but it's crucial to understand that Not everything that can be done is legal or ethically acceptable.In Spain, for example, the use of tools such as Wireshark or physical sniffers is not a crime per se, but accessing, intercepting or disseminating third-party data without consent is, falling under crimes of discovery and disclosure of secrets.
To protect yourself, always limit yourself to networks and devices owned by you or by clients who have given you explicit written permissionDon't take advantage of open Wi-Fi networks in cafes, airports, or near neighbors to "see what's going on." Even if you think you're "just snooping," if your screenshots of passwords, messages, or personal data are caught, explaining it to a judge later is much more complicated than it seems.
Another key point is that The screenshots may contain highly sensitive informationCredentials, internal traffic, metadata, keys, etc. If you're going to share a pcap file with a third party to help you debug, do it only with someone you trust, anonymize what you can, and if there's encrypted traffic, don't give out private keys lightly.
As for alternatives and complementary tools, in addition to those already mentioned (tcpdump, TShark, Zeek, Suricata, Fiddler, mitmproxy), you have solutions such as CloudShark (focused on analysis and sharing of captures via the web), Smart Sniff for Windows, or visual viewers such as EtherApeMany of them work very well with Wireshark because they share the pcap format, so you can combine the brute force of some with the fine analysis of others.
This entire ecosystem—open hardware USB sniffers, Wireshark and TShark, ETW and USB 3.x debugging on Windows, ADB on Android, serial tools for industrial buses, IoT frameworks like Ubertooth or KillerBee, and modern analysis platforms—allows you going from “I have no idea what’s going on” to “I see every bit that moves and I know where it’s failing”and also understand Why USB transfer is slow when appropriate.
