Most expert reviews mean physical access to the device, and the expert has two tasks to achieve: retrieve as much information and data as possible and leave as little evidence of such retrieval (artifacts) as possible. The second task is especially important when the results of such forensics are to be presented in court: too many artifacts may impede a follow-up expertize, which is, in turn, may compromise the results of the initial one. In many cases it is impossible to avoid such artifacts; one of attempts to solve this problem is a detailed record of each artifact created on various stages of the investigation.
The data stored on iOS devices is protected rather well, and you’ll have to overcome the following obstacles in order to retrieve them:
- Passcode. It protects the device from unauthorized access (including the forensics) and provides cryptic protection for some part of the data. It means that even if you somehow bypass the passcode, some files and Keychain records will be unavailable, because the device won’t be able to get matching cipher keys without the passcode.
- Keychain. It is a centralized storage for passwords, tokens, cipher keys and other secrets recommended by Apple for application developers to keep their important data. Physically it’s a SQLite3 base with all the records encrypted. The access to this base is performed indirectly through ‘securityd’ service requests.
- File encryption. Unlike full disk encryption systems (FDE) iOS encrypts each file with a separate key (reminds me of EFS in Windows). Some files are protected with a key derived from the device’s unique key and can be decrypted without passcodes. Some of the files are protected in such a way that it’s impossible to decrypt them without a passcode.
These three mechanisms together form a data protection subsystem that first appeared in iOS4 and complicated forensics significantly. After iOS4 was issued Data Protection has changed insignificantly but for one thing: Secure Enclave appeared in iPhone 5 and later models. Secure Enclave is used under Data Protection for operations with fingerprints, passcode, cipher keys, etc.; but we won’t review it in this article.
The following methods are usually used to retrieve data from iOS devices:
- ‘Physical retrieval’ allows to get a bit-to-bit disk image, all cipher keys and, in most cases, allows searching passcodes (if selected). Generally physical retrieval requires code execution in the user space with root and out of the sandbox. This method used to be popular several years ago, as the weakness of old device loaders (such as iPhone 4 or old iPads) allowed to run a bunch of random codes on the device. Physical retrieval is possible for later models (in some ways) only with ‘jailbreak’, so we won’t review it today.
- ‘Logical retrieval’ retrieves data with the help of interfaces and services already installed on the device and used by such programs as iTunes or Xcode. Creation of iTunes backup copy is a classic example here: you don’t need to install any additional programs, it contains a lot of useful information about the device (including contacts and calls, correspondence history, location history, photos/videos). But the story doesn’t end with just backup. iOS devices contain other services allowing to obtain access to data.
- Retrieval from iCloud allows to download the device’s backup copy from the cloud. But to do this you need to know authentication data for the Apple device’s ID: Apple ID and the password or authentication token. The backup copy stored on iCloud contains reams of important information too.
When we talk about ‘logical retrieval’ the key term for us is device-to-host pairing. The device will often respond only to requests sent from the host (or the hosts) it was paired with earlier. The pairing record consists of two parts; one of them is stored on the device, the other is located on the host. The record is created when the device pairs with a new host for the first time. In order to create such a record the device has to be unlocked (i.e. you have to enter the passcode to pair the devices); the user must confirm creation of a pairing record on the device (starting with iOS7; earlier iOS versions used to create the record automatically).
The pairing record contains cipher keys for the whole content stored on the device and therefore can be used to connect the device and unlock it. In other words, in the context of access to encrypted data the pairing record is the same as the passcode: with any of these factors you can unlock the device and obtain access to all the (encrypted) data.
In the context of practical use it means that logical retrieval requires an actual pairing record from a trusted computer or the passcode (to create this record). Most iOS services won’t run and return data without it.
We’ll need a virtual or a physical machine running Linux for our research. Basically, Linux may be of any build; the only important thing is correct performance of ‘libusb’ and ‘libimobiledevice’. I’m going to use Santoku Linux, the distributive build, among other things, to carry out Android and iOS-based investigations. Unfortunately, Santoku Linux doesn’t contain everything we need, so we’ll have to “polish” some elements by ourselves.
In order to perform logical retrieval we’ll need
libimobiledevice being a cross-platform library for communication with various iOS services. Unfortunately, Santoku Linux 0.5 comes with the outdated
libimobiledevice version (1.1.5), which doesn’t provide full support for iOS8. That’s why we’ll install the latest (1.1.7) build and all its dependencies first (use the provided links to download archives, unpack, go to the created folder and run
./autogen.sh && make && sudo make install):
- libimobiledevice-1.1.7 — please pay attention to –enable-dev-tools key, as it includes a build of additional utilities, we’ll need it in the future and use it to communicate with some iOS services: ./autogen.sh –enable-dev-tools;
- usbmuxd-1.1.0 — it seems that –without-systemd key is necessary for Santoku 0.5, as ‘usbmuxd’ won’t run without it: ./autogen.sh –without-systemd;
If everything is OK, then it’s the very time to plug in some iOS device to a PC (or a VM) and check whether the host can see it:
santoku@santoku-vm:~$ idevice_id -l 23f88587e12c30376f8ab0b05236798fdfa4e853 santoku@santoku-vm:~$
This command should display the identifiers (UUID) of the devices connected.
The next step is to get detailed information on the device. ‘ideviceinfo’ utility is designed for this. It can be used in two variants:
- ideviceinfo –s displays common information on the device without any attempt to create a new host-to-device pairing or use the existing one;
- ideviceinfo [-q <domain>] [-x] displays much more detailed information, but requires a host-to-device pairing. The utility requests info from ‘lockdownd’ service running on the device. The information features key-value pairs, the keys are grouped into domains. The ‘-q’ parameter can be used to indicate a specific domain from which the data needs to be retrieved.
The ‘-x’ parameter allows to format program display as XML (or rather as property list), so the display may be redirected to a file, and then process it with other programs or scripts.
You can get access to application data under the logical retrieval. First you have to obtain the list of installed applications with the help of ‘ideviceinstaller’ utility:
santoku@santoku-vm:~$ ideviceinstaller -l Total: 4 apps com.viaforensics.viaprotect-app - NowSecure 1 com.facebook.Facebook - Facebook 6017145 ph.telegra.Telegraph - Telegram 39280 com.getdropbox.Dropbox - Dropbox 3.6.2 santoku@santoku-vm:~$
As a result, we’ll get an identifier for each application (so called bundle ID), its name and version. With application ID we can access to its data. These two iOS services — ‘house_arrest’ and ‘afc’ — are used for this action. AFC (Apple File Conduit) is a file access service; iTunes uses it to obtain access to music and other media files on the device.
house_arrest is a less known service that allows to run AFC server in a specific application’s sandbox; it is used for implementation of File Sharing function in iTunes.
But that’s all theory. In reality using of ‘ifuse’ utility is enough to get access to files of the application:
santoku@santoku-vm:~$ ifuse --container com.getdropbox.Dropbox ~/Desktop/Applications/ santoku@santoku-vm:~$
As a result of this command, the directory containing the application’s data will be mounted in ~/Desktop/Applications directory:
santoku@santoku-vm:~$ ls ~/Desktop/Applications/ Documents Library StoreKit tmp santoku@santoku-vm:~$
The application data can be mounted with fusermount –u ~/Desktop/Applications command.
Device backup traditionally serves as one of popular vectors of data retrieval, which is not at all surprising taking into account the fact that backup by definition must contain reams of important information on the device and its owner. You can use ‘idevicebackup2` utility to create a backup:
santoku@santoku-vm:~$ idevicebackup2 backup --full ~/Desktop Backup directory is "/home/santoku/Desktop" Started "com.apple.mobilebackup2" service on port 50066. Negotiated Protocol Version 2.1 Starting backup... Enforcing full backup from device. Backup will be unencrypted. Requesting backup from device... Full backup mode. [= ] 1% Finished Receiving files .... Received 237 files from device. Backup Successful. santoku@santoku-vm:~$
Backup may take rather long (up to half an hour) depending on the amount of content.
Another potential problem related to backups is that they cannot be encrypted. Backup encrypting in iOS is performed on the part of the device, so if the user has protected the backup with a password, then all the data given out by the device during backup will be encrypted. You can still try to sort out the password with various commercial or free tools. The access to backup contents is impossible without a password.
By default idevicebackup2 saves backup copies in iOS own format that doesn’t fit for manual research, because, for example, it uses the SHA-1 hash function value instead of the file name. The advantage of this iOS own format is that many programs know how to work with it, so it is enough to open the backup with one of such programs in order to analyze its contents (e.g. iOS Backup Analyzer, iBackupBot, or iExplorer).
If, by some reason, you need a backup of a more “readable” format then you can use ‘unback’ command:
santoku@santoku-vm:~$ idevicebackup2 unback ~/Desktop
This command will create _unback_ directory on the desktop where the device backup copy will be saved as a traditional file tree, but not as a list of files with pseudo-random names as before.
The ‘ifuse’ utility can be used to access to file system of iOS-based device. Note that standard AFS service only allows access to contents of /var/mobile/Media directory where photos, videos, films, music and other media files are stored. This directory can be mounted with ifuse ~/Desktop/Media/ command.
If ‘jailbreak’ was performed with AFC2 service installed on the device, then your access capabilities will broaden up significantly. AFC2 is the same AFC but with access to the whole file system, but not only to /var/mobile/Mediadirectory. The device’s root file system can also be mounted as follows:ifuse –root ~/Desktop/Media/. The device mounting is performed the same way as obtaining access to application data, withfusermount –u ~/Desktop/Media` command.
File_relay is one of less known iOS services allowing in some cases to obtain data unavailable through other interfaces. The service is present in all iOS versions starting with 2.0 (the OS was called iPhone OS then), but the list of available data changes from version to version.
In order to retrieve data through file_relay service you may use filerelaytest utility (it will only be compiled if you indicate –enable-dev-tools parameter with libimobiledevice configuration):
santoku@santoku-vm:~$ filerelaytest Connecting... Requesting AppleSupport, Network, VPN, WiFi, UserDatabases, CrashReporter, tmp, SystemConfiguration Receiving ......................................................................................................... Total size received: 393414 santoku@santoku-vm:~$
This command will perform connection to
file_relay service and request a fixed list of sources: AppleSupport, Network, VPN, WiFi, UserDatabases, CrashReporter, tmp, SystemConfiguration. Each of such sources is one file or more from the device. The complete list of sources for iOS8 is provided in the insertion. In order to send a request for a certain source you just need to use its name as a parameter for
santoku@santoku-vm:~$ filerelaytest Accounts Connecting... Requesting Accounts Receiving .......... Total size received: 31217 santoku@santoku-vm:~$
The result (i.e. retrieved data) will be written into dump.cpio.gz file located in the current directory. It may be unpacked with standard gunzip and cpio utilities:
santoku@santoku-vm:~$ gunzip dump.cpio.gz santoku@santoku-vm:~$ cpio -idmv < dump.cpio . ./var ./var/mobile ./var/mobile/Library ./var/mobile/Library/Accounts ./var/mobile/Library/Accounts/Accounts3.sqlite ./var/mobile/Library/Accounts/Accounts3.sqlite-shm ./var/mobile/Library/Accounts/Accounts3.sqlite-wal ./var/mobile/Library/Preferences ./var/mobile/Library/Preferences/com.apple.accountsd.plist 6297 blocks santoku@santoku-vm:~$
This service used to be exceptionally useful before iOS8, as it helped retrieve data which was unavailable through other interfaces (e.g. when the backup is encrypted). But starting with iOS8 Apple introduced additional verification procedure: in order for
file_relay service to run, the device must be provided with a specific configuration profile signed by Apple.
During installation of such a profile a com.apple.mobile_file_relay.plist file will be created in /Library/Managed Preferences/mobile/ directory. The file will contain the following:
<--?xml version="1.0" encoding="UTF-8"?--> Enabled
When running file_relay checks availability of this file and the value of ‘Enabled’ key in it, then it only returns data if it is set ‘true’.
Starting with iOS5 the devices may create their own backup in iCloud and recover from such backup at the initial setup. In order to access data you need to know Apple ID and the password. One of open source solutions for such procedure is iLoot. The utility is rather simple to use, so I don’t see it necessary to explain anything: you provide your Apple ID and password, and after that you get backups downloaded from iCloud. As of this writing, iLoot doesn’t work with accounts for which two-step authentication is enabled.
In my article I tried to describe available ways to retrieve data from iOS devices, and these ways don’t require financial expenses. Such important aspect as analysis of retrieved data was left off screen, as the topic is much more extensive and mostly depends on iOS’s version and programs installed. So I deem it difficult of accomplishment to do a “general” discussion on this topic. Nevertheless I hope that the material turned out to be interesting and you could learn something new. Happy hacking!