Modification of UEFI BIOS, part two: useful modifications
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 search methods. In addition, the light described in the first part of the UEFITool utility has not yet come up with a wedge, so other programs used to modify UEFI BIOSes from various manufacturers will be mentioned.
If the topic is interesting to you - welcome under cat.
I don’t want to repeat my tirade about the need for a SPI programmer and the fact that you make all the modifications at your own peril and risk, so if suddenly you haven’t read it, read and come back.
From this point on, I believe that with recovery from unsuccessful firmware, you don’t have a hole, and you also know UEFITool, so I’m not going to dwell on technical issues like "How do I pull a file out of an image" and "how to insert it back" .
To successfully modify your UEFI BIOS image, you may need the following tools:
Enough prefaces go to the modifications themselves. Here I will describe only those modifications that I tested myself, so the listmay be necessarily incomplete. If you have tried any other mods - please share the results in comments. The description format will be: the name of the modification or class of modifications, the purpose and a brief description of the necessary steps. Go.
')
Why : open register 0xE2 is necessary for the operation of the CPU Power Management subsystem in MacOS X, when closed, the kernel panic occurs. If you do not plan its installation or in your UEFI BIOS there is a setting “Unlock C-State MSR” - this modification is not necessary for you.
Where to look : in the UEFI-drivers related to CPU PM. In older BIOSes, the installation code for the lock is in the CpuPei module, in the new ones - in the PowerManagement module (it may also be called PowerManagement2.efi or PowerMgmtDxe.efi).
Modification method : In CpuPei, the code that needs to be modified looks like this:
In PowerManagement, the code looks different, most often like this:
If there is no such code 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 motherboards, the AMI stopped locking this register, so there is no way to find such code in them - consider that the manufacturer made this mod for you.
Why : Enable 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 is not much different from PM patch (and has already been described in Habré ), so I will not dwell on it in detail.
Why : the manufacturer's idea is clear - you can sell the owners of "incompatible" equipment also rebranded compatible at exorbitant prices. 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, for LenovoWmaPolicyDxe.efi, but it may be called otherwise.
Modification method : Notebook makers try to change the Whitelist verification code more often, then it’s pretty hard to describe some kind of permanent method.
The general search strategy is:
Details of the modification on the example of HP are well described here by comrade Donovan6000 , well known in the modders community , and I will describe a modification variant using the example of Lenovo X121E.
The check is performed by the LenovoWmaPolicyDxe.efi driver, you need to go here:
Why : with a large number of experiments with UEFI, every time the programmer gets bored quickly, and the firmware by the built-in programmer is faster (due to the work on the QuadSPI protocol instead of the usual SPI in the case of an external programmer).
Where to search : in the chipset drivers, most often in PchInitDxe (another version of the mod is in BiosWriteProtect)
Modification method : the PchInitDxe modification variant is fully described here in English, so I will only give an idea. It is necessary to find the entry of the BIOS Lock Enable (BLE) bit in the BIOS_CNTL register of the chipset and prevent it. This can be done in several places, for example, here:
If the required code was not found in PchInitDxe, you can change the BiosWriteProtect driver to bypass the registration of the SMI handler in it, which sets the BLE bit when trying to reset it, then to unlock the firmware, simply reset this bit. The above described method works fine for me, so I haven’t tried this option yet and therefore I will not describe it in detail.
Why : among these settings, something interesting might get caught, but they are usually hidden for a reason.
Where to search : for Phoenix and Insyde, the menu is stored in HII files with names like SetupMain, SetupAdvanced, etc. For AMI, the menu is stored in the Setup file, and the settings are in AMITSE. Moreover, AMI provides end-user products to its AMIBCP program, versions of which often flow into public access. Working with it is quite simple, so I don’t see any point in describing it - download and try it.
Modification method : for AMI - open the image in AMIBCP, change default settings, save, flash, reset, ready. For Insyde and Phoenix, things are a little more complicated. If the write access to NVRAM is not denied, you can use the method of Comrade Falseclock , 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, either provide it to the script described in the above article, or the Universal IFR Extractor utility, which you need to set on HII files extracted from the UEFI image. After that, it is enough to change the SUPRESS_IF conditions in the extracted HII Form file so that they are never met and all the menus will be available.
Why : sometimes the update helps to fix errors in the system, sometimes adds support for an important feature (TRIM work for SSD in RAID0, for example), but most often the update is made because finally a new version is released.
Where to search : strongly depends 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 intended, OROMs by VID / DID of the devices they serve, pictures in the format JPEG can be found by the string “JFIF”, in the GIF - by “GIF8”, etc.
Modification method : simple as mooing - to find a new version in free access, find where the old one lies in the image, and replace one with another. For AMI, comrade LS_29 was written a set for automatic updates based on the MMTool utility, you can download it from our theme on overs . I have not heard about automated solutions for Phoenix or Insyde yet.
Replacing pictures can be done either with utilities like AMI ChangeLogo, or manually, but more often than not a specially prepared picture causes a hang, since image format decoders are very limited. In general, it is better to delete the EXIF ​​data in advance.
In this article I described only those mods that I successfully made with my own hands. If you have any comments and additions - I will be glad to your comments.
Once again, I will humbly ask the administration of Habr and personally the UFO to create the UEFI hub, because this is a very broad topic, and there is literally no place to put articles on it.
Thank you for your attention, I wish you successful modifications.
If the topic is interesting to you - welcome under cat.
Introduction and another disclaimer
I don’t want to repeat my tirade about the need for a SPI programmer and the fact that you make all the modifications at your own peril and risk, so if suddenly you haven’t read it, read and come back.
From this point on, I believe that with recovery from unsuccessful firmware, you don’t have a hole, and you also know UEFITool, so I’m not going to dwell on technical issues like "How do I pull a file out of an image" and "how to insert it back" .
Required Tools
To successfully modify your UEFI BIOS image, you may need the following tools:
- Hex editor of your choice.
- The image editor UEFI, for which, for obvious reasons, I will use UEFITool, but you can also use PhoenixTool (universal and well-debugged, but not without restrictions) or MMTool (more or less tolerably works only with AMI Aptio images).
- If there is no permanent pattern for the required modification, an assembler and disassembler with x86-64 support may be required. The assembler is quite adequate online , but the disassembler needs a normal one, otherwise searches for the modification point can be very long.
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 in the Microsoft compiler set, and for MacOS X, either objdump or the Hopper Disassembler trial version. - If the modification can be performed by the 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,” so most often there is no suitable utility from the manufacturer.
Modifications
Enough prefaces go 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 POSTWhy : open register 0xE2 is necessary for the operation of the CPU Power Management subsystem in MacOS X, when closed, the kernel panic occurs. If you do not plan its installation or in your UEFI BIOS there is a setting “Unlock C-State MSR” - this modification is not necessary for you.
Where to look : in the UEFI-drivers related to CPU PM. In older BIOSes, the installation code for the lock is in the CpuPei module, in the new ones - in the PowerManagement module (it may also be called PowerManagement2.efi or PowerMgmtDxe.efi).
Modification method : In CpuPei, the code that needs to be modified looks like this:
It is enough to replace in this place 00800018 with 00000018 and 00800000 with 00000000 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 simply bury the entire lock installation code. The easiest thing to do is the first. 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 the value from this variable into the 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 there is no such code 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 motherboards, the AMI stopped locking this register, so there is no way to find such code in them - consider that the manufacturer made this mod for you.
AES NI unlock
What : bypassing the LOCK bit (0x02) to the MSR 0x13C registerWhy : Enable 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 is not much different from PM patch (and has already been described in Habré ), so I will not dwell on it in detail.
Whitelist removal
What : Bypassing the white list of compatible hardware that some laptop manufacturers use in their UEFI BIOSes.Why : the manufacturer's idea is clear - you can sell the owners of "incompatible" equipment also rebranded compatible at exorbitant prices. 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, for LenovoWmaPolicyDxe.efi, but it may be called otherwise.
Modification method : Notebook makers try to change the Whitelist verification code more often, then it’s pretty hard to describe some kind of permanent method.
The general search strategy is:
- 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 references this message.
- Investigate this code and try to change it so that the check always ends successfully. You can do this in two ways: either patch the transition, or add your Vendor ID and Device ID to the white list.
Details of the modification on the example of HP are well described here by comrade Donovan6000 , well known in the modders community , and I will describe a modification variant using the example of Lenovo X121E.
The check is performed by the LenovoWmaPolicyDxe.efi driver, you need to go here:
All transitions to this code need to be patched to unconditional, and in the code itself you need to “close up” 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 modified UEFI images with the built-in programmer.Why : with a large number of experiments with UEFI, every time the programmer gets bored quickly, and the firmware by the built-in programmer is faster (due to the work on the QuadSPI protocol instead of the usual SPI in the case of an external programmer).
Where to search : in the chipset drivers, most often in PchInitDxe (another version of the mod is in BiosWriteProtect)
Modification method : the PchInitDxe modification variant is fully described here in English, so I will only give an idea. It is necessary to find the entry of the BIOS Lock Enable (BLE) bit in the BIOS_CNTL register of the chipset and prevent it. This can be done in several places, for example, here:
You can change JE to JMP, but sometimes, instead of a short jump, you come across a long one, which additionally has to calculate the offset, so it’s better to change the test to any command that sets the ZF flag, for example, xor rax, rax (48 31 C0), and the possible difference in size commands correct by adding NOPs.48 8B 4C 24 40 mov rcx, qword ptr [rsp + 40h]; Download the address of the PchPlatformData structure to RCX 48 8B 41 50 mov rax, qword ptr [rcx + 50h]; And in RAX - the address of the child structure LockdownConfig F6 00 10 test byte ptr [rax], 10h; Check if the fifth bit is set (BiosLock) 74 25 je 0000000180001452; If not set, jump over all 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 LPC chipset registers, and 0xDC is the offset of the BIOS_CNTL register 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; Install lok
If the required code was not found in PchInitDxe, you can change the BiosWriteProtect driver to bypass the registration of the SMI handler in it, which sets the BLE bit when trying to reset it, then to unlock the firmware, simply reset this bit. The above described method works fine for me, so I haven’t tried this option yet and therefore I will not describe it in detail.
Advanced settings unlock
What : unlocking access to hidden BIOS Setup.Why : among these settings, something interesting might get caught, but they are usually hidden for a reason.
Where to search : for Phoenix and Insyde, the menu is stored in HII files with names like SetupMain, SetupAdvanced, etc. For AMI, the menu is stored in the Setup file, and the settings are in AMITSE. Moreover, AMI provides end-user products to its AMIBCP program, versions of which often flow into public access. Working with it is quite simple, so I don’t see any point in describing it - download and try it.
Modification method : for AMI - open the image in AMIBCP, change default settings, save, flash, reset, ready. For Insyde and Phoenix, things are a little more complicated. If the write access to NVRAM is not denied, you can use the method of Comrade Falseclock , 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, either provide it to the script described in the above article, or the Universal IFR Extractor utility, which you need to set on HII files extracted from the UEFI image. After that, it is enough to change the SUPRESS_IF conditions in the extracted HII Form file so that they are never met and all the menus will be available.
CPU Microcode, OptionROM, drivers and images update
What : update of CPU microcodes, firmware of various peripheral devices, EFI-drivers and images displayed at boot and in BIOS Setup.Why : sometimes the update helps to fix errors in the system, sometimes adds support for an important feature (TRIM work for SSD in RAID0, for example), but most often the update is made because finally a new version is released.
Where to search : strongly depends 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 intended, OROMs by VID / DID of the devices they serve, pictures in the format JPEG can be found by the string “JFIF”, in the GIF - by “GIF8”, etc.
Modification method : simple as mooing - to find a new version in free access, find where the old one lies in the image, and replace one with another. For AMI, comrade LS_29 was written a set for automatic updates based on the MMTool utility, you can download it from our theme on overs . I have not heard about automated solutions for Phoenix or Insyde yet.
Replacing pictures can be done either with utilities like AMI ChangeLogo, or manually, but more often than not a specially prepared picture causes a hang, since image format decoders are very limited. In general, it is better to delete the EXIF ​​data in advance.
Conclusion
In this article I described only those mods that I successfully made with my own hands. If you have any comments and additions - I will be glad to your comments.
Once again, I will humbly ask the administration of Habr and personally the UFO to create the UEFI hub, because this is a very broad topic, and there is literally no place to put articles on it.
Thank you for your attention, I wish you successful modifications.
Source: https://habr.com/ru/post/211879/
All Articles