The iPhone Wiki - User contributions [en]

IRecovery

2010-08-11T13:17:48Z

Westbaer:

{{DISPLAYTITLE:iTunes}}
iRecovery is a libusb-based CLI utility for Mac OS X, Linux, and Windows. It is able to talk to [[iBoot]] and [[iBSS]] via USB. It's completely open source; the source code is released under the terms of the GNU GPL v3. The full license text can be found in the LICENSE file on github.

It currently connects to:
* [[DFU 0x1227|0x1227]] ([[DFU]]/[[WTF]] Mode 2.0)
* [[Recovery Mode (Protocols)#Recovery_Mode_2.x_.28DevID.3D0x1281.29|Recovery Mode 0x1281]] (Recovery Mode/iBSS)

==Credits==
westbaer

==Thanks==
[[pod2g]], [[tom3q]], [[planetbeing]], [[User:Geohot|geohot]] and [[posixninja]].

==Features==

===DFU 2.0 (0x1227)===
It can upload a file, such as an [[iBSS]], so that you can unplug and spawn a shell with 0x1281.

===Recovery 2.0 (0x1281)===
====File Uploading====
You can upload a file to 0x9000000 with the following syntax:
./iRecovery -f file
In newer builds that use libusb-1.0 this is now
./iRecovery -u file

====Two-Way Shell====
You can spawn a shell to do all sorts of neat things with the syntax:
./iRecovery -s
Once it has spawned, you can type 'help' and iBoot will respond with its built-in command list.

====Single Command====
./iRecovery -c "command"
Sends a single command to the device *without* spawning a shell.

====usb_control_msg(0x21, 2) Exploit Command====
./iRecovery -k
Sends Chronic Dev's + Geohot's latest usb exploit. Implemented into blackra1n.
This was updated near October 17, 2009. [http://github.com/posixninja/irecovery posixninja's fork]
In newer builds this is now -e

====Auto Boot====
You can now enable auto-boot by running:
./iRecovery -a
or by sending /auto-boot in a shell.

====USB Reset====
Reset USB
./iRecovery -r

====Batch Scripting====
iRecovery now supports batch scripting, this allows you to send commands to iBoot from a pre written list of commands, this also suports scripting such as /auto-boot and /upload <file>
./iRecovery -b <file>
or in a shell:
/batch <file>

====Raw Commands====
You can now send raw commands via the -x21 -x40 or -xA1 flags

==Example Output==

iRecovery -s
<pre>
======================================
::
:: iBSS for n82ap, Copyright 2009, Apple Inc.
::
:: BUILD_TAG: iBoot-596.24
::
:: BUILD_STYLE: RELEASE
::
:: USB_SERIAL_NUMBER: CPID:8900 CPRV:30 CPFM:03 SCEP:05 BDID:04 ECID:000003293C113D76 IBFL:00
::
=======================================

Entering recovery mode, starting command prompt
] printenv
build-style = "RELEASE"
build-version = "iBoot-596.24"
config_board = "n82ap"
loadaddr = "0x9000000"
boot-command = "fsboot"
bootdelay = "0"
auto-boot = "true"
idle-off = "true"
boot-device = "nand0"
boot-partition = "0"
boot-path = "/System/Library/Caches/com.apple.kernelcaches/kernelcache.s5l8900x"
display-color-space = "RGB888"
display-timing = "optC"
framebuffer = "0xfd00000"
secure-boot = "0x1"
</pre>

==Forks==
[http://github.com/iH8sn0w/irecovery iH8sn0w/irecovery]

[http://github.com/GreySyntax/irecovery GreySyntax/irecovery]

==Updates==
A C++ port is also in the works dubbed iRecovery++ (by [[User:GreySyntax|GreySyntax]]). [http://github.com/GreySyntax/iRecoveryplusplus]

A C# port using LibUSBDotNET can be found at (by [[User:GreySyntax|GreySyntax]]). [http://github.com/GreySyntax/Alpine]

A VB.NET port is currently under development (by [[User:Fallensn0w|Fallensn0w]]). [http://github.com/fallensn0w/vbiRecovery]

==Download==
[http://github.com/chronicdev/libirecovery Offical Repository (Maintained) / Download here]

AT+XAPP Vulnerability

2010-06-22T19:42:42Z

Westbaer: Credits & Formatting

Used as an injection vector for the current iPhone 3G and iPhone 3GS unlock payloads‭ - ‬ultrasn0w 0.93‭. ‬Currently available in all baseband versions until 05.13.04‭.‬
‭
== Credit ==

* '''vulnerability''': [http://twitter.com/sherif_hashim sherif_hashim], also discovered independently by [http://twitter.com/westbaer westbaer], also discovered independently by [[geohot]]
* '''exploitation''': [[iPhone Dev Team]]

== Exploit ==

There is a stack overflow in the AT+XAPP‭="..." ‬command‭, ‬which allows unsigned code execution on the [[X-Gold 608]]

at+xapp="‬0000111122223333444455556666777788889999000011112222"‬

applying a string of more than 52‭ ‬characters will trigger the overflow
‭

== Implementation ==

The exploit was used by [[iPhone Dev Team]] in [[Ultrasn0w]] 0.93‭ which is able to unlock 4.26.08‭, ‬5.11.07‭, ‬5.12.01‭ ‬and 5.13.04‭ ‬BB firmwares

----

Category‭: ‬Baseband Exploits

Recovery Mode

2010-03-30T08:34:39Z

Westbaer: It does work on iPhone 2G.

Recovery Mode is a failsafe in [[iBoot]] that is used to reflash the device with a new OS, whether the currently installed one is somehow damaged or the device is undergoing an upgrade via [[iTunes]].

== Entering Recovery Mode ==
# Turn the device completely off and disconnect it from cable/dock.
# Hold down the home button.
# While holding down the home button connect to a computer with a cable (easiest) or dock.
# Keep holding down the home button until you see a connect-to-[[iTunes]] screen (on a QuickPwn'ed phone a drawing of Steve might be shown). You are now in recovery mode.

To escape Recovery Mode and power the phone off simply hold down power and home buttons for ten seconds.

==Protocols==
*[[Recovery Mode 0x1280]] in pre-2.0
*[[Recovery Mode 0x1281]] in 2.0 and above

IRecovery

2009-11-03T16:50:49Z

Westbaer:

iRecovery is a libusb-based commandline utility for Mac OS X , Linux ,and Windows . It is able to talk to the iBoot/iBSS in Apple's iPhone/iPod touch via USB.

It's completely open-source, the source-code is released under the terms of the GNU General Public License version 3.
The full license text can be found in the LICENSE file on github.

It currently connects to 0x1281 (iPhone, iPhone 3G, iPod touch, iPod touch 2G: Recovery Mode/iBSS), 0x1227 (iPhone,
iPhone 3G, iPod touch: WTF Mode; iPod touch 2G: DFU Mode).

==Credits==
westbaer

==Features==

===DFU 2.0 (0x1227)===
It can upload a file, such as an iBSS, so that you can unplug and spawn a shell with 0x1281.

===Recovery 2.0 (0x1281)===
====File Uploading====
You can upload a file to 0x9000000 with the following syntax:
./iRecovery -f file

====Two-Way Shell====
You can spawn a shell to do all sorts of neat things with the syntax:
./iRecovery -s
Once it has spawned, you can type 'help' and iBoot will respond with its built-in command list.

====Single Command====
./iRecovery -c "command"
Sends a single command to the device *without* spawning a shell.

====usb_control_msg(0x21, 2) Exploit Command====
./iRecovery -k
Sends Chronic Dev's + Geohot's latest usb exploit. Implemented into blackra1n.
This was just updated a few days ago. (10/17/09) [http://github.com/posixninja/irecovery posixninja's fork]

==Download==
[http://github.com/westbaer/irecovery Offical Repository / Download here]

0x24000 Segment Overflow

2009-10-13T20:39:26Z

Westbaer: As this has *nothing* to do with NitroKey and/or the 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]] 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-13T20:37:52Z

Westbaer:

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' iPhone 3GS units with a new 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]]

Blackra1n

2009-10-12T13:57:44Z

Westbaer:

== Credit ==
* '''Vulnerability, Exploit''': [[geohot]]

== Info ==
This is geohot's latest [[jailbreak]] utility. It is an updated version of [[purplera1n]] but now uses geohot's implementation of the [[usb_control_msg(0x21, 2) Exploit]].
It has been released for Windows and undoubtedly a Mac version is to follow. It will jailbreak all devices on 3.1, 3.1.1 and 3.1.2.
It will even jailbreak OTB [[N88ap|iPhone 3GS]] and [[N18AP|iPod touch 3G]].

blackra1n does '''not''' support hacktivation, so it will your iPhone will need to be officially activated.

== Links ==
[http://www.blackra1n.com/ Official blackra1n website]
[http://iphonejtag.blogspot.com/ Geohot's blog]

== See also ==
[[greenpois0n]]

Usb control msg(0x21, 2) Exploit

2009-10-06T12:35:24Z

Westbaer:

{{DISPLAYTITLE:usb_control_msg(0x21, 2) Exploit}}
== Credit (Alphabetical) ==
* '''vulnerability''': pod2g and westbaer
* '''exploitation''': ius, chronic, pod2g, and posixninja
* '''payload ([[greenpois0n]])''': chronic and posixninja

== Vulnerability ==
'''pod2g''' and '''westbaer''' discovered, via some reversing + fuzzing, you could overwrite the content of 0x0 thanks to Apple not checking the contents of a register they should have, shown in the disassm below. Now, the reason that this is useful is because the MMU maps whatever is running ([[LLB]], [[iBoot]], etc.) to 0x0 so that if an exception vector is triggered, it would jump to the one designed to be used with what is running, versus jumping to what is normally located at 0x0, the [[S5L8920 (Bootrom)|bootrom]].

All you need to do is send the following (assuming you're using libusb 0.1.x)...
usb_control_msg(iDev, 0x21, 2, 0, 0, 0, 0, 1000);
And thanks to our vulnerability, it will do this:
memcpy(0, LOAD_ADDR, 0x2000);

As you can see, we have full control over the first 0x2000 bytes of iBoot.

=== Disassm ===
<pre>
// R5: a pointer to a buffer is here if requesttype==0xA1.
// however, if requesttype==0x21, R5 is undefined.

SRAM:22009ED2 code_1 ; CODE XREF: handle_file_io_control_req+62�j
SRAM:22009ED2 014 36 49 LDR R1, =usb_file_loadaddr
SRAM:22009ED4 014 36 4B LDR R3, =usb_file_offset
SRAM:22009ED6 014 28 68 LDR R0, [R5]
SRAM:22009ED8 014 09 68 LDR R1, [R1]
SRAM:22009EDA 014 1B 68 LDR R3, [R3]
SRAM:22009EDC 014 22 1C ADDS R2, R4, #0
SRAM:22009EDE 014 C9 18 ADDS R1, R1, R3
SRAM:22009EE0 014 07 F0 94 EF BLX memcpy
SRAM:22009EE4 014 00 2E CMP R6, #0
SRAM:22009EE6 014 53 D0 BEQ return
SRAM:22009EE8 014 01 23 MOVS R3, #1
SRAM:22009EEA 014 33 60 STR R3, [R6]
SRAM:22009EEC 014 50 E0 B return
</pre>

== Exploitation ==
So, how do you actually run code with this? Well, '''chronic''' suggested that since the irq vector was in constant use, we try that, so we were able to simply replace the address of the irq vector handler in the 0x2000 [[iBoot]] chunk that we send with 0x41002000, and then just tack our payload to the end of that chunk. Of course, since we are hijacking the irq exception, you must disable interrupts first. Here is the basic procedure:
* Call enter_critical_task(); disabling interrupts, so that your code can reliably execute.
* Restore 0x38 with the original irq vector address
* '''DO WHAT YOU WANT AT THIS POINT, YOU MAY NOT USE INTERRUPTS'''.
* Call exit_critical_task(); re-enabling interrupts.
* Call the irq handler so that the interrupt request that you jijacked can execute.

=== Roadblocks ===
* If what you send is not 0x2000 bytes, the remainder is filled in with zeroes, which is bad.
* Due to the above rule, you need the first 0x2000 of a decrypted iBoot by the time your payload is done running.
* You must disable interrupts to reliably execute your payload. Due to this, this will rule out the possibility of reading the 0x2000 iBoot chunk needed from NOR, since nor_read(); requires interrupts.

The [[PwnageTool]] method requires an [[IPSW]] to be input in order to create a custom firmware anyway, so the 0x2000 chunk is not an issue. It can just be copied from the [[iBoot]] in the [[IPSW]].

Main Page

2009-09-09T20:07:49Z

Westbaer:

<center>[[Image:Iptwiki.jpg‎]]</center>

{{:Main Page/Welcome}}
<table border="1" width="100%"><tr>
<td style="background-color:orange; text-align:center; width:25%;"><b>[[Jailbreak iPhone2,1|Find bootrom exploit allowing unsigned code exec via USB (S5L8920)]]</b></td>
<td style="background-color:orange; text-align:center; width:25%;"><b>[[Unlock 2.0|Break Chain of Trust (X-Gold 608)]]</b></td>
</tr>
<tr>
<td colspan="4">
<center>[[Disclaimer]]</center>
</td>
</tr>
</table><br />
==Software==
* [[/|Filesystem]]
* [[Firmware]]
* [[Keys]]
* [[Protocols]]
* [[System Log]]

==Hardware==
=== iPhone ===
* [[m68ap|iPhone (m68ap)]]
* [[n82ap|iPhone 3G (n82ap)]]
* [[N88AP|iPhone 3GS (n88ap)]]

=== iPod touch ===
* [[n45ap|iPod touch (n45ap)]]
* [[n72ap|iPod touch 2nd Generation (n72ap)]]
* [[N18AP|iPod touch 3rd Generation (n18ap)]]

==App Processor ([[Jailbreak]])==
The [[iPhone]], [[iPod touch]], and [[iPhone 3G]] makes use of the [[S5L8900]] platform as application processor. Current models, such as the [[iPod touch 2G]] and the [[N88AP|iPhone 3GS]], use newer processors. The [[S5L8720]] and [[S5L8920]] are used, respectively. Here is where the [[Jailbreak|jailbreak]] applies.

==Baseband ([[Unlock]])==
The [[Baseband Device]] is where the [[unlock]] applies.

==Application Development==
* [[Toolchain]] (Includes tutorials)
* [[Toolchain 2.0]] (Includes tutorials)
* [[Frameworks]]
* [[MobileDevice Library]]
* [[Apple Certification Process]]
* [[Bypassing iPhone Code Signatures]]
* [[Distribution Methods]]

==Application Copy Protection==
* [[Copy Protection Overview]]
* [[Application Structure and Signatures]]
* [[Mach-O Loading Process]]
* [[Bugging Debuggers]]

==Definitions==
* [[Jailbreak]]
* [[Activation]]
* [[Unlock]]
* [[Baseband Device|Baseband]]
* [[Baseband Bootloader|Bootloader]]
* [[DFU]]
* [[iBoot]]
* [[iBEC]]
* [[iBSS]]
* [[NORID]]
* [[CHIPID]]

==Other==
* [[Bluetooth]]
* [[Glossary]]
* [[Tutorials]]
* [[Useful Links]]

Purplera1n

2009-07-13T20:39:02Z

Westbaer:

== Credit ==
[[geohot]]

Mac OS X client: AriX, and westbaer.

== Phase 1: Signature Grabber ==
* '''Blog Post''': http://iphonejtag.blogspot.com/2009/06/usbdump-huh-how.html

Allows anyone with a [[N88AP|3GS]] right now to generate a file that contains:
* The [[ECID|Exclusive Chip ID tag]] for your device
* The new RSA signature for a 3.0GM [[N88AP|iPhone 3GS]] iBSS that includes your ECID

This way, if Apple tries to pull a fast one and disallow downgrades to earlier versions, you have a backup that can be used to still allow you to boot an older iBSS.

Apple can not stop you from obtaining the ECID from your phone. But the webapp behind purplera1n calls the same Apple servers which are also used by iTunes for signing your personal iBSS ECID combination. So this will stop working, when
* a new firmware gets released and Apple does not allow downgrading any more or
* Apple finds a way to distinguish between requests from iTunes and purplera1n

As purplera1n uses a distributed application hosting it is not easy for Apple to filter it using IP addresses.

== Phase 2: Jailbreak Tool (3.0) ==
* '''Web Site''': http://purplera1n.com

One-Click, dead simple, jailbreak for the [[iPhone 3GS]]. Currently available for Windows, Mac, and Linux. It utilizes the [[iBoot Environment Variable Overflow]].

== How purplera1n Works ==

purplera1n is so simple, that it hides the complex work it's doing from the user. Figured I'd describe it step by step
* purplera1n sends the enter recovery commands using iTunesMobileDevice
* once in recovery(iBoot), it sends the [[IBoot Environment Variable Overflow]] exploit
* the exploit adds a "geohot" command to the phone which runs the payload
* the "geohot" command is run, control is now transferred from iboot to the payload
* the purplera1n client is done
Inside payload
* the payload restores the default environment variable ring buffer and saves the environment to nvram(sets auto-boot to true)
* it patches iBoot to load unsigned img3s and not care about the tags
* it loads the purplera1n picture(sent with payload)
* the nor patcher starts
* llb is decrypted, patched, and increased in size to 0x24200. this is the resident [[0x24000 Segment Overflow]] exploit
* a little loader code is put @ 0x20000 in the LLB to load it and fix the stack
* iboot is decrypted, patched
* everything else is read as is
* nor is written back, nor patcher is done
* kernel is loaded, decrypted, and patched
* ramdisk is loaded(sent with payload) and moved to ramdisk region at 0x44000000, patched kernel is tacked on to the end
* patched kernel is booted
* control is now transferred from payload to ramdisk
Inside ramdisk
* launchd is run, all stuff happens here
* /dev/disk0s1 is mounted
* fstab and services are overwritten here to allow disk0s1 writes and afc2 respectively
* Freeze.app is transferred and Freeze.app loader has SUID bit set
* patched kernel is read from end of ramdisk block device and written to filesystem
* ramdisk is done, rebooting...
Reboots as jailbroken phone

Decrypting Firmwares

2009-07-05T23:14:51Z

Westbaer:

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

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

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

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

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

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

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

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

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

If you're using img3decrypt use this:
''img3decrypt e restore_ramdisk.dmg restore_ramdisk_decrypted.dmg Ramdisk_IV Ramdisk_Key''

Use this if you're using xpwntool:
''xpwntool restore_ramdisk.dmg restore_ramdisk_decrypted.dmg -k Ramdisk_Key -iv Ramdisk_IV''

Where '''restore_ramdisk.dmg''' is image of restore ramdisk (for example 3.0 beta 1 iPhone GSM firmware restore ramdisk is 018-4793-1.dmg), and '''restore_ramdisk_decrypted.dmg''' is decrypted image, that you can mount and explore from Finder. Ramdisk_IV and Ramdisk_Key is a decrypted keys that you can find in [[VFDecrypt_Keys:_3.x|vfdecrypt page]] or in Info.plist from PwnageTool FirmwareBundles folder (when Dev Team include support for this firmware).

Because of the new HFS Compression used in Snow Leopard and 3.0 DMGs, you may see zero-sized files in the DMG if you don't use Snow Leopard. In order to extract those, check [[Talk:Ramdisk Decryption]].

Ultrasn0w

2009-07-05T12:18:33Z

Westbaer:

ultrasn0w (previously: '''yellowsn0w''') is the only [[iPhone 3G]] [[Unlock 2.0|unlock]] payload. yellowsn0w was released on 01/01/09 [http://blog.iphone-dev.org/post/67797811/dont-eat-yellowsn0w]. ultrasn0w was released on June 23th 2009 [http://blog.iphone-dev.org/post/128573459/ultras-now].

==Credit==
MuscleNerd, and [[The dev team]]

==Exploit==
Relies on an unsigned code injection vulnerability.

The actual unlock works by a daemon patching the baseband's RAM on-the-fly, overriding the carrier lock code. It is not permanent because of the signature checks - the bootloader has to pass the sigchecks and the baseband has to pass them too, so any change to the baseband/bootloader cannot be made.

==Current Injection Vector==
ultrasn0w refers to the reuseable '''payload''', but it requires an injection vector in order to be inserted into the baseband. yellowsn0w was originally to be released with an injection vector that works on pre-2.28.00 baseband versions. However, [[geohot]] had an injection vector for 2.28.00 and the decision was made to release yellowsn0w with this injection vector to benefit the most people. This injection vector is discussed [[AT+stkprof Exploit|here]]. ultrasn0w uses a different injection vector - [[AT+XLOG Exploit]].

==ultrasn0w payload with comments (by Oranav)==

===Code loader (incl. Stage2)===
<pre>
ROM:00000000 ; =============== S U B R O U T I N E =======================================
ROM:00000000
ROM:00000000
ROM:00000000 code_loader
ROM:00000000 dest_addr = R1
ROM:00000000 src_addr = R6
ROM:00000000 MOVLS dest_addr, 0x110
ROM:00000004 ADDS dest_addr, #6
ROM:00000006 LSLS dest_addr, dest_addr, #8 ; unused ram to place code = 0x11600
ROM:00000008 ADDS R2, dest_addr, #1 ; thumbing
ROM:0000000A
ROM:0000000A loop ; CODE XREF: code_loader+24�j
ROM:0000000A MOVLS R0, 0x22 ; '"'
ROM:0000000E LDRB R3, [src_addr] ; first nibble
ROM:00000010 CMP R0, R3
ROM:00000012 LDRB R0, [src_addr,#1] ; second nibble
ROM:00000014 BEQ run ; branch if end of string
ROM:00000016 SUBS R3, #0x41 ; subtract 'A'
ROM:00000018 SUBS R0, #0x41 ; subtract 'A'
ROM:0000001A LSLS R3, R3, #4 ; make room for next nibble
ROM:0000001C ADDS R3, R3, R0 ; put them together as a byte
ROM:0000001E STRB R3, [dest_addr]
ROM:00000020 ADDS dest_addr, #1
ROM:00000022 ADDS src_addr, #2
ROM:00000024 B loop
ROM:00000026 ; ---------------------------------------------------------------------------
ROM:00000026
ROM:00000026 run ; CODE XREF: code_loader+14�j
ROM:00000026 BLX R2 ; handler_replace()
ROM:00000028 MOVLS R0, 0 ; safe exit
ROM:0000002C ADDS dest_addr, R0, #0
ROM:0000002E BLX R4
ROM:00000030 MOV SP, R5
ROM:00000032 POP {R0-src_addr,PC}
ROM:00000032 ; End of function code_loader
</pre>

===Handler replace===
<pre>
RAM:00011600 ; =============== S U B R O U T I N E =======================================
RAM:00011600
RAM:00011600
RAM:00011600 handler_replace
RAM:00011600 PUSH {LR}
RAM:00011602 LDR R0, =0x40492FC0 ; (probably) where to save task_loop_jmp + task_loop
RAM:00011604 ADR R1, task_loop_jmp
RAM:00011606 ADR R2, task_loop_end
RAM:00011608 SUBS R2, R2, R1 ; size of task_loop + task_loop_jmp = 0x70
RAM:0001160A LDR R3, =0x2040882C ; memcpy()
RAM:0001160C BLX R3
RAM:0001160E LDR R0, =0x40492C20 ; where to save task_creator_jmp + task_creator
RAM:00011610 ADR R1, task_creator_jmp
RAM:00011612 ADR R2, task_creator_end
RAM:00011614 SUBS R2, R2, R1 ; size of task_creator + task_creator_jmp = 0xA0
RAM:00011616 LDR R3, =0x2040882C ; memcpy()
RAM:00011618 BLX R3
RAM:0001161A LDR R0, =0x40492C20
RAM:0001161C BLX R0 ; task_creator_jmp()
RAM:0001161E POP {PC}
RAM:0001161E ; End of function handler_replace
</pre>

===Task creator (thanks Darkmen for the comments!)===
I'm also missing here a comment.
<pre>
RAM:40492C20 ; =============== S U B R O U T I N E =======================================
RAM:40492C20
RAM:40492C20
RAM:40492C20 task_creator_jmp
RAM:40492C20 STMFD SP!, {R1-R12,LR}
RAM:40492C24 BLX task_creator
RAM:40492C28 LDMFD SP!, {R1-R12,PC}
RAM:40492C28 ; End of function task_creator_jmp
RAM:40492C28
RAM:40492C2C
RAM:40492C2C ; =============== S U B R O U T I N E =======================================
RAM:40492C2C
RAM:40492C2C
RAM:40492C2C task_creator ; CODE XREF: task_creator_jmp+4�p
RAM:40492C2C PUSH {R4-R7,LR}
RAM:40492C2E LDR R3, =0x401ED3B8 ; jumptable var
RAM:40492C30 MOVLS R4, 0x800
RAM:40492C34 SUB SP, SP, #0x24
RAM:40492C36 STRH R0, [R3] ; R0 = task_creator_jmp addr
RAM:40492C38 LDR R5, =0x201493F0 ; malloc
RAM:40492C3A ADDS R0, R4, #0 ; 0x800
RAM:40492C3C ADDS R7, R1, #0 ; R7 = resp_string
RAM:40492C3E BLX R5 ; malloc(0x800)
RAM:40492C40 ADDS R6, R0, #0 ; R6 = addr returned from malloc
RAM:40492C42 MOVS R0, #0x98 ; sizeof(NU_TASK)
RAM:40492C44 BLX R5 ; malloc(sizeof(NU_TASK))
RAM:40492C46 MOVS R2, #0
RAM:40492C48 MOVS R3, #0x44
RAM:40492C4A LDR R1, =aDevteam1 ; char *name
RAM:40492C4C STR R2, [R0,#0xC] ; task.field=0
RAM:40492C4E STR R3, [SP,#0xC] ; priority = 0x44
RAM:40492C50 MOVS R3, #0xA
RAM:40492C52 STR R3, [SP,#0x14] ; preempt = NU_PREEMPT
RAM:40492C54 MOVS R3, #0xC
RAM:40492C56 STR R2, [SP] ; void *argv = 0
RAM:40492C58 STR R4, [SP,#8] ; stack_size = 0x800
RAM:40492C5A STR R2, [SP,#0x10] ; time_slice = 0
RAM:40492C5C STR R3, [SP,#0x18] ; auto_start = NU_START
RAM:40492C5E LDR R2, =0x40492FC0 ; ???
RAM:40492C60 STR R6, [SP,#4] ; void *stack_address = malloc(0x800)
RAM:40492C62 MOVS R3, #0
RAM:40492C64 LDR R4, =0x2043E5B4 ; NU_Create_Task
RAM:40492C66 BLX R4 ; status = NU_Create_Task()
RAM:40492C68 ADDS R2, R0, #0 ; R2 = status (for the %d reference in sprintf)
RAM:40492C6A CMP R0, #0 ; success = zero
RAM:40492C6C BNE status_error
RAM:40492C6E LDR R1, =aOk ; "OK!"
RAM:40492C70 ADDS R0, R7, #0 ; resp_string
RAM:40492C72 LDR R3, =0x204B11F0 ; sprintf
RAM:40492C74 BLX R3 ; sprintf(resp_string, "OK!")
RAM:40492C76 B exit
RAM:40492C78 ; ---------------------------------------------------------------------------
RAM:40492C78
RAM:40492C78 status_error ; CODE XREF: task_creator+40�j
RAM:40492C78 LDR R1, =aErrorD ; "ERROR %d"
RAM:40492C7A ADDS R0, R7, #0 ; resp_string
RAM:40492C7C LDR R3, =0x204B11F0 ; sprintf
RAM:40492C7E BLX R3 ; sprintf(resp_string, "ERROR %d", status)
RAM:40492C80
RAM:40492C80 exit ; CODE XREF: task_creator+4A�j
RAM:40492C80 ADD SP, SP, #0x24 ; fixing stack
RAM:40492C82 POP {R4-R7,PC}
RAM:40492C82 ; End of function task_creator
</pre>

===Unlock task loop (thanks Darkmen for the comments!)===
<pre>
RAM:00011630 ; =============== S U B R O U T I N E =======================================
RAM:00011630
RAM:00011630
RAM:00011630 task_loop_jmp
RAM:00011630 STMFD SP!, {R1-R12,LR}
RAM:00011634 BLX task_loop
RAM:00011634 ; ---------------------------------------------------------------------------
RAM:00011638 LDMFD SP!, {R1-R12,PC}
RAM:00011638 ; End of function task_loop_jmp
RAM:00011638
RAM:0001163C
RAM:0001163C ; =============== S U B R O U T I N E =======================================
RAM:0001163C
RAM:0001163C
RAM:0001163C task_loop
RAM:0001163C PUSH {R4,R5,LR}
RAM:0001163E LDR R5, =0x401E829C ; sec mailbox
RAM:00011640 SUB SP, SP, #0x14
RAM:00011642
RAM:00011642 loop ; CODE XREF: task_loop+44�j
RAM:00011642 LDR R3, =0x2042FFD8 ; NU_Receive_From_Mailbox
RAM:00011644 ADDS R0, R5, #0 ; NU_MAILBOX *mailbox
RAM:00011646 MOV R1, SP ; void *Message
RAM:00011648 MOVS R2, #0xFF ; Timeout
RAM:0001164A BLX R3 ; NU_Receive_From_Mailbox(sec_mailbox,SP,0xFF)
RAM:0001164C LDR R3, [SP] ; Message[0]
RAM:0001164E CMP R3, #0xD ; Message[0] = 0xD ?
RAM:00011650 BNE skip
RAM:00011652 LDR R1, [SP,#4] ; Message[1]
RAM:00011654 LDR R3, =0x40301650
RAM:00011656 LDR R2, [R1] ; Message[1].field0
RAM:00011658 STR R2, [R3] ; sec_task_var1 = Message[1].field0
RAM:0001165A ADDS R3, #4 ; 0x40301654
RAM:0001165C LDR R2, [R1,#4] ; Message[1].field1
RAM:0001165E STR R2, [R3] ; sec_task_var2 = Message[1].field1
RAM:00011660 LDR R2, [R1,#8] ; Message[1].field2
RAM:00011662 LDR R3, =0x100FF00
RAM:00011664 STR R3, [R2] ; Message[1].field2[0] = 0x100FF00
RAM:00011666 LDR R3, =0x4020401
RAM:00011668 STR R3, [R2,#4] ; Message[1].field2[1] = 0x4020401
RAM:0001166A LDR R3, =0x4040403
RAM:0001166C STR R3, [R2,#8] ; Message[1].field2[2] = 0x4040403
RAM:0001166E MOVS R3, #1
RAM:00011670 STR R3, [R1,#0xC] ; Message[1].field3 = 1
RAM:00011672 MOVS R3, #0x20 ; ' '
RAM:00011674 STR R3, [SP] ; Message[0] = 0x20
RAM:00011676
RAM:00011676 skip ; CODE XREF: task_loop+14�j
RAM:00011676 ADDS R0, R5, #0 ; sec mailbox
RAM:00011678 MOV R1, SP ; void *Message
RAM:0001167A MOVS R2, #0xFF ; timeout
RAM:0001167C LDR R3, =0x20430040
RAM:0001167E BLX R3 ; NU_Send_To_Mailbox()
RAM:00011680 B loop
RAM:00011680 ; End of function task_loop
RAM:00011680
RAM:00011680 ; ---------------------------------------------------------------------------
</pre>

==Old yellowsn0w payload w/ comments (by Darkmen) ===

The exploit consists from 4 parts:

===Code loader===
<pre>
ROM:00000000 ; =============== S U B R O U T I N E =======================================
ROM:00000000
ROM:00000000
ROM:00000000 loader
ROM:00000000 LDR R2, =0x11700 ; unused ram to place code
ROM:00000002 ADDS R4, R2, #1 ; thumb switch
ROM:00000004 LDR R3, =0x40159FBF ; at-handler buffer where stage2 binary and following hexdata are
ROM:00000006
ROM:00000006 copy.loop ; CODE XREF: loader+12�j
ROM:00000006 LDRB R0, [R3] ; copying code+data until double quotes
ROM:00000008 CMP R0, #0x22 ; '"'
ROM:0000000A BEQ run ; jump thumb code
ROM:0000000C STRB R0, [R2]
ROM:0000000E ADDS R2, #1
ROM:00000010 ADDS R3, #1
ROM:00000012 B copy.loop ;
ROM:00000014 run ; CODE XREF: loader+A�j
ROM:00000014 BX R4 ; jump stage2 code
ROM:00000014 ; End of function loader
ROM:00000014
ROM:00000014 ; ---------------------------------------------------------------------------
</pre>

===Stage2(tm)===
<pre>
RAM:00000000 ; =============== S U B R O U T I N E =======================================
RAM:00000000 stage2
RAM:00000000 ADDS R2, #0x10 ; R2 = 0x11700 + stage2 size
RAM:00000002 MOVS R7, #0xF
RAM:00000004 BICS R2, R7 ; align offset by 0x10
RAM:00000006 ADDS R7, R2, #0 ; saving address to jump
RAM:00000008 ADR R4, 0x44 ; skipping Stage2 size and taking first char from at-string
RAM:0000000A ADR R5, char2byte ; loading routine addr
RAM:0000000C ADDS R5, #1 ; thumb
RAM:0000000E
RAM:0000000E loop ; CODE XREF: stage2+2C�j
RAM:0000000E LDRB R1, [R4] ; at-string[index]
RAM:00000010 CMP R1, #'x' ; end of line?
RAM:00000012 BEQ jump_code
RAM:00000014 BLX R5 ; char2byte first hakfbyte
RAM:00000016 LSLS R3, R1, #4 ; <<4 0X becoming X0
RAM:00000018 LDRB R1, [R4,#1] ; at-string[index+1]
RAM:0000001A BLX R5 ; char2hex second halfbyte
RAM:0000001C NOP
RAM:0000001E NOP
RAM:00000020 NOP
RAM:00000022 NOP
RAM:00000024 ADDS R1, R1, R3 ; R1 = complete byte
RAM:00000026 STRB R1, [R2] ; storing byte to dst
RAM:00000028 ADDS R4, #2 ; hexstr_index+=2
RAM:0000002A ADDS R2, #1 ; dst++
RAM:0000002C B loop ; at-string[index]
RAM:0000002E jump_code
RAM:0000002E NOP
RAM:00000030 NOP
RAM:00000032 ADDS R7, #1 ; thumbing
RAM:00000034 BX R7 ; run Task creator code
RAM:00000034 ; End of function stage2
RAM:00000038
RAM:00000038 ; =============== S U B R O U T I N E =======================================
RAM:00000038 char2byte ; DATA XREF: stage2+A�o
RAM:00000038 CMP R1, #0x41 ; 'A'
RAM:0000003A BGE letter ; letter to number
RAM:0000003C SUBS R1, #0x30 ; '0' ; digit to number
RAM:0000003E BX LR
RAM:00000040 letter ; CODE XREF: char2byte+2�j
RAM:00000040 SUBS R1, #0x37 ; '7' ; letter to number
RAM:00000042 BX LR ; ret
RAM:00000042 ; End of function char2byte
</pre>

===Task creator===
<pre>
RAM:000119A0 ; =============== S U B R O U T I N E =======================================
RAM:000119A0
RAM:000119A0
RAM:000119A0 handler_replace
RAM:000119A0 LDR R0, =0x4011714C ; soft reset handler addr
RAM:000119A2 ADR R1, new_handler
RAM:000119A4 ADDS R1, #1 ; thumbing
RAM:000119A6 STR R1, [R0] ; setting new handler
RAM:000119A8 POP {R0-R4,PC} ; safe exit fixing stack
RAM:000119A8 ; End of function handler_replace

RAM:000119B0 ; =============== S U B R O U T I N E =======================================
RAM:000119B0
RAM:000119B0
RAM:000119B0 new_handler ; DATA XREF: handler_replace+2�o
RAM:000119B0 PUSH {R4-R7,LR}
RAM:000119B2 LDR R3, =0x403BB344 ; jamptable var
RAM:000119B4 MOVS R6, #0x80
RAM:000119B6 SUB SP, SP, #0x2C
RAM:000119B8 LSLS R6, R6, #4 ; 0x200
RAM:000119BA STRH R0, [R3] ; saving R0 to mem var
RAM:000119BC STR R1, [SP,#0x40+resp_string] ; saving responce prt to stack
RAM:000119BE LDR R4, =0x201420AC ; malloc
RAM:000119C0 ADDS R0, R6, #0
RAM:000119C2 BLX R4 ; malloc(0x200)
RAM:000119C4 MOVS R5, #0
RAM:000119C6 STR R0, [SP,#0x40+ptr_200] ; saving pointer to stack
RAM:000119C8 MOVS R0, #0x98 ; sizeof(NU_TASK)
RAM:000119CA BLX R4 ; malloc(0x98)
RAM:000119CC ADDS R7, R0, #0 ; R7 = task
RAM:000119CE STR R5, [R0,#0xC] ; task.field=0
RAM:000119D0 MOVS R0, 0x100
RAM:000119D4 BLX R4 ; malloc(0x100)
RAM:000119D6 MOVS R2, #0x80
RAM:000119D8 LDR R1, =task_loop ; src
RAM:000119DA LSLS R2, R2, #1 ; size to copy
RAM:000119DC LDR R3, =0x203C58A0 ; bytecpy
RAM:000119DE ADDS R4, R0, #0 ; R4 = dyn_task_loop
RAM:000119E0 BLX R3 ; bytecpy(task_loop, dyn_task_loop, 0x100)
RAM:000119E2 LDR R3, [SP,#0x40+ptr_200]
RAM:000119E4 STR R3, [SP,#4] ; void *stack_address = malloc(0x200)
RAM:000119E6 MOVS R3, #0x44
RAM:000119E8 STR R3, [SP,#0xC] ; priority = 0x44
RAM:000119EA MOVS R3, #0xA
RAM:000119EC ADDS R4, #1 ; thumbing dyn_task_loop
RAM:000119EE STR R3, [SP,#0x14] ; preempt = NU_PREEMPT
RAM:000119F0 MOVS R3, #0xC
RAM:000119F2 ADDS R2, R4, #0 ; void(*task_entry)
RAM:000119F4 STR R3, [SP,#0x18] ; auto_start = NU_START
RAM:000119F6 LDR R1, =devteam1 ; char *name
RAM:000119F8 STR R5, [SP] ; void *argv = 0
RAM:000119FA STR R6, [SP,#8] ; stack_size = 0x200
RAM:000119FC STR R5, [SP,#0x10] ; time_slice = 0
RAM:000119FE ADDS R0, R7, #0 ; NU_TASK *task
RAM:00011A00 MOVS R3, #0 ; int argc = 0
RAM:00011A02 LDR R4, =0x203FB540 ; NU_Create_Task
RAM:00011A04 BLX R4 ; status = NU_Create_Task()
RAM:00011A06 ADDS R2, R0, #0
RAM:00011A08 CMP R0, #0 ; success = zero
RAM:00011A0A BNE status_error
RAM:00011A0C LDR R1, =OK
RAM:00011A0E LDR R0, [SP,#0x40+resp_string]
RAM:00011A10 LDR R3, =0x2046DD00 ; sprintf
RAM:00011A12 BLX R3 ; sprintf(resp_string,"OK")
RAM:00011A14 B exit ; fixing stack
RAM:00011A16 ; ---------------------------------------------------------------------------
RAM:00011A16
RAM:00011A16 status_error ; CODE XREF: new_handler+5A�j
RAM:00011A16 LDR R1, =ERROR
RAM:00011A18 LDR R0, [SP,#0x40+resp_string]
RAM:00011A1A LDR R3, =0x2046DD00 ; sprintf
RAM:00011A1C BLX R3 ; sprintf(resp_string,"ERROR")
RAM:00011A1E
RAM:00011A1E exit ; CODE XREF: new_handler+64�j
RAM:00011A1E ADD SP, SP, #0x2C ; fixing stack
RAM:00011A20 POP {R4-R7,PC} ; bye
RAM:00011A20 ; End of function new_handler
RAM:00011A20
RAM:00011A20 ; ---------------------------------------------------------------------------
</pre>

===Unlock task loop===
<pre>
RAM:00011A64 ; =============== S U B R O U T I N E =======================================
RAM:00011A64
RAM:00011A64 task_loop ; DATA XREF: RAM:off_11A2C�o
RAM:00011A64 PUSH {R4,R5,LR}
RAM:00011A66 LDR R5, =0x40232754 ; sec mailbox
RAM:00011A68 SUB SP, SP, #0x14
RAM:00011A6A
RAM:00011A6A loop ; CODE XREF: task_loop+44�j
RAM:00011A6A LDR R3, =0x20165998 ; NU_Receive_From_Mailbox
RAM:00011A6C ADDS R0, R5, #0 ; NU_MAILBOX *mailbox
RAM:00011A6E MOV R1, SP ; void *Message
RAM:00011A70 MOVS R2, #0xFF ; Timeout
RAM:00011A72 BLX R3 ; NU_Receive_From_Mailbox(sec_mailbox,SP,0xFF)
RAM:00011A74 LDR R3, [SP] ; Message[0]
RAM:00011A76 CMP R3, #0xD ; Message[0] = 0xD ?
RAM:00011A78 BNE skip ;
RAM:00011A7A LDR R1, [SP,#4] ; Message[1]
RAM:00011A7C LDR R3, =0x402F79BC
RAM:00011A7E LDR R2, [R1] ; Message[1].field0
RAM:00011A80 STR R2, [R3] ; sec_task_var1 = Message[1].field0
RAM:00011A82 ADDS R3, #4 ; 0x402F79C0
RAM:00011A84 LDR R2, [R1,#4] ; Message[1].field1
RAM:00011A86 STR R2, [R3] ; sec_task_var2 = Message[1].field1
RAM:00011A88 LDR R2, [R1,#8] ; Message[1].field2
RAM:00011A8A LDR R3, =0x100FF00
RAM:00011A8C STR R3, [R2] ; Message[1].field2[0] = 0x100FF00
RAM:00011A8E LDR R3, =0x4020401
RAM:00011A90 STR R3, [R2,#4] ; Message[1].field2[1] = 0x4020401
RAM:00011A92 LDR R3, =0x4040403
RAM:00011A94 STR R3, [R2,#8] ; Message[1].field2[2] = 0x4040403
RAM:00011A96 MOVS R3, #1
RAM:00011A98 STR R3, [R1,#0xC] ; Message[1].field3 = 1
RAM:00011A9A MOVS R3, #0x20
RAM:00011A9C STR R3, [SP] ; Message[0] = 0x20
RAM:00011A9E
RAM:00011A9E skip ; CODE XREF: task_loop+14�j
RAM:00011A9E ADDS R0, R5, #0 ; sec mailbox
RAM:00011AA0 MOV R1, SP ; void *Message
RAM:00011AA2 MOVS R2, #0xFF ; timeout
RAM:00011AA4 LDR R3, =0x203ED568
RAM:00011AA6 BLX R3 ; NU_Send_To_Mailbox()
RAM:00011AA8 B loop ; NU_Receive_From_Mailbox
RAM:00011AA8 ; End of function task_loop
</pre>

===Planetbeing explains...===
<pre>
13:24:29 <crash-x_> especially how does ultra/yellow sn0w work
13:24:40 <crash-x_> are you overwriting instructions
13:24:48 <crash-x_> or some values in memory to make it accept the sim?
13:24:48 <planetbeing> Nah.
13:24:53 <planetbeing> It's a task.
13:25:06 <planetbeing> That just waits for securiy messages to go through the inbox.
13:25:13 <westbaer> planetbeing: btw, why isnt yellowsn0w/ultrasn0w not open-source anymore? like u posted an *oooold* version once

...

13:26:33 <planetbeing> The only thing I do for ys/us is the loader bit.
13:26:39 <westbaer> so whats actually the loader stuff you've been talking about?
13:26:46 <planetbeing> That uses the exploit to start MuscleNerd's payload.
13:27:21 <westbaer> ah
13:27:26 <planetbeing> Well, you have a vulnerability.
13:27:30 <planetbeing> And you want to load a large chunk of code.
13:27:39 <planetbeing> And you don't have much room to wriggle in for your overflow
13:28:21 <westbaer> aah, makes sense
13:28:50 <planetbeing> So the solution is a small loader that loads the rest of the code, and overcomes any restrictions there are on allowable characters.
13:28:55 <ashikase> francis: pm
13:28:59 <westbaer> yeah
13:29:10 <crash-x_> planetbeing: the baseband is it like one process that runs there
13:29:19 <crash-x_> or is it like a small os with process and stuff
13:29:19 <planetbeing> Basically a good loader should turn a vulnerability into a reliable platform for the execution of arbitrary code, unrestricted by vulnerability-specific stuff.
13:29:37 <planetbeing> Oh, it's a full-featured OS.
13:29:38 <planetbeing> Nucleus.
13:29:51 <planetbeing> http://www.mentor.com/products/embedded_software/nucleus_rtos/
13:29:54 <crash-x_> and when you execute an at command
13:30:06 <crash-x_> does that start another process that is crashed then
13:30:21 <planetbeing> Ideally, you don't crash anything.
13:30:21 <crash-x_> or does it crash like the main baseband program
13:30:23 <planetbeing> And we don't.
13:30:49 <crash-x_> so am i understand it right
13:30:50 <westbaer> wait. is nucleus on the baseband already installed or do you actually inject it with ultrasn0w?
13:30:51 <planetbeing> We load a bunch of code into certain memory locations, execute them, and then return safely back to the main command parser task.
13:31:00 <planetbeing> Nucleus is what the baseband runs.
13:31:04 <westbaer> ah ok
13:31:29 <planetbeing> I mean, even the bootrom is an OS.
13:31:36 <planetbeing> With one task, but it still has a scheduler. =P
13:31:39 <crash-x_> ah thats how you do it
13:31:42 <westbaer> heh
13:31:44 <crash-x_> and about your payload
13:31:57 <crash-x_> does it start a new process like using fork()
13:32:03 <crash-x_> or does it all the work in the exploited process
13:32:11 <planetbeing> It uses Nucleus-specific calls that create the new task.
13:32:19 <planetbeing> Well, the payload has to create a new task
13:32:22 <westbaer> I think they are documented on the wiki
13:32:25 <planetbeing> To monitor for certain events.
13:32:47 <planetbeing> Yeah, just read Darkmen's decompile.
13:33:00 <planetbeing> us has the exact same payload as ys
13:33:08 <planetbeing> Just different addresses for function calls and stuff.
13:33:19 <planetbeing> And I had to rewrite the loader due to even tighter constraints.
13:33:28 <crash-x_> thats cool, thanks for explaining
13:33:34 <westbaer> yup, thanks

From irc.saurik.com #iphone on sunday the 5th of july.
</pre>

==Source Code==
The source code for yellowsn0w 0.9.1 (old version) was released along with yellowsn0w release. [http://xs1.iphwn.org/releases/yellowsn0w.tar.bz2]

==See Also==
* [[X-Gold 608 Unlock]]
* [[X-Gold 608]]
* [[Baseband]]

==External links==
* [http://chronic-dev.org/blog/2008/12/props/ Chronic Dev's post about Yellowsn0w]
* [http://blog.iphone-dev.org/post/65126957/tis-the-season-to-be-jolly Yellowsn0w Announcement]
* [http://qik.com/video/729275 MuscleNerd's yellowsn0w Demo]
* [http://yellowsn0w.com yellowsn0w Official Website]
* [http://www.youtube.com/watch?v=kd5vOy2m5uY MuscleNerd's ultrasn0w demo]

[[Category:Unlocking Methods]]
[[Category:Baseband]]

Main Page

2009-07-04T16:22:00Z

Westbaer:

<center>[[Image:Iptwiki.jpg‎]]</center>

{{:Main Page/Welcome}}
<table border="1" width="100%"><tr>
<td style="background-color:orange; text-align:center; width:25%;"><b>[[Unlock 2.0|Break Chain of Trust (X-Gold 608)]]</b></td>
</tr>
<tr>
<td colspan="4">
<center>[[Disclaimer]]</center>
</td>
</tr>
</table><br />
==Software==
* [[Filesystem]]
* [[Firmware]]
* [[Keys]]
* [[Protocols]]
* [[System Log]]

==Hardware==
=== iPhone ===
* [[m68ap|iPhone (m68ap)]]
* [[n82ap|iPhone 3G (n82ap)]]
* [[N88AP|iPhone 3GS (n88ap)]]

=== iPod touch ===
* [[n45ap|iPod touch (n45ap)]]
* [[n72ap|iPod touch 2nd Generation (n72ap)]]

==App Processor ([[Jailbreak]])==
The [[iPhone]], [[iPod touch]], and [[iPhone 3G]] makes use of the [[S5L8900]] platform as application processor. Current models, such as the [[iPod touch 2G]] and the [[N88AP|iPhone 3GS]], use newer processors. The [[S5L8720]] and [[S5L8920]] are used, respectively. Here is where the [[Jailbreak|jailbreak]] applies.

==Baseband ([[Unlock]])==
The [[Baseband Device]] is where the [[unlock]] applies.

==Application Development==
* [[Toolchain]] (Includes tutorials)
* [[Toolchain 2.0]] (Includes tutorials)
* [[Frameworks]]
* [[MobileDevice Library]]
* [[Apple Certification Process]]
* [[Bypassing iPhone Code Signatures]]
* [[Distribution Methods]]

==Application Copy Protection==
* [[Copy Protection Overview]]
* [[Application Structure and Signatures]]
* [[Mach-O Loading Process]]
* [[Bugging Debuggers]]

==Definitions==
* [[Jailbreak]]
* [[Activation]]
* [[Unlock]]
* [[Baseband Device|Baseband]]
* [[Baseband Bootloader|Bootloader]]
* [[DFU]]
* [[iBoot]]
* [[iBEC]]
* [[iBSS]]
* [[NORID]]
* [[CHIPID]]

==Other==
* [[Bluetooth]]
* [[Glossary]]
* [[Tutorials]]
* [[Useful Links]]

Main Page

2009-06-13T23:47:26Z

Westbaer:

<center>[[Image:Iptwiki.jpg‎]]</center>

{{:Main Page/Welcome}}
<table border=1 width=100%><tr>
<td bgcolor=orange width=25%><center><b>[[Jailbreak iPhone2,1|Break Chain of Trust (S5L8920x)]]</b></center></td>
<td bgcolor=orange width=25%><center><b>[[Unlock 2.0|Break Chain of Trust (X-Gold 608)]]</b></center></td>
</tr>
<tr>
<td colspan=4>
<center>[[Disclaimer]]</center>
</td>
</tr>
</table><BR>
==Software==
* [[Filesystem]]
* [[Firmware]]
* [[Keys]]
* [[Protocols]]
* [[System Log]]

==Hardware==
=== iPhone ===
* [[m68ap|iPhone (m68ap)]]
* [[n82ap|iPhone 3G (n82ap)]]
* [[N88AP|iPhone 3G S (n88ap)]]

=== iPod touch ===
* [[n45ap|iPod touch (n45ap)]]
* [[n72ap|iPod touch 2nd Generation (n72ap)]]

==App Processor ([[Jailbreak]])==
The [[iPhone]], [[iPod touch]], and [[iPhone 3G]] makes use of the [[S5L8900]] platform as application processor, while the [[iPod touch 2G]] uses the [[S5L8720]]. Here is where the [[Jailbreak|jailbreak]] applies.

==Baseband ([[Unlock]])==
The [[Baseband Device]] is where the [[unlock]] applies.

==Application Development==
* [[Toolchain]] (Includes tutorials)
* [[Toolchain 2.0]] (Includes tutorials)
* [[Frameworks]]
* [[MobileDevice Library]]
* [[Apple Certification Process]]
* [[Bypassing iPhone Code Signatures]]
* [[Distribution Methods]]

==Application Copy Protection==
* [[Copy Protection Overview]]
* [[Application Structure and Signatures]]
* [[Mach-O Loading Process]]
* [[Bugging Debuggers]]

==Definitions==
* [[Jailbreak]]
* [[Activation]]
* [[Unlock]]
* [[Baseband Device|Baseband]]
* [[Baseband Bootloader|Bootloader]]
* [[DFU]]
* [[iBoot]]
* [[iBEC]]
* [[iBSS]]
* [[NORID]]
* [[CHIPID]]

==Other==
* [[Bluetooth]]
* [[Glossary]]
* [[Tutorials]]
* [[Useful Links]]

N88AP

2009-06-13T23:47:05Z

Westbaer: IPhone2,1 moved to N88AP

[[Image:IPhone3GS.jpg|right|thumb|iPhone 3G S, back and front.]]

This is the iPhone 3G S. It will be released on June 19, 2009 with a price tag of $199 for the 16GB model and $299 for the 32GB model, in the U.S., Canada and major European countries. Price varies depending on the operator selling it. It features the same design as the [[iPhone 3G]], but has also new features such as video recording, voice control, digital compass, faster CPU, increased RAM etc.

== Baseband ==
The iPhone 3G S will probably use the [[X-Gold 608]] baseband chip, same as in the iPhone 3G.

== Application Processor ==
It makes use of the [[S5L8920x]] application processor.

== Specifications ==
'''Color''': Black or white <br>
'''Size''': 4.5 inches (115.5 mm) (h) × 2.4 inches (62.1 mm) (w) × 0.48 inch (12.3 mm) (d) <br>
'''Weight''': 135 g (4.8 oz) <br>
'''Battery''': Up to 12 hours of 2G talk, 5 hours of 3G talk, 5 (3G) or 9 (Wi-Fi) hours of Internet use, 10 hours of video playback, and up to 30 hours of audio playback, lasting over 300 hours on standby. <br>
'''3G''': Broadband data speeds, supporting 7.2Mbps HSDPA <br>
'''Camera''': 3.15MP with Autofocus and manual focus (''Tap to focus''), supporting VGA video recording @ 30FPS

More specifications available in [http://www.gsmarena.com/apple_iphone_3g_s-2826.php GSMArena].

== See also ==
* [[Jailbreak iPhone2,1]]
* [[X-Gold 608 Unlock]]

==External Links==
* [http://www.anandtech.com/gadgets/showdoc.aspx?i=3579 AnandTech: The iPhone 3GS Hardware Exposed & Analyzed]

IPhone2,1

2009-06-13T23:47:05Z

Westbaer: IPhone2,1 moved to N88AP

#REDIRECT [[N88AP]]

IRecovery

2009-05-27T19:19:23Z

Westbaer:

iRecovery is a libusb-based commandline utility for Mac OS X and Linux (perhaps Windows too). It is able to talk to the iBoot/iBSS in Apple's iPhone/iPod touch via USB.

It's completely open-source, the source-code is released under the terms of the GNU General Public License version 3.
The full license text can be found in the LICENSE file on github.

It currently connects to 0x1281 (iPhone, iPhone 3G, iPod touch, iPod touch 2G: Recovery Mode/iBSS), 0x1227 (iPhone,
iPhone 3G, iPod touch: WTF Mode; iPod touch 2G: DFU Mode).

==Credits==
westbaer

==Features==

===DFU 2.0 (0x1227)===
It can upload a file, such as an iBSS, so that you can unplug and spawn a shell with 0x1281.

===Recovery 2.0 (0x1281)===
====File Uploading====
You can upload a file to 0x9000000 with the following syntax:
./iRecovery -f file

====Two-Way Shell====
You can spawn a shell to do all sorts of neat things with the syntax:
./iRecovery -s
Once it has spawned, you can type 'help' and iBoot will respond with its built-in command list.

====Single Command====
./iRecovery -c "command"
Sends a single command to the device *without* spawning a shell.

==Download==
[http://github.com/westbaer/irecovery/tree Latest version always on GitHub]