"sniffing" USB -
"sniffing" USB -
(OP)
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
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





RE: "sniffing" USB -
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
RE: "sniffing" USB -
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.
RE: "sniffing" USB -
Anyone got an idea of the man-hours required to make a USB sniffer system?
Thank you very much,
Rob
RE: "sniffing" USB -
TTFN
FAQ731-376: Eng-Tips.com Forum Policies
RE: "sniffing" USB -
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
RE: "sniffing" USB -
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: Eng-Tips.com Forum Policies
RE: "sniffing" USB -
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
RE: "sniffing" USB -
Dan - Owner

http://www.Hi-TecDesigns.com
RE: "sniffing" USB -
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
RE: "sniffing" USB -
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
RE: "sniffing" USB -
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
RE: "sniffing" USB -
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
RE: "sniffing" USB -
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
RE: "sniffing" USB -
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: Eng-Tips.com Forum Policies
RE: "sniffing" USB -
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://
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.
RE: "sniffing" USB -
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: Eng-Tips.com Forum Policies
RE: "sniffing" USB -
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: Eng-Tips.com Forum Policies
RE: "sniffing" USB -
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....
RE: "sniffing" USB -
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: Eng-Tips.com Forum Policies
RE: "sniffing" USB -
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
RE: "sniffing" USB -
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: Eng-Tips.com Forum Policies
RE: "sniffing" USB -
Dan - Owner

http://www.Hi-TecDesigns.com
RE: "sniffing" USB -
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.