Konstantin Bläsi - 2014-01-13
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. http://linux.conf.au/schedule/30177/view_talk?day=wednesday
This was absolutely amazing, although I pray to {$DEITY} that I never find myself in this guy's position.
Great lecture. Brings back some memories when reverse engineering apps from the 80s/90s - so my guess is that it was old DOS code. We used to have fun disabling the college computers unless it was booted with our disk by writing code that broke all the rules.
Make slides big, and the guy small :-)
lol
Wow, what a bright guy
Interesting video and what a brilliant and funny guy
Wow, this was painful to listen to (purely due to the software design, not the speaker!!), but I enjoyed it and learnt quite a bit :) The fruit-flies bit was a great ending!
Whoah, I actually felt sick and like I'm about to throw up -- then he started talking about his neighbors recylicing bin. Amazing how knowledge of bad implementations can affect one in a such way!..
Reverse engineering vendor firmware drivers for no fun and big profit
You guys are wizard friken ninjas
...around 19:24 he's wrong. why? because you need to ASK the kernel first for an MDL or map memory. so it won't touch that range as its considered aquired
It's entirely permitted for multiple applications to map the same physical address range, and the kernel can touch it regardless of how many applications have done so.
Useful insights - Especially as I am about to try and unravel a problem where Mint displays at 1024x768 from USB but only allows 640x480 when installed (may be specific to SiS video). I'll be looking for those tools !
2:35
> Automating the process of placing servers on racks and making the necessary connections.
With a standard configuration and "predetermined" mount points, it could be automated. Of course, the "predetermined" points could also be determined, initialized if you will, by means of automation. Although, decreased abstraction often equate to increased futility in this regard. Speaking of futile, I only just realized that I might be over-analyzing what was probably meant as a joke but I digress. What I'm trying to get to is that automating streamlined labor makes very much sense but certain tasks are better suited for an industrial engineer. Just to clarify, I'm not implying any similarities between industrial engineers and mindless laborers.
This very much reminds me of some reverse engineering I did early in my career.
On Windows, which has less support for this kind of activity, so you end up tapping into the physical electric signals to figure out what's going on.
Fellow computer people, don't fake laughter, ever. I know, these confs are like the only time of year we get to socialize and talk to people that actually are interested in our stuff. Still, please be genuine. Last thing we need in our communities is this managerial sort of fakery
What makes you think it's fake?
Why Windows is always better.. lmao!
edgeeffect - 2016-09-05
-d - absolutely priceless!!!