IOSurface Kernel Exploit

2010-10-13T20:07:18Z

C0d3r:

This vulnerability, along with the [[Malformed_CFF_Vulnerability]], was used in [[Star]]/[[JailbreakMe]] 2.0. It is a buffers overflow in the handling of the [http://iphonedevwiki.net/index.php/IOCoreSurfaceRoot kernel-extension for managing pixel buffers] used to get root privileges.

== exploit ==

Selector 19 was Vulnerability to a buffer overflow that allow access to the root filesystem without making the kernel fail signature check

{| class="wikitable" style="font-size: smaller; text-align: center; table-layout: fixed; border-collapse: collapse;" border="1"
|-
! Selector !! Action !! Input !! Output
|-
| 0 || lookupFromMachPort || - || 1,208 bytes of stuff
|-
| 1 || release || IOSurfaceID ''surfaceID'' || -
|-
| 2 || lock || struct IOSurfaceLockArg || 1,208 bytes of stuff
|-
| 3 || unlock || struct IOSurfaceLockArg || struct IOSurfaceLockSeedArg
|-
| 4 || lockPlane || struct IOSurfaceLockArg || 1,208 bytes of stuff
|-
| 5 || unlockPlane || struct IOSurfaceLockArg || struct IOSurfaceLockSeedArg
|-
| 6 || lookup || void* ''???'' || 1,208 bytes of stuff
|-
| 7 || setYCbCrMatrix || IOSurfaceID ''surfaceID'', uint32_t ''YCbCrMatrix'' || -
|-
| 8 || wrapClientImage || 28 bytes of stuff || 1,208 bytes of stuff
|-
| 9 || wrapClientMemory || void* ''param0'', void* ''param1'' || 1,208 bytes of stuff
|-
| 10 || getYCbCrMatrix || IOSurfaceID ''surfaceID'' || uint32_t ''YCbCrMatrix''
|-
| 11 || setValue || ? || -
|-
| 12 || getValueMethod || ? || ?
|-
| 13 || kIOSurfaceMethodRemoveValue || ? || -
|-
| 14 || bindAccel || IOSurfaceID ''surfaceID'', void* ''unknown0'', void* ''unknown4'' || -
|-
| 15 || bindAccelOnPlane || IOSurfaceID ''surfaceID'', void* ''param1'', void* ''param2'', size_t ''planeIndex'' || -
|-
| 16 || readLimits || - || 20 bytes of stuff.
|-
| 17 || kIOSurfaceMethodIncrementUseCount || IOSurfaceID ''surfaceID'' || -
|-
| 18 || kIOSurfaceMethodDecrementUseCount || IOSurfaceID ''surfaceID'' || -
|-
| 19 || ? || void* ''???'' || void* ''???''
|-
| 20 || setSurfaceNotify || 24 bytes of stuff || -
|-
| 21 || removeSurfaceNotify || 24 bytes of stuff || -
|}

== Credit ==
[[User:Comex|comex]]

25C3 presentation "Hacking the iPhone"

2010-10-13T19:28:33Z

C0d3r:

{{DISPLAYTITLE:25C3 presentation "Hacking the iPhone"}}
This was a presentation held on the 27 December 2008 at the [http://events.ccc.de/congress/2008/wiki/Main_Page/ 25th Chaos Communication Congress (25C3)] in Berlin. Speakers were [[pytey]], [[User:planetbeing|planetbeing]] and [[User:MuscleNerd|MuscleNerd]].

The presentation explained the inner workings of the iOS architecture, its security, and how it was circumvented. [http://events.ccc.de/congress/2008/Fahrplan/events/2976.en.html Short event description]

During the presentation [[User:MuscleNerd|MuscleNerd]] wanted to show the [http://qik.com/video/729275 video of a live demo of the unlock] with ([[yellowsn0w]]), but skipped it because of the missing time. This video was actually released [[Timeline#December|some days before]].

== Conference Recordings ==
* [http://vimeo.com/2646755?pg=embed&sec=2646755 Conference recording video on Vimeo]
* [http://mirror.netcologne.de/CCC/25C3/video_h264_720x576/25c3-2976-en-hacking_the_iphone.mp4 Conference recording video in H264] or [ftp://ftp.ccc.de/congress/25c3/video_h264_720x576/25c3-2976-en-hacking_the_iphone.mp4 via FTP] or [http://ftp.ccc.de/congress/25c3/video_h264_720x576/25c3-2976-en-hacking_the_iphone.mp4.torrent torrent link]. This version is the best quality available.
* [http://derchris.eu/ccc/25C3/video_h264_iPod/25c3-2976-en-hacking_the_iphone.ipod.m4v Conference recording video in M4V]
* [http://bork.informatik.uni-erlangen.de/pub/ccc/25c3/audio_only/25c3-2976-en-hacking_the_iphone.mp3 Conference recording as MP3 audio]
* [http://ftp.uni-kl.de/25C3/audio_only/25c3-2976-en-hacking_the_iphone.ogg Conference recording as OGG audio]
* [http://events.ccc.de/congress/2008/wiki/Conference_Recordings/index.html Official download page] (look for presentation 2976)
* [http://ftp.ccc.de/congress/25c3/ 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 ==

[[Image:25C3_A01.png|thumb|left|A01]]
=== 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. [[Image:25C3_B01.png|thumb|B01]] This is a slide called hacking the iPhone. I’ll give a little history here about [[iPhone Dev Team|our little crew]]. [[Image:25C3_B02.png|thumb|left|B02]] We formed in [[Timeline#June_4|June 2007]], just before the release of the [[M68ap|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 [[wikipedia:Internet Relay Chat|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. [[Image:25C3_B03.png|thumb|B03]] We’ve got a wide membership: Germany, Belgium, France, Russia, Hungary, USA, Israel. And during those initial few months of the [[M68ap|iPhone first generation]] DHL and FedEx shipped around a lot of US phones to us. [[Image:25C3_B04.png|thumb|left|B04]] We’ve got some statistics here of our little site. We’ve had about 1.7 million visits in the last month. [[Image:25C3_B05.png|thumb|B05]] Fifty, sixty thousand unique visitors per day and various networks around. [[Image:25C3_B06.png|thumb|left|B06]] We’ve got a tool called [[PwnageTool|Pwnage tool]] and another tool called [[QuickPwn]] which is viewed here as the next good project. [[Image:25C3_B07.png|thumb|B07]] It’s a [[wikipedia:Cocoa (API)|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 [[wikipedia:Sparkle (software)|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. [[Image:25C3_B08.png|thumb|left|B08]] 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 [[[wikipedia:Sparkle (software)|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 [[PwnageTool|Pwnage tool]] on a regular basis, so I think they like our software, which is pretty cool. Thank you very much Apple. (big applause)

[[Image:25C3_B09.png|thumb|B09]] I’ll just introduce my colleagues here. We’ve got [[User:Bushing|bushing]] on the end. He’s one of the guys. This is [[User:MuscleNerd|MuscleNerd]] (laughter) - I don’t know why. This is [[User:Planetbeing|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 [[User:Planetbeing|planetbeing]] who’s gonna talk a bit about the applications processor side of the iPhone. Thanks.

=== Part 1: Applications Processor (by [[User:Planetbeing|planetbeing]]) ===
[[Image:25C3_C01.png|thumb|left|C01]] So my talk is gonna be about the application’s processor side. That’s the chip that runs the [[iOS|iPhone OS]] in all the racing car games that you all see in the [[App Store]]. [[Image:25C3_C02.png|thumb|C02]] It’s only related to the [[Unlock|baseband unlock]], because the iPhone has two [[ARM]] processors and the [[S-Gold_2|baseband modem]] has one of them and the [[S5L8900|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 [[S5L8900|application processor]]. And you know our goal is to execute custom code on the [[iOS|iPhone OS]]. [[Image:25C3_C03.png|thumb|left|C03]]The purpose of doing so is to launch third-party apps, [[activation]] of the iPhone which allows the [[iOS|iPhone OS]] to recognize unofficial carriers, and it also provides a useful platform for the [[Unlock|SIM unlock]] because then we can use the [[iOS|iPhone OS]] to directly communicate with the [[Baseband_Device|baseband modem]]. So I’m gonna just go over some of the security framework of the [[M68ap|iPhone]], and first of all I’m gonna talk about the basic software architecture of the device. [[Image:25C3_C04.png|thumb|C04]]

As Apple advertised the [[iOS|iPhone OS]] architecture is basically [[wikipedia:Mac OS X|Mac OS X]]. If you look at a disassembly of the [[kernel]], you can see that it’s basically [[wikipedia:XNU|XNU]], which is the kernel for the [[wikipedia:Mac OS X|Mac OS]], it’s basically [[wikipedia:XNU|XNU]] code compiled for [[ARM]]. A lot of the userland architecture is also the same. There is [[wikipedia:Launchd|launchd]], which is the Mac OS version of [[wikipedia:Init|init]] like Linux is [[wikipedia:Init|init]]. It’s a little bit bottomized, there’s no command line switches, but, you know it’s basically the same thing, have launch [[wikipedia:Daemon (computer software)|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 [[iOS|iPhone OS]] is that there’s an additional [[wikipedia:Daemon (computer software)|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 [[wikipedia:Multiplexing|multiplexes]] the USB connections and it establishes an [[wikipedia:Transport Layer Security|SSL]] [[wikipedia:Tunneling protocol|tunnel] between a [[wikipedia:Internet socket|socket]] on the computer and on the iPhone. It’s basically like [[wikipedia:inetd|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? [[Image:25C3_C05.png|thumb|left|C05]] The [[iOS|iPhone OS]] primarily runs on a [[NAND]] flash disk. To userland it appears as a normal [[wikipedia:Device file#Block devices|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 [[wikipedia:Flash file system|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 [[iOS|iPhone OS]] is protected. [[Image:25C3_C06.png|thumb|C06]] Third-party applications and everything else that’s modifiable on the [[iOS|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 [[Category:Exploits|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. [[Image:25C3_C07.png|thumb|left|C07]] The [[kernel]] is stored on the system partition, which again is mounted read-only. It’s a big [[wikipedia:Blob (computing)|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 [[wikipedia:Lempel–Ziv–Storer–Szymanski|LZSS]] and encrypted and signed. And you can’t alter this [[kernelcache]], except as [[wikipedia:Superuser|root]]. So even if you got a code execution [[Category:Exploits|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 only just take briefly take you to the [[boot process]] for the iPhone.

[[Image:25C3_C08.png|thumb|C08]] 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 [[NOR (NVRAM)|NVRAM]] for the OS which concludes [[wikipedia:Kernel panic|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 [[wikipedia:Master boot record|MBR]] for the [[NOR]], which it does the same thing that the [[wikipedia:Master boot record|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. [[Image:25C3_C09.png|thumb|left|C09]] The next stage in the [[S5L8900#Boot Chain|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 [[wikipedia:Open Firmware|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 [[M68ap|iPhone]], one for the [[N82ap|iPhone 3G]] and one for the [[N45ap|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 [[wikipedia:Gamma correction|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.

[[Image:25C3_C10.png|thumb|C10]] 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 [[iPhone Restore Procedure|restore process]] and I’ll explain why in a second after I tell you what it is. [[Image:25C3_C11.png|thumb|left|C11]] Every stage in the [[S5L8900#Boot Chain|boot process]] that I described earlier can abort to either a [[DFU Mode|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 [[iPhone Restore Procedure|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|Restore ramdisk]] to this [[iBoot]]. And then [[iBoot]] boots the [[kernel]] from the [[Restore Ramdisk|ramdisk]. The [[iPhone Restore Procedure|restore process]] itself is actually conducted by this [[Restore Ramdisk|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 [[S5L8900|applications processor]] that is. At any point because you can always bootstrap the [[iPhone Restore Procedure|restore process]] like this. [[Image:25C3_C12.png|thumb|C12]] The way that this [[iPhone Restore Procedure|restore process]] is protected is that [[iBoot]] that’s loaded from any stage is signature-checked before being executed. The [[Restore Ramdisk|ramdisk]] and [[kernel]] is also signature-checked by [[iBoot]], and [[restored]] itself signature-checks the [[wikipedia:Apple Software Restore|ASR]] image in a [[NOR]] firmware and it already sits on a signature checked [[Restore Ramdisk|ramdisk]], so itself cannot normally be modified. [[Image:25C3_C13.png|thumb|left|C13]] Also, everything is encrypted with a key that’s derived from a hardware [[wikipedia:Advanced Encryption Standard|AES]] key. This [[wikipedia:Advanced Encryption Standard|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 [[Restore/Update Ramdisks|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 [[wikipedia:FileVault|FileVault]] and the way that’s done is that [[wikipedia:FileVault|FileVault]] key and also the expected [[wikipedia:Secure Hash Algorithm|SHA]] hash of the filesystem is stored on a encrypted [[Restore/Update Ramdisks|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. [[Image:25C3_C14.png|thumb|C14]] 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]].

[[Image:25C3_C15.png|thumb|left|C15]] 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 [[wikipedia:Distinguished Encoding Rules|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 [[Image:25C3_C16.png|thumb|C16]] 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 [[Image:25C3_C17.png|thumb|left|C17]] highlighted areas it makes space on the stack for three certificate structs. So what you wanna do is construct a certificate [[wikipedia:Distinguished Encoding Rules|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. [[Image:25C3_C18.png|thumb|C18]] 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. [[Image:25C3_C19.png|thumb|left|C19]] 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 [[Restore/Update Ramdisks|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.app|Installer]]. We use the [[Pwnage 2.0|DFU exploit]] to load a version of [[iBoot]] that doesn’t perform signature checking and then we use the normal [[iPhone Restore Procedure|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)

[[Image:25C3_C20.png|thumb|C20]] 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. [[Image:25C3_C21.png|thumb|left|C21]] Another vulnerability in 1.1.1 and 1.1.2 is that everything used to run as [[wikipedia:Superuser|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. [[Image:25C3_C22.png|thumb|C22]] 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 [[Restore/Update Ramdisks|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 [[Restore/Update Ramdisks|ramdisk]] pretty easily, because when we upload a [[Restore/Update Ramdisks|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 [[Restore/Update Ramdisks|ramdisk]] is still in memory, so we can use pmd= or vmd= to construct a [[Restore/Update Ramdisks|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 [[Restore/Update Ramdisks|ramdisk]] right away. And allow us to flash our first [[bootloader]]s. 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 [[User:MuscleNerd|Musclenerd]] to describe the [[Baseband Firmware]].

=== Part 2: Baseband (by [[User:MuscleNerd|MuscleNerd]]) ===
(in work by [[User:http|http]], will follow here)

=== End and Q&A ===
(in work by [[User:http|http]], will follow here)

[[Category:Events]]

The iPhone Wiki - User contributions [en]

IOSurface Kernel Exploit

25C3 presentation "Hacking the iPhone"