5

I am looking for a way to sniff the data running between a PC ("A") and a USB device ("B") by using another PC ("C").

To do this, I spliced the cable going from A to B and soldered another USB cable to create a Y splitter and ran it to C, thinking the signals will be duplicated.

What happened was the two PCs A and C fought over the control of B (should have seen that coming...) and all hell broke loose.

I have a couple of assumptions/ideas I would like to run by you: 1. Can I disconnect the VCC and GND wires on the sniffing cable, so that C will not try to control B? 2. Can I place a diode on the D+ or D- wires of the sniffing cable of to make the data flow only one-way? 3. Will I be able to read the data off the USB port in C?

Any comments/suggestions will be greatly appreciated.

(Disclaimer - I am a NOOB to USB so go easy on me)

zulfik
  • 61
  • 1
  • 1
  • 3
  • What, ultimately, are you trying to build? Is this a one-off or some kind of USB intercepting product? I don't think it's going to be possible to do it without some kind of hardware. USB is not a simple serial protocol, and you don't have access to the raw protocol on the ports. – pjc50 Nov 06 '12 at 13:24
  • 2
    I will most likely start off with a software solution running on the host PC. Next step will be some kind of Man In The Middle solution running on a micro-pc of some sort. Thanks @pjc50. – zulfik Nov 07 '12 at 15:15
  • See also a similar question posted here: https://reverseengineering.stackexchange.com/questions/12730/where-do-i-find-a-cheap-hardware-usb-sniffer/20511#20511 – jrouquie Jan 30 '19 at 16:38

3 Answers3

9

Usually I either use a CATC analyzer like this. enter image description here

The nice thing is you get great software that shows you exactly what's happening:

enter image description here

Or you can try a software only solution like this. I've used that when the catc was busy.

enter image description here

You might also try checking ebay for CATC analyzer, or you could rent one. Making a Y cable won't work out though as you already found :)

Some Hardware Guy
  • 15,815
  • 1
  • 31
  • 44
  • Thanks a lot for the detailed answer @SHG. I understand how the CATC can help, but the final product will not be able to incorporate such expensive gear and will have to be based on some "magical" wiring + proprietary software on the sniffing PC. Is there not a way to send only the data to a 2nd PC? – zulfik Oct 28 '12 at 15:36
  • 1
    One additional comment for newcomers to USB, though it is obvious to the experienced folks: USB is not like a parallel port, which carries separate bits of every byte on separate wires, allowing level-sensing stealth sniffing. USB has a handshake, and an entire master-slave protocol stack - hence the need for devices like the CATC. – Anindo Ghosh Oct 28 '12 at 15:40
  • Thanks Anindo. Do you know of any USB to Serial adapters that would provide the functionality I need? I don't mean those that facilitate connecting USB devices to PCs without USB ports but rather a real converter (and I am still left with splitting the cable somehow). – zulfik Oct 28 '12 at 16:14
  • 1
    Maybe if you explain what you're trying to do we could help you better. There are plenty of USB to serial adapters out there but they're made so you can connect your USB port to a device that only has say RS232. Not to covert all the data sent over USB into serial data you can look at. – Some Hardware Guy Oct 28 '12 at 16:38
  • I am building a remote protocol analyzer in software (Remote - because it runs on a different PC than the one the device is hooked up to). I am looking for a way to receive the bit stream going to the device without interfering (I can use a piggyback cable, or replace the USB cable entirely). I am willing to build a fancy cable and write glorious software but the solution can't require costly hardware. – zulfik Oct 28 '12 at 18:26
  • Ah ok not a small undertaking then :) If you look at how the CATC does it they usually have an FPGA in there that's snooping the lines and decoding the protocol for them. Then they're storing all that information in local memory. Once their capture buffers are filled up or there's a trigger the PC grabs the raw data for analysis. I don't see a way that you'll be able to just connect some cables up to the second PC without some sort of custom hardware in the middle. – Some Hardware Guy Oct 28 '12 at 18:33
  • Hey, they fly stuff to Mars... How hard can this be?? Thanks a lot for you time and effort. I truly appreciate it. – zulfik Oct 28 '12 at 18:48
  • Hahaha, the mars-argument, lol, I used the exact same argument the other day. – zduk Oct 28 '12 at 18:50
  • ...and did you accomplish your mission? – zulfik Oct 28 '12 at 19:01
  • If the operating system will let you get in to monitor below the level of the client drivers, a fully software solution should be possible. There is even a fair amount of monitoring built into Windows 7 which I was able to use to figure out why a custom USB device developed against Linux would not enumerate on Windows (turns out I had violated one of the specs). – Chris Stratton Oct 28 '12 at 19:35
  • Not yet, but by .., I **will** find a reliable way to have my device detect if the power-plug in the wall-outlet is inserted upside down aka [reverse polarity detection](http://electronics.stackexchange.com/questions/43343/ac-polarity-detection) :) – zduk Oct 28 '12 at 19:42
  • Would a pure software solution also capture low-level events such as: * High-speed negotiation (K/J chirps) * Reset, Suspend, and Resume events * IN/NAKs, PING/NAKs, SOF * Transmission errors and retransmissions * and more... – zduk Oct 28 '12 at 19:50
  • It seems unlikely that a pure software version would be possible. From the POV of the Man In The Middle, both host and device messages are passing through, none of which it initiated; the USB host chip is not made to simply pass on raw bytes to higher layers like this. – Nick Johnson Oct 29 '12 at 14:30
  • @NickJohnson a pure software solution would need to run on the computer which is acting as the USB host. It would man-in-the-middle various portions of the USB host stack's interaction with device-specific drivers or the host controller chip, rather than the actual data on the wire. – Chris Stratton Oct 29 '12 at 23:38
  • @ChrisStratton Yes, that would certainly work - and there are packages that do this by intercepting API calls. But the OP was talking about a software only solution on a third-party machine, and I seriously doubt that's possible - USB host ports aren't made like that. – Nick Johnson Oct 30 '12 at 10:58
4

What usb-versions do you want to support (specifically, do you need usb3)?

To answer your current question/idea:

  1. Can I disconnect the VCC and GND wires on the sniffing cable, so that C will not try to control B?
    Yes, unless your sniffer runs on the host-supplied power

  2. Can I place a diode on the D+ or D- wires of the sniffing cable of to make the data flow only one-way?
    D+ and D- are differential data (the base-voltage-levels indicate to the usb-device the maximum amount of current it may draw). So.. the diodes are useless for your application. Especially since your sniffer MUST run in 'promiscuous mode'.

  3. Will I be able to read the data off the USB port in C?
    If you build a sniffer, then yes, but not with the simple splitter-cable you have in mind.

Also note that USB3 is finally bi-directional (where as previous versions where not).
Also note that USB2 is already 480Mb/s and this might (depending on your computer C) be a lot or impossible to capture as a stream. Now USB3 will be around 5Gb/s...

So if you'd want to build a sniffer of your own, you'd be looking at a differential data buffer capable of at least 480Mb/s, and some processor to handle the copy of the data and store it in memory, then have your computer C download the captured data.

Oh, and don't forget, you'd need software on your computer do do something usefull with the captured data.

The data is encoded with NRZI. A 0 will make the signal flip sign and a 1 will keep the same signal level. If a 6bits of 1 are sended an additional 7th bit (0) is send to make the signal flip. Adding this dummy bit is called bit-stuffing and is used to keep the clocks of the host and client in sync. The clocks are generated from the data signal. When the signal is received the NRZI is decoded and bitstuffing removed. Then the controller will detect the USB packet start (start with a synac field). The packets are buffers which are called endpoints. CRC is applied to the packets to maintain data integrity. When an error is detected this will be flagged and the corrupt packet will be discarded.

UPDATE:
Please read this answer that details some very interesting options that might help you with software-only solutions, like in vm-ware or wireshark, depending on what information you need:
A. Physical (electrical signals)
B. The bitstream (which is just the differential between D- and D+)
C. The USB packets
D. The USB descriptors and the USB data

Community
  • 1
zduk
  • 203
  • 1
  • 2
  • 8
  • Hey zduk, thanks for this. It is totally possible that the sniffer will **actually be** computer C - I don't necessarily need any hardware in the middle. If I hookup to the data wires going to the device and run them into a USB port on C - will a USB port sniffer (such as USBlyser) "see" the data stream? – zulfik Oct 28 '12 at 19:00
  • No, you NEED hardware in between. USB is 1:1 (ok, it supports a slave). See updated answer, you asked for option B, thus you need a 'promiscuous' system. You need a very beefy pc with a solid state drive to handle 480 Mb/s (let alone usb3's maximum potential) if you want a live streaming realtime (so no data-buffering) capture! – zduk Oct 28 '12 at 19:19
  • zduk, thanks a lot for all the information. I will take a couple of deep breaths and re-plan my attack. I respectfully reserve the right to nag some more in the future. Thanks again. – zulfik Oct 29 '12 at 09:11
-1

I am looking for a way to receive the bit stream going to the device without interfering

This should be extremely easy!

USB, prior to 3.0 is broadcast protocol in the downstream direction. Meaning, you just connect computer C to the transmitter's USB bus, and you can listen to all downstream (host-> any device) packets.

Just modify the USB driver of C to not throw away packets, which are not addressed to it!

Vorac
  • 3,091
  • 5
  • 29
  • 52