StoneTemplePilots Posted September 9, 2013 Share Posted September 9, 2013 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. Link to comment Share on other sites More sharing options...
CodeRush Posted September 9, 2013 Author Share Posted September 9, 2013 I haven't modified ME region of that file at all. The only modification made is described above. 1 Link to comment Share on other sites More sharing options...
StoneTemplePilots Posted September 9, 2013 Share Posted September 9, 2013 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 More sharing options...
buoo Posted September 10, 2013 Share Posted September 10, 2013 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 0from 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 More sharing options...
StoneTemplePilots Posted September 10, 2013 Share Posted September 10, 2013 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 0from 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 More sharing options...
CodeRush Posted September 11, 2013 Author Share Posted September 11, 2013 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). 2 Link to comment Share on other sites More sharing options...
StoneTemplePilots Posted September 11, 2013 Share Posted September 11, 2013 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. 1 Link to comment Share on other sites More sharing options...
CodeRush Posted September 11, 2013 Author Share Posted September 11, 2013 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 0x00000037f6 00 10 -> 48 31 c0, like above, or just 74 2e --> eb 2e Link to comment Share on other sites More sharing options...
CodeRush Posted September 11, 2013 Author Share Posted September 11, 2013 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. 1 Link to comment Share on other sites More sharing options...
StoneTemplePilots Posted September 11, 2013 Share Posted September 11, 2013 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 Link to comment Share on other sites More sharing options...
buoo Posted September 11, 2013 Share Posted September 11, 2013 I don't understand how to replace the instances Link to comment Share on other sites More sharing options...
CodeRush Posted September 11, 2013 Author Share Posted September 11, 2013 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 More sharing options...
StoneTemplePilots Posted September 11, 2013 Share Posted September 11, 2013 I don't understand how to replace the instances buoo, show me your bios and I'll show you mine just kidding, bios link or which board please ... We'll make it here so you can follow the steps. Okay 4you? Link to comment Share on other sites More sharing options...
CodeRush Posted September 11, 2013 Author Share Posted September 11, 2013 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. 1 Link to comment Share on other sites More sharing options...
StoneTemplePilots Posted September 11, 2013 Share Posted September 11, 2013 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 More sharing options...
buoo Posted September 11, 2013 Share Posted September 11, 2013 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 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 More sharing options...
CodeRush Posted September 11, 2013 Author Share Posted September 11, 2013 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. 1 Link to comment Share on other sites More sharing options...
TimeWalker75a Posted September 11, 2013 Share Posted September 11, 2013 I just hope you did your research before buying that vostro in high hopes it's not a Phoenix Tiano based machine. Link to comment Share on other sites More sharing options...
buoo Posted September 11, 2013 Share Posted September 11, 2013 Roger! Link to comment Share on other sites More sharing options...
CodeRush Posted September 11, 2013 Author Share Posted September 11, 2013 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 More sharing options...
James Drake Posted September 12, 2013 Share Posted September 12, 2013 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. I haven't tried to flash the BIOS yet Link to comment Share on other sites More sharing options...
James Drake Posted September 12, 2013 Share Posted September 12, 2013 Just want to say that flashing my BIOS with your patched file worked. But not tried booting anything yet...... 1 Link to comment Share on other sites More sharing options...
James Drake Posted September 13, 2013 Share Posted September 13, 2013 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 More sharing options...
StoneTemplePilots Posted September 14, 2013 Share Posted September 14, 2013 Screen 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 1 Link to comment Share on other sites More sharing options...
cdnGHOST Posted September 15, 2013 Share Posted September 15, 2013 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 More sharing options...
Recommended Posts