February 9, 2014 at 21:19UEFI BIOS Modification Part Two: Useful Modifications
- Tutorial
In this article I will try to talk about the most popular and useful modifications of the UEFI BIOS, the conditions of their use and the search methods. In addition, the light in the UEFITool utility described in the first part has not yet wedged, so other programs used to modify UEFI BIOSes from various manufacturers will be mentioned.
If you are interested in the topic - welcome to cat.
I do not want to repeat my tirade about the need for an SPI programmer and the fact that you make all the modifications at your own peril and risk, so if you suddenly did not read it, read it and come back.
From now on, I believe that you do not have a problem with recovery from unsuccessful firmware, and you are also familiar with UEFITool, so I will not dwell on technical issues such as “How do I extract a file from an image” and “how to insert it back then” .
To successfully modify your UEFI BIOS image, the following tools may be required:
Enough preface, let's move on to the modifications themselves. Here I will describe only those modifications that I tested myself, so the listmay be necessarily incomplete. If you tried any other mods - please share the results in the comments. The description format will be as follows: name of the modification or class of modifications, purpose and brief description of the necessary steps. Go.
Why : the open register 0xE2 is necessary for the CPU Power Management subsystem to work in MacOS X, and when closed, the kernel panic occurs. If you do not plan to install it or your Unified C-State MSR is present in your UEFI BIOS, you do not need this modification.
Where to look : in CPU-related UEFI drivers. In old BIOSes, the lock setup code is in the CpuPei module, in new BIOSes, in the PowerManagement module (it can also be called PowerManagement2.efi or PowerMgmtDxe.efi).
Modification method : In CpuPei, the code to be modified looks something like this:
In PowerManagement, the code looks different, most often like this:
If no such code was found in your UEFI BIOS, look for 0xE2 in the drivers related to CPU Power Management and check the entire code for setting the 15th bit. In the latest BIOS versions for some modern desktop AMI boards, they no longer lock this register, so this code cannot be found in them anymore - consider that the manufacturer made this mod for you.
Why : enabling AES hardware acceleration on systems with export restrictions
Where to look : in UEFI drivers related to CPU PM, most often in PowerManagement Modification
method : it differs little from PM patch '(and it was already described on a habr ), therefore I will not dwell on it in detail.
Why : the manufacturer’s idea is clear - you can also sell rebranded compatible exorbitant prices to owners of "incompatible" equipment. If you yourself want to decide what equipment is compatible with your laptop - this modification is for you.
Where to look : in UEFI drivers related to PCIe devices. For HP, this driver is usually called BiosLockPcie, for Lenovo it is LenovoWmaPolicyDxe.efi, but may be called differently.
Modification Method : Notebook manufacturers are trying to change the Whitelist verification code more often, it is rather difficult to describe some permanent method.
The general search strategy is as follows:
The details of the modification on the example of HP are well described here by the comrade Donovan6000 , widely known in modder circles , and I will describe the modification variant on the example of the Lenovo X121E.
The verification is carried out by the LenovoWmaPolicyDxe.efi driver, you need to get here:
Why : with a large number of experiments with UEFI, getting the programmer quickly gets boring every time, and firmware is faster with the built-in programmer (due to QuadSPI protocol operation instead of the usual SPI in the case of an external programmer).
Where to look : in the chipset drivers, most often in PchInitDxe (another version of the mod is in BiosWriteProtect)
Modification method : the modification option for PchInitDxe is fully described here in English, so I will give only an idea. It is necessary to find the BIOS Lock Enable (BLE) bit record in the BIOS_CNTL register of the chipset and prevent it. You can do this in several places, for example, here:
If the desired code was not found in PchInitDxe, you can change the BiosWriteProtect driver in such a way as to bypass the registration of the SMI handler located in it, which sets the BLE bit when trying to reset it, after which it is enough to clear this bit to unlock the firmware. The above method works fine for me, so I have not tried this option yet and therefore I will not describe it in detail.
Why : among these settings, something interesting may come across, but usually they are hidden for a reason.
Where to look : for Phoenix and Insyde, menus are stored in HII files with names like SetupMain, SetupAdvanced, etc. For AMI, the menu is stored in the Setup file, and the settings are stored in AMITSE. Moreover, AMI provides its end-user product manufacturers with its AMIBCP program, versions of which often go public. Working with it is quite simple, so I do not see the point of describing it - download and try it.
Modification Method: for AMI - open the image in AMIBCP, change the default settings, save, flash, perform a factory reset, done. For Insyde and Phoenix, things are a little more complicated. If write access to NVRAM is not denied, you can use the Falseclock comrade method described in this article , but if there is no access, you will have to modify the firmware. You will need to parse the HII Form File format either manually, or provide this to the script described in the above article, or the Universal IFR Extractor utility , which must be set to the extracted HII files from the UEFI image. After that, just change the SUPRESS_IF conditions in the extracted HII Form file so that they never run and all the menus become available.
Why : sometimes the update helps to fix errors in the system, sometimes it adds support for an important feature (TRIM for SSD in RAID0, for example), but most often the update is done because a new version has finally been released.
Where to look : it depends heavily on the manufacturer, EFI drivers can be found simply by name (SataDriver, for example), microcode can be found by the Model ID of the processor for which it is designed, OROMs by the VID / DID of the devices they serve, pictures in format JPEG can be found by the string “JFIF”, in GIF - by “GIF8”, etc.
Modification Method: simple as a lowing - find a new version in the public domain, find where the old one is in the image, and replace one with the other. For AMI friend LS_29 was written set to update automatically based on MMTool utility, you can download it from our theme on overs . I have not heard about automated solutions for Phoenix or Insyde.
Replacing pictures can be done either by utilities like AMI ChangeLogo, or manually, but more often than not specially prepared picture causes a freeze, because image format decoders are very limited. In general, it is better to delete EXIF data in advance.
In this article, I described only those mods that I successfully did with my own hands. If you have any comments or additions - I will be glad to your comments.
Once again, I humbly ask the Habr administration and UFO personally about the creation of the UEFI hub, because this is a very broad topic, and there is literally nowhere to poke articles on it.
Thank you for your attention, I wish you successful modifications.
If you are interested in the topic - welcome to cat.
Introduction and another disclaimer
I do not want to repeat my tirade about the need for an SPI programmer and the fact that you make all the modifications at your own peril and risk, so if you suddenly did not read it, read it and come back.
From now on, I believe that you do not have a problem with recovery from unsuccessful firmware, and you are also familiar with UEFITool, so I will not dwell on technical issues such as “How do I extract a file from an image” and “how to insert it back then” .
Necessary tools
To successfully modify your UEFI BIOS image, the following tools may be required:
- Hex editor of your choice.
- The UEFI image editor, for which, for obvious reasons, I will use UEFITool, but you can also use PhoenixTool (universal and well-debugged, but not without limitations) or MMTool (more or less tolerably works only with AMI Aptio images).
- If there is no permanent pattern for the necessary modification, an assembler and disassembler with x86-64 support may be required. The assembler is quite online , but the disassembler needs a normal one, otherwise the search for the modification point can take a long time.
Unfortunately, the free version of IDA Pro does not support parsing 64-bit PE files, so for Windows I recommend using the dumpbin utility included with Microsoft compilers, and for MacOS X either objdump or a trial version of Hopper Disassembler. - If the modification can be performed by a utility from the manufacturer of the UEFI platform, let it be done to it - this is more reliable than manually. Unfortunately, “the circle of these revolutionaries is narrow and they are terribly far from the people,” therefore most often there is no suitable utility from the manufacturer.
Modifications
Enough preface, let's move on to the modifications themselves. Here I will describe only those modifications that I tested myself, so the list
CPU PM patch, MSR 0xE2 lock removal
What : bypassing the setting of the LOCK bit (0x0F) to the MSR_PMG_CST_CONFIG_CONTROL (0xE2) register after passing POSTWhy : the open register 0xE2 is necessary for the CPU Power Management subsystem to work in MacOS X, and when closed, the kernel panic occurs. If you do not plan to install it or your Unified C-State MSR is present in your UEFI BIOS, you do not need this modification.
Where to look : in CPU-related UEFI drivers. In old BIOSes, the lock setup code is in the CpuPei module, in new BIOSes, in the PowerManagement module (it can also be called PowerManagement2.efi or PowerMgmtDxe.efi).
Modification method : In CpuPei, the code to be modified looks something like this:
It is enough to replace 00800018 with 00000018 and 00800000 with 00000000 in this place to bypass the installation of the lock.81 FB D0 06 02 00 cmp ebx, 206D0h 75 0C jne FFFE426E 0D 00 80 00 18 or eax, 18008000h; Bit 15 (LOCK) is set here. EB 05 jmp FFFE426E 0D 00 80 00 00 or eax, 8000h; Or here 6A FF push 0FFFFFFFFh 6A F8 push 0FFFFFFF8h 6A 00 push 0 50 push eax 56 push esi E8 DC 0F 00 00 call FFFE5257; And inside this function is wrmsr
In PowerManagement, the code looks different, most often like this:
You can replace JNE with JMP, BTS with BTR, or just “scoop” all the lock setup code. The easiest way to do the first, i.e. change 75 08 to EB 08.80 FB 01 cmp bl, 1; If BL == 1 75 08 jne 0000000180002700; Jump over the next two teams 0F BA E8 0F bts eax, 0Fh; Set bit 15 (LOCK) 89 44 24 30 mov dword ptr [rsp + 30h], eax; Save result to variable on stack 48 8B 54 24 30 mov rdx, qword ptr [rsp + 30h]; Load value from this variable into RDX B9 E2 00 00 00 mov ecx, 0E2h; And the MSR number in ECX E8 79 0C 00 00 call 0000000180003388; And call the function with wrmsr inside
If no such code was found in your UEFI BIOS, look for 0xE2 in the drivers related to CPU Power Management and check the entire code for setting the 15th bit. In the latest BIOS versions for some modern desktop AMI boards, they no longer lock this register, so this code cannot be found in them anymore - consider that the manufacturer made this mod for you.
AES NI unlock
What : bypassing setting the LOCK bit (0x02) to the MSR 0x13C registerWhy : enabling AES hardware acceleration on systems with export restrictions
Where to look : in UEFI drivers related to CPU PM, most often in PowerManagement Modification
method : it differs little from PM patch '(and it was already described on a habr ), therefore I will not dwell on it in detail.
Whitelist removal
What : Bypassing the white list of compatible hardware that some notebook manufacturers use in their UEFI BIOSs.Why : the manufacturer’s idea is clear - you can also sell rebranded compatible exorbitant prices to owners of "incompatible" equipment. If you yourself want to decide what equipment is compatible with your laptop - this modification is for you.
Where to look : in UEFI drivers related to PCIe devices. For HP, this driver is usually called BiosLockPcie, for Lenovo it is LenovoWmaPolicyDxe.efi, but may be called differently.
Modification Method : Notebook manufacturers are trying to change the Whitelist verification code more often, it is rather difficult to describe some permanent method.
The general search strategy is as follows:
- Insert an incompatible card into the notebook, wait for the message about the impossibility of loading and remember it.
- Find this message in one of the FFS files.
- Find the code that refers to this message.
- Examine this code and try changing it so that the check always succeeds. You can do this in two ways: either patch the transition, or add your Vendor ID and Device ID to the white list.
The details of the modification on the example of HP are well described here by the comrade Donovan6000 , widely known in modder circles , and I will describe the modification variant on the example of the Lenovo X121E.
The verification is carried out by the LenovoWmaPolicyDxe.efi driver, you need to get here:
All transitions to this code need to be patched to unconditional, and in the code itself it is necessary to "scoop" the first and second lines, after which the check will always end successfully.44 38 0D F0 0F 00 00 cmp byte ptr [00001BF0h], r9b 75 18 jne 0000000000000C1A E8 35 FD FF FF call 000000000000093C 48 85 C0 test rax, rax 4C 8B C8 mov r9, rax 0F 88 77 FF FF FF js 0000000000000B8A C6 05 D6 0F 00 00 01 mov byte ptr [00001BF0h], 1 49 8B C1 mov rax, r9 E9 68 FF FF FF jmp 0000000000000B8A
BIOS lock removal
What : removing protection from firmware for modified UEFI images by the built-in programmer.Why : with a large number of experiments with UEFI, getting the programmer quickly gets boring every time, and firmware is faster with the built-in programmer (due to QuadSPI protocol operation instead of the usual SPI in the case of an external programmer).
Where to look : in the chipset drivers, most often in PchInitDxe (another version of the mod is in BiosWriteProtect)
Modification method : the modification option for PchInitDxe is fully described here in English, so I will give only an idea. It is necessary to find the BIOS Lock Enable (BLE) bit record in the BIOS_CNTL register of the chipset and prevent it. You can do this in several places, for example, here:
You can change JE to JMP, but sometimes instead of a short jump you get a long one that has to additionally calculate the offset, so it's better to change test to any command that sets the ZF flag, for example to xor rax, rax (48 31 C0), and the possible size difference commands to fix by adding NOPs.48 8B 4C 24 40 mov rcx, qword ptr [rsp + 40h]; Load the PchPlatformData structure address into RCX 48 8B 41 50 mov rax, qword ptr [rcx + 50h]; And in RAX - the address of the LockdownConfig child structure F6 00 10 test byte ptr [rax], 10h; Check if the fifth bit is set (BiosLock) 74 25 je 0000000180001452; If not installed, jump over all the code below 8A 50 01 mov dl, byte ptr [rax + 1] B9 B2 00 00 00 mov ecx, 0B2h; E8 A2 5A 00 00 call 0000000180006EDC 4C 8D 87 DC 00 00 00 lea r8, [rdi + 000000DCh]; The RDI is the base address of the chipset's LPC registers, and 0xDC is the BIOS_CNTL register offset 33 C9 xor ecx, ecx 4C 8B CD mov r9, rbp 33 D2 xor edx, edx 4C 89 44 24 20 mov qword ptr [rsp + 20h], r8 E8 AA 76 00 00 call 0000000180008AFC; Set lock
If the desired code was not found in PchInitDxe, you can change the BiosWriteProtect driver in such a way as to bypass the registration of the SMI handler located in it, which sets the BLE bit when trying to reset it, after which it is enough to clear this bit to unlock the firmware. The above method works fine for me, so I have not tried this option yet and therefore I will not describe it in detail.
Advanced settings unlock
What : unlocking access to hidden BIOS Setup settings.Why : among these settings, something interesting may come across, but usually they are hidden for a reason.
Where to look : for Phoenix and Insyde, menus are stored in HII files with names like SetupMain, SetupAdvanced, etc. For AMI, the menu is stored in the Setup file, and the settings are stored in AMITSE. Moreover, AMI provides its end-user product manufacturers with its AMIBCP program, versions of which often go public. Working with it is quite simple, so I do not see the point of describing it - download and try it.
Modification Method: for AMI - open the image in AMIBCP, change the default settings, save, flash, perform a factory reset, done. For Insyde and Phoenix, things are a little more complicated. If write access to NVRAM is not denied, you can use the Falseclock comrade method described in this article , but if there is no access, you will have to modify the firmware. You will need to parse the HII Form File format either manually, or provide this to the script described in the above article, or the Universal IFR Extractor utility , which must be set to the extracted HII files from the UEFI image. After that, just change the SUPRESS_IF conditions in the extracted HII Form file so that they never run and all the menus become available.
CPU Microcode, OptionROM, drivers and images update
What : updating the microcode of the CPU, the firmware of various peripheral devices, EFI drivers and images displayed at boot time and in BIOS Setup.Why : sometimes the update helps to fix errors in the system, sometimes it adds support for an important feature (TRIM for SSD in RAID0, for example), but most often the update is done because a new version has finally been released.
Where to look : it depends heavily on the manufacturer, EFI drivers can be found simply by name (SataDriver, for example), microcode can be found by the Model ID of the processor for which it is designed, OROMs by the VID / DID of the devices they serve, pictures in format JPEG can be found by the string “JFIF”, in GIF - by “GIF8”, etc.
Modification Method: simple as a lowing - find a new version in the public domain, find where the old one is in the image, and replace one with the other. For AMI friend LS_29 was written set to update automatically based on MMTool utility, you can download it from our theme on overs . I have not heard about automated solutions for Phoenix or Insyde.
Replacing pictures can be done either by utilities like AMI ChangeLogo, or manually, but more often than not specially prepared picture causes a freeze, because image format decoders are very limited. In general, it is better to delete EXIF data in advance.
Conclusion
In this article, I described only those mods that I successfully did with my own hands. If you have any comments or additions - I will be glad to your comments.
Once again, I humbly ask the Habr administration and UFO personally about the creation of the UEFI hub, because this is a very broad topic, and there is literally nowhere to poke articles on it.
Thank you for your attention, I wish you successful modifications.
