Hacker News Reader

Comment by pilif | Hacker News Reader

Reminds me when I had to read barcodes from a USB-connected barcode scanner on a Mac. The manufacturer supplied a closed-source library which only supported PPC code and they told me that they lost the source code, so I couldn't easily add intel support.

In the end I sniffed the USB protocol of the windows driver and was delighted to see how they abused the control endpoint rather than setting up proper data endpoints.

I was so happy when my Mac application was able to talk to the scanner and, compared to windows, completely without any driver installation thanks to user-space IOKit on macOS.

Writing software to make hardware beep is even more fun than writing software that doesn't involve hardware making noise.

View on HN

Core memory unlocked. Somewhere deep in the bellows of my electronics pile, I have an ancient HP barcode reader box that plugged inline with an AT keyboard. Into this box plugged a reader pen that you dragged across a barcode.

Once read, it would send the barcode number as keyboard commands. It was a very tactile experience.

Meanwhile, USB barcode scanners nowadays work by basically being a keyboard, so I guess we've come full circle.

I think keyboard emulation was always the way most barcode readers operated.

> In the end I sniffed the USB protocol of the windows driver and was delighted to see how they abused the control endpoint rather than setting up proper data endpoints.

Is there a better way to implement this? They seem to use it for any non-standard feature. My laptop's keyboard uses the control endpoint to control the LEDs.

you're supposed to use the control endpoint to negotiate which data endpoints to set up in what way for communication and then communicate over those.

In the case of this barcode scanner all communication was done over the control endpoint though.

That sounds pretty fun (once you're finished with it, I'm sure)! How does sniffing the USB work? Do you do that via some software/kernel extension, via special hardware, or something simpler? Do you find there are some USB devices where the manufacturer would rather you didn't sniff their traffic and make it more painful to piece together?

Wireshark via usbmon under Linux can be used to capture USB traffic. This is especially useful when the device has windows drivers, as usbmon can be used to capture the traffic off a windows VM.

For black box devices, you can build/buy a bus snoop cable and hook that up to usbmon/Wireshark (eg sniff the Xbox Kinect protocol).

Percurnious devices will encrypt/sign their packets to make reverse engineering more difficult, if not impossible, but those are few and far between. You're already buying the hardware and that's the expensive bit, so as long as you've bought the hardware, DRM-style weirdness over USB is rare. Still exists, but most hardware I see these days just uses a generic driver like HID for input, or UVC for video, reducing the amount of snooping needed to make the basics work. Getting extra functionality (like special LEDs) working still requires snooping of the working Windows driver+program though.

Reply on news.ycombinator.com