Tethered

2009-03-24T21:11:50Z

Owned674: New page: Tethered means being basically "attached" to your computer in a way; you must boot your device by running code on it to make use of an exploit. ==iPod touch 2nd generation== The iPod tou...

Tethered means being basically "attached" to your computer in a way; you must boot your device by running code on it to make use of an exploit.

==iPod touch 2nd generation==

The iPod touch 2nd generation was jailbreakable only as a tethered device until recently, when the hybrid dev team released the [[0x24000 Segment Overflow]], and the 2nd generation iPod touch became fully jailbreakable, permanently. The codename for the tethered jailbreak was Redsn0w.

==Linux==

Currently, certain devices are capable of booting to Linux. The downside is that this is a tethered boot.

Untethered jailbreak

2009-03-24T21:09:16Z

Owned674:

An untethered jailbreak is a jailbreak where your device does not require you to reboot from a computer by running code on it every time. Currently, all [[iPhone]]s and [[iPod touch]] models are jailbreakable in this method and the current released devices will always be subject to [[pwnage]]. The only exception is Linux on your device, where it is still in a [[tethered]] form.

0x24000 Segment Overflow

2009-03-24T21:06:52Z

Owned674:

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]] SoC has a MIU configuration which maps the "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. Statically allocated variables, heap, and stack must use the SRAM, as "[[VROM (S5L8720)|Secure ROM]]" is unwritable. A region of memory starting from 0x22024000 is used for this purpose. The region of memory from 0x22000000 to 0x22024000 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 0x22024000 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.

[[Category:Exploits]]

NitroKey

2009-03-11T18:23:26Z

Owned674:

NitroKey was a product released in late February of 2009, by the company "NitroKey," in order to aid those with a tethered jailbroken iPod touch 2G to boot their iPods. It consisted of a small dongle that looked EXACTLY like the end of an iPod cable, with no cord on it. The product was being sold for an outrageous price of $55.00 to those unfortunate enough to have made the decision to purchase one, as it went obsolete not two weeks after its release.

NitroKey

2009-03-11T18:23:09Z

Owned674: New page: NitroKey was a product released in late February of 2009, in order to aid those with a tethered jailbroken iPod touch 2G to boot their iPods. It consisted of a small dongle that looked EXA...

NitroKey was a product released in late February of 2009, in order to aid those with a tethered jailbroken iPod touch 2G to boot their iPods. It consisted of a small dongle that looked EXACTLY like the end of an iPod cable, with no cord on it. The product was being sold for an outrageous price of $55.00 to those unfortunate enough to have made the decision to purchase one, as it went obsolete not two weeks after its release.

0wnboot

2009-01-22T00:00:02Z

Owned674: New page: 0wnboot is Chronic's method of utilizing the Redsn0w exploit. It uses the same thing and does not give him any advantages over the Dev Team's Redsn0w. It's basically the same thing.

0wnboot is Chronic's method of utilizing the Redsn0w exploit. It uses the same thing and does not give him any advantages over the Dev Team's Redsn0w. It's basically the same thing.

The iPhone Wiki - User contributions [en]

Tethered

Untethered jailbreak

0x24000 Segment Overflow

NitroKey

NitroKey

0wnboot