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


  • 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


comments powered by Disqus