Jump to content

SpeedStepper (now supports Mountain Lion 10.8.3)


  • Please log in to reply
573 replies to this topic

#361
rcork

rcork

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 168 posts
@dmazar Nicely done!

#362
oSxFr33k

oSxFr33k

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 845 posts
  • Gender:Male
  • Interests:Sound and Graphic Design. Electronics in general.
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

Attached Files



#363
jazzyguy

jazzyguy

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 188 posts
  • Gender:Male
  • Location:USA
I wonder if that could cause the difference in the pstates aworking.

#364
oSxFr33k

oSxFr33k

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 845 posts
  • Gender:Male
  • Interests:Sound and Graphic Design. Electronics in general.
@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.

Attached Files



#365
rcork

rcork

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 168 posts

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

#366
oSxFr33k

oSxFr33k

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 845 posts
  • Gender:Male
  • Interests:Sound and Graphic Design. Electronics in general.

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.

Attached Files



#367
rcork

rcork

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 168 posts
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.

Attached Files



#368
oSxFr33k

oSxFr33k

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 845 posts
  • Gender:Male
  • Interests:Sound and Graphic Design. Electronics in general.

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.

#369
rcork

rcork

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 168 posts
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


#370
oSxFr33k

oSxFr33k

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 845 posts
  • Gender:Male
  • Interests:Sound and Graphic Design. Electronics in general.

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?

#371
rcork

rcork

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 168 posts

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?

#372
oSxFr33k

oSxFr33k

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 845 posts
  • Gender:Male
  • Interests:Sound and Graphic Design. Electronics in general.

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?

#373
rcork

rcork

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 168 posts

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.

#374
oSxFr33k

oSxFr33k

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 845 posts
  • Gender:Male
  • Interests:Sound and Graphic Design. Electronics in general.

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

#375
oldnapalm

oldnapalm

    InsanelyMac V.I.P.

  • Moderators
  • 6,857 posts
  • Gender:Male
  • Location:Brazil
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.

Attached File  AICPMPatch.pl.zip   1.47KB   222 downloads

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 by oldnapalm, 03 March 2012 - 08:53 PM.
Script updated


#376
dmazar

dmazar

    InsanelyMac Sage

  • Coders
  • 274 posts
  • Gender:Male
Oh, great :)

Although a bit risky - it still should be checked by hand on new version, I believe. But, the best option so far.

Not sure if I understand what do you mean with "addresses from otool doesn't have 0F 30". Do you mean that when you take offset with lipo and add it to address from tool, it does not match offset of this instruction in file? That position does not contain 0f 03?

#377
oldnapalm

oldnapalm

    InsanelyMac V.I.P.

  • Moderators
  • 6,857 posts
  • Gender:Male
  • Location:Brazil
Yes, that's it, if I run otool with -arch i386 and add i386 offset from lipo, the position does not contain 0F 30.

#378
jazzyguy

jazzyguy

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 188 posts
  • Gender:Male
  • Location:USA

This script searches for wrmsr (preceded by movl $0x000000e2,%ecx) in otool output, so it should work for any version. I tested only with 10.7.3 and 10.8. Thanks to el coniglio for the script.



Usage:

Search for wrmsr

perl AICPMPatch.pl /System/Library/Extensions/AppleIntelCPUPowerManagement.kext/Contents/MacOS/AppleIntelCPUPowerManagement

Patch
sudo perl AICPMPatch.pl /System/Library/Extensions/AppleIntelCPUPowerManagement.kext/Contents/MacOS/AppleIntelCPUPowerManagement patch

Important: don't patch a file that has already been patched, or unnecessary patching will be done.


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


Will this always work?

What if there was something else set to 0xe2, then the address changes and then the next line down is a 0f30?

Or am I mistaken?

#379
dmazar

dmazar

    InsanelyMac Sage

  • Coders
  • 274 posts
  • Gender:Male

Yes, that's it, if I run otool with -arch i386 and add i386 offset from lipo, the position does not contain 0F 30.


I'm not sure if I got it right, but I think it works like this ...
10.7.3 in example:

> lipo -detailed_info AppleIntelCPUPowerManagement.kext/Contents/MacOS/AppleIntelCPUPowerManagement
Fat header in: AppleIntelCPUPowerManagement
fat_magic 0xcafebabe
nfat_arch 2
architecture x86_64
	cputype CPU_TYPE_X86_64
	cpusubtype CPU_SUBTYPE_X86_64_ALL
	offset 4096
	size 191440
	align 2^12 (4096)
architecture i386
	cputype CPU_TYPE_I386
	cpusubtype CPU_SUBTYPE_I386_ALL
	offset 196608 ====> OFFarch
	size 213540
	align 2^12 (4096)

> otool -l -arch i386 AppleIntelCPUPowerManagement.kext/Contents/MacOS/AppleIntelCPUPowerManagement
AppleIntelCPUPowerManagement:
Load command 0
	  cmd LC_SEGMENT
  cmdsize 600
  segname
   vmaddr 0x00000000
   vmsize 0x00028034
  fileoff 756
filesize 154412
  maxprot 0x00000003
initprot 0x00000003
   nsects 8
	flags 0x0
Section
  sectname __text
   segname __TEXT
	  addr 0x00000000 ====> VAsect
	  size 0x0001b294
	offset 756 ====> OFFsect
	 align 2^4 (16)
	reloff 155168
	nreloc 3648
	 flags 0x00000000
reserved1 0
reserved2 0
Section
  sectname __const
   segname __TEXT
	  addr 0x0001b2a0
	  size 0x00000db4
	offset 112020
	 align 2^4 (16)
	reloff 184352
	nreloc 703
	 flags 0x00000000
reserved1 0
reserved2 0
...
...

VA = address from otool disassembled output
OFF = offset of this instruction in file - this is what you need
OFFarch = offset of architecture speciffic binary in Fat file (in lipo output)
OFFsect = offset of segment __TEXT section __text (contains code) inside architecture specific binary (in otool output)
VAsect = starting virtual address of segment __TEXT section __text (in otool output)

Then:
OFF = OFFarch + OFFsect + VA - VAsect

The same logic is for x86_64.

#380
oSxFr33k

oSxFr33k

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 845 posts
  • Gender:Male
  • Interests:Sound and Graphic Design. Electronics in general.

This script searches for wrmsr (preceded by movl $0x000000e2,%ecx) in otool output, so it should work for any version. I tested only with 10.7.3 and 10.8. Thanks to el coniglio for the script.



Usage:

Search for wrmsr

perl AICPMPatch.pl /System/Library/Extensions/AppleIntelCPUPowerManagement.kext/Contents/MacOS/AppleIntelCPUPowerManagement

Patch
sudo perl AICPMPatch.pl /System/Library/Extensions/AppleIntelCPUPowerManagement.kext/Contents/MacOS/AppleIntelCPUPowerManagement patch

Important: don't patch a file that has already been patched, or unnecessary patching will be done.


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



Works great thanks very much. I verified with manually patched 10.7.2, 10.7.3 and 10.8!!

I am interested to in patching for 32 bit since I mentioned once before there are rare moments I have to boot into 32 bit mode to use my Sprint Modem Software for when I am on call.

I also want to reiterate that the one address I mentioned here http://www.insanelym...dpost&p=1797998 if left unpatched, does not cause a kernel panic for either 10.7.2 nor 10.7.3. This type of address is not in 10.8

Is there a reason for this? Can someone try it on there Asus P8 maybe its just my Asus G74SX Laptop motherboard that is not affected. It should kernel panic in theory and it doesn't!!

Thanks again for keeping this project alive





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy