Changing firmware config that doesn't want to be changed | Hacker News Reader

Changing firmware config that doesn't want to be changed

mjg59.dreamwidth.org

84 pointszdw15 comments

For anyone interested in efivars, I have an old blog post about essentially the same thing but going a bit more in-depth, including how to actually modify the efivar entries: https://ristovski.github.io/posts/inside-insydeh2o/

Thanks! I've updated to point at your post, since it's much more detailed.

> This is also considered a security boundary - before ExitBootServices everything running has been subject to any secure boot restrictions, and afterwards applications can do whatever they want.

This is how things are supposed to work, but in practice, the pro-tivoization corporate lobby has successfully gotten the "Secure" Boot restrictions to be enforced even after ExitBootServices is called. E.g., try to load an unsigned kernel module on RHEL or Ubuntu with it enabled.

Firmware stubborness can be infuriating. For example, I had a very nice windows tablet that was rendered useless by an un-downgradable firmware update introducing a two-second lag to touchscreen taps.

Small claims court?

Do you have to flash this modified firmware to the machine or how is it applied?

> Rewriting Setup-EC87D643-EBA4-4BB5-A1E5-3F3E36B20DA9 with a modified value in offset 0x39 will allow direct manipulation of the config option

Looks like a simple write to UEFI vars. The option is still grayed out, but it is now in the correct state.

I'm pretty sure that it's saved where any other custom changes you make in the EFI screen would be. But instead of using the GUI you're just directly editing the config on NVRAM.

As you need the boot services still loaded, you cannot do this from Linux or Windows. One way is to use a hacked up version of grub or similar that has commands to write to EFI vars.

Would this (technically) essentially open up a path to disable Computrace on "permanantly activated" machines by forcing the Computrace variables back to disabled?

I believe that should be possible, yes.

Here is an interesting paper about Computrace: https://www.coresecurity.com/sites/default/files/private-fil...

Sounds like an opportunity for a generic UI/management tool. The pre/post boot thing could be mitigated by a rebooting into a special stub that just verifies intent/signatures, applies the settings and reboots back into the OS.

If I understand this correctly he analyzes a UEFI binary to find those IFR/VFR records. I have grub, the UEFI stub of the Linux kernel or then BIOS updates provided by the vendor which are UEFI executables. But an executable showing the setup screens? Where would I find that?

Edit: It looks like the comment by user Ristovski might help. However, not having actively done anything in that area, I can't say for sure by just quickly reading it.

The setup app is typically embedded in the firmware, so you need a copy of the firmware. The post you reference in your reply shows how you can potentially use flashrom to get that, but in some cases you can also download firmware updates from a vendor and extract image contents using uefitool.

Reply on news.ycombinator.com