Extracting the File System from iPhone/iPad/iPod Touch Devices

May 23rd, 2011 by Andrey Belenko

In our previous blog post we have described how we broke the encryption in iOS devices. One important thing was left out of that article for the sake of readability, and that is how we actually acquire the image of the file system of the device. Indeed, in order to decrypt the file system, we need to extract it from the device first.

When it comes to obtaining the contents of iPhone’s file system, mobile forensic specialists usually mention the following three opportunities:

1. One can 'mount' the device, mapping it as a drive letter and copy data file after file. In this mode, I/O requests are served by the file system driver on the device that’s supposed to ‘know’ the encryption keys for all files. Essentially, this means that analyst receives file data that is already decrypted during the transfer. The ‘mounting’ in this case is achieved by using undocumented interfaces provided by Apple iTunes, which makes the researcher rely on something that’s a) undocumented, and b) involuntarily provided by the manufacturer. The amount of data available depends on whether the device is booted into a so-called "jailbroken" state or not. Devices that are not booted into a "jailbroken" state allow access to significantly less information. In "jailbroken" state, all information stored on the device may be available.

It is worth mentioning that booting a device into a "jailbroken" state does not necessarily require a permanent "jailbreak" modification of the device, and can be performed without modifying data stored on the device, i.e. without violating read-only principle so important in computer forensics.

While relatively simple, the file-based approach has numerous limitations that make it less than ideal for forensic purposes. Since the transfer is done file-by file, the case quickly becomes difficult to manage. Typical file system contains tens of thousands of files so it might be quite a challenge to even store them in forensically sound way (i.e. making sure that no files are added, deleted, or modified after acquisition is complete). Another problem is that some files may be locked by running processes, may require additional privileges, symbolic links may interfere with the host system, etc.

2. The second option would be to decrypt file system as a part of acquisition process so that its result is a decrypted file system.

3. Finally, one can do a physical acquisition of the encrypted file system and decrypt the data off-line. This would require an additional step of extracting required keys off the device.

The last two options are indeed very similar. In both cases, I/O requests are served by storage driver (as opposed to file system driver in the first case), effectively bypassing proprietary file system drivers and avoiding all types of file locks and access permission problems. Both methods require the device to be in "jailbroken" state.

Although those last two acquisition approaches are similar and first one might seem more attractive on the first sight, we decided to go with the last one. In our eyes, there are numerous important benefits to doing the physical acquisition in a ‘raw’ way.

1. We believe that physical acquisition should be as close to the original device data as possible. The first method (mounting the device) relies on the file system driver to deliver decrypted file data. If we wanted to implement similar on-the-fly decryption during the physical acquisition process, the resulting image won’t be a bit-to-bit physical copy at all. Instead, we can do those actions off-line, and produce a decrypted image out of a precise bit copy.

2. Some device secrets such as the passcode or escrow keys might not be known at acquisition time. Without knowing those secrets, some files can not be decrypted. Off-line processing allows capturing and storing the original encrypted image while postponing the decryption to a later moment. An analyst can return to the original image if more secrets become available (e.g. escrow keys are discovered on suspects’ desktop computer) without having to re-acquire data from the physical device.

3. Analysts may have a backlog of cases. Re-doing the acquisition with a new tool might not be what they’re looking for. With off-line approach, one can obtain the keys from the device, which takes much less time than re-imaging it.

4. Forensics often already have a favorite (or the only approved) tool to do device imaging. For those who don’t, ElcomSoft can provide a basic one that just works. As long as the tool is capable of producing raw (dd-style) images, the analysts can continue using it.

5. Finally, the tools are not bug-free. The acquisition must be as simple and as straightforward as possible. Having to re-acquire the contents of a 64 Gb iPad because of a glitch in the imaging tool could be extremely frustrating and time-consuming. By performing the decryption as a separate process, one can reduce the risk of this happening.

The Toolkit

Elcomsoft Phone Password Breaker is available to general public. We will also provide eligible parties with additional acquisition Toolkit to use on devices running iOS 4.x. We’ll also provide detailed instructions. The Toolkit will allow the following:

  • Extract hardware-dependent keys, file system keys and escrow keys from the device;
  • Recover the passcode (subject to passcode length and complexity);
  • Obtain bit-to-bit copy of device storage.

After obtaining an image of the device storage area accompanied by device-specific keys, analysts will be able to run Elcomsoft Phone Password Breaker to decrypt the acquired image and then analyze the decrypted image with the forensic tool of their choice.

Tags: , , , ,

Sign up for free ElcomSoft Password Recovery Software newsletter

Leave a Reply

14 Comments on "Extracting the File System from iPhone/iPad/iPod Touch Devices"

Notify of
avatar

volkspost
Guest
volkspost
5 years 3 months ago

So what you are saying is you use a Custom Recovery Ramdisk to boot the root an user partition an dd it then in the first step. Did this all the tim up to iOS 4 when the images started to be encrypted. Right now I have to mount the two partition and go with the files that are decrypted by the iPhone itself.
Cool you found the keys, I have been wondering how long this would take when Apple introduced the new system combining in the users passcode.

hats off, rock on,
v.

Bob Walder
Guest
Bob Walder
5 years 2 months ago
They did NOT find the keys…. the toolkit relies on 1) Possession of the escrow keybag which is stored on any host PC which has sync’d to the device via iTunes (good luck with that if I store my iTunes backups on an encrypted volume, BTW!) or 2) Brute force attack on the device to break the passcode. What they have done that is cool is shown that they can do this. HOWEVER, since any sensible user with data to protect will use a complex passcode consisting of a larger number of alphanumeric & special characters and NOT a simple… Read more »
Paul Creswici
Guest
Paul Creswici
5 years 2 months ago

@Andrey,
It’s precisely that I have to enter the complex password many times a day that makes it workable – repetition of a complex string makes it memorable and practise makes it easy to enter rather than annoying.

Devon
Guest
Devon
4 years 11 months ago

Thanks for this useful information, I will be refering to it for my mobile forensics project. @bob the “wipe device after 10 failed passcode attempts” is useless as the device cracking will be performed in off-line mode if I’m correct?

Jerome
Guest
Jerome
4 years 9 months ago

1) I would assume that if passcode is complex and if the application is storing credentials in keychain with adequate protection attributes (I would assume all attributes would do the job, except the kSecAttrAccessibleAlways), then this information is not accessible by your tool (EBBP). I am correct ?
2) If not, or more generally, do you have some best practices to follow for users AND developers to make sure the information (in keychain items, files, iTunes backup, etc) are well protected and not accessible by your tool ?

JK
Guest
JK
4 years 9 months ago

Does iOS 5 mitigate any of this?

Jezza
Guest
Jezza
4 years 9 months ago

Does this mean that: as long as you can neither break the passcode nor the backup encryption password, the data is safe (both on device and/or computer)?

(i.e. from a user point of view a strong passcode and strong backup encryption password is enough to avoid having the data protection cracked?)

Any point in further encrypting the actual sync folder used by the iTunes?

Faye
Guest
Faye
4 years 2 months ago

Hi just wondering if u can advise in best product to buy? I made a backup of my iPhone 4 on my windows 7 pc, I need a password and told that there will be a file called keychain which has it?

Dary
Guest
Dary
2 years 8 months ago

Hi Guys, will it be possible to extract the whole filesystem and run it inside a Linux or MACOS VM to launch IOS apps on PC?

Alan Kaplan
Guest
Alan Kaplan
2 years 6 months ago
Some put their faith in complex passwords. We think in terms of human frailties. If you’ve ever investigated a “Jimmy Valentine” safecracking, the odds are that rather than the safe being opened by some guy with a magic touch, was open because some guy wrote to combination down on his desk pad or his calendar or on the wall. The same thing is true of computer users. Most of us jot down the password someplace in the computer. Often the password is entered and reentered many times. Further, passwords on one device is often used on several devices. I agree… Read more »
Vladimir Katalov
Admin
2 years 5 months ago

Alan,

Thanks a lot for your comment! Yes, it is definitely a good idea to collect as much information as we can, to create the “target” custom dictionary.

wpDiscuz