"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]

There's no reason why you can't do it, though it won't be as simple as sniffing ASCII over a serial line where every 9-10 blips translates directly into a specific character. With USB, you have a significantly higher percentage of protocol traffic mixed in with the data. It's not hard to pick out once you understand the format, but you won't be able to sit a simple data register on the line looking for a specific character to come across... you're sniffer will need some understanding of the protocol.

Quite a few basic USB books out there (I think Jan Axelson had a relatively decent one out years ago) that should help you understand the format pretty quickly.

Dan - Owner

http://www.Hi-TecDesigns.com

 

[robd2002]

Mac,

I sure appreciate the reply. So - it's feasible to make a piece of hardware that taps into the USB wires and can identify the text characters that are sent from a pc to a printer and store only those characters? I still cannot comprehend this. Nor can I thank you enough for talking to me about this. You think a micro can handle the task?

Regards,

Rob D.

 

[robd2002]

Let me ask this: Let's assume I have pc1 connected to printer1 and pc2 connected to printer2. I know that if the printers are RS-232 serial, that the letter A will show up as 41h, whether or not the printers are Panasonic or Canon. Now let's move from 1980 to 2010 and upgrade to USB connections. Will the letter A still look the same? Let's make things easier by assuming Courier font on both examples.

Anyone got an idea of the man-hours required to make a USB sniffer system?

Thank you very much,

Rob

 

[IRstuff]

Yes, that's what he's saying. Your processor will need to parse entire messages, instead of a byte or two. It'll need to start by looking at the headers and determining the source and destination and the type of message, which should be all in the USB standard.

TTFN

FAQ731-376

 

[robd2002]

Hi IR, and thank you very much for the reply.

Can you ballpark the effort level required, and is it realistic to think that an "all around type system engineer" who is OK at a bunch of things, knows enough to get himself into trouble and can usually get himself out of trouble, can tackle this on his own?

On what I think is a positive note, I probably wouldn't be constrained to an embedded solution, if I could do it with a pc that would be good enough.

You know more than I do, how long would the job take you? Anyone else's answer to this is more than welcome.

Thank you again for your help (Mac, IR, and all else!)

Rob

 

[IRstuff]

You'll need to download the spec to which your system will be compliant, and look though it. I have Universal Serial Bus Specification Revision 1.1.

There's too much for me to go through now, but protocol overheads range from ~9 bytes to ~46 bytes, and two of the bytes are the CRC. A typical one:
3 SYNC bytes, 3 PID bytes, 2 Endpoint+CRC bytes, 2 CRC bytes, 3 bytes interpacket delay. The endpoint+CRC bytes reference is the actual payload byte count.

TTFN

FAQ731-376

 

[itsmoked]

(In the same voice and tembre as the James Bond villian - "Ahh leave him, the sharks have him.")

Ahhhh... Just use a "USB sniffer". You can find sniffers for dang near anything now.

I suspect there are even free ones you can find that are entirely SW based. USB is a much higher protocol than RS232 which makes it harder to decipher but at the same time makes it easier for a SW based decipher.

Just google around a little. I seem to remember something called usbsniff or usbsnoop. It was one of the SW based ones.

I'm sure there are some pretty reasonably priced hardware sniffers out there too. You would probably want one of those if you are faced with hacking various products that don't run under the windoz or mac operating systems.

Keith Cress
kcress -

http://www.flaminsystems.com

 

[MacGyverS2000]

Yeah, if all you want is a PC-based monitor, spend the $30 and be done with it. If you're trying to make a salable product, you'll need to dig into the spec yourself and determine the level of effort required. If all I cared about was the raw data packets and drop all protocol, I could probably have a complete working stand-alone hardware system in a few weeks... but when it comes to packet interception this ain't my first rodeo, either.

Dan - Owner

http://www.Hi-TecDesigns.com

 

[robd2002]

Again, I appreciate the responses but none of you are telling me what I want to hear: Boss is asking for something impossible.

Here is what Boss thinks can be done:

1. Start with PC1 connected to a printer. Print a document.
2. Disconnect the printer USB cable from PC1 and plug it into PC2.
3. Connect PC1 to PC2.
4. From PC1, print the same document as in step 1, except now the printer is connected to PC2.
5. PC2 has software running that captures the file that was printed from PC1.

And this needs to ultimately happen on commercial point of sale system connected to a proprietary printer. I'm not talking about hardware that you can buy at any pc store.

I'm going to have to "no bid" this one.

Thank you all,

Rob

 

[MacGyverS2000]

Are you trying to reverse engineer the printer's protocol? Can you not simply ask the manufacturer for the protocol?

What you propose is not going to work unless you're able to create a program on PC2 that will act as a gateway for the USB traffic. Even then, it probably wouldn't work (unless you had direct access to the USB hardware) as during the initialization stage PC2 is not going to answer to PC1 with the correct data (USB manufacturer, product code, etc.). As far as PC1 is concerned, the printer isn't connected to the USB port, some other device is.

If you cannot install the $30 software mentioned earlier on PC1, your only other option is to clip into the USB cable wires and log all traffic.

Dan - Owner

http://www.Hi-TecDesigns.com

 

[MikeHalloran]

So PC2 implements a man in the middle attack on the link between PC1 and the printer; at least it _could_ do so, i.e. modify what comes out of the printer.

Just roaching onto the wire and extracting the data transmitted is a little easier, but not trivial.

Sounds like great fun, but more than a few days' work.


Mike Halloran
Pembroke Pines, FL, USA

 

[robd2002]

Dan: Are you trying to reverse engineer the printer's protocol?
Rob: No, just capture some of the printed data, e.g. gallons of gasoline sold.

Dan: Can you not simply ask the manufacturer for the protocol?
Rob: My experience is that companies do not in general give away their secrets for free to just anyone who asks. Why would they? Even if I bought a printer I can't imagine the mfr. doing more for me than troubleshooting its operation.

Dan: What you propose is not going to work unless you're able to create a program on PC2 that will act as a gateway for the USB traffic. Even then, it probably wouldn't work (unless you had direct access to the USB hardware) as during the initialization stage PC2 is not going to answer to PC1 with the correct data (USB manufacturer, product code, etc.). As far as PC1 is concerned, the printer isn't connected to the USB port, some other device is.
Rob: Now you are saying what I want to hear.

Dan: If you cannot install the $30 software mentioned earlier on PC1, your only other option is to clip into the USB cable wires and log all traffic.
Rob: Do you mind saying exactly what software that is? I've downloaded USBlyzer; it logs traffic on the resident USB, do not see how it would sniff external USB. I've clipped onto wires and observed data on a scope...what can log all traffic? Not USBlyzer.

Mike: So PC2 implements a man in the middle attack on the link between PC1 and the printer; at least it _could_ do so, i.e. modify what comes out of the printer.
Rob: Implement a middleman - yes; modify what comes from the printer - I don't think so.

Mike: Just roaching onto the wire and extracting the data transmitted is a little easier, but not trivial.Sounds like great fun, but more than a few days' work.
Rob: Like I asked Dan, extract the traffic with what? I can capture serial data only because the micro has a UART to do the ASCII conversion for me. To try to do the same thing by capturing the individual bits may be fun, but kind of futile as that's what UARTs do. Sure, if I were working for the CIA trying to crack some code for the sake of national defense, not sure it makes sense to try to figure out how much gas is being sold.

Thanks again guys!

Rob

 

[MacGyverS2000]

If you're not comfortable with clipping onto wires and recording the bit patterns running across them (and cannot figure out how to do so without someone's help), you have little hope of accomplishing such a project in a reasonable period of time, even with our help.

The project itself is pretty straightforward with a copy of the USB protocol in hand and a microcontroller dev environment... if these are foreign to you, it's best to tell your boss you're not up to the task. If you need a pass-through device, add on a few weeks to add in spoofing code, but that assumes you're capable of creating such a codebase. It does not appear you're up to the task.

Sorry it's not what you want to hear, but I still believe your problem (as stated) is solvable using a $30 software analyzer (Google USB port monitor) and no extra PC or hardware.

Dan - Owner

http://www.Hi-TecDesigns.com

 

[IRstuff]

1. Start with PC1 connected to a printer. Print a document.

OK


2. Disconnect the printer USB cable from PC1 and plug it into PC2.

OK

3. Connect PC1 to PC2.

OK

4. From PC1, print the same document as in step 1, except now the printer is connected to PC2.

OK, this is where you write a driver that spits the USB stuff you get from PC1 USB connection to the printer's USB connection

5. PC2 has software running that captures the file that was printed from PC1.

OK, this is where you use the USB analyzer of your choice to log the USB traffic from PC1

TTFN

FAQ731-376

 

[robd2002]

I'm familiar with Atmel's STK500 and the M128 processor. I've programmed it to measure a serial baud rate by clocking bit patterns (boss won't allow an oscilloscope - apparently likes things done the hard way).

I could imagine capturing bits and making a lookup table instead of using a UART but can't imagine why anyone would do this, again, short of cracking some unknown code. And while 9600 baud is one thing, 1.5 Mbps or faster is daunting.

As to my problem, installing software from

http://www.hhdsoftware.com/Products/home/usb-monitor.html

on PC1 is not an option, that is a POS system at someone's retail store, and they don't want us messing with it. I just used a PC as an example to make the explaining easier, as a POS system is sometimes a glorified pc. In this case, I think it would be much more proprietary.

Alas, I'm not up to the task. Not sure if I mentioned the Beagle device (see

http://www.totalphase.com/products/beagle_usb12/).

That would seem to be the solution, but again, Boss doesn't like doing things the "easy" way.

 

[IRstuff]

Software would be on PC2

It's not an "unknown" code, as far as USB is concerned. The packets are well defined in the standard.

The Beagle is PC2 with two USB ports as described above with a USB analyzer software built in.

TTFN

FAQ731-376

 

[IRstuff]

Oh, but note that you still need a PC to talk to the Beagle.

You should point out to your boss that $400 would equate to $400/your_rate+overhead, probably way less than 16 hours of engineering time. There is no way that you can complete this project in 16 hrs.

TTFN

FAQ731-376

 

[robd2002]

Rob: 4. From PC1, print the same document as in step 1, except now the printer is connected to PC2.

IR: OK, this is where you write a driver that spits the USB stuff you get from PC1 USB connection to the printer's USB connection

Rob: Definitely over my head...

Rob: 5. PC2 has software running that captures the file that was printed from PC1.

IR: OK, this is where you use the USB analyzer of your choice to log the USB traffic from PC1

Rob: OK, I said the printer was proprietary...how can it be installed onto PC2? And how does PC2 fool PC1 into thinking it is a printer? The company that has Epson make the printer for them is not going to give me the driver.

IR: Oh, but note that you still need a PC to talk to the Beagle.
Rob: Got that, thank you for pointing it out.

IR: You should point out to your boss that $400 would equate to $400/your_rate+overhead, probably way less than 16 hours of engineering time. There is no way that you can complete this project in 16 hrs.

Rob: My company is strange...we make money processing data and it's like I'm just used at the whim of my boss to try to do whatever he gets in his mind can be done. Glad to be employed, do oh so much more than I did as a pretend engineer at a big defense contractor, but sometimes I wonder about the projects I get assigned. Many of them are in vain, get finished and never used. Hard to believe but true.

I hope you guys are not now angry that I've wasted your time...I enjoy the collaboration but sure understand if you are all done with this. I'm pretty sure I am....

 

[IRstuff]

You don't need the printer to be installed on PC2, that was the bit about writing your own driver. All it needs to do is to echo the stuff coming from PC1 and send it on its merry way to the printer.

Everything on your PC uses drivers to interface between the operating system and the actual hardware. As you said, the printer would otherwise require "installation" which just means that there is a driver that was written specifically for taking text like what you're reading now, and converts it into the printer code that's needed to drive the printer mechanisms.

However, in this particular case, that's not necessary, since PC1 already did that. You simply need to bucket-brigade the data from PC1 and ship it to the printer.

What you do need, unfortunately, is something to decode the printer codes. But, if it's a sufficiently common printer, someone may have already done that. In the hoary old days of PCs, there are myriads of printers, each with its own printer interface, and someone was nice enough to collect all the information about the printer interfaces and publish a guidebook for that. I just recently donated one such book to my public library.

Nonetheless, the codes are relatively straightforward, and some dedicated snooping will eventually reveal the format of the codes. The basic procedure would be to print known information and compare that information to what the printer receives. This is classic codebreaking. Send enough known information to the printer, and you'll be able to determine what commands are being sent, and what the data looks like.

TTFN

FAQ731-376