Jump to content

[UEFIPatch] UEFI patching utility

CodeRush

By CodeRush,
in UEFI

 Share
1,981 posts in this topic

Recommended Posts

CrazyCreator
CrazyCreator
Posted
Posted

Thanks for the assertion :-)  :thumbsup_anim:

 

But a question is remaining:

 

I can write my values in OzmosisDefaults.plist ... No Problem. But iMessage does not function so yet? Or perhaps nevertheless?

 

And it is beautiful to read which you a driver develops this ozmosis problem eliminated

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

@CrazyCreator, go try UEFI shell and "nvram" command, as I suggested. I've used OZM once and I don't know or like it much, ask other people in related topic about your iMessage problems.

Link to comment
Share on other sites
CrazyCreator
CrazyCreator
Posted
Posted

Ohhhh ... UEFI Shell  :hysterical: ... I get already fear if I the terminal see.

Now the UEFI Shell? I rather leave that, there is peoples those that better can than i.

 

I can operate after one tutorial, also in the terminal too. But i go to google and learning ^^

Link to comment
Share on other sites
dmazar
dmazar
Posted
Posted

Thanks for excelent explanation CodeRush.

 

...All OSes are compatible with this implementations, except OSX, for some reason.

...

 

There is one difference in handling RT services between OSX and Win and Linux - OSX (boot.efi) copies RT code and data to different physical addresses after virtualization, while Win and Linux leave them at original physical addresses (at least I believe so).

 

OSX wants to defragment memory by moving RT services after kernel image in physical memory. In theory (by UEFI spec) this is perfectly legal and should work if RT drivers are written by the spec, but in practice this already caused us trouble because UEFI implementations are buggy.

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

@dmazar, I don't think that any moves of memory allocated as EfiRuntimeServicesData are compatible with UEFI specs, and RT is allocated that way, AFAIK.  

Anyway, EmuVariable works OK, and I will use it as an example of working NVRAM implementation for OSX.

UPD: another approach is to reimplement the whole NvramSmi by developing 2 separate drivers: DXE for initialization and SMM for actual NVRAM writes. Both of them must then be integrated into BIOS image, but it's no big problem.

Link to comment
Share on other sites
bs0d
bs0d
Posted
Posted

// 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.

 

Its not a bootloader, it just adds functionality to the firmware to boot os x naitively like a driver does.

 

its designed to run either from the firmware or from media such as a hard drive using bcfg to add.

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

@dmazar, I don't think that any moves of memory allocated as EfiRuntimeServicesData are compatible with UEFI specs, and RT is allocated that way, AFAIK.

 

 

If RT drivers are written by the spec, then they can be moved during virtualization. All they need is to accept new virtual addresses from SetVirtualAddressMap call and adjust their pointers to RT data. Then you can move them to another physical address and just define virtual address mapping to those new addresses. That is what boot.efi is doing (mapping is done by kernel, later).

 

But I just wanted to mention that speciffic OSX relocation that, quite likely, causes issues.

 

If I got it correctly, you mentioned that writes to flash/nvram is done by SMM handler. How is data (GUID, name ...) passed between RT driver and SMM handler? If they are using some common memory area, maybe they are not using the same area anymore after relocation?

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

Yes, they use common physical memory area, called NVRAM mailbox, and I have the same thoughts about this problem.

I have opened a topic on projectosx, because this is not UEFIPatch-related discussion, and there I have asked a question: where can I allocate such buffer that won't be relocated by boot.efi? Are the such addresses at all?

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

@NSCXP2005, dump you bios and try patching, if .patched file is generated - it will work, if not - attach your dump here, I'll look at it. 

Are you sure you need this patch? There is no easy way to flash modified BIOS on modern Ultrabooks, and if something failt, the PC will be bricked.

Link to comment
Share on other sites
Guest Qwaser
Guest Qwaser
Posted
Posted

I use Clover ;)

 

 

 

Have you checked in bios if you can disable the bit?

I don't understand what the bit and where to find it in the BIOS ? :/

Link to comment
Share on other sites
Kill.Javascript
Kill.Javascript
Posted
Posted

Yes, you'll use the Terminal (likely as "sudo") to run the script (which you can just copy and paste). Make sure your directory paths are correct when you issue the Terminal commands. Here's a rundown of how this guy did it. Not all of it applies to you, but you'll be able to pick up some tips: http://www.thev.net/PaulLiu/nuc-hackintosh.html

Link to comment
Share on other sites
Kill.Javascript
Kill.Javascript
Posted
Posted

double-check the md5 hash to make sure the patch actually succeeded. the md5 (terminal command: md5) for the vanilla mach_kernel is different than the one for the patched one. if the patched one is the same, re-do your patch operation. again, make sure you follow the proper directories (just drag and drop the file onto the Terminal window, as well as the patched file location. and use the sudo command.

 

also, make sure you keep a backup of the original.

 

if you've done everything properly and it STILL doesn't work, then you might want to consider re-authoring your USB stick with another installer strategy. I've used myHack lately on a few installs and for the most part it's been fine.

Link to comment
Share on other sites
Guest Qwaser
Guest Qwaser
Posted
Posted

The MD5 of the mach_kernel "vanilla" and patch is differents. You advice me  to use myHack ? What is myHack ? It's a bootloader like Clover ?

Link to comment
Share on other sites
Kill.Javascript
Kill.Javascript
Posted
Posted

well, i hope i'm not breaking any written or unwritten forum protocols here, but check out myHack home page (vous avez lu google, non?): http://myhack.sojugarden.com/guide/

as I indicated above, it's not perfect but I've got three OS X.9.4 builds running fine that I installed with it.

 

again, you'll have to do the mach_kernel patching after creating the USB installer, and then again on your OS X hard drive after installing (provided you get that far).

Link to comment
Share on other sites
mhaeuser
mhaeuser
Posted
Posted

Hey fellow hackintoshers,

 

I'm not entirely sure if this is really the right place to ask, but to be honest it seems like the best place to me. :)

After having my NVRAM working with the AptioFixDrv by dmazar (as far as I know with the help of CodeRush, not entirely sure, but thanks you very much if so!), I thought I could look into having my MSR register unlocked. The guide looked quite simple to me (and in fact it works as simple, thanks again CodeRush :) ), but my problem is more... essential. I dumped my firmware with AFU and noticed that index 0 and 1 are the exact same (I checked checksums). Thus I read through the topic and found recommendations of FPT (one user suggested it to me "personally" a while back). Downloaded, extracted, run, firmware dumped. I compared the files and found out that they were different. To be precise, index 0 differs. Index 0 and 1 are NOT the same in the image created with FPT, while they are in the AFU image. While the FPT image looks more legit to me, AFU was created by AMI and thus there is a level of trust in it. The other indexes are identical by the way.

 

As I don't have much knowledge about this area I decided that I either need to forget about patching my firmware or I need advise from someone who has an idea of what he is doing. :) I attached both dumps below in the zip-file. If you don't mind, I also have a follow-up question: I hear about People losing their motherboard S/N, their MAC adress and other data. Is it possible that THIS is exactly what happened to one of the images? If not, do I have to worry about this with FPT or AFU? I was suggested to use DPCI Maneger to be sure to keep these data, but it failed extraction.

 

I will appreciate any kind of answer helping me, even if it's a "don't patch". :) Thanks in advance!

 

Have a nice day,

Download-Fritz.

 

Edit: typo.

Link to comment
Share on other sites
Net-burst
Net-burst
Posted
Posted

Hi, CodeRush. Can you please help me? I'm trying to remove NVRAM lock on Z77 Asus Maximus V Extreme board. I found info about using AMIBCP to remove lock, but it produces image without capsule header. I think I read somewhere that UBF don't do any checks, so I'm little afraid to flash this image. So, what's best way to remove NVRAM lock for Asus boards? If its complicated like using disassembler, then can you please help me with producing image with lock removed: https://mega.co.nz/#!rk12BapQ!kCXx-HpGXsljtPCQZnlgTK6EGimu2rtUuKqPEy2H-6g ? Thanks in advance.

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