The iPhone Wiki - User contributions [en]

Timeline

2011-02-07T21:30:47Z

Littlemartian:

==2011==
===February===
*February 7 -- 9pm GMT The [[Chronic Dev (team)|Chronic Dev Team]] release a version of Greenpois0n to jailbreak the Verizon iPhone 4 using the [[HFS_Legacy_Volume_Name_Stack_Buffer_Overflow]].
*February 3 -- [[User:Jaywalker|Jaywalker]] of the [[Chronic Dev (team)|Chronic Dev Team]] posts [http://www.youtube.com/watch?v=T3NYPVT13xw a video] of custom boot using a soon to be released version of [[Greenpois0n (jailbreak)|Greenpois0n]].

===January===
*January 12 -- Apple discontinues iOS support for [[N82ap|iPhone 3G]] and [[N72ap|iPod touch 2G]] since today's beta release of iOS 4.3. Also first time a beta iOS for [[K66ap|Apple TV 2G]] is released.
*January 11 -- Verizon announces CDMA version of iPhone 4

==2010==
===November===
*November 28 -- [[ultrasn0w]] 1.2 is released by the [[iPhone Dev Team]] to unlock [[N82ap|iPhone 3G]] and [[N88ap|iPhone 3GS]] on baseband 6.15.00
*November 22 -- Apple releases iOS 4.2.1 (respectively 4.2 for [[K66ap|Apple TV 2G]])

===October===
*October 31 -- The [[iPhone Dev Team|Dev Team]] releases [[redsn0w]] 0.9.6b2 which jailbreaks iOS 4.1, 4.2 and 3.2.2 on every device available at the time of release (except for iPT 2G MC). It also includes "DFU" button allowing to flash custom [[IPSW]] from Windows [http://blog.iphone-dev.org/post/1452044444/redsn0w-limera1n-fun (see blog post)].
*October 20 -- The [[iPhone Dev Team|Dev Team]] releases [[PwnageTool]] 4.1 which jailbreaks iOS 4.1 and 3.2.2 on every device available at the time of release. [http://blog.iphone-dev.org/post/1359246784/20102010-event (see blog post)]
*October 18 -- [[Chronic Dev (team)|Chronic Dev Team]] releases [[Greenpois0n (jailbreak)|greenpois0n]] RC4 which added support for iPod touch 2G (MC and MB) for an untethered jailbreak using [[User:comex|comex]]'s kernel exploit and the [[usb_control_msg(0xA1, 1) Exploit]].
*October 12 -- [[Chronic Dev (team)|Chronic Dev Team]] releases [[Greenpois0n (jailbreak)|greenpois0n]] after switching its exploit from SHAtter to the exploit [[limera1n]] uses. By doing this, SHAtter remains undisclosed, meaning there is a chance that the 5th generation devices are vulnerable. (The exploit [[limera1n]] uses appears to be fixed in the [[iBoot (Bootloader)|iBoot]] revision found in iOS 4.2 beta 2, which means Apple probably knows about the vulnerability and the next [[bootrom]] revision may have it patched.)
*October 10 -- Following the first [[limera1n]] beta release, [[User:geohot|geohot]] released multiple versions, each fixing bugs affecting previous releases. [[Chronic Dev (team)|Chronic Dev Team]] officialy anounces that, in order to keep SHAtter undisclosed and possibly preserve it for 5th generation devices, [[Greenpois0n (jailbreak)|greenpois0n]] would be delayed in order to incorporate this new exploit [[limera1n]] uses.
*October 9 -- In order to push [[Chronic Dev (team)|Chronic Dev Team]] to change the exploit used on [[Greenpois0n (jailbreak)|greenpois0n]], [[User:geohot|geohot]] rushed out a beta version of [[limera1n]].
*October 8 -- [[User:Geohot|Geohot]] comes back to the scene with a new [[bootrom]] exploit believed to work on all devices, as shown on the resurrected [http://www.limera1n.com limera1n web site]. He prompts [[Chronic_Dev_(team)|Chronic Dev Team]] to use his exploit instead of SHAtter, but, since [[Greenpois0n (jailbreak)|greenpois0n]] is already scheduled to October 10, it may be not possible. [[User:Geohot|Geohot]] ETA'd his [[limera1n]] release to October 11, if [[Greenpois0n (jailbreak)|greenpois0n]] can't be changed to use this new exploit. This decision, however, would burn 2 [[bootrom]] exploits: SHAtter itself and the one used by [[limera1n]], which is unpatchable by firmware updates.
*October 6 -- Chronic Dev Team issues expected ETA of [[Greenpois0n (jailbreak)|greenpois0n]] as October 10, featuring the new SHAtter exploit for devices with the [[S5L8930]].

===September===
*September 30 -- [[User:MuscleNerd|MuscleNerd]] of the [[iPhone Dev Team]] posts [http://www.youtube.com/watch?v=adVp-IxcDHI the first video] of an [[K66ap|Apple TV 2G]] jailbroken via SHAtter.
*September 27 -- [[User:MuscleNerd|MuscleNerd]] of the [[iPhone Dev Team]] posts [http://www.youtube.com/watch?v=aoX1Q8ym2J8 the first video] of an [[N81ap|iPod touch 4G]] jailbroken via SHAtter.
*September 20 -- [[User:pod2g|pod2g]] discloses details about the [[usb_control_msg(0xA1, 1) Exploit‎]] here at The iPhone Wiki. It was used in [[redsn0w]] the following day.
*September 9 -- The existence of SHAtter is revealed. Further details were not released, however.
*September 8 -- Apple releases the [[N81ap|iPod touch 4G]], and iOS 4.1, closing the [[AT+XAPP Vulnerability]].
*September 1 -- Apple event. They announced the new [[N81ap|iPod touch 4G]], [[K66ap|Apple TV 2G]], iOS 4.1, and [[iTunes]] 10.

===August===
*August 12 -- [[Saurik]] releases the first version of PDF Patcher, which installs Apple's patch for the FreeType vulnerability (used in conjunction with other exploits by [[Star]]). It works on firmwares as far back as 2.x, and renders iOS 3.2.2 and 4.0.2 useless for jailbreakers. Jailbreaking and installing this patch is currently the only way for users of first generation iPod touches and iPhones to protect themselves against malicious use of the exploit.
*August 11 -- Apple releases iOS 4.0.2 for [[iPhone]]/[[iPod touch]] and iOS 3.2.2 for [[K48ap|iPad]] as a hotfix for [[Star]]'s exploits. [[Ultrasn0w]]'s exploit remains, since there's no [[Baseband Firmware|baseband]] update on those versions.
*August 3 -- Just before midnight in [[User:planetbeing|planetbeing]]'s timezone [[ultrasn0w]] has been released by the [[iPhone Dev Team]] to [[unlock]] the [[N90ap|iPhone 4]].
*August 1 -- [[User:Comex|comex]] releases [[Star]], a [[jailbreak]] for all iDevices with iOS 3.1.2 through 4.0.1.

===July===
*July 30 -- [[N90ap|iPhone 4]] is released in major countries (second wave).
*July 26 -- Jailbreaking is now officially legal in the U.S.A.: [http://www.eff.org/press/archives/2010/07/26 EFF Wins New Legal Protections for Cell Phone Jailbreakers and Unlockers]
*July 15 -- Apple releases iOS 3.2.1 and 4.0.1.

===June===
*June 24 -- [[N90ap|iPhone 4]] is launched.
*June 22 -- [[iPhone Dev Team]] releases [[PwnageTool]] 4.0 and later 4.0.1 for all devices on 4.0 except those with newer bootroms (some [[N72ap|iPod touch 2G]] and [[N88ap|iPhone 3GS]] devices, and all [[N18ap|iPod touch 3G]] and newer devices).
*June 21 -- [[iPhone Dev Team]] releases [[redsn0w]] 0.9.5 to jailbreak 4.0 on [[N82ap|iPhone 3G]] and [[N72ap|iPhone touch 2G]] ([[iBoot-240.4|old bootrom]]).
*June 21 -- [[iPhone Dev Team]] releases [[ultrasn0w]] 0.93, an unlock for baseband firmwares [[4.26.08]], [[5.11.07]], [[5.12.01]], and [[5.13.04]].
*June 21 -- Apple releases iOS 4.0
*June 19 -- [[User:Geohot|geohot]] holds a speech at the [[Nuit du hack 2010|Nuit du Hack]]

===May===
*May 3 -- Windows version of [[Spirit]] has been updated to not require Windows 98 compatibility mode to run and fixed a photo deletion issue.
*May 2 -- [[User:Comex|comex]] releases [[Spirit]], an [[untethered jailbreak]] for all iDevices with iOS 3.1.2 through 3.2.

===April===
*April 3 -- Apple releases the [[K48ap|iPad]].

===Feb===
*Feb 12 -- [[User:sherif hashim|sherif_hashim]] discovers [[AT+XAPP Vulnerability]] and passes it to [[User:MuscleNerd|MuscleNerd]], an elite member of the [[iPhone Dev Team]]
*Feb 2 -- Apple releases iOS 3.1.3, closing [[usb_control_msg(0x21, 2) Exploit|usb_control_msg(0x21, 2)]] vulnerability used by [[blackra1n]], [[redsn0w]], et. al.

==2009==
===November===
*November 3 -- [[User:Geohot|geohot]] releases [[blackra1n]] RC3, a software jailbreak for all devices. Includes a new unlock for baseband [[5.11.07]] called [[blacksn0w]] and is also noticeably faster than previous versions.

===October===
*October 11 -- [[User:Geohot|geohot]] releases [[blackra1n]] RC1, a 30 second software jailbreak for all devices, including a [[tethered jailbreak]] for the [[N18ap|iPod touch 3G]], and [[N88ap|iPhone 3GS]] and [[N72ap|iPod touch 2G]] units with newer bootrom revisions.

===September===
* September 24 -- [[User:iH8sn0w|iH8sn0w]] discovers the [[AT+XEMN Heap Overflow|AT+XEMN]] crash independently.
* September 9 -- The [[N18ap|iPod touch 3G]] with [[S5L8922]] processor is released. [[N72ap|iPod touch 2G]] units continue shipping, but with [[iBoot-240.5.1|a new bootrom]]. [[N88ap|iPhone 3GS]] units also begin shipping with [[iBoot-359.3.2|a new bootrom]]. These are no longer vulnerable to the [[0x24000 Segment Overflow]].
* Apple releases iOS 3.1/3.1.1 (7C144/7C145), closing the [[iBoot Environment Variable Overflow]] and [[AT+XLOG Vulnerability|AT+XLOG]] + [[AT+FNS]] Baseband Exploits.

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

===June===
* June 28 -- [[User:Geohot|geohot]] posts pictures on his blog of the first fully jailbroken [[N88ap|iPhone 3GS]].
* June 25 -- It's discovered that [[N88ap|iPhone 3GS]] is vulnerable to the [[0x24000 Segment Overflow]].
* June 24 -- The [[iPhone Dev Team]] releases [[ultrasn0w]], an [[unlock]] for [[X-Gold 608]] thanks to [[AT+XLOG Vulnerability|a new exploit]] discovered by [[User:Oranav|Oranav]].
* June 23 -- [[User:Geohot|geohot]] announces he's found a new exploit in [[iBoot (Bootloader)|iBoot]] he calls [[purplera1n]].
* June 19 -- Release of [[N88ap|iPhone 3GS]] to the public and the release of [[PwnageTool]] 3.0 and [[redsn0w]] for jailbreaking devices running iOS 3.0
* June 17 -- Apple releases iOS 3.0.
* June 8 -- Apple announces the [[N88ap|iPhone 3GS]].

===March===
* March 10 -- Information about the [[0x24000 Segment Overflow]] exploit used for the [[N72ap|iPod touch 2G]] [[untethered jailbreak]] is released thanks to the combined work of [[chronic]], [[CPICH]], [[User:Posixninja|posixninja]], [[User:Pod2g|pod2g]], [[ius]], [[planetbeing]], [[User:MuscleNerd|MuscleNerd]], and co. after being leaked and sold by [[NitroKey]]. To prevent users wasting their money on a stolen exploit, the Hybrid DevTeam decided to release it immediately.

===January===
* January 31 -- The [[iPhone Dev Team]] released [[redsn0w Lite]], a [[tethered jailbreak|tethered]] [[N72ap|iPod touch 2G]] [[jailbreak]]. It combines the [[ARM7 Go]] vulnerability with the well-established [[pwnage]] flow for other Apple mobile devices. It was bundled in a way that allowed usage on iOS 2.2.1 by uploading [[iBoot (Bootloader)|iBoot]] from iOS 2.1.1, which is vulnerable to [[ARM7 Go]], to the device while in [[DFU Mode]].
* January 29 -- Apple releases iOS 2.2.1, closing the [[AT+stkprof]] exploit.
* January 25 -- [[0wnboot]] is released to [http://code.google.com/p/chronicdev/ chronicdev google code page], thanks to [[AriX]], [[User:ChronicDev|chronic]], [[CPICH]], [[westbaer]], [[ius]], [[User:Pod2g|pod2g]], the rest of the iPod devel crew on IRC, and to the #iphone-hax lab rats. Within days, [[AriX]] and the [[Chronic Dev (team)|Chronic Dev Team]] got a ramdisk booting for a [[tethered jailbreak]].
* January 17 -- [[User:MuscleNerd|MuscleNerd]] of the [[iPhone Dev Team]] [https://twitter.com/MuscleNerd/status/1127346766 shows a video demo] of the first jailbroken [[N72ap|iPod touch 2G]].
* January 16 -- [[ARM7 Go]] vulnerability disclosed where else but here on The iPhone Wiki, for developers to poke and prod at.
* January 15 -- The [[iPhone Dev Team]] [https://twitter.com/iphone_dev/status/1120595069 tweets the VFDecrypt key] for iOS 2.2 on [[N72ap|iPod touch 2G]], demonstrating for the first time that unsigned code can now be run on that device.
* January 1 -- The [[iPhone Dev Team]] releases [[yellowsn0w]] 0.9 beta for baseband [[2.28.00]].

==2008==
===December===
* December 27 -- [[25C3 presentation "Hacking the iPhone"]]
* December 21 -- [[User:MuscleNerd|MuscleNerd]], of the [[iPhone Dev Team]] does a live demo of the 3G unlock, dubbed as [[yellowsn0w]]: http://qik.com/video/729275

===November===
* November 21 -- Apple releases iOS 2.2.

===September===
* September 9 -- Apple releases iOS 2.1. [[N72ap|iPod touch 2G]], which no longer had the [[Pwnage 2.0]] exploit, is revealed.

===August===
* August 18 -- Apple releases 2.0.2 fimware. [[iPhone 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.
* August 4 -- Apple releases 2.0.1 fimware

===July===
* July 22 -- [[TA_Mobile]] hardware dumps the 3G baseband (bootloader 5.8 & FW 1.45.00) by desoldering the [[NOR]].
* July 19 -- [[iPhone Dev Team]] releases [[PwnageTool]] 2.0, jailbreaking and unlocking the 2.0 software on the [[M68ap|iPhone 2G]] and jailbreaking iOS 2.0 on the [[N82ap|iPhone 3G]] and [[N45ap|iPod touch]].
* July 15 -- Apple releases iOS 1.1.5, the last of the 1.x firmwares
* July 11 -- [[N82ap|iPhone 3G]] is released. Apple releases iOS 2.0 and MobileMe on the same date, resulting in server issues.

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

===April===
* April 3 -- [[iPhone 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 -- [[iPhone Dev Team|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+]].

===February===
* February 28 -- [[Cydia Application|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 26 -- Apple releases iOS 1.1.4.
* February 11 -- [[User:Zibri|Zibri]] leaks the [[Ramdisk Hack]] in [[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 -- [[iPhone Dev Team]] releases [[Soft Upgrade]] jailbreak for 1.1.3.
* January 24 -- [[Nate True]] releases a version of [[iBrickr]] that used the [[Soft Upgrade]] method to jailbreak 1.1.3 for [[M68ap|iPhones]].
* January 18 -- [[User:Geohot|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 -- [[iPhone Dev Team]] posts YouTube video of a jailbroken 1.1.3, which was made possible by the dual boot jailbreak from [[bgm]].
* January 15 -- Apple releases iOS 1.1.3, closing the [[Mknod]] exploit. In addition, everything now runs as "mobile" instead of "root."

== 2007 ==
===November===
* November 15 -- [[Baseband Bootloader|Baseband bootloader]] 4.6 is found on new [[M68ap|iPhone]]s, which initially had no [[unlock]].
* November 12 -- Apple releases iOS 1.1.2, closing the [[LibTiff]] and [[Symlinks]] exploits.
* November 2 -- [[JailbreakMe|AppSnapp]] is released, bringing jailbreaking to the mainstream iPhone user.

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

===September===
* September 27 -- Apple releases iOS 1.1.1.
* September 11 -- [[iPhone Dev Team]] releases [[iUnlock]], first free software unlock.
* September 10 -- [[IPSF]] releases first paid software unlock.
* September 9 -- Apple announces the [[N45ap|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 -- [[iPhone 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 -- [[M68ap|iPhone]] is released. World's most hyped consumer product.
* June 26 -- The [[iPhone Dev Team]] was formed.

Timeline

2011-02-07T21:08:37Z

Littlemartian:

==2011==
===February===
*February 7 -- 9pm GMT The [[Chronic Dev (team)|Chronic Dev Team]] release a version of Greenpois0n to jailbreak the Verizon iPhone 4.
*February 3 -- [[User:Jaywalker|Jaywalker]] of the [[Chronic Dev (team)|Chronic Dev Team]] posts [http://www.youtube.com/watch?v=T3NYPVT13xw a video] of custom boot using a soon to be released version of [[Greenpois0n (jailbreak)|Greenpois0n]].

===January===
*January 12 -- Apple discontinues iOS support for [[N82ap|iPhone 3G]] and [[N72ap|iPod touch 2G]] since today's beta release of iOS 4.3. Also first time a beta iOS for [[K66ap|Apple TV 2G]] is released.
*January 11 -- Verizon announces CDMA version of iPhone 4

==2010==
===November===
*November 28 -- [[ultrasn0w]] 1.2 is released by the [[iPhone Dev Team]] to unlock [[N82ap|iPhone 3G]] and [[N88ap|iPhone 3GS]] on baseband 6.15.00
*November 22 -- Apple releases iOS 4.2.1 (respectively 4.2 for [[K66ap|Apple TV 2G]])

===October===
*October 31 -- The [[iPhone Dev Team|Dev Team]] releases [[redsn0w]] 0.9.6b2 which jailbreaks iOS 4.1, 4.2 and 3.2.2 on every device available at the time of release (except for iPT 2G MC). It also includes "DFU" button allowing to flash custom [[IPSW]] from Windows [http://blog.iphone-dev.org/post/1452044444/redsn0w-limera1n-fun (see blog post)].
*October 20 -- The [[iPhone Dev Team|Dev Team]] releases [[PwnageTool]] 4.1 which jailbreaks iOS 4.1 and 3.2.2 on every device available at the time of release. [http://blog.iphone-dev.org/post/1359246784/20102010-event (see blog post)]
*October 18 -- [[Chronic Dev (team)|Chronic Dev Team]] releases [[Greenpois0n (jailbreak)|greenpois0n]] RC4 which added support for iPod touch 2G (MC and MB) for an untethered jailbreak using [[User:comex|comex]]'s kernel exploit and the [[usb_control_msg(0xA1, 1) Exploit]].
*October 12 -- [[Chronic Dev (team)|Chronic Dev Team]] releases [[Greenpois0n (jailbreak)|greenpois0n]] after switching its exploit from SHAtter to the exploit [[limera1n]] uses. By doing this, SHAtter remains undisclosed, meaning there is a chance that the 5th generation devices are vulnerable. (The exploit [[limera1n]] uses appears to be fixed in the [[iBoot (Bootloader)|iBoot]] revision found in iOS 4.2 beta 2, which means Apple probably knows about the vulnerability and the next [[bootrom]] revision may have it patched.)
*October 10 -- Following the first [[limera1n]] beta release, [[User:geohot|geohot]] released multiple versions, each fixing bugs affecting previous releases. [[Chronic Dev (team)|Chronic Dev Team]] officialy anounces that, in order to keep SHAtter undisclosed and possibly preserve it for 5th generation devices, [[Greenpois0n (jailbreak)|greenpois0n]] would be delayed in order to incorporate this new exploit [[limera1n]] uses.
*October 9 -- In order to push [[Chronic Dev (team)|Chronic Dev Team]] to change the exploit used on [[Greenpois0n (jailbreak)|greenpois0n]], [[User:geohot|geohot]] rushed out a beta version of [[limera1n]].
*October 8 -- [[User:Geohot|Geohot]] comes back to the scene with a new [[bootrom]] exploit believed to work on all devices, as shown on the resurrected [http://www.limera1n.com limera1n web site]. He prompts [[Chronic_Dev_(team)|Chronic Dev Team]] to use his exploit instead of SHAtter, but, since [[Greenpois0n (jailbreak)|greenpois0n]] is already scheduled to October 10, it may be not possible. [[User:Geohot|Geohot]] ETA'd his [[limera1n]] release to October 11, if [[Greenpois0n (jailbreak)|greenpois0n]] can't be changed to use this new exploit. This decision, however, would burn 2 [[bootrom]] exploits: SHAtter itself and the one used by [[limera1n]], which is unpatchable by firmware updates.
*October 6 -- Chronic Dev Team issues expected ETA of [[Greenpois0n (jailbreak)|greenpois0n]] as October 10, featuring the new SHAtter exploit for devices with the [[S5L8930]].

===September===
*September 30 -- [[User:MuscleNerd|MuscleNerd]] of the [[iPhone Dev Team]] posts [http://www.youtube.com/watch?v=adVp-IxcDHI the first video] of an [[K66ap|Apple TV 2G]] jailbroken via SHAtter.
*September 27 -- [[User:MuscleNerd|MuscleNerd]] of the [[iPhone Dev Team]] posts [http://www.youtube.com/watch?v=aoX1Q8ym2J8 the first video] of an [[N81ap|iPod touch 4G]] jailbroken via SHAtter.
*September 20 -- [[User:pod2g|pod2g]] discloses details about the [[usb_control_msg(0xA1, 1) Exploit‎]] here at The iPhone Wiki. It was used in [[redsn0w]] the following day.
*September 9 -- The existence of SHAtter is revealed. Further details were not released, however.
*September 8 -- Apple releases the [[N81ap|iPod touch 4G]], and iOS 4.1, closing the [[AT+XAPP Vulnerability]].
*September 1 -- Apple event. They announced the new [[N81ap|iPod touch 4G]], [[K66ap|Apple TV 2G]], iOS 4.1, and [[iTunes]] 10.

===August===
*August 12 -- [[Saurik]] releases the first version of PDF Patcher, which installs Apple's patch for the FreeType vulnerability (used in conjunction with other exploits by [[Star]]). It works on firmwares as far back as 2.x, and renders iOS 3.2.2 and 4.0.2 useless for jailbreakers. Jailbreaking and installing this patch is currently the only way for users of first generation iPod touches and iPhones to protect themselves against malicious use of the exploit.
*August 11 -- Apple releases iOS 4.0.2 for [[iPhone]]/[[iPod touch]] and iOS 3.2.2 for [[K48ap|iPad]] as a hotfix for [[Star]]'s exploits. [[Ultrasn0w]]'s exploit remains, since there's no [[Baseband Firmware|baseband]] update on those versions.
*August 3 -- Just before midnight in [[User:planetbeing|planetbeing]]'s timezone [[ultrasn0w]] has been released by the [[iPhone Dev Team]] to [[unlock]] the [[N90ap|iPhone 4]].
*August 1 -- [[User:Comex|comex]] releases [[Star]], a [[jailbreak]] for all iDevices with iOS 3.1.2 through 4.0.1.

===July===
*July 30 -- [[N90ap|iPhone 4]] is released in major countries (second wave).
*July 26 -- Jailbreaking is now officially legal in the U.S.A.: [http://www.eff.org/press/archives/2010/07/26 EFF Wins New Legal Protections for Cell Phone Jailbreakers and Unlockers]
*July 15 -- Apple releases iOS 3.2.1 and 4.0.1.

===June===
*June 24 -- [[N90ap|iPhone 4]] is launched.
*June 22 -- [[iPhone Dev Team]] releases [[PwnageTool]] 4.0 and later 4.0.1 for all devices on 4.0 except those with newer bootroms (some [[N72ap|iPod touch 2G]] and [[N88ap|iPhone 3GS]] devices, and all [[N18ap|iPod touch 3G]] and newer devices).
*June 21 -- [[iPhone Dev Team]] releases [[redsn0w]] 0.9.5 to jailbreak 4.0 on [[N82ap|iPhone 3G]] and [[N72ap|iPhone touch 2G]] ([[iBoot-240.4|old bootrom]]).
*June 21 -- [[iPhone Dev Team]] releases [[ultrasn0w]] 0.93, an unlock for baseband firmwares [[4.26.08]], [[5.11.07]], [[5.12.01]], and [[5.13.04]].
*June 21 -- Apple releases iOS 4.0
*June 19 -- [[User:Geohot|geohot]] holds a speech at the [[Nuit du hack 2010|Nuit du Hack]]

===May===
*May 3 -- Windows version of [[Spirit]] has been updated to not require Windows 98 compatibility mode to run and fixed a photo deletion issue.
*May 2 -- [[User:Comex|comex]] releases [[Spirit]], an [[untethered jailbreak]] for all iDevices with iOS 3.1.2 through 3.2.

===April===
*April 3 -- Apple releases the [[K48ap|iPad]].

===Feb===
*Feb 12 -- [[User:sherif hashim|sherif_hashim]] discovers [[AT+XAPP Vulnerability]] and passes it to [[User:MuscleNerd|MuscleNerd]], an elite member of the [[iPhone Dev Team]]
*Feb 2 -- Apple releases iOS 3.1.3, closing [[usb_control_msg(0x21, 2) Exploit|usb_control_msg(0x21, 2)]] vulnerability used by [[blackra1n]], [[redsn0w]], et. al.

==2009==
===November===
*November 3 -- [[User:Geohot|geohot]] releases [[blackra1n]] RC3, a software jailbreak for all devices. Includes a new unlock for baseband [[5.11.07]] called [[blacksn0w]] and is also noticeably faster than previous versions.

===October===
*October 11 -- [[User:Geohot|geohot]] releases [[blackra1n]] RC1, a 30 second software jailbreak for all devices, including a [[tethered jailbreak]] for the [[N18ap|iPod touch 3G]], and [[N88ap|iPhone 3GS]] and [[N72ap|iPod touch 2G]] units with newer bootrom revisions.

===September===
* September 24 -- [[User:iH8sn0w|iH8sn0w]] discovers the [[AT+XEMN Heap Overflow|AT+XEMN]] crash independently.
* September 9 -- The [[N18ap|iPod touch 3G]] with [[S5L8922]] processor is released. [[N72ap|iPod touch 2G]] units continue shipping, but with [[iBoot-240.5.1|a new bootrom]]. [[N88ap|iPhone 3GS]] units also begin shipping with [[iBoot-359.3.2|a new bootrom]]. These are no longer vulnerable to the [[0x24000 Segment Overflow]].
* Apple releases iOS 3.1/3.1.1 (7C144/7C145), closing the [[iBoot Environment Variable Overflow]] and [[AT+XLOG Vulnerability|AT+XLOG]] + [[AT+FNS]] Baseband Exploits.

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

===June===
* June 28 -- [[User:Geohot|geohot]] posts pictures on his blog of the first fully jailbroken [[N88ap|iPhone 3GS]].
* June 25 -- It's discovered that [[N88ap|iPhone 3GS]] is vulnerable to the [[0x24000 Segment Overflow]].
* June 24 -- The [[iPhone Dev Team]] releases [[ultrasn0w]], an [[unlock]] for [[X-Gold 608]] thanks to [[AT+XLOG Vulnerability|a new exploit]] discovered by [[User:Oranav|Oranav]].
* June 23 -- [[User:Geohot|geohot]] announces he's found a new exploit in [[iBoot (Bootloader)|iBoot]] he calls [[purplera1n]].
* June 19 -- Release of [[N88ap|iPhone 3GS]] to the public and the release of [[PwnageTool]] 3.0 and [[redsn0w]] for jailbreaking devices running iOS 3.0
* June 17 -- Apple releases iOS 3.0.
* June 8 -- Apple announces the [[N88ap|iPhone 3GS]].

===March===
* March 10 -- Information about the [[0x24000 Segment Overflow]] exploit used for the [[N72ap|iPod touch 2G]] [[untethered jailbreak]] is released thanks to the combined work of [[chronic]], [[CPICH]], [[User:Posixninja|posixninja]], [[User:Pod2g|pod2g]], [[ius]], [[planetbeing]], [[User:MuscleNerd|MuscleNerd]], and co. after being leaked and sold by [[NitroKey]]. To prevent users wasting their money on a stolen exploit, the Hybrid DevTeam decided to release it immediately.

===January===
* January 31 -- The [[iPhone Dev Team]] released [[redsn0w Lite]], a [[tethered jailbreak|tethered]] [[N72ap|iPod touch 2G]] [[jailbreak]]. It combines the [[ARM7 Go]] vulnerability with the well-established [[pwnage]] flow for other Apple mobile devices. It was bundled in a way that allowed usage on iOS 2.2.1 by uploading [[iBoot (Bootloader)|iBoot]] from iOS 2.1.1, which is vulnerable to [[ARM7 Go]], to the device while in [[DFU Mode]].
* January 29 -- Apple releases iOS 2.2.1, closing the [[AT+stkprof]] exploit.
* January 25 -- [[0wnboot]] is released to [http://code.google.com/p/chronicdev/ chronicdev google code page], thanks to [[AriX]], [[User:ChronicDev|chronic]], [[CPICH]], [[westbaer]], [[ius]], [[User:Pod2g|pod2g]], the rest of the iPod devel crew on IRC, and to the #iphone-hax lab rats. Within days, [[AriX]] and the [[Chronic Dev (team)|Chronic Dev Team]] got a ramdisk booting for a [[tethered jailbreak]].
* January 17 -- [[User:MuscleNerd|MuscleNerd]] of the [[iPhone Dev Team]] [https://twitter.com/MuscleNerd/status/1127346766 shows a video demo] of the first jailbroken [[N72ap|iPod touch 2G]].
* January 16 -- [[ARM7 Go]] vulnerability disclosed where else but here on The iPhone Wiki, for developers to poke and prod at.
* January 15 -- The [[iPhone Dev Team]] [https://twitter.com/iphone_dev/status/1120595069 tweets the VFDecrypt key] for iOS 2.2 on [[N72ap|iPod touch 2G]], demonstrating for the first time that unsigned code can now be run on that device.
* January 1 -- The [[iPhone Dev Team]] releases [[yellowsn0w]] 0.9 beta for baseband [[2.28.00]].

==2008==
===December===
* December 27 -- [[25C3 presentation "Hacking the iPhone"]]
* December 21 -- [[User:MuscleNerd|MuscleNerd]], of the [[iPhone Dev Team]] does a live demo of the 3G unlock, dubbed as [[yellowsn0w]]: http://qik.com/video/729275

===November===
* November 21 -- Apple releases iOS 2.2.

===September===
* September 9 -- Apple releases iOS 2.1. [[N72ap|iPod touch 2G]], which no longer had the [[Pwnage 2.0]] exploit, is revealed.

===August===
* August 18 -- Apple releases 2.0.2 fimware. [[iPhone 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.
* August 4 -- Apple releases 2.0.1 fimware

===July===
* July 22 -- [[TA_Mobile]] hardware dumps the 3G baseband (bootloader 5.8 & FW 1.45.00) by desoldering the [[NOR]].
* July 19 -- [[iPhone Dev Team]] releases [[PwnageTool]] 2.0, jailbreaking and unlocking the 2.0 software on the [[M68ap|iPhone 2G]] and jailbreaking iOS 2.0 on the [[N82ap|iPhone 3G]] and [[N45ap|iPod touch]].
* July 15 -- Apple releases iOS 1.1.5, the last of the 1.x firmwares
* July 11 -- [[N82ap|iPhone 3G]] is released. Apple releases iOS 2.0 and MobileMe on the same date, resulting in server issues.

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

===April===
* April 3 -- [[iPhone 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 -- [[iPhone Dev Team|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+]].

===February===
* February 28 -- [[Cydia Application|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 26 -- Apple releases iOS 1.1.4.
* February 11 -- [[User:Zibri|Zibri]] leaks the [[Ramdisk Hack]] in [[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 -- [[iPhone Dev Team]] releases [[Soft Upgrade]] jailbreak for 1.1.3.
* January 24 -- [[Nate True]] releases a version of [[iBrickr]] that used the [[Soft Upgrade]] method to jailbreak 1.1.3 for [[M68ap|iPhones]].
* January 18 -- [[User:Geohot|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 -- [[iPhone Dev Team]] posts YouTube video of a jailbroken 1.1.3, which was made possible by the dual boot jailbreak from [[bgm]].
* January 15 -- Apple releases iOS 1.1.3, closing the [[Mknod]] exploit. In addition, everything now runs as "mobile" instead of "root."

== 2007 ==
===November===
* November 15 -- [[Baseband Bootloader|Baseband bootloader]] 4.6 is found on new [[M68ap|iPhone]]s, which initially had no [[unlock]].
* November 12 -- Apple releases iOS 1.1.2, closing the [[LibTiff]] and [[Symlinks]] exploits.
* November 2 -- [[JailbreakMe|AppSnapp]] is released, bringing jailbreaking to the mainstream iPhone user.

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

===September===
* September 27 -- Apple releases iOS 1.1.1.
* September 11 -- [[iPhone Dev Team]] releases [[iUnlock]], first free software unlock.
* September 10 -- [[IPSF]] releases first paid software unlock.
* September 9 -- Apple announces the [[N45ap|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 -- [[iPhone 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 -- [[M68ap|iPhone]] is released. World's most hyped consumer product.
* June 26 -- The [[iPhone Dev Team]] was formed.

NitroKey

2010-10-05T20:31:03Z

Littlemartian:

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

They also released a '''stolen''' version of the [[0x24000 Segment Overflow]], the vulnerability that the untethered [[N72ap|iPod Touch 2G]] jailbreak uses, giving Apple enough time to fix the [[N18ap|iPod Touch 3G]] so that it CAN NOT be directly jailbroken from its release. In addition, NitroKey's irresponsible handling gave Apple enough time to add the [[ECID]] tag to the [[IMG3 File Format]] in the [[N88AP|iPhone 3GS]], preventing a permanent untethered [[jailbreak]] without a new [[iBoot]] exploit in every firmware.

NitroKey has also leaked [[AT+FNS]], a [[baseband]] hole which was meant to be kept secret. [http://nitrokey.com/Hash.html] The hash was posted by NitroKey one day after [[User:Oranav|Oranav]] found and shared the exploit with the [[iPhone Dev Team]], making things very suspicious. Apple has now patched the hole, needlessly burning an exploit that could have been used as an unlock vector for a future firmware.

May the thieving bastards of NitroKey burn in hell for all eternity. Their selfish leaks have done nothing short of hold the entire Jailbreak community backwards in the name of pure selfish desires. For this, the actions of NitroKey are condemned, with the suggestion they exercise sincere moral introspection before continuing their inconsiderate and obtuse line of action.
The Jailbreak community has always kept the interests of the public and developers as the foremost topic on their agenda. NitroKey stand as a damning symbol against this, and for these reasons, we ask you all to stand with us and shout: '''SCREW NITROKEY'''.

NitroKey

2010-10-05T20:21:36Z

Littlemartian:

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

They also released a stolen version of the [[0x24000 Segment Overflow]], the vulnerability that the untethered [[N72ap|iPod Touch 2G]] jailbreak uses, giving Apple enough time to fix the [[N18ap|iPod Touch 3G]] so that it CAN NOT be directly jailbroken from its release. In addition, NitroKey's irresponsible handling gave Apple enough time to add the [[ECID]] tag to the [[IMG3 File Format]] in the [[N88AP|iPhone 3GS]], preventing a permanent untethered [[jailbreak]] without a new [[iBoot]] exploit in every firmware.

NitroKey has also leaked [[AT+FNS]], a [[baseband]] hole which was meant to be kept secret. [http://nitrokey.com/Hash.html] The hash was posted by NitroKey one day after [[User:Oranav|Oranav]] found and shared the exploit with the [[iPhone Dev Team]], making things very suspicious. Apple has now patched the hole, needlessly burning an exploit that could have been used as an unlock vector for a future firmware.

May the bastards of NitroKey burn in hell for all eternity.
We know where they live.

AT+XEMN Heap Overflow

2009-10-28T08:08:26Z

Littlemartian:

AT+XEMN is a command on baseband 5.11.07 (pushed out with official 3.1.2 firmware), which when exploited correctly, causes a heap overflow allowing the crash to be moulded into an injection vector. This injection vector can then be used to inject the Ultrasn0w/Generic Unlocking Payload to provide a coveted Software Sim Unlock on Official 3.1.2 running 5.11.07

== Exception Dump ==
+XLOG: Exception Number: 1
Trap Class: 0xDDDD (SW GENERATED TRAP)
Identification: 140 (0x008C)
Date: 22.10.2009
Time: 00:30
File: atform/text/_malloc.c
Line: 1036
Logdata:
2E 0C 76 ED 40 14 31 64 61 74 63 3A 31 00 64 63 ..v.@.1datc:1.dc
20 44 F4 E9 20 20 20 20 20 20 20 20 20 20 20 20 D..
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20

== July 2009 ==
*Oranav discovers this command.
*Shortly after discovered, The iPhone Dev Team, confirms that the command is non-exploitable.
*There was no talk about this command.

== September 2009 ==
*iH8sn0w discovered this command but kept it a secret for about a month - http://twitter.com/iH8sn0w/status/4353547726

== October 2009 ==
*When the Dev-Team stated that iH8sn0w did not have a unlock, he posted the command on Twitter - http://twitter.com/iH8sn0w/status/4954333558.
*Shortly after, Oranav discovered this, and posted his Hash from July - http://pastebin.ca/1485104.
*MuscleNerd tells iHacker that the command was received awhile ago and was non-exploitable - http://twitter.com/MuscleNerd/status/4978871033 | http://twitter.com/iHacker/status/4978821448
*GeoHot attempts to use this command, but later finds out aswell that it is non-exploitable - http://twitter.com/geohot/status/4979506974
*The hunt for another exploit continues as New 3G/3G[S] users join or if 3G/3G[S] users upgrade to Official Apple Firmware.
*Geohot does more investigation and discovers that this command is indeed exploitable - http://twitter.com/geohot/status/5196861045

AT+XEMN Heap Overflow

2009-10-28T08:06:30Z

Littlemartian:

AT+XEMN is a command on baseband 5.11.07, which when exploited correctly, causes a heap overflow allowing the crash to be moulded into an injection vector. This injection vector can then be used to inject the Ultrasn0w Payload to provide a coveted Software Sim Unlock on Official 3.1.2 running 5.11.07

== Exception Dump ==
+XLOG: Exception Number: 1
Trap Class: 0xDDDD (SW GENERATED TRAP)
Identification: 140 (0x008C)
Date: 22.10.2009
Time: 00:30
File: atform/text/_malloc.c
Line: 1036
Logdata:
2E 0C 76 ED 40 14 31 64 61 74 63 3A 31 00 64 63 ..v.@.1datc:1.dc
20 44 F4 E9 20 20 20 20 20 20 20 20 20 20 20 20 D..
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20

== July 2009 ==
*Oranav discovers this command.
*Shortly after discovered, The iPhone Dev Team, confirms that the command is non-exploitable.
*There was no talk about this command.

== September 2009 ==
*iH8sn0w discovered this command but kept it a secret for about a month - http://twitter.com/iH8sn0w/status/4353547726

== October 2009 ==
*When the Dev-Team stated that iH8sn0w did not have a unlock, he posted the command on Twitter - http://twitter.com/iH8sn0w/status/4954333558.
*Shortly after, Oranav discovered this, and posted his Hash from July - http://pastebin.ca/1485104.
*MuscleNerd tells iHacker that the command was received awhile ago and was non-exploitable - http://twitter.com/MuscleNerd/status/4978871033 | http://twitter.com/iHacker/status/4978821448
*GeoHot attempts to use this command, but later finds out aswell that it is non-exploitable - http://twitter.com/geohot/status/4979506974
*The hunt for another exploit continues as New 3G/3G[S] users join or if 3G/3G[S] users upgrade to Official Apple Firmware.
*Geohot does more investigation and discovers that this command is indeed exploitable - http://twitter.com/geohot/status/5196861045

0x24000 Segment Overflow

2009-10-17T13:57:26Z

Littlemartian: /* Timing Impact */

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]].

As of October 2009, seven months after the exposure of this hole, Apple is now selling updated [[iPhone 3GS]] and [[N72ap|iPod Touch 2G]] units with a new bootrom, erasing the vulnerability used by this exploit.

==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 though it was too late to patch the bootrom, it was not too late for Apple to repair the restore process in the stock IPSW, removing the method used 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 were able to prioritize a fix for this oversight thus making the permanent [[pwnage]] of future devices significantly more difficult.

Thanks to irresponsible handling of the exploit by a third-party company known as [[NitroKey]] who were interested in making financial gain from the work of others, this eventuality became a near-certainty and pretty much erased the possibility of a day-of-release jailbreak for the [[iPhone 3GS]] and the third-generation iPod touch. In addition, to counteract the exploit, with the early exposure of the exploit, Apple were able to add the [[ECID]] tag to the [[IMG3 File Format|IMG3 format]] in the iPhone 3GS. The early leak of the exploit allowed Apple to understand that an iBoot exploit would be necessary to flash the required oversized LLB and through doing so, Apple have prevented this exploit from allowing the iPhone 3GS to be permanently jailbroken through this exploit unless new iBoot exploits (allowing unsigned code to be run) can be found in every firmware release or a signed copy of an (older) vulnerable version of iBoot is stored.

May the bastards of 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-10-16T17:22:46Z

Littlemartian:

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]].

As of October 2009, seven months after the exposure of this hole, Apple is now selling updated [[iPhone 3GS]] and [[N72ap|iPod Touch 2nd Generation]] units with a new bootrom, erasing the vulnerability used by this exploit.

==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 though it was too late to patch the bootrom, it was not too late for Apple to repair the restore process in the stock IPSW, removing the method used 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 were able to prioritize a fix for this oversight thus making the permanent [[pwnage]] of future devices significantly more difficult.

Thanks to irresponsible handling of the exploit by a third-party company known as [[NitroKey]] who were interested in making financial gain from the work of others, this eventuality became a near-certainty and pretty much erased the possibility of a day-of-release jailbreak for the [[iPhone 3GS]] and the third-generation iPod touch. In addition, to counteract the exploit, with the early exposure of the exploit, Apple were able to add the [[ECID]] tag to the [[IMG3 File Format|IMG3 format]] in the iPhone 3GS. The early leak of the exploit allowed Apple to understand that an iBoot exploit would be necessary to flash the required oversized LLB and through doing so, Apple have prevented this exploit from allowing the iPhone 3GS to be permanently jailbroken through this exploit unless new iBoot hacks can be found in every firmware release.

May the bastards of 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-10-13T19:16:06Z

Littlemartian: /* Timing Impact */

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]].

==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 though it was too late to patch the bootrom, it was not too late for Apple to repair the restore process in the stock IPSW, removing the method used 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 were able to prioritize a fix for this oversight thus making the permanent [[pwnage]] of future devices significantly more difficult.

Thanks to irresponsible handling of the exploit by a third-party company known as [[NitroKey]] who were interested in making financial gain from the work of others, this eventuality became a near-certainty and pretty much erased the possibility of a day-of-release jailbreak for the [[iPhone 3GS]] and the third-generation iPod touch. In addition, to counteract the exploit, with the early exposure of the exploit, Apple were able to add the [[ECID]] tag to the [[IMG3 File Format|IMG3 format]] in the iPhone 3GS. The early leak of the exploit allowed Apple to understand that an iBoot exploit would be necessary to flash the required oversized LLB and through doing so, Apple have prevented this exploit from allowing the iPhone 3GS to be permanently jailbroken through this exploit unless new iBoot hacks can be found in every firmware release.

'''''== May the bastards of NitroKey burn in hell for all eternity. =='''''

'''As of October 2009, seven months after the exposure of this hole, Apple are now selling 'updated' iPhone3GS units with a 'corrected' bootrom, erasing the vulnerability used by this exploit.'''

==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-10-13T19:15:53Z

Littlemartian: /* Timing Impact */

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]].

==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 though it was too late to patch the bootrom, it was not too late for Apple to repair the restore process in the stock IPSW, removing the method used 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 were able to prioritize a fix for this oversight thus making the permanent [[pwnage]] of future devices significantly more difficult.

Thanks to irresponsible handling of the exploit by a third-party company known as [[NitroKey]] who were interested in making financial gain from the work of others, this eventuality became a near-certainty and pretty much erased the possibility of a day-of-release jailbreak for the [[iPhone 3GS]] and the third-generation iPod touch. In addition, to counteract the exploit, with the early exposure of the exploit, Apple were able to add the [[ECID]] tag to the [[IMG3 File Format|IMG3 format]] in the iPhone 3GS. The early leak of the exploit allowed Apple to understand that an iBoot exploit would be necessary to flash the required oversized LLB and through doing so, Apple have prevented this exploit from allowing the iPhone 3GS to be permanently jailbroken through this exploit unless new iBoot hacks can be found in every firmware release.

'''''== May the bastards of NitroKey burn in hell for all eternity. =='''''
'''
As of October 2009, seven months after the exposure of this hole, Apple are now selling 'updated' iPhone3GS units with a 'corrected' bootrom, erasing the vulnerability used by this exploit.
'''

==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-10-13T19:14:07Z

Littlemartian: /* Timing Impact */

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]].

==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 though it was too late to patch the bootrom, it was not too late for Apple to repair the restore process in the stock IPSW, removing the method used 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 were able to prioritize a fix for this oversight thus making the permanent [[pwnage]] of future devices significantly more difficult.

Thanks to irresponsible handling of the exploit by a third-party company known as [[NitroKey]] who were interested in making financial gain from the work of others, this eventuality became a near-certainty and pretty much erased the possibility of a day-of-release jailbreak for the [[iPhone 3GS]] and the third-generation iPod touch. In addition, to counteract the exploit, with the early exposure of the exploit, Apple were able to add the [[ECID]] tag to the [[IMG3 File Format|IMG3 format]] in the iPhone 3GS. The early leak of the exploit allowed Apple to understand that an iBoot exploit would be necessary to flash the required oversized LLB and through doing so, Apple have prevented this exploit from allowing the iPhone 3GS to be permanently jailbroken through this exploit unless new iBoot hacks can be found in every firmware release.

'''''== May the bastards of NitroKey burn in hell for all eternity. =='''''

As of October 2009, seven months after the exposure of this hole, Apple are now issuing 'updated' iPhone3GS units with a 'corrected' bootrom, erasing the vulnerability used by this exploit.

==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-10-13T18:50:34Z

Littlemartian: /* Timing Impact */

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]].

==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 though it was too late to patch the bootrom, it was not too late for Apple to repair the restore process in the stock IPSW, removing the method used 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 were able to prioritize a fix for this oversight thus making the permanent [[pwnage]] of future devices significantly more difficult.

Thanks to irresponsible handling of the exploit by a third-party company known as [[NitroKey]] who were interested in making financial gain from the work of others, this eventuality became a near-certainty and pretty much erased the possibility of a day-of-release jailbreak for the [[iPhone 3GS]] and the third-generation iPod touch. In addition, to counteract the exploit, with the early exposure of the exploit, Apple were able to add the [[ECID]] tag to the [[IMG3 File Format|IMG3 format]] in the iPhone 3GS. The early leak of the exploit allowed Apple to understand that an iBoot exploit would be necessary to flash the required oversized LLB and through doing so, Apple have prevented this exploit from allowing the iPhone 3GS to be permanently jailbroken through this exploit unless new iBoot hacks can be found in every firmware release.

'''''== May the bastards of NitroKey burn in hell for all eternity. =='''''

As of October 2009, seven months after the exposure of this hole, Apple have begun selling new iPhone3GS units with a 'corrected' bootrom, disabling the exploitation of this exploit.

==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-09-13T17:12:25Z

Littlemartian: /* Timing Impact */

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]].

==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 though it was too late to patch the bootrom, it was not too late for Apple to repair the restore process in the stock IPSW, removing the method used 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 were able to prioritize a fix for this oversight thus making the permanent [[pwnage]] of future devices significantly more difficult.

Thanks to irresponsible handling of the exploit by a third-party company known as [[NitroKey]] who were interested in making financial gain from the work of others, this eventuality became a near-certainty and pretty much erased the possibility of a day-of-release jailbreak for the [[iPhone 3GS]] and the third-generation iPod touch. In addition, to counteract the exploit, with the early exposure of the exploit, Apple were able to add the [[ECID]] tag to the [[IMG3 File Format|IMG3 format]] in the iPhone 3GS. The early leak of the exploit allowed Apple to understand that an iBoot exploit would be necessary to flash the required oversized LLB and through doing so, Apple have prevented this exploit from allowing the iPhone 3GS to be permanently jailbroken through this exploit unless new iBoot hacks can be found in every firmware release.

'''''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-09-13T17:12:05Z

Littlemartian: /* Timing Impact */

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]].

==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 though it was too late to patch the bootrom, it was not too late for Apple to repair the restore process in the stock IPSW, removing the method used 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 were able to prioritize a fix for this oversight thus making the permanent [[pwnage]] of future devices significantly more difficult.

Thanks to irresponsible handling of the exploit by a third-party company known as [[NitroKey]] who were interested in making financial gain from the work of others, this eventuality became a near-certainty and pretty much erased the possibility of a day-of-release jailbreak for the [[iPhone 3GS]] and the third-generation iPod touch. In addition, to counteract the exploit, with the early exposure of the exploit, Apple were able to add the [[ECID]] tag to the [[IMG3 File Format|IMG3 format]] in the iPhone 3GS. The early leak of the exploit allowed Apple to understand that an iBoot exploit would be necessary to flash the required oversized LLB and through doing so, Apple have prevented this exploit from allowing the iPhone 3GS to be permanently jailbroken through this exploit unless new iBoot hacks can be found in every firmware release.

''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-09-13T17:11:51Z

Littlemartian: /* Timing Impact */

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]].

==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 though it was too late to patch the bootrom, it was not too late for Apple to repair the restore process in the stock IPSW, removing the method used 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 were able to prioritize a fix for this oversight thus making the permanent [[pwnage]] of future devices significantly more difficult.

Thanks to irresponsible handling of the exploit by a third-party company known as [[NitroKey]] who were interested in making financial gain from the work of others, this eventuality became a near-certainty and pretty much erased the possibility of a day-of-release jailbreak for the [[iPhone 3GS]] and the third-generation iPod touch. In addition, to counteract the exploit, with the early exposure of the exploit, Apple were able to add the [[ECID]] tag to the [[IMG3 File Format|IMG3 format]] in the iPhone 3GS. The early leak of the exploit allowed Apple to understand that an iBoot exploit would be necessary to flash the required oversized LLB and through doing so, Apple have prevented this exploit from allowing the iPhone 3GS to be permanently jailbroken through this exploit unless new iBoot hacks can be found in every firmware release.

==== '''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-09-13T17:11:36Z

Littlemartian: /* Timing Impact */

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]].

==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 though it was too late to patch the bootrom, it was not too late for Apple to repair the restore process in the stock IPSW, removing the method used 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 were able to prioritize a fix for this oversight thus making the permanent [[pwnage]] of future devices significantly more difficult.

Thanks to irresponsible handling of the exploit by a third-party company known as [[NitroKey]] who were interested in making financial gain from the work of others, this eventuality became a near-certainty and pretty much erased the possibility of a day-of-release jailbreak for the [[iPhone 3GS]] and the third-generation iPod touch. In addition, to counteract the exploit, with the early exposure of the exploit, Apple were able to add the [[ECID]] tag to the [[IMG3 File Format|IMG3 format]] in the iPhone 3GS. The early leak of the exploit allowed Apple to understand that an iBoot exploit would be necessary to flash the required oversized LLB and through doing so, Apple have prevented this exploit from allowing the iPhone 3GS to be permanently jailbroken through this exploit unless new iBoot hacks can be found in every firmware release.

== '''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-09-13T17:11:19Z

Littlemartian: /* Timing Impact */

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]].

==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 though it was too late to patch the bootrom, it was not too late for Apple to repair the restore process in the stock IPSW, removing the method used 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 were able to prioritize a fix for this oversight thus making the permanent [[pwnage]] of future devices significantly more difficult.

Thanks to irresponsible handling of the exploit by a third-party company known as [[NitroKey]] who were interested in making financial gain from the work of others, this eventuality became a near-certainty and pretty much erased the possibility of a day-of-release jailbreak for the [[iPhone 3GS]] and the third-generation iPod touch. In addition, to counteract the exploit, with the early exposure of the exploit, Apple were able to add the [[ECID]] tag to the [[IMG3 File Format|IMG3 format]] in the iPhone 3GS. The early leak of the exploit allowed Apple to understand that an iBoot exploit would be necessary to flash the required oversized LLB and through doing so, Apple have prevented this exploit from allowing the iPhone 3GS to be permanently jailbroken through this exploit unless new iBoot hacks can be found in every firmware release.

'''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-09-13T17:11:04Z

Littlemartian: /* Timing Impact */

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]].

==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 though it was too late to patch the bootrom, it was not too late for Apple to repair the restore process in the stock IPSW, removing the method used 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 were able to prioritize a fix for this oversight thus making the permanent [[pwnage]] of future devices significantly more difficult.

Thanks to irresponsible handling of the exploit by a third-party company known as [[NitroKey]] who were interested in making financial gain from the work of others, this eventuality became a near-certainty and pretty much erased the possibility of a day-of-release jailbreak for the [[iPhone 3GS]] and the third-generation iPod touch. In addition, to counteract the exploit, with the early exposure of the exploit, Apple were able to add the [[ECID]] tag to the [[IMG3 File Format|IMG3 format]] in the iPhone 3GS. The early leak of the exploit allowed Apple to understand that an iBoot exploit would be necessary to flash the required oversized LLB and through doing so, Apple have prevented this exploit from allowing the iPhone 3GS to be permanently jailbroken through this exploit unless new iBoot hacks can be found in every firmware release.
'''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-30T18:25:02Z

Littlemartian: /* Timing Impact */

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 though it was too late to patch the bootrom, it was not too late for Apple to repair the restore process in the stock IPSW, removing the method used 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 were able to prioritize a fix for this oversight thus making the permanent [[pwnage]] of future devices significantly more difficult.

Thanks to irresponsible handling of the exploit by a third-party company known as [[NitroKey]] who were interested in making financial gain from the work of others, this eventuality became a near-certainty and pretty much erased the possibility of a day-of-release jailbreak for the [[iPhone 3GS]] and the third-generation iPod touch. In addition, to counteract the exploit, with the early exposure of the exploit, Apple were able to add the [[ECID]] tag to the [[IMG3 File Format|IMG3 format]] in the iPhone 3GS. The early leak of the exploit allowed Apple to understand that an iBoot exploit would be necessary to flash the required oversized LLB and through doing so, Apple have prevented this exploit from allowing the iPhone 3GS to be permanently jailbroken through this exploit unless new iBoot hacks can be found in every firmware release. 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]]

Timeline

2009-07-27T10:43:44Z

Littlemartian: /* January */

==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 and the release of [[PwnageTool|Pwnage Tool 3.0]] and [[RedSn0w|Redsn0w]] for jailbreaking devices running firmware 3.0
* 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 after being leaked and sold by [[NitroKey]]. To prevent users wasting their money on a stolen exploit, the Hybrid DevTeam decided to release it immediately.

===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 through uploading the [[ARM7_Go]] vulnerable 2.1.1 iBoot to the device while in DFU mode.

* 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.

Redsn0w

2009-07-27T10:39:40Z

Littlemartian: /* Exploit */

The redsn0w program (at version 0.1) was originally a quickpwn-like implementation of the [[0x24000 Segment Overflow]] for the [[N72ap|iPod Touch 2G]].
However, due to the theft and exploitation of the quickPWN name by quickpwn.com, as of firmware 3.0, quickpwn was discontinued and redsn0w (at the time, version 0.7) was converted into a jailbreaking tool for all current devices as well as providing unlock support the iPhone 2G. As of version 0.8, the [[N88ap|iPhone 3GS]] can also be jailbroken through redsn0w. It is currently closed-sourced but the executable is being worked into several third-party GUIs as the underlying engine can also be used as a commandline tool.

== Credit ==
[[iPhone Dev Team]]

== Exploit ==
For [[iPod Touch]], [[iPhone]] and [[iPhone 3G]], see:
*[[Pwnage_2.0|Pwnage 2.0]]

For [[N72ap|iPod Touch 2G]], see:
*[[0x24000 Segment Overflow]] Credit for this exploit work goes to a mixture of the [[User:ChronicDev|Chronic Dev]] and the iPhone Dev Team.
*[[ARM7_Go]] used to upload the oversized LLB required to take advantage of 24kPWN.

For [[iPhone 3GS]], see:
*[[0x24000 Segment Overflow]]
*[[IBoot_Environment_Variable_Overflow|iBoot Environmental Variable Overflow]]

== Download ==
* http://redsn0w.com/

Redsn0w

2009-07-27T10:37:10Z

Littlemartian:

The redsn0w program (at version 0.1) was originally a quickpwn-like implementation of the [[0x24000 Segment Overflow]] for the [[N72ap|iPod Touch 2G]].
However, due to the theft and exploitation of the quickPWN name by quickpwn.com, as of firmware 3.0, quickpwn was discontinued and redsn0w (at the time, version 0.7) was converted into a jailbreaking tool for all current devices as well as providing unlock support the iPhone 2G. As of version 0.8, the [[N88ap|iPhone 3GS]] can also be jailbroken through redsn0w. It is currently closed-sourced but the executable is being worked into several third-party GUIs as the underlying engine can also be used as a commandline tool.

== Credit ==
[[iPhone Dev Team]]

== Exploit ==
For [[iPod Touch]], [[iPhone]] and [[iPhone 3G]], see:
[[Pwnage_2.0|Pwnage 2.0]]

For [[iPod Touch 2G]], see:
[[0x24000 Segment Overflow]] Credit for this exploit work goes to a mixture of the [[User:ChronicDev|Chronic Dev]] and the iPhone Dev Team.
[[Arm7_Go]] used to upload the oversized LLB required to take advantage of 24kPWN.

For [[iPhone 3GS]], see:
[[0x24000 Segment Overflow]]
[[IBoot_Environment_Variable_Overflow|iBoot Environmental Variable Overflow]]

== Download ==
* http://redsn0w.com/

Redsn0w

2009-07-27T10:36:23Z

Littlemartian:

The redsn0w program (at version 0.1) was originally a quickpwn-like implementation of the [[0x24000 Segment Overflow]] for the [[N72ap|iPod Touch 2G]].
However, due to the theft and exploitation of the quickPWN name by quickpwn.com, as of firmware 3.0, quickpwn was discontinued and redsn0w (at the time, version 0.7) was converted into a jailbreaking tool for all current devices as well as providing unlock support the iPhone 2G. As of version 0.8, the [[N88ap|iPhone 3GS]] can also be jailbroken through redsn0w. It is currently closed-sourced but the executable is being worked into several third-party GUIs as the underlying engine as it can also be used as a commandline tool.

== Credit ==
[[iPhone Dev Team]]

== Exploit ==
For [[iPod Touch]], [[iPhone]] and [[iPhone 3G]], see:
[[Pwnage_2.0|Pwnage 2.0]]

For [[iPod Touch 2G]], see:
[[0x24000 Segment Overflow]] Credit for this exploit work goes to a mixture of the [[User:ChronicDev|Chronic Dev]] and the iPhone Dev Team.
[[Arm7_Go]] used to upload the oversized LLB required to take advantage of 24kPWN.

For [[iPhone 3GS]], see:
[[0x24000 Segment Overflow]]
[[IBoot_Environment_Variable_Overflow|iBoot Environmental Variable Overflow]]

== Download ==
* http://redsn0w.com/

Timeline

2009-07-27T10:29:57Z

Littlemartian: /* June */

==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 and the release of [[PwnageTool|Pwnage Tool 3.0]] and [[RedSn0w|Redsn0w]] for jailbreaking devices running firmware 3.0
* 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 after being leaked and sold by [[NitroKey]]. To prevent users wasting their money on a stolen exploit, the Hybrid DevTeam decided to release it immediately.

===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.

Timeline

2009-07-27T10:27:56Z

Littlemartian: /* June */

==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 and the release of Pwnage Tool 3.0 and Redsn0w for jailbreaking devices running firmware 3.0
* 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 after being leaked and sold by [[NitroKey]]. To prevent users wasting their money on a stolen exploit, the Hybrid DevTeam decided to release it immediately.

===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.

NitroKey

2009-07-27T10:26:28Z

Littlemartian:

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

They also released a stolen version of the 24kpwn untethered iPod Touch 2G jailbreak, giving Apple enough time to fix the 3rd generation iPod Touch so that it CANNOT be directly jailbroken from its release. In addition, NitroKey's irresponsible handling gave Apple enough time to add the [[ECID]] tag to the [[IMG3 File Format|IMG3 format]] in the iPhone 3GS, preventing a permanent untethered JB without a new iBoot exploit in every firmware exploit.

NitroKey has also leaked a baseband hole which was meant to be kept in secret - [[AT+FNS]]. [http://nitrokey.com/Hash.html] The hash was posted by NitroKey one day after the exploit was found, making things very suspicious. Apple will now be able to patch this hole, significantly reducing the possibility of an unlock in firmware release 3.1.

May they burn in hell for all eternity.

NitroKey

2009-07-27T10:25:06Z

Littlemartian:

Timeline

2009-07-27T10:20:42Z

Littlemartian: /* March */

==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 after being leaked and sold by [[NitroKey]]. To prevent users wasting their money on a stolen exploit, the Hybrid DevTeam decided to release it immediately.

===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.

Timeline

2009-07-27T10:20:08Z

Littlemartian: /* March */

==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 after being leaked and sold by [[Nitrokey]]. To prevent users wasting their money on a stolen exploit, the Hybrid DevTeam decided to release it immediately.

===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.

Unlock

2009-07-26T20:10:54Z

Littlemartian:

This is the process by which the iPhone baseband is modified to accept the [[SIM]] card of any GSM carrier. This is entirely different than a [[Jailbreak]] though a [[jailbreak]] is required for the current unlocks to take effect.

==Official Unlock==
[[Image:iTunesUnlock.png|thumb|Unlock in iTunes]]
At +0x400 in the [[seczone]], a token is stored encrypted with (NCK + NORID + HWID). Apple, knowing the [[NCK]], sends it using an [[activation token]] over iTunes. The phone receives an AT+CLCK="PN",0,"......NCK......" It decrypts the token with the generated [[Baseband_TEA_Keys|key]]. If that decryption, after deRSAing with Key 2, is a valid token for the phone, it is stored back to that flash with the token TEA, but not RSA decrypted. On startup, if the lockstate table says the phone is unlocked, it validates that RSA token.

==Old AnySim Patch (1.0.X)==
This deprecated patch disabled signature checks. So the RSA signature would always validate, and the phone would always appear to be unlocked and every NCK would appear to be valid. This patch caused the locktables to be rewritten to the unlocked state which resulted in a cypto failure once the patch was removed during a BB upgrade, causing the 0049 IMEI issue. The virginizer was written in response to this problem and allowed users to write locked, virgin locktables. This removed the crypto failure and allowed the application of the ignore MCC/MNC patch.

==New AnySIM Patch (1.1+)==
This patch, also know as the ignore MCC/MNC patch, makes every MCC/MNC pair appear valid. This patch is overwritten on a reflash of the baseband, and doesn't touch the seczone or the locktables at all. It must be reapplied for every baseband upgrade to maintain the unlock.

==IPSF==
See [[IPSF]] for main article. This exploit changed the lockstate table in the [[seczone]] to read unlocked and created a spoofed RSA token that was seen as valid by BL3.9 (BL4.6 was ''not'' vulnerable to IPSF). It overwrote your previous token, which means the phone could nor longer be officially unlocked, unless a restore of the token was performed from a previously made backup. Since the token isn't modified in a baseband flash, this unlock survived a baseband downgrade or upgrade. Apple attempted to combat this by requiring AT+CLCK command to be sent every startup. In a officially unlocked iPhones, lockdownd does this. In a late verion IPSF phone, signal.app does this.

== Cloning Officially Unlocked Phones ==
This has been suggested by many people, however it has been well investigated and virtually ruled out for these reasons:
# Replacing the [[Baseband Bootloader|baseband bootloader]] or [[Baseband Firmware|firmware]] of a locked phone with that of an officially unlocked phone does ''not'' unlock the phone, as the unlock information resides in a different flash area, known as the [[seczone]] and is unique to each phone.
# Cloning the [[seczone]] would duplicate [http://en.wikipedia.org/wiki/International_Mobile_Equipment_Identity IMEIs] which would be illegal in most places and would likely result in a ban of these.
# Phones with cloned seczones would not even be unlocked by the NCKs of the phone they were cloned from as the CHIPID and NORID is concatenated with the NCK to produce the decryption key used on the RSA [[seczone]] token. The only way to make this work is to change the NORID and CHIPID which is not possible at this time.

Untethered jailbreak

2009-07-26T20:08:54Z

Littlemartian:

An untethered jailbreak is a jailbreak where your device does not require you to reboot with a connection to an external device capable of executing commands on the device. Currently, all [[iPhone]]s and [[iPod touch]] models are jailbreakable in this method and, with the exception of the most recent [[iPhone 3GS]], the current released devices will always be subject to [[pwnage]]. The only exception is Linux on your device, where it is still in a [[tethered]] form.

0x24000 Segment Overflow

2009-07-26T20:07:10Z

Littlemartian: /* Timing Impact */

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 though it was too late to patch the bootrom, it was not too late for Apple to repair the restore process in the stock IPSW, removing the method used 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 were able to prioritize a fix for this oversight thus making the permanent [[pwnage]] of future devices significantly more difficult.

Thanks to irresponsible handling of the exploit by a third-party company known as [[NitroKey]] who were interested in making financial gain from the work of others, this eventuality became a near-certainty and pretty much erased the possibility of a day-of-release jailbreak for the [[iPhone 3GS] and the third-generation iPod touch. In addition, to counteract the exploit, with the early exposure of the exploit, Apple were able to add the [[ECID]] tag to the [[IMG3 File Format|IMG3 format]] in the iPhone 3GS. The early leak of the exploit allowed Apple to understand that an iBoot exploit would be necessary to flash the required oversized LLB and through doing so, Apple have prevented this exploit from allowing the iPhone 3GS to be permanently jailbroken through this exploit unless new iBoot hacks can be found in every firmware release. 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-26T20:06:53Z

Littlemartian: /* Timing Impact */

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 though it was too late to patch the bootrom, it was not too late for Apple to repair the restore process in the stock IPSW, removing the method used 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 were able to prioritize a fix for this oversight thus making the permanent[[pwnage]] of future devices significantly more difficult.

Thanks to irresponsible handling of the exploit by a third-party company known as [[NitroKey]] who were interested in making financial gain from the work of others, this eventuality became a near-certainty and pretty much erased the possibility of a day-of-release jailbreak for the [[iPhone 3GS] and the third-generation iPod touch. In addition, to counteract the exploit, with the early exposure of the exploit, Apple were able to add the [[ECID]] tag to the [[IMG3 File Format|IMG3 format]] in the iPhone 3GS. The early leak of the exploit allowed Apple to understand that an iBoot exploit would be necessary to flash the required oversized LLB and through doing so, Apple have prevented this exploit from allowing the iPhone 3GS to be permanently jailbroken through this exploit unless new iBoot hacks can be found in every firmware release. 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-26T20:03:18Z

Littlemartian: /* Timing Impact */

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 has become a near-certainty and pretty much erased the possibility of a day-of-release jailbreak for the third-generation iPod touch. In addition, to counteract the exploit, with the early exposure of the exploit, Apple were able to add the [[ECID]] tag to the [[IMG3 File Format|IMG3 format]] in the iPhone 3GS. The early leak of the exploit allowed Apple to understand that an iBoot exploit would be necessary to flash the required oversized LLB and through doing so, Apple have prevented this exploit from allowing the iPhone 3GS to be permanently jailbroken through this exploit unless new iBoot hacks can be found in every firmware release. 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-26T20:00:09Z

Littlemartian: /* Timing Impact */

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 became a near-certainty and pretty much erased the possibility of a day-of-release jailbreak for the third-generation iPod touch and iPhone 3GS. In addition, to counteract the exploit, Apple 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 to flash the required oversized LLB, and through doing so, prevented these exploits from allowing the phone to be permanently jailbroken through this exploit. 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]]

Jailbreak

2009-07-26T19:57:57Z

Littlemartian: /* iPod Touch 2G */

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]] (hacktivation), 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 but also in the untethered jailbreak to flash the required oversized LLB, thus allowing exploitation of the [[24kpwn|24Kpwn]] vulnerability)
* [[24kpwn]]

===iPhone 3GS===
* [[iBoot Environment Variable Overflow]] (also uses the [[24kpwn]] exploit to make it untethered)

Jailbreak

2009-07-26T19:57:33Z

Littlemartian: /* iPod Touch 2G */

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]] (hacktivation), 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 but also in the untethered jailbreak to flash the required oversized LLB, thus allowing exploitation of the [[24Kpwn]] vulnerability)
* [[24kpwn|24kpwn]]

===iPhone 3GS===
* [[iBoot Environment Variable Overflow]] (also uses the [[24kpwn]] exploit to make it untethered)

Jailbreak

2009-07-26T19:57:06Z

Littlemartian: /* iPod Touch 2G */

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]] (hacktivation), 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 but also in the untethered jailbreak to flash the required oversized LLB, thus allowing exploitation of the [[24Kpwn]] vulnerability)
* [[24kpwn]]

===iPhone 3GS===
* [[iBoot Environment Variable Overflow]] (also uses the [[24kpwn]] exploit to make it untethered)

ARM7 Go

2009-07-26T19:55:19Z

Littlemartian:

This vulnerability is present in 2.1.1 iPod Touch 2G devices, as well as the iBEC / iBSS if you choose to upload it via DFU. It allows the running of unsigned code on the iPod Touch 2G device's ARM7 coprocessor.

'''This exploit cannot be used on an [[iPhone]], [[iPhone 3G]], [[iPhone 3GS]] or [[n45ap|iPod touch 1G]], nor is there any reason for it to be as they have already been jailbroken.'''

==Credit==
chronic and [[iPhone Dev Team]] (independently)

==Exploit==
There is an ARM7 coprocessor in the iPod Touch 2G in addition to the main processor, the ARM11. Like the ADM in the [[S5L8900]] devices, it has access to everything the ARM11 has access to, such as the AES engine, the PKE accelorator, and such. The actual vulnerability is that, in the iPod Touch 2G 2.1.1 firmware, they left behind two commands: arm7_stop and arm7_go. They were promptly removed in 2.2. The arm7_go command had no signature checking, permissions checking, or anything like that.

==Payload==
The command gives the ARM7 the load address (default is 0x09000000) of an "image" you sent it, and it will jump to it. The limitation is, unlike the [[diags]] exploit you cannot just pass a patched iBoot or iBEC. You must write a payload for it to run, but one that patches iBEC or iBoot in memory would do fine.

==Implementations==
Two released payloads are [[RedSn0w]] and [[0wnboot]]

==How to use==
* Enter device in [[DFU]] mode.
* Upload iBSS 2.1.1.
* Unplug and then replug the device.
* Upload payload you wish to execute.
* Run arm7_go command to execute payload.
* Run arm7_stop to stop arm7 processor.

[[Category:Exploits]]

IBoot (Bootloader)

2009-07-26T19:54:42Z

Littlemartian: /* Commands used as an exploit vector */

This is Apple's stage 2 bootloader for all of the iDevices. It runs what is known as [[Recovery Mode]]. It has an interactive interface which can be used over USB or serial.

== Versions ==

*204.3.14 (iPhone 2G [[Firmware]] 1.1.4)

==Commands used as an exploit vector==
* Until 2.0 beta 6, the [[diags]] command would jump to code at the address provided to it. For example, if you sent "diags 0x9000000", it would directly jump to the code at written to 0x9000000. There is now a check that only allows engineering devices to utilize this backdoor.
* In the iPod Touch 2G firmware 2.1.1 iBoot (iBoot version 385.22), the [[ARM7 Go]] command could be used to run a payload on the ARM7 in the iPod Touch 2G.
* The [[iBoot Environment Variable Overflow]] exists in 3.0 iBoot, and is being used by [[purplera1n]] and redsn0w (as of version 0.8) in order to flash the oversized LLB which utilizes the [[24kpwn]] exploit to the iPhone 3GS. While this exploit is present on iPod Touch 2nd Gen, it is not used in favour of the [[ARM7_Go]] exploit.

==OpeniBoot==
There is an open source version of iBoot being made so that Linux on the iPhone will work. You can check out the source [http://github.com/planetbeing/iphonelinux/tree/master/openiboot here]. It is VERY useful if you are ever reversing iBoot and do not feel like finding out what certain hardware registers are yourself.

==Remappings==
<pre>
// n88
0x4FF00000 => 0x0
0x40000000 => 0xC0000000
</pre>

IBoot (Bootloader)

2009-07-26T19:54:29Z

Littlemartian: /* Commands used as an exploit vector */

This is Apple's stage 2 bootloader for all of the iDevices. It runs what is known as [[Recovery Mode]]. It has an interactive interface which can be used over USB or serial.

== Versions ==

*204.3.14 (iPhone 2G [[Firmware]] 1.1.4)

==Commands used as an exploit vector==
* Until 2.0 beta 6, the [[diags]] command would jump to code at the address provided to it. For example, if you sent "diags 0x9000000", it would directly jump to the code at written to 0x9000000. There is now a check that only allows engineering devices to utilize this backdoor.
* In the iPod Touch 2G firmware 2.1.1 iBoot (iBoot version 385.22), the [[ARM7 Go]] command could be used to run a payload on the ARM7 in the iPod Touch 2G.
* The [[iBoot Environment Variable Overflow]] exists in 3.0 iBoot, and is being used by [[purplera1n]] and redsn0w (as of version 0.8) in order to flash the oversized LLB which utilizes the [[24kpwn]] exploit to the iPhone 3GS. While this exploit is present on iPod Touch 2nd Gen, it is not used in favour of the [[ARM7_Go] exploit.

==OpeniBoot==
There is an open source version of iBoot being made so that Linux on the iPhone will work. You can check out the source [http://github.com/planetbeing/iphonelinux/tree/master/openiboot here]. It is VERY useful if you are ever reversing iBoot and do not feel like finding out what certain hardware registers are yourself.

==Remappings==
<pre>
// n88
0x4FF00000 => 0x0
0x40000000 => 0xC0000000
</pre>

IBoot (Bootloader)

2009-07-26T19:53:00Z

Littlemartian:

This is Apple's stage 2 bootloader for all of the iDevices. It runs what is known as [[Recovery Mode]]. It has an interactive interface which can be used over USB or serial.

== Versions ==

*204.3.14 (iPhone 2G [[Firmware]] 1.1.4)

==Commands used as an exploit vector==
* Until 2.0 beta 6, the [[diags]] command would jump to code at the address provided to it. For example, if you sent "diags 0x9000000", it would directly jump to the code at written to 0x9000000. There is now a check that only allows engineering devices to utilize this backdoor.
* In the iPod Touch 2G firmware 2.1.1 iBoot (iBoot version 385.22), the [[ARM7 Go]] command could be used to run a payload on the ARM7 in the iPod Touch 2G.
* The [[iBoot Environment Variable Overflow]] exists in 3.0 iBoot, and is being used by [[purplera1n]] and redsn0w (as of version 0.8) in order to flash oversized LLB which utilizes the [[24kpwn]] exploit.

==OpeniBoot==
There is an open source version of iBoot being made so that Linux on the iPhone will work. You can check out the source [http://github.com/planetbeing/iphonelinux/tree/master/openiboot here]. It is VERY useful if you are ever reversing iBoot and do not feel like finding out what certain hardware registers are yourself.

==Remappings==
<pre>
// n88
0x4FF00000 => 0x0
0x40000000 => 0xC0000000
</pre>