The iPhone Wiki - User contributions [en]

User:Pod2g

2010-09-25T20:24:50Z

AriX:

pod2g is an iPhone hacker who has discovered several [[bootrom]] exploits, including the [[0x24000 Segment Overflow]] and the [[usb_control_msg(0xA1, 1) Exploit]]. He was formerly part of the [[Chronic Dev Team]], but left for personal reasons.

He was the first to [https://twitter.com/pod2g/status/23932796062 tweet the IMG3 keys] for [[iBSS]] for iOS 4.0.1 on the [[N90ap|iPhone 4]], as proof of unsigned code running on the device.

[https://twitter.com/pod2g pod2g on Twitter]

[[Category:Hackers]]

User:Pod2g

2010-09-25T20:23:57Z

AriX: Grammar.

pod2g is an iPhone hacker who has discovered several [[bootrom]] exploits, including the [[0x24000 Segment Overflow]] and the [[usb_control_msg(0xA1, 1) Exploit]]. He was part formerly of the [[Chronic Dev Team]], but left for personal reasons.

He was the first to [https://twitter.com/pod2g/status/23932796062 tweet the IMG3 keys] for [[iBSS]] for iOS 4.0.1 on the [[N90ap|iPhone 4]], as proof of unsigned code running on the device.

[https://twitter.com/pod2g pod2g on Twitter]

[[Category:Hackers]]

User:AriX

2010-09-21T18:06:05Z

AriX: New page: Member of the Chronic Dev Team. [http://ariweinstein.com/ Blog that is never updated] or [http://twitter.com/AriX Twitter].

Member of the [[Chronic Dev Team]].

[http://ariweinstein.com/ Blog that is never updated] or [http://twitter.com/AriX Twitter].

Talk:Usb control msg(0xA1, 1) Exploit

2010-09-21T18:04:23Z

AriX:

Is this even suppose to be here? :S

[[User:Ih8sn0w|iH8sn0w]] 00:31, 21 September 2010 (UTC)
:[[User:Pod2g|Pod2g]] posted it himself so I don't see much of a problem for it as it doesn't sound like it will work on new devices. --[[User:OMEGA_RAZER|OMEGA_RAZER]]

So would this exploit lead to a tethered jailbreak or would it be untethered? --[[User:JacobVengeance|JacobVengeance]] 01:50, 21 September 2010 (UTC)

:Tethered. This just allows unsigned code execution to be performed regardless of SHSH or model revision at the DFU/bootrom level. This is useful for redsn0w or blackra1n type hacks as they provide a quick and unclosable exploit to perform the actual jailbreak. Functionally, this replaces the need for sending 2.1.1 iBSS + iBEC to use Arm7Go or the 3.1.2 iBSS/iBEC (if that can even be done?) for that other USB control msg exploit in 3.1.2 iBoot. [[User:Iemit737|Iemit737]] 02:37, 21 September 2010 (UTC)

the new bootrom ipod touch 2g where ipod touch 3g so will this exploit work on ipod3g and iphone 3gs --[[User:Liamchat|liamchat]] 14:51, 21 September 2010 (UTC)

:I don't completely understand your question, but no, this exploit will work on nothing other than the 2nd generation iPod touch (and is not particularly big news, since we can already run unsigned code on the second gen touch). [[User:AriX|AriX]] 18:01, 21 September 2010 (UTC)

Talk:Usb control msg(0xA1, 1) Exploit

2010-09-21T18:01:30Z

AriX:

0x24000 Segment Overflow

2009-07-25T02:12:23Z

AriX:

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 third-generation iPod touch. In addition, Apple has added the [[ECID]] tag to the [[IMG3 File Format|IMG3 format]] in the iPhone 3GS, because they understood that an iBoot exploit would be necessary and they needed a way to prevent these exploits from permanently allowing the phone to be jailbroken. May NitroKey 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]]

0x24000 Segment Overflow

2009-07-24T23:52:25Z

AriX: iPod touch. Not iPod Touch.

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 third-generation iPod touch. In addition, Apple has added the [[ECID]] to the [[IMG3 File Format|IMG3 format]] in the iPhone 3GS, because they knew that in order to utilize 24kpwn an iBoot exploit is needed. May NitroKey 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]]

N45AP

2009-07-24T15:58:30Z

AriX:

[[Image:Ipod-touch.jpg|thumb|right|iPod touch 1G]]
This is the '''iPod Touch''' (trademarked as iPod touch) it is a portable media player with a Wi-Fi platform designed by [[Apple Inc]]. The product was launched on September 5, 2007 at an Apple hosted event called ''the beat goes on''. The iPod touch is the first iPod to introduce a multi-touch graphical interface to the iPod generations. It is availible with 8, 16, or 32GB of flash memory. It also includes Apple's popular browser [[Safari]]. With a software update introduced by Apple, users were granted access to the [[App Store]]. However, this update costed $9.95.
==Internals==
See: [[N45ap (Internals)]]

== Application Processor ==
It makes use of the [[S5L8900]] application processor. At this time, the [[iPhone]], [[iPhone 3G]], and [[iPod Touch]] all use this same processor.

== Jailbreaking Process ==
Redsn0w and PwnageTool currently support [[iPhone 3G]], [[iPhone]] and [[iPod touch 1G]]. You update through [[iTunes]] then run QuickPwn, this version supports all firmwares up to 2.2.

/private/var

2009-07-24T15:52:38Z

AriX:

== Overview ==
/private/var is the mount point for /dev/disk0s2, which is the iPhone's user/data partition. It is the larger of the two partitions, and stores all App Store applications, iTunes media, settings, photos, etc. Pre-1.1.3, all of this data was stored in /private/var/root. However, for security reasons, in 1.1.3 Apple made most applications run under the user mobile, and moved all of the data to /private/var/mobile.

== Parents ==
[[/| Root]]

== Children ==
<ul>
<li>[[/private/var/Keychains| Keychains]]</li>
<li>[[/private/var/lib| lib]]</li>
<li>[[/private/var/root| root]]</li>
<li>[[/private/var/mobile| mobile]]</li>
</ul>

/private/var

2009-07-24T15:50:05Z

AriX:

0x24000 Segment Overflow

2009-07-24T15:48:43Z

AriX: /* Timing Impact */ Nope. If we had waited for release until the 3Gs though, it would probably have been present in the iPod3,1

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 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:Alpine 1A420

2009-07-24T15:37:37Z

AriX: /* Boot the Kernel? */

== Disassembler Frameworks? ==

Has anyone noticed the ARMDisassembler, NDISASM and PPCDisasm PrivateFrameworks? --[[User:Oranav|Oranav]] 13:07, 21 July 2009 (UTC)

Yeah, at least the PPC Disasm is funny I think. Wouldn't use my iPhone for that --[[User:M2m|M2m]] 14:49, 21 July 2009 (UTC)

Those frameworks plus a lot of the other stuff here is put on the device if you have a dev membership, when the Developer Disk Image gets sent over [[User:ChronicDev|ChronicDev]] 00:16, 22 July 2009 (UTC)

== Revision Name? ==

btw, I think you should add the nickname to those revision SkankPhone or PurpleSkank. I think PurpleSkank is actually the name of something on the device, and SkankPhone the actual name, not 100% sure though. but the numbers + letters shit is kinda annoying and... bleh --[[User:Posixninja|posixninja]] 00:51, 22 July 2009 (UTC)

I'm not sure if it has an official Name like Kirkwood, Timberline, etc. I wonder if the name is somewhere "hidden" in the bunch of files.
SkankPhone is an App on the device. But if there's no objection we could name it "PurpleSkank 1A420" until the official name is found...--[[User:M2m|M2m]] 02:38, 22 July 2009 (UTC)

PurpleSkank 1A420 sounds great to me! --[[User:Posixninja|posixninja]] 04:03, 22 July 2009 (UTC)

Actually the file /private/var/db/dyld/update-prebinding-paths.txt begins with # Alpine1A420. So could this release be called Alpine ? In current firmwares the root pw is alpine, but it used to be dottie afaik. --[[User:M2m|M2m]] 11:13, 22 July 2009 (UTC)

weird, never seen that. honestly I still like PurpleSkank more. --[[User:Posixninja|posixninja]] 17:29, 22 July 2009 (UTC)

I checked /private/var/db/dyld/update-prebinding-paths.txt of FW 1.1.4 - begins with ''# LittleBear4A102''. I checked 1.0.1 and it begins with ''# SUHeavenlyJuly1C25''. So I think the official name of this FW is ''Alpine 1A420''. --[[User:M2m|M2m]] 12:59, 23 July 2009 (UTC)

The password to the root account is and has always been alpine, and the password to the mobile account is and has always been dottie (there was a mobile account even before Apple began running apps under it) [[User:AriX|AriX]] 15:33, 24 July 2009 (UTC)

== Boot the Kernel? ==

None of the kernel or kernelcache files is 8900 packed/encrypted. So the kernel refuses to boot on my 2G iPhone. Any Ideas ? --[[User:M2m|M2m]] 13:11, 23 July 2009 (UTC)

does the iboot from it even require it to be packed/encrypted? I wasn't around in the 8900 days, but I'm pretty sure the framework is still there in xpwn to pack 8900 files if you want to hack something together. --[[User:Posixninja|posixninja]] 14:27, 23 July 2009 (UTC)

I don't have the iboot from the Prototype. At least not as an iboot file. Maybe it could be extracted from the NOR Dump.. who know. Will have a look at xpwn. Maybe I can find a 8900 packer/encryptor there --[[User:M2m|M2m]] 02:59, 24 July 2009 (UTC)

M2m, If you still need help dumping anything or figuring stuff out. geohot@gmail I'll be around at 5:30 EST tonight --[[User:Geohot|geohot]] 14:07, 24 July 2009 (UTC)

I have not even tried to go as far as booting the kernel, because 1.1.4 is mostly compatible with SkankPhone and stuff... I've copied over a lot of the stuff from the prototype FW and it works pretty well. At some point maybe I'll get my act together and see if I can flash the NOR and stuff, but SkankPhone is cool enough for me :p (Mine is currently set up as a dual boot system where one partition is the 1.1.4/Prototype fw, and the other partition is a plain 1.1.4 partition... I wonder if I could set it up to dual boot 3.0 instead? It wouldn't really work with iTunes easily.) [[User:AriX|AriX]] 15:36, 24 July 2009 (UTC)

Talk:Alpine 1A420

2009-07-24T15:37:21Z

AriX: /* Boot the Kernel? */

Talk:Alpine 1A420

2009-07-24T15:36:34Z

AriX: /* Boot the Kernel? */

Talk:Alpine 1A420

2009-07-24T15:33:49Z

AriX: /* Revision Name? */

Normal Mode

2009-07-18T20:33:44Z

AriX:

This is the protocol [[iTunes]] uses to talk to the booted iPhone. It uses usbmux to provide TCP like connectivity over a USB port using SSL. There is a pairing process iTunes uses to establish the secure channel. File transfer is provided by [[AFC]].

==Device IDs==
It appears that it uses different device IDs:
* [[iPhone]] - 0x1290
* [[iPod touch]] - 0x1291
* [[iPhone 3G]] - 0x1292
* [[iPod touch 2G]] - 0x1293
* [[iPhone 3Gs]] - 0x1294
* [[iPod touch 3G]] - 0x1295 (likely)

==Patch: Disable SSL==
There is a way to disable SSL encyption during iTunes communication on jailbroken devices by patching lockdownd binary:

:(#) Disable SSL protection
:(#) FW 2.1
:(#) binary /usr/libexec/lockdownd
:-0x1000
'''Offset''' 000112F8: 0C 30 98 E5 > 00 30 A0 E3 ; Conn.UseSSL = false

After applying the patch all packets between iPhone and iTunes become plain and clear. Musthave for R&D ppl.
==USBMux Protocol==

===Resources===
* [[MobileDevice Library]]
* [http://wikee.iphwn.org/usb:usbmux The dev team's page on the topic]
* [http://matt.colyer.name/projects/iphone-linux/index.php?title=Protocol_Documentation Protocol Documentation]
* [http://matt.colyer.name/projects/iphone-linux/index.php?title=Main_Page iFuse]

[[Category:Protocols (S5L)]]

AFC

2009-07-18T20:33:22Z

AriX:

AFC is a service that runs on every iPhone / iPod, which iTunes uses to exchange files with the device. It is jailed to the directory /private/var/mobile/Media, which is on the second (non-OS) partition. The AFC service is handled by /usr/libexec/afcd, and runs over the [[Normal Mode|usbmux protocol]].

=== AFC2 ===
AFC2 is a an additional AFC service, configured to allow access to the whole filesystem. Installing it and patching the fstab file for full write access is considered a bare-bones [[jailbreak]]. The AFC2 service is added by editing the /System/Library/Lockdown/Services.plist file and adding a service that runs under root with access to /.

AFC

2009-07-18T20:28:10Z

AriX:

AFC is a service that runs on every iPhone / iPod, which iTunes uses to exchange files with the device. It is jailed to the directory /private/var/mobile/Media, which is on the second (non-OS) partition. The afc service is handled by /usr/libexec/afcd.

=== AFC2 ===
AFC2 is a an additional AFC service, configured to allow access to the whole filesystem. Installing it and patching the fstab file for full write access is considered a bare-bones [[jailbreak]]. The AFC2 service is added by editing the /System/Library/Lockdown/Services.plist file and adding a service that runs under root with access to /.

IPSW File Format

2009-07-18T19:39:37Z

AriX: /* IPSW Contents */

'''IPSW''' (guess '''IP'''hone/ '''IP'''od '''S'''oft'''W'''are) Files have the Magic Number 504B0304 (PK\003\004) and thus are [http://en.wikipedia.org/wiki/ZIP_%28file_format%29 ZIP] Archives. They can be modified with typical zip/unzip tools (i.e. change extension to .zip and double click). An IPSW File is used to deliver the iPod Touch / iPhone [[firmware]] to the end-user.

== IPSW Contents ==

=== root folder ===
*[[Restore Ramdisk]]
*[[Update Ramdisk]] (Firmware 1.0 didn't contain an Update Ramdisk as there is no official firmware to update from)
*[[Disk Image Formats|Filesystem Ramdisk]] (the largest .dmg file)
*kernelcache.release.XXXXXXX file (application processor specific i.e [[S5L8900]], [[S5L8920]], [[S5L8720]])
*BuildManifest.plist (first appeared in firmware 3.0, I guess)
*Restore.plist file

*\Firmware (Folder)

=== Firmware Folder ===
*\all_flash\all_flash.XXXXX.production (Folder - hardware specific i.e. [[M68ap]], [[N82ap]], [[N88ap]], [[N45ap]], [[N72ap]])
*\dfu (Folder)

=== all_flash.XXXXX.production Folder ===
*img2/img3 files
*manifest

=== dfu Folder ===
*iBEC.XXXXX.DFU (hardware specific i.e. [[M68ap]], [[N82ap]], [[N88ap]], [[N45ap]], [[N72ap]])
*iBSS.XXXXX.DFU (hardware specific i.e. [[M68ap]], [[N82ap]], [[N88ap]], [[N45ap]], [[N72ap]])
*WTF.XXXXX.DFU (hardware specific i.e. [[M68ap]], [[N82ap]], [[N45ap]], [[N72ap]] - currently not present in the iPhone 3Gs firmware, because it is mostly used to patch issues with the DFU mode that was burned into the bootrom)

== Example ==
This is a ls -alR of an extracted iPhone 3GS Firmware ipsw.

<pre>total 608400
drwx------@ 11 m staff 374 17 Jun 07:11 .
drwxrwxrwx 5 m staff 170 18 Jul 07:34 ..
-rw-r--r--@ 1 m admin 281214976 22 Mai 17:10 018-5302-002.dmg
-rw-r--r--@ 1 m admin 12769604 22 Mai 16:59 018-5304-002.dmg
-rw-r--r--@ 1 m admin 12777796 22 Mai 16:59 018-5306-002.dmg
-rw-r--r-- 1 m admin 21097 22 Mai 17:29 BuildManifest.plist
drwxr-xr-x@ 5 m staff 170 17 Jun 07:11 Firmware
-rw-r--r-- 1 m admin 1763 22 Mai 17:10 Restore.plist
-rw-r--r--@ 1 m staff 4695492 22 Mai 14:32 kernelcache.release.s5l8920x

./Firmware:
total 16
drwxr-xr-x@ 5 m staff 170 17 Jun 07:11 .
drwx------@ 11 m staff 374 17 Jun 07:11 ..
drwxr-xr-x@ 4 m staff 136 18 Jun 02:10 all_flash
drwxr-xr-x@ 4 m staff 136 22 Mai 13:39 dfu

./Firmware/all_flash:
total 16
drwxr-xr-x@ 4 m staff 136 18 Jun 02:10 .
drwxr-xr-x@ 5 m staff 170 17 Jun 07:11 ..
drwxr-xr-x@ 16 m staff 544 22 Mai 13:43 all_flash.n88ap.production

./Firmware/all_flash/all_flash.n88ap.production:
total 1320
drwxr-xr-x@ 16 m staff 544 22 Mai 13:43 .
drwxr-xr-x@ 4 m staff 136 18 Jun 02:10 ..
-rw-r--r--@ 1 m staff 44996 22 Mai 13:08 DeviceTree.n88ap.img3
-rw-r--r--@ 1 m staff 67908 22 Mai 13:12 LLB.n88ap.RELEASE.img3
-rw-r--r--@ 1 m staff 9604 22 Mai 13:15 applelogo.s5l8920x.img3
-rw-r--r--@ 1 m staff 19716 22 Mai 13:15 batterycharging0.s5l8920x.img3
-rw-r--r--@ 1 m staff 24900 22 Mai 13:16 batterycharging1.s5l8920x.img3
-rw-r--r--@ 1 m staff 76100 22 Mai 13:16 batteryfull.s5l8920x.img3
-rw-r--r--@ 1 m staff 56772 22 Mai 13:16 batterylow0.s5l8920x.img3
-rw-r--r--@ 1 m staff 65348 22 Mai 13:17 batterylow1.s5l8920x.img3
-rw-r--r--@ 1 m staff 20356 22 Mai 13:17 glyphcharging.s5l8920x.img3
-rw-r--r--@ 1 m staff 19332 22 Mai 13:18 glyphplugin.s5l8920x.img3
-rw-r--r--@ 1 m staff 178500 22 Mai 13:21 iBoot.n88ap.RELEASE.img3
-rw-r--r--@ 1 m staff 341 22 Mai 13:43 manifest
-rw-r--r--@ 1 m staff 20484 22 Mai 13:24 needservice.s5l8920x.img3
-rw-r--r--@ 1 m staff 47876 22 Mai 13:24 recoverymode.s5l8920x.img3

./Firmware/dfu:
total 416
drwxr-xr-x@ 4 m staff 136 22 Mai 13:39 .
drwxr-xr-x@ 5 m staff 170 17 Jun 07:11 ..
-rw-r--r--@ 1 m staff 104772 22 Mai 13:30 iBEC.n88ap.RELEASE.dfu
-rw-r--r--@ 1 m staff 104772 22 Mai 13:36 iBSS.n88ap.RELEASE.dfu
</pre>

AFC

2009-07-18T19:30:53Z

AriX:

AFC is a service (run by afcd) running on every iPhone / iPod, which iTunes uses to send files to the device. It is locked in the /var/mobile/media jail.

=== AFC2 ===
AFC2 is a an additional AFC service, configured to allow access to the whole filesystem. Installing it and patching the fstab file for full write access is considered a bare-bones [[jailbreak]]. The AFC2 service is added by editing the /System/Library/Lockdown/Services.plist file and adding a service that runs under root with access to /.

Jailbreak

2009-07-18T19:26:55Z

AriX:

This is the process by which full execute and write access is obtained on all the partitions of the iPhone. It is done by patching /etc/fstab to mount the System partition as read-write. This is entirely different from an [[unlock]]. Jailbreaking is the first action that must be taken before things like unofficial [[activation]] (hactivation), and unofficial unlocking can be applied.

The original jailbreak also included modifying the [[AFC|afc]] service (used by [[iTunes]] to access the filesystem) to give full filesystem access from root. This was later updated to create a new service (afc2) that allows access to the full filesystem.

Modern jailbreaks also include patching the kernel to get around code signing and other restrictions.

==Exploits which were used in order to jailbreak (in chronological order)==
=== 1.0.2 ===
* [[Restore Mode]] (iBoot had a command named cp, which had access to the whole filesystem)
=== 1.1.1 ===
* [[Symlinks]] (an upgrade jailbreak)
* [[LibTiff | libtiff exploit]] (Adapted from the PSP scene, used by [[Jailbreakme]])
=== 1.1.2 ===
* [[Mknod]] (an upgrade jailbreak)
=== 1.1.3 / 1.1.4 ===
* [[Soft Upgrade]] (an upgrade jailbreak)
* [[Ramdisk Hack]]

==Exploits which are used in order to jailbreak 2.0 and above==
===iPhone / iPhone 3G / iPod Touch===
* [[Pwnage]] and [[Pwnage 2.0]] (together)
===iPod Touch 2G===
* [[ARM7 Go]] (used by tethered jailbreaks)
* [[24kpwn]]
===iPhone 3GS===
* [[iBoot Environment Variable Overflow]] (also uses the [[24kpwn]] exploit to make it untethered)

Jailbreak

2009-07-18T19:24:34Z

AriX: /* Exploits which are used in order to jailbreak 2.0 and above */ iBoot exploit would be necessary anyway :p

This is the process by which full execute and write access is obtained on all the partitions of the iPhone. It is done by patching /etc/fstab to mount the System partition as read-write. This is entirely different to an [[unlock]]. Jailbreaking is the first action that must be taken before things like non-official [[activation]], and non-official unlocking, can proceed.

The original jailbreak also included modifying the [[AFC|afc]] service (service used by [[iTunes]] to access the filesystem) to give full filesystem access from root. This was later updated to creating a new service (afc2) that allows access to the full filesystem.

Modern jailbreaks also include patching the OS kernel to get around code-signing and other restrictions.

==Exploits which were used in order to jailbreak (in chronological order)==
=== 1.0.2 ===
* [[Restore Mode]] (iBoot had a command named cp, which had access to the whole filesystem)
=== 1.1.1 ===
* [[Symlinks]] (an upgrade jailbreak)
* [[LibTiff | libtiff exploit]] (Adapted from the PSP scene, used by [[Jailbreakme]])
=== 1.1.2 ===
* [[Mknod]] (an upgrade jailbreak)
=== 1.1.3 / 1.1.4 ===
* [[Soft Upgrade]] (an upgrade jailbreak)
* [[Ramdisk Hack]]

==Exploits which are used in order to jailbreak 2.0 and above==
===iPhone / iPhone 3G / iPod Touch===
* [[Pwnage]] and [[Pwnage 2.0]] (together)
===iPod Touch 2G===
* [[ARM7 Go]] (used by tethered jailbreaks)
* [[24kpwn]]
===iPhone 3GS===
* [[iBoot Environment Variable Overflow]] (also uses the [[24kpwn]] exploit to make it untethered)

Jailbreak

2009-07-18T19:23:55Z

AriX: /* Exploits which are used in order to jailbreak 2.0 and above */

This is the process by which full execute and write access is obtained on all the partitions of the iPhone. It is done by patching /etc/fstab to mount the System partition as read-write. This is entirely different to an [[unlock]]. Jailbreaking is the first action that must be taken before things like non-official [[activation]], and non-official unlocking, can proceed.

The original jailbreak also included modifying the [[AFC|afc]] service (service used by [[iTunes]] to access the filesystem) to give full filesystem access from root. This was later updated to creating a new service (afc2) that allows access to the full filesystem.

Modern jailbreaks also include patching the OS kernel to get around code-signing and other restrictions.

==Exploits which were used in order to jailbreak (in chronological order)==
=== 1.0.2 ===
* [[Restore Mode]] (iBoot had a command named cp, which had access to the whole filesystem)
=== 1.1.1 ===
* [[Symlinks]] (an upgrade jailbreak)
* [[LibTiff | libtiff exploit]] (Adapted from the PSP scene, used by [[Jailbreakme]])
=== 1.1.2 ===
* [[Mknod]] (an upgrade jailbreak)
=== 1.1.3 / 1.1.4 ===
* [[Soft Upgrade]] (an upgrade jailbreak)
* [[Ramdisk Hack]]

==Exploits which are used in order to jailbreak 2.0 and above==
===iPhone / iPhone 3G / iPod Touch===
* [[Pwnage]] and [[Pwnage 2.0]] (together)
===iPod Touch 2G===
* [[ARM7 Go]] (used by tethered jailbreaks)
* [[24kpwn]]
===iPhone 3GS===
All jailbreaks are using the [[24kpwn]] exploit (to make it untethered), but an iBoot exploit is necessary as well because of the new [[ECID]] tag.
* [[iBoot Environment Variable Overflow]]

Jailbreak

2009-07-18T19:21:40Z

AriX: /* Exploits which were used in order to jailbreak (in chronological order) */

This is the process by which full execute and write access is obtained on all the partitions of the iPhone. It is done by patching /etc/fstab to mount the System partition as read-write. This is entirely different to an [[unlock]]. Jailbreaking is the first action that must be taken before things like non-official [[activation]], and non-official unlocking, can proceed.

The original jailbreak also included modifying the [[AFC|afc]] service (service used by [[iTunes]] to access the filesystem) to give full filesystem access from root. This was later updated to creating a new service (afc2) that allows access to the full filesystem.

Modern jailbreaks also include patching the OS kernel to get around code-signing and other restrictions.

==Exploits which were used in order to jailbreak (in chronological order)==
=== 1.0.2 ===
* [[Restore Mode]] (iBoot had a command named cp, which had access to the whole filesystem)
=== 1.1.1 ===
* [[Symlinks]] (an upgrade jailbreak)
* [[LibTiff | libtiff exploit]] (Adapted from the PSP scene, used by [[Jailbreakme]])
=== 1.1.2 ===
* [[Mknod]] (an upgrade jailbreak)
=== 1.1.3 / 1.1.4 ===
* [[Soft Upgrade]] (an upgrade jailbreak)
* [[Ramdisk Hack]]

==Exploits which are used in order to jailbreak 2.0 and above==
===iPhone / iPhone 3G / iPod Touch===
* [[Pwnage]] and [[Pwnage 2.0]] (together)
===iPod Touch 2G===
* [[ARM7 Go]] (used by tethered jailbreaks)
* [[24kpwn]]
===iPhone 3GS===
All jailbreaks are using the [[24kpwn]] exploit, but you need an iBoot exploit as well because of [[ECID]].
====3.0====
* [[iBoot Environment Variable Overflow]]

S5L File Formats

2009-07-18T19:19:42Z

AriX: /* 8900 */

==IMG2==
This was the file format used prior to 2.0 firmware. Post 1.1.1, it was encrypted with [[Key 0x837]]. It can only be parsed by an iBoot in a firmware version less than beta 3, or the [[S5L8900]] [[VROM]]. The [[S5L8720]] has no support for it.

==8900==

This is the file format used by the [[S5L8900]]. Usually this wraps around an [[IMG2 File Format|IMG2]] file. It can only be parsed by an iBoot in a firmware version less than 2.0 beta 3, or the [[S5L8900]] [[VROM]]. The [[S5L8720]] has no support for it.

===Header===
typedef struct {
uchar magic[4]; // string "8900"
uchar version[3]; // string "1.0"
uint8 format; // plaintext format is 0x4, encrypted with [[GID-key]] format is 0x3, boot plaintext is 0x2, boot encrypted with [[UID-key]] is 0x1.
uint32 unknown1;
uint32 sizeOfData; // size of data (ie, filesize - header(0x800) - footer signature(0x80) - footer certificate(0xC0A))
uint32 footerSignatureOffset; // offset to footer signature
uint32 footerCertOffset; // offset to footer certificate, from end of header (0x800)
uint32 footerCertLen;
uchar salt[0x20]; // a seemingly random salt (an awfully big one though... needs more attention)
uint16 unknown2;
uint16 epoch; // the security epoch of the file
uchar headerSignature[0x10]; // encrypt(sha1(header[0:0x40])[0:0x10], key_0x837, zero_iv)
uchar padding[0x7B0];
} Apple8900Header;

===Resources===
[http://wikee.iphwn.org/s5l8900:8900_format The dev team's wiki page on the topic]

==IMG3==
This is the replacement for the [[IMG2 File Format]] in 2.0 firmware. The [[VROM (S5L8720)|S5L8720 Bootrom]] can understand this by default, but [[WTF 2.0]] must be uploaded to the [[DFU]] mode of an [[S5L8900]] that has code in it to parse IMG3 files, or the [[S5L8900]] will not be able to understand them.

===Header===
struct Img3 {
unsigned int magic; // fourcc="IMG3"
unsigned int fullSize; // full size of fw image
unsigned int sizeNoPack; // size of fw image without header
unsigned int sigCheckArea; // although that is just my name for it, this is the
// size of the start of the data section (the code) up to
// the start of the RSA signature (SHSH section)
unsigned int iden; // identifier of image, used when bootrom is parsing images
// list to find LLB (illb), LLB parsing it to find iBoot (ibot),
// etc.

} typedef Img3;

===Tag Format===
unsigned int magic;
unsigned int total_length; //data_length+0xC
unsigned int data_length;

===Tags===
VERS: Version
SDOM: Security Domain
PROD: Processor to be used with.
CHIP: Chip to be used with. "0x8900" for [[S5L8900]] and "0x8720" for [[n72ap|S5L8720]]. Instead of there being a check against some piece of hardware, whatever is verifying this (bootrom / iBoot / LLB / etc.) has this hardcoded in.
BORD: Board to be used with
[[KBAG]]: contains the KEY and IV required to decrypt encrypted with the [[GID-key]]
SHSH: RSA encrypted SHA1 hash of the file
CERT: Certificate

===Encryption===
Apple got smarter this time, requiring the Hardware AES engine to be run per file. Decrypt the [[KBAG]] tag data (0x20 byte?) with the hardware AES engine and get the 0x10 byte IV and the 0x10 byte KEY.

iBoot has support for aes-192 and aes-256 also. In the current method, iBoot will always use the first 16 bytes as the IV, then the remaining 16 (aes-128, current method), 24 (aes-192), or 32 (aes-256) bytes for the key.

===Resources===
[http://www.iphonelinux.org/img3.tar.gz cmw's IMG3 Unpacker]

DFU Mode

2009-07-16T22:26:10Z

AriX: /* Revisions */

'''DFU''' or '''Device Firmware Upgrade''' mode allows the [[S5L8900]] and [[S5L8720]] to be restored from any state. It resides in the [[VROM]] and the [[S5L8900]] variant is vulnerable to the [[Pwnage 2.0]] exploit.

==Entering / Exitting DFU==
Software cannot be used to reliably enter DFU. Software methods rely on sending a signed WTF file which either calls the "real" DFU mode in bootrom or emulates it. Only ones calling the bootrom DFU is useful for exploiting bootrom (unpatchable) exploits and none exist that work for firmware 2.0 and later. If you are attempting to exploit the DFU, it is advisable to always use the hardware method. If your NOR firmware is corrupted, of course you have no recourse but to use the hardware method.

===How to Enter True Hardware DFU===
# Turn off the device.
# Hold Power and Home for 10 seconds
# Release Power, and keep holding Home
# Keep holding home for 4-8 seconds or until you are alerted by your computer that it has detected a device in DFU.

If the Restore Logo is present on the screen, you are in ''[[Recovery Mode]]'', '''not''' ''DFU''.

===Exiting DFU===
While in DFU, hold the power button for 30-60 seconds. When I have tested it, it has varied, so I don't know an exact length of time to hold it. Note that sometimes if you do this, when the device reboots from DFU, it will go into recovery mode for reasons unknown.

Another way to exit DFU through software is by the use of [[iRecovery]]. Load iBSS, then iBoot, and send the "fsboot" command.

==Revisions==
===[[S5L8900]] (0x1222)===
This is the device ID in the iPod Touch First Generation, the iPhone, and the iPhone 3G. For more information about the protocol, see [[DFU 0x1222]].

===[[S5L8720 Bootrom|S5L8720]], [[S5L8920]], and [[WTF|WTF mode post-2.0]] (0x1227)===
This is the device ID in the [[iPod Touch 2G]], the [[iPhone 3Gs]], and [[WTF|WTF mode]]. For more information on the protocol, see [[DFU 0x1227]].

[[Category:VROM]]

Normal Mode

2009-07-16T17:01:26Z

AriX: /* Device IDs */

This is the protocol iTunes uses to talk to the booted iPhone. It uses usbmux to provide TCP like connectivity over a USB port using SSL. There is a pairing process iTunes uses to establish the secure channel.

==Device IDs==
It appears that it uses different device IDs:
* [[iPhone]] - 0x1290
* [[iPod touch]] - 0x1291
* [[iPhone 3G]] - 0x1292
* [[iPod touch 2G]] - 0x1293
* [[iPhone 3Gs]] - 0x1294
* iPod touch 3G - 0x1295 (likely)

==Patch: Disable SSL==
There is a way to disable SSL encyption during iTunes communication on jailbroken devices by patching lockdownd binary:

:(#) Disable SSL protection
:(#) FW 2.1
:(#) binary /usr/libexec/lockdownd
:-0x1000
'''Offset''' 000112F8: 0C 30 98 E5 > 00 30 A0 E3 ; Conn.UseSSL = false

After applying the patch all packets between iPhone and iTunes become plain and clear. Musthave for R&D ppl.
==USBMux Protocol==

===Resources===
* [[MobileDevice Library]]
* [http://wikee.iphwn.org/usb:usbmux The dev team's page on the topic]
* [http://matt.colyer.name/projects/iphone-linux/index.php?title=Protocol_Documentation Protocol Documentation]
* [http://matt.colyer.name/projects/iphone-linux/index.php?title=Main_Page iFuse]

[[Category:Protocols (S5L)]]

Disk Image Formats

2009-07-16T16:57:05Z

AriX:

iPhone [[Firmware]] (ipsw) files contain three disk image (.dmg) files in addition to the img3 images for the [[NOR]] and on older models, unencrypted files for the [[Restore Process|restore process]]. The three disk images are the [[Update Ramdisk|update ramdisk]], the [[Restore Ramdisk|restore ramdisk]], and the main [[filesystem]].

The main filesystem .dmg disk image (the largest .dmg file) is [[VFDecrypt_Keys|decrypted]] to an UDZO .dmg disk image.

== UDZO Image Format ==

The UDZO Image is an UDIF zlib-compressed read-only image which can be mounted on Mac OSX.
UDZO Images can be converted to read/write UDRW Images with [http://developer.apple.com/documentation/Darwin/Reference/Manpages/man1/hdiutil.1.html hdiutil] on Mac OSX:

<pre>hdiutil convert -format UDRW udzo.dmg -o udrw.dmg</pre>

To add checksums of the data in the provided UDZO Image and store them in the image [http://developer.apple.com/documentation/Darwin/Reference/ManPages/man8/asr.8.html asr] on Mac OSX can be used:

<pre>asr -imagescan udzo.dmg</pre>

== UDRW Image Format ==

The UDRW Image is an UDIF read/write image which can be mounted on Mac OSX.
UDRW Images can be converted to zlib-compressed read-only UDZO Images with [http://developer.apple.com/documentation/Darwin/Reference/Manpages/man1/hdiutil.1.html hdiutil] on Mac OSX:

<pre>hdiutil convert -format UDZO udrw.dmg -o udzo.dmg</pre>

Timeline

2009-07-16T00:55:48Z

AriX: /* October */

==2009==

===July===
* July 14 -- [[Geohot]] releases [[purplesn0w]], a software unlock for the [[iPhone 3GS]] using [[AT+XLOG Vulnerability|the same exploit as ultrasn0w]], but handled differently. Minutes later, an explanation and source code was posted.
* July 7 -- [[The dev team]] updates [[redsn0w]] and [[ultrasn0w]] to version 0.8, now with [[iPhone 3GS]] support. Saurik also updates Winterboard to support the [[iPhone 3GS]].
* July 3 -- [[Geohot]] releases [[purplera1n]], a software jailbreak for the [[iPhone 3GS]].

===June===
* June 28 -- [[Geohot]] posts pictures on his blog of the first fully jailbroken [[iPhone 3GS]].
* June 25 -- It's discovered that [[iPhone 3GS]] is vulnerable to [[0x24000 Segment Overflow|24kpwn]] exploit.
* June 24 -- [[The dev team]] release [[ultrasn0w]] unlock for [[iPhone 3G]] thanks to [[AT+XLOG Vulnerability|a new exploit]] discovered by [[User:Oranav|Oranav]].
* June 23 -- [[Geohot]] announces he's found a new exploit in [[iBoot]] he calls purplera1n.
* June 19 -- Release of [[iPhone2,1|iPhone 3GS]] to the public.
* June 17 -- Release of firmware 3.0 to the public.
* June 8 -- Apple announces the [[iPhone2,1|iPhone 3GS]].

===March===
* March 10 -- The [[0x24000 Segment Overflow|untethered jailbreak]] for the [[iPod touch 2G]] is released thanks to the combined work of chronic, CPICH, posixninja, pod2g, ius, planetbeing, MuscleNerd, and co.

===January===
* January 31 -- [[The dev team]] released a "lite" version of [[RedSn0w]], a tethered jailbreak for the [[iPod touch 2G]]. It combines the [[ARM7 Go]] exploit with the well-established pwnage flow for other Apple mobile devices. It is bundled in a way that will allow usage on the 2.2.1 firmware.

* January 25 -- [[0wnboot]] is released to chronicdev google code page, thanks to AriX, chronic, CPICH, westbaer, ius, pod2g, the rest of the iPod devel crew on IRC, and to the #iphone-hax lab rats. Within days, the AriX and the chronic dev team got a ramdisk booting for a tethered jailbreak.

* January 17 -- [[The dev team]] [http://twitter.com/MuscleNerd/status/1127346766 shows a video demo] of the first jailbroken iPod Touch 2G. This tethered jailbreak is released 2 weeks later.

* January 16 -- [[ARM7 Go]] hole disclosed where else but here on The iPhone Wiki, for developers to poke and prod at

* January 15 -- [[The dev team]] [http://twitter.com/iphone_dev/status/1120595069 tweets the vfdecrypt key] for the [[iPod touch 2G]] 2.2 firmware, demonstrating for the first time that unsigned code can now be run on that device.

* January 1 -- [[The dev team]] releases [[yellowsn0w]] 0.9 beta for baseband 02.28.00.

==2008==

===December===
* December 21 -- [[MuscleNerd]], of [[the dev team]] does a live demo of the 3G unlock, dubbed as 'yellowsn0w': http://qik.com/video/729275

===August===
* August 18 -- [[The dev team]] releases [http://wikee.iphwn.org/news:pwnage20announcement QuickPwn], a 2.x [[pwnage]]/ramdisk combination exploit that allows jailbreaking without needing to create custom IPSWs.

===July===
* July 22 -- [[TA_Mobile]] hardware dumps the 3G baseband (bootloader 5.8 & FW 1.45.00) by desoldering the [[NOR]].
* July 19 -- [[The dev team]] releases [[PwnageTool]] 2.0, jailbreaking and unlocking the 2.0 software on the iPhone 2G and jailbreaking the 2.0 software on the iPhone 3G.
* July 11 -- [[iPhone 3G]] is released.

===June===
* June 9 - [[iPhone 3G]] is announced at [[WWDC]] '08.

===April===
* April 3 -- Dev team releases [[PwnageTool]] 1.0, making use of the pmdx exploit (to patch RSA checks out of the [[kernel]], to write unsigned to [[NOR]])

===March===
* March 12 -- Dev team releases dual-boot jailbreak method, only to be silently fixed in 2.0.
* March 4 -- [[User:N000b|George Zhu (n000b)]] releases [[ILiberty / ILiberty%2B]].

===February===
* February 28 -- [[Cydia]] is released as an open-source alternative to Installer.app, and prepares to take over the jailbreak application scene upon 2.0's release.
* February 11 -- [[Zibri]] releases [[ZiPhone]], the first all-in-one unlock, activate, jailbreak solution.
* February 8 -- [[User:Geohot|geohot]] releases software unlock for 4.6, Apple states 25% of phones were never activated with AT&T.

===January===
* January 28 -- Dev team releases soft upgrade jailbreak for 1.1.3.
* January 18 -- Geohot and his friends [http://iphonejtag.blogspot.com/2008/01/112-otb-unlocked.html unlocked 1.1.2 OTB 4.6 by test point], the unbeatable version at that time.
* January 18 -- Dev team posts YouTube video of a jailbroken 1.1.3, which was made possible by the dual boot jailbreak from bgm.

== 2007 ==
===November===
* November 15 -- New baseband [[Bootloader 4.6|bootloader (4.6)]] comes out, new iPhones can't be unlocked.
* November 2 -- [[Jailbreakme]] is released, bringing jailbreaking to the mainstream iPhone user.

===October===
* October 23 -- iPhone-Elite Team releases the [[Virginizer]].
* October 14 -- AriX releases iJailBreak, the first automated iPod touch jailbreak for the Mac.
* October 12 -- planetbeing releases touchFree, the first automated iPod touch jailbreak.
* October 10 -- niacin, cmw, and dre release the [[LibTiff]] exploit to jailbreak the iPod touch, which is later adapted for use in [[Jailbreakme]].

===September===
* September 11 -- [[The dev team]] releases [[iUnlock]], first free software unlock.
* September 10 -- [[IPSF]] releases first paid software unlock.
* September 9 -- Apple announces the [[iPod touch]] at a media event.

===August===
* August 23 -- [[User:Geohot|geohot]] and team release [[hardware unlock]] method.
* August 21 -- Installer.app is released by Nullriver, first GUI apps are distributed.

===July===
* July 23 -- First phones are used with other carriers by means of [[SIM hacks]].
* July 20 -- nightwatch adapts a [[toolchain]] to the iPhone. The first apps are compiled.
* July 9 -- [[The dev team]] releases a [[jailbreak]] method. The first use of this is ringtones.
* July 3 -- DVD Jon first cracks [[activation]]. People can use the apps on the phone without a subscription.

===June===
* June 29 -- [[iPhone]] is released. World's most hyped consumer product.

S5L8900

2009-07-16T00:54:53Z

AriX: /* Exploits */ RIP purplera1n

This is the Application Processor shared between the [[iPhone]], [[N45ap|iPod touch]], and the [[iPhone 3G]]. Not much is known about it through official sources. This processor is not used in any of the current devices, being replaced by the [[S5L8720]] and [[S5L8920]].

==Firmware File Formats==
See [[S5L File Formats|this page]] for more information on the types of firmware files it interprets

==Exploits==
===[[System|Userland]]===
* [[Restore Mode]] - Firmware v1.0.2 and below
* [[symlinks|Symlinks]] - Firmware v1.1.1 and below
* [[LibTiff|LibTIFF]] - Firmware v1.1.1 and below
* [[Mknod]] - Firmware v1.1.2 and below
* [[Dual Boot Exploit]] - Firmware 1.1.4 / v2.0b3 and below

===[[iBoot]] / [[Kernel]]===
* [[Ramdisk Hack|Ramdisk Exploit]] - Firmware v1.1.4 / v2.0b3 and below
* [[diags|Diags Exploit]] - Firmware v1.1.4 / v2.0b5 and below
* [[iBoot Environment Variable Overflow]] - Firmware 3.1b2 and below

===[[VROM (S5L8900)|Bootrom]]===
* [[pwnage|Pwnage 1.0 (Ramdisk + AppleImage2NORAccess)]]
* [[pwnage 2.0|Pwnage 2.0 (DFU + Malformed Certificate)]]

==Boot Chain==
[[VROM]]->[[LLB]]->[[iBoot]]->[[Kernel]]->[[System|System Software]]

One of the [[iPhoneLinux]] goals are to replace that Boot Chain after iBoot : 
[[VROM]]->OpeniBoot->Linux Kernel->X Server->Window Manager

==Upgrade Process==

=== Restore mode ===
The common upgrade process chain is [[VROM]]->[[DFU]]->[[WTF]]->[[iBoot]]->[[Kernel]]->[[Ramdisk]]->[[Restore Mode|Restore]], also called [[Restore Mode|restore mode]].

== DFU mode ==
See full article [[DFU|here]]. To flash an older version of the iPhone software you have to let your phone reside in [[DFU]]. In iTunes you have to press the Alt-Key (Mac) or the shift-key (Windows) when pressing 'Restore' to be able to manually chose an update file (ipsw file).

=== Boot Chain ===
[[VROM]]-->[[DFU]]

Timeline

2009-07-16T00:51:49Z

AriX: /* 2009 */ No one other than us (and the iPhone dev team) jailbroke it when we released 0wnboot

==2009==

===July===
* July 14 -- [[Geohot]] releases [[purplesn0w]], a software unlock for the [[iPhone 3GS]] using [[AT+XLOG Vulnerability|the same exploit as ultrasn0w]], but handled differently. Minutes later, an explanation and source code was posted.
* July 7 -- [[The dev team]] updates [[redsn0w]] and [[ultrasn0w]] to version 0.8, now with [[iPhone 3GS]] support. Saurik also updates Winterboard to support the [[iPhone 3GS]].
* July 3 -- [[Geohot]] releases [[purplera1n]], a software jailbreak for the [[iPhone 3GS]].

===June===
* June 28 -- [[Geohot]] posts pictures on his blog of the first fully jailbroken [[iPhone 3GS]].
* June 25 -- It's discovered that [[iPhone 3GS]] is vulnerable to [[0x24000 Segment Overflow|24kpwn]] exploit.
* June 24 -- [[The dev team]] release [[ultrasn0w]] unlock for [[iPhone 3G]] thanks to [[AT+XLOG Vulnerability|a new exploit]] discovered by [[User:Oranav|Oranav]].
* June 23 -- [[Geohot]] announces he's found a new exploit in [[iBoot]] he calls purplera1n.
* June 19 -- Release of [[iPhone2,1|iPhone 3GS]] to the public.
* June 17 -- Release of firmware 3.0 to the public.
* June 8 -- Apple announces the [[iPhone2,1|iPhone 3GS]].

===March===
* March 10 -- The [[0x24000 Segment Overflow|untethered jailbreak]] for the [[iPod touch 2G]] is released thanks to the combined work of chronic, CPICH, posixninja, pod2g, ius, planetbeing, MuscleNerd, and co.

===January===
* January 31 -- [[The dev team]] released a "lite" version of [[RedSn0w]], a tethered jailbreak for the [[iPod touch 2G]]. It combines the [[ARM7 Go]] exploit with the well-established pwnage flow for other Apple mobile devices. It is bundled in a way that will allow usage on the 2.2.1 firmware.

* January 25 -- [[0wnboot]] is released to chronicdev google code page, thanks to AriX, chronic, CPICH, westbaer, ius, pod2g, the rest of the iPod devel crew on IRC, and to the #iphone-hax lab rats. Within days, the AriX and the chronic dev team got a ramdisk booting for a tethered jailbreak.

* January 17 -- [[The dev team]] [http://twitter.com/MuscleNerd/status/1127346766 shows a video demo] of the first jailbroken iPod Touch 2G. This tethered jailbreak is released 2 weeks later.

* January 16 -- [[ARM7 Go]] hole disclosed where else but here on The iPhone Wiki, for developers to poke and prod at

* January 15 -- [[The dev team]] [http://twitter.com/iphone_dev/status/1120595069 tweets the vfdecrypt key] for the [[iPod touch 2G]] 2.2 firmware, demonstrating for the first time that unsigned code can now be run on that device.

* January 1 -- [[The dev team]] releases [[yellowsn0w]] 0.9 beta for baseband 02.28.00.

==2008==

===December===
* December 21 -- [[MuscleNerd]], of [[the dev team]] does a live demo of the 3G unlock, dubbed as 'yellowsn0w': http://qik.com/video/729275

===August===
* August 18 -- [[The dev team]] releases [http://wikee.iphwn.org/news:pwnage20announcement QuickPwn], a 2.x [[pwnage]]/ramdisk combination exploit that allows jailbreaking without needing to create custom IPSWs.

===July===
* July 22 -- [[TA_Mobile]] hardware dumps the 3G baseband (bootloader 5.8 & FW 1.45.00) by desoldering the [[NOR]].
* July 19 -- [[The dev team]] releases [[PwnageTool]] 2.0, jailbreaking and unlocking the 2.0 software on the iPhone 2G and jailbreaking the 2.0 software on the iPhone 3G.
* July 11 -- [[iPhone 3G]] is released.

===June===
* June 9 - [[iPhone 3G]] is announced at [[WWDC]] '08.

===April===
* April 3 -- Dev team releases [[PwnageTool]] 1.0, making use of the pmdx exploit (to patch RSA checks out of the [[kernel]], to write unsigned to [[NOR]])

===March===
* March 12 -- Dev team releases dual-boot jailbreak method, only to be silently fixed in 2.0.
* March 4 -- [[User:N000b|George Zhu (n000b)]] releases [[ILiberty / ILiberty%2B]].

===February===
* February 28 -- [[Cydia]] is released as an open-source alternative to Installer.app, and prepares to take over the jailbreak application scene upon 2.0's release.
* February 11 -- [[Zibri]] releases [[ZiPhone]], the first all-in-one unlock, activate, jailbreak solution.
* February 8 -- [[User:Geohot|geohot]] releases software unlock for 4.6, Apple states 25% of phones were never activated with AT&T.

===January===
* January 28 -- Dev team releases soft upgrade jailbreak for 1.1.3.
* January 18 -- Geohot and his friends [http://iphonejtag.blogspot.com/2008/01/112-otb-unlocked.html unlocked 1.1.2 OTB 4.6 by test point], the unbeatable version at that time.
* January 18 -- Dev team posts YouTube video of a jailbroken 1.1.3, which was made possible by the dual boot jailbreak from bgm.

== 2007 ==
===November===
* November 15 -- New baseband [[Bootloader 4.6|bootloader (4.6)]] comes out, new iPhones can't be unlocked.
* November 2 -- [[Jailbreakme]] is released, bringing jailbreaking to the mainstream iPhone user.

===October===
* October 23 -- iPhone-Elite Team releases the [[Virginizer]].
* October 14 -- AriX releases iJailBreak, the first automated iPod touch jailbreak for the Mac.
* October 12 -- planetbeing releases touchFree, the first automated iPod touch jailbreak.
* October 10 -- niacin, cmw, and dre release the [[TIFF exploit]] to jailbreak the iPod touch, which is later adapted for use in [[Jailbreakme]].

===September===
* September 11 -- [[The dev team]] releases [[iUnlock]], first free software unlock.
* September 10 -- [[IPSF]] releases first paid software unlock.
* September 9 -- Apple announces the [[iPod touch]] at a media event.

===August===
* August 23 -- [[User:Geohot|geohot]] and team release [[hardware unlock]] method.
* August 21 -- Installer.app is released by Nullriver, first GUI apps are distributed.

===July===
* July 23 -- First phones are used with other carriers by means of [[SIM hacks]].
* July 20 -- nightwatch adapts a [[toolchain]] to the iPhone. The first apps are compiled.
* July 9 -- [[The dev team]] releases a [[jailbreak]] method. The first use of this is ringtones.
* July 3 -- DVD Jon first cracks [[activation]]. People can use the apps on the phone without a subscription.

===June===
* June 29 -- [[iPhone]] is released. World's most hyped consumer product.

Timeline

2009-07-16T00:49:51Z

AriX: Adding some stuffz

==2009==

===July===
* July 14 -- [[Geohot]] releases [[purplesn0w]], a software unlock for the [[iPhone 3GS]] using [[AT+XLOG Vulnerability|the same exploit as ultrasn0w]], but handled differently. Minutes later, an explanation and source code was posted.
* July 7 -- [[The dev team]] updates [[redsn0w]] and [[ultrasn0w]] to version 0.8, now with [[iPhone 3GS]] support. Saurik also updates Winterboard to support the [[iPhone 3GS]].
* July 3 -- [[Geohot]] releases [[purplera1n]], a software jailbreak for the [[iPhone 3GS]].

===June===
* June 28 -- [[Geohot]] posts pictures on his blog of the first fully jailbroken [[iPhone 3GS]].
* June 25 -- It's discovered that [[iPhone 3GS]] is vulnerable to [[0x24000 Segment Overflow|24kpwn]] exploit.
* June 24 -- [[The dev team]] release [[ultrasn0w]] unlock for [[iPhone 3G]] thanks to [[AT+XLOG Vulnerability|a new exploit]] discovered by [[User:Oranav|Oranav]].
* June 23 -- [[Geohot]] announces he's found a new exploit in [[iBoot]] he calls purplera1n.
* June 19 -- Release of [[iPhone2,1|iPhone 3GS]] to the public.
* June 17 -- Release of firmware 3.0 to the public.
* June 8 -- Apple announces the [[iPhone2,1|iPhone 3GS]].

===March===
* March 10 -- The [[0x24000 Segment Overflow|untethered jailbreak]] for the [[iPod touch 2G]] is released thanks to the combined work of chronic, CPICH, posixninja, pod2g, ius, planetbeing, MuscleNerd, and co.

===January===
* January 31 -- [[The dev team]] released a "lite" version of [[RedSn0w]], a tethered jailbreak for the [[iPod touch 2G]]. It combines the [[ARM7 Go]] exploit with the well-established pwnage flow for other Apple mobile devices. It is bundled in a way that will allow usage on the 2.2.1 firmware.

* January 25 -- [[0wnboot]] is released to chronicdev google code page, thanks to AriX, chronic, CPICH, westbaer, ius, pod2g, the rest of the iPod devel crew on IRC, and to the #iphone-hax lab rats. In effect, within days AriX got a ramdisk booting and / or a pwnage bundle created and working.

* January 17 -- [[The dev team]] [http://twitter.com/MuscleNerd/status/1127346766 shows a video demo] of the first jailbroken iPod Touch 2G. This tethered jailbreak is released 2 weeks later.

* January 16 -- [[ARM7 Go]] hole disclosed where else but here on The iPhone Wiki, for developers to poke and prod at

* January 15 -- [[The dev team]] [http://twitter.com/iphone_dev/status/1120595069 tweets the vfdecrypt key] for the [[iPod touch 2G]] 2.2 firmware, demonstrating for the first time that unsigned code can now be run on that device.

* January 1 -- [[The dev team]] releases [[yellowsn0w]] 0.9 beta for baseband 02.28.00.

==2008==

===December===
* December 21 -- [[MuscleNerd]], of [[the dev team]] does a live demo of the 3G unlock, dubbed as 'yellowsn0w': http://qik.com/video/729275

===August===
* August 18 -- [[The dev team]] releases [http://wikee.iphwn.org/news:pwnage20announcement QuickPwn], a 2.x [[pwnage]]/ramdisk combination exploit that allows jailbreaking without needing to create custom IPSWs.

===July===
* July 22 -- [[TA_Mobile]] hardware dumps the 3G baseband (bootloader 5.8 & FW 1.45.00) by desoldering the [[NOR]].
* July 19 -- [[The dev team]] releases [[PwnageTool]] 2.0, jailbreaking and unlocking the 2.0 software on the iPhone 2G and jailbreaking the 2.0 software on the iPhone 3G.
* July 11 -- [[iPhone 3G]] is released.

===June===
* June 9 - [[iPhone 3G]] is announced at [[WWDC]] '08.

===April===
* April 3 -- Dev team releases [[PwnageTool]] 1.0, making use of the pmdx exploit (to patch RSA checks out of the [[kernel]], to write unsigned to [[NOR]])

===March===
* March 12 -- Dev team releases dual-boot jailbreak method, only to be silently fixed in 2.0.
* March 4 -- [[User:N000b|George Zhu (n000b)]] releases [[ILiberty / ILiberty%2B]].

===February===
* February 28 -- [[Cydia]] is released as an open-source alternative to Installer.app, and prepares to take over the jailbreak application scene upon 2.0's release.
* February 11 -- [[Zibri]] releases [[ZiPhone]], the first all-in-one unlock, activate, jailbreak solution.
* February 8 -- [[User:Geohot|geohot]] releases software unlock for 4.6, Apple states 25% of phones were never activated with AT&T.

===January===
* January 28 -- Dev team releases soft upgrade jailbreak for 1.1.3.
* January 18 -- Geohot and his friends [http://iphonejtag.blogspot.com/2008/01/112-otb-unlocked.html unlocked 1.1.2 OTB 4.6 by test point], the unbeatable version at that time.
* January 18 -- Dev team posts YouTube video of a jailbroken 1.1.3, which was made possible by the dual boot jailbreak from bgm.

== 2007 ==
===November===
* November 15 -- New baseband [[Bootloader 4.6|bootloader (4.6)]] comes out, new iPhones can't be unlocked.
* November 2 -- [[Jailbreakme]] is released, bringing jailbreaking to the mainstream iPhone user.

===October===
* October 23 -- iPhone-Elite Team releases the [[Virginizer]].
* October 14 -- AriX releases iJailBreak, the first automated iPod touch jailbreak for the Mac.
* October 12 -- planetbeing releases touchFree, the first automated iPod touch jailbreak.
* October 10 -- niacin, cmw, and dre release the [[TIFF exploit]] to jailbreak the iPod touch, which is later adapted for use in [[Jailbreakme]].

===September===
* September 11 -- [[The dev team]] releases [[iUnlock]], first free software unlock.
* September 10 -- [[IPSF]] releases first paid software unlock.
* September 9 -- Apple announces the [[iPod touch]] at a media event.

===August===
* August 23 -- [[User:Geohot|geohot]] and team release [[hardware unlock]] method.
* August 21 -- Installer.app is released by Nullriver, first GUI apps are distributed.

===July===
* July 23 -- First phones are used with other carriers by means of [[SIM hacks]].
* July 20 -- nightwatch adapts a [[toolchain]] to the iPhone. The first apps are compiled.
* July 9 -- [[The dev team]] releases a [[jailbreak]] method. The first use of this is ringtones.
* July 3 -- DVD Jon first cracks [[activation]]. People can use the apps on the phone without a subscription.

===June===
* June 29 -- [[iPhone]] is released. World's most hyped consumer product.

Decrypting Firmwares

2009-04-12T14:25:28Z

AriX: /* 1.1.x */

==1.x==
If you want to decrypt 1.x iPhone ramdisk you must remove some trash from the beginning of them. You can do this in Terminal.app (on Mac OS X you can find them in /Applications/Utilities/).

Unzip firmware image (change extension .ipsw to .zip and double click on archive) and find restore ramdisk. In Terminal.app enter simple command:

''dd if=restore_ramdisk.dmg of=restore_ramdisk.stripped.dmg bs=512 skip=4 count=37464 conv=sync''

Where '''restore_ramdisk.dmg''' is image of restore ramdisk (for example 1.0 iPhone firmware restore ramdisk is 694-5259-38.dmg), and '''restore_ramdisk.stripped.dmg''' is 'decrypted' image, that you can mount and explore from Finder.

Note: If after mounting stripped ramdisk you see errors, ignore them.

==1.1.x==
To decrypt the 1.1.x ramdisk, strip the first 0x800 bytes. I'm not proficient in dd, but the above command could be modified for this, or it could be done in a hex editor. Once that's complete, run this command:

''openssl enc -d -in ramdisk.dmg -out de.dmg -aes-128-cbc -K 188458A6D15034DFE386F23B61D43774 -iv 0''

This uses the iPhone's GID key which was first leaked by Zibri and had its purpose revealed on Geohot's blog.

==2.x+==
The ramdisk on both 2.x and 3.x firmwares is a simple [http://www.theiphonewiki.com/wiki/index.php?title=IMG3_File_Format img3 file], that you can decrypt using [http://code.google.com/p/img3decrypt/ img3decrypt] or [http://github.com/planetbeing/xpwn/tree/master xpwntool]. You must download one of these utilities. For easier access, put them in '''/usr/local/bin'''

In Terminal.app enter:

''img3decrypt e restore_ramdisk.dmg restore_ramdisk_decrypted.dmg Ramdisk_IV Ramdisk_Key''

Where '''restore_ramdisk.dmg''' is image of restore ramdisk (for example 3.0 beta 1 iPhone GSM firmware restore ramdisk is 018-4793-1.dmg), and r'''estore_ramdisk_decrypted.dmg''' is decrypted image, that you can mount and explore from Finder. Ramdisk_IV and Ramdisk_Key is a decrypted keys that you can find in [http://www.theiphonewiki.com/wiki/index.php?title=VFDecrypt_Keys:_3.x vfdecrypt page] or in Info.plist from PwnageTool FirmwareBundles folder (when Dev Team include support for this firmware).

Decrypting Firmwares

2009-04-12T14:25:16Z

AriX:

==1.x==
If you want to decrypt 1.x iPhone ramdisk you must remove some trash from the beginning of them. You can do this in Terminal.app (on Mac OS X you can find them in /Applications/Utilities/).

Unzip firmware image (change extension .ipsw to .zip and double click on archive) and find restore ramdisk. In Terminal.app enter simple command:

''dd if=restore_ramdisk.dmg of=restore_ramdisk.stripped.dmg bs=512 skip=4 count=37464 conv=sync''

Where '''restore_ramdisk.dmg''' is image of restore ramdisk (for example 1.0 iPhone firmware restore ramdisk is 694-5259-38.dmg), and '''restore_ramdisk.stripped.dmg''' is 'decrypted' image, that you can mount and explore from Finder.

Note: If after mounting stripped ramdisk you see errors, ignore them.

==1.1.x==
To decrypt the 1.1.x ramdisk, strip the first 0x800 bytes. I'm not proficient in dd, but the above command could be modified for this, or it could be done in a hex editor. Once that's complete, run this command:
''openssl enc -d -in ramdisk.dmg -out de.dmg -aes-128-cbc -K 188458A6D15034DFE386F23B61D43774 -iv 0''

This uses the iPhone's GID key which was first leaked by Zibri and had its purpose revealed on Geohot's blog.

==2.x+==
The ramdisk on both 2.x and 3.x firmwares is a simple [http://www.theiphonewiki.com/wiki/index.php?title=IMG3_File_Format img3 file], that you can decrypt using [http://code.google.com/p/img3decrypt/ img3decrypt] or [http://github.com/planetbeing/xpwn/tree/master xpwntool]. You must download one of these utilities. For easier access, put them in '''/usr/local/bin'''

In Terminal.app enter:

''img3decrypt e restore_ramdisk.dmg restore_ramdisk_decrypted.dmg Ramdisk_IV Ramdisk_Key''

Where '''restore_ramdisk.dmg''' is image of restore ramdisk (for example 3.0 beta 1 iPhone GSM firmware restore ramdisk is 018-4793-1.dmg), and r'''estore_ramdisk_decrypted.dmg''' is decrypted image, that you can mount and explore from Finder. Ramdisk_IV and Ramdisk_Key is a decrypted keys that you can find in [http://www.theiphonewiki.com/wiki/index.php?title=VFDecrypt_Keys:_3.x vfdecrypt page] or in Info.plist from PwnageTool FirmwareBundles folder (when Dev Team include support for this firmware).

Decrypting Firmwares

2009-04-12T14:24:58Z

AriX:

==1.x==
If you want to decrypt 1.x iPhone ramdisk you must remove some trash from the beginning of them. You can do this in Terminal.app (on Mac OS X you can find them in /Applications/Utilities/).

Unzip firmware image (change extension .ipsw to .zip and double click on archive) and find restore ramdisk. In Terminal.app enter simple command:

''dd if=restore_ramdisk.dmg of=restore_ramdisk.stripped.dmg bs=512 skip=4 count=37464 conv=sync''

Where '''restore_ramdisk.dmg''' is image of restore ramdisk (for example 1.0 iPhone firmware restore ramdisk is 694-5259-38.dmg), and '''restore_ramdisk.stripped.dmg''' is 'decrypted' image, that you can mount and explore from Finder.

Note: If after mounting stripped ramdisk you see errors, ignore them.

==1.1.x==
To decrypt the 1.1.x ramdisk, strip the first 0x800 bytes. I'm not proficient in dd, but the above command could be modified for this, or it could be done in a hex editor. Once that's complete, run this command: openssl enc -d -in ramdisk.dmg -out de.dmg -aes-128-cbc -K 188458A6D15034DFE386F23B61D43774 -iv 0

This uses the iPhone's GID key which was first leaked by Zibri and had its purpose revealed on Geohot's blog.

==2.x+==
The ramdisk on both 2.x and 3.x firmwares is a simple [http://www.theiphonewiki.com/wiki/index.php?title=IMG3_File_Format img3 file], that you can decrypt using [http://code.google.com/p/img3decrypt/ img3decrypt] or [http://github.com/planetbeing/xpwn/tree/master xpwntool]. You must download one of these utilities. For easier access, put them in '''/usr/local/bin'''

In Terminal.app enter:

''img3decrypt e restore_ramdisk.dmg restore_ramdisk_decrypted.dmg Ramdisk_IV Ramdisk_Key''

Where '''restore_ramdisk.dmg''' is image of restore ramdisk (for example 3.0 beta 1 iPhone GSM firmware restore ramdisk is 018-4793-1.dmg), and r'''estore_ramdisk_decrypted.dmg''' is decrypted image, that you can mount and explore from Finder. Ramdisk_IV and Ramdisk_Key is a decrypted keys that you can find in [http://www.theiphonewiki.com/wiki/index.php?title=VFDecrypt_Keys:_3.x vfdecrypt page] or in Info.plist from PwnageTool FirmwareBundles folder (when Dev Team include support for this firmware).

Ramdisk

2009-04-12T14:18:14Z

AriX:

This is what iTunes boots to upgrade the [[System|OS]] and the [[NOR]], and in the case of the [[iPhone]], it upgrades the [[Baseband Device|Baseband]].

It is signed, but if you have administered the [[Pwnage]] hack, you can load modified ones.

There are two types of ramdisks. They are very similar, and both are located in the IPSW. There is a [[Restore Ramdisk]] and an [[Update Ramdisk]]. To decrypt the ramdisks, follow the instructions on the [[Ramdisk Decryption]] page.

Decrypting Firmwares

2009-04-12T14:15:37Z

AriX:

==1.x==
If you want to decrypt 1.x iPhone ramdisk you must remove some trash from the beginning of them. You can do this in Terminal.app (on Mac OS X you can find them in /Applications/Utilities/).

Unzip firmware image (change extension .ipsw to .zip and double click on archive) and find restore ramdisk. In Terminal.app enter simple command:

''dd if=restore_ramdisk.dmg of=restore_ramdisk.stripped.dmg bs=512 skip=4 count=37464 conv=sync''

Where '''restore_ramdisk.dmg''' is image of restore ramdisk (for example 1.0 iPhone firmware restore ramdisk is 694-5259-38.dmg), and '''restore_ramdisk.stripped.dmg''' is 'decrypted' image, that you can mount and explore from Finder.

Note: If after mounting stripped ramdisk you see errors, ignore them.

==2.x+==
The ramdisk on both 2.x and 3.x firmwares is a simple [http://www.theiphonewiki.com/wiki/index.php?title=IMG3_File_Format img3 file], that you can decrypt using [http://code.google.com/p/img3decrypt/ img3decrypt] or [http://github.com/planetbeing/xpwn/tree/master xpwntool]. You must download one of these utilities. For easier access, put them in '''/usr/local/bin'''

In Terminal.app enter:

''img3decrypt e restore_ramdisk.dmg restore_ramdisk_decrypted.dmg Ramdisk_IV Ramdisk_Key''

Where '''restore_ramdisk.dmg''' is image of restore ramdisk (for example 3.0 beta 1 iPhone GSM firmware restore ramdisk is 018-4793-1.dmg), and r'''estore_ramdisk_decrypted.dmg''' is decrypted image, that you can mount and explore from Finder. Ramdisk_IV and Ramdisk_Key is a decrypted keys that you can find in [http://www.theiphonewiki.com/wiki/index.php?title=VFDecrypt_Keys:_3.x vfdecrypt page] or in Info.plist from PwnageTool FirmwareBundles folder (when Dev Team include support for this firmware).

Decrypting Firmwares

2009-04-12T14:11:48Z

AriX: 3.x firmware moved to Ramdisk Decryption: Why do we need 3 of these pages??

Ramdisk on 3.x firmware (currently beta release) is a simple [http://www.theiphonewiki.com/wiki/index.php?title=IMG3_File_Format img3 file], that you can decrypt using [http://code.google.com/p/img3decrypt/ img3decrypt] or [http://github.com/planetbeing/xpwn/tree/master xpwntool]. So you must download one of these utilities. For easier access, put them in '''/usr/local/bin'''

In Terminal.app enter:

''img3decrypt e restore_ramdisk.dmg restore_ramdisk_decrypted.dmg Ramdisk_IV Ramdisk_Key''

Where '''restore_ramdisk.dmg''' is image of restore ramdisk (for example 3.0 beta 1 iPhone GSM firmware restore ramdisk is 018-4793-1.dmg), and r'''estore_ramdisk_decrypted.dmg''' is decrypted image, that you can mount and explore from Finder. Ramdisk_IV and Ramdisk_Key is a decrypted keys that you can find in [http://www.theiphonewiki.com/wiki/index.php?title=VFDecrypt_Keys:_3.x vfdecrypt page] or in Info.plist from PwnageTool FirmwareBundles folder (when Dev Team include support for this firmware).

Decrypting Firmwares

2009-04-12T14:10:02Z

AriX:

Decrypting Firmwares

2009-04-12T14:09:19Z

AriX:

Ramdisk on 3.x firmware (currently beta release) is a simple [http://www.theiphonewiki.com/wiki/index.php?title=IMG3_File_Format img3 file], that you can decrypt using [http://code.google.com/p/img3decrypt/ img3decrypt] or [http://github.com/planetbeing/xpwn/tree/master xpwntool]. So you must download this utility. For easier access, put them in '''/usr/local/bin'''

In Terminal.app enter:

''img3decrypt e restore_ramdisk.dmg restore_ramdisk_decrypted.dmg Ramdisk_IV Ramdisk_Key''

Where '''restore_ramdisk.dmg''' is image of restore ramdisk (for example 3.0 beta 1 iPhone GSM firmware restore ramdisk is 018-4793-1.dmg), and r'''estore_ramdisk_decrypted.dmg''' is decrypted image, that you can mount and explore from Finder. Ramdisk_IV and Ramdisk_Key is a decrypted keys that you can find in [http://www.theiphonewiki.com/wiki/index.php?title=VFDecrypt_Keys:_3.x vfdecrypt page] or in Info.plist from PwnageTool FirmwareBundles folder (when Dev Team include support for this firmware).

IPhone Dev Team

2009-04-08T01:39:52Z

AriX: The dev team moved to IPhone Dev Team: This is not the only dev team that exists in this field anymore.

==Blog==
[http://blog.iphone-dev.org Dev Team blog]

==Current members==
asap18, bgm, Bugout, bushing, c1de0x, chris, dinopio, drudge, Fred_, ghost_000, gray, iZsh, jim–, MuscleNerd, netkas, np101137, penisbird, planetbeing, pr3d4t0r, pumpkin, pytey, roxfan, saurik, Turbo, w___, wizdaz, Zf

==Previous Members==
[[geohot]], gj, kroo, Nate True, NerveGas, sam, Whiterat, [[Zibri]]

==See also==
* [[PwnageTool]]
* [[pwnage]]
* [[pwnage 2.0]]
* [[yellowsn0w]]
* [[redsn0w]]

Talk:IPhone Dev Team

2009-04-08T01:39:52Z

AriX: Talk:The dev team moved to Talk:IPhone Dev Team: This is not the only dev team that exists in this field anymore.

I know about the rest of them, but does anyone have any idea why kroo was kicked out? My guess is that he leaked the DFU/iBoot exploit to geohot..

== Sam ==

chronic seems to think that sam is no longer on the devteam, however on hackint0sh his tag still says 'iPhone Dev Team' and in this post (http://hackint0sh.org/forum/showthread.php?t=61327) he speaks as one of the devteam.

Can anyone provide anymore insight on Sam..is he still on the devteam or not?

S5L8900

2009-04-07T14:52:36Z

AriX: /* iBoot / Kernel */

This is the Application Processor shared between the [[iPhone]], [[N45ap|iPod touch]], and the [[iPhone 3G]]. Not much is known about it through official sources.

==Firmware File Formats==
See [[S5L File Formats|this page]] for more information on the types of firmware files it interprets

==Exploits==
===Userland===
* [[Restore Mode]] - Firmware v1.0.2 and below
* [[symlinks|Symlinks]] - Firmware v1.1.1 and below
* [[LibTiff|LibTIFF]] - Firmware v1.1.1 and below
* [[Mknod]] - Firmware v1.1.2 and below

===[[iBoot]] / [[Kernel]]===
* [[Ramdisk Hack|Ramdisk Exploit]] - Firmware v1.1.4/v2.0b3 and below
* [[diags|Diags Exploit]] - Firmware v1.1.4/v2.0b5 and below

===[[VROM (S5L8900)|Bootrom]]===
* [[pwnage|Pwnage 1.0 (Ramdisk + AppleImage2NORAccess)]]
* [[pwnage 2.0|Pwnage 2.0 (DFU + Malformed Certificate)]]

==Boot Chain==
[[VROM]]->[[LLB]]->[[iBoot]]->[[Kernel]]->[[System|System Software]]

One of the [[iPhoneLinux]] goals are to replace that Boot Chain after iBoot : 
[[VROM]]->OpeniBoot->Linux Kernel->X Server->Window Manager

==Upgrade Process==

=== Restore mode ===
The common upgrade process chain is [[VROM]]->[[DFU]]->[[WTF]]->[[iBoot]]->[[Kernel]]->[[Ramdisk]]->[[Restore Mode|Restore]], also called [[Restore Mode|restore mode]].

== DFU mode ==
See full article [[DFU|here]]. To flash an older version of the iPhone software you have to let your phone reside in [[DFU]]. In iTunes you have to press the Alt-Key (Mac) or the shift-key (Windows) when pressing 'Restore' to be able to manually chose an update file (ipsw file).

=== Boot Chain ===
[[VROM]]-->[[DFU]]

S5L8900

2009-04-07T14:52:27Z

AriX: Most people don't have 2.0 beta builds, so I added release build information

This is the Application Processor shared between the [[iPhone]], [[N45ap|iPod touch]], and the [[iPhone 3G]]. Not much is known about it through official sources.

==Firmware File Formats==
See [[S5L File Formats|this page]] for more information on the types of firmware files it interprets

==Exploits==
===Userland===
* [[Restore Mode]] - Firmware v1.0.2 and below
* [[symlinks|Symlinks]] - Firmware v1.1.1 and below
* [[LibTiff|LibTIFF]] - Firmware v1.1.1 and below
* [[Mknod]] - Firmware v1.1.2 and below

===[[iBoot]] / [[Kernel]]===
* [[Ramdisk Hack|Ramdisk Exploit]] - Firmware v1.1.4/v2.0b3 and below
* [[diags|Diags Exploit]] - Firmware v1.1.4/2.0b5 and below

===[[VROM (S5L8900)|Bootrom]]===
* [[pwnage|Pwnage 1.0 (Ramdisk + AppleImage2NORAccess)]]
* [[pwnage 2.0|Pwnage 2.0 (DFU + Malformed Certificate)]]

==Boot Chain==
[[VROM]]->[[LLB]]->[[iBoot]]->[[Kernel]]->[[System|System Software]]

One of the [[iPhoneLinux]] goals are to replace that Boot Chain after iBoot : 
[[VROM]]->OpeniBoot->Linux Kernel->X Server->Window Manager

==Upgrade Process==

=== Restore mode ===
The common upgrade process chain is [[VROM]]->[[DFU]]->[[WTF]]->[[iBoot]]->[[Kernel]]->[[Ramdisk]]->[[Restore Mode|Restore]], also called [[Restore Mode|restore mode]].

== DFU mode ==
See full article [[DFU|here]]. To flash an older version of the iPhone software you have to let your phone reside in [[DFU]]. In iTunes you have to press the Alt-Key (Mac) or the shift-key (Windows) when pressing 'Restore' to be able to manually chose an update file (ipsw file).

=== Boot Chain ===
[[VROM]]-->[[DFU]]

Mknod

2009-04-07T14:49:13Z

AriX:

This exploit, also known as OktoPrep, after the name of the package used to prepare it, was the standard 1.1.2 jailbreak. Like [[Symlinks]] and [[Soft Upgrade]], this was an update jailbreak that required the user to upgrade from an older to a newer version of the OS to achieve the jailbreak. Essentially, the user would jailbreak 1.1.1 through the [[LibTiff|TIFF]] exploit, install the OktoPrep package in Installer, and update to 1.1.2 in iTunes, and use the iPhone Dev Team's jailbreak utility, written by planetbeing. The OktoPrep package created a node for the operating system, essentially copying /dev/rdisk0s1 to /private/var/root/Media/rdisk0s1. Since the 1.1.2 ramdisk did not check for this, it would remain in 1.1.2, and the operating system could be downloaded, jailbroken, and re-uploaded through iPHUC, similar to the symlink and TIFF exploits. The most popular method of TIFF jailbreak, jailbreakme.com, later updated their payload to automatically apply OktoPrep for easier 1.1.2 jailbreaking. This was in response to complaints about how long it took to jailbreak 1.1.3, which originally had to be jailbroken through a long process involving jailbreaking 1.1.1, moving on to 1.1.2, and finally upgrading to 1.1.3.

This exploit was closed in 1.1.3 when /etc/fstab was changed so that /private/var was mounted with the 'nodev' flag in addition to the others.

[[Category:Jailbreaks]]

Mknod

2009-04-07T14:48:11Z

AriX: 1.1.2 jailbreak. Mknod, or OktoPrep. The disk was NOT symlinked, as suggested in the original symlink article, it was created with the mknod command.

This exploit, also known as OktoPrep, after the name of the package used to prepare it, was the standard 1.1.2 jailbreak. Like [[Symlinks]] and [[Soft Upgrade]], this was an update jailbreak that required the user to upgrade from an older to a newer version of the OS to achieve the jailbreak. Essentially, the user would jailbreak 1.1.1 through the [[LibTiff|TIFF]] exploit, install the OktoPrep package in Installer, and update to 1.1.2 in iTunes, and use the iPhone Dev Team's jailbreak utility, written by planetbeing. The OktoPrep package created a node for the operating system, essentially copying /dev/rdisk0s1 to /private/var/root/Media/rdisk0s1. Since the 1.1.2 ramdisk did not check for this, it would remain in 1.1.2, and the operating system could be downloaded, jailbroken, and re-uploaded through iPHUC, similar to the symlink] and TIFF exploits. The most popular method of TIFF jailbreak, jailbreakme.com, later updated their payload to automatically apply OktoPrep for easier 1.1.2 jailbreaking. This was in response to complaints about how long it took to jailbreak 1.1.3, which originally had to be jailbroken through a long process involving jailbreaking 1.1.1, moving on to 1.1.2, and finally upgrading to 1.1.3.

This exploit was closed in 1.1.3 when /etc/fstab was changed so that /private/var was mounted with the 'nodev' flag in addition to the others.

[[Category:Jailbreaks]]

S5L8900

2009-04-07T14:41:40Z

AriX: /* Exploits */

This is the Application Processor shared between the [[iPhone]], [[N45ap|iPod touch]], and the [[iPhone 3G]]. Not much is known about it through official sources.

==Firmware File Formats==
See [[S5L File Formats|this page]] for more information on the types of firmware files it interprets

==Exploits==
===Userland===
* [[Restore Mode]] - Firmware v1.0.2 and below
* [[symlinks|Symlinks]] - Firmware v1.1.1 and below
* [[LibTiff|LibTIFF]] - Firmware v1.1.1 and below
* [[Mknod]] - Firmware v1.1.2 and below

===[[iBoot]] / [[Kernel]]===
* [[Ramdisk Hack|Ramdisk Exploit]] - Firmware v2.0b3 and below
* [[diags|Diags Exploit]] - Firmware 2.0b5 and below

===[[VROM (S5L8900)|Bootrom]]===
* [[pwnage|Pwnage 1.0 (Ramdisk + AppleImage2NORAccess)]]
* [[pwnage 2.0|Pwnage 2.0 (DFU + Malformed Certificate)]]

==Boot Chain==
[[VROM]]->[[LLB]]->[[iBoot]]->[[Kernel]]->[[System|System Software]]

One of the [[iPhoneLinux]] goals are to replace that Boot Chain after iBoot : 
[[VROM]]->OpeniBoot->Linux Kernel->X Server->Window Manager

==Upgrade Process==

=== Restore mode ===
The common upgrade process chain is [[VROM]]->[[DFU]]->[[WTF]]->[[iBoot]]->[[Kernel]]->[[Ramdisk]]->[[Restore Mode|Restore]], also called [[Restore Mode|restore mode]].

== DFU mode ==
See full article [[DFU|here]]. To flash an older version of the iPhone software you have to let your phone reside in [[DFU]]. In iTunes you have to press the Alt-Key (Mac) or the shift-key (Windows) when pressing 'Restore' to be able to manually chose an update file (ipsw file).

=== Boot Chain ===
[[VROM]]-->[[DFU]]

Symlinks

2009-04-07T14:30:02Z

AriX:

Before the discovery of the [[LibTiff]], this was used on 1.1.1 to jailbreak iPhones from 1.0.2. However, this only worked for iPhones, as the new iPod touch could not run 1.0.2 and therefore could not use this jailbreak method. The symlink method involved symlinking /private/var/root/Media, the "jailed" directory that could be accessed via iPHUC, to /, and then downloading, jailbreaking, and reuploading the entire system partition from /dev/rdisk0s1.

This exploit was fixed in 1.1.2, when Apple introduced a check in the update ramdisk that prevented this from happening. Note that this is not the 1.1.2 [[mknod]] exploit.

[[Category:Jailbreaks]]

Symlinks

2009-04-07T14:29:47Z

AriX:

Before the discovery of the [[LibTiff]], this was used on 1.1.1 to jailbreak iPhones from 1.0.2. However, this only worked for iPhones, as the new iPod touch could not run 1.0.2 and therefore could not use this jailbreak method. The symlink method involved symlinking /private/var/root/Media, the "jail directory" that could be accessed via iPHUC, to /, and then downloading, jailbreaking, and reuploading the entire system partition from /dev/rdisk0s1.

This exploit was fixed in 1.1.2, when Apple introduced a check in the update ramdisk that prevented this from happening. Note that this is not the 1.1.2 [[mknod]] exploit.

[[Category:Jailbreaks]]

Symlinks

2009-04-07T14:22:20Z

AriX:

Before the discovery of the [[LibTiff]], this was used on 1.1.1 to jailbreak iPhones from 1.0.2. However, this only worked for iPhones, as the new iPod touch could not run 1.0.2 and therefore could not use this jailbreak method. The symlink method involved symlinking /private/var/root/Media, the directory that the AFC protocol can access access, to /, and then downloading, jailbreaking, and reuploading the entire system partition from /dev/rdisk0s1.

This exploit was fixed in 1.1.2, when Apple introduced a check in the update ramdisk that prevented this from happening. Note that this is not the 1.1.2 [[mknod]] exploit.

[[Category:Jailbreaks]]