"sniffing" USB - 2

[robd2002]

Hi,

My company is pretty good at capturing RS-232 data between devices such as a point-of-sale system (cash register) and a serial printer, as long as we know the baud, parity, data bits, etc.

My boss thinks I can do the same thing with a USB connection and I'm telling him I cannot. He thinks I can do it. I've looked at data between a keyboard and a pc on an oscilloscope, and honestly, I cannot begin to imagine how to pick out the data that is sent when I simply hold down a key.

Am I just being stubborn or is too much being expected of me. My company has about 20 employees and I'm the sole engineer. I've designed simple microcontroller based circuits that talk serial and sample a/d converters, but this really seems out of my league.

Is capturing and deciphering the USB data between a pc and a printer something a sole engineer with no experience in USB can be expected to handle? Should I try to find a job as a technician?

Thank you,

Rob

 

[MacGyverS2000]

IR,

If there is any form of initial handshaking between the printer and the PC, nothing can play man in the middle. The PC is going to request the ID of what it's connected to, it won't be the printer (directly), and it will fail its handshake.

Maybe they didn't include such a check (even though it costs nothing to add the ID check in), but I know it's what I would do to help deter reverse engineering.

Dan - Owner

http://www.Hi-TecDesigns.com

 

[IRstuff]

Agreed, that would be something that the Beagle would already be configured for.

Seems to me that it could still be done, since you know PC1 will only be looking for the printer, and after a few iterations, the sniffer will have collected what PC1 sends out, which PC2 can send to the printer and get the response back, which would be relayed back to PC1.

The only major issue would be if there's some sort of timing handshake, i.e., excessive latency would drop the connection. It just means that the PC2 software needs to be very lean for the bucket brigade part.

TTFN

FAQ731-376

 

[MacGyverS2000]

Hmmm, I'll have to look at this "Beagle" thingy later and comment appropriately... I have to jet right now to make sandwiches for my step-daughter's baseball game

Dan - Owner

http://www.Hi-TecDesigns.com

 

[Noway2]

There is a program that I used in the past which is freely available called USB Snoopy. It is a windows program that allows you to put the USB host into a promiscuous mode. It sits like a man in the middle and captures all of the data between the host (PC) and the device (printer).

http://sourceforge.net/projects/usbsnoop/

I would suggest that you down load that and take a look at the data associated with the USB printer. You have nothing to loose and it should answer a lot of your questions, or at least give you a better idea of what you are up against.

USB 'packet's are transmitted in frames. The frames have a wrapper with a header and other pieces of information, such as device address, endpoint address, checksum, etc. These frames occur on a 1ms rate, assuming "full speed". High Speed USB is more complex and runs micro-frames within the frames. USB then implements transfers consisting of these transaction frames. There are handshake, data, and acknowledge frames in the transfers. There are four basic transfers; control, bulk, isochronous, and interrupt. The control transfers are used to enumerate the device. The process begins with each device being unassigned. The host will apply power to the device and issue commands to it to figure out what type of device it is. This tells it how to use the device. A printer will undoubtedly fall into a pre-defined class with a set of protocols to talk to it. These protocols will probably use other 'wrappers', effectively data structures, to pass the data to the printer. In these structures will be the payload - the 'A' you were referring to.

In principle, USB is like RS-232 in that it is a communication link that works with a serial stream of bits that in turn form a set of bytes. The difference with USB is that there are A LOT of protocol layers, one on top of the other, that are used to apply meaning to the data. You need to understand these protocols thoroughly to make sense of the data.

Of course it seems simple. You just plug it into your Windows PC and go. Remember that Windows has to go through a lot of processing to identify the device, locate the right drivers and then provide an interface to it.