As promised in their yellowsnow demo, [pytey], [MuscleNerd], and [planetbeing] from the iphone-dev team presented at 25C3 on their work Hacking the iPhone. The team originally formed in 2007 and this is the most detailed presentation on how the iphone was compromised to date. You can find the full talk embedded above.
They opened with a few stats about how popular their software is. Our favorite by far is that at least 180 people with Apple corporate IPs update their phones using the dev-team’s software on a regular basis. From there the talk was split into two sections: jailbreaking the S5L application processor and unlocking the S-Gold baseband processor.
The phone counts on a chain of depend on to guarantee that only Apple’s code is being run on it. all of userland is signature checked by the kernel. The kernel is checked when loaded by iboot. The iboot image is checked when loaded by LLB. LLB is loaded from the nor by the lowest piece of code, the bootrom. That’s where things fall apart; the bootrom does not check the signature of the LLB. To take advantage of this, the team found what they describe as a classic stack buffer overflow in DFU mode. DFU is device Firmware upgrade mode, a state that the phone can be forced into after the bootrom loads. Their exploit forces the certificate check to return ‘true’. They are then able to patch all of the subsequent signature checks out of the phone’s system.
The baseband processor verified to be much a lot more tough simply because it doesn’t have any sort of recovery mode; bricking a phone was always a possibility. The S-Gold is a complete system-on-chip and has a special ID on each phone. The nor also has a special ID on each phone. These two IDs are used to sign the secpack, which in turn enforces the SIM carrier lock. These special IDs are why you can’t just take an officially unlocked phone and copy the secpack off of it to unlock another phone. everything else is identical: the firmware, the baseband, the bootroom are all the same. On the second generation iPhone, the bootrom checks the bootloader. The bootloader then verifies the bootrom before checking and then loading the firmware. The firmware enforces the carrier lock. The team made a decision that it wasn’t worth attempting to break the chain of trust. The SIM unlock code they developed is divided into two sections. The first part is the actual software unlock. They patch the firmware while it’s running in RAM. Their patch modifies the firmware’s decision tree about whether to enforce the carrier lock. The second half is the exploit that allows them to inject the code. The team knows that Apple can and probably will patch the exploit hole, but their RAM patching code will always work, so it’s just a matter of finding another hole to apply it through. In buy to do a permanent unlock option (like on the first generation iPhone), they’d need to examine the actual bootrom code.
The team pointed out several things Apple did that actually helped them in their efforts. safety was gradually rolled out, so they were able to look at things that would eventually be hidden. The firmware was initially unencrypted. earlier versions trusted iTunes, something they could easily modify. All userland apps originally ran as root indicating any application exploit gave root level access.
The iphone-dev team has genuinely put in a incredible amount of effort and we look forward to the yellowsn0w release on new Year’s Eve.