|
The iPhone Wiki is no longer updated. Visit this article on The Apple Wiki for current information. |
25C3 presentation "Hacking the iPhone"
This was a presentation held on the 27 December 2008 at the 25th Chaos Communication Congress (25C3) in Berlin. Speakers were pytey, planetbeing and MuscleNerd.
The presentation explained the inner workings of the iOS architecture, its security, and how it was circumvented. Short event description
During the presentation MuscleNerd wanted to show the video of a live demo of the unlock with (yellowsn0w), but skipped it because of the missing time. This video was actually released some days before.
Contents
Conference Recordings
- Conference recording video on Vimeo
- Conference recording video in H264 or via FTP or torrent link. This version is the best quality available.
- Conference recording video in M4V
- Conference recording as MP3 audio
- Conference recording as OGG audio
- Official download page (look for presentation 2976)
- Official FTP server (look for presentation 2976)
The presentation slides are currently not available. Maybe one of the presentators can upload them here or post a link.
Transcript of the presentation
Start
Good evening everybody. I would like to introduce the iPhone Dev Team who are here to give a talk on iPhone hacking. So if you join me to give a round full of applause please.
Introduction (by pytey)
Good evening ladies and gentlemen. Here’s a little slide show here for you.
This is a slide called hacking the iPhone. I’ll give a little history here about our little crew.
We formed in June 2007, just before the release of the original iPhone. We’re original hardware hackers and device enthusiasts, based around Apple products and we sort of rather say towards the iPhone as a platform. We exist on IRC. This is the first time most of us have met each other. Originally there was a couple of channels on the osx86.hu server.
We’ve got a wide membership: Germany, Belgium, France, Russia, Hungary, USA, Israel. And during those initial few months of the iPhone first generation DHL and FedEx shipped around a lot of US phones to us.
We’ve got some statistics here of our little site. We’ve had about 1.7 million visits in the last month.
Fifty, sixty thousand unique visitors per day and various networks around.
We’ve got a tool called Pwnage tool and another tool called QuickPwn which is viewed here as the next good project.
It’s a Cocoa application. It’s got 20,000 lines of code. QuickPwn has got 15,000 lines of code. There’s also other platforms: Windows and Linux as well. We’ve had 3.6 million Sparkle updates since we last deleted our logs, which was in the 16th of July. We try to release patches when Apple releases an iPhone update.
We try to get patches out 24-48 hours after the release of those updates. And the modular bundle sets for cross-platform use. We use Sparkle for updates for the Mac platform, as I mentioned. An interesting lead: There’s a 180 very active users from Apple who update their QuickPwn and Pwnage tool on a regular basis, so I think they like our software, which is pretty cool. Thank you very much Apple. (big applause)
I’ll just introduce my colleagues here. We’ve got bushing on the end. He’s one of the guys. This is MuscleNerd (laughter) - I don’t know why. This is planetbeing. And we’ve got a bunch of other guys here we don’t want to be identified for obvious reasons, but they’re over there wearing Pwn-Apple T-shirts. And they speak Russian. (laughter) Say hi guys! (applause)
So with that further I’ll hand you over to planetbeing who’s gonna talk a bit about the applications processor side of the iPhone. Thanks.
Part 1: Applications Processor (by planetbeing)
So my talk is gonna be about the application’s processor side. That’s the chip that runs the iPhone OS in all the racing car games that you all see in the App Store.
It’s only related to the baseband unlock, because the iPhone has two ARM processors and the baseband modem has one of them and the application processor has the other one, and they’re only loosely connected. Each has their own security framework. My portion of the talk will be focusing on the application processor. And you know our goal is to execute custom code on the iPhone OS.
The purpose of doing so is to launch third-party apps, activation of the iPhone which allows the iPhone OS to recognize unofficial carriers, and it also provides a useful platform for the SIM unlock because then we can use the iPhone OS to directly communicate with the baseband modem. So I’m gonna just go over some of the security framework of the iPhone, and first of all I’m gonna talk about the basic software architecture of the device.
As Apple advertised the iPhone OS architecture is basically Mac OS X. If you look at a disassembly of the kernel, you can see that it’s basically XNU, which is the kernel for the Mac OS, it’s basically XNU code compiled for ARM. A lot of the userland architecture is also the same. There is launchd, which is the Mac OS version of init like Linux is init. It’s a little bit bottomized, there’s no command line switches, but, you know it’s basically the same thing, have launch daemons and everything else. System libraries are slightly modified, but they’re pretty much the same as on a typical OS X Mac machine. So instead of the Finder you have SpringBoard as the shell. One important difference between the Mac version of OS X and the iPhone OS is that there’s an additional daemon called lockdownd, and it handles communications with the computer. It basically is the gateway between the computer and the iPhone over the USB cable. It multiplexes the USB connections and it establishes an SSL tunnel between a socket on the computer and on the iPhone. It’s basically like inetd. You can have different services that lockdownd activates. Services like MobileSync, MobileBackup and a rather important one for our purposes is called AFC, which allows the computer to access a small jailed portion to the file system. So our goal here is to sort of subvert this and to modify the operating system, so that we can run our own code. How do we do this?
The iPhone OS primarily runs on a NAND flash disk. To userland it appears as a normal block device. So if you’re familiar with the Mac OS terminology, it’s under /dev/rdisk0s1 /dev/rdisk0s2. There’s two logical partitions on a NAND drive. There’s a system partition, which is mounted at root, and there’s a user partition. The system partition is read-only, and these are only logical partitions, and they sit on top of an FTL which convert the logical partitions which are better suited for traditional disk drives to NAND flash geometries, which, you know, have peculiar things, like be only able to erase a block at a time.
Here is how the iPhone OS is protected.
Third-party applications and everything else that’s modifiable on the iPhone OS are installed on the user partition. The system partition is read-only, so in case the iPhone crashes you don’t have to recheck the system partition for file system integrity. Every program, every executable on the iPhone is signature-checked when the system call execv is executed on that. All executables must be signed by Apple and the signatures and the hashes are stored in the mark-up format as segments and because the signatures are only checked when the program starts you can still use code execution if you have a buffer overflow or a stack overflow, but the limitations of that is that all the applications like MobileSafari or MobileMail and everything else run as a mobile user, so they can’t really alter the operating system. The signature-checks are implemented inside the kernel. So in order to do our thing, in order to run third-party applications, we have to modify the kernel. Here is how the kernel is protected.
The kernel is stored on the system partition, which again is mounted read-only. It’s a big binary blob with the kernel and all the kernel extensions, KEXTs, which basically provide driver functionality for Mac OS X and they are all concatenated together and compressed with LZSS and encrypted and signed. And you can’t alter this kernelcache, except as root. So even if you got a code execution, you still need a privilege escalation exploit as well in order to modify this file. And even if you could do that, the kernelcache is signed, so if you modify it, your system will stop booting. So, to get around that, we need to look at how the signature for the kernel is checked. And I’m only just take briefly take you to the boot process for the iPhone.
The first piece of code that’s loaded on the iPhone is the bootrom. It’s Secure-Boot as Apple’s terminology is. I mean it’s kind of a lie as you find out later. So the first thing that it does is it loads from NOR flash a program called LLB. The NOR flash supplements the NAND flash. It’s just an 8 megabit NOR flash and it serves as the NVRAM for the OS which concludes kernel panic logs, bootloader variables. It also has a file system, or a kind of a rudimentary one; a list of images that contain the bootloaders themselves. So the LLB is, like the way I put it, is that it’s the MBR for the NOR, which it does the same thing that the MBR does on like an x86 machine. It reads the image-less format and it loads the next-stage bootloader from the image list, signature-checking it first before executing it.
The next stage in the boot process after LLB is iBoot, which is loaded from the image list. If you’re familiar at all with the Mac boot process, iBoot is an analogous to Open Firmware. On a Mac machine, instead of the kernel probing devices and discovering what hardware is there, the bootloader provides the kernel with the DeviceTree which has all this information already included. And iBoot loads the DeviceTree from the NOR. The DeviceTree - there’s one for each different type of platform, one for the iPhone, one for the iPhone 3G and one for the iPod touch. And this DeviceTree is only partially populated. There’s still some device-specific things, like the serial number that must be added by iBoot. Also Apple uses different components from different vendors in their manufacturing process. There’ll be like a few different types of LCD panels that they use and a few different types of NAND chips from different vendors, and some of them have their own initialization sequences. Instead of having the kernel do that, iBoot actually does that, which makes the kernel more flexible. So it populates the DeviceTree with gamma tables, Wi-Fi calibration data, it does all of that. And then finally it loads the kernel from NAND and executes it. The thing here is that iBoot checks signatures on everything. It checks signatures on the kernel, it checks signatures on the DeviceTree, and even the boot logo and graphics that it displays. So we need to get around this in order to do our eventual goal of running unsigned applications on the iPhone. And the whole structure works like this. You have this whole chain that signature-checks the kernel and then the kernel signature-checks all the userland applications.
So there’s one slight problem with this scheme. We know that userland applications are signature-checked by the kernel, which is good. And the kernel is signature-checked by iBoot, so that’s good. iBoot is signature-checked by the LLB. OK. But is the LLB signature-checked by the bootrom? No! So, that’s a big problem. So all we need to do is just flash our own LLB and then patch all the signature-checking on all the subsequent stages and then we can run our own code. This is a little bit easier said than done though. The only way we can flash the NOR is through the restore process and I’ll explain why in a second after I tell you what it is.
Every stage in the boot process that I described earlier can abort to either a DFU or Recovery Mode, and it’s activated by either keypresses or if the next stage can’t load. Recovery Mode is basically a USB or serial console. It’s a feature of iBoot. And DFU Mode is just a mode where iBoot can be loaded and you can get into Recovery Mode. So the restore process is basically a version of iBoot is loaded- a newer version, the latest one- is loaded by iTunes onto existing version of iBoot or DFU Mode. And then iTunes sends the latest kernel and a Restore ramdisk to this iBoot. And then iBoot boots the kernel from the ramdisk. The restore process itself is actually conducted by this ramdisk/kernel combination, lockdownd daemon, called restored. The lockdownd thing, as I described, it communicates with iTunes, it downloads of ASR image. I don’t know if you guys know about ASR, but it’s an Apple backup thing. ASR image from iTunes: it also downloads NOR firmware to be flashed. And the good thing about this process is it’s actually very well designed. It’s pretty much impossible to break the iPhone because of this process. Because you can at any point... break the applications processor that is. At any point because you can always bootstrap the restore process like this.
The way that this restore process is protected is that iBoot that’s loaded from any stage is signature-checked before being executed. The ramdisk and kernel is also signature-checked by iBoot, and restored itself signature-checks the ASR image in a NOR firmware and it already sits on a signature checked ramdisk, so itself cannot normally be modified.
Also, everything is encrypted with a key that’s derived from a hardware AES key. This AES key we can’t read it, but the code on the iPhone can use it. These keys are disabled from any boot that’s not from a signed ramdisk. So this means that even if we’re able to find a code execution exploit on a normal boot and have a privilege escalation exploit and communicate with the kernel and tell it to flash the NOR, we still can’t do it, because we’re not in a secure mode. The filesystem itself is encrypted with FileVault and the way that’s done is that FileVault key and also the expected SHA hash of the filesystem is stored on a encrypted ramdisk. And this way everything is encrypted. This makes it difficult for us to do our work, because we can’t read any code and we can’t reverse engineer it. That’s the way that they planned it.
So it still sounds pretty secure. All the modification that this graph shows the modification vectors for every piece of the software that I mentioned. And you see that everything signature-checks everything else pretty much. So, it’s still pretty secure even if the bootrom doesn’t signature-check LLB, as long as you can’t modify the NOR.
Well, there’s one problem, is that this chain can be broken. And what place we break it is at the bootrom level or where they can’t patch it or fix it in any way. So it’s a pretty much your standard stack overflow exploit. They’re processing certificates which are on a DER format. They copy all the certificate information onto the stack, but the signature itself is copied into this data structure without any sort of bounds checking. So then you have this classic stack buffer overflow and then you just make the signature checking function return true. I was just gonna show you – I probably don’t have enough time to do a very thorough job of this, but basically
this is the function that we want to return true. We want to jump to offset 57EC and make R4=1, because our R4 gets moved into the return value later. CheckCertificateAndGetSecureBootOnes is the function that has the vulnerability. As you can see, in the
highlighted areas it makes space on the stack for three certificate structs. So what you wanna do is construct a certificate DER that’s structured like this. The thing that’s overflowable is MCertSignatureValue, so you have 0x30 bytes of padding at the end of covered the rest of these and then you can start loading the registers with your own exploit values. So 1 for R4, we don’t really care about the other registers.
And the offset 57EC for the PC – for the program counter. So that’s basically our exploit. What we load from this is what we called Pwnage, which is our complete solution as it were.
What we do is we patch every single stage, like where I mentioned all the signature checks, we patch all of those out. And what we do, we patch out in the LLB, iBoot, kernel, the restored on the ramdisk, and on the filesystem image, because we patched out the signature checking on restored, we can put our own sort of App Store for unsigned programs for things that Apple won’t support. And the two most popular ones are Cydia and Installer. We use the DFU exploit to load a version of iBoot that doesn’t perform signature checking and then we use the normal restore process to restore the rest of it; to flash the rest of this onto the iPhone. And what ends up happening is that we can use iTunes to flash our own custom firmware onto the iPhone. So, yeah. (applause)
Just briefly I just mentioned stuff that Apple did wrong, to make the job easier for us and probably the biggest reason is that instead of rolling out all this wonderful security mechanisms at once, they did it piece by piece and they sort of made a few mistakes early on in the process. And by doing so they allow us to get access to pieces of code and we’re able to reverse engineer it and we were able to figure out how it all worked and where the vulnerable points are and how to attack it. One of the early mistakes is in 1.0.2. The iPhone actually trusted iTunes which we can modify easily. At that point we could actually send custom restore commands and jailbreak the iPhone. Another call was none of the executables were signed at that point, so you could make a simple file system alteration and you’re jailbroken.
Another vulnerability in 1.1.1 and 1.1.2 is that everything used to run as root. So if you find a vulnerability within any userland program, then you have root. They also left some interesting things like /dev/kmem which means that we can poke and peek kernel memory and execute kernel code, so that was kinda bad.
And finally probably the mistake that first allowed Pwnage was they left the boot arguments pmd= and vmd= and these boot arguments can construct a ramdisk to boot out of anything. And that basically... not out of anything but out of any contiguous portion of memory. And that allowed us to bootstrap a ramdisk pretty easily, because when we upload a ramdisk, the iPhone has to store in memory somewhere and then signature check and then decide whether it wants it pass on to the kernel based on whether the signature is correct. But even if it fails the signature check, the ramdisk is still in memory, so we can use pmd= or vmd= to construct a ramdisk out of that portion of memory that it temporarily stores or upload in. And then this basically allowed us to boot from an unsigned ramdisk right away. And allow us to flash our first bootloaders. We learn a lot from this process. We now have added quick control over the iPhone’s hardware to even run Linux on it, so that’s basically where we are. I’ll pass it to Musclenerd to describe the Baseband Firmware.
Part 2: Baseband (by MuscleNerd)
right i am musclenerd i am part of the team is sorted in to baseband gyes and s5l gyes all thoe there is sort of a crotch i have spent most of the last few month's on the baseband side the gole on the baseband side is to remove the sim carea lock we want it completely gone for the first generation phone there where good resin's because there whereat any market's that other than the usa that you could use the iphone so there was a push to get unlock for the next generation it was open to more market's out there but there are some valid resin's other than just the challenge of it to get a software based or a non apple based unlock in to the phone mostly for travel perpus, moving between the market's
the baseband in both version's of the phone is run by a system on chip called the sgold there was the original sgold and the sgold 3 it's a full system on chip it's completely different from the s5l ( over on the application side ) it is connected to the s5l throughout some limited hardware mens serial lines, gios some i25script and some dam is used for audio there is some scattered radio peripharal's on that side three is some unique id that are permuntley etched in to the sgold to the nor that are firmware they uniquely identify your phone and come in to play a little bit later
the second generation also has gps that sort of a hardware over view software over view it's sort of got the same rhyme as the s5l side there is a sequence of loader's some of the are that first one the bottom is based in hardware we believe it is mask rom we hope it's not because if it's not and we do some thing to apple they well try to reprogram the bootrom's in the field and that would be glorious to see and we could reuse that our selves but we beleve it in mask rom so the bottom load's the bootloader witch load's the firmware witch is where that heumungus bit of code is and where all of the action takes place so that includes nucleus witch is a comet invented operating system's the gsm is in a stack and sim support and stk support and all the thing's you'd expect from the radio so there is a sequence and when i do the next few slides i will describe a little bit more detail about itch of those component's oh i forgot these what they are calling eprom and nvram witch are really just part's of the nor but there are in parameter blocks witch are smaller so you can program them faster these hold things that are well they hold two thing's tied to the baseband and thing's that are tied to your phone for example your wifi is calibrated at the factory and there is a useque set of calibration data that was determined at the factory that works with your particle rf chip to a specific profile so some of it changes depending on the baseband and some of it never changes unless you change phone
now the big thing about the baseband is and the most irritating thing is there is no recovery mode and i have alway's being jealous of planetbeing and wizdat and pumpkin and all these gyes because they alway's had a failsafe to give them a free pass to do any thing you think of to the phone some of us throughout point's have erased the nor and completely invalidated the llb like that and what happens if you have an invalid llb ( sort of a second stage ) is your phone rapidly flashes away in black with like these horrible looking sere marks going down the screen and it's very scary to watch and you think it's completely gone and we nicknamed it crismastree mode zf but as bad as it looked at the time al long as you where good with timing you can alway's enter dfu mode and recover from that there is nothing like that in the baseband there are thing;s you can do the the bseband or the images in the nor that can permontley brick your phone and on the first gen i mentioned this fakeblank thing but i will get in to it later
so now each of the bootloader's the boot rom is just the basic setup it maps the some of the tightly cupeled memory, it maps the external nor coming to the address space set's up the serial then it goose through a sequence of checks it checks to see if the nor is blank and does not check the whole nor is blank but it looks at certain key location's to see if blank if it is blank then it allows through the serial port you to upload your next stage loader if it's not blank it will go off and load it in he second generation but int in the first generation the serial payload that you send to the bottom has to be sighed with an apple certificate that was not true in the first generation phone and we actually made use of that not being true in the first generation phone quite a lot because it gives you low lever access to the baseband also in the second generation phone the bootloader it's sylph is normally signature checked to make sure it has not being tampered with and if it does not match the sinned hash then it just wont load it it will just stay there in the bootrom and spin that wasn't true in the first generation phone the bootloader which is this next step is the first few nor sectors it has a couple different entry point's normal, service mode but there is completely separate witch is only enabled by having that bit set in that chip i mentioned early it is set then considered trusted or a developer, engineer device of cross any of these thing;s i will talk about in the next few slides the bootloader in the first generation phone the nor sector's where locked down so they are not normally erasable but evan if you got the authority to remove them you would need to lift a signal to get the pin it's like an extra lockdown
the bootloader is alway's in the nor and it is invokeable and it is very easy to invoke and that bootloader it sylph i don't know if that is it's name or whether it is an official term or wether it was developed by the community but that bootloader that allows you to go off and program the next stage as long as you pass the check and one of those checks is a signature check on the firmware so the bootloader i don't think 3.9 but 4.6 bootloader on the first generation phone does signature check the firmware except for the bootloader it's sylph not being checked i guess the chain of trues begins at that point in the second generation phone unlike the first generation phone that interactive loader is not there in nor it is permanent you have to upload it you have to upload a payload that the rom acsept's with key's and along as you have the authority to do that it will go off and upload a second stage loader there is this devishon of trust in this loader of a loader that is hard to brake and it signature checks then next stage that next stage being firmware
(in work by http, will follow here)
End and Q&A
(in work by http, will follow here)
