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

This is totally normal, ME has it's own data storage in ME region and it can modify the stored data any second. There is nothing to worry about.

ok, I'll try something now:

 

I'll flash me locked ROM and then I'll flash the ME extracted from unlocked ROM.

 

The I'll report if it worked. No, didn't work. :ph34r:

Link to comment
Share on other sites
StoneTemplePilots
StoneTemplePilots
Posted
Posted

I haven't modified ME region of that file at all. :) The only modification made is described above.

comparing disassembled PchInitDxe modules of all available ROMs for my board I found interesting results for the values you provided above:

 

http://pastebin.com/zeXRNAvB

 

0312 & 0401 ROMs are unlocked for flashing by vendor. 49 8B 43 50 did not even exist in those modules.

Link to comment
Share on other sites
buoo
buoo
Posted
Posted

CodeRush

 

In this way?

0000000180001233: 4C 8B 5C 24 40     mov         r11,qword ptr [rsp+40h] ; Loading PchPlatformData variable address to R11
0000000180001238: 49 8B 43 50        mov         rax,qword ptr [r11+50h] ; Loading PchPlatformData->LockdownConfig to RAX  <--- HERE IS WHAT WE SEARCHED FOR
000000018000123C: 40 84 28           test        byte ptr [rax],bpl      ; Testing if the fisrt bit of LockdownConfig (GlobalSmi) is 0
                                                                         ; BPL register holds 0x01 here, and "test" instruction is actual "and" without storing the result 
000000018000123F: 74 69              je          00000001800012AA        ; Jump 0x69 bytes further if GlobalSmiLock is 0
from

0000000180001233: 4C 8B 5C 24 40     mov         r11,qword ptr [rsp+40h] ; Loading PchPlatformData variable address to R11
0000000180001238: 49 8B 43 50        mov         rax,qword ptr [r11+50h] ; Loading PchPlatformData->LockdownConfig to RAX  <--- HERE IS WHAT WE SEARCHED FOR
000000018000123C: 40 84 28           test        byte ptr [rax],bpl      ; Testing if the fisrt bit of LockdownConfig (GlobalSmi) is 0
                                                                         ; BPL register holds 0x01 here, and "test" instruction is actual "and" without storing the result 
000000018000123F: 74 69              jmp         00000001800012AA        ; Jump 0x69 bytes further if GlobalSmiLock is 0
Link to comment
Share on other sites
StoneTemplePilots
StoneTemplePilots
Posted
Posted

CodeRush

 

In this way?

0000000180001233: 4C 8B 5C 24 40     mov         r11,qword ptr [rsp+40h] ; Loading PchPlatformData variable address to R11
0000000180001238: 49 8B 43 50        mov         rax,qword ptr [r11+50h] ; Loading PchPlatformData->LockdownConfig to RAX  <--- HERE IS WHAT WE SEARCHED FOR
000000018000123C: 40 84 28           test        byte ptr [rax],bpl      ; Testing if the fisrt bit of LockdownConfig (GlobalSmi) is 0
                                                                         ; BPL register holds 0x01 here, and "test" instruction is actual "and" without storing the result 
000000018000123F: 74 69              je          00000001800012AA        ; Jump 0x69 bytes further if GlobalSmiLock is 0
from

0000000180001233: 4C 8B 5C 24 40     mov         r11,qword ptr [rsp+40h] ; Loading PchPlatformData variable address to R11
0000000180001238: 49 8B 43 50        mov         rax,qword ptr [r11+50h] ; Loading PchPlatformData->LockdownConfig to RAX  <--- HERE IS WHAT WE SEARCHED FOR
000000018000123C: 40 84 28           test        byte ptr [rax],bpl      ; Testing if the fisrt bit of LockdownConfig (GlobalSmi) is 0
                                                                         ; BPL register holds 0x01 here, and "test" instruction is actual "and" without storing the result 
000000018000123F: 74 69              jmp         00000001800012AA        ; Jump 0x69 bytes further if GlobalSmiLock is 0

No, in this case 74 = je & 69 = 69byte further but I saw a different jump method on H87 Zotac board which was a conditional jz qword jump, so we have totally different values.

In my case on Z77 board 74(JE) has been replaced with EB(JMP).

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

Instead of patching jumps (which is not easy if it's not a near jump with immediate value, like 74 69 --> EB 69) you can patch test (F6 00 xx / 40 84 xx / 40 84 xx xx xx xx) to be xor rax, rax (48 31 c0), making jz to be jmp anyway. If long version of test is used, add 3 nops (90).

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

Instead of patching jumps (which is not easy if it's not a near jump with immediate value, like 74 69 --> EB 69) you can patch test (F6 00 xx / 40 84 xx / 40 84 xx xx xx xx) to be xor rax, rax (48 31 c0), making jz to be jmp anyway. If long version of test is used, add 3 nops (90).

can you show us an example? did you mean

000000018000123C: 40 84 90           test        byte ptr [rax],bpl      ; Testing if the fisrt bit of LockdownConfig (GlobalSmi) is 0

instead of 

000000018000123C: 40 84 28           test        byte ptr [rax],bpl ; Testing if the fisrt bit of LockdownConfig (GlobalSmi) is 0

? I did some testing and found disassembling with dumpbin /all we're getting more info, so we can see there's a raw data section at the end of ever module at the same position counted back from the end:

RAW DATA #5
  000000018000A640: 00 90 00 00 10 00 00 00 90 AF A0 AF B0 AF 00 00  .........¯ ¯°¯..
  000000018000A650: 00 A0 00 00 0C 00 00 00 08 A0 18 A0              . ....... . 

SECTION HEADER #5
  .reloc name
      14 virtual size
    B220 virtual address (000000018000B220 to 000000018000B233)
      20 size of raw data
    B220 file pointer to raw data (0000B220 to 0000B23F)
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
42000040 flags
         Initialized Data
         Discardable
         Read Only

different compared data sections of locked and unlocked boards look like that:

00 90 00 00 10 00 00 00 90 AF A0 AF B0 AF 00 00 00 A0 00 00 << unlocked P8Z77-V LX 0312
00 90 00 00 10 00 00 00 90 AF A0 AF B0 AF 00 00 00 A0 00 00 << unlocked P8Z77-V LX 0401
00 90 00 00 14 00 00 00 70 AF 80 AF 90 AF E8 AF F8 AF 00 00 
00 B0 00 00 14 00 00 00 B0 A3 C0 A3 D0 A3 28 A4 38 A4 00 00
00 A0 00 00 14 00 00 00 90 A5 A0 A5 B0 A5 08 A6 18 A6 00 00
00 A0 00 00 14 00 00 00 F0 A5 00 A6 10 A6 68 A6 78 A6 00 00
00 A0 00 00 14 00 00 00 F0 A5 00 A6 10 A6 68 A6 78 A6 00 00
00 A0 00 00 14 00 00 00 B0 A7 C0 A7 D0 A7 28 A8 38 A8 00 00
00 A0 00 00 14 00 00 00 B0 A7 C0 A7 D0 A7 28 A8 38 A8 00 00
00 A0 00 00 14 00 00 00 B0 A7 C0 A7 D0 A7 28 A8 38 A8 00 00
00 A0 00 00 14 00 00 00 70 AB 80 AB 90 AB E8 AB F8 AB 00 00
00 A0 00 00 14 00 00 00 70 AB 80 AB 90 AB E8 AB F8 AB 00 00
00 00 01 00 14 00 00 00 30 A4 40 A4 50 A4 B8 A4 4D A9 00 00
00 B0 00 00 14 00 00 00 B0 A3 C0 A3 D0 A3 28 A4 38 A4 00 00
00 F0 00 00 10 00 00 00 70 AD 80 AD 90 AD 10 AE 00 00 01 00
00 00 01 00 14 00 00 00 70 A0 80 A0 90 A0 08 A1 9D A5 00 00
00 A0 00 00 14 00 00 00 10 AB 20 AB 30 AB 88 AB 98 AB 00 00 << locked P8Z77-V LX 2204
00 B0 00 00 14 00 00 00 B0 A3 C0 A3 D0 A3 28 A4 38 A4 00 00
00 A0 00 00 14 00 00 00 50 AB 60 AB 70 AB C8 AB D8 AB 00 00
00 A0 00 00 14 00 00 00 30 AD 40 AD 50 AD A8 AD B8 AD 00 00

maybe it helps if here are the variables for test are stored ;) but anyway I guess this data looks very structured and interesting.

Jump back 3Bh from the end and you'll find this section in every module.

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

Sure. PchInitDxe from Maximus IV Hero 0711 BIOS.

SmiLock:

49 8b 43 50        mov rax,QWORD PTR [r11+0x50]
44 84 28           test BYTE PTR [rax],r13b
0f 84 86 00 00 00  je 0x00000093
44 84 28 --> 48 31 c0, that makes

49 8b 43 50        mov rax,QWORD PTR [r11+0x50]
48 31 c0           xor rax, rax ; RAX is now 64-bit zero, ZF (zero flag) bit is now set
0f 84 86 00 00 00  je 0x00000093 ; jumping if ZF is set, which is now always set
BiosLock:

48 8b 41 50        mov rax,QWORD PTR [rcx+0x50]
f6 00 10           test BYTE PTR [rax],0x10
74 2e              je 0x00000037
f6 00 10 -> 48 31 c0, like above, or just 74 2e --> eb 2e
Link to comment
Share on other sites
CodeRush
CodeRush
Posted
  • Author
Posted

BTW, my new netbook is here. It's Dell Vostro 3360, so after replacing WiFi to Atheros it would be easy to install OS X there, I hope. Will try if I have much free time. :)

BonBon6, thanks, will look at this data deeper.

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

BTW, my new netbook is here. It's Dell Vostro 3360, so after replacing WiFi to Atheros it would be easy to install OS X there, I hope. Will try if I have much free time. :)

BonBon6, thanks, will look at this data deeper.

Inside the ROM is a PchBiosWriteProtect.efi additional to the PchInitDxe.efi ;-) I've already extracted it.

But same routines with your vostro 3360:

 

Vostro 3360 PchInitDxe.efi:

  000000000000133D: 49 8B 43 50        mov         rax,qword ptr [r11+50h]
  0000000000001341: 40 84 28           test        byte ptr [rax],bpl
  0000000000001344: 74 65              je          00000000000013AB

  00000000000013AB: 49 8B 43 50        mov         rax,qword ptr [r11+50h]
  00000000000013AF: 40 84 30           test        byte ptr [rax],sil
  00000000000013B2: 74 5D              je          0000000000001411

  0000000000001471: 49 8B 43 50        mov         rax,qword ptr [r11+50h]
  0000000000001475: F6 00 04           test        byte ptr [rax],4
  0000000000001478: 74 23              je          000000000000149D

Vostro 3360 PchBiosWriteProtect.efi:

  0000000000000780: 49 8B 43 50        mov         rax,qword ptr [r11+50h]
  0000000000000784: 4C 8D 44 24 20     lea         r8,[rsp+20h]
  0000000000000789: 48 8D 15 EC FE FF  lea         rdx,[0000067Ch]
                    FF
  0000000000000790: 0F B6 48 01        movzx       ecx,byte ptr [rax+1]

what if setting

0000000000000790: 0F B6 48 00        movzx       ecx,byte ptr [rax+0]

in this case? similiar for PchInitDxe.efi on Z77 boards we have

  0000000180000B9C: 0F B6 48 01        movzx       ecx,byte ptr [rax+1]
  0000000180000E1A: 0F B6 48 01        movzx       ecx,byte ptr [rax+1]

setting

  0000000180000B9C: 0F B6 48 00        movzx       ecx,byte ptr [rax+0]
  0000000180000E1A: 0F B6 48 00        movzx       ecx,byte ptr [rax+0]

same effect? Such a patch can be implemented easily in your PMpatch utility :thumbsup_anim:

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

buoo, assembly code is just for your reference.

Open your PchInitDxe.bin file with hex editor, search for "49 8B 43 50", check that there are "F6 00 xx" or "40 84 xx" after it - there is your place to start. Modyfy test or je with hex editor, save the file and reintegrate it (checkum must be also fixed).

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

BonBon6, it's not that easy. The code in PchInitDxe aquires all instances of PchPlatformData and sets lock in foreach loop. If only one module sets a lock to SMI or BIOS - we are screwed, so patching the code that actually sets the locks is easier for me. As for automated solutions - it will be easier to patch "test" instruction, because it don't requires recalculation of jump target offset, which is needed for patch long jumps. Will probably try to implement such a routine on this weekend.

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

BonBon6, it's not that easy. The code in PchInitDxe aquires all instances of PchPlatformData and sets lock in foreach loop. If only one module sets a lock to SMI or BIOS - we are screwed, so patching the code that actually sets the locks is easier for me. As for automated solutions - it will be easier to patch "test" instruction, because it don't requires recalculation of jump target offset, which is needed for patch long jumps. Will probably try to implement such a routine on this weekend.

 

CodeRush, have you already been fiddling with Ozmosis? Maybe interesting for your new Vostro ;)

Link to comment
Share on other sites
buoo
buoo
Posted
Posted

buoo, assembly code is just for your reference.

Open your PchInitDxe.bin file with hex editor, search for "49 8B 43 50", check that there are "F6 00 xx" or "40 84 xx" after it - there is your place to start. Modyfy test or je with hex editor, save the file and reintegrate it (checkum must be also fixed).

 

I understand the procedure, it's really clear.

I don't understand how to modify "test" or "je".

 

 

buoo, show me your bios and I'll show you mine :P just kidding, bios link or which board please ... We'll make it here so you can follow the steps. Okay 4you?

 

I'd like to make a new mini hackintosh with a Asus H87I-Plus but I'm waiting a solution to flash the bios with a patched one.

Also GA-H87N-WIFI is good, but I'm not sure if it need a patched bios to get the speedstep working. 

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

buoo, you can replace some bytes in the file you open with hex editor, that's why it's called editor. :)

To replace JE with JMP is to replace "74" with "EB" in the right place, and so on.


BonBon6, nope, thanks for the link. I have no plans to modify BIOS on that machine, because of warranty, but I will try some other methods to achieve the goals needed.  

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

TimeWalker, I have indeed done some research and there is a new version on SCT here, you are right. But now I'm OK with that. I have desktop PC to play with BIOSes, and this machine is my portable workplace. There are no restrictions that bothers me right now, and if some appears I still have SPI programmer to do the job. 

Link to comment
Share on other sites
James Drake
James Drake
Posted
Posted

Hi,

 

First of all, many thanks for this tool.

 

Similar to genzai (back on page 23 http://www.insanelymac.com/forum/topic/285444-pmpatch-uefi-patching-utility/page-23?do=findComment&comment=1928839) I am playing with Pro Tools systems on the Jetway NAF92-Q67 motherboard.

 

I am currently using version 4 of their BIOS, but the latest available is version 7.

 

I tested your utility, downloaded from here: http://www.mediafire.com/?8866wtwhp4wi7

 

Both the 0.5.11 and 0.5.13 versions, running on OS 10.8.4 on my MacBook Pro.

 

I tried to patch both BIOS versions 4 and 7 for my motherboard.

 

Here is the output.

 

So it's interesting to see that Jetway changed something between the different BIOS versions, and your utility crashes only with one of the BIOS files.

 

post-76946-0-57413200-1379028122_thumb.png

 

I haven't tried to flash the BIOS yet :)

Link to comment
Share on other sites
James Drake
James Drake
Posted
Posted

post-76946-0-33789900-1379107581_thumb.png

 

Interesting to note that using version 7 of the BIOS for the Jetway NAF92-Q67, the fresh download from their website, I am unable to flash my motherboard anyway! Version 7 was released to add support for Ivy Bridge CPUs so obviously there is a lot changed.

 

I ran your patch tool (both versions) again on my MacBook Pro running OS 10.8.4 with version 6 of my BIOS, and all seems OK.

 

So there is something strange about this BIOS version 7 file that won't flash on my motherboard and is crashing your patch tool.


And flashing the version 6 bios, patched with your tool, is OK.

Link to comment
Share on other sites
StoneTemplePilots
StoneTemplePilots
Posted
Posted

attachicon.gifScreen Shot 2013-09-13 at 11.21.04 PM.png

 

Interesting to note that using version 7 of the BIOS for the Jetway NAF92-Q67, the fresh download from their website, I am unable to flash my motherboard anyway! Version 7 was released to add support for Ivy Bridge CPUs so obviously there is a lot changed.

 

I ran your patch tool (both versions) again on my MacBook Pro running OS 10.8.4 with version 6 of my BIOS, and all seems OK.

 

So there is something strange about this BIOS version 7 file that won't flash on my motherboard and is crashing your patch tool.

And flashing the version 6 bios, patched with your tool, is OK.

 

Hi,

 

I patched this ROM for you, NAF92-Q67 ver 07 PM unlocked ROM download, extract to a DOS stick and execute flash.bat

should be no problem to flash this ROM ;)

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

Hey I am new to this whole bios patching, i plan on buying a Asus Maximus VI Impact in the coming days.... 

I had noticed a few of the other ROG boards had been patched in the past...

Will it be possible to patch the VI series to work? 

 

Thanks if any more info is needed i will supply it asap

 

Hope to hear back soon!

 

Here is a link to the Motherboard specs 

http://www.asus.com/ca-en/ROG_ROG/MAXIMUS_VI_IMPACT/

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