ElcomSoft blog

«…Everything you wanted to know about password recovery, data decryption,
mobile & cloud forensics…»

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

May 23rd, 2011 by Andrey Belenko
  • 1

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.

  • 1

Tags: , , , ,

Sign up for free ElcomSoft Password Recovery Software newsletter

14 Responses to “Extracting the File System from iPhone/iPad/iPod Touch Devices”

  1. volkspost says:

    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,

  2. Bob Walder says:

    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 4 digit passcode, then my guess is that on-device cracking of the passcode is not realistic. ALSO, if user has set “wipe device after 10 failed passcode attempts” then…. this stuff makes for good headlines but it is not “game over” for iOS 4 users by any stretch of the imagination

    • @Bob,
      1) Escrow keybag is not required. Without both escrow keybag and the passcode we can decrypt almost every file and significant part of the Keychain. Let me say this again: having only the device and not knowing the passcode nor having escrow keybag we can decrypt very significant part of its device contents. FDE on your PC does not help.
      2) Do you REALLY use complex alphanumeric passcode (passcode – and not backup password)? You have to enter it like dozens of times a day and I don’t think many people are using something really complex. That quickly becomes annoying. Also, the ‘wipe device after 10 attempts’ is irrelevant here, too, since we bypass all sort of such protections. And it is a ‘game over’ for iOS 4 in some environments with certain security requirements.

  3. Paul Creswici says:

    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.

  4. Devon says:

    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?

  5. Jerome says:

    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 ?

    • 1. What you are saying is generally true when getting data from the device itself and not from the backup. Keychain items protected with classes above the kSecAttrAccessibleAlways are impossible to decrypt without the passcode (or the escrow keys in iOS 4). EPPB, however, works only with the backups and the story is slightly different there.
      If backup is encrypted and backup password is known then all keychain items from the backup can be decrypted (except for those with …ThisDeviceOnly protection classes). Device passcode protection does not matter here.

      2. For developers I’d suggest to use standard system services for storing sensitive data (i.e. use Keychain and do not re-invent the wheel crypto) and to use the most restrictive protection classes for both keychain items and application data files.
      For users – use complex passcode, do not connect the device to third-party PCs, use backup encryption.

  6. JK says:

    Does iOS 5 mitigate any of this?

  7. Jezza says:

    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?

  8. Faye says:

    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?

  9. Dary says:

    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?

  10. Alan Kaplan says:

    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 that in many cases a brute force attack is just not feasible timewise. How many weeks or months can we afford to wait? Accordingly our approach is to go after a dictionary attack. We do this with FTK set up to produce a literal list of words on SUBJECTs computer. We convert that into a dictionary and use that dictionary in PRTK to produce passwords of any sort that had been used or noted on the computer. Using that approach a password such as $E~18stD^ becomes child’s play as long as the user has cooperated by jotting it down on the hard drive. One can then take the passwords derived from the computer hard drive and apply them to the cellular phone.

  11. 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.