iPhone secure boot
Any comments on this?
The ARM CPU begins executing a secure bootloader on power-up. It then starts a low-level bootloader (“LLB”) that runs several setup routines and on firmware versions 2.0 and higher it checks the signature of iBoot before jumping to it.
The stage 2 bootloader, iBoot, places the operating system in memory and starts the OSX kernel, which then launches the usermode environment and the SpringBoard.
The secure bootloader acts as a library for iBoot, providing an API for verifying signatures on applications. During initialization, iBoot copies the secure bootloader to RAM and then performs a series of fix-ups for function pointers that redirect back into iBoot itself. In order to support updates and different versions, iBoot has a table of offsets and byte patches it applies to the secure bootloader before calling it.
The Iphone can be placed in two different upgrade modes during boot.
The normal upgrade mode is called Recover Mode. This is the mode users will experience the first time they start their iPhone. This mode asks for a connection to iTunes in order to fetch a firmware (FW) package (ipsw). The recovery mode is managed by iBoot and the firmware is placed on the device. During this process the firmware package’s components signatures is verified using the API provided by the secure bootloader.
There is another mode called the DFU mode. The Device Firmware Upgrade (DFU) mode
is a vendor and device independent way of updating the firmware of a USB device. The idea is to have only one vendor-independent FW update tool as part of the operating system, which can then (given a particular firmware image) be downloaded into the device.
In addition to firmware download, it also specifies firmware upload, i.e. loading the currently installed device FW to the USB Host. However Apple only uses this feature as a stage for their own secure bootup chain.
However, bad handling of USB control messages in DFU mode of the iPhone has enabled hackers to run code on the device.
By triggering a buffer overflow on the stack they can overwrite the return address and point to the malicious code that actually is part of the message. The code attached will patch the secure bootloader so that any signature checks will pass regardless of the actual result of the check. This will make the iBoot operational with any custom made FW passed to it over USB in recovery mode.
The FW components are however encrypted so in order to customize the root filesystem or any other package of the firmware those need to be decrypted.
The FW package ipsw-file is just a zip-archive containing manifest files, img3 files and dmg files. The root filesystem, for instance, is provided as an encrypted DMG file.
DMG files are mountable disk images commonly used in Mac OS X, they contain raw block data typically compressed and sometimes encrypted.
The img3 file format contains data and executables for LLB, iBoot, KernelCache, etc.
The img3 file format has a header and some tags. The DATA tag contains the real content of the file. Another interesting tag is the KBAG-tag, it contains the KEY and IV required to decrypt the DATA section of the img3 file.
The SoC AES coprocessor on the iPhone knows the GID-key and UID-key. This AES-engine is used to decrypt the KBAG tag of the img3 file. The KBAG contains the KEY and IV required to encrypt/decrypt the DATA section of the file.
The GID-key is thus secured in hardware and extremely hard to extract. However the engine itself is pretty easy to use from the device itself (located at address 0x38c00000). So by using the AES-engine on the device a hacker could easily pass the encrypted KBAG and get the KEY and IV for the DATA portion of the firmware package.
The baseband chip on the iPhone runs a separate operating system for communicating with the cell towers. There are several different transmission technologies that the iPhone supports and the basebands is responsible for handling this for the iPhone. When placing a call the iPhone only pass the phone number to the baseband and the baseband takes care of the rest. The baseband processor has its own RAM and firmware in NOR flash, separate from the ARM core resources. The Wi-Fi and bluetooth are managed by the main CPU, although the baseband stores their MAC addresses in it’s NVRAM.
Baseband Bootloader : The baseband bootloader is the code which runs before the baseband FW, it is responsible for signature checking and updating the baseband.
It sounds like they are describing Pwned DFU mode, but that's only applicable to certain devices. I don't think this is anything new?