Perth, Western Australia - 6th to 10th January 2014

<-- Back to schedule

Reverse engineering vendor firmware drivers for little fun and no profit

Project: Linux kernel

Hardware vendors like to add Unique Selling Points to their devices to convince you to buy them instead of someone else's. Of course, this typically leads to hardware vendors desperately copying each other's Unique Selling Points in a process eerily reminiscent of evolution's Red Queen Effect, all desperately trying to run faster than each other in order to stay in the same place. Putting effort into standardisation would risk them falling behind vendors who choose not to, so in the absence of some external force to compel them, vendor-specific solutions proliferate.

What does that mean for us freedom loving Linux users? If we're lucky, it means a 32-bit only userspace binary that speaks to hardware in unspeakable ways. If we're unlucky, it's doing it via SOAP. In many cases it would be possible to write a proper Linux driver for this functionality and expose it in a way that could be shared between multiple vendors, but vendors aren't enthusiastic about that. This is a problem.

This presentation will cover reverse engineering techniques that allow developers to work out just what vendor binaries are doing and write a sufficiently comprehensive specification to permit the development of a proper Linux driver, along with some examples of just how bad vendor code can be. The audience should leave with a better understanding of how they could approach such tasks, along with a healthy disquiet at the idea of ever having to do so.

Matthew Garrett

Matthew Garrett was lucky enough to be born with a natural intuitive ability for figuring out what firmware authors were thinking, and unfortunate enough to have to wait 25 years before he had an opportunity to make use of this talent. He works as a security developer at Nebula, helping integrate the cloud with its underlying hardware and doing his best to avoid it all falling out of the sky in a privacy disaster. He once spent four days staring very hard at a 250K userspace binary, then rewrote it as a 1000 line kernel driver. He is a professional. Closed course circuit. Side effects may vary. Do not try this at home.