Hamish Coleman
<p><a rel="nofollow" class="external free" href="https://linux.conf.au/schedule/present">http://linux.conf.au/schedule/present</a>...
In this talk, I will take you through the tools and techniques
I used to reverse engineer the keyboard controller in my Thinkpad
laptop and re-flash it with custom firmware.  This will cover how the
Thinkpad range of laptops have tried to secure their firmware from
unauthorised changes.  Finally, I will present my ongoing work to
reverse engineer the protocol used between the BIOS and the vendor's
flash update tool (which included writing a custom virtual machine
to emulate a minimal laptop).
</p><p>I was driven to start this project when I realised that the laptops
currently on sale just did not meet my requirements.  Even the durable
Thinkpad laptops I have preferred in the past are being dumbed down.
Eventually, I will need a new laptop - and with the current offerings,
I just do not want anything I can purchase off the shelf.  I knew
I was not going to be able to build my own laptop from scratch
(and having discounted all the current free/open laptop offerings)
so I started looking at what I could hack together.
</p><p>To keep the project achievable, I reduced my laptop gripes as far
as I could and focused on just the keyboard - asking the question:
"Can I shoehorn an older keyboard in a modern laptop?"  Eventually
answering it with "yes, sometimes."
</p><p>It turned out to be easily possible to physically replace the
keyboard on any of the Thinkpads in the xx30 series with one from the
xx20 series.  I was stalled with a half-working keyboard until early
2016 when Zmatt published how he unlocked his laptop.  The firmware
changes needed were bundled up into a complete build system which
others have used to replicate the keyboard replacement. However,
with both these laptop series' being several years old now, I am
still looking at forward porting this to a newer laptop - which has
led me to research the hardware and firmware design there.
</p><p>I will also take the audience through my current knowledge of how
the vendor's protocol to tell the BIOS to write a new image to
flash works.  Now that it is possible to write new code for the
embedded controller and to install it and run it - I wanted to
know how secure this was (or wasn't) separate to simply "fixing"
the keyboard.  I have written a custom virtualisation tool to host
the vendors "dosflash" program and capture the protocol it uses to
request that the BIOS write a new image to flash.
</p><p>It is my hope that others will be inspired to look closer at their
hardware and to give them both some tools and the confidence that
</p>
it is possible to "fix" the way that consumer hardware works.
<a rel="nofollow" class="external text" href="https://www.youtube.com/channel/UCDMo9DyACXG62ak5cVgs3TA">linux conf au 2017 - Hobart, Australia</a>
CC BY 3.0
<bdo lang="en" dir="ltr"><a href="//commons.wikimedia.org/wiki/Commons:YouTube_files" title="Commons:YouTube files">YouTube</a>: <a rel="nofollow" class="external text" href="https://www.youtube.com/watch?v=Fzmm87oVQ6c"><bdi lang="">My personal fight against the modern laptop</bdi></a> – View/save archived versions on <a rel="nofollow" class="external text" href="https://web.archive.org/web/*/https://www.youtube.com/watch?v=Fzmm87oVQ6c">archive.org</a> and <a rel="nofollow" class="external text" href="https://archive.today/https://www.youtube.com/watch?v=Fzmm87oVQ6c">archive.today</a></bdo>