Universal Bios Extractor Tool
Charise Scrivner
Hi there,
The BIOS capture as below,
Main
Advance
Boot
Security
Exit
Seems like just a few options within my BIOS.
So is it possible to insert UEFI module?
Or is it possible to unlock all hiding advance options.
I do not understand how it could remain the same. If everything is as you say, then the BIOS was not flashed. Which cannot be.
Or may you try with your previos running enviroment, but BIOS (.bin file) from TWHQR192.rar?
@Bruce
File extensions do not exist when we mean binaries. So bin=fd=rom=whatever. Maybe you would like to try the flashing method for DOS? I recommend it because if we succeed it will make the BIOS MOD universal for everyone.
And only then, I think, it will be reasonably to resort to FPT tool.
As I've reported earlier, VerifyMsrE2.efi reports my MSR 0xE2 as locked and ControlMsrE2.efi can't find CFGLock. Could it be that my MSR 0xE2 is unlocked, but it's simply not visible to VerifyMsrE2 and ControlMsrE2? Does VerifyMsrE2 report MSR 0xE2 as "locked" if it can't find it? Details below.
I'm currently booting my rig with OC 0.6.7 (Both Catalina 10.15.7 and Big Sur 11.2.3). VerifyMsrE2 reports my MSR 0xE2 as locked. ControlMsrE2 can't find my MSR 0xE2 to unlock it. I've attempted to examine my BIOS.bin with UEFITool / Universal IFR Extractor but can't find the required SETUP region for MSR 0xE2 (same as @MacKonsti reported for his NUC8). With CLOVER r5122 (Catalina), I needed KernelPm patch enabled in order to boot. With OC 0.6.7, I'm finding that I don't need AppleCpuPmCfgLock or AppleXcpmCfgLock enabled to boot.
@Slice I'm booting with OC 0.6.7 now - hard to go back to CLOVER, but I can reference old debug logs. I last captured the attached F2 preboot.log in CLOVER r5122. My CLOVER config.plist is also attached. VerifyMsrE2.efi (OC Tools) reports my MSR 0xE2 as locked. ControlMsrE2 (OC Tools) cannot find my MSR 0xE2. I am currently running OC 0.6.7 with AppleCpuPmCfgLock and AppleXcpmCfgLock both false and OC boots Big Sur 11.2.3 and Catalina 10.15.7 without any problems. With KernelPm = false (CLOVER) I could not boot Catalina 10.15.7.
@Slice I'm booting with OC 0.6.7 now - hard to go back to CLOVER, but I can reference old debug logs. I last captured the attached F2 preboot.log in CLOVER r5122. My CLOVER config.plist is also attached. VerifyMsrE2.efi (OC Tools) reports my MSR 0xE2 as locked. ControlMsrE2 (OC Tools) cannot find my MSR 0xE2. I am currently running OC 0.6.7 with AppleCpuPmCfgLock or AppleXcpmCfgLock both false and OC boots Big Sur 11.2.3 and Catalina 10.15.7 without any problems. With KernelPm = false (CLOVER) I could not boot Catalina 10.15.7.
@Slice I see that CLOVER says it's locked and VerifyMsrE2 says it's locked, too, but I question the result. I can't find CFG Lock in the BIOS.bin and ControlMsrE2 can't find it. My OC 0.6.7 config.plist is attached. This OC 0.6.7 config.plist is what I'm current using to boot Catalina 10.15.7 and BS 11.2.3. AppleCpuPmCfgLock or AppleXcpmCfgLock are both false. My rig is defined here.
@Slice If my MSR 0xE2 register is truly locked (and not just invisible to ControlMsrE2), would I observe a kernel panic on every boot, or just on rare instances? I have been running with AppleCpuPmCfgLock and AppleXcpmCfgLock set to FALSE today and have booted/rebooted 5 or 6 times without problems. If this is just an intermittent boot issue, then I will need to test longer.
EDIT: I don't believe that OC is providing any CPU Speedstep. I believe that I have my rig running with native macOS CPU Power Management. I suspect that @Andrey1970 knows this answer better than I do.
@Slice You are correct - I was confusing the two concepts. I did not understand that the CPU register and the BIOS Option were two separate entities. Now I understand why VerifyMsrE2 and CLOVER can "see" that the CPU register is locked without having access to the BIOS CFG Unlock Option. Thank you very much for teaching me!
Glad to see you have this sorted out now @tonyx86. I believe Intel and HP and perhaps Dell and big makers, do hide the ability to unlock this register from BIOS hence why we can't find any reference of this (unless it's a totally masked variable name only known to the manufacturer!)
0:103 0:000 MSR 0xE2 is locked, PM patches will be turned on
On my NUC10 that is not using this Visual BIOS but some other variant, the "cfg" variable is found and I can unlock it. Perhaps a choice of the manufacturer or change of heart. But A LOT of manufacturers lock down this darn register without offering a BIOS option.
On my NUC10 that is not using this Visual BIOS but some other variant, the "cfg" variable is found and I can unlock it. Perhaps a choice of the manufacturer or change of heart. But A LOT of manufacturers lock down this darn register without offering a BIOS option.
@tonyx86 another method I forgot to mention to validate the CFG Lock support is to run AppleIntelInfo.kext and check out the output. There is a mention for that lock thing. The problem is that until Mojave we could run this manually, but after the stricter protection, we need to include it temporarily in our EFI folder and load it in config.plist (if using OpenCore). The original work was done by -Alpha/AppleIntelInfo here, but not sure who took over and continued the work, I could not find a more modern version and reference.
If anyone knows where to find a more modern and/or improved version of Piker's work, please kindly post it? @Slice and @Andrey1970 any idea? Or a signed kext that may run under Catalina?
Thanks
I made a bios dump using the AFUDOS utility and also using the universal bios backup toolkit 2.0 program and opened both backups in the UEFI Tool application and tried to find the text "CFG Lock" there, but nothing was found.
What's worse is that BIOS/firmware updates can also LOCK this value even if it's exposed. This happened on my Intel NUC10; I used to be able to change it, but after latest BIOS update, it's switched to read-only value
If all of the OKs (ie, a write to the BIOS settings memory is enabled), then the setting is saved. And it will not be reset if you do not update the BIOS firmware and do not discard the BIOS settings before the default settings.
Nice guide, thanks you mate. I saw the same work on UEFI tables on Dell laptops, if i get it well, you could edit a lot of bios settings like this ofter the boot? Do you confirm it? Like the overclocking or the turbo current/time lock? Evrithing without really editin/flashing the bios?
if i get it well, you could edit a lot of bios settings like this ofter the boot? Do you confirm it? Like the overclocking or the turbo current/time lock? Evrithing without really editin/flashing the bios?
Yes it is. We assign the address of the desired setting and change it. The most important thing is that there would be write access to the BIOS settings memory. If there is no access to write, then only in the BIOS patch.
I mean if the bios is UEFI but the actual windows install is on normal MBR, i was too lazy today to build again my usb stick used for installing win 10. Even it should be UEFI boot ready, no way the laptop get it with UEFI mode only enable. So i went on a normal MBR install i think.
Hmm, just curious did anyone with AMI Bios actually when through with the setup_var step? I ask this because I tried to help a Dell user back then using this method since Dell mess with the original AMI Bios too much to unlock it by manually moding the bios and reflash. Insyde bioses work fine with setup_var method though.
Dell Latitudes/Precisions with AMI BIOS allow setup_var UEFI variable changes. A collection of 2nd-4th Gen Dell Latitude and Precision IFR reference files containing the UEFI variables is available at: -shared/Dell_IFR/
For Windows, you can edit bios settings directly in there, then save the file and flash it with either AFUWINGUI, or FPT (Intel Flash Programming Tool) with "fptw64 -f filename.rom -BIOS". You can read the bios with either AFUWINGUI or FPT too, and use that file in AMIBCP to set the options.
So i have the same hex value for different variables settings in my IFR.txt, when lunch the UEFI tool to edit the values, if i check if Turbo is enable so 0x1, the reported value for the Turbo is 0x0 disable when i read it.
Now, Im stuck up with BIOS update. On start-up of my laptop(Pavillion DV6000), all I could see is blank screen. All of its multimedia touch keys are lighted up, I could hear the hard disk been read-up. After all this, its is not starting up. I have been trying to get it restored.
I bought a pavillon dv6-2012sf two years ago and this morning I could not get it working. It stopped before loading the BIOS with the the two LEDS (cap lock and num lock) blinking twice. I have checked on the HP website ( -en/document/c02693833 to get the meaning of these LEDS and their blinking code. It is said that it comes from a "corrupted BIOS". Unfortunately I have removed for space reasons the HP_TOOLS volume on my HDD. It means that I only can recover the BIOS by using an external storage device which will be my USB key. For this, I have downloaded the utility HP Unified Extensible Firmware Interface (UEFI) Support Environment on the webpage ( =us&lc=en&dlc=en&softwareitem=ob-101396-1... After running the downloaded software, my USB key was renamed to HP_TOOLS and the following directories were created:
4a15465005