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.