datasone / setup_var.efi

UEFI command-line tool for read/write access of variables
Apache License 2.0
221 stars 8 forks source link

Is it possible that changes made by setup_var.efi don't persist? #13

Closed chrisdma closed 1 year ago

chrisdma commented 1 year ago

Hello,

I have a Lenovo ThinkStation P360 Tiny that I am trying to flash a new BIOS to with microcode to support Intel 13th Generation CPUs.

I am getting this error when attempting to flash back my modified BIOS: Error 167: Protected Range Registers are currently set by BIOS, preventing flash access. Please contact the target system BIOS vendor for an option to disabled Protected Range Registers.

I have full read access to the SPI chip so I dumped my BIOS and used IFR Extractor to see the system BIOS strings and searched for range registers and found this: image

I booted into a UEFI shell and used setup_var to set 0x73D to 0x0 (with -n PchSetup) and I see it set when I read it back then and there; however when I reboot, I see the Lenovo splash screen, and my screen goes black as if it reboots and then I see the Lenovo splash screen again and then see the loading circle for booting into my Windows OS.

Is there a reason why the values don't persist over a reboot/why my BIOS seems like it reloads and possibly resets those variables? I have tried using fpt in the UEFI shell while the 0x73D offset is set to 0x0 and I still get the same Error 167 error, as if it doesn't make a difference. Not sure if it needs to reboot to go into effect, but if I reboot it seems like the BIOS resets those changed offsets.

I have tried disabling BIOS Lock (only and with FPRR) and that resets back to its default value as well.

Would you be able to provide assistance on why this may be happening, as well as any ideas on a resolution?

Thanks, Chris

datasone commented 1 year ago

The dual reboot seems like firmware detects and tries to fix Flash Protection Lock by itself. There may be additional high-level protections in the firmware that can't be unlocked by just changing settings.

This tool (setup_var.efi) relies on "by-the-book" approaches (UEFI standard-defined services) rather than hacks to work, as bypassing firmware limitations can be very tricky, implementation-specific and often requires leaked information. In the case of standard setting values, most OEMs simply hide them from the Settings UI instead of protecting them from being overwritten. Therefore, this topic is not the primary focus of this repository.

Since you have tried FPRR, I don't think there are more methods I've learnt about BIOS modding that could help here. (Though this tool is all about BIOS modding, I haven't met many modding requirements myself and thus didn't learn or participate much into the community)

Using a SPI programmer to directly write BIOS image was the last resort, but given that nowadays the OEMs making many more security-related stuff into the firmware, I'm not sure if that would trigger more protections.

Besides, I've heard of a project called BITS that can load microcode and chainload other UEFI OS. You might find it interesting if you only want to boot an OS that doesn't have support for live microcode loading.


I've closed the issue as it's not directly related to the repository, but feel free to continue this thread if you think it's necessary.