Jump to content

[UEFIPatch] UEFI patching utility


CodeRush
1,981 posts in this topic

Recommended Posts

Hi friend, thanx in advance for your work.

I want to ask if the patch was successful.

And... Can I flash the generated file with WinFlash Utitlity?

My machine is a Asus K53SC with Bios 221.

post-968396-0-03080600-1368601040_thumb.jpg

Link to comment
Share on other sites

Yes, it was successful. Flash it like normal BIOS file.

Thanx for your reply...

I can't flash this file... when I go to flash I have an error, it say: "Date file is old, please press enter for exit".

I use Bios soft and Winflash with same result.

What I can do?

 

PD. Solved.

I can downgrade my bios with WinFlash.

Command:

WinFlash /nodate

Link to comment
Share on other sites

Pike, can you or anyone else disable this protection? If you can - please share the way to do it. If not - it's nothing to talk about. I'm not interested in arguing about whether it was Sam who discovered this protection method first, or anyone else. I don't try to have any credit in discovering it or anything. The point is: can we crack it. If so - it must be published, because for Z86 boards there will be no BIOS without this protection. If not - we could work together to crack it. Or just build or buy cheap SPI programmer and finish with it the hardware way. I have done it already.

I am not concerned about the credits. We've been over that already. It's about getting the job done. Whoever that may be. I don't really care. As long as it works. And when I find something, then I will share it right away. Like I always do. Free of charge.

  • Like 3
Link to comment
Share on other sites

Patching a backup of

maybe make a backup of bios while its on raid and mod that ?

 

Making a backup in RAID mode, patching the backup and reflashing the modded backup did indeed work.

 

Or at least I think so.. :unsure: at least ftk flashed the modded 1908 bios (both OROM and PMPatch) with no errors, after flashing the older 1805 version first. :D

 

The only problem now is that the installation of mountain lion stops when the first grey screen appears and the pointer is spinning while the machine is constantly ejecting the bluray drive.

 

I guess it wants the installation DVD, not the Clover/Mount Lion-USB stick I made with BootDiskUtility. But I really haven't had the time to troubleshoot it. :)

Link to comment
Share on other sites

z77-ds3h

I think, there is no need to patch BIOS on Z77-based Gigabyte boards, they aren't locked by default.

 

HP lapic problem

I'm not familiar with this problem.

What is it about and how it got solved now?

Link to comment
Share on other sites

I'm not familiar with this problem.

What is it about and how it got solved now?

 

I'm not an expert, but I believe that HP insyde BIOS disables APIC/LAPIC which causes the OS X kernel to panic if booting with a multicore CPU.

 

There are currently two work arounds for that:

1- Either use cpus=1 as a kernel flag (which makes OS X use only one core) or

2- Patch the kernel to disable the lapic panic.

Link to comment
Share on other sites

I'm not an expert, but I believe that HP insyde BIOS disables APIC/LAPIC which causes the OS X kernel to panic if booting with a multicore CPU.

 

There are currently two work arounds for that:

1- Either use cpus=1 as a kernel flag (which makes OS X use only one core) or

2- Patch the kernel to disable the lapic panic.

It seems that the latest Clover rev. has added a lapic patch, don't know if it is the same.

Link to comment
Share on other sites

I think, there is no need to patch BIOS on Z77-based Gigabyte boards, they aren't locked by default.

 

 

I'm not familiar with this problem.

What is it about and how it got solved now?

 

Yeah you're right, thank you. I don't know why but I can't get more then 2 p-states with clover (16 and 39 with macmini6,1. unfortunately macmini6,2 makes the system reboot during boot)

With chameleon (and model macmini6,2) now i get up to 6 states ( 16 21 28 34 37 39 )

Link to comment
Share on other sites

I don't know if this LAPIC bug can be solved with BIOS modification. At first, I need to figure out the difference between buggy BIOS and normal BIOS, and as far as I don't have any affected system, it can be very hard to do.

If this Clover patch is working, then it's easier to use it and do nothing with BIOS.

Link to comment
Share on other sites

It's not really a bug in the BIOS, but rather a stupid decision by HP. I think the problem is that APIC is "disabled" by the BIOS and since this is an OEM BIOS there is no user-visible option to re-enable it.

 

What clover does is patch the kernel before booting to "disable" the panic. Not a very wise idea as kernel code could change anytime.

 

I saw people online unlocking Insyde BIOS which gives options to mess with APIC. Have a look here: http://forum.noteboo...ation-info.html

 

Once again, I'm no expert so I don't know if I'm making any sense here.

 

Thanks for your time.

Link to comment
Share on other sites

 

What clover does is patch the kernel before booting to "disable" the panic. Not a very wise idea as kernel code could change anytime.

 

 

I'm the guy who created the lapic patches that were added to clover by gsly.

 

The kernel code it patches has remained the same since at least 10.6.0. So unless Apple completely rewrites that portion of the kernel, clover should successfully fix this issue for a long time :thumbsup_anim:

 

 

@CodeRush I originally thought that the APIC table in the bios was responsible for the kernel panic, but I tried injecting modified versions of it using clover's

 

<key>ApicName</key>
<string>APIC.aml</string>
<key>DropAPIC</key>
<string>Yes</string>

 

but I couldn't get anything to fix it. I did notice that HP's APIC tables don't have any NMI entries as compared to most other vendor's. This was kind of interesting because the first lapic kernel fix discovered by yehla2amer involved adding this line of code to the kernel:

 

/* NMI: ummasked, off course */
LAPIC_WRITE(LVT_LINT1, LAPIC_LVT_DM_NMI);

 

Fixing the lapic problem with a bios mod doesn't seem worth it to me when Clover is now perfectly capable of achieving the same result :P

 

And are you still working on a successor to PMPatch? Haven't heard you mention anything about it for a while.

  • Like 2
Link to comment
Share on other sites

Thank you for explanation, Donovan.

Yes, i'm still woking on that PMPatch successor, but very slowly, because right now I have no time for programming at all.

In 2 months I have my last exams, and now I'm taking part of uC-related hardware project of my university, that consumes all my free time.

As far as I see, current PMPatch version is good enough and there is no reason to hurry.

  • Like 2
Link to comment
Share on other sites

New Intel CPU platform is now on the market and I'm waiting for it's first users, that try installing OS X on it and see if this patch is still needed.

Power management routines for Haswell have been changed a lot, so if our register is still 0xE2 and it's still locked, then we must find a way to patch the locking code out.

I need BIOS images from real Z87 boards, especially ASUS ones (not BIOS files from vendor sites), and MSRDumper reports.

To make a backup of your Z8x BIOS, use Intel FPT (attached) and one of batch files, running it as Administrator.

Try biosbck.bat first, if it works and produces biosbck.bin file, try backup.bat too. Attach your biosbck.bin or backup.bin file to your post.

Thank you in advance.

Z8x_BIOS_backup.zip

  • Like 1
Link to comment
Share on other sites

I have made a small research and now see, that Intel code is stable and persistent. No one knows what is it for, so no one touches it. And it goes unmodified from the beginning of the Universe to the end of it. :)

Behold, the 0xE2 locking code in ASUS Z87 WS BIOS based on AMI Aptio V platform:

80 FB 01
75 08
0F BA E8 0F
89 44 24 30

Looks familiar? Exactly the same code as in PowerManagement module for Sandy/Ivy, only located in different module named PowerMgmtDxe with GUID F7731B4C-58A2-4DF4-8980-5645D39ECE58.

Trivial change for PMPatch will make it compatible with new BIOSes.

The problem is that flashing modified BIOSes can be very hard on boards without USB Flashback feature, because of AMI's new protection, but there is nothing impossible for people with hardware SPI programmer. :)

  • Like 5
Link to comment
Share on other sites

I'm pleased to announce that this patch works fine for the

Asus P8H77-M LE bios.

Both with flashrom dumps and the original cap bios dumps.

Thanks Coderush ;)

  • Like 1
Link to comment
Share on other sites

I have made a small research and now see, that Intel code is stable and persistent. No one knows what is it for, so no one touches it. And it goes unmodified from the beginning of the Universe to the end of it. :)

Behold, the 0xE2 locking code in ASUS Z87 WS BIOS based on AMI Aptio V platform:

80 FB 01
75 08
0F BA E8 0F
89 44 24 30

Looks familiar? Exactly the same code as in PowerManagement module for Sandy/Ivy, only located in different module named PowerMgmtDxe with GUID F7731B4C-58A2-4DF4-8980-5645D39ECE58.

Trivial change for PMPatch will make it compatible with new BIOSes.

The problem is that flashing modified BIOSes can be very hard on boards without USB Flashback feature, because of AMI's new protection, but there is nothing impossible for people with hardware SPI programmer. :)

 

Hi CodeRush - Thanks for the heads up on this - appreciated and good luck with the final exams. Your work has made a significant difference to many of us with Asus boards and it looks as though more will be added to the list.

  • Like 1
Link to comment
Share on other sites

Hello CodeRush, the new Zotac Z77 ITX bios (april 2013) gave me this

Last login: Wed Jun  5 23:07:47 on console
localhost:~ gio$ /Users/gio/Desktop/PMPatch /Users/gio/Desktop/A2290426.bin /Users/gio/Desktop/A2290426Patch.bin 
PMPatch 0.5.11
PowerManagement modules not found.
Trying to apply patch #1
Nested PowerManagement module at 0032FC8C not patched: Patch pattern not found.
AMI nest module at 00550048 not patched: PowerManagement modules not found in nested module.
Phoenix nest modules not found.
CpuPei module at 0079F3E0 not patched: Patch pattern not found.
localhost:~ gio$ 

Any idea?

  • Like 1
Link to comment
Share on other sites

The power management module itself is there but PMPatch is not able to find the patch pattern. It will need to be added to a future version. Until then you can try to do it yourself.

 

PS: Just found out PMPatch is able to patch a single module without without extracting the bios. Nice!

 

EDIT: Are you sure it needs to be patched at all? I suspect that it already is unlocked.

Edited by k3nny
  • Like 1
Link to comment
Share on other sites

@CodeRush.

 

Please to advise that PMPATCH works with the latest Asus BIOS 2003 for my Z77 Sabertooth, and fixes the power management issue. One is no longer able to write to nvram on these boards with the two latest BIOS releases (1908/2003) . We hoped it was a bug, but it now looks intentional as 2003 exhibits the same issue. Fortunately for Clover users there is a workaround using EmuVariableUefi-64.efi, which saves a nvram.plist to disk rather than the internal nvram which is now locked....

 

PMPATCH is great! Thanks.

  • Like 1
Link to comment
Share on other sites

×
×
  • Create New...