RSS

Tag Archives: ios 5 forensics

iPhone Forensics – Analysis of iOS 5 backups : Part2

In the first part of this article, we discussed the techniques to read iTunes backups. The following article discloses the procedure to extract protection class keys from the Backup Keybag and covers the techniques & the tools to decrypt the protected backup files and the encrypted backups.

Data protection mechanism introduced in iOS 4 protects the sensitive data in files on the file system and items in the keychain by adding another layer of encryption. Data protection uses the user’s passcode key and the device specific hardware encryption keys to generate a set of class keys which protect the designated data. Developers use the data protection API to add protection class flag to the files and the keychain items. On the iPhone, protection class keys are stored in the System Keybag. During the backup, iTunes generates a new set of protection class keys and stores them in the Backup Keybag. Class keys stored in the System Keybag are different from the keys in the Backup Keybag. Protected files and data in the backup are encrypted using the class keys that are stored in the Backup Keybag. In normal backups Backup Keybag is protected with a key generated from the iPhone hardware (Key 0x835) and in encrypted backups it is protected with the iTunes password.

Data protection for files can be enabled by setting a value for the NSFileProtection attribute using the NSFileManager class setAttributes:ofItemAtPath:error method. List of protection classes available for the files are shown in Table 1.

 

iPhone data protection for files

Data protection for keychain items can be enabled by setting a protection class value inSecItemAdd or SecItemUpdate methods. Keychain class keys also define whether a keychain item can be migrated to other device or not. List of protection classes available for the keychain items are shown in Table 2.

 

iPhone keychain data protection

Jean Sigwald, a researcher at Sogeti ESEC labs has released open source forensic tool kit that can be used to decrypt the protected backup files from normal backups and encrypted backups. Below details outline their research and gives an overview on usage of the tools.

Setup:

On Mac OS X, download & install the required python modules (pycrypto, M2crypto, construct and progressbar).

sudo ARCHFLAGS='-arch i386 -arch x86_64' easy_install pycrypto
sudo easy_install M2crypto construct progressbar

Download and install Mercurial (http://mercurial.selenic.com/) to check out the source code from the iphone-dataprotection Google code repository.

hg clone https://code.google.com/p/iphone-dataprotection/
cd iphone-dataprotection

Decrypting Normal backups:

In case of normal backups, the data protection class keys stored in the Backup Keybag are protected by a hardware generated key (Key 0x835). In order to grab the protection class keys from the Backup Keybag Key 0x835 is required and the key is computed only on the device. So decryption of protected files in the normal backup is not possible without having access to the actual device. In forensic investigations the information recovered from the normal backups is less if physical access to the device is not available.

Steps below explain the procedure to decrypt the protected files stored in the normal backup in case physical access to device is obtained. On the iPhone, Key 0x835 is computed by the IOAESAccelerator kernel service at iOS boot by encrypting a static value 01010101010101010101010101010101 with UID. UID is a hardware encryption key embedded in the iPhone application processor AES engine and it is unique for each device. iOS running on the iPhone cannot read the hardware key (UID) but it uses the key to compute Key 0x835 in kernel mode. UID is not accessible to user land process. This restriction can be bypassed by patching the IOAESAccelerator kernel service.

Steps to extract Key 0x835 from the iPhone:

1. Jailbreak your iPhone. If you don’t like to Jailbreak the phone, follow the steps explained in the iPhone Forensics article.
2. On the iPhone, install OpenSSH from Cydia. OpenSSH allows connecting to the device over SSH.
3. On Mac OS X workstation, download device_infos, kernel_patcher and Cyberduck tools.
4. Connect the iPhone and workstation to the same Wi-Fi network.
5. On OS X run Cyberduck and connect to the iPhone by typing iPhone IP address, root as username and alpine as password.
6. Copy device_infos and kernel_patcher executables to the iPhone root directory.
7. Run Mac terminal and SSH to the iPhone by typing iPhone IP, root as username and alpine as password.

ssh  root@iPhone-IP
Password: alpine

8. On SSH terminal, run the below commands to change the execution permissions of kernel_patcher and device_infos.

chmod 777 kernel_patcher
chmod 777 device_infos

9. Patch IOAESAccelerator kernel service to use the hardware encryption key (UID) from user land process. Kernel_patcher script modifies the kernel and applies the required patches to IOAESAccelerator.

./kernel_patcher

* If the kernel is already patched, the above script displays kernel patching failed message.

10. Run device_infos script and supply key835 as a parameter. The script computes the Key 0x835 and displays on the screen. If key835 parameter is not supplied, the script computes all the encryption keys and stores them in a Plist file.

./device_infos key835

Extract encryption keys on iPhone

Once Key 0x835 is grabbed, it is possible to decrypt the Backup Keybag and obtain the data protection class keys. Later these class keys are used to decrypt the protected files in the backup.

11. On Mac OS X terminal, navigate to iphone-dataprotection directory. Run the backup_tool.py script by supplying the iTunes backup directory path.

python python_scripts/backup_tool.py /Users/User/Library/Application Support/MobileSync/Backup/[iPhone UDID]/ [output_path]

If output_path is not mentioned, the script creates [iPhone UDID]_extract directory in the backup folder and extracts the backup files into it.

On the backup, the iPhone keychain sqlite database is stored as a Plist file (Keychain-backup.plist). The Plist file contents are encrypted with the keychain data protection class keys. Items in the keychain can only be viewed after decrypting it with the keychain protection class keys.

Run keychain_tool.py and supply Key 0x835. The script decrypts the Backup Keybag, grabs the protection class keys from 6 to 11 (listed in Table 2) and decrypts the keychain items.

python python_scripts/keychain_tool.py –d /Users/User/Library/Application Support/MobileSync/Backup/[iPhone UDID_extract]/keychain-backup.plist /Users/User/Library/Application Support/MobileSync/Backup/[iPhone UDID_extract]/Manifest.plist

The above script dumps the generic passwords, internet passwords, certificates and private keys from the keychain backup file.

Decrypting Encrypted backups:

In cases of encrypted backups, migratable data protection class keys (6 to 8 listed in Table 2) stored in the Backup Keybag are protected by iTunes password and ThisDeviceOnly class keys (9 to 11 listed in Table 2) stored in the Backup Keybag are protected by Key 0x835 along with the iTunes password. Most of the data stored in the encrypted backups is migratable as the data is encrypted with the iTunes password and it is not tied to a specific device. Files in the backup are encrypted with a unique key for each file using AES 256 in CBC mode. Encryption keys are stored in the Backup Keybag and protected by iTunes password. In order to decrypt the Backup Keybag, grab the protection class keys and decrypt backup files iTunes password is required. So decryption of files in the encrypted backup is not possible without the iTunes password. In forensic investigations the information recovered from the backups is less if the iTunes password is not available. As iTunes does not impose any password strength rules on encrypted backups, it is easy to perform a brute force attack on it. Encrypted backups add a significant difficulty in data recovering and it may be impossible with a complex password in use.

During the backup iTunes stores the encrypted backup password on the iPhone keychain. So if the backup password is unknown and physical access to the device is available, the backup password can be retrieved by viewing the iPhone keychain items. On a JailBroken iPhone, all the keychain items can be viewed using keychain_dumper tool.

Tools like iPhone Backup Extractor & iPhone Backup Browser does not work on encrypted backups. They can only read & parse the Manifest.mbdb file and prepares a file structure. However the file cannot be opened as the content is encrypted.

Steps below explain the procedure to decrypt the files stored in the encrypted backup with a known iTunes password.

Run backup_tool.py and supply iTunes password to it. In case if the password is unknown, modify the backup_tool.py script and attach a brute force script to it. Backup_tool.py script takes the user entered password, decrypts the Backup Keybag, grabs all the encryption keys and decrypts the files in the backup.

python python_scripts/backup_tool.py /Users/User/Library/Application Support/MobileSync/Backup/[iPhone UDID]/ [output_path]

If output_path is not mentioned, the script creates [iPhone UDID]_extract directory in the backup folder and extracts the backup files into it.

On the encrypted backup, the iPhone keychain sqlite database is stored as a Plist file (Keychain-backup.plist). The Plist file contents are encrypted with the migratable and ThisDeviceOnly keychain data protection class keys.

To view migratable keychain items run keychain_tool.py and supply iTunes password.
To view ThisDeviceOnly keychain items run keychain_tool.py and supply Key 0x835.

python python_scripts/keychain_tool.py –d /Users/User/Library/Application Support/MobileSync/Backup/[iPhone UDID_extract]/keychain-backup.plist /Users/User/Library/Application Support/MobileSync/Backup/[iPhone UDID_extract]/Manifest.plist

The above script dumps the generic passwords, internet passwords, certificates and private keys from the keychain backup file.

During an iPhone backup, iTunes only stores the existing files to the backup. So it is not possible to recover the deleted files on the iPhone from backups.

Conclusion:

Techniques illustrated in the article shows that forensics investigation is possible on the latest version of iPhone backups. However the information recovered from the backup alone without physical access to the device is less. Apple is also changing the backup mechanism with every major release of iTunes. So it is always challenging to design the scripts to decrypt the iTunes backups.

References:

  1.  iPhone data protection in depth by Jean-Baptiste Bédrune, Jean Sigwald
    http://esec-lab.sogeti.com/dotclear/public/publications/11-hitbamsterdam-iphonedataprotection.pdf
  2. iPhone data protection tools
    http://code.google.com/p/iphone-dataprotection/
  3. iPhone wiki
    http://theiphonewiki.com

Part 3 of this article will demonstrate the techniques in a video.

I wrote this article for infosec institute. Take a look at the web application security course offered by infosecinstitute.

 

Posted by on May 30, 2012 in iPhone

18 Comments

Tags: , , , , , , , , , , , , , , , , , , , ,

iPhone Forensics – Analysis of iOS 5 backups : Part1

iPhone forensics can be performed on the backups made by iTunes or directly on the live device. Previous article on iPhone forensics detailed the forensic techniques and the technical challenges involved in performing live device forensics. Forensic analysis on live device reboots the phone and may alter the information stored on the device. In critical cases, forensic examiners rely on analyzing the iPhone logical backups acquired through iTunes. iTunes uses AFC (Apple file connection) protocol to take the backup and also the backup process does not modify anything on the iPhone except the escrow key records. This article explains the technical procedure and challenges involved in extracting data and artefacts from the iPhone backups. Understanding the forensics techniques on iTunes backups is also useful in cases where we get physical access to the suspect’s computer instead of the iPhone directly. When a computer is used to sync with the iPhone, most of the information on the iPhone is likely to be backed up onto the computer. So gaining access to the computer’s file system will also gives access to the mobile devices’ data.

Note: iPhone 4 GSM model with iOS 5.0.1 is used for the demos. Backups shown in the article are captured using iTunes 10.6.

Goal: Extracting data and artefacts from the backup without altering any information.

Jean Sigwald a researcher at Sogeti ESEC Labs has released open source forensic tools (with the support of iOS 5) to read normal and encrypted iTunes backups. Below details outline their research and gives an overview on usage of backup recovery tools

Backups:

With iOS 5, data stored on the iPhone can be backed up to a computer with iTunes or to a cloud based storage with iCloud. The article briefs about iCloud backups and provides a deep analysis of iTunes backups.

iCloud Backup:

iCloud allows backup & restoring the iPhone contents over Wi-Fi/3 G to a cloud with a registered Apple account. iCloud backups the photos, application data, device settings, messages and mail, etc. iCloud services were introduced to provide a computer free backup solution. It acts as a remote backup service and allows moving data seamlessly between different Apple devices like Mac, iPod and iPad. iCloud also provide services to track the lost phone, lock the device remotely and wipe the data remotely. iCloud limits the free backup storage to 5 Giga Bytes. However additional iCloud data storage can be purchased by paying annual fees to Apple. iCloud uses a secure token for authentication and secures the content by encrypting it when sent over the internet. Use of a secure token for authentication eliminates the need to store iCloud password on devices. Apple also claims that, all the iCloud data except the emails and notes is stored encrypted on disk using 128 bit encryption algorithm. Encrypted data stored on the disk is decrypted on the fly when requested from an authentication device. Data stored on the iCloud can also be backed up to a computer and more details are available at Apple documentation.

On the iPhone, iCloud backup storage can be turned on/off by navigating to Settings -> iCloud -> Storage & Backup.

iCloud Backup toggle is shown in Figure 1.

                        (Figure 1)

iCloud data is effectively safe from hackers as Apple provides the best authentication mechanism by enforcing the users to use strong passwords, which would prevent the brute force attacks. As long as the user uses a strong password, information stored on the iCloud is safe.

iTunes Backup:

iTunes is used to backup the iPhone to a computer. When the iPhone is connected to a computer for the first time and synced with iTunes, iTunes automatically creates a folder with device UDID (Unique device ID – 40 hexadecimal characters long) as the name and copies the device contents to the newly created folder. The iPhone can be synced with iTunes over Wi-Fi or over an USB connection. If the automatic sync option is turned off in iTunes, the user has to manually initiate the backup process whenever the device is connected to the computer. Once the backup folder is created on the computer, then each time when the device is synced with the iTunes, it will only update the files in the existing folder. During first sync iTunes takes a full backup of the device. From there on, iTunes only backup and overwrite the files which are modified on the device. The behaviour can be observed by looking at different timestamps for the files in the backup. iTunes also initiates an automated backup when the iPhone is updated or restored. During an iOS update/restore, iTunes creates a differential backup with a folder name [UDID] + ‘-‘ + [Time stamp] in the same backup location.  iTunes backup location varies for different operating systems and the exact directory paths are listed in Table-1. Backup files created by iTunes are platform independent and can be moved from one operating system to other.

If a passcode protected iPhone is connected to the computer for the first time, iTunes will require the user to enter the passcode (shown in Figure 2) and unlock the device before starting the sync process.

Upon unlocking the iPhone with a valid passcode, iTunes recognizes the device as authorized and allows to backup and sync with the computer. From there on, iTunes will allow to backup or sync the iPhone without entering the passcode as long as it connects to the same computer. During backup, iTunes also creates a property list file with device UDID as the name and stores the Escrow key bag, Device certificate, Host ID, Host certificate and Host private key in it. Escrow Keybag allows a paired device (normally a computer) to gain full access to the iPhone file system when the phone is in a locked state. This improves the usability by not asking the user to unlock the device during every backup. Escrow key bag location varies for different operating systems and the exact directory paths are listed in Table-2.

Escrow Keybag is encrypted with a key computed from the iPhone hardware (key 0x835) and is protected with a 32 byte passcode which is stored on the iPhone. Escrow Keybag passcode gets stored in a PList file ([Host ID].plist) located at – /private/var/root/Library/Lockdown/escrow_records directory on the iPhone. With iOS 5, Escrow Keybag is also protected with a passcode key derived from the user’s passcode, restricting to perform Escrow Keybag attacks. Escrow Keybag attack bypasses the iPhone data protection mechanism and allows decrypting every file on the device without requiring the user’s passcode. Escrow Keybag is a copy of the System Keybag and contains a collection of protection class keys that are used for data encryption on the iPhone. Protection class keys stored in the Escrow Keybag allows the iTunes to access protected files & keychain items when the iPhone is locked.

iTunes also creates a Backup Keybag for each backup. It consists of class keys that are different from the ones in the System Keybag. The files in the backup are encrypted using AES 256 in CBC mode, with a unique key and a null IV. These file keys are stored wrapped by a class key from the Backup Keybag. Keys in the Backup Keybag facilitate to store the backups in a secure manner. By default, Backup Keybag is encrypted with a key (key 0x835) derived from the iPhone hardware key (UID key). So even if someone gain access to the backup, it is not possible to retrieve all the data from the backup unless they know the hardware key, which can be achieved only through physical access to the device. As the backup files are encrypted with a hardware key, backup taken from a device can only be restored to the original device. With iOS 4, Apple introduced a feature to encrypt the iTunes backups, which provides portability and allows restoring the backup files of one device to another device. Encrypted backups are designed for data migration between different iOS devices. Data migration is achieved by encrypting the backup with a password that a user gives in iTunes instead of the devices hardware key.  With encrypted backups, all the backup data can be migrated except the content which is protected by ThisDeviceOnly class keys.

To create encrypted backups, connect the device to the computer and select ‘Encrypt iPhone Backup’ option in iTunes. During the encrypted backup, iTunes prompt the user to enter a password as shown in the Figure 3. Later the password is used to encrypt all the files in the backup. In encrypted backups, Backup Keybag is encrypted with the backup password. This would allow decrypting the backups without physical access to the device.

iTunes backup makes a copy of everything on the device like contacts, SMS, photos, calendar, music, call logs, configuration files, database files, keychain, network settings, offline web application cache, safari bookmarks, cookies and application data, etc.  It also backups the device details like serial number, UDID, SIM hardware number and the phone number.

Backup folder contains a list of files which are not in a readable format and it consists of uniquely named files with a 40 digit alphanumeric hex value without any file extension. Example file name is: f968421bd39a938ba456ef7aa096f8627662b74a.

iTunes 10.6 backup of an iOS 5 device is shown in the Figure 4.

 

This 40 digit hex file name in the backup folder is the SHA1 hash value of the file path appended to the respective domain name with a ‘-‘ symbol. So the hash of DomainName-filepath will match to the correct file in the backup. In iOS 5, applications and inside data are classified into 12 domains (11 system domains and one application domain). The list of system domains can be viewed from /System/Library/Backup/Domains.plist file on the iPhone. Domains.plist file contents are listed out in Figure 5.

 

The method of managing the backups has changed with every major release of iTunes however the method of converting the path names to the file names still remains the same.

Few examples for path name to backup file name conversions are shown below –

Ex 1: Address book images backup file is – cd6702cea29fe89cf280a76794405adb17f9a0ee and this value is computed from SHA-1(HomeDomain-Library/AddressBook/AddressBookImages.sqlitedb).
*Online hash calculator – http://www.fileformat.info/tool/hash.htm?text=HomeDomain-Library%2FAddressBook%2FAddressBookImages.sqlitedb
Ex 2: AppDomain is used for the applications which are downloaded from AppStore.
Skype property list backup file is – bc0e135b1c68521fa4710e3edadd6e74364fc50a and this value is computed from SHA-1(AppDomain-com.skype.skype-Library/Preferences/com.skype.skype.plist).
*Online Hash calculator – http://www.fileformat.info/tool/hash.htm?text=AppDomain-com.skype.skype-Library%2FPreferences%2Fcom.skype.skype.plist


Ex 3:
Keychain sqlite database backup file is – 51a4616e576dd33cd2abadfea874eb8ff246bf0e and
this value is computed from SHA-1(KeychainDomain-keychain-backup.plist).
*Online Hash calculator – http://www.fileformat.info/tool/hash.htm?text=KeychainDomain-keychain-backup.plist

iTunes stores/reads the domain names and path names from Meta files. Every iOS backup contains four Meta files – Info.plist, Manifest.plist, Status.plist and Manifest.mbdb along with the actual file contents.

Info.plist: The property list file contains the device details like device name, build version, IMEI, phone number, last backup date, product version, product type, serial number, sync settings and a list of application names that were installed on the device, etc.

Manifest.plist: The property list file contains the applications bundle details, Backup Keybag, a flag to identify the passcode protected devices (WasPasscodeSet) and a flag to identify the encrypted backup (IsEncrypted), etc.

Status.plist: The property list file contains the details about the backup. It includes backup state, a flag to identify the full backup (IsFullBackup), date and version, etc.

Manifest.mbdb: The binary file contains information about all other files in the backup along with the file sizes and file system structure data. Backup file structure in older version of iTunes is managed by two files – Manifest.mbdx and Manifest.mbdb. In which, Manifest.mbdx file acts as an index file for the backup and indexes the elements that will be found in Manifest.mbdb. Since the introduction of iTunes 10, index file (mbdx) is eliminated and the backup is managed by a single mbdb file.

A sample Manifest.mbdb file is shown in Figure 6. As Manifest.mbdb is a binary file, a Hex editor is used to view the contents.

Manifest.Mbdb file header and record format is shown in Table 3 & Table 4.

Header:  Mbdb file header is a fixed value of 6 bytes and the value acts as a magic number to identify the mbdb files.

Record:  Mbdb file contain many records and each record is of variable size. Every record contains various details about a file.

In the backup, most of the information is stored as plist files, sqlite database files and images files. Backup files can be viewed directly by adding an appropriate file extension.

Ex: Adding .plist file extension to bc0e135b1c68521fa4710e3edadd6e74364fc50a file allows to view the contents of Skype property list file using a plist editor.

There are many free tools available to read iTunes backups. Some of the famous tools are listed here.

MAC OS X – iPhone Backup Extractor – http://supercrazyawesome.com/
Windows – iPhone Backup Browser – http://code.google.com/p/iphonebackupbrowser/
Mac OS X & Windows – iBackupBot – http://www.icopybot.com/itunes-backup-manager.htm

These tools parse the information stored in the Mbdb file and create the file structure. The tools convert the gibberish backup files into a readable format as shown in Figure 7.

Some of these tools leverage the Apple mobile devices API that comes with iTunes to create and read backups. The amount of information that can be extracted by the backup extractors is limited as the protected files in the backup are encrypted.

Ex:  Keychain-backup.plist file extracted from the backup can be opened using a plist editor. However the contents inside the file are encrypted as shown in Figure 8.

 

Protected files in the backup are encrypted using class keys that are stored in the Backup Keybag. In normal backups Backup Keybag is protected with a key generated from the iPhone hardware (Key 0x835) and in encrypted backups it is protected with iTunes password.

Part 2 of this article will discloses the procedure to extract protection class keys from the Backup Keybag. It is also going to cover the techniques & the tools to decrypt the protected backup files and the iTunes encrypted backups.

I wrote this article for infosec institute. Take a look at the web application security course offered by infosecinstitute.

 

Posted by on May 6, 2012 in iPhone

8 Comments

Tags: , , , , , , , , , , , , , , , , ,

iPhone Forensics – on iOS 5

iPhone Forensics goal is extracting data and artifacts from iPhone without altering the information on the device.
iPhone forensics can be performed on the backups made by iTunes (escrow key attack) or directly on the live device. This article explains the technical procedure and the challenges involved in extracting data from the live iPhone.

The techniques explained in the article only works for iPhone 3gs, iPhone 4 & iPad1. It does not work for iPhone 4s, iPad 2,  iPad 3 and iPad mini.

Techniques explained in the article also works for iOS 6 (Use iOS 5.1.1 ipsw file iOS 6 devices).

Forensics on Live Device:

Jean Sigwald a researcher at Sogeti ESEC Labs has released open source forensic tools (with the support of iOS 5) to recover low level data from the iPhone. Below details outline their research and gives an overview on usage of iPhone forensic tools.

iPhone 4 GSM model, running with iOS 5.1.1 is used for the demos.

Steps involved in iPhone forensics:

  • Creating & Loading forensic toolkit on to the device without damaging the evidence
  • Establishing a communication between the device and the computer
  • Bypassing the iPhone passcode restrictions
  • Reading the encrypted file system
  • Recovering the deleted files

 

1. Creating & Loading forensic toolkit

Imagine a computer which is protected with OS level password –  we can still access the hard disk data by booting a live CD or by removing the hard disk and connecting it to other machine. When we compare computers to the iPhone, it is an embedded device. So it is not easy to take out the chips (hard disk) and dump data in it. iPhone makes chip dumping even more complicated by encrypting the data during storage. In order to perform iPhone forensics, we use Live CD approach. As the iPhone has only one serial port, we are going to load custom OS over USB to access hard disk (NAND chip) of the device. But the problem here is, iPhone only loads the firmware which is signed by Apple.

In order to create and load forensic toolkit, first we need to understand iPhone functions at operating system level.  iOS (previously known as iPhone OS) is the operating system that runs on all Apple devices like iPhone, iPod, Apple TV and iPad.  iOS is a zip file (ships as an .ipsw file) that contains boot loaders, kernel, system software, shared libraries & built in applications.

When an iPhone boots up, it walks through a chain of trust which is a series of RSA signature checks among software components in a specific order as shown in Figure 1.

The BootRom is a Read only memory (ROM) and it is the first stage of booting an iOS device. BootRom contains the Apple root certificates to signature check the next stage.

iPhone operates in 3 modes – Normal Mode, Recovery Mode, DFU mode

In Normal mode, BootRom start off some initialization stuff and loads the low level boot loader (LLB) by verifying its signature. LLB signature checks and loads the stage 2 boot loader (iBoot). iBoot signature checks the kernel & device tree and kernel signature checks all the user applications.

In DFU mode, iPhone follows the boot sequence with a series of signature checks as shown in
Figure 2. BootRom signature checks the second level boot loaders (iBSS, iBEC). Boot loader signature checks the kernel and kernel signature checks the Ramdisk.

During iOS update, Ramdisk gets loaded into RAM and it loads all other OS components. In Forensics, we will create a custom Ramdisk with all our forensic tool kit and load it on iPhone volatile memory. Signature checks implemented at various stages in the boot sequence does not allow loading our custom Ramdisk. To load our custom Ramdisk we have to bypass all these signature checks. In the chain of trust boot sequence, if we compromise one link, we can fully control all the links that follow it. The hacker community have found several vulnerabilities in BootRom using which we can flash our own boot loader and patch all other signature checks in all the subsequent stages. Apart from signature checks, every stage is also encrypted. These encryption keys can be grabbed from JailBreaking tools.

Building custom Ramdisk

First we will build a custom Ramdisk with all our forensic tools and patch the Ramdisk signature checks in kernel. Later, we use jailbreak tools to load our kernel by patching BootRom signature checks.

With the open source forensic toolkit released by Sogeti Labs, we can build Ramdisk only on MAC OS X. During this article, Ramdisk is built on MAC OS X 10.6. The entire forensic toolkit contains python scripts, few binaries and few shell scripts.

In order to run the tools, first we need to install all the dependencies (Use the below listed commands from OS X terminal).

Download and install Xcode 4. It installs the required compilers (ex: gcc).

Download ldid, grant execute permissions and move it to /usr/bin directory. ldid is used for signing the binaries.

curl -O http://networkpx.googlecode.com/files/ldid
chmod +x ldid
sudo mv ldid /usr/bin/

Download and install OSXFuse. OSXFUSE allows to extend Mac OS X’s native file handling capabilities via third-party file system.

curl -O -L https://github.com/downloads/osxfuse/osxfuse/OSXFUSE-2.3.4.dmg
hdiutil mount OSXFUSE-2.3.4.dmg
sudo installer -pkg /Volumes/FUSE for OS X/Install OSXFUSE 2.3.pkg -target /
hdiutil eject /Volumes/FUSE for OS X/

Download & install python modules – pycrypto, M2crypto, construct and progressbar.

sudo ARCHFLAGS='-arch i386 -arch x86_64' easy_install pycrypto
sudo easy_install M2crypto construct progressbar

Download and install Mercurial (http://mercurial.selenic.com/) to check out the source code from the repository.

hg clone https://code.google.com/p/iphone-dataprotection/
cd iphone-dataprotection

Compile img3fs.c which is located in img3fs folder. This script is used to encrypt and decrypt Ramdisk and kernel. If you run into a problem while running this command, edit the makefile in img3fs folder and change the compiler path.

make -C img3fs/

Download redsn0w which is a famous JailBreaking tool. Keys.plist file inside redsn0w contains the encryption keys to decrypt Ramdisk and Kernel.

curl -O -L https://sites.google.com/a/iphone-dev.com/files/home/redsn0w_mac_0.9.14b2.zip
unzip redsn0w_mac_0.9.14b2.zip
cp redsn0w_mac_0.9.14b2/redsn0w.app/Contents/MacOS/Keys.plist .

To patch the signature checks in kernel, supply iOS 5.1.1 ipsw file to kernel_patcher.py. iOS 5.1.1 ipsw file can be downloaded from www.getios.com which maintains all iOS versions for all Apple devices.

python python_scripts/kernel_patcher.py iPhone3,1_5.1.1_9B208_Restore.ipsw

The above python script creates a patched kernel and a shell script to create Ramdisk.

sh ./make_ramdisk_n88ap.sh

Running the shell script downloads the forensic tool kit (ssh.tar.gz) and adds it to the Ramdisk. The Ramdisk image is just a plain HFS+ file system which is native to Mac OS, making it fairly simple to add files to it. All the steps mentioned above create a patched kernel and a custom Ramdisk with forensic tools.

Note: I have created the patched kernel and the custom Ramdisk for iPhone 4. You can directly download these files and skip all the above steps.

Download Link – http://www.4shared.com/folder/dKmG68Im/iPhone_Forensics.html

Loading Forensic Toolkit

In order to load forensic toolkit, supply iOS 5.1.1 ipsw file, patched kernel and custom Ramdisk to redsn0w tool. Connect the device to computer using USB cable and run the below command. Follow the steps displayed by redsn0w to boot the device in DFU mode. In DFU mode, redsn0w exploits the BootRom vulnerability and loads patched kernel & custom Ramdisk on to the device.

./redsn0w_mac_0.9.14b2/redsn0w.app/Contents/MacOS/redsn0w -i iPhone3,1_5.1.1_9B208_Restore.ipsw -r myramdisk.dmg -k kernelcache.release.n88.patched

If the process fails with the No identifying data fetched error, make sure that the host computer is connected to the internet. After redsn0w is done, the Ramdisk boots in verbose mode. Upon successful boot up, iPhone displays ‘OK’ message.

2. Establishing device to computer communication

Once booted with custom Ramdisk, networking capabilities (like WI-FI) are not enabled by default. So a different way is chosen to communicate with the device by following the approach that Apple took with iTunes. USBMUX is a protocol used by iTunes to talk to the booted iPhone and coordinate access to its iPhone services by other applications. USB multiplexing provides TCP like connectivity over a USB port using SSL. Over this channel iTunes uses AFC service to transfer files. But here we use this channel to establish a SSH connection and get shell access to the device.

SSH works on port 22. Tcprelay.py script redirects port 22 traffic to 2222 port.

python usbmuxd-python-client/tcprelay.py -t 22:2222 1999:1999

SSH is now accessible at localhost:2222.

ssh -p 2222 root@localhost
password: alpine

At this point, we get access to the file system. To make things even more complicated, every file is encrypted with its own unique encryption key tied to particular iOS device. Furthermore, data protection mechanism introduced with iOS 4 adds another layer of encryption that does not give access to the protected files & keychain items when the device is locked. Data protection is the combination of using hardware based encryption along with a software key.  Every iPhone (>3gs) contains a special piece of hardware (AES processor) which handles the encryption with a set of hardcoded keys (UID, GID). OS running on the device cannot read the hardcoded keys but it can use the keys generate by UID (0x835 and 0x89B) for encryption and decryption. Software key is protected by a passcode and is also used to unlock the device every time the user wants to make use of the device. So in order to access the protected files, first we have to bypass the passcode.

3. Bypassing the iPhone passcode restrictions

Initially (< iOS 4), passcode is stored in a file which can be removed directly over SSH. Since the introduction of data protection (from iOS 4), passcode is used to encrypt protected files and keychain items on the device. So in order to decrypt the data, we have to supply the valid passcode.

Passcode validation is performed at two levels one at springboard and another one at kernel level. Brute force attack performed at springboard level locks the device, introduces delays and may lead to data wipe-out. However these protection mechanisms are not applicable at kernel level (AppleKeyStore method) and it leads to brute force attacks.  To make brute force attacks less practical, passcode key derived from the user passcode is tied to hardware UID key.  So the brute force can only be performed on the device and it is not possible to prepare pre compute values (like rainbow tables) offline. Demo_bruteforce.py script can be used to brute force the 4 digit passcode.

python python_scripts/demo_bruteforce.py

Port 1999 opened with tcprelay.py is used by the brute force script. It connects to the custom restored_external daemon on the Ramdisk, collects basic device information (serial number, UDID, etc.), unique device keys (keys 0x835 and 0x89B), downloads the system keybag and tries to brute force the passcode (4 digits only).

Table 1 illustrates the time required to brute force different types of passcodes.

4. Reading the encrypted file system

Upon successful passcode brute force, the script automatically downloads the keychain. Keychain is a SQLite database which stores sensitive data on your device.  Keychain is encrypted with hardware key.  Keychain also restrict which applications can access the stored data.  Each application on your device has a unique application-identifier (also called as entitlements).  The keychain service restricts which data an application can access based on this identifier. By default, applications can only access data associated with their own application-identifier.  Later apple introduced keychain groups. Now applications which belong to same group can share the keychain items.  There are two ways to access all the keychain items. One way is, by writing an application and making it as a member of all application groups. The other way is by writing an application and granting com.apple.keystore.access-keychain-keys entitlement.

Keychain database contents can be extracted using keychain_tool.py.

python python_scripts/keychain_tool.py -d [UDID]/keychain-2.db [UDID]/[DATAVOLUMEID].plist

To dump the iPhone file system execute the dump_data_partition shell script.

./dump_data_partition.sh

The script reads the file system from the device and copies it to UDID directory as an image (.dmg) file. The image file can be opened using the modified HFSExplorer that will decrypt the files on the fly. To decrypt it permanently, emf_decrypter.py script can be used.

python python_scripts/emf_decrypter.py [UDID]/[data_DATE].dmg

emf_decrypter.py decrypts all files in the file system image. To view the decrypted files, mount the file system with below command.

Hdituil mount [UDID]/[data_DATE].dmg

As soon as the file system is decrypted, there are various files of interest available such as the mail database, the SMS database and location history, etc…

5. Recovering the deleted files

Deleting a file on iPhone, only deletes the file reference. So it is possible to recover the deleted files. To recover the deleted files run emf_undelete.py script.

python python_scripts/emf_undelete.py [UDID]/[data_DATE].dmg

With this technique it is possible to recover valuable data like call logs, deleted images, deleted SMS, deleted contacts, deleted voicemail and deleted emails.

With the techniques illustrated in the article it is clear that iPhone Forensics is still possible on the latest version of iOS.

Techniques used in the article are explained and demonstrated in the video.

Presentation:

 

Video:

I wrote this article for infosecinstitute.

References

  1.  iPhone data protection in depth by Jean-Baptiste Bédrune, Jean Sigwald
    http://esec-lab.sogeti.com/dotclear/public/publications/11-hitbamsterdam-iphonedataprotection.pdf
  2. iPhone data protection tools
    http://code.google.com/p/iphone-dataprotection/
  3. ‘Handling iOS encryption in forensic investigation’ by Jochem van Kerkwijk
    http://staff.science.uva.nl/~delaat/rp/2010-2011/p26/report.pdf
  4. iPhone Forensics by Jonathan Zdziarski
    http://shop.oreilly.com/product/9780596153595.do
  5. iPhone forensics white paper
    http://viaforensics.com/education/white-papers/iphone-forensics
  6. Keychain dumper
    http://labs.neohapsis.com/2011/02/28/researchers-steal-iphone-passwords-in-6-minutes-true-but-not-the-whole-story/
  7. 25C3: Hacking the iPhone
    http://www.youtube.com/watch?v=1F7fHgj-e_o
  8. iPhone wiki
    http://theiphonewiki.com
 

Posted by on January 10, 2012 in iPhone

45 Comments

Tags: , , , , , , , , , , ,