To show off how all the pieces work together, let's do a demo on my X201.

Please keep in mind that I do not know if the encoding that is used on my laptop will be the same on any other laptop. So my naive approach to reading and decoding the password might work nowhere else!

However, what always works is deleting the password altogether because it doesn't even require any special knowledge of the checksum as it's simply 0x00.

In the end, there are only two risks involved in this process and I want to make sure these are understood:

1. Soldering any wires to your laptop might break it because the solder points are very small, there might be shorts, taking apart a complex device isn't easy or straight forward. Simply put: You can brick your laptop by just opening it up the wrong way and making electrical changes to the system might have side effects we cannot foresee.
2. Even reading from the EEPROM can cause a hazard. This is due to the fact that the system accesses the I2C bus every four seconds even when the system is doing absolutely nothing. Without an oscilloscope or a similar device one has no idea when the bus is being accessed. Accessing the bus with another I2C master at the same time will cause data corruption. Something that I did which, in fact, messed up the RFID area in my X201.
   But then worst, writing to the EEPROM can definitely brick your device because we have no idea if we're able to write everything back into the EEPROM correctly (yet). And if we don't, the system wakes up broken. This is even worst when one writes to the EEPROM while the host system also intends to access the bus. Data corruption guaranteed!

Having said all of the above, one way to get at least around the bus access every four seconds is to turn the laptop off completely and have it connected to a power supply. For some reason, the Thinkpad's mainboard power is on (anyone have any thoughts on the Intel Management Engine? - leave a comment down below) but no one is accessing the I2C bus at that time! Great news for me, as I can freely read and write the EEPROM.

On my laptop, since I knew I wanted to fiddle around with this further, I broke out my I2C bus into the PCMCIA slot via a simple three pin connector. So I can just plug it in and do whatever I want on the bus. If I hadn't done that, I would not be experimenting with it now.

My setup is simple: I use the Beagle Bone Black (even after many days of research still a terribly documented system and I don't understand why anyone would still use this in time of Raspberry Pi galore - yes, I'm aware of the PRU, I haven't looked into programming those in detail, yet) and connect it straight to my laptop's I2C bus.

Then I fire up the cloud9 IDE and execute my Python project which accesses the bus and attempts to read from it. Since I know the bus is being accessed every four seconds, I have an oscilloscope set up to watch the signal lines. Once an access cycle is over, starting the four second gap, I hit enter to signal the BBB to start the process and read the bios EEPROM. Once read, it will spit out the currently set supervisor password in clear text, create a separate image with a modified, known password, confirm that it calculated everything correctly and then wait for another user input to start writing the new image file back to the EEPROM.

I really didn't want to write junk to the EEPROM so I force the user (me) to type a security sentence to start the writing process. Watching the oscilloscope closely, waiting for the four second gap again, I hit enter once the gap is there. Within milliseconds, the new image is written to the bios EEPROM (only one of the four sections of the EEPROM) and the new password can be entered immediately to unlock the laptop.

Obviously, the EEPROM write step isn't mandatory to unlock the laptop because the script already exposed the originally set super visor password. So once we have that, we can just enter it to unlock the bios. But if the password uses a different encryption, we can use a different command to delete the bios password altogether. Honestly, this is what I should be doing because why would I want to enter anything at all if I don't absolutely have to.

So what's next to do? Well, there are a couple things I really want to implement should I find the time:

• Automatic detection of bus activity via GPIO lines and showing the status on an LED
• Use that detection to time reading and writing automatically within the script
• Option to write a new password or write a blank password via security phrase before writing
• Writing and verifying the EEPROM automatically
• Understanding how Computrace is stored in the EEPROM and allow deactivation of Computrace if active
• Understanding how any other bios password is stored and figure out a way remove or rewrite those as well
• Publish the script without getting sued by Lenovo. :) It's science after all and they definitely know about all of this. The EEPROM has been decoded many times and it's borderline insane that all these techniques still work after so many years even through all the various bios updates. But hey. Access to hardware has almost always allowed a hacker to break the security gates given some time.