The iPhone Wiki is no longer updated. Visit this article on The Apple Wiki for current information. |
Difference between revisions of "Research: Pwnage Patches"
ChronicDev (talk | contribs) (→Wait what?) |
m (Disambiguation.) |
||
(10 intermediate revisions by 5 users not shown) | |||
Line 3: | Line 3: | ||
Thanks to CPICH for helping out! |
Thanks to CPICH for helping out! |
||
+ | ==The Patches== |
||
− | == 2.0 (5A347) iBoot == |
||
+ | There are three core patches in Pwnage. |
||
− | === |
+ | ===[[iBoot (Bootloader)|iBoot]]=== |
− | There is only 1 patch made to the iBoot, |
+ | There is only 1 patch made to the [[iBoot (Bootloader)|iBoot]], [[LLB]], [[iBEC]], [[iBSS]], and [[WTF]]. It simply patches the RSA check to return success when an error occurs. |
+ | The patch is simple. This is the default non-patched area: |
||
− | Here is a snippet of it from IDA: |
||
+ | <pre> |
||
+ | ROM:00002636 _fail ; CODE XREF: rsaCheck+3C�j |
||
+ | ROM:00002636 ; rsaCheck+84�j |
||
+ | ROM:00002636 ; rsaCheck+A0�j |
||
+ | ROM:00002636 ; rsaCheck+B4�j |
||
+ | ROM:00002636 ; rsaCheck+F0�j |
||
+ | ROM:00002636 ; rsaCheck+100�j |
||
+ | ROM:00002636 ; rsaCheck+10C�j |
||
+ | ROM:00002636 ; rsaCheck+110�j |
||
+ | ROM:00002636 ; rsaCheck+118�j |
||
+ | ROM:00002636 ; rsaCheck+11C�j ... |
||
+ | ROM:00002636 454 01 20 MOVS R0, #1 |
||
+ | ROM:00002638 454 40 42 NEGS R0, R0 |
||
+ | </pre> |
||
+ | Now, all that they do is change the "40 42" you see at 0x2638 to "00 20" (negs r0,r0->movs r0,#0). |
||
− | 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 |
||
+ | ===DeviceTree=== |
||
− | === Why does this help us? === |
||
+ | This simply patches "secure-root-prefix" and "function-disable_keys". It seems that you could bypass this patch by simply patching the [[iBoot (Bootloader)|iBoot]] flags to 0xffffffff, but I have personally never verified that the decrypted [[KBAG]] was correct, so anyone that is feeling adventurous and wants to verify, please do. |
||
− | ROM:18005D72 FF F7 D2 FC BL sub_1800571A ; Branch with Link |
||
+ | ===[[Kernel]]=== |
||
− | 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: |
||
+ | Haven't really looked into this too far, but I know that the kernel is patched for codesign as well as a write and execution patch to allow addons such as [[Mobile Substrate]] to execute on / at the kernel |
||
− | |||
− | 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". |
||
− | This would presumably prevent the hardware keys from being disabled at boot. |
||
− | |||
− | === Wait what? === |
||
− | This tricks the iPhone into: |
||
− | # Making it always secure boot |
||
− | # Making it enable key access |
||
− | |||
− | This is required to decrypt KBAGs, as a sidenote. |
||
− | |||
− | == 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. |
Latest revision as of 04:42, 8 November 2010
If you have IDA Pro and you are at least semi-handy with ARM please contribute :)
Thanks to CPICH for helping out!
Contents
The Patches
There are three core patches in Pwnage.
iBoot
There is only 1 patch made to the iBoot, LLB, iBEC, iBSS, and WTF. It simply patches the RSA check to return success when an error occurs.
The patch is simple. This is the default non-patched area:
ROM:00002636 _fail ; CODE XREF: rsaCheck+3C�j ROM:00002636 ; rsaCheck+84�j ROM:00002636 ; rsaCheck+A0�j ROM:00002636 ; rsaCheck+B4�j ROM:00002636 ; rsaCheck+F0�j ROM:00002636 ; rsaCheck+100�j ROM:00002636 ; rsaCheck+10C�j ROM:00002636 ; rsaCheck+110�j ROM:00002636 ; rsaCheck+118�j ROM:00002636 ; rsaCheck+11C�j ... ROM:00002636 454 01 20 MOVS R0, #1 ROM:00002638 454 40 42 NEGS R0, R0
Now, all that they do is change the "40 42" you see at 0x2638 to "00 20" (negs r0,r0->movs r0,#0).
DeviceTree
This simply patches "secure-root-prefix" and "function-disable_keys". It seems that you could bypass this patch by simply patching the iBoot flags to 0xffffffff, but I have personally never verified that the decrypted KBAG was correct, so anyone that is feeling adventurous and wants to verify, please do.
Kernel
Haven't really looked into this too far, but I know that the kernel is patched for codesign as well as a write and execution patch to allow addons such as Mobile Substrate to execute on / at the kernel