Hacker News new | past | comments | ask | show | jobs | submit login
Ever wondered how device drivers are reverse engineered? (linuxvoice.com)
281 points by nkurz on Mar 20, 2015 | hide | past | web | favorite | 17 comments



Wow, I really wish I had read something like this when I attempted to write a program to use USB weighing scales in Linux.[0]

I learned things like needing to detach the kernel driver the hard way. And because I didn't know anything about USB (and still don't), I was stumbling my way through libusb. There I still missing features that I need to revisit once I learn how to use USB properly.

[0] https://github.com/erjiang/usbscale


Beautiful, well documented code. Thanks for sharing.


As someone who has never needed to write device drivers, this is pretty interesting toy example.

I was a bit confused when it got to the part about > detach (unbind) the kernel driver Does this mean there is a default kernel driver on the interface and we must detach it first to make it available?


> Does this mean there is a default kernel driver on the interface and we must detach it

Yes. Sometimes, and most prominently: A lot of cheap gizmos register themselves as "HID" (human interface devices) which is a class normally reserved for keyboards and mice. Windows, Linux, OSX, ... have default drivers, and the HID protocols implements a channel for arbitrary data to be passed to/from the device (/dev/hidraw* in Linux). In turn it allows people to talk to the "USB rocket launcher" providing a simple executable application, without needing to register a driver.

If you want to talk to the usb device using libusb (or the python bindings) you have to unbind this generic driver. You can either do it from within libusb, or for example, in the sys filesystem.

For a USB ethernet adapter (which I happen to have laying around):

    $ cd /sys/bus/usb/drivers/ax88179_178a
    $ ls
    (...)
    lrwxrwxrwx 1 root root 0 Mar 20 20:33 2-1.1:1.0 -> ../../../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.0
    (...)
...so it's bound to device 2-1.1:1.0 ...

    $ sudo sh -c "echo 2-1.1:1.0 >unbind"
...ethernet interface is now gone, I can, theoretically, now talk to the device using libusb.

Another example: Some programming cables for microcontroller development (similar to, e.g. the Arduino stuff) might have use a standard USB-to-Serial bridge chip. But as you have to talk to it in a non-standard way you'd have to unbind the default usb-to-serial kernel module and talk directly to the usb device.


Correct, in this case it's the most common type of USB device/driver, the HID driver. Many devices will present themselves as HID Devices initially and even communicate over the HID protocol since it is one of the few USB classes that doesn't require a special driver to be written for windows to recognize it (other classes such as a serial device require at least an INF to be installed in order for windows to load the correct driver).


Furthermore, I think, HID is the only standard device class that can work on Low-Speed USB (1.5 Mbit/s) which allows only a control and an interrupt endpoint.

Every other class (including serial ports) will need at least Full-Speed USB (12 MBit) increasing the cost of the USB Rocket Launcher by 10ยข ;-).


Getting: Error establishing a database connection

Article is already in web.archive.org:

http://web.archive.org/web/20150320100539/http://www.linuxvo...


This is awesome, I think it just unblocked my quad copter experiments :-)


Out of curiosity, what hardware are you using / drivers are you missing? Given the number of existing flight control boards with decent open source software support, I'm a little surprised that drivers are blocking you, rather than something more interesting like running out of CPU cycles to run a Kalman filter ;)


Crazieflie 1.0 [1], when I first got it there was zero Linux support (the radio wanted to talk on a Windows box) I started porting it to Linux, got libusb going and then got stuck on both not knowing what I didn't know, and a process for discovering what was going on. Since that time I see they have updated their code for Linux support. :-) (I guess procrastination can pay off!)

[1] http://www.bitcraze.se/crazyflie/


Cool platform, thanks for sharing. Based on the picture, I'm pretty sure the main CPU board on my current quad is about as large as the Crazieflies whole frame :)


For reference he is reverse engineering the Dream Cheeky USB Mini RC Car:

http://www.amazon.com/Dream-Cheeky-USB-Mini-Car/dp/B000XGQ9L...


Tridge (of Samba fame), did a really neat talk at LCA a few years back, where he reversed engineered a USB gadget in front of the audience (well the process anyway)

http://mirror.linux.org.au/pub/linux.conf.au/2011/2011-01-28...


This is cool.. Ive done some easier stuff like this using PySerial but i always had the specifications before hand. Cool to see how to sniff the windows driver.


Is this something the Bus Pirate device could also be used to do?


My experience has been the Bus Pirate is good for ad-hoc sending/receiving data over various protocols when you are working at the level of single recieve/response commands (i.e. you have a data sheet for a part and want to test it out). full-on logic analyzers or USB analyzers are nicer for capturing an entire conversation or trying to understand how data flows relate to each other.


Betteridge's law of headlines comes to mind.




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: