iOS Backups

iOS has a backup feature that copies the data on the device to either the host computer or iCloud. The backup functionality is initiated from iTunes (up to macOS Catalina) or from the Finder (from macOS Catalina and newer). The backup may include sensitive data that is on the device, and this should be checked at various stages of your testing.

For user installed iOS applications, everything in the Documents/ directory and the Library/Application Support/ directory are automatically backed up by default. These directories are in the application Data directory. While these are included by default, the developer may exclude specific files from the backup using the NSURLIsExcludedFromBackupKey: method. Additionally, the use of the Data Protection APIs could be implemented to further restrict a file from being included in a backup. (See the Data Protection procedures for more information).

Creating A Backup

We need to create a backup of the device before we can test for sensitive data exposure. At this point, I assume everyone has upgrade to macOS Catalina or newer. So, I will show the Finder method of taking a backup!

Connect your device to the macOS system
Open Finder
The device will show up under the ‘Locations’ section
- If this is the first time connecting, you will have to enable the trust to create the pairing record
Select the device in Finder
The device screen will appear. Select the General tab if not already selected
In the middle, there is a Backups section
- Select “Back up all of the data on your iPhone to this Mac
- For now, ensure that the “Encrypt local backup” option is not selected
- Click the “Back Up Now” button

The backup will be stored at the following location in your $HOME directory:

~/Library/Application Support/MobileSync/${UDID}

To get the ${UDID} of the device, run the command: idevice_id -l

Backup Directory Access

If you attempt to change into that directory from the Terminal app, you may encounter the following issue:

This is not a permission issue, as the MobileSync directory will be owned by you:

drwxr-xr-x   3  steve  staff    96 Jan  5  2022 MobileSync

The issue is that the Terminal application does not have access to these directories. To get around this, you will need to apply some additional Privacy settings. Open the System Preferences on the Mac:

Go to Security & Privacy
Select the Privacy tab
Click the pad lock in the lower left (and enter your password) to unlock the preferences
In the left pane, select “Full Disk Access”
In the right pane, select the Terminal application that you are using
- You may need to click the “+” button and add the application if it does not already exist
You will be required to quit and re-launch the Terminal app

You will be able to go into the Backup directory:

Review Backup Files

In true Apple fashion, they store the backup files in an odd, esoteric format. However, for our purposes, there are a few ways we can see which files from the app are included in the backup. In the backup directory you will find many sub-directories consisting of two (2) characters. Additionally, there are some PLIST files and a Database.

First, we will check to ensure that backup is not encrypted:

% /usr/libexec/PlistBuddy -c 'Print :IsEncrypted' Manifest.plist
false

Next, check that your application was included in the backup:

% /usr/libexec/PlistBuddy -c 'Print :Installed\ Applications' Info.plist
Array {
    io.stinger.dvia2
    com.example.appname
    io.stinger.uncover
}

If the app is included in the backup, get a listing of the files that are included in the backup:

% sqlite3 Manifest.db "SELECT relativePath FROM Files WHERE domain LIKE '%com.example.app%'" | sort -u

We need to understand how the Manifest.db database is storing this information first. We can get this from the database schema.

% sqlite3 Manifest.db ".schema"
CREATE TABLE Files (fileID TEXT PRIMARY KEY, domain TEXT, relativePath TEXT, flags INTEGER, file BLOB);
…

Column	Description
`fileID`	the primary key which appears to be a hash of something…
`domain`	the backup domain such as AppDomain
`relativePath`	the file path and name
`flags`	the flags used to store the file
`file`	A PLIST of the filename’s metadata

Viewing the files that are stored in the backup is not a straight-forward process. But for our purposes we can get a good idea of the data in the files.

For instance, let’s say that the Cookies file is present in the backup at Library/Cookies/Cookies.binarycookies. We can get the fileID of that file from the Manifest.db database and then run strings against it.

% sqlite3 Manifest.db "SELECT fileID FROM Files WHERE domain LIKE '%com.example.app%' AND relativePath LIKE '%Cookies%'"
b686664633b48b87039bb4844031cbf92b8722d4
46ad03aaf24c35e671d1ba6a12453be616935408

This returns two (2) locations where the Cookies.binarycookies file for our app could be stored. To view these files, use the following directory structure:

The returned location looks like this: 46ad03aaf24c35e671d1ba6a12453be616935408

Use the first two (2) characters as the directory, then the full string as the filename.

% strings 46/46ad03aaf24c35e671d1ba6a12453be616935408 
cook
Asso.godaddy.com
akm_lmprb-ssn
0aPNHuBZshuZMDqcGTizyWISgppRWS4UQjditgKKDFBrIkDntcSlIxlKgll2YIinSIRbBL7JK7x0hhvO87sSFQChQUzQ7QOhXhRmb7GO4ruycRYoOuFFlnsjw9i5XEA0tzno
Asso.godaddy.com
akm_lmprb
0aPNHuBZshuZMDqcGTizyWISgpplIxlKgll2YIinSIRbBL7JK7x0hhvO87sSFQChQUzQ7QOhXhRuKTdcKh2puMgmb7GO4ruycRYpOxppDvRoOuFFln5XEA0tzno

Depending on the data, you may need to use other ways to see the data.

% xxd 46/46ad03aaf24c35e671d1ba6a12453be616935408 
00000000: 636f 6f6b 0000 0003 0000 01f2 0000 0085  cook............
00000010: 0000 0389 0000 0100 0200 0000 1400 0000  ................
00000020: 0501 0000 0000 0000 f100 0000 0000 0000  ................
00000030: 2500 0000 0000 0000 3800 0000 4800 0000  %.......8...H...
00000040: 5600 0000 5800 0000 0000 0000 0000 0000  V...X...........
00000050: 0000 80c8 f13e c441 0000 8008 493e c441  .....>.A....I>.A
00000060: 7373 6f2e 676f 6461 6464 792e 636f 6d00  sso.godaddy.com.
00000070: 616b 6d5f 6c6d 7072 622d 7373 6e00 2f00  akm_lmprb-ssn./.
00000080: 3061 504e 4875 425a 7368 755a 4d44 7163  0aPNHuBZshuZMDqc
00000090: 4754 697a 7957 4953 6770 7052 5753 3455  GTizyWISgppRWS4U
000000a0: 0000 0389 0000 0100 0200 0000 1400 0000  ................
000000b0: 7463 536c 4978 6c4b 676c 6c32 5949 696e  tcSlIxlKgll2YIin
000000c0: 5349 5262 424c 374a 4b37 7830 6868 764f  SIRbBL7JK7x0hhvO
000000d0: 3837 7353 4651 4368 5155 7a51 3751 4f68  87sSFQChQUzQ7QOh
000000e0: 5868 5275 4b54 6463 4b68 3270 754d 676d  XhRuKTdcKh2puMgm
000000f0: 6237 474f 3472 7579 6352 5970 4f78 7070  b7GO4ruycRYpOxpp
00000100: 4476 526f 4f75 4646 6c6e 736a 7739 6935  DvRoOuFFlnsjw9i5
00000110: 5845 4130 747a 6e6f 00ed 0000 0000 0000  XEA0tzno........

If you want to view the file metadata that is stored in the Manifest.db, you can look at it this way:

% sqlite3 Manifest.db "SELECT writefile('cookie.plist', file) FROM Files WHERE fileID='46ad03aaf24c35e671d1ba6a12453be616935408'"

This will produce a file called cookie.plist in the current directory. To view it:

% plutil -p cookie.plist
{
  "$archiver" => "NSKeyedArchiver"
  "$objects" => [
    0 => "$null"
    1 => {
      "$class" => <CFKeyedArchiverUID 0x600001408180 [0x7ff85c3b2d80]>{value = 3}
      "Birth" => 1657559697
      "Flags" => 0
      "GroupID" => 501
      "InodeNumber" => 1430558
      "LastModified" => 1657559697
      "LastStatusChange" => 1657559697
      "Mode" => 33188
      "ProtectionClass" => 3
      "RelativePath" => <CFKeyedArchiverUID 0x6000014081a0 [0x7ff85c3b2d80]>{value = 2}
      "Size" => 1643
      "UserID" => 501
    }
    2 => "Library/Cookies/Cookies.binarycookies"
    3 => {
      "$classes" => [
        0 => "MBFile"
        1 => "NSObject"
      ]
      "$classname" => "MBFile"
    }
  ]
  "$top" => {
    "root" => <CFKeyedArchiverUID 0x6000014080a0 [0x7ff85c3b2d80]>{value = 1}
  }
  "$version" => 100000
}

Remove Backups

Since the backups that we created were not encrypted, they should be removed – especially if sensitive data was found. Make sure to keep any artifacts that you need for reporting, and if desired zip the backup into an encrypted archive.

Encrypted zip file (with device attached to Mac):

% zip -er backup.zip ~/Library/Application\ Support/MobileSync/Backup/${idevice_id -l}
Enter password: 
Verify password: 
  adding: 61/ (stored 0%)

Remove backup:

Open Finder and select the device
On the General tab, select “Manage Backups…”
Select the Device backup, and click on the “Delete Backup” button

Creating A Backup​

Backup Directory Access​

Review Backup Files​

Remove Backups

Creating A Backup

Backup Directory Access

Review Backup Files