Jump to content
About Just Joined group Read more... ×
CodeRush

[UEFIPatch] UEFI patching utility

1,987 posts in this topic

Recommended Posts

Advertisement

For Dell machines with Phoenix Secure Core Tiano UEFI 2.0, such as Vostro 3750, L502x etc you can apply the patch straight to the .exe you have got from Dell.

Then flash it as if it was a stock updater thereafter. As said in the original post it will unlock all the advanced menus available for a particular machine you are patching for. The patch sequence used in this utility has originated from bios-mods, you can read this article for in-depth details on the advanced menus.

Share this post


Link to post
Share on other sites

k3nny, FTK for Windows is easier to use and don't have any CAP verification at all, but I still don't recommend to flash BIOS under Windows - it's way too risky.

Any other system program or driver can interfere with flashing process and make unpredictable results. With strong antivirus or virtual machine enabled this chance is rather high.

It's less dangerous to use flashrom under Linux or OS X, but DOS or is still better, because nothing can interfere with flashing process in single task system (if a bunch of drivers and/or TSR's don't loaded, of course).

More to say, flashing with non-Asus tools leads to individual data loss, so now you have to restore your SMBIOS UUID, LAN MAC and Motherboard S/N using FD44Editor and then reflash BIOS to write the restored data.

Read my post on [H] linked above.

Share this post


Link to post
Share on other sites

buoo, yes and no.

The pattern to find is also 75080fbae80f89442430, but there are 6 different patch variants that the program is trying to perform.

I have made an analysis of that assembly (warning, crappy Google-translate from Russian) and now is a bit more complex then just patching 0x75 to 0xeb.

Different patch variants are needed because after 0x75 to 0xeb patch the compressed module is often 1 byte bigger than original and there are BIOS versions that don't have even 1 byte of free space to insert it.

Share this post


Link to post
Share on other sites

Lenovo ThinkPad R61i 8932-FDG (Phoenix)

Not an UEFI, can't be patched with this program.

Intel SC5520SC

Has different module organisation and doesn't have PowerManagement or CpuPei modules to patch.

Is a patch required for this board to work with native AppleICPM.kext? Is there any patched BIOS for this board anywhere?

Share this post


Link to post
Share on other sites

Lenovo ThinkPad R61i and Intel SC5520SC require patching AICPUPM.kext. I haven't seen anyone who patched Intel EFI BIOSes.

 

EDIT: about Lenovo:

 

UEFI BIOS Version 8JET42WW (1.36) 
UEFI BIOS Date 2012-05-15

Share this post


Link to post
Share on other sites

oswaldini, 8JET42WW can be patched by version 0.5.9 after unpacking, BIOS file to patch is $0A8J000.FL1

There is no problem to patch Intel EFI file, the main problem is to flash patched file to BIOS chip on Intel boards.

I don't know any method to flash modified Intel BIOSes with standard Intel tools, but I do know two methods to unlock access to whole BIOS and flash it with Intel Flash Programming Tool.

Another possible way to flash modified BIOS is described by phpdev32 in his mail:

I can report that the Intel DQ77KB thin mITX build I made this weekend worked just fine. Naturally I tested the newest ROM with PMPatch before I even bought the parts (just to be safe)' date=' but the F7 BIOS flasher worked just fine. I'm pretty sure the recovery flash didn't work, restarted several times without flashing, but that isn't critical. I imagine anyone wanting to repair the BIOS could flash the stock first using recovery, then flash the patched using F7 after rebooting.[/quote']

Share this post


Link to post
Share on other sites

The utility is BSD-licensed and available on GitHub.

Compiled versions for Windows and OS X are here.

Latest version is 0.5.9

 

Much better and easier than doing it under windows with Phoenix tools and an hex editor. :)

Thumb up.

 

I need testers with different boards from different vendors to make the utility better, so if you have enough courage or a spare BIOS chip - please try it and report in this topic.

Thank you in advance.

 

Tested on my Asus P8B-WS, bios 2106 (previously patched) with a Xeon E3-1230v2.

Works without any problem, a binary file compare show differences with my "hand-patched" bios but I can't see any differences under UEFI bios screens nor working under ML 10.8.2

Sleeps and wakes as usual, speedstep is the same using the same SSDT with modified iMac12_2.plist :

 

MSRDumper PStatesReached: 16 20 27 33 35 36 37.

 

Nice work !

Share this post


Link to post
Share on other sites

I can't see any differences under UEFI bios screens nor working under ML 10.8.2

It's normal, for AMI UEFI it only patches PowerManagement module and nothing more. Thank you for report.

Share this post


Link to post
Share on other sites

Did not work for me on Intel DZ77GA70K. I press F7 and then select .bio file and PC reboots and tries to flash but then reboots again and boots into Windows.

 

C:\>pmpatch GA0061.bio GA0061A.bio
PMPatch 0.5.9
PowerManagement module at 0045CC8C patched.
AMI nest modules not found.
Phoenix nest modules not found.
CpuPei module at 001FE83C not patched: Patch pattern not found.
Output file generated.

Share this post


Link to post
Share on other sites

Intel is famous for difficulties on flashing modified BIOSes...

I know a way to overcome it, but it isn't simple.

Please download FTK for Windows from the link in third post, then open Administrator console, cd to FTK/Win32 and execute fpt -i command.

I need the output to guide you further.

Share this post


Link to post
Share on other sites

Intel is famous for difficulties on flashing modified BIOSes...

I know a way to overcome it, but it isn't simple.

Please download FTK for Windows from the link in third post, then open Administrator console, cd to FTK/Win32 and execute fpt -i command.

I need the output to guide you further.

 

C:\FTK_0.9.4_win\Win32>fpt -i

Intel (R) Flash Programming Tool. Version:  8.1.10.1286
Copyright (c) 2007 - 2012, Intel Corporation. All rights reserved.

Platform: Intel(R) Z77 Express Chipset
Reading HSFSTS register... Flash Descriptor: Valid

   --- Flash Devices Found ---
   W25Q64BV    ID:0xEF4017    Size: 8192KB (65536Kb)

   --- Flash Image Information --
   Signature: VALID
   Number of Flash Components: 1
    Component 1 - 8192KB (65536Kb)
   Regions:
    Descriptor - Base: 0x000000, Limit: 0x000FFF
    BIOS	   - Base: 0x1C0000, Limit: 0x7FFFFF
    ME		 - Base: 0x003000, Limit: 0x1BFFFF
    GbE	    - Base: 0x001000, Limit: 0x002FFF
    PDR	    - Not present
   Master Region Access:
    CPU/BIOS - ID: 0x0000, Read: 0x0B, Write: 0x0A
    ME	   - ID: 0x0000, Read: 0x0D, Write: 0x0C
    GbE	  - ID: 0x0118, Read: 0x08, Write: 0x08

Total Accessable SPI Memory: 8192KB, Total Installed SPI Memory : 8192KB

FPT Operation Passed

Share this post


Link to post
Share on other sites

OK, as we can see, ME and GbE regions are locked, BIOS region is not.

Execute fpt -bios -d dump.bin command, if it works, patch this dump.bin file with PMPatch (pmpatch dump.bin mod.bin) and flash patched file with FPT by executing fpt -bios -f mod.bin command. If it works, reboot your computer.

Share this post


Link to post
Share on other sites
C:\FTK_0.9.4_win\Win64>fpt -bios -f mod.bin

Intel (R) Flash Programming Tool. Version:  8.1.10.1286
Copyright (c) 2007 - 2012, Intel Corporation. All rights reserved.

Platform: Intel(R) Z77 Express Chipset
Reading HSFSTS register... Flash Descriptor: Valid

   --- Flash Devices Found ---
   W25Q64BV    ID:0xEF4017    Size: 8192KB (65536Kb)


Error 280: Failed to disable write protection for the BIOS space!

Share this post


Link to post
Share on other sites

It's won't be so easy, as I thought but there is a way to unlock BIOS from this kind of lock. It is described here and can be dangerous, but I tried it like 10 times and it worked.

You need to disable Intel AntiTheft before trying it.

After unlocking access to all regions, you can make a dump of Descriptor region by executing fpt -desc -d desc.bin, and edit it with Hex-editor to remove locks completely.

This values are to be set:

locki.png

Then you can flash modified Descriptor region by executing fpt -desc -f desc.bin and modified BIOS region by fpt -bios -f mod.bin. If all things goes without error, then modified BIOS is finally flashed.

This way it dangerous and can lead to BIOS loss, so I don't recommend to try it unless you have to.

Share this post


Link to post
Share on other sites

No thanks. I don't want to risk to break anything, i can't afford to buy another board if this breaks. I rathed use NullCPU or patch DSDT. There is no AntiTheft on this motherboard.

 

I don't understand why it works to flash with F7 on Intel DQ77KB http://www.insanelym...y/#entry1878932 but not on my board, they have similar BIOS.

 

My motherboard has Intel® BIOS Vault Technology but so does DQ77KB.

 

Virtually incorruptible BIOS that provides fault-tolerant and secure firmware operating and upgrade environments.

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.

Announcements

  • Similar Content

    • By miliuco
      What is CFG Lock and MSR 0xE2?
       
      CFG Lock is a BIOS setting that allows writing to a specific register, in this case MSR E2 (MSR = Model Specific Register). An MSR consists of one or more registers in blocks of instructions used to do certain tasks on a CPU. MTRs are also used to control CPU's access to memory ranges. Commands capable of reading and writing to MSR work with elevated privileges (the operating system, primarily).

      Many motherboards come from factory with MSR E2 region locked (read but not write) and quite a few of them even hide this option in BIOS user interface. In those that do show the option to block or unblock this variable, it is usually called CFG Lock. CFG Lock is a bit with 2 values, 0x1 or 0x0. When it is 0x1, macOS cannot write into this region and kernel patches are required.

      macOS wants to write this registry, both the Kernel and AppleIntelPowerManagement. It defines the C-states of the CPU, which is why it is essential for macOS. Without the ability to write to MSR E2, all or most of the CPU power management is lost and the system does not boot.

      In Clover 2 patches have been used: KernelPM (for AppleIntelPowerManagement.kext) and KernelXCPM (for the kernel). In OpenCore 2 others have been used: AppleCpuPmCfgLock (for AppleIntelPowerManagement.kext) and AppleXcpmCfgLock (for the kernel). These patches fix the problem but the registry is still read-only. To ensure native CPU power management, CFG Lock bit must be set to 0x0.

      To achieve this, the firmware must be modified to support writing to MSR E2. This method is preferred over Clover and OC patches, it generates greater system stability and the CPU power management more closely resembles that of a real Mac. The methods that are usually proposed for this task are too complex for most users who do not have a high level of knowledge, requiring specialized tools and even modified Grub.

      Below I comment on an alternative method that is much simpler and that, at least in my case, seems to have been successful. Like any of the methods that modify this bit, it has the risk of not working or even damaging the BIOS, so if you try it it is under your entire responsibility.

      CFGLock.efi

      User @Brumbaer has a tool called CFGLock.efi (see post). It is an EFI application, it has to be installed in OC Tools folder (Misc - Tools in config.plist) and in this way it is available in the OC menu next to Reset NVRAM. It should be accompanied by another tool included in the OC package called VerifyMsrE2.efi that reports current status of CFG Lock (locked / unlocked).

      When CFGLock.efi runs, it displays information (CFG variable found, varstore in which it resides, current reading and requests user intervention to make the change from 0x1 to 0x0 or vice versa). Then you have to restart. With VerifyMsrE2.efi we can check if the change has been successful.

      Both EFI applications can be run by selecting them directly in the OC menu but it is also possible, by installing OpenShell.efi tool, to run this shell and running them from there. Information for handling OpenShell.efi is available in OC and elsewhere.
       

       
      After CFGLock.efi

      I have tried CFGLock.efi and apparently it has worked well.
       
      macOS boots up and works fine with the OC patches AppleCpuPmCfgLock and AppleXcpmCfgLock disabled.
        VerifyMsrE2.efi reports "This firmware has UNLOCKED MSR 0XE2 register!".
        Hackintool in Utilities - Get AppleIntelInfo displays this text: AppleIntelInfo.kext v3.0 Copyright © 2012-2017 Pike R. Alpha. All rights reserved. IA32_MISC_ENABLES................(0x1A0) : 0x850089 ------------------------------------------ - CFG Lock............................. : 0 (MSR not locked) Note: Hackintool current version (3.4.6) doesn't show text after Get AppleIntelInfo in Big Sur beta 10. It's got from Catalina.
        Intel Power Gadget - Frequency graph shows variations between maximum and minimum suggestive of CPUPM.  

    • By qmgoqwe
      I have installed MacOS and Windows on the following hardware:
       
      AMD Ryzen 7 3700X MSI B450M Mortar Max Sapphire Radeon Pulse RX 5600 XT 6G Samsung 860 QVO, 1 TB SSD (PciRoot(0x0)/Pci(0x1,0x3)/Pci(0x0,0x1)/Sata(0x5,0xFFFF,0x0)) - MacOS on this disk Kingston A2000 SSD 1TB M.2 2280 NVMe (PciRoot(0x0)/Pci(0x1,0x1)/Pci(0x0,0x0)/NVMe(0x1,15-AD-CD-26-28-B7-26-00)) - Windows on this disk  
      OpenCore 0.6.1 MacOS 10.15.7 both disks GPT UEFI  
      Both OSs boot nicely and work as a charm when selecting either of the disks as boot disks in the BIOS.
       
      However, trying to boot Windows 10 from the Opencore Bootmanager (no matter whether PickerMode=internal or OpenCanopy) causes a Windows Blue Screen ("SYSTEM THREAD EXCEPTION NOT HANDLED").
      To be on the safe side, I have added an appropriate entry to Misc->Entries:
      <key>Arguments</key> <string></string> <key>Auxiliary</key> <false/> <key>Comment</key> <string>Not signed for security reasons</string> <key>Enabled</key> <true/> <key>Name</key> <string>Windows 10</string> <key>Path</key> <string>PciRoot(0x0)/Pci(0x1,0x1)/Pci(0x0,0x0)/NVMe(0x1,15-AD-CD-26-28-B7-26-00)/HD(1,GPT,2E9695CB-0F9A-4005-AADB-2FF9C96AD02C,0x800,0x32000)/\EFI\Microsoft\Boot\bootmgfw.efi</string> It points to the Windows 10 bootmanager on the Windows disk's EFI partition.
       
      What's wrong with that? Why does this cause a BSOD? It is not clear to me why it works when booting from BIOS but not here.
       
      config.plist attached (but maybe it has no relevance for the problem).
      config.plist
    • By jrbros1
      Hi there,
       
      So I have my Windows computer, used a USB with Clover setup to boot into Mojave OS that I installed on the SD card in the computer. The world was a great place and all was well!

      Then I did the steps to partition the pc system to now include the additional drive that I would put Clover on. Here's where I messed up: Instead of directly copying over the full Clover folder into the EFI folder of the new drive (which just had the Boot & Microsoft folders in it), I replaced the EFI's boot folder with Clover's boot folder. So the EFI folder now contains a Microsoft folder, a Clover folder, and Clover's Boot folder only.

      Now, I only can access the Clover boot up menu, the macOS, but no Windows at all. Even if I go into BIOS and pick Windows Boot Manager or Partition 1 for the start up, I get a black screen for both. I can still access the macOS as well as Shell, but I don't know what that does other than displaying all of the yellow text fly by..

      Is there a kind soul out there that can help me get Windows back to boot? Keep in mind I'm a bit of a newbie here so laying out the common-sense steps would be helpful!

      Thank you in advance!
    • By pink101
      Hello everyone, i just want to ask something. why is it that my radeon hd 7770 graphic card was detected as "Latte" gpu instead of verde when using radeon_bios_decode? is the card actually a Latte graphic card but someone flashed it so they can sold to me as radeon hd 7770? or is it actually a real radeon hd 7770 but the tool falsely detected it as latte cpu?

    • By ltooz_audis
      This is the way I patched my DSDT and SSDTs to get perfect sleep/wake and USB ports on my Skylark i7-6600u HD520 HP EliteBook 820 G3.
       
       
      Cheers,
      Louis
×