Jump to content

[UEFIPatch] UEFI patching utility

CodeRush

By CodeRush,
in UEFI

 Share
1,981 posts in this topic

Recommended Posts

naujoks
naujoks
Posted
Posted

Thanks for that, @CodeRush!

Before I flash (and sorry to be so paranoid, but we all know how much can go wrong): I note that the biosbck.bin memory dump of my current BIOS is 2560kb long, when the 3306 BIOS I can download from the ASUS website (.rom extension) is 4096kb long. Does that matter?

I also read about the locked BIOS that some people have and had to work around. How do I know if that is a problem for me or not (Asus Sabertooth P67)?

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

@naujoks, sizes are different because a full 4 Mb image has all regions (Descriptor + GbE + ME + BIOS) and your backup has only BIOS. P67 has BIOS Lock indeed, but it's disabled by default, so here is nothing to worry about.

Link to comment
Share on other sites
dgsga
dgsga
Posted
Posted

Hi All, has anyone had success with unlocking NVRAM on Asus z97 bioses? PchInitDxe has changed yet again, can't find any of the patchable patterns, the SCEWIN technique appears to work (nvram dump says bios and spi are unlocked) but I still get error 26 when I try to dump the bios with FPT. Any help would be appreciated

Cheers!

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

@dgsga, you need to patch SbSmi.ffs to prevent SMM_BWP bit (5) of BIOS_CNTL (PCI Dev 00:1F:00 offset DC) from being set. Test the modified BIOS and if FPT works, remove NvramSmi,ffs to have (possibly) working NVRAM. 

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

@CodeRush

Thanks very much for the suggestion. I did find the snippet of code in SbSmi that TimeWalker mentioned in an earlier post (my call addresses are slightly different from the example below)

00000001800008fe E8410C0000                      call       0x180001544 
0000000180000903 41B9DC000000                    mov        r9d, 0xdc
0000000180000909 4533C0                          xor        r8d, r8d
000000018000090c 24FE                            and        al, 0xfe 
000000018000090e B21F                            mov        dl, 0x1f
0000000180000910 33C9                            xor        ecx, ecx
0000000180000912 88442420                        mov        byte [ss:rsp+0x20], al
0000000180000916 E8CD0D0000                      call       0x1800016e8

I changed 0xFE to 0xFF then reinserted and reflashed. OS boots up fine but unexpected effect of change is that some SATA slots in bios marked as empty even tough there are drives attached. Have I located the right code segment, and do I need to change the 0x20 to 0x00 as well to unlock SMI? I can attach the SbSmi.asm file if it will help. Thanks!

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

@dgsga, you need to change 0x20 to 0x00 to disable SMM_BWP, then use AMIBCP/AMISDL to disable BIOS Lock (which disables BLE), and then remove NvramSmi.ffs. 70% chance that NVRAM will work that way. If not - EmuVariable it the only solution right now.


@CrazyCreator, please wait for 1-2 days, my work PC is down right now, so I can't mod anything.

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

@CrazyCreator, please wait for 1-2 days, my work PC is down right now, so I can't mod anything.

 

OK ... I waiting for your answer. 

 

 

I have write a message to the gigabyte support. Here times the correspondence

I wrote:

"I can't write in the NVRAM with your new BIOS Version (F3)! Can you make a solution for me?"

Gigabyte answer:

"What OS you use and what App need the possibility"

I wrote:

"I using Linux and MAC OS X and i need the NVRAM writable for saving keys or bootargs"

Gigabyte wrote today:

"Try this: Z77NWIFI-A1BIOS"

 

I have download the BIOS and with ozmosis infects. But the NVRAM ist not save my Values :-( Now i send Gigabyte a log with the error message from terminal:

Mac-Pro:~ CrazyCreator$ nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:SystemSerial

nvram: Error getting variable - '4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:SystemSerial': (iokit/common) data was not found

 

We will see the answer tomorrow. :-) But i think you are the better Man for this, CodeRush :-) 

Link to comment
Share on other sites
CrazyCreator
CrazyCreator
Posted
Posted

For saving i need the "sudo nvram ..." command. For reading without sudo ... or is this wrong???

 

but i have, by testing the BIOS from gigabyte support,

all necessary values write with sudo ...

then reboot ...

and then "nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:SystemSerial"

and the Message you can read in my posting above

Link to comment
Share on other sites
kennyroody
kennyroody
Posted
Posted

C.Frio,

 

On Z87 board I can recommend the method as explained by Mainul. There will be no capsule issues.

It's easier to apply and it works ; )

The patched ROM from you has 8.196 KB which is 4KB overhead. I'd not mess with it.

 

Better use afudos /gan method instead.

 

You can even do it all from windows as pmpatch is provided as windows executable,

steps:

  1. backup: afuwinx64 bios.bin /o
  2. patch: pmpatch bios.bin bios-pmpatched.bin
  3. apply: afuwinx64 bios-pmpatched.bin /gan

verification after reboot:

  1. backup: afuwinx64 bios.bin /o
  2. test: pmpatch bios.bin bios-pmpatched.bin

will report there's nothing left to patch.

Voila, you have a pmpatched UEFI now.

 

Most important: don't use a different bios version, it potentially causes bricks. Work only with the created backup bios.

 

The AFU for APTIO /GAN switch appears to serve the same purpose as /SANTA on AFU for regular BIOS.

@DirectXtraOrdinary, I spend days researching appropriate ways to fix the my BIOS in an ASUS Q550LF (Q550LF-BSI7T21). Thank you so much for posting your comment, it worked perfectly for me.

 

I originally started with Google search: "Haswell early reboot, Mavericks, locked MSRs". That led me to http://www.insanelymac.com/forum/topic/285444-uefipatch-uefi-patching-utility/ , the first page of this thread. I just want to update your instructions a little bit with current updates. This worked for me and hopefully for everyone on an ASUS Q550LF. I will paraphrase your info with some updates:

 

Q550LF MSR Unlock Patch for Native Power Management

 

Before you begin please click Here and Read Post #1! After you've read that over and over, and understand this could seriously brick your laptop, we can move on.

 

Please download the newest release of UEFIPatch from CodeRush (Thank you so much for all your hard work!). As of writing this, UEFIPatch is version 0.2.1 on win. Last you need AMI BIOS Support Tool - AFUWinx64 found here. It will be listed as AFUWin v4.xx. I created a directory on the root of my Win8x64 drive, "C:\UEFI\". I extracted everything I downloaded there. You will need to navigate to the following "C:\uefi\amiflash\Aptio\afuwin\64\" and extract "afuwin64.zip" to "C:\UEFI".

  1. Start Command Prompt with Administrator Priveledges (How to).
  2. Navigate to C:\UEFI ("cd c:\uefi\")
  3. Backup (will only READ your BIOS and write to a file):      "afuwinx64 bios.bin /o"
  4. Patch (patches the file you just backed up):     "uefipatch bios.bin bios-patched.bin"
  5. Close Everything!: Shut off your virus software and anything unecessary. 
  6. Warning: Last chance... You've read everything you possibly can about this subject and you're sure you want to continue. Good place to cross your fingers.
  7. Apply : "afuwinx64 bios-patched.bin /gan"

Verification after reboot, here you will backup your BIOS again, if its patched it shouldn't do anything. If not you will see "patch applied":

  1. Backup: afuwinx64 bios.bin /o
  2. Test: uefipatch bios.bin bios-pmpatched.bin

Will report there's nothing left to patch.

Voila, you have a uefipatched UEFI now.

 

Most important: Don't use a different bios version, it potentially causes bricks. Work only with the created backup bios. I followed these instructions while at Bios version 214. I know that 215 was realeased on 01AUG14. I have no need to update to that, it only affects Sata0/2Dev Mode.

 

The AFU for APTIO /GAN switch appears to serve the same purpose as /SANTA on AFU for regular BIOS. No idea what the switch does, just do it!

 

That concludes this instruction, now go forth and install Mavericks! Your laptop should work with Native Power Management.

 

Thank you again DirectXtraOrdinary, CodeRush, and all others for your work!

 

~Kennyroody

PS. Please let me know if anyone needs help with anything, I'll help where I can.

Link to comment
Share on other sites
dgsga
dgsga
Posted
Posted

@CodeRush

Thanks for the tip. Unfortunately no joy. I always end up with SATA ports 5 and 6 empty. I have attached the disassembled SbSmi file and have marked the areas which I changed (in various combinations) 0x20 to 0x00 with ***?*** I disassembled the files with dumpbin.

Have I missed anything blindingly obvious?? Any help would be great.

SbSmi.txt.zip

PchInitDxe.txt.zip

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

@dgsga,

00000001800008E7: 24 FE              and         al,0FEh <- this must be changed from "24 FE" to "24 FF"

0000000180000937: 0C 20              or          al,20h <- this must only be changed from "0C 20" to "90 90"

NvramSmi must be removed.

I don't know why SATA ports are f*cked up after modification, normally they aren't. Try to mod only the lines above.

Link to comment
Share on other sites
CrazyCreator
CrazyCreator
Posted
Posted
@CrazyCreator, I have modded your files, try them on your own risk.

attachicon.gifGA-Z77N-WIFI-F3-nvr.zip

attachicon.gif [url=http://www.insanelymac.com/forum/index.php?app=core&module=attach&section=attach&attach_rel_module=post&attach_id=146517]Z77NWIFI-F4a-nvr.zip[/

 

I have try your BIOS but i have KernelPanic.

I insert all Ozmosis files and FakeSMC. The AmiBoardInfo is untouched from me.

 

The Kernel Panic Pic

post-530903-14079565571647_thumb.jpgpost-530903-14079565665099_thumb.jpg

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

@shiecldk, attached.

P7AUD3R3.U1B-nvr.bin.zip

 

@CrazyCreator, I don't have a solution for you now, OZM requires working NVRAM, and I can't provide it. 

As a workaround, you can boot into UEFI shell and use built-in "nvram" command to add values you like.

 

// My opinion to OZM as UEFI developer: storing bootloader in firmware is a bad idea.

// I do know why it's done like this by QUO people, but for normal boards it's fully useless and makes no sence.

  • Like 3
Link to comment
Share on other sites
CrazyCreator
CrazyCreator
Posted
Posted

Ok ... Now understand :-) 

 

I used clover forwards ozmosis. But Ozmosis is better. Because it bootet faster :-D

But with the NVRAM Problem Ozmosis will die in the future. Then I return gladly too Clover.

 

I can use the F2 Bios Version for my Board, with this Version the NVRAM is writable.

Only reason for change to the F3 BIOS Version is the correct recognition of my installed RAM in "About my Mac"

 

I wait for the answer from Gigabyte Support maybe can help ... If yes ... I Upload the BIOS here :-)  

 

But the bad idea works quite well: -) as long as nvram remains recordable

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

@all, let us clear the whole NVRAM story.

 

Facts:

1. To obtain Windows 8 Ready logo, UEFI must be updated to 2.3.1C+ compliant version, which adds support for features like SecureBoot, AuthenticatedVariables, SecureFlash and so on.

2. AuthVars support and BIOS Lock (BLE/BIOSWE or SMM_BWP or both, i.e. writes to SPI flash are possible only for code inside SMRAM, i.e by SMM drivers) are incompatible with "old" NVRAM implementation, but this implementation is still used for DXE drivers that works before OS boot (because flash is not locked yet).

3. To provide SetVariable function for UEFI-booted OS, new NvramSmi driver was introduced, that becomes a GUID and variable data from OS code, copies it into buffer and generates an SMI, the handler of which calls "old" SetVariable function inside SMM. All OSes are compatible with this implementations, except OSX, for some reason.

 

What can we do:

1. Disable BLE/BIOSWE (FE -> FF patch) and SMM_BWP (or 0x20 -> nop nop patch) to make BIOS region writable again, then remove NvramSmi to prevent "old" SetVariable from being replaced by "new" one. It works on some boards, but not for all of them. I think the problem here is a correct physical to virtual address transition, that must be done for RS pointer, but not done. I will try to dig this idea further, if I find some time for that.

2. Use EmuVariable driver to replace all *Variable functions with emulated ones and use another storage (i.e .plist file) to store and loand NVRAM vars. This is done by EmuVariable + scripts.

3. Develop a proxy driver based on EmuVariable, that calls a real SetVariable function. I'm working on such driver right now, please be patient.

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