|
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 internal presentation is number 2976.
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.
Conference Recordings
- Vimeo.com
- MP4@720x576 HTTP (mirror.netcologne.de) [MD5]
- MP4@720x576 FTP (ftp.ccc.de)
- M4V HTTP (derchris.eu)
- MP3 HTTP (bork.informatik.uni-erlangen.de) [MD5]
- OGG Vorbis HTTP (ftp.ccc.de) [MD5]
- Official download page (Presentation 2976)
- Official FTP server (Presentation 2976)
- Slides
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 our 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 gravitated 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 an Xcode 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 without further ado, 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's 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 exploits 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 exploit, 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 just going to briefly take you through 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 list 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 Restore Ramdisk. The restore process itself is actually conducted by this Restore Ramdisk/kernel combination, lockdownd daemon, called restored. The lockdownd thing, as I described, it communicates with iTunes, it downloads an 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 brick 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 Restore 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 Restore 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)
I'm MuscleNerd. I am part of... The team is sorted into baseband guys and S5L guys, although there is sort of a crossover. I've spent most of the last few months on the baseband side. The goal on the baseband side is to remove the SIM carrier lock. We want it completely gone. You know, for the first-gen iPhone there was a good reason to do it because there weren't any markets other than the US that you could use the iPhone, so there was a big push to get the first generation unlocked. For the next generation, obviously it was open to a lot more markets out there but there are some valid reasons, other than just the challenge of it, to get a software based or a non Apple-based unlock into the phone mostly for travel purposes, just moving between the markets.
The baseband in both versions of the phone is run by a system on chip called the S-Gold. There was the original S-Gold and the S-Gold 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 means: some serial lines, some GPIOs, some I²S and some DMA which is used for audio mostly. There's some scattered radio peripherals on that side. There's some unique IDs that are permanently etched in to the S-Gold into the NOR that are firmware. They uniquely identify your phone and they'll come in to play a little bit later.
The second generation also has GPS. That's sort of a hardware overview. Software overview, it's sort of got the same rhyme as the S5L side; there is a sequence of loaders. Some of them are, that first one, the bootrom is based in hardware. We believe it is mask ROM. We hope it's not because if it's not and we do something stimulating to Apple they may go off and try to reprogram the bootroms in the field and that would be glorious to see if we could reuse that ourselves. But we believe it's in mask ROM. So the bootrom loads the bootloader, which loads the firmware, which is where that humongous bit of code where all of the action takes place. So that includes Nucleus, which is a common invented operating system. The GSM is in a stack, SIM support and STK support, and all the things 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 each of those components. oh i forgot these what they are calling EEPROM and NVRAM, which are really just different parts of the NOR, but they're in parameter blocks, which are smaller so you can program them faster. These hold things that are two different things tied to the baseband and things that are tied to your phone. For example your Wi-Fi is calibrated at the factory and there is a unique set of calibration data that was determined at the factory that works with your particular RF chip to a specific peripheral. So some of it changes depending on the baseband and some of it never changes unless you change the phone.
Now the big thing about the baseband, and the most irritating thing, is that there is no DFU/Recovery Mode, and I've always been jealous of planetbeing and wizdaz and pumpkin and all these guys because they always had a failsafe to basically give them a free pass to do everything you think of to the phone. Some of us at several points have completely erased the NOR, and completely invalidated the LLB and things like that. And, what happens if you have an invalid LLB in there, which is sort of that second stage, is your phone basically just 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 "Christmas Tree Mode" Zf... But, as bad as it looked at the time, as long as you were good with your timing of your fingers, you can always enter DFU Mode and recover from that. There is nothing like that in the baseband; there are things you can do the the baseband and to the NOR, or the images in the NOR, that can permanently brick your phone and on the first... I mentioned this fakeblank thing but i will get in to it later.
So now, each of the bootloaders...So the bootrom is just the basic hardware setup: it maps the some of the tightly coupled memory. It maps the external NOR coming to the address space. It sets up the serial. Then it goes through a sequence of checks. It goes off and checks to see if the NOR is blank, and doesn't really check to see if the whole NOR is blank, but it looks at certain key locations to see if they're blank. If it is blank, then it allows, through the serial port, you to upload your next stage loader. If the bootloader's not blank, it will go off and load it. In the 2nd generation phone, but not in the 1st generation phone, the serial payload that you give to the bootrom has to be signed with an Apple certificate. That was not true in the 1st gen. phone and we actually made use of that not being true in the 1st gen. phone quite a lot 'cause it gives you really low-level... very early access to the baseband CPU. Also, in the 2nd generation phone the bootloader itself, which would normally be the next stage in the process is first signature-checked to make sure it has not being tampered with. And if it does not match the signed hash then it just wont load it; it will just stay there in the bootrom and spin. That wasn't true in the 1st gen. phone. The bootloader, which is this next step, is the first few NOR sectors. It has a couple different entry points. Two of the entry points are used for normal versus service mode. But there's also this completely separate bit which is normally enabled only by having a certain bit in that chip ID I mentioned earlier. And if that is set, then it's considered a trusted or a developer device, or an engineering device, and it doesn't enforce any of these things I'm about to talk about in the next few slides. The bootloader in the 1st gen. phone... The NOR sectors... In NOR terminology, they're locked down, so there's actually... not only are they not normally erasable but even if you had the authority to erase them, you'd have to lift a signal on a pin to allow that to go through. It's like an extra lockdown.
The bootloader is always in the NOR and it is invokable 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 trust 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 accepts 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 devision 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.
So the firmware is where everything except for the booting happens so this is where your wikipedia:Radio hardware get's setup and the stack's and sim start's and STK his is where all the action is once the firmware is up and running this is done by nucleus it's basically the whole program of the phone the only thing that can bring it out of this mode is a crash or a power off the firmware can be updated obviously and in the next few slides our brief description of an update.
You basically reboot the baseband with a control signal you ping it and tell it to enter service mode that i talked about in the second generation phone this is where you do that multi stage loader of the loader it sylph so there is this security loader and this ram loader but in the first generation Phone it was a lot easier you just reset it and ask it please go into service mode that is where they differ at that point they sort of join up again and you basically give these loader's what called a secpack it's basically it's a file that sinned by apple and verifiably sinned by the bootloader and it defines what NOR addresses you are allowed to touch what the signature of the firmware you are about to load so it's a sinned package describing what is about to happen if any of thoes field's are mutated in any way the signature fails.
If all of those thing's pass you send the firmware and the bootloader takes care of updating the upper NOR so this is the chain of trust i am going to do it in reverse order so the sim carear lock which is our ultimate gole is enforced by the Firmware defiantly do not want to go into detail because there is a lot of table's that describe the phone whether the lock exist's it's tied to two id i mentioned earlier the CHIPID of the sgold and the NOR there is TEA encryption there is RSA encryption there all the thing's that go on in the seczone the only difference between a locked and an unlocked phone in the official sense is the tables that are encrypted in the seczone the firmware is identical the baseband is identical the bootrom is identical everything is identical except the seczone that linked to a chipped and norid that is why you cant just take an officially unlocked phone somehow copy the firmware over to a locked phone and somehow make it unlocked because that seczone would not verify the bootloader and the firmware it's sylph would try to decrypt it with that phones CHIPID and NORID it would be bogus it would not recognize it.
So this is the check for the existing firmware the existing firmware will not be run of the integrity check fail's witch mean's someone has come in after the fact and changed the nor on there is also update process so new firmware is verified by the service mode loader and it is verified with all the usual checks and then this loader overloader stuph and here is a simile thing in the S-Gold side the bootloader witch is that first thing in NOR it is the first programmable thing you can touch the bootloader is not integrity checked by the bootrom witch is that thing that exist in hardware so there is no integrity check so if you have the mean's to change the bytes in the nor you can take control of the baseband there is only a few checks maybe there is garbage in the nor a few magic value cheek's it's not an integrity check as opposed to the second generation phone where the bootrom does a full integrity check of the bootloader this last point is important the the bootrom after handing control to the bootloader the first thing the bootloader does not evan 20 instruction's in to the sequence it maps the bootrom and it map's it out in a way that you can never bring it back without doing a full reset and we see what look's like Port knockin' which is used to tell the bootrom never to come back so and that is the limitation hope fully we will have time to get in to that at the end.
So now to the exploit for the first generation Phone there where two bootloader's published there are actually more at first in packages by apple but the only ones in play where 3.9 and 4.6 without boring you the bug's in 3.9 where allowed you to bypass the secpack restriction's by doing some address manipulation's in other word's the secpack said you cannot program at this address for this many bites but it didn't say you could start a little bit early and progress right through the previously restricted area so all you had to do was back up where you wanted to write from write garbage if you want then write what you really want to write so it was just an address bug there is also a Bleichenbacher attack it's different form the secpack research hack does is that check that is done by the bootloader to weather the Firmware is ok uses RSA an xpwnent 3 version of RSA witch is subject to this Bleichenbacher attack witch is basiculy a way to forge the RSA in a way it passes to import a limitation on RSA and it's interesting because this Bleichenbacher attack actually comes in to play and if you place it not only does it allow you to forge the Firmware it actually is used in the seczone and this iPhone SIM Free solution was the first software solution out there for the first generation phone actually used this bleichenbarher attack on the seczone to mutate the token's in a way that they went really valid if you used them with the chipid and norid of the phone it would still fail but if you just blinds use rsa on them it will look the end result would look valid like an unlocked token those where the two primary bug's on the 3.9 4.6 had some different bug's allowed you to bypass the secpack restriction's again the secpack is a constant newsence and any thing you can do to get rid of it's restriction's is good this baysiculy a different version of the -0x400 well i shuldent say that there is another way to trick the address verification of the secpack on the first generation Phone the bootrom does not check the integrity of the bootloader there is this application witch we put out called BootNeuter not only did it allow you to reprogram it but it also allowed you to nuttier it or fakeblank it neutering was a way to permuntley remove all the secpack checks on that phone so it was a patch in the bootloader that would forge that i talked about earlier and make it look like a developer phone called neutering and it takes the secpack completely out of the picture fake blank was just a way to allow the phone to normally boot but if you really wanted to get in there at the low level an give a serial payload before the bootloader has a chance to run you can actually do both normally you whuldent be able to the very last sort of exploit was JerrySIM it was a simcard based hacked witch allowed unsigned code execution in the baseband due to a buffer overflow JerrySIM was leaked and we presume it to be burned lost forever because at the time it was leaked the 3g was being developed and there was no update's for the first generation Phone they had all this time to see what we where exploiting in JerrySIM.
There are exploit's for the second generation phone the chain of trust is tough to beat but it's not impossible to beat it whuld be possibly easier if we had an image if the bootrom but we don't so now we will forget about breaking the chain of trust and just patch the firmware running out of RAM in a way it is safer than flashing NOR because flashing NOR has a bunch of risk that can be user related if the user does something at the wrong time they can put the phone in this permeant brick that i talked about this doesn't have that risk.
There are two part's of this soft unlock there is the unlocking code witch is your ultimate payload it's what you want to get into the running firmware and allow it to code the firmware and baysiculy what you do is reprogram the firmware while it is in ram you basiculy change the desition that would normally take place when a sim is inserted and wether it is allowed to operate the development of the unlocking code takes a little bit more investment because you have to understand what apple has intended in the firmware but that is the downside but once you got that out of the way the principle that the unlock is reusable over and over again as there Firmware changes i don't have time to go in to the demo of code injection but that is on our blog so that first part is the unlock code the body of code that you want to run on the baseband the second part is important you need to get that code in to the running firmware to inject the exploit you need to do it in a way that does not crash the firmware because once you crash the baseband goes through that whole boot process begin's again the chain of trust is reenforced the ram is wiped out anything you may have patched in ram is gone and your at square 1 again the resin i mentioned JerrySIM ageing is because JerrySIM is still present in the first release of the iPhone 3G, the whole is still there can actual fix it and they fixed it during the beta cycle before 2.0.1 this injection only works if you are jailbroken the jailbreak is important to the 3G soft unlock you can only do this if you are running code that apple doesn't want you to be running.
Apple is definitely going to be closing any of these exploit's as we use them similar to the jailbreak to the first generation Phone every time we made a jailbreak for the iPhone they patched the whole that was used similarly to the soft unlock every time they see how we are injecting this unlock code the are going to fix it it's going to go a way fast so injection holes are easy for apple to identify because we use them but there will be this cat and mouse game that steve job's said and the community said i think the unlock code that is injected is not fixable there was a live demo of the unlock yesterday the demo on the blog what helped the soft unlock was IDA not just the second generation phone but the [M68AP|first generation Phone]] we had the unencrypted flash files of the firmware and we where able to reverse engineer different stages in the baseband boot JerrySIM was very important during that long gap i mentioned where apple wasn't was doing update's to the firmware we where actively using JerrySIM we had an early release of 1.45 firmware i had a lot of time to peak and poke at that firmware JerrySIM wasn't used in the field. It was used internally though.
What also helps is that we have team members that have different hardware rig's for probing different injection exploit's so this is from w_ this is a rig that he has without going in to the detail it is basically a muckcenter mucks between the real simcard and a pic controller allowing him to quickly fuzz the baseband of holes in the STK or other part's of the sim ovilusley the internet is a big help because there is a lot of help because the S-Gold 3 is not unique to apple other phone's use it and other groups do similar thing's for other phone's address maps and low level hardware identified just because they had parale effort's for other devices.
There is nothing left to be done to the first generation Phone the application side is completely venerable there is nothing they can do to patch it we have complete control over the baseband for the first generation Phone the second generation phone for now the soft unlock is great it's a great first step but it would be nice to have a permeant unlock like the first generation Phone the problem with the soft unlock is people will update there Firmware blindly and lose the soft unlock and will have to what for a new injection exploit to be found to inject the unlock code but the unlocking code it's sylph wont need to be changed again it might need to be relocated because the baseband change's the location but the unlocking code it's sylph is not taking advantage of a bug that apple does the firmware it's basically just reprogramming the Firmware and there is very little that apple can do to change that we are just dynamically changing the restriction.
This is the last slide the two last thing we need to find the bootrom so that we can really have a more permeant unlock assuming there is an exploit that can be found to change the chain of trust and there is another side project is a utility for dumping GSM packages and logging them and there are a few cheaper devices that allow you to do that and the tench used in the soft unlock is running wrong with the existing firmware and it interactively coperates it's running there sort of dealing with the same thing packet's processed allows basically to dump an unlock and that is it.
(audience claps)
End and Q&A
So we have three minute's for questioning :
Q: Hello I heard Apple is trying to attack you on the OS X directly. Is there any truth in Apple blocking you from running PwnageTool on OS X?
A: That was actually a bug we believe it was a bug in. Yea I actually had a look in to that. In fact iTunes crashes also with the same bug so it's not a mulitious attack from Apple it's simply a bug we think it will go a way soon.
Q: Is it possible to dump the bootrom of the baseband by unsolding the chip and then soldering the RomChip to a test board and dumping from the hardware positive?
A: Not the bootrom when we talk about a RomChip. It's not an external chip as it is buried inside the processor remember that 100 rectangle image the bootrom could be any one of those rectangle's.
Q: In the other room some one was chopping the top of chip's off and extracting the data? ([1])
A: We want to talk to that guy that would be a way to dump the memory.
Q: If you get your hand's on an unlocked iPhone, can you dump the information from this one to an load it into your own bootloader?
A: No I tried to address that earlier the code base is genetical there is no difference between an unlocked phone and a locked phone the only difference is between the seczone and the whole purpose of the seczone is to be unique to your phone the information in that seczone cannot be copied e.g if you take the seczone from an unlocked phone and copy the seczone to another phone that phone will not work anymore you cannot copy that seczone.
Q: Have you had any communication with Apple?
A: Since we started in 2007 we have had no communication with Apple what so ever; well Steve Wozniak was interested but we have had no formal communication with Apple we are vey careful what we ship no copywrited code and that is the resin we are not hassled by them they are quite nice but they do fix the bug's
Q: Is there any motivation for the next generation iPhone?
A: Yes it's fun.
Q: I got the iPhone in the Netherlands, and when they connect it to iTunes they unlock it for £10
A: It's the same question, no.
OK, so, thanks very much, and we will see you later.
