iOS Forensics

25/04/2012 - 13:37 by poney

Starting from iPhone 3GS, iDevices contain a cryptographic chip that performs hardware encryption of the filesystem. The NAND chip is a flash memory organized as the following:

Block 0: contains the LLB
Block 1: contains the following encryption keys:
- EMF: used to encrypt the filesystem
- Dkey: used to encrypt the master key of the protection class "NSFileProtectionNone" (the majority of files)
- BAG1: used with the passcode to produce the encryption keys for the other master keys (for files like Mails...).
Block 16 to (END-15) blocks: contains the HFS+ filesystem
Last 15 blocks: reserved for other usage by Apple.

Note: Each file on the filesystem is encrypted with a unique "cprotect" key. Master keys protected with the Dkey and BAG1 permit the decryption of the "cprotect" content.

On public iDevices (do custom iDevices exist ?), as there is no password prompt at boot, EMF and Dkey keys are automatically extracted from Block 1 of the NAND in order to decrypt the the HFS+ filesystem.

Files that belong to NSFileProtectionComplete, NSFileProtectionCompleteUnlessOpen and NSFileProtectionCompleteUntilUserAuthentication protection classes can not be decrypted, unless the passcode is obtained [1].

Partitions are like the following:

On iOS 4 and older
- root device is /dev/disk0s1 mounted on /
- user device is /dev/disk0s2s1 mounted on /private/var
On iOS 5
- root device became /dev/disk0s1s1
- user device became on /dev/disk0s1s2

In order to recover data from an iDevice, all we have to do is booting on a ramdisk, mounting the partitions and copying files, like the following:

1- Booting the iDevice on a ramdisk

With the all-in-one msftguy jar archive [2], it does everything for us (exploiting one of several iOS vulnerabilities, disabling watchdog, loading the ramdisk on memory then launching an ssh daemon on tcp/2222)
With a custom ramdisk that have to be pushed with redsn0w or other tools.

2- Mounting partitions

On iOS 4 and older:

# mkdir /mnt1 /mnt2
# mount -t hfs -r /dev/disk0s1 /mnt1
# mount -t hfs -r /dev/disk0s2s1 /mnt2

On iOS 5:

# mkdir /mnt1 /mnt2
# mount -t hfs -r /dev/disk0s1s1 /mnt1
# mount -t hfs -r /dev/disk0s1s2 /mnt2

Some iDevices refuse to boot if the filesystem get full or corrupt. So if a partition is corrupt (/dev/disk0s2s1 for example), /sbin/hfs_fsck could be used [3]:

# fsck_hfs -d /dev/disk0s2s1
# fsck_hfs -r /dev/disk0s2s1

3- Recovering data

FileZilla, WinSCP or scp could be used to copy files from the iDevice to computer over the usb data cable (through usbmux).

Interesting folders are (root path must be changed according to the mount point):

Photos took by the iDevice: /private/var/mobile/Media/DCIM
Photos synchronized from computer: /private/var/mobile/Media/Photos/Thumbs
Address book: /private/var/mobile/Library/AddressBook/AddressBook.sqlitedb
Calendar: /private/var/mobile/Library/Calendar/Calendar.sqlitedb
Notes: /private/var/mobile/Library/Notes/notes.sqlite
SMS: /private/var/mobile/Library/SMS/sms.db
Safari bookmarks: /private/var/mobile/Library/Safari/Bookmarks.db
Voice records: /private/var/mobile/Media/Recordings

Notes

Tools like "sqlite3 client" or "SQLite Database Browser" could be used to extract data from sqlite databases. The following example is for SMS messages:

$ sqlite3 sms.db
sqlite> .headers on
sqlite> .mode csv
sqlite> .output mySMS.csv
sqlite> select * from messages;
sqlite> .exit
$ ls -l
-rw-------  1 adeleda adeleda  942154 2012-04-22 20:23 sms.csv
-rw-------  1 adeleda adeleda 1630208 2012-02-20 02:38 sms.db

Retrieved data could overwrite iPhone's one, after a fresh restore (do not forget to restore files permissions)
If a /bin/dd is done without mounting the filesystem, data will remain encrypted.

Happy data recovering

Adel

iOS Forensics

1- Booting the iDevice on a ramdisk

2- Mounting partitions

3- Recovering data

Notes

Comments