Jump to content

[UEFIPatch] UEFI patching utility


CodeRush
1,981 posts in this topic

Recommended Posts

Not right now. X79/C602 chipset boards are incompatible with OS X native PM at all, AFAIK.

 

As donovan6k discovered, the code setting the lock in his BIOS is here:

00000001800034BE: 48 0F BA E0 0F bt rax,0Fh // if bit 15 in RAX is set
00000001800034C3: 72 12 jb 00000001800034D7 // jump over the following 4 lines
00000001800034C5: 48 0F BA E8 0F bts rax,0Fh // setting bit 15 in RAX
00000001800034CA: B9 E2 00 00 00 mov ecx,0E2h // loading 0xE2 (MSR number) to ECX
00000001800034CF: 48 8B D0 mov rdx,rax // copying RAX to RDX
00000001800034D2: E8 EB C4 00 00 call 000000018000F9C2 // setting the lock
00000001800034D7: 33 C0 xor eax,eax // the execution continues here

So the patch is rather simple: jb to jmp and 0-18 NOP's to make the module size same after recompression.

Many thanks for donovan6000 for this discovery. Will implement the patching routine now.

 

UPD: done.

New version 0.5.11 is out.

Changes:

- implemented SmmPlatform patch described above.

- fixed en error in displaying patched module offsets.

 

The code is getting more and more ugly, so I will rewrite it completely as soon as possible.

Compiled versions for both OSes will be updated soon.

  • Like 2
Link to comment
Share on other sites

I think the 0xE2 register itself is not locked on X79/C602 platforms, but AppleIntelCpuPowerManagement.kext refuses to work with them. I don't know if it's possible to patch AICPM.kext to enable that support, but I heard some buzz about it.

  • Like 1
Link to comment
Share on other sites

Have an Acer S3-951 notebook.

All is working great.

Would like to get rid of the patched AICPM.kext once and for all.

 

Patched the BIOS but not sure if it's OK.

Here's the output:

ML-S3:DOS Mac$ ./PMPatch SM30118.ROM SM30118-MOD.ROM
PMPatch 0.5.10
PowerManagement modules not found.
AMI nest modules not found.
Trying to apply patch #1
Nested PowerManagement2.efi module at 009F3E92 not patched: Unknown module state.
Nested PowerManagement2.efi module at 00BBB918 patched.
Phoenix nest module at 001A6048 patched.
CpuPei modules not found.
Output file generated.

 

The reason I ask is that I am not sure if the BIOS is EFI for my model.

In other words, does the patcher check if the BIOS is truely UEFI ?

 

BTW, great job on the tool. Fantastic idea. Keep it up.

 

Thx,

Mac

Link to comment
Share on other sites

@MacNB, patching is done right. If your BIOS file is not UEFI no modules with specified UUIDs will be found.

Nested PowerManagement2.efi module at 00BBB918 patched.

Phoenix nest module at 001A6048 patched.

Link to comment
Share on other sites

Doesn't work with Intel SC5520SC (*.cap EFI bioses)

Intel SC5520SC: http://downloadcente...Y&DwnldID=18951

I have probably found the module to patch and pattern to alter (62D171CB-78CD-4480-8678-C6A2A797A8DE, MpCpuX64)

000000000000305D: 48 0F BA E0 0F bt rax,0Fh // if bit 15 in RAX is set
0000000000003062: 72 1C jb 0000000000003080 // jump over next 6 lines
0000000000003064: B9 E2 00 00 00 mov ecx,0E2h // loading MSR number to ECX
0000000000003069: E8 1A A1 00 00 call 000000000000D188 // doing something
000000000000306E: B9 E2 00 00 00 mov ecx,0E2h // loading MSR number to ECX 
0000000000003073: 48 0F BA E8 0F bts rax,0Fh // setting bit 15 in RAX
0000000000003078: 48 8B D0 mov rdx,rax // copying RAX to RDX
000000000000307B: E8 E0 3F 00 00 call 0000000000007060 // setting the lock
0000000000003080: E8 D7 9D 00 00 call 000000000000CE5C // the execution continues here

Will implement the patch soon.

Link to comment
Share on other sites

The patch above will be implemented in completely new version of PMPatch.

It will be different project written in C++/Qt with simple drag-n-drop GUI, informative log file and ability to add or edit patch patterns and modules without recompilation of executable file.

I don't think I will call it PMPatch anymore (because it can be anything with right patch patterns: AES-NI/PM/WhiteLists/etc.), so 0.5.11 is probably the latest PMPatch version will be available.

The code is very ugly now and it becomes uglier with every new module to patch and every new small feature to implement, so I need to rewrite it from scratch.

It was made as fast solution for ASUS boards only, but then it rapidly grew to this mess.

The development of this new project starts tomorrow, I will provide source code and links to beta as soon as possible. Thank you all for support and testing.

I will dedicate this project to RevoGirl who discovered PM patch at the first place. Rest in peace, RG, I didn't know you but your deeds are with us.

  • Like 3
Link to comment
Share on other sites

Before I go deep into programming, I must make a summary post about BIOSes we don't know how to patch now.

Probably, people capable of finding the way to patch by themselves, like donovan6000, will help me to find the way to patch this hard boiled pieces of binary.

 

1, by lunux, Phoenix SCT 2.1 from chinese OEM board.

PhoenixTechnologiesLtd.-11D.rom.zip

No signs of normal locking code, appears to be a variation of old CpuPei patch in different module, but I don't know for sure.

 

2., by dajs, AMI UEFI from ECS P67H2-A3.

ECS.zip

No sings of normal locking code at all. Can be CpuPei patch too.

 

3. X79/C062 BIOSes - no BIOS patch can provide native PM support, the kext itself needs to be patched. Nothing to do here now.

 

If anyone could help I'll be happy.

  • Like 2
Link to comment
Share on other sites

Only have x8 and x25 states of CPU.

Did you remove any additional or modified kexts like NullCpuPowerManagement.kext, patched AppleIntelCpuPowerManagement.kext or similar?

  • Like 1
Link to comment
Share on other sites

Before I go deep into programming, I must make a summary post about BIOSes we don't know how to patch now.

Probably, people capable of finding the way to patch by themselves, like donovan6000, will help me to find the way to patch this hard boiled pieces of binary.

 

1, by lunux, Phoenix SCT 2.1 from chinese OEM board.

PhoenixTechnologiesLtd.-11D.rom.zip

No signs of normal locking code, appears to be a variation of old CpuPei patch in different module, but I don't know for sure.

 

2., by dajs, AMI UEFI from ECS P67H2-A3.

ECS.zip

No sings of normal locking code at all. Can be CpuPei patch too.

 

3. X79/C062 BIOSes - no BIOS patch can provide native PM support, the kext itself needs to be patched. Nothing to do here now.

 

If anyone could help I'll be happy.

 

Hope this helps. After disassembling each of the bios's modules and searching through them for instances of 0xE2, this is what I've concluded.

 

Phoenix SCT 2.1's MSR lock probably happens in either:

PowerManagement2.efi F7731B4C-58A2-4DF4-8980-5645D39ECE58

SysemHddPwdDxe.efi ABAA46B8-84A3-4E74-882F-6368F6EDC9B8

 

AMI UEFI ECS P67H2-A3's MSR lock probably happens in:

CpuPei 2BB5AFA9-FF33-417B-8497-CB773C2B93BF

  • Like 1
Link to comment
Share on other sites

Did you remove any additional or modified kexts like NullCpuPowerManagement.kext, patched AppleIntelCpuPowerManagement.kext or similar?

 

My mistake. It worked. Maybe I did not run any program so that CPU also could not run with other cores. Double confirm: work on Toshiba L755, newest Bios ver 3.6 (both Mac and Windows). Thank for a great tool.

  • Like 1
Link to comment
Share on other sites

Hope this helps.

It is, thanks.

I'm looking into the disassembly of those modules, and I think SystemHddPwdDxe.efi has nothing to do with PM, but other two are definitely what we want to patch.

  • Like 1
Link to comment
Share on other sites

I have probably found the the code to patch in that CpuPei module on ECS P67H2-A3.

FFF7A8CF: 38 5D FF cmp byte ptr [ebp-1],bl // checking if first byte on stack is equal to BL
FFF7A8D2: 74 0E je FFF7A8E2 // if so, jumping over 4 next lines
FFF7A8D4: 80 7D FE 04 cmp byte ptr [ebp-2],4 // checking if second byte on stack is 4
FFF7A8D8: 76 0E jbe FFF7A8E8 // if so, jumping over 3 next lines
FFF7A8DA: 81 CE 00 80 00 18 or esi,18008000h // setting bits 28,27 and 15 (lock bit) in ESI
FFF7A8E0: EB 06 jmp FFF7A8E8 // jumping over the next line
FFF7A8E2: 81 CE 00 80 00 00 or esi,8000h // setting bit 15 (lock bit) in ESI
FFF7A8E8: 6A FF push 0FFFFFFFFh // AND mask to EDX register
FFF7A8EA: 6A F8 push 0FFFFFFF8h // AND mask to EAX register
FFF7A8EC: 53 push ebx // OR mask to EDX register
FFF7A8ED: 56 push esi // OR mask to EAX register
FFF7A8EE: 57 push edi // 0E2h MSR number is stored here
FFF7A8EF: E8 CB 11 00 00 call FFF7BABF // WRMSR inside

So the patch is a simple again, 81 CE 00 80 00 18 -> 81 CE 00 00 00 18 and 81 CE 00 80 00 00 -> 81 CE 00 00 00 00 in this particular place.

I made this patch manually with PhoenixTool, but I can't test it, so try it on your own risk.

modified_ECS.zip

 

PS. It's funny but previos CpuPei patch I have implemented is similar to this one, except the code uses ECX instead of ESI. I didn't disassemble and dig into this patch, because it was for ASUS boards with ME7 BIOSes, which are rare now. Anyway, both patches will be implemented the right way.

  • Like 2
Link to comment
Share on other sites

And I think I have found the piece of code to patch in that Phoenix SCT 2.1 by lunux.

UPD: nevermind, Atom processors have complete different MSR layout. Nothing to do here.

  • Like 2
Link to comment
Share on other sites

The lock can hopefully be removed by resetting bit 15 as long as other bits at 0000254E. The patch itself is 25 FF FF E0 FF -> 25 FF 7F E0 FF.

I have made in by hand with PhoenixTool. Test it on your own risk, lunux.

 

 

 

thanks Code Rush

I will try but can you help me to explain in which way I can do it?

thanks a lot

Link to comment
Share on other sites

dajs, it's already patched, no need to patch it again. Please flash it using normal BIOS flashing tools from ECS.

Have you updated your BIOS to the latest version using CPU EVO II utility?

 

lunux, I still need MSRDumper.kext output from you.

I don't know what utility flashes BIOS on that particular OEM board, so it's up to you to find the way to flash it.

Please don't flash anything before providing me MSRDumper.kext output.

  • Like 2
Link to comment
Share on other sites

And that's why you must not flash this modified BIOS back, or your system becomes unbootable.

Please make bootable FTK-drive as described in the first part of BIOS flashing guide linked in my signature, then boot DOS from this FTK-drive and enter biosbck command.

Wait for green "FPT Operation Passed" message, then reboot your PC with Ctrl+Alt+Del.

Now you have biosbck.bin file on your FTK-drive.

Please attach it to your reply, I will modify it and guide you further.

  • Like 1
Link to comment
Share on other sites

×
×
  • Create New...