The iPhone Wiki - User contributions [en]

0x24000 Segment Overflow

2009-07-19T15:45:18Z

IZsh:

Also known by its codename, "24kpwn", this was the first exploit in the [[S5L8720]] that allowed us to bypass the bootrom signature checks on [[LLB]] and create what is known as an [[untethered jailbreak]].

==Note==
It is unclear how, but the company known as "NitroKey" is selling this. We were planning on holding back for the new iPhone (which subsequently could mean an iPod touch 3G as well), but now that they are profiteering off of this we would like to explain exactly how this works as soon as possible so people do not have to waste their good money on it.

==Credit==
A "hybrid" dev team, in alphabetical order: '''chronic''', '''CPICH''', '''ius''', '''MuscleNerd''', '''planetbeing''', '''pod2g''', '''posixninja''', et al. (anyone wishing to be unnamed)

==Background==

Upon boot-up, the [[S5L8720]] and [[S5L8920]] SoC have a MIU configuration which maps the [[VROM (S5L8720)|Secure ROM]] to 0x0, providing the newly turned on device with an ARM exception vector and the first code to execute. This MIU configuration also maps a small amount of SRAM to 0x22000000 for the [[S5L8720]], and 0x84000000 for the [[S5L8920]]. Statically allocated variables, heap, and stack must use the SRAM, as "[[VROM (S5L8720)|Secure ROM]]" is unwritable. A region of memory starting from (SRAM Start)+24000 is used for this purpose. The region of memory from the start of SRAM to (SRAM Start)+0x24000 is used as a buffer for loading the [[LLB|next stage bootloader]] code. The [[LLB]] code is stored in [[NOR]], along with code for all other bootloader stages, as well as art resources (boot logos) and the [[DeviceTree|OpenFirmware device tree]] to provide to the XNU [[kernel]]. The first portion (first 0x160 bytes) of memory at (SRAM Start)+0x24000 is used for initialized statically allocated variables. Shortly after boot, values for that region are initialized from [[VROM (S5L8720)|Secure ROM]].

==Vulnerability==

The code that reads the [[LLB]] img3 from [[NOR]] into memory does not check the size of the [[LLB]] image being loaded, instead taking the size directly from the non-signature checked portion of its img3 header on the [[NOR]] (see ROM offset 0x2178). Any image greater than 0x24000 bytes in length will begin overwriting the portion of memory used to store Secure ROM statically allocated variables. Immediately vulnerable data includes USB data structures for [[DFU]] mode, a pointer to the bdev list structure, task list structures for the Secure ROM's scheduler, as well as the addresses of the hardware SHA1 registers. All of the above are potential avenues for exploitation. The method described below uses the SHA1 register addresses.

This vulnerability was discovered independently by '''pod2g''' and '''MuscleNerd'''.

== Exploit==

The goal of the exploit is to gain arbitrary code execution capability.

The exploit, as proposed by '''planetbeing''', uses the overflow to overwrite one of the addresses of the SHA1 registers. The particular register is the only one that directly copies data to be hashed into the hardware (or into an arbitrary memory location, once the destination address has been overwritten). Code execution is achieved by writing data into the stack, specifically by overwriting the LR of the function performing the write to the "SHA1 register" so that instead of returning to the main SHA1 routine, it returns to a chosen location in memory that contains the payload code. The location chosen is within the range of memory that is filled with the [[LLB]] img3, so that the payload code can be placed within the [[LLB]] img3.

The challenge is determining what to put in as the SHA1 register location so that the right portion of stack can be overwritten with the payload LR. This can be challenging without having access to any sort of exception dump (crash register dumps in the bootrom had been disabled by Apple). '''planetbeing''' performed a static analysis of a very detailed IDB produced by '''chronic''' and '''CPICH''' and determined the theoretical call stack for both of the invocations of the SHA1 hardware within the bootrom code [http://pastie.org/414981].

In-situ verification of the LR location was performed by '''posixninja'''. '''CPICH''' discovered a way to alter the img3 DER so that the second invocation of the SHA1 hardware was not performed without affecting the first, allowing better confirmation that this step was performed properly.

The final SHA1 register address was chosen so that the first dword of the DATA tag of the [[LLB]] img3 would replace sub_5E54's LR. This is because this is the first dword of the img3 that can be altered without substantially changing the img3's structure (and possibly disrupting earlier parsing code). The LR replacement must be done the first time the exploit is triggered (by the invocation of sub_5E54), or else the bootrom would crash. Since sub_5E54 takes 0x40 bytes of data at a time, the replacement LR thus must be within the first 0x40 bytes of data to be hashed. Data to be hashed starts at 0xC bytes from the start of the img3, and the first dword of the DATA tag is 0x20 bytes from the start of the img3. Thus, the SHA1 register address chosen should be 0x20 - 0xC = 0x14 bytes before sub_5E54's LR. So, it must be 0x2202FE24. Note that the exploit will also trash up to 0x2202FE24 + 0x40 = 0x2202FE64. So a sizeable portion of doComputeSHA1's stack will be trashed as well.

The final exploit img3 was verified by '''posixninja''' under '''planetbeing''''s instructions to allow arbitrary code execution. It was a regular Img3 with padding up to 0x24000 bytes. The next 0x100 bytes were taken from the original initialization values for 0x22024000. However, 0x240FC, the offset of the SHA1 register address, was altered to 0x2202FE24. The first dword of the DATA tag (offset 0x20) was altered to 0x22023000. Payload code was placed at offset 0x23000.

==Payload==

The goal of the payload is to allow an unsigned [[LLB]] to be loaded.

There are several ways that can be used, including directly calling the JumpToMemory function which is designed to prepare the SoC and invoke the [[LLB]] code. However, it's designed to be used on decrypted, unpacked code, and the [[LLB]] code currently resides in an encrypted from within the img3's DATA tag. The simplest solution is thus to use the bootrom's own machinery to decrypt and execute the code.

The final payload evolved out of a discussion between '''pod2g''' and '''planetbeing''', based on an IDB documented by '''pod2g''', '''chronic''', '''CPICH''', et al. The lowest impact solution is to apply the pwnage patch to the rsaCheck subroutine of the bootrom, and returning from the payload from computing the SHA1 without crashing the bootrom. However, in this case, since bootrom text is unwritable, this was not a viable solution.

The next lowest impact solution is to return from the entire parseFirmwareFooter function with a successful value, instead of the failure value it would normally return if signature checks fail. This would skip any remaining code in that subroutine. This solution did not work in-situ. Failures checking the epoch tags prevented the firmware from being executed. The cause of this was not investigated.

The final payload was to return past the verification of epoch and other tags in the [[LLB]] img3 to a spot right before the DATA tag was loaded from memory and decrypted. R5 was set to 0 to ensure decryption would not be skipped. The original value for the first DATA dword (before we had to overwrite it with the exploit LR) is written back to 0x22000020 by the payload, and the original SHA1 register value was written back to 0x2202FE24 to ensure the payload only activates once.

==Deployment==

Although the exploitive [[LLB]] can be manually written to [[NOR]] by bootstrapping from a tethered jailbreak, the easiest way is to use the Apple restore process itself. Apple's Restore process will write arbitrary img3s onto the [[NOR]], even if they fail signature checks. However, the "total size" value of the img3 is fixed up by the kernel before it is written to [[NOR]]. This would negate the exploit. However, '''MuscleNerd''' discovered that this could be bypassed by including the padding in another tag, such as CERT. Then, the written exploit [[LLB]] would have the "correct", exploitive total size.

==Timing Impact==
This exploit would have allowed the [[pwnage]] of the next generation iPhone without the discovery of an additional code execution vulnerability (required to write the exploit [[LLB]]), provided that the bug still existed in the next generation's bootrom. Even if it is too late to patch the bootrom now, it is not too late for Apple to repair the restore process in the stock IPSW so that we have no way to get the exploitive [[LLB]] onto the device. Before, Apple would have no reason to fix this, since writing arbitrary data to [[NOR]] does not negate their chain of trust. However, now that a way has been found, they now can prioritize a fix for this oversight.

Thanks to irresponsible handling of the exploit by a third-party company known as [[NitroKey]], this eventuality is a near-certainty and pretty much erased the possibility of a day-of-release jailbreak for the next-generation iPhone or iPod touch. May they burn in hell for all eternity.

==3GS Implementation==

The exploit remains the same in spirit.

The call tree and stacks analysis is very similar although a few bytes here and there changed it slightly. It was again done manually but afterward, and out of fun, an IDA Python Script was written to automate the process. The new static analysis can be seen here [http://pastie.org/551212], and the IDA Python Script for it there [http://github.com/iZsh/IDA-Python-Scripts/].

The main differences are:

* the SRAM is at 0x84000000 instead of 0x22000000
* the Original value of the first DATA dword is written back to 0x84000040 (which was overwritten by the LR address)
* the SHA1 register original value is written back to 0x840241CC
* '''The decrypt flag is not held in R5 anymore''', but in a local variable of the function "my_process_module" (sub_2564). An extra static analysis tells us this variable is held at 0x84033F30, thus that's where you have to store your 0x0 value before returning to this function.

[[Category:Exploits]]

Talk:ARM7 Go

2009-07-07T19:35:57Z

IZsh:

== Vulnerability vs. Exploit and Credits ==
@Chronic: I'm fine with you adding that you found it independently, but you have to be careful with the wording in general.
It seems there are a great deal of misusages of the word "exploit" vs. vulnerability in this community. So if you don't mind, I'd like to clarify:

'''A vulnerability is the actual bug/security hole, whereas an exploit is the actual implementation which allows one to exploit the vulnerability.'''

For instance in the following sentence from the wiki:
"The actual exploit is that, in the iPod Touch 2G 2.1.1 firmware, they left behind two commands: arm7_stop and arm7_go", the word "exploit" is not used properly. You are here talking about the vulnerability, not the exploit.

In my opinion, credits for vulnerability and exploit should be separated in general (I'm not talking about this one in particular, but I'm talking about vuln/exploit in general). One can find a vulnerability without exploiting it (because he doesn't want to, doesn't have the time, or it's too complicated and he doesn't manage actually to exploit it), and likewise someone can implement an actual exploit without discovering the initial vulnerability. IMHO, '''most of the time''', the exploit is where the skills really are, because it's one thing to understand why something is a security vulnerability, it's often another to make it actually real with a POC code (because of sanity checks, checking, filters and so on). Although sometimes, I do agree that finding the vulnerability itself requires mad skillz (as an example, prop' to Bleichenbacher for finding his RSA attack), it is my belief that most of the time, the exploit is where the difficulty lies.

Anyway, I think this page contains misusage of the word exploit, and other pages too, and I just wanted to point it.

Theres one thing to be said for finding a vuln and seeing it crash, sure, thats usually not where the skill is and I'm not sure how much credit it deserves. But after an exploit is out using the vuln, it's a lot easier to get yourself to write another exploit since you have confirmation that the vuln is exploitable. The iBoot envvar one happened to be reasonably easy to find yet reasonably hard to exploit. If you really had your exploit working pre ra1n then props. But if you wrote an exploit post ra1n it's a lot easier knowing that this vuln can work. --[[User:Geohot|geohot]] 18:44, 7 July 2009 (UTC)

iZsh, when I wrote this article I was a little less experienced, and have adjusted it a bit. That being said, if you check the chronic dev google code svn, you will see that I did implement it in a payload called "0wnboot". But yes, I did confuse the "exploit" and "vulnerability" definitions. [[User:ChronicDev|ChronicDev]] 19:16, 7 July 2009 (UTC)

@geo: I can ensure you we definitely found it independently and implemented way before you released purplera!n. And I agree that re-implementing a different exploit once you know a vuln to be workable is not credit-able. Only fully independent discovery/implementation is.

Talk:ARM7 Go

2009-07-07T17:15:49Z

IZsh:

==My Payload==
(Since RedSn0w will be out any day, this is just for the hell of it :)

If anyone has any ideas and would like to mess around with this hack, here is some code that (should) patch a 2.1.1 iBSS that you loaded, in memory. Again, just for fun, as the [[dev team]] probably has redsn0w, it's payload, and program almost completed.

<pre>
@ ipod touch 2G ibss 2.1.1 patcher
@ by chronic with some gas help from ius
@
@ assemble this with gas

.section .text
.global _start
_start:
stmdb sp!, {r0-r6}
ldr r0, =rangePatch
ldr r1, =permsPatch
ldr r2, =sigchPatch
ldr r3, =sigchecLoc
ldr r4, =permschLoc
ldr r6, =rangechLoc
strh r1, [r4]
strh r0, [r6]
strh r2, [r3]
ldmia sp!, {r0-r6}
mov pc, lr

.section .data
sigchecLoc: .word 0x2200F2FE
permschLoc: .word 0x2200C330
rangechLoc: .word 0x2200C3A6
rangePatch: .hword 0x0120
permsPatch: .hword 0x0124
sigchPatch: .hword 0x0020
</pre>

[[User:ChronicDev|ChronicDev]] 19:45, 16 January 2009 (UTC)

==Chronic, I may have found the way to use arm7_go==
Try to add the size of your payload just before it as an 32bit integer.

1. without size :
I assembled your payload with gas then tried to upload it at 0x09000000 and start arm7_go.
It did nothing.
2. with size before : 0x00000048 then your payload uploaded at 0x09000000.
arm7_go => it crashed my ipod 2G.

I hope it can help. I am continuing my reasearches.

~[[User:pod2g|pod2g]]

==How do you pass the bootrom RSA checks?==
I've noticed that the exploit is at the iBoot level. So how do you (or the Dev-Team) pass the bootrom RSA checks?

~[[User:Oranav|Oranav]]

==RE: How do you pass the bootrom RSA checks?==
I do not know how it is done, but taking the screenshot on the latest devteam blog post, they have found a way to do so.

== RE: RE: How do you pass the bootrom RSA checks? ==

Okay, as to MuscleNerd's redsn0w demo, it's pretty yellowsn0w like - you have to let the bootrom sigchecks pass, and then use the exploit every time the device boots. Pretty annoying, but that's the only option without a way to pass bootrom sigchecks.

~[[User:Oranav|Oranav]]

== Wel... ==

They noted they are looking for a way around that.

== We may have something! ==

I tried what iPod2G said.

Now, after running my payload...well...things are acting really WEIRD. the first time I tried,it crashed, and now...

http://pastie.org/private/gpsvfcve6yqnm3uk4qzouq

mdb is messed up. Oh, and my screen turned blue for some reason.

Just tried again, and it turned green :O

== Vulnerability vs. Exploit and Credits ==
@Chronic: I'm fine with you adding that you found it independently, but you have to be careful with the wording in general.
It seems there are a great deal of misusages of the word "exploit" vs. vulnerability in this community. So if you don't mind, I'd like to clarify:

'''A vulnerability is the actual bug/security hole, whereas an exploit is the actual implementation which allows one to exploit the vulnerability.'''

For instance in the following sentence from the wiki:
"The actual exploit is that, in the iPod Touch 2G 2.1.1 firmware, they left behind two commands: arm7_stop and arm7_go", the word "exploit" is not used properly. You are here talking about the vulnerability, not the exploit.

In my opinion, credits for vulnerability and exploit should be separated in general (I'm not talking about this one in particular, but I'm talking about vuln/exploit in general). One can find a vulnerability without exploiting it (because he doesn't want to, doesn't have the time, or it's too complicated and he doesn't manage actually to exploit it), and likewise someone can implement an actual exploit without discovering the initial vulnerability. IMHO, '''most of the time''', the exploit is where the skills really are, because it's one thing to understand why something is a security vulnerability, it's often another to make it actually real with a POC code (because of sanity checks, checking, filters and so on). Although sometimes, I do agree that finding the vulnerability itself requires mad skillz (as an example, prop' to Bleichenbacher for finding his RSA attack), it is my belief that most of the time, the exploit is where the difficulty lies.

Anyway, I think this page contains misusage of the word exploit, and other pages too, and I just wanted to point it.

Talk:ARM7 Go

2009-07-07T17:15:02Z

IZsh:

==My Payload==
(Since RedSn0w will be out any day, this is just for the hell of it :)

If anyone has any ideas and would like to mess around with this hack, here is some code that (should) patch a 2.1.1 iBSS that you loaded, in memory. Again, just for fun, as the [[dev team]] probably has redsn0w, it's payload, and program almost completed.

<pre>
@ ipod touch 2G ibss 2.1.1 patcher
@ by chronic with some gas help from ius
@
@ assemble this with gas

.section .text
.global _start
_start:
stmdb sp!, {r0-r6}
ldr r0, =rangePatch
ldr r1, =permsPatch
ldr r2, =sigchPatch
ldr r3, =sigchecLoc
ldr r4, =permschLoc
ldr r6, =rangechLoc
strh r1, [r4]
strh r0, [r6]
strh r2, [r3]
ldmia sp!, {r0-r6}
mov pc, lr

.section .data
sigchecLoc: .word 0x2200F2FE
permschLoc: .word 0x2200C330
rangechLoc: .word 0x2200C3A6
rangePatch: .hword 0x0120
permsPatch: .hword 0x0124
sigchPatch: .hword 0x0020
</pre>

[[User:ChronicDev|ChronicDev]] 19:45, 16 January 2009 (UTC)

==Chronic, I may have found the way to use arm7_go==
Try to add the size of your payload just before it as an 32bit integer.

1. without size :
I assembled your payload with gas then tried to upload it at 0x09000000 and start arm7_go.
It did nothing.
2. with size before : 0x00000048 then your payload uploaded at 0x09000000.
arm7_go => it crashed my ipod 2G.

I hope it can help. I am continuing my reasearches.

~[[User:pod2g|pod2g]]

==How do you pass the bootrom RSA checks?==
I've noticed that the exploit is at the iBoot level. So how do you (or the Dev-Team) pass the bootrom RSA checks?

~[[User:Oranav|Oranav]]

==RE: How do you pass the bootrom RSA checks?==
I do not know how it is done, but taking the screenshot on the latest devteam blog post, they have found a way to do so.

== RE: RE: How do you pass the bootrom RSA checks? ==

Okay, as to MuscleNerd's redsn0w demo, it's pretty yellowsn0w like - you have to let the bootrom sigchecks pass, and then use the exploit every time the device boots. Pretty annoying, but that's the only option without a way to pass bootrom sigchecks.

~[[User:Oranav|Oranav]]

== Wel... ==

They noted they are looking for a way around that.

== We may have something! ==

I tried what iPod2G said.

Now, after running my payload...well...things are acting really WEIRD. the first time I tried,it crashed, and now...

http://pastie.org/private/gpsvfcve6yqnm3uk4qzouq

mdb is messed up. Oh, and my screen turned blue for some reason.

Just tried again, and it turned green :O

@Chronic: I'm fine with you adding that you found it independently, but you have to be careful with the wording in general.
It seems there are a great deal of misusages of the word "exploit" vs. vulnerability in this community. So if you don't mind, I'd like to clarify:

'''A vulnerability is the actual bug/security hole, whereas an exploit is the actual implementation which allows one to exploit the vulnerability.'''

For instance in the following sentence from the wiki:
"The actual exploit is that, in the iPod Touch 2G 2.1.1 firmware, they left behind two commands: arm7_stop and arm7_go", the word "exploit" is not used properly. You are here talking about the vulnerability, not the exploit.

In my opinion, credits for vulnerability and exploit should be separated in general (I'm not talking about this one in particular, but I'm talking about vuln/exploit in general). One can find a vulnerability without exploiting it (because he doesn't want to, doesn't have the time, or it's too complicated and he doesn't manage actually to exploit it), and likewise someone can implement an actual exploit without discovering the initial vulnerability. IMHO, '''most of the time''', the exploit is where the skills really are, because it's one thing to understand why something is a security vulnerability, it's often another to make it actually real with a POC code (because of sanity checks, checking, filters and so on). Although sometimes, I do agree that finding the vulnerability itself requires mad skillz (as an example, prop' to Bleichenbacher for finding his RSA attack), it is my belief that most of the time, the exploit is where the difficulty lies.

Anyway, I think this page contains misusage of the word exploit, and other pages too, and I just wanted to point it.