70 replies to this topic

[dgsga]

First of all I'd like to say credit where credit's due. This has been a joint work, the crucial link being provided by Revogirl. Read and learn how it's done so you can unlock your own bios, google to find the tools you need. Remember that this tutorial is using my bios as an example. The byte strings in yours may be different.

This is a risky procedure, do not attempt unless you are confident with modifying and flashing your bios. A mistake could easily brick your board

Use Phoenixtool in a Windows VM to dump all the EFI modules in your bios (a folder called DUMP will appear on the desktop when Phoenix tool runs). Then look at your bios in Aptio MMtool to get the GUID of the powermanagement EFI module. Now look through your DUMP directory until you find the ROM module with the same GUID. In my bios it's called 8C783970-F02A-4A4D-AF09-8797A51EEC8D_1_393.ROM. There will be two files with the same GUID, choose the larger one. This is your powermanagement module that needs to be fixed. Disassemble it using objdump on either Linux or Windoze (using MinGW shell). Google MinGW for more info:

objdump -m i386 -b binary -D 8C783970-F02A-4A4D-AF09-8797A51EEC8D_1_393.ROM > pm.asm


Open up pm.asm with a text editor. Remember we are looking to allow writes to MSR register 0xE2. Bit 15 is the lock bit, 15 in hex is 0xf. So we look for an instance of 0xE2 followed shortly by a bts (bit test and set) of 0xf. Sure enough, in my bios it appears here:


30e4: b9 e2 00 00 00 mov $0xe2,%ecx
30e9: e8 06 11 00 00 call 0x41f4
30ee: 48 dec %eax
30ef: 89 44 24 30 mov %eax,0x30(%esp)
30f3: 0f ba f0 0f btr $0xf,%eax
30f7: 89 44 24 30 mov %eax,0x30(%esp)
30fb: 80 fb 01 cmp $0x1,%bl
30fe: 75 08 jne 0x3108
3100: 0f ba e8 0f bts $0xf,%eax
3104: 89 44 24 30 mov %eax,0x30(%esp)
3108: 48 dec %eax
3109: 8b 54 24 30 mov 0x30(%esp),%edx
310d: b9 e2 00 00 00 mov $0xe2,%ecx
3112: e8 e9 10 00 00 call 0x4200
3117: 33 c0 xor %eax,%eax
3119: 48 dec %eax
311a: 83 c4 20 add $0x20,%esp
311d: 5b pop %ebx
311e: c3 ret


We need to change the jump highlighted above in blue:

30fe: 75 08 jne 0x3108

into:

30fe: eb 08 jmp 0x3108

To make it jump unconditionally as we don't want to set the lock bit. So open up the rom module in your favourite hex editor and search for the byte string:

75080fbae80f89442430

and replace it with:

eb080fbae80f89442430

then save. Now re-run Phoenixtool on your bios, when it has finished unpacking then go into Advanced options and tick the box that says 'Allow user to modify other modules'. Also tick 'No SLIC', then press Done. Now copy over your modified ROM file into the DUMP directory and agree to overwrite the original. Now press Go in Phoenixtool. Phoenixtool will insert the modified rom into your bios, fixing any checksums as it goes along. Flash the fixed bios and native speedstepping is all yours

Please no PM's about fixing your bios. If you learn how to do it yourself then you can always fix any updated bios in the future. That is, until this:

http://www.projectos...t=0

[buoo]

Nice job Dave!

[Shikumo]

Thanks alot, I successfully patched a Thinkpad W520, where actually the same byte sequence is used. (specifics here). So maybe the title should be more general.
Also the "MMAptio tool" got me stumped, but i finally figured it to be the "aptio mmtool"

[davidm71]

Use Phoenixtool in a Windows VM to dump all the EFI modules in your bios (a folder called DUMP will appear on the desktop when Phoenix tool runs). Then look at your bios in MMAptio tool to get the GUID of the powermanagement EFI module. Now look through your DUMP directory until you find the ROM module with the same GUID. In my bios it's called 8C783970-F02A-4A4D-AF09-8797A51EEC8D_1_393.ROM. There will be two files with the same GUID, choose the larger one. This is your powermanagement module that needs to be fixed. Disassemble it using objdump on either Linux or Windoze (using MinGW shell). Google MinGW for more info:

Hi,

Way to go cracking the code! But was just wondering do you have to first flash the original 3XXX bios to your rom and then dump it so that phoenixtools can work? And why in a VM?

Wonder if you could break up the steps a bit..

Thanks!

[davidm71]

Just wanted to say before I go to bed it works as advertised. Had a couple of glitches along the way. Namely I was using version 1.96 of PheonixTools and according to the guide your suppose to copy the new Rom file into the dump file before you click 'Go'. Seems like you have to copy the file when PheonixTools prompts you to do so or else your flashing the plain old 3203 as I was getting KPs until I investigated and found out that the original hex string was still in place. So started over and it works now!

Other than that going into linux and decompiling the rom file is a waste of time. I would just search for '

75080fbae80f89442430' and replace it accordingly in the extracted rom file. At least if you have an Asus Z68 Deluxe.

Anyhow thanks to everyone who worked on this one including dgsga and revogirl, and whoever else involved. Wish I could do more than just beta test but guess its proof it works..

Thanks.

[dgsga]

Decompiling the .ROM file is most definitely not a waste of time. How do you think the fix was discovered in the first place? The same string might be present in all ASUS motherboards but it is not necessarily so for other makes. The purpose of the tutorial is to teach people how to manage their own bios if theirs turns out to be different.

[davidm71]

About decompiling that Rom file I would say it was very educational. I'm sure it helped find that instruction and also helps compare the code to make sure the right conditions exist and follow along your steps. Though I wonder if it would be just easier to search for that long hex code in the extracted powermanement guid matching rom file? I mean what are the odds that you get a false positive in searching for it? I mean don't get me wrong I appreciate your efforts and understand what your saying kind of..

Thanks.

Ps: I would go further and recommend that every one double checks their final rom file and extract that guid rom file to make sure the fix is in there so they don't have to flash their system twice like I did. Better safe than sorry I guess.

[ludacrisvp]

I'm curious about this, I don't have one but if the time comes to replace what I have I have to wonder what benefit this 'unlocking' the EFI bios is getting you?

[davidm71]

I'm curious about this, I don't have one but if the time comes to replace what I have I have to wonder what benefit this 'unlocking' the EFI bios is getting you?

No Kernel Panics and black screen crashes after apple applies an update to each version release..

[Greggen]

Sweeeeet! 3707 modified for P8Z68-V LX got sleep, wake, whatever working OOTB! Before (0707 i think?) I wasn't ever able to get sleep working even with DSDT-edits. Feels like these BIOSes where made for hacks =D

[chenpoo]

Thanks to dgsga , I really learned something from this post ..

There is a saying that in Chinese : "If you are going to give a fish to someone,an rod instead ..."

and for someone who wondering why "eb" instead of "75" :

Intel Pentium Instruction Set Reference

[beta992]

Thanks, don't know if this is working for my MB, but gonna check this out.

Does this means that Chameleon edits could be added/placed to the UEFI-firmware of the MB?
So you will get a (more) vanilla UEFI boot-support for OSX86?

I don't else why you want to unlock EFI?

[rcork]

Just wanted to say before I go to bed it works as advertised. Had a couple of glitches along the way. Namely I was using version 1.96 of PheonixTools and according to the guide your suppose to copy the new Rom file into the dump file before you click 'Go'. Seems like you have to copy the file when PheonixTools prompts you to do so or else your flashing the plain old 3203 as I was getting KPs until I investigated and found out that the original hex string was still in place. So started over and it works now!

Other than that going into linux and decompiling the rom file is a waste of time. I would just search for '

75080fbae80f89442430' and replace it accordingly in the extracted rom file. At least if you have an Asus Z68 Deluxe.

Anyhow thanks to everyone who worked on this one including dgsga and revogirl, and whoever else involved. Wish I could do more than just beta test but guess its proof it works..

Thanks.

I agree with davidm71. After choosing Advanced Options and clicking done, i then had to click Go, wait for the dialog box that said it was ok to modify files in the DUMP directory, then move the patched rom file to the DUMP directory, and click OK on the dialog box.

Also, the Advanced Options button was greyed out until i chose ASUS from the Manufacturer drop down.

Other than that, worked like a charm. Goodbye SpeedStepper. If you already used SpeedStepper to patch AICPM kext, make sure you replace it with an unmodified version. I actually have more P-States now than when i was using modified AICPM.

[DeskIDE]

Will this method work on Z77 mobos or its exclusive to Z68 ?

[davidm71]

Will this method work on Z77 mobos or its exclusive to Z68 ?

According to Revogirl there is a problem with Z77. Read about it here : http://revogirl.word...module-located/

[oSxFr33k]

I had no problem finding mmtool but cannot find Phoenixtool?

[davidm71]

I had no problem finding mmtool but cannot find Phoenixtool?

Its somewhere in the mydigitallife forums. Took me ten to 15 minutes using google to find it.

[rcork]

I had no problem finding mmtool but cannot find Phoenixtool?

http://www.sendspace.com/file/ouhlzy

[oSxFr33k]

Thanks rcork, I am not sure if I know which is PM? Is it the CPUpei? ASUSpei? Assuming it is the CPUpei I have 3 roms that where extracted 2 of them 1k and one 13k This is an Asus G74SX ROG laptop. Is there any other way or program for windows or MAC such as otool to decompile this rom other than Linux or MinGW. There is no straight forward instlaller for it, and does not look so easy to get installed in windows. I do use Linux but have to port over the file no biggie I suppose. I do have some assemblers would they do the trick? IDA PRO for example


EDITED A COUPLE HOURS LATER:

I finally found the installer but getting this error:

$osxfr33k@WIN-L8T7CB4LJK2 /c/extract
objdump -m i386 binary -D 2BB5AFA9-FF33-417B-8497-CB773C2B93BF_1_479.ROM > pm
.asm
$C:\MinGW\bin\objdump.exe: 'binary': No such file

Attached Files

•  2BB5AFA9-FF33-417B-8497-CB773C2B93BF_1_479.rar   7.86KB   21 downloads
•  pm.rar   31.91KB   23 downloads

[King_Khan]

since these newer boards are starting to come with UEFI in the future is it possible to skip the bootloader altogether and let OS X boot? I believe the reason they cannot do it right now is because the firmware does not have a "driver" for the HFS+ file system on OS X bootable volumes