Pwnage exploits a bad chain of trust in the boot sequence of the S5L8900 device. The boot sequence includes LLB and iBoot modules which are stored in device NOR flash and are typically encrypted (as of 1.1.*). However, they are not signed with RSA signature at that point, because the 8900 container is dropped away before the file is written to NOR flash. Pwnage exploits this vulnerability.

• First, Apple assumes that if something is in the NOR flash, it had necessarily passed through an RSA signature verification, and is therefore authentic Apple code. This is incorrect, because the only mechanism preventing the writing of unauthorized code to the NOR flash is the kernel. The iPhone/iPod Touch kernel contains an extension designed specifically to write to the NOR flash, called AppleImage2NORAccess. This extension performs an RSA signature verification on any data it tries to write. The verification itself is performed by the Fairplay extension, which is heavily obfuscated, but neutering the check is very simple. After the check is patched out, anything can be written to the NOR flash.

• Second, Apple assumes that disabling the encryption keys in “normal” environment will prevent from writing firmware files to the NOR flash. Luckily, we have found a way to run our code in “secure” environment and use AppleImage2NORAccess extension the same way as Apple does it on restore.

Pwnage starts by booting from a memory device (ramdisk) in “secure” environment to prevent the kernel from disabling encryption keys. Also, we add another memory device, pointed at the kernel's address space, to allow live kernel patching. After booting up, we patch out signature check from AppleImage2NorAccess extension and proceed with flashing our custom firmware files (iBoot, LLB, DeviceTree, and pictures). Because the signature check has been patched out, and encryption keys are available, AppleImage2NORAccess happily writes them to the suitable location in NOR flash. After that, the device can be restarted, and will accept any unsigned 8900 file without complaint.

One specific aspect of our attack that is worth examining more closely is the iBoot patch. iBoot is the last and most complicated bootloader on the devices, and is what actually loads up the kernel with device tree. However, Apple made the decision to keep all the PKE (Public Key Encryption) logic out of iBoot, instead putting it in the secure bootloader. Thus, iBoot actually jumps into the secure bootloader when it wants to verify the authenticity of an 8900 file. This makes it hard to directly patch out the RSA signature verification from iBoot, as it actually occurs in the secure bootloader. Simply killing the jump into the secure bootloader is impossible, as it also fills in other information iBoot needs to proceed.

Because of the tight coupling between the secure bootloader and the higher-level bootloaders, Apple gave us a solution: the secure bootloader often needs to call functions in the higher-level bootloaders, but it has the problem of knowing where to jump, as functions move around in different revisions. To get around this, Apple made thunks out of the function calls, and makes the higher-level bootloaders patch the secure bootloader on the fly (in RAM) with the relevant jump addresses. They just copy the secure bootloader into RAM and blindly apply a list of patches to it. We exploited this pre-existing patching mechanism to patch out the RSA signature verification from secure bootloader.