Difference between revisions of "Research: Pwnage Patches"

From The iPhone Wiki
Jump to: navigation, search
(2.0 (5A347) iBoot)
(Wait what?)
Line 44: Line 44:
 
It seems to be a file full of strings. Taking into account I am a noob that has been on Windows almost all of my life and just recently moved to Mac stuff, I really don't know what else to say :P
 
It seems to be a file full of strings. Taking into account I am a noob that has been on Windows almost all of my life and just recently moved to Mac stuff, I really don't know what else to say :P
   
I do know that if someone knows where DeviceTree is in memory, I can look through other files to see what exactly references these offsets in a way that they need patching
+
I do know that if someone knows where DeviceTree is in memory, I can look through other files to see what exactly references these offsets in a way that they need patching. As I look more and more into them, these pwnage patches seem to be getting more and more complex :P
   
 
== 2.0 (5A347) [[Lockdownd]] ==
 
== 2.0 (5A347) [[Lockdownd]] ==

Revision as of 17:56, 4 August 2008

If you have IDA Pro and you are at least semi-handy with ARM please contribute :)

Thanks to CPICH for helping out!

2.0 (5A347) iBoot

Patched Area

There is only 1 patch made to the iBoot, iLLB, iBEC, iBSS, and WTF.n82ap. They are all iBoots, pretty much, and they all have the same opcodes to their patches, so I am going to assume that they all have this same patch for the same reason. Please feel free to correct this if this is not true.

Here is a snippet of it from IDA:

ROM:1800587C 01 20                       MOVS    R0, #1          ; R1 = 1
ROM:1800587E 40 42                       NEGS    R0, R0          ; PWNAGE PATCH
ROM:1800587E                                                     ; Change 40 42 > 00 20
ROM:1800587E                                                     ; That will make it:
ROM:1800587E                                                     ; MOVS R0 = #0
ROM:1800587E                                                     ;
ROM:1800587E                                                     ; R0 (unpatched) = -1
ROM:1800587E                                                     ; R0 (patched) = 0

Why does this help us?

ROM:18005D72 FF F7 D2 FC                 BL      sub_1800571A    ; Branch with Link

That jumps to 0x1800571A. Why does that matter? well, the above "Patched Area" is at the end of this routine, and then we come back with our modified R0. Right after this BL, we get this, which is where our new R0 comes into play:

ROM:18005D76 00 28                       CMP     R0, #0          ; Set cond. codes on Op1 - Op2
ROM:18005D78 00 D0                       BEQ     loc_18005D7C    ; Branch
ROM:18005D7A 8A E0                       B       loc_18005E92    ; Branch

If R0 = 0, which is does, it will jump to 0x18005D7C. If not, it will go to 0x18005E92. I don't know the nitty gritty, but basically this is to make it so that we jump to an earlier part in the file that we were supposed to. A further analysis may be in order, I will definitely get to that later.

2.0 (5A347) DeviceTree

Patched Area

Easy one. Just two string patches

Patch One

At offset 0x30, "secure-root-prefix" is patched to "xxxxxx-root-prefix"

Patch Two

At offset 0x3344, "function-disable_keys" is patched to "xxxxxxxx-disable_keys"

Wait what?

It seems to be a file full of strings. Taking into account I am a noob that has been on Windows almost all of my life and just recently moved to Mac stuff, I really don't know what else to say :P

I do know that if someone knows where DeviceTree is in memory, I can look through other files to see what exactly references these offsets in a way that they need patching. As I look more and more into them, these pwnage patches seem to be getting more and more complex :P

2.0 (5A347) Lockdownd

This may actually confuse some people. You see, there is 'technically' two patches, but in reality, there is only one. The second one is the rehashed signature done with ldid, because you must remember that this is a userland binary, not a lower level one like the iBoot, which resides in the NOR. These files on the main filesystem must cohere to the demands of the kernel, and according to a devteam member, the patches to not require this were to complex and it would just be much easier to use ldid to take care of it. So that is what they did here. They took the original file, then one with the one patch that they needed, rehashed the patched one, BsDiff'd them, and then as you can now tell, the .patch tile contains the actual patch + the new sig :)

(Be back in a little bit with actual snippets from IDA showing the actual patch done, I want to go through the actual low level stuff first)

I don't think the dev team is using ldid because ldid changes the file size (i.e. asr sig patch added 0x20 bytes using ldid). However the same ldid method may work as well.