How Device Drivers Are Reverse Engineered
An anonymous reader writes: Linux Voice magazine has published a long article about how people go about reverse engineering drivers for hardware peripherals. They use Python and a USB radio-controlled car to demonstrate, walking us through the entire process. It's a cool, easy-to-follow insight into what often seems to be a rather opaque process.
are reverse engineered ?
Nice article, I used a similar technique, and found a reference where someone reverse engineered a usb missile launcher toy. I used that knowledge to buld the USB driver for the Antec Kuhler 920 water cooler, my small contribution to the open source community.
Of course, the Kuhler Windows App was rather poor quality, as well as the USB implementation. But at least they didn't do anything esoteric, like use USB interrupt transfers, etc. Thank goodness for simple USB transfers.
Sharing knowledge like this is what the open source community is all about.
Check me out on sourceforge, kuhler_ctl.
Maybe Linux Voice needs to learn to engineer a working database?
Google cache of TFA
Any sufficiently unpopular but cohesive argument is indistinguishable from trolling.
It's hard to call this sort of thing a "driver" since it's so high level. They're basically just decoding the protocol that is used over USB. If they could do the same thing if it used network packets over a wifi connection I doubt they'd call it a device driver.
Fundamentally, the only any driver really does is send commands to a device over a bus and handle the responses. What other kind of driver were you hoping for? :-)
Check out my sci-fi/humor trilogy at PatriotsBooks.