iPad Forensics and Data Theft

I recently had an opportunity to do some testing on the iPad, I wanted to evaluate the methods for performing forensics and the ability for someone to recover data off of the device. Apple’s security implementation on the iOS platform is pretty abysmal. In this post I will talk a little about the iOS platform and go over some of the techniques I used to pull data off the device. I have a few more tricks that aren’t mentioned here, and hopefully I will get a chance to type those up in the near future.
All of this information is available out there somewhere, but I didn’t find a nice complete guide of how to get at the data without permanently jailbreaking the device. None of this is original research, and I don’t have any association with any of the software developers and hackers that built these tools.
The premise is that when performing forensics you should modify the device as minimally as possible. This isn’t always possible, but with iOS it is particularly difficult because accessing the data requires a jailbroken kernel and a few *nix utilities. The most common approach (at least when doing an acquisition in the field) is to use a boot disk, load an operating system into RAM and then perform the data capture.
Before getting into the details, and they are not for someone that is not technically inclined, I want to talk a little about iOS.
Some common misconceptions about iOS (iPhone and iPad):

It isn’t a PC.

Well, it sort of isn’t, it’s a Mac, but aside from marketing distinctions it most certainly is a Unix computer–just with a interface that doesn’t allow you to do anything other than what you are told.

According to Apple’s sales numbers, people like having a limited user interface and no control over the computer they are using.

This leads to a assumption that the device is simple–it is not.

It’s Darwin, essentially a trimmed down version of Mac OS X with Springboard instead of Finder.

Once you load up some tools, you can do most things that any other Unix system can do.

Data isn’t stored on the device, everything is in the “cloud” or stored elsewhere.

No, it has a hard drive (solid state.)

Most applications cache everything you view, you have no control over this, once again the decisions have been made for you.

It tracks your location (this recently made the news.)

It has to keep a log of what you type to make predictive typing work. Yes, it logs what you type.

It’s encrypted, your data is safe.

Technically it is encrypted, but Apple did such a poor job of implementing the key management, the encryption is rendered completely useless.

There IS a second layer of encryption that is new in the 4.x releases of iOS, so far it only applies to mail.app.

Calendars ARE NOT encrypted–how much email is embedded in calendar requests in a corporate environment? You might be surprised.

Unless you can decrypt the keychain, you can’t get access to these files (in theory this can be done, but who knows if the videos posted to youtube are real.)

Only applies if 4.x was installed from scratch. Upgraded your iPad/iPhone from 3.x? Your data is still plaintext.

That said, Apple actually got something right: remote wipe works like a champ. As long as your device is turned on, and on a network, you might be able to stop someone from stealing information off of it.
Tools I found useful:
All my testing was completed on a Mac, it is likely that there are equivalent programs for Windows or Linux, but I will not provide any information on those. Please, don’t send me questions about other operating systems, I would be interested to know about them, but I don’t have time to research this on your behalf. (I will say most of this stuff has significant overlap with other operating systems, so it is probably a good starting point.)
Miscellaneous Tools
DiskAid :

That should be most if not all of the tools I used to pull this off. The process isn’t trivial, and I urge you to read up on what each tool does. I am not associated with any of these projects, and I won’t provide any type of support. If you are doing this I assume that you are technically competent working a Unix environment, if you couldn’t figure this out on your own, my notes will be of little use.Overview of the process for gaining access to an iOS device without modifying the device’s disk:

Super-short overview:

Create custom ramdisk, and kernel that includes an OpenSSH daemon.

Use DFU mode to push ramdisk, kernel, and then boot the device.

Create TCP tunnel over USB.

Access device over SSH.

Profit.

Detailed overview:

Shutdown the device.

Remove the SIM card

Download Apple’s IPSW for the version and hardware you are working on.

Make a copy of the IPSW and rename the copy with a .zip extension, unzip.

Copy the ramdisk image into the xpwntool directory. (Which one is the ramdisk? Look in the PwnageTool bundle plist file (see below) for the Restore Ramdisk filename.)

Mount the ramdisk . (By default, OSX will not enable “owners” and will not preserve file permissions, this is problematic for SSH, which checks that its config files are owned by root. SSH won’t start if the files have incorrect permissions. Use the “-owners on” flag.)

Extract the ssh.tar from RecoveryRamDiskBuilder into the mounted disk image. (Once again, be sure to preserve permissions. )

Unmount the image.

Re-encrypt the image using xpwntool, place the file in your working directory for the attack (I put it in the tetheredboot directory, easiest not to have to type long paths when loading the ramdisk.)

Use Pwnagetool to create a custom IPSW. (Use expert mode. Specify the IPSW file you grabbed from Apple. Don’t install any packages–including Cydia.)

Rename the *custom* IPSW with a .zip extension, and unzip.

Copy the iBSS and kernel cache files to a working directory where you will be performing the process (I just put these in the same directory as the tetheredboot executable. The bootloader and kernel files disable the executable signing protection for the iOS operating system (aka Jailbreak.) Don’t worry though, we aren’t going to permanently jailbreak the device, this is just for creating a ram-disk bootable device, we won’t write to the SSD during this process.)

Place iOS device in DFU mode (Hold power and home for 10 seconds , hold home for 15 seconds )

Apple has been dropping new versions at an unbelievable rate. So these notes were already outdated by the time I wrote this up. These instructions definitely work on 4.2.1, and 4.3.0. I had some problems running this exact procedure on 4.3.1 & 4.3.2. I did have some luck using a 4.2.1 ramdisk image against an iPad running 4.3.1, but I can’t say with confidence it will work all the time. This is untested on an iPad 2, but I have been able to use this on both an iPhone 3g and iPhone 4. Don’t ask me for help if you can’ make it work, I am just too busy, sorry.
This procedure isn’t for the faint of heart, and most likely what worked for me won’t work for you. This isn’t a recipe, don’t expect it to work without modification and testing. If you need to do this for an investigation I can only suggest that you have another device, same hardware and software version, to test on before trying this.
Here are some of my command syntax notes, for building the recovery images, and getting a copy of the filesystem (your paths will be different, but this should be sufficient for seeing the options):
Note: I didn’t cut long statements for readability–I left them intact so it is possible to cut and paste.
Setup a working directory

1

mkdir -p ~/Desktop/iOS-4.2.1/tetheredboot

1

cd ~/Desktop/iOS-4.2.1/tetheredboot

wget isn’t standard on OSX, use macports if you want to install it. I just use it for demonstration purposes, you can just use your browser.