Jump to content

[UEFIPatch] UEFI patching utility


CodeRush
1,981 posts in this topic

Recommended Posts

stinga11, this is a complete different function there. I think the reason for sleep problems is changes in UEFI structure made by UEFITool, try using PhoenixTool instead. I will debug this issue if I have an affected system to test on.

Thanks for answering. Clover in legacy mode works well. I will use it this way.

Link to comment
Share on other sites

The patch works with ASRock E3C226D2I Motherboard and BIOS P1.80 flawlessly. I tested with Mavericks 10.9.2. Before the patch, just a reboot (even installation can't start). After: installation and booting works!

Link to comment
Share on other sites

I made a bit of research (thanks to Pacman for supplied files) and I think I could found a way to disable NVRAM write protection on new AMI-based BIOSes that have NvramSmi.ffs file. That file registers ReadyToBoot event handler, that replaces normal SetVariable runtime services function with it's own implementation, that checks for vendor ID and some other stuff instead of just writing to NVRAM. If we could bypass that handler setup, it can either lead to working NVRAM write as before, or just disable NVRAM write completely.

I have no affected system to test on, that is why I need someone brave to test this mod of NvramSmi.ffs file:

Pattern to find is "FF504048BE00000000000000804885C67407", two bytes at the end must be replaced with nops, making replace pattern "FF504048BE00000000000000804885C69090".

Please test and report, thank you in advance.

  • Like 5
Link to comment
Share on other sites

I made a bit of research (thanks to Pacman for supplied files) and I think I could found a way to disable NVRAM write protection on new AMI-based BIOSes that have NvramSmi.ffs file. That file registers ReadyToBoot event handler, that replaces normal SetVariable runtime services function with it's own implementation, that checks for vendor ID and some other stuff instead of just writing to NVRAM. If we could bypass that handler setup, it can either lead to working NVRAM write as before, or just disable NVRAM write completely.

I have no affected system to test on, that is why I need someone brave to test this mod of NvramSmi.ffs file:

Pattern to find is "FF504048BE00000000000000804885C67407", two bytes at the end must be replaced with nops, making replace pattern "FF504048BE00000000000000804885C69090".

Please test and report, thank you in advance.

 

 

Hello,

 

I've patch Gigabyte Z77-DS3H rev 1.1 bios F11a.

Mac osx boot up to FakeSmc and restart.

Just like when you remove NvramSmi from bios.

 

Fred

  • Like 1
Link to comment
Share on other sites

Thanks for this guide and the patch for x79 board. I patch a Gigabyte UD3 X79 and it work flawlessly. :thumbsup_anim:

 Hi Stinga11,

 

What Mobo version did you patch? v1 or v1.1

Can you share the patched bios?

 

t2m

Link to comment
Share on other sites

Things are much more complex then I first thought, it seems. Nvram Dxe driver is a part of Platform.ffs module, and SetVariable function of runtime service is moved to NvramSmi, so every call of this function will generate SMI interrupt and then the handler will do all the work. But I can't see why it doesn't working like normal... Will digg into it later on.

Link to comment
Share on other sites

Hello,

 

I've patch Gigabyte Z77-DS3H rev 1.1 bios F11a.

Mac osx boot up to FakeSmc and restart.

Just like when you remove NvramSmi from bios.

 

Fred

As far i know Gigabyte have nvram working without any patching i have one GAH87M-HD3 and i dont have any nvram isue even with last bios version ( F6 in my case) 

Link to comment
Share on other sites

As far i know Gigabyte have nvram working without any patching i have one GAH87M-HD3 and i dont have any nvram isue even with last bios version ( F6 in my case) 

u are using 8 series and 7 series with latest version all have this problem.

  • Like 1
Link to comment
Share on other sites

CodeRush, on Asus P9X79 I have this doubt: with the latest .cap bios from asus site, no modules founded by PMPatch (no output file generated, of course) nor 75080FBAE80F89442430 hex pattern founded from your UEFI tool. In your uefi tool guide (step 4) you wrote that if no 75080FBAE80F89442430 hex pattern was found "you have nonstandard BIOS that needs to be studied further". Is that so? Or simply this bios doesn't need to be unlocked?

Link to comment
Share on other sites

Was this for PM for Gigabyte? 

Yes, The gigabyte x79 boards are locked, with this you unlocked the msr but in my case I lost the ability to awaken on uefi boot with clover. But in legacy mode works perfect.

Link to comment
Share on other sites

I need some assistance. 

 

I successfully PMPatched my Asus U46SV Laptop bios 204 and I'm using vanilla AICPM.

 

Although almost everything is working fine, I realized that my DMI data was reseted. I don't have a MB serial number, and specially, the UUID. Now, my nvram.XXXXXX.plist is not working and I get the "No UUID present in SMBIOS System Information Table".

I've tried editing my patched bios with AMIBCP but I don't know how to set an UUID there. In type 1 table, I set the Serials just fine, also the SKU#. And the 6th field I assume is the UUID.

Sometimes when I enter many numbers, the DMI goes crazy and the Type 1 table is not displayed after a reboot, that causes me to get the nvram loading on OS X, but the serial is not injected and I don't get a system definition.

The tools I also used to insert the UUID is AMIDEDOS, DMIDOS and SMBCFG. The latter came with a success and now it says that DMI is read only.

I can generate an UUID with AMIDEDOS /SU AUTO, and says it's done, but it won't survive a reboot.

I also tried your FDD44Editor and I can input the values, but they can't save it to either the untouched downloaded Asus Bios or my pmpatched. My bios is Aptio and it's just 2MB of size.

If anyone knows something, please post it here.

Cheers!

 

EDIT:

 

I can modify almost all values with SMBCFG except the f****g UUID!! :wallbash:

 

I've set the Asset Tags, the system serial, and the Motherboard serial. Everything but the UUID. 

Link to comment
Share on other sites

Hello guys,

 

Tried to flash the patched bios Code gave me but no luck, so I tried to use the SCEWIN_64 technique but my motherboard is an ASUS so I can't succeed installing the gigabyte tools to get access to SCEWIN.

 

Could someone please package just the SCEWIN_64.EXE so I can use it tu unlock the flash lock for custom FW ?

 

Thank you,

 

A.

Link to comment
Share on other sites

Super cool Code, thank you for the tools !

 

Sorry to abuse your good will, but could you give this firmware a look (new one) to check if it's locked ?

Followed your instructions but I am just a little scared of doing the wrong thing and bricking the thing...

 

Greatly appreciated,

 

EDIT : I managed to get 10.9.2 running at last, but I had to rollback to PCIfamily and APCI 10.9.1 kexts to be able to boot properly... otherwise I was getting this horrible lag, I've been following Netkas thread and I'm not the only one experiencing this. MysticalOS said it's a slight voltage change, for motherboards having the options to up PCI voltages you can fix it this way, unluckily my bios (Z9PE-D8) doesn't.

 

Omni is running a SR-X, rolling back means no PM for him... my board is different, lets see if it works on my side. Running Sandy Bridge Xeons (not v2).

 

A.

Z9PE-D8-WS-ASUS-5404.CAP.zip

Link to comment
Share on other sites

el_charlie, use FD44Editor 0.9.0, it must work on your BIOS now.

 

It says MSVCP120.dll is missing. I'm using windows 8.1 Nevermind, needed Visual C++ 2013. Thanks

 

Cheers!

 

EDIT again:

 

I can't launch the program :( I tried copying the dll from Windows/system32 to the path of the exe and then I get another error.

 

Cheers!

 

I'm installing Win7 x86 on a VM to see if I can launch the program.

 

UPDATE:

 

I managed to edit correctly with FD44Editor on Win7. and flashed to my laptop with afuwin. The values are still reset. What can I do??

Link to comment
Share on other sites

Any ideas about the above, CodeRush??

 

Cheers!

 

UPDATE:

 

Looking more into the issue, I can make a bios backup with AFU and read it with FD44Editor, the uuid and serials are still there, but the DMI data is still generic. I tried again with SMBCFG and could edit everything, even the UUID but the UUID doesn't survive a reboot. All the other info does.

 

Opening the same file with AMIBCP, I can see that in the DMI table, all the values are generic. Maybe the FD44 module is just for UEFI???

Link to comment
Share on other sites

×
×
  • Create New...