Jump to content

[UEFIPatch] UEFI patching utility

CodeRush

By CodeRush,
in UEFI

 Share
1,981 posts in this topic

Recommended Posts

StoneTemplePilots
StoneTemplePilots
Posted
Posted

I found a setting mismatch in AMIBCP at Main > (Unnamed directory): handle 02FA, BIOS Lock - Enable or disable BIOS lock enable (BLE) bit. 1001 had it disabled and 1103 enabled.

attachicon.gifamibcp_lock.jpg

 

Altering this setting from Enabled to Disabled and saving a new BIOS using AMIBCP changes one single byte from 0x01 to 0x00 in two different modules:

1) B1DA0ADF-4F77-4070-A88E-BFFE1C60529A - AMITSE

2) CEF5B9A3-476D-497F-9FDC-E98143E0422C - ?

 

To automate the patch we need to figure out how to determine the correct settings byte.

 

Running an unlocked 1104 (an update came out today) right now. Tried reflashing the same version using FPT and it worked.  :)

 

Output from RW-Everything while running FPT:

attachicon.gifrwe_lock.jpg

 

Edit:

This method doesn't seem to work with newer boards from Asus. For example it isn't possible to change the setting using AMIBCP on a Z87-PRO BIOS. Even if this would be possible, there is no way to flash such a modified BIOS without UBF I guess.

Awesome!

+-----------------------------------------------------------------------------+
| Driver Information                                                          |
+-----------------------------------------------------------------------------+
| Firmware Volume : 00               Location :  00180800   Length :  020000  |
+---+---------------+------------------------------------+--------+------+----+
|NO |    FileName   |               GUID                 |Location| Size |Type|
+---+---------------+------------------------------------+--------+------+----+
|000|               |CEF5B9A3-476D-497F-9FDC-E98143E0422C|00180848|01FFB8|RAW |
+---+---------------+------------------------------------+--------+------+----+
| Bytes Free       : 000000 (  0 KB)    Bytes Used       : 020000 (128 KB)    |
+-----------------------------------------------------------------------------+

I tried that now but fpt still shows:

 

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

 

at least in Windows 7 x64 UEFI, I'll try to flash in CSM mode. Nope, does not change anything for me.

Now I'll disable the SMI-Lock above.

Link to comment
Share on other sites
k3nny
k3nny
Posted
Posted

I tried that now but fpt still shows:

 

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

Did you flash an officially unlocked BIOS before the manually unlocked one? The lock bit can only be unset during a platform reset with a BIOS that does not set it again.
  • Like 1
Link to comment
Share on other sites
StoneTemplePilots
StoneTemplePilots
Posted
Posted

Did you flash an officially unlocked BIOS before the manually unlocked one? The lock bit can only be unset during a platform reset with a BIOS that does not set it again.

Yes, I flashed 0401.CAP with

afudos 0401.CAP /p /b /n /k ...

only after flashing 0401.CAP I can flash again with FPT but after upgrading again to the unlocked version of 2204

the same lock error appears. Also I found another place where the locks are set:

 

szv9cl.jpg

Link to comment
Share on other sites
CodeRush
CodeRush
Posted
  • Author
Posted

Awesome findings, guys.

Now we need to figure out, what code reads this setting and actually sets a lock byte, so we can patch it out.

k3nny, you are right that there is no way to flash unlocked BIOS on new ASUS boards besides external SPI programmer, but it will be needed only once to flash the initial unlocked version, so it would be great to be able to unlock them too.

Keep pushing! :weight_lift:


More to say, we can also patch SMM driver that is responsible to CAP validation, so it will validate anything. That way the locks can be left untoched. It will be harder to do things that way, so it is plan B.

  • Like 1
Link to comment
Share on other sites
k3nny
k3nny
Posted
Posted (edited)

...after upgrading again to the unlocked version of 2204

the same lock error appears. Also I found another place where the locks are set...

I only changed the first occurrence in section Main and it is enough here. You could look what exactly changes in these modules after saving with AMIBCP and how the BIOS_CNTL byte looks like in RWEverything after applying the different BIOSes.

 

More to say, we can also patch SMM driver that is responsible to CAP validation, so it will validate anything. That way the locks can be left untoched. It will be harder to do things that way, so it is plan B.

I really would like to see that happen sometime! :P

 

Edit:

The place to look is probably B1DA0ADF-4F77-4070-A88E-BFFE1C60529A, which should contain the procedure to load the default values (StdDefaults).

Edited by k3nny
Link to comment
Share on other sites
CodeRush
CodeRush
Posted
  • Author
Posted

I think it will be better to find the code, that sets locking bits in to BIOS_CNTL it the first place. It depends on AMITSE/CEF5B9A3 settigns, but there are no such settings on Z87, so it's only a partial solution.

PM locking code is easier to find, because 'mov ecx, 0xe2' is not a common instruction, but I hope we can find that code too.

Link to comment
Share on other sites
CodeRush
CodeRush
Posted
  • Author
Posted

The probable way to find it is looking fo code accesing to PCI device with DF D31:F0 or DID (can be found in datasheet) (LPC I/F), where our beloved BIOS_CNTL is located.

There will be much code found, but it is a point to start anyway.

post-1111314-0-47908700-1378202151_thumb.pngpost-1111314-0-60549000-1378202156_thumb.png

  • Like 1
Link to comment
Share on other sites
StoneTemplePilots
StoneTemplePilots
Posted
Posted

The probable way to find it is looking fo code accesing to PCI device with DF D31:F0 or DID (can be found in datasheet) (LPC I/F), where our beloved BIOS_CNTL is located.

There will be much code found, but it is a point to start anyway.

attachicon.gif1.pngattachicon.gif2.png

 

B00 D1F F00: Intel® Z77 Express Chipset LPC Controller - 1E44 [8086-1E44] [NoDB]

 

  Offset 000:  86 80 44 1E  07 00 10 02  04 00 01 06  00 00 80 00

  Offset 010:  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00

  Offset 020:  00 00 00 00  00 00 00 00  00 00 00 00  43 10 CA 84

  Offset 030:  00 00 00 00  E0 00 00 00  00 00 00 00  00 00 00 00

  Offset 040:  01 04 00 00  80 00 00 00  01 05 00 00  10 00 00 00

  Offset 050:  F8 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00

  Offset 060:  8B 8A 8A 83  90 00 00 00  80 85 8B 86  F8 F0 00 00

  Offset 070:  78 F0 78 F0  78 F0 78 F0  78 F0 78 F0  78 F0 78 F0

  Offset 080:  10 00 0F 3C  91 02 0C 00  00 00 00 00  00 00 00 00

  Offset 090:  00 00 00 00  00 0C 00 00  00 00 00 00  00 00 00 00

  Offset 0A0:  18 0E A0 00  09 18 06 00  00 47 00 00  00 00 00 00

  Offset 0B0:  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00

  Offset 0C0:  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00

  Offset 0D0:  33 22 11 00  67 45 00 00  CF FF 00 00  2A 00 00 00

  Offset 0E0:  09 00 0C 10  00 00 00 00  B3 02 64 04  00 00 00 00

  Offset 0F0:  01 C0 D1 FE  00 00 00 00  87 0F 04 08  00 00 00 00

Link to comment
Share on other sites
CodeRush
CodeRush
Posted
  • Author
Posted

k3nny, you are possibly right.

 

Modules of ASUS P8Z77-V-LE-PLUS BIOS 0905 with "mov eax,1e44h"

Setup / 899407D7-99FE-43D8-9A21-79EC328CAC21

PchSpiSmm / 27F4917B-A707-4AAD-9676-26DF168CBF0D

SmmControl / A0BAD9F7-AB78-491B-B583-C52B7F84B9E0

SBDXE / B7D19491-E55A-470D-8508-85A5DFA41974

PchReset / BB1FBD4F-2E30-4793-9BED-74F672BC8FFE

ActiveBios / BFD59D42-FE0F-4251-B772-4B098A1AEC85

PchSpiRuntime / C194C6EA-B68C-4981-B64B-9BD271474B20

SaInitDxe / DE23ACEE-CF55-4FB6-AA77-984AB53DE811

AcpiPlatformSmi / DFD8D5CC-5AED-4820-A2B6-5C55E4E640EF

SaInitPeim / FD236AE7-0791-48C4-B29E-29BDEEE1A811

PchDeviceGpio / FC1B7640-3466-4C06-B1CC-1C935394B5C2

 

The most interesting one is PchSpiSmm, I think. Digging into it now.

Link to comment
Share on other sites
buoo
buoo
Posted
Posted

Guys, did you discover how the Asus protection works?

What does it control? The size, the hash?

 

If you open an official bios with PhoenixTools and rebuild it without changes will it pass the check?

Link to comment
Share on other sites
StoneTemplePilots
StoneTemplePilots
Posted
Posted

I think it will be better to find the code, that sets locking bits in to BIOS_CNTL it the first place. It depends on AMITSE/CEF5B9A3 settigns, but there are no such settings on Z87, so it's only a partial solution.

PM locking code is easier to find, because 'mov ecx, 0xe2' is not a common instruction, but I hope we can find that code too.

CodeRush, which decompiler do you use, is there something free for decompiling efi modules you'd recommend on Linux or Windows?

 

IDA Pro Demo does not decompile anything ;) and I just don't have >$1000 for this excellent piece of software.

Link to comment
Share on other sites
CodeRush
CodeRush
Posted
  • Author
Posted

Yes, there are some.

On linux it's objdump from binutils, on windows - dumpbin from VS 2010 Express or Windows SDK package. Don't forget to cut section header from files in PT's DUMP directory.

For searching in many binary files i'm using Swiss File Knife utility with "hexfind -binary /pattern/" option. I also use online assemblers and disassemblers for asm/dasm a single command.

  • Like 2
Link to comment
Share on other sites
MiniHack
MiniHack
Posted
Posted

Hi CodeRush,

Cheers for your help in the past. I am attaching my bios from my Zotac H87 ITX board and would welcome your comments on whether it needs to /can be patched. 

This board is working for me on 10.8.4 (with patched mach_kernel) but I get an instant reboot trying with 10.8.5 or 10.9 I realise it is a long shot that bios patching is an answer to that problem, but either way would welcome your input.

Many thanks.


APologies, upload is not working for me tonight. Bios is in this location though: http://www.zotac.com/products/mainboards/intel-cpu/zotac-h87/product/zotac-h87/detail/h87-itx-wifi-a-series/sort/product_name/order/DESC/amount/10/section/downloads.html

Link to comment
Share on other sites
StoneTemplePilots
StoneTemplePilots
Posted
Posted

Hi CodeRush,

Cheers for your help in the past. I am attaching my bios from my Zotac H87 ITX board and would welcome your comments on whether it needs to /can be patched. 

This board is working for me on 10.8.4 (with patched mach_kernel) but I get an instant reboot trying with 10.8.5 or 10.9 I realise it is a long shot that bios patching is an answer to that problem, but either way would welcome your input.

Many thanks.

APologies, upload is not working for me tonight. Bios is in this location though: http://www.zotac.com/products/mainboards/intel-cpu/zotac-h87/product/zotac-h87/detail/h87-itx-wifi-a-series/sort/product_name/order/DESC/amount/10/section/downloads.html

 

Hi Minihack,

 

looks like it can be patched:

 

$BIOSWORX\pa287>pmpatch A2870719.bin A2870719-pmpatched.bin

PMPatch 0.5.13

PowerManagement modules not found.

PowerMgmtDxe/PowerManagement2.efi modules not found.

Trying to apply patch #1

Nested PowerMgmtDxe/PowerManagement2.efi module at 001BB05C patched.

Patched module too big after compression.

Trying to apply patch #2

Nested PowerMgmtDxe/PowerManagement2.efi module at 001BB05C patched.

Patched module too big after compression.

Trying to apply patch #3

Nested PowerMgmtDxe/PowerManagement2.efi module at 001BB05C patched.

Patched module too big after compression.

Trying to apply patch #4

Nested PowerMgmtDxe/PowerManagement2.efi module at 001BB05C patched.

Patched module too big after compression.

Trying to apply patch #5

Nested PowerMgmtDxe/PowerManagement2.efi module at 001BB05C patched.

AMI nest module at 00450048 patched.

Phoenix nest modules not found.

CpuPei module at 007A3A80 not patched: Patch pattern not found.

Output file generated.

 

http://rghost.net/48557584

 

@CodeRush, found something interesting maybe:

 

2rhur9u.jpg

2hx9kxh.jpg

Link to comment
Share on other sites
badaxe2
badaxe2
Posted
Posted 
C:\Users\Mathew\Desktop\New folder>pmpatch afuwin.bios patched.bios
PMPatch 0.5.13
PowerManagement modules not found.
PowerMgmtDxe/PowerManagement2.efi modules not found.
Trying to apply patch #1
Nested PowerManagement module at 003AC614 patched.
Patched module too big after compression.
Trying to apply patch #2
Nested PowerManagement module at 003AC614 patched.
Patched module too big after compression.
Trying to apply patch #3
Nested PowerManagement module at 003AC614 patched.
Patched module too big after compression.
Trying to apply patch #4
Nested PowerManagement module at 003AC614 patched.
Patched module too big after compression.
Trying to apply patch #5
Nested PowerManagement module at 003AC614 patched.
Patched module too big after compression.
AMI nest module at 00050048 not patched: Repacked module can't be inserted.
Phoenix nest modules not found.
CpuPei module at 0029EB50 not patched: Patch pattern not found.

C:\Users\Mathew\Desktop\New folder>pmpatch afuwin.rom patched.rom
PMPatch 0.5.13
PowerManagement modules not found.
PowerMgmtDxe/PowerManagement2.efi modules not found.
Trying to apply patch #1
Nested PowerManagement module at 003AC614 patched.
Patched module too big after compression.
Trying to apply patch #2
Nested PowerManagement module at 003AC614 patched.
Patched module too big after compression.
Trying to apply patch #3
Nested PowerManagement module at 003AC614 patched.
Patched module too big after compression.
Trying to apply patch #4
Nested PowerManagement module at 003AC614 patched.
Patched module too big after compression.
Trying to apply patch #5
Nested PowerManagement module at 003AC614 patched.
Patched module too big after compression.
AMI nest module at 00050048 not patched: Repacked module can't be inserted.
Phoenix nest modules not found.
CpuPei module at 0029EB50 not patched: Patch pattern not found.

Hey guys, doesnt seem to work on my ami aptio bios... Any idea whats up ?

 

I have attached my bios backed up with afudos in dos..

 

Also tried renaming from .rom to .bios as per instructions...

 

I get a error also under Os X

Mats-Mac:untitled folder mat$ /Users/mat/Desktop/untitled\ folder/PMPatch afuwin.rom patched.rom
PMPatch 0.5.13
PowerManagement modules not found.
PowerMgmtDxe/PowerManagement2.efi modules not found.
Trying to apply patch #1
Nested PowerManagement module at 003AC614 patched.
Segmentation fault: 11
Mats-Mac:untitled folder mat$

afuwin.zip

Link to comment
Share on other sites
StoneTemplePilots
StoneTemplePilots
Posted
Posted
...................

I get a error also under Os X

Mats-Mac:untitled folder mat$ /Users/mat/Desktop/untitled\ folder/PMPatch afuwin.rom patched.rom
PMPatch 0.5.13
PowerManagement modules not found.
PowerMgmtDxe/PowerManagement2.efi modules not found.
Trying to apply patch #1
Nested PowerManagement module at 003AC614 patched.
Segmentation fault: 11
Mats-Mac:untitled folder mat$

Yep, the tools fails due to the ffs checksum mismatch, needs to be regenerated by hand,

I did that for you : ) the manual PM unlock way with mmtools ... I found mmtool failed to reintegrate the module due to broken checksum.

 

After patching

 

75080fbae80f89442430 to eb080fbae80f89442430

 

with HxD I cut the ffs header to MZ so I had a native .efi driver

and then I regenerated the ffs driver module with matching ffs checksum that way:

GenSec -s EFI_SECTION_PE32 -o Powermanagement.pe32 Powermanagement.efi
GenFfs -t EFI_FV_FILETYPE_DRIVER -g 8C783970-F02A-4A4D-AF09-8797A51EEC8D -o Powermanagement.ffs -i Powermanagement.pe32

Now I was able to re-integrate the patched Powermanagement.ffs :thumbsup_anim:

 

Patched ROM Download »» http://rghost.net/48590491««

 

Using pmpatch on Windows I saw a little bit more: AMI nest module at 00050048 not patched: Repacked module can't be inserted.

Link to comment
Share on other sites
badaxe2
badaxe2
Posted
Posted

Yep, the tools fails due to the ffs checksum mismatch, needs to be regenerated by hand,

I did that for you : ) the manual PM unlock way with mmtools ... I found mmtool failed to reintegrate the module due to broken checksum.

 

After patching

 

75080fbae80f89442430 to eb080fbae80f89442430

 

with HxD I cut the ffs header to MZ so I had a native .efi driver

and then I regenerated the ffs driver module with matching ffs checksum that way:

GenSec -s EFI_SECTION_PE32 -o Powermanagement.pe32 Powermanagement.efi
GenFfs -t EFI_FV_FILETYPE_DRIVER -g 8C783970-F02A-4A4D-AF09-8797A51EEC8D -o Powermanagement.ffs -i Powermanagement.pe32

Now I was able to re-integrate the patched Powermanagement.ffs :thumbsup_anim:

 

Patched ROM Download »» http://rghost.net/48590491««

 

Using pmpatch on Windows I saw a little bit more: AMI nest module at 00050048 not patched: Repacked module can't be inserted.

That is all chinese to me !! Is this file ok to flash now ? Did you change anything else ?

Link to comment
Share on other sites
CodeRush
CodeRush
Posted
  • Author
Posted

BonBon6, this problem has notnig to do with checksums, but with LZMA compression parameters. Andy has implemented a nice routine, that tries to fit a recompressed module by tweaking LZMA algorithm parameters, so PhoenixTool can fit a modified module (almost) always. I have no time for PMPatch about 3 months in a row, so I didn't implement such routine, that is why there are some BIOSes with that problem.

As for segfault in OS X - I have no idea what is going on with CLang Release configuration on my code. Debug works OK, so next version will be compiled as debug. I don't have OS X installed, so I can't replace it for now.

Thank you for patching that BIOS with PT, BTW. Less work for me. :)

 

badaxe2, try using Intel FPT to flash it. What is your motherboard name?

Link to comment
Share on other sites
CodeRush
CodeRush
Posted
  • Author
Posted

kenny, I have found the code that actially sets a locking bits, but there are no place to mod it, and it uses NVRAM to store default values anyway.

Thank you very much. :beer:

BIOS and SPI lock setup butes are definitely in NVRAM, storage "StdDefaults", variable name "Setup", offset 0xB0 (SMI) and 0xB1 (BIOS) from the beginning of storage.

That offsets are constant, because there is simply a storage of SB_SETUP_DATA structure.

If someone with ASUS Z87 board with UBF support willing to test the unlock - post here, I will make it.

  • Like 2
Link to comment
Share on other sites
k3nny
k3nny
Posted
Posted

kenny, I have found the code that actially sets a locking bits, but there are no place to mod it, and it uses NVRAM to store default values anyway.

Thank you very much. :beer:

BIOS and SPI lock setup butes are definitely in NVRAM, storage "StdDefaults", variable name "Setup", offset 0xB00 (SMI) and 0xB01 (BIOS) from the beginning of storage.

That offsets are constant, because there is simply a storage of SB_SETUP_DATA structure.

If someone with ASUS Z87 board with UBF support willing to test the unlock - post here, I will make it.

Very nice. Can you please point me to the place where the locking bits are set? I just would like to know where it is.

What about the changes in module "AMITSE", besides NVRAM? Did you take them into account or do you know what they represent?

 

So after all, the write protection was there all the time - it just wasn't enabled.

  • Like 1
Link to comment
Share on other sites
StoneTemplePilots
StoneTemplePilots
Posted
Posted

kenny, I have found the code that actially sets a locking bits, but there are no place to mod it, and it uses NVRAM to store default values anyway.

Thank you very much. :beer:

BIOS and SPI lock setup butes are definitely in NVRAM, storage "StdDefaults", variable name "Setup", offset 0xB0 (SMI) and 0xB1 (BIOS) from the beginning of storage.

That offsets are constant, because there is simply a storage of SB_SETUP_DATA structure.

If someone with ASUS Z87 board with UBF support willing to test the unlock - post here, I will make it.

 

Bon jour CodeRush,

 

do you think you can implement the unlock in your next pmpatch release?

 

Btw, as you know I own a Z77 board from ASUS, and I'm young willing and able to test it (SPI flasher).

Uploaded my ROM << here.

 

Friday my TUMPA arrived :D from canada.

 

Au jaaa!

 

best regards

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...