SpeedStepper (now supports Mountain Lion 10.8.3)

[rcork]

They are the RVA (virtual offset). I edited the file directly in MachOView so i didn't need to load up the file in a hex editor (therefore, not needing the file offset).

[jazzyguy]

Alright thanks.

 

But I thought dmazar said you couldn't edit it in that application?

 

Actually I see how to change the 0f30, but not how to add a whole new line for another 90

[rcork]

Just replace 0F 30 with 90 90 (two NOP instructions). When you save and then reopen the file, it will then list the NOP instructions on separate lines.

[jazzyguy]

Gotcha. Thanks. I really appreciate the help.

[slave-zeo]

I'll be the first to admit I don't understand about 75% of what you folks are saying BUT what I can say is that I tried the above linked kext (AppleIntelCPUPowerManagement.kext-PATCHED.zip) and my Mt. Lion 10.8 system booted without the need for the NullCPU kext.

 

Upon booting into the OS I loaded MSRDumper and opened up the console and let the system run for about 15 minuets. Saddly, all I got was one state and it was 16. I would asume my cpu was running at the bare minimum. Still, this is very promising. Thanks for the patched kext!

[oSxFr33k]

I'll be the first to admit I don't understand about 75% of what you folks are saying BUT what I can say is that I tried the above linked kext (AppleIntelCPUPowerManagement.kext-PATCHED.zip) and my Mt. Lion 10.8 system booted without the need for the NullCPU kext.

 

Upon booting into the OS I loaded MSRDumper and opened up the console and let the system run for about 15 minuets. Saddly, all I got was one state and it was 16. I would asume my cpu was running at the bare minimum. Still, this is very promising. Thanks for the patched kext!

 

If you do not get a kernel panic it means the patching was successful!!! It's main purpose is to patch the AICPUPM to prevent the kernel from panic. I think the speedstep part is separate and has nothing to do with this patch. Its your machine's profile, someone correct me if I am wrong?

[oSxFr33k]

@dmazar,

 

Thanks for your great guide which sparked others for alternate ways to accomplish this.

 

@oldnapalm,

 

Thanks for sharing your method. A perfect and quick way to search.

 

@rcork,

 

Thanks for the clarifying how this can all be done in MachOView. No need for a separate Hex editor.

 

I compared my patched 10.7.3 with the one that was patched by flAked and they are 100% the same.

 

Thanks to the rest of you who motivated others to help us out!!

[slave-zeo]

If you do not get a kernel panic it means the patching was successful!!! It's main purpose is to patch the AICPUPM to prevent the kernel from panic. I think the speedstep part is separate and has nothing to do with this patch. Its your machine's profile, someone correct me if I am wrong?

 

Good deal, then it's a go on the patch I'll have a look at the imac12_2.plist and see whats going on inside it.

 

Thanks a bunch for the speedy work and replies.

[jazzyguy]

Yeah guys thanks for the works, I was afraid we might struggle with this, and I wouldn't be able to upgrade, but now not only do I know others can do it, I can as well.

 

Thanks a ton!

[dmazar]

Hi guys, that was fast.

Did not know it's possible to edit file in MachoView - know now.

 

OsXFr33k - I never worked with IDA Pro, so not sure, but since it's one of the best disassemblers and more then that, I guess you can do all of it in there also.

 

Here is a tool equivalent to flAked's patcher, but in Perl. Can be easily edited and modified. Replaces wrmsr's with nop. Handles different versions of AICPUPM by different specification files.

 

Usage:

> perl patch_aicpupm.pl <AICPUPM_executable> <spec_file>

if permissions are problem, then

> sudo perl patch_aicpupm.pl <AICPUPM_executable> <spec_file>

 

For example, if you put in the same folder:

- patch_aicpupm.pl

- AppleIntelCPUPowerManagement.kext (ML version)

- Spec-ML-10.8.0-12A128p.txt (patch spec for ML version)

 

Then you can patch AICPUPM with:

perl patch_aicpupm.pl AppleIntelCPUPowerManagement.kext/Contents/MacOS/AppleIntelCPUPowerManagement Spec-ML-10.8.0-12A128p.txt

 

Patching of different AICPUPM version can be done by specifying appropriate Spec file. Spec file is just a list of addresses/positions (in hex, one per line) of target wrmsr's in AICPUPM. This does not save us from manually finding places for patch when new AICPUPM arrives - somebody would still need to do that - but if he makes new spec file and share it, anybody could execute that patch. Specially if kext uploading becomes a problem.

 

Initial files are here - perl file and specs for 10.7.0, 10.7.3 and 10.8.0 (12A128p) .... feel free to test it, fix it, change it, improve it, add new specs ...

I've done some limited tests - seems to work fine, but I'm not 100% sure. Last time doing some perl coding long time ago.

 

Method: by flAked

Addresses in spec for Lion: from flAked's patcher

Addresses in spec for ML: from oldnapalm and rcork from above posts

 

Update: there's a universal patcher from el coniglio and oldnapalm here

patch_aicpupm-v1.0.zip

[rcork]

@dmazar Nicely done!

[oSxFr33k]

When I checked my edited 10.7.3 against the one flAked released I do see some minor binary differences in line 66 of an application called kdiff.

 

I compared the PDF files and the edits were identical so I wonder if the machoview inserted something from buffer or something else when I saved the file? Can someone else do the edits with Mach0view then compare the binaries with KDIFF to see if you come up with the same difference in line 66.

 

See screenshot:

 

Left side is my edit right side is the one flAked edited.

 

 

EDITED A FEW MINUTED LATER:

 

I wanted to make sure machoview was not introduces any artifacts etc so I opened flAked patched 10.7.3 and clicked on RVA then saved. Reloaded in kdiff and same result some extremely minor differences in the last couple of lines in section 66. Sorry the screenshot sux. Program to compare binaries is actually called kdiff3 not kdiff

[jazzyguy]

I wonder if that could cause the difference in the pstates aworking.

[oSxFr33k]

@rcork,

 

Are we suppose to patch only ECX followed by WRMSR or also the ones followed by RSI RDX, then WRMSR?

 

Can we also edit the x86 if we need to boot 32 bit mode which I have to on occasion to launch my Sprint USB modem software. I have to put in the null AICPUPM kext when I need to boot 32 bit mode.

[rcork]

@rcork,

 

Are we suppose to patch only ECX followed by WRMSR or also the ones followed by RSI RDX, then WRMSR?

 

Can we also edit the x86 if we need to boot 32 bit mode which I have to on occasion to launch my Sprint USB modem software. I have to put in the null AICPUPM kext when I need to boot 32 bit mode.

We need to patch any WRMSR instruction where the ECX register holds 0xe2. Most of the time the mov instruction is followed directly by the wrmsr but not always.

[oSxFr33k]

We need to patch any WRMSR instruction where the ECX register holds 0xe2. Most of the time the mov instruction is followed directly by the wrmsr but not always.

 

WHat about 32 bit mode how can we modify the binary or what section?

 

Also can you check my 10.7.3 against yours and flAked. I think the one flAked released has an error. See my post a couple up. I attached flAked wich is the second one that has 10.7.3 in the zip name.

 

EDITED:

 

I checked mine against yours in diff3 and the binaries are exact. I replaced flAked with mine and I am running about 5 degrees cooler. Maybe his was from a Developer Release?

 

EDITED AGAIN:

 

I am seeing the same issue in 10.7.2 as well. See my post a few up.

AppleIntelCPUPowerManagement.zip

AppleIntelCPUPowerManagement_10.7.3.kext.zip

[rcork]

I just patched the 10.7.3 AICPM kext using flaked's program, manually using machoview, and dmazar's perl script and in all three cases, the patched files were identical (i used Hex Fiend to compare).

 

@osxfr33k, in the first file you attached above (without the _10.7.3), it was missing the patch at address 0xab64.

[oSxFr33k]

I just patched the 10.7.3 AICPM kext using flaked's program, manually using machoview, and dmazar's perl script and in all three cases, the patched files were identical (i used Hex Fiend to compare). @osxfr33k, in the first file you attached above (without the _10.7.3), it was missing the patch at address 0xab64.

 

I printed the file as PDF so maybe the PDF is missing that address each time? WHat is the address in RVA mode in machoview please. So same deal in 10.7.2 the PDF printout is missing that address.

[rcork]

In Machoview, with RAW selected, scroll down to address 0000AB64. Then click RVA and the address will change to 00009B64.

 

Instead of using print to pdf, just open terminal and use otool to extract and disasseble to a text file. Then just search the text file for what you are looking for and then patch over in Machoview. The line addresses in the text file correlate to the RVA addresses in Machoview. Better yet, just use the perl script from dmazar.

 

otool -tv -arch x86_64 AICPM/Contents/Mac/AppleIntelCPUPowerManagement > asm.txt

[oSxFr33k]

In Machoview, with RAW selected, scroll down to address 0000AB64. Then click RVA and the address will change to 00009B64.

 

Instead of using print to pdf, just open terminal and use otool to extract and disasseble to a text file. Then just search the text file for what you are looking for and then patch over in Machoview. The line addresses in the text file correlate to the RVA addresses in Machoview. Better yet, just use the perl script from dmazar.

 

otool -tv -arch x86_64 AICPM/Contents/Mac/AppleIntelCPUPowerManagement > asm.txt

 

Sorry about going back and forth but I see why it was missed. Are we not searching for 0x000000e2, %ecx?

 

That address you gave to me is 0x00000800, %eax

 

I know WRMSR follows that but are we not looking for 0e2, ecx?

[rcork]

Sorry about going back and forth but I see why it was missed. Are we not searching for 0x000000e2, %ecx?

 

That address you gave to me is 0x00000800, %eax

 

I know WRMSR follows that but are we not looking for 0e2, ecx?

Remember, we have to patch any call to WRMSR where ECX is holding 0xe2. The instruction at address 0xAB53 is storing 0xe2 in ECX. Even though there are 4 instructions between 0xAB53 and 0xAB64, ECX is still holding 0xe2 at that point. That means we need to patch it. Make sense?

[oSxFr33k]

Remember, we have to patch any call to WRMSR where ECX is holding 0xe2. The instruction at address 0xAB53 is storing 0xe2 in ECX. Even though there are 4 instructions between 0xAB53 and 0xAB64, ECX is still holding 0xe2 at that point. That means we need to patch it. Make sense?

 

I think I get it except I see an rdmsr there which is what I thought where the prior 0x0e2 would stop? SO its still being held beyond that I am guessing. What is the "stop" or an indicator when its no longer being held? What to look for?

[rcork]

I think I get it except I see an rdmsr there which is what I thought where the prior 0x0e2 would stop? SO its still being held beyond that I am guessing.

rdmsr reads 64 bits from the MSR in ECX and stores the data in EDX:EAX. So the code stores 0xe2 in ECX. Then it calls rdmsr which reads the data from MSR 0xe2 and stores that in EDX:EAX. However, ECX is still set to 0xe2 so when the wrmsr is called, it would kernel panic if not patched.

[oSxFr33k]

rdmsr reads 64 bits from the MSR in ECX and stores the data in EDX:EAX. So the code stores 0xe2 in ECX. Then it calls rdmsr which reads the data from MSR 0xe2 and stores that in EDX:EAX. However, ECX is still set to 0xe2 so when the wrmsr is called, it would kernel panic if not patched.

 

And the weird thing is I have 10.7.2 and 10.7.3 not patched at that address and neither one gets a kernel panic!!

 

So is there a command that would tell me when the sequence is complete. movl movl orq etc etc

 

Thanks

[oldnapalm]

This script searches for write operations to MSR 0xE2 in otool output, so it should work for any version. Tested with 10.6.8, 10.7, 10.7.2, 10.7.3 and 10.8. Thanks to el coniglio for the script.

 

AICPMPatch.pl.zip

 

Usage:

 

List wrmsr (without patching)

perl AICPMPatch.pl AICPM.kext/Contents/MacOS/AppleIntelCPUPowerManagement

 

Patch

sudo perl AICPMPatch.pl AICPM.kext/Contents/MacOS/AppleIntelCPUPowerManagement --patch

 

 

Any ideas about i386? The wrmsr addresses from otool doesn't have 0F 30. How does it work in 32 bit?

Solved, thanks dmazar.

Edited March 3, 2012 by oldnapalm
Script updated