Site: http://blog.iphone-dev.org
The group found on 26th June 2007 a few days before the release of the iPhone
usually just on IRC, the first time here to meet each other. irc.osc86 ??
members from many countries
site has 1.7 milion visits in the last month.
They have a tool called PwnageTool and QuickPwn
Release patches about 24-48 hours after apple releases software updates
using Sparkle for updates
interesting there are about 180 active users from within Apple’s IP range.
Application Processor
Goal: Execute custom code on the iPhone OS
- instalation of third-party apps
- Activation
- SIM Unlock
iPhone OS architecture is largely OS X
Kernel is XNU (basically)
Lots of the userland architecture is the same
Lobotomized launchd (no command line switches)
Modified system libraries
SpringBoard as the shell
Lockdownd handles communications with the computer
- Service like sync’ing and AFC
- Activation
- SSL tunnel between sockets on the computer and the iPhone
- (basically like inetd)
Goal is to modify this to run your own code. But how to do this?
- iPhone OS runs on a NAND flash disk
- Appears as a normal block device to userland
- Uses Samsung’s „Whimory“ FTL
- OS runs on an read-only System parttion (/) ad writable User partition (private/var)
- Only logical distinction
This party applications are installed onto the user partition (the system partition never needs to be checked on reboot/crash)
- all executables must be signed by Apple
- Signatures and hashes stored in segments in the Mach-o-format
- Signatures only checked on startup
- Code execution exploits can still work
For our goal kernel needs to be modified.
How is it protected?
Kernel is stored on the System partition, with all kexts concatenated in Mach-O form
Cannot alter kernel file except as root
How is the signature of the kernel checked?
Boot process:
- Bootrom loads LLB from NOR flash
- LLB parses NOR image list format
- LLB loads the next stage bootloader from the image list, sig check
- LLB is the MBR of the NOR
next stage: LLB loads iBoot from NOR Flash
- iBoot is analogous to an OpenFirmware boot
- Loads the device tree form NOR
- populates device tree
- Allow different components from different vendors
- Loads kernel from NAND and executes it
iBoot checks signatures on everything (not the kernel does that) (kernel, device tree and graphics display)
We need to get around this to run our unsigned applications.
After that the kernel can protect the rest it loads.
One problem is there with this scheme: Userland apps are checked by the kernel, kernel by iBoot, iBoot by LLB.
LLB is signature checked by the bootrom? NO! epic fail!
So we can fake it.
The only way we can flush the NOR is through the restore process.
Every stage in the boot process can abot to either a DFU or a „recovery mode“
A newer version of iboot can be loaded form any stage
A newer version of the kernel and a ramdisk can be loaded from this iBoot.
The Restore process is performed by this ramdisk/kernel combination
Vortually impossible to brick the iPhone due to corruption of non-volatile data under normal circumstances.
The iBoot loaded from any stage is sig checked before being executed.
The ramdisk and kernel is sig checked before being loaded by iBoot.
All data is encrypted by keys derived from a hardware AES key (cannot be read)
Keys disabled on a non-secure boot (thus cannot be done)
The filesystem is encrypted by filevault (in the ramdisk, whcih is encrypted with the HW key).
Still sounds pretty secure, right?
Userland apps are secured by kernel by NOR firmware by restore ramdisk by NOR firmware by bootrom.
Bootrom DFU vulnerability
All certs chain infor stored on stack
Sig copied into data structure … (editor remark: they are too fast ;-) )
Pwnage
Signature checking patched out throughout the chain, using DFU vulnerability to load the iBoot stage.
- LLB, iBoot, Kernel (with no sig checking anymore)
- Ramdisk, restored
- Filesytem image
- cydia, Installer
They can use iTunes to flash their own custom firmware onto the iPhone.
Where did it all go wrong?
- Gradual roll-out of the pieces of the security, allowing the adversary to learn
- Firmware was initially unencrypted
- iPhone trusted iTunes in 1.0.2, meaning you could modify the root filesystem by sending commands to restored.
- Easy root access
- Everything used to run as root (epic fail)
Early mistakes:
- Allowing boot-args pmd= and vmd=
- Allowing an unsigned ramdisk (another break in the chain)
- This let us flash our first modified bootloaders, and allowed us to experiment even more with custom kernel-mode code. This allowes even running linux on it.
iPhone Baseband Hacking
This is what Muscle Nerd is working on.
The goal: Removing the sim-carrier lock
Good uses: Travel purposes and others
Boot process is entirely separate from S5L
Connected to S5L via UART, some DPIOs, I2S, and some DMA
Radio peripherals
2nde gen: GPS
Booting is done by a sequenc of loaders. Firmware, which is the main body of code
Nucleos OS, GSM/UMTS stack, (U)SIM support, speech and data via I2S.
EEPROM & NVRAM – NOR param blocks
Radio and wifi specific calibration
No DFU-like recovery mode! (so you can permanently break your phone!)
Can really be „bricked“
Fakeblank hack can help on 1stgen
Basic h/w setup: address space, NOR, serial
if NOR is „blank“, allow serial payloads
if not blank, load bootloader from NOR
2nd gen: Signed serial loader override, Bootloader undergoes RSA sig check
Bootloader:
First few NOR sectors
Specific header with two entry points (normal and service mode)
Also includes a trusted device mode.
1st gen: Bootloader NOR sectors are „locked down“ in NOR via GPIO pin. Always-resident interactive serrvice mode, protocol for direct firmware updates. Firmware RSA signature check
2nd gen: Service mode uses loader-over-loader protocol for fiwmware and EEPROM updates. There is no always-there service mode, you have to upload it. Firmware RSA sig check
Next stage: Firmware
- Hardware inits
- GSM/UMTS stacks inits
- (U)SIM support inits
- 2nd gen: GPD device init
Firmware update steps
Reboot the baseband and enter bootloader service mode
2nd gen:
- Load security loader over the bootloader
- Load RAM loader over the bootloader
After that 1st and 2nd gen the same.
Produce signed secpack. Defines which NOR addresses are allowed to be writted or erased.. RSA sig of main firmware.
Finally, send fi
rmware and then EEPROM parameter blocks.
Chain of trust
SIM carrier-lock enforced by FW
- Tables describing which MCC/MNC the iPhone locked to, conditions of the lock and IMEI, all signed with RSA key
- RSA-encrypted S-Gold and NOR-dependant rtoken stored TEA-encrypted with the SIM unlock code
- Need to enter SIM unlock code or to break RSA to produce good token.
Existing firmware integrity is checked by the bootloader (signed with RSA, checked by the bootloader during boot)
New firmware is verified by the service module loader
On the 1st gen phone, existing bootloader is not integrity checked by bootrom (only simple checks)
ON 2nd gen: bootrom integrity checks BL. BL is RSA signed, checked by bootrom. Bootrom is then read-protected by BL.
Exploits
1st gen: Bootloader v3.9
- Bugs in service mode loader allow circumventing secpack restictions
- RSA implementation is prone to Bleichenbacher attack
- Allow fake signatures in firmware signature and in seczone tokens
1st gen: Bootloader v4.6
New bugs in service mode loader allow circumventing secpack restrictions
Tool for this: BootNeuter app
1st gen: JerrySIM. A SIM-card based hack. It was leaked and presumed „burned“.
Exploits 2nd gen
Forget about tryingt to break chain-of-trust to modify firmware in NOR (for now)
Instead oatch the firmware once it’s executing from RAM
Actually safer than reflashing NOR.
Part 1: Unlocking code
- Works alongside already running firmware tasks
- Overrides logic decisions otherwise made by official firmware
- Requires more extensive reversing and understanding of baseband software
- Reusable knowledge
Part 2: Injection exploit
- Injects the unlocking code into the running firmware environment
- Must not crash the running firmware
- JerrySIM hole was still in 01.45.00 but it was fixed during next beta cycle.
- works only if S5L is jailbroken (or if injectable like JerrySIM was)
- The AT parser is a huge body of code (FW undergoes frequent revisions)
- Injection holes are easy for Apple to identify and fix once exploits are published
- Much easier to fix than preventing actual injected code from overriding…
What helped?
- IDA
- Unencrypted FLS file of the baseband firmware updates (including old bootloader versions) allowed us to reverse S-Gold
- JerrySIM allowed extensive reverse engineering of 2nd gen 01.45.00 firmware.
- Hardware rigs for quick bug probing owned by some participants
- internet also helped (chip is used by others, too)
Future
2nd gen iPhone:
- For soft unlock, every new baseband version will probably require a new injection exploit
- But injecting code will need little changing (it’s a rewriting of the firmware’s lock decision
- Good would be a bootrom code to break the chain of trust.
Technorati Tags: 25c3, ccc, iphone, hacking, liveblogging