Down the Rabbit Hole – Part I: A Journey into the UEFI Land | Hacker News Reader

Down the Rabbit Hole – Part I: A Journey into the UEFI Land

erfur.github.io

102 pointszdw15 comments

White-listing hardware to the point of bricking a device when non-listed hardware is present is plain user-hostile and seves no purpose but revenue generation for the device manufacturer.

I don't buy the "but it's for your security" argument at all. An attacker who wants to own a machine with a malicious device might as well just spoof the identity of the malicious device.

I also don't buy the "but we need to minimise the support burden and warranty repairs" argument. If third party devices are such a problem, then tell the user that they are going to void the warranty but allow them to continue to use the device.

The only purpose this policy serves is to force users to purchase the most expensive add-on device possible or, worse, to force the user to upgrade an otherwise perfectly well working machine.

This gives you all the drawbacks of un-expandable hardware with none of the benefits of soldered-on components (size, weight)

IBM/Lenovo isn't the only one who does this, and they've been doing it for a very long time. Also, BIOS modding has been a bit of an "underground" hobby for about as long as BIOSes were easily flashable; there are forums full of modded BIOS images which have such whitelists removed as well as other "advanced" features unlocked (e.g. RAM timing configurations, clock frequency controls, etc.), among other things. Pre-UEFI BIOSes had a modular structure too, although it varied between the different companies.

These days, you have to beware of "features" like BootGuard which will make any BIOS modification impossible (unless some exploit is found to bypass it, or a signing key leaks), as well as the "security vultures" who love to report and close any such user-freedom-enabling paths...

Or you add your signing key through mokutil, then sign your UEFI module with your own key. This only works on your machine, but that's the point.

I did a similar mod to the UEFI of my x230t. Don‘t be too excited, it boils down to about 5 jumps that have to be replaced with NOPs.

Took me a screwdriver, a bus pirate for dumping and flashing, and about half an hour start to finish.

That sounds cool. I wouldn't even know where to begin unless there were posts detailing every necessary step.

5 jumps? I guess they really wanted to frustrate crackers, given that one would've probably been enough to do what they wanted.

They check about five properties of the PCIE device against whitelists. Would be a shame if these comparisons always returned true, wouldn‘t it...

Rather than go through all that mess of appeasing a ridiculously limited (proprietary) firmware, the author should have just built/flashed coreboot. The x230 is very well supported on coreboot, and I can install any wifi device I want on mine without having to fuck around with patching UEFI modules.

I feel like the author did this in part as a learning experience and interesting project. This blog post would be far less interesting and less informative to read if he just said "well, I just flashed Coreboot and it works great". There's value in learning.

There's also 'value in learning' to build and flash coreboot, and you'd end up with a better 'product' in the end.

Learning what exactly? How to type 'sudo ./flash'? Oh come on. Modifying the BIOS himself let him delve into technical details far more than flashing some ready-made BIOS ever would. And it's knowledge that can be used to interact with other BIOS's as well. The specific detail of where the whitelist is irrelevant - what's important is finding out how to dump the BIOS, how to open/read it, learning enough about UEFI to not get completely lost, how to make changes, how to sign it (or not) and get it working with the modified version. This is knowledge that one can apply to any number of devices with UEFI. Knowledge of how to flash coreboot is limited to the handful of devices that the developers have ported it to, and everybody else is just shit out of luck (aside from the fact that you haven't learned anything).

> How to type 'sudo ./flash'? Oh come on.

Clearly you have no idea what you are talking about. Installing coreboot requires extracting existing firmware, locating and extracting blobs from it, removing ME, configuring coreboot and payload(s). They could even patch any of the things along the way to add additional functionality (e.g. tianocore actually breaks fairly often, and requires debugging and patching).

Yea, the author learned some things, but that doesn't mean all other options are "learn nothing" (even if they are for you).

I checked for the instructions on the ThinkPad T60. Literally sudo flash. I also flashed it on my Chromebook, which was utterly trivial. These are ready-made solutions that don't require more than two brain cells to apply.

He was very clear upfront about what he wanted to get out of this .. "Initial Roadmap - Since I wanted this to be a reverse engineering task, I chose to go with modifying my laptop’s BIOS"

Nice writeup, eagerly awaiting the next section.

Companies should be named-and-shamed for this behavior. Ridiculous.

Reply on news.ycombinator.com