tl;dr iOS backups in macOS Catalina appear to be exactly the same as iTunes backups in macOS Mojave, all the way down to the backup version number (3.3)

macOS Catalina iOS Backups

When I first heard that Apple was eliminating iTunes, I was quite worried that local iOS backups were a thing of the past (which could still happen). But macOS Catalina came out, I learned that various iTunes features were replaced with separate programs: iTunes Movies -> Apple TV, iTunes Music -> Apple Music, etc. The backup functionality in iTunes for iOS devices was simply integrated into the ubiquitous Finder:

If you familiar with the normal iTunes backup flow, it's pretty much the same. You have to:

1. Trust the iOS device from iTunes and then reciprocate on the device
2. Choose Backup Now
3. If you want encrypted backups, configure as needed
4. Perform the backup

Files are still stored in the normal places (and since I always forget I'm added here for my own reference):

• macOS: /Users/username/Library/Application Support/MobileSync/Backup/
• Windows 10, 8, 7 or Vista: \Users\username\AppData\Roaming\Apple Computer\MobileSync\Backup
• Windows XP: \Documents and Settings\username\Application Data\Apple Computer\MobileSync\Backup
• Microsoft Store version of iTunes: \Users\username\Apple\MobileSync\Backup

Device and content management

Just like iTunes previously, you can also perform device and content management from the Finder iOS device interface:

Encrypted backups

As mentioned, you can also configure encrypted backups. If encrypted backups were previously setup, those settings travel with the device and will be the default. Here's the option you receive if the setting has not been configured:

If you have the passcode to the device (which you will need to unlock and to enable the encrypted backups), it's a good idea to enable this feature from a forensics standpoint as you will acquire more data. Of course, your forensic software has to be able to decrypt the backup and I've written a blog series that demonstrates how to accomplish this with various open source tool (see HOWTO decrypt iOS 10 backups with open source tools

Differences in macOS Catalina iOS backups

In order to determine if there were obvious differences between an iOS backup on iTunes vs. macOS Catalina Finder, I performed a backup of the same device on each platform. Specifically, the platforms were:

• macOS Catalina 12.15.2
• macOS Mojave 10.14.6, iTunes v12.9.5.5

iOS backup analysis with ftree

For file analysis, I released a free forensic tool called ftree and I ran it against each backup so I would have a full set of forensic file metadata and structure perform a quick verification. Here's the output from ftree for both backups:

macOS Catalina backup

$ ftree generate -f sqlite -o catalina.sqlite 0cf0077a56aed9c119835a50e027dc79b9e1de040
✔ Crawled 8179 files/dirs (0 inaccessible)
✔ No errors accessing files
✔ No files >1GB found
Saved sqlite file to catalina.sqlite

iTunes 12.9.5.5 on macOS Mojave

$ ftree generate -f sqlite -o mojave.sqlite ~/Library/Application\ Support/MobileSync/Backup/0cf0077a56aed9c11983a50e027dc79b9e1de040
✔ Crawled 8277 files/dirs (0 inaccessible)
✔ No errors accessing files
✔ No files >1GB found
Saved sqlite file to mojave.sqlite

The ftree analysis took about 30 seconds for each backup and the resulting sqlite files were around 95MB. The first thing I noticed was iTunes backup (which I performed 2nd) had 98 more files and directories (8277 in total) than the Catalina backup.

ftree diff analysis

To determine the difference between the two backups would normally be a daunting and tedious task but one of the key features of ftree is the ability to diff two directories. Since I already had the sqlite out (you can also output to json or csv), I went ahead and ran a quick diff with ftree:

$ ftree -o ~/Downloads/itunes-v-catalina/diff.sqlite -f sqlite diff mojave.sqlite catalina.sqlite
Saved sqlite file to ~/Downloads/itunes-v-catalina/diff.sqlite

which took less than 2 seconds. I then ran a few quick sql queries and figured out what was going on and determined:

• 8,115 files or directories were identical
• 167 files were not identical
  • 103 files were not present in the Catalina backup (deleted)
  • 59 files were in both but changed (modified)
  • 5 files were new in the Catalina backup (new)

Of course, I couldn't leave it at that and wanted to understand what changed and why. So I spot checked a few files.

plist analysis

First up was to check out the backup metadata which Apple stores in a series of plist files in the backup directory, specifically:

• Info.plist
• Manifest.plist
• Status.plist

In the Manifest.plist, Apple stores details about the backup, including the backup version. To examine plist, binary plist or xml files, I released a free forensic tool called fplist. Here's what the two Manifest.plist files showed:

macOS Catalina backup

$ fplist -f dot 0cf0077a56aed9c11775a50e027dc79b9e1de040/Status.plist
IsFullBackup = false
Version = "3.3"
UUID = "D5BFE992-D878-4F4E-A898-14C653AECCAC"
Date = "2020-01-05T22:37:25.676Z"
BackupState = "new"
SnapshotState = "finished"

iTunes 12.9.5.5 on macOS Mojave

$ fplist -f dot ~/Library/Application\ Support/MobileSync/Backup/0cf0077a56aed9c11983a50e027dc79b9e1de040/Status.plist
IsFullBackup = false
Version = "3.3"
UUID = "59BD9C8E-9767-496D-892C-4D0313B37FC2"
Date = "2020-01-05T22:15:08.400Z"
BackupState = "new"
SnapshotState = "finished"

So one key finding is that both backups share the same Version (3.3).

new files created

Since there were only 5 new files created, I wanted to see what they why and why, after less than 20 minutes, new files were created. Instead of hopping back into sqlite, I used the default output format in ftree which is json lines so I could do everything on the command line:

$ ftree diff mojave.sqlite catalina.sqlite | jq '. | select(.diff_status=="new")'
{
  "id": 439,
  "key": "./05/05d615c2b07dc4566a0d5025dd46f37eaf1cd35a-shm",
  "diff_status": "new",
  "file_name": "05d615c2b07dc4566a0d5025dd46f37eaf1cd35a-shm",
  "original_type": null,
  "original_magic_base": null,
  "original_path": null,
  "original_file_hash": null,
  "new_type": "file",
  "new_magic_base": "data",
  "new_path": "/Users/hiro/Downloads/itunes-v-catalina/0cf0077a56aed9c11983a50e027dc79b9e1de040/05/05d615c2b07dc4566a0d5025dd46f37eaf1cd35a-shm",
  "new_file_hash": "fd4c9fda9cd3f9ae7c962b0ddf37232294d55580e1aa165aa06129b8549389eb"
}
<truncated for brevity>

Side-note: if you're comfortable using the command line (or want to be), check out the awesome jq tool which is indispensable when working with json data. In the above command, I streamed the json results from ftree, piped through jq and filtered for entries that had a diff_state of new.

From the example entry (and if you've been working in development for forensics for a while), you'll immediately recognize the -shm file extension as a temporary file left when accessing a .sqlite file. Since I'm analyzing the direct iOS backup, I have to lookup what the file key 05d615c2b07dc4566a0d5025dd46f37eaf1cd35a references. [Note: I have a yet unreleased tool to decode iOS backups so check the (free tools)[/tools/free] section in case I've released it by the time you read this article]. To perform the lookup, you simple open the Manifest.db sqlite file and search/filter on the filename which is in the CameraRollDomain domain and is a file named Media/PhotoData/momentanalysis.

At this point, I realized that I had actually taken a quick screen capture of the Trust screen on the iOS device to potentially include in this blog. That's a nice little reminder that everything you do on a target phone is likely to have some impact on the device!

So, with that info in hand, the 5 new files now made a lot of sense. Armed with the file metadata from ftree, I could now easily determine the type and reason for each newly created file:

other file difference

At this point, I was getting pretty comfortable that the two backups were basically being performed in an identical manner. I decided to make a cursory check of the deleted and modified files.

deleted files

There were 103 deleted file that were very easy to sort out. Using the json output along with grep and wc (word count), it took less than a minute to determine:

1. One file was .DS_Store and was created when I browsed the directory on my macOS computer
2. The remaining 102 files were evenly split between:
   1. an empty -wal file
   2. a -shm file with data in it

So, there were temporary sqlite files around when I did the first backup that were not in the 2nd backup. This does not seem unusual and with a little additional time, it would be simple to review 1-2 files to confirm. In case you were curious about the commands I used, here there are:

count number of deleted files

jq '. | select(.diff_status=="deleted")' diff.json | grep id | wc -l
     103

examine all file type and the next line with location

$ jq '. | select(.diff_status=="deleted")' diff.json  | grep original_magic_base -A1 | less
  "original_magic_base": "Apple Desktop Services Store",
  "original_path": "/Users/hiro/Library/Application Support/MobileSync/Backup/0cf0077a56aed9c11775a50e027dc79b9e1de040/.DS_Store",
--
  "original_magic_base": "empty",
  "original_path": "/Users/hiro/Library/Application Support/MobileSync/Backup/0cf0077a56aed9c11775a50e027dc79b9e1de040/12/12b144c0bd44f2b3dffd9186d3f9c05b917cee25-wal",
--
  "original_magic_base": "data",
  "original_path": "/Users/hiro/Library/Application Support/MobileSync/Backup/0cf0077a56aed9c11775a50e027dc79b9e1de040/12/12b144c0bd44f2b3dffd9186d3f9c05b917cee25-shm",
<truncated>

modified files

To get a quick count of the modified files, I again leveraged jq, grep and wc:

jq '. | select(.diff_status=="modified")' diff.json | grep id | wc -l
     59

and then took a quick look at the files and their types:

$ jq '. | select(.diff_status=="modified")' /tmp/diff.json  | grep original_magic_base -A1 | less
  "original_magic_base": "Apple binary property list",
  "original_path": "/Users/hiro/Library/Application Support/MobileSync/Backup/0cf0077a56aed9c11775a50e027dc79b9e1de040/Status.plist",
--
  "original_magic_base": "Apple binary property list",
  "original_path": "/Users/hiro/Library/Application Support/MobileSync/Backup/0cf0077a56aed9c11775a50e027dc79b9e1de040/Manifest.plist",
--
  "original_magic_base": "SQLite 3.x database",
  "original_path": "/Users/hiro/Library/Application Support/MobileSync/Backup/0cf0077a56aed9c11775a50e027dc79b9e1de040/Manifest.db",
<truncated>

where I began to see some expected file changes such as the backup metadata written by iTunes/Finder in the backup process. So I skipped further down and randomly pick a sqlite file (c2/c2a024f688265147c389cb15ddac132a1e335fb7).

I then looked that file hash up in the Manifest.db file and learned it was on the HomeDomain and specifically mapped to Library/VoiceShortcuts/VoiceShortcuts.sqlite. I wasn't immediately sure why that file would change so I used sqlite3 to examine the files. Indeed, they were Voice Shortcuts that an iPhone user can setup on their device. But why would it change? The answer: teenagers.

The test phone I grabbed was an iPhone 6 one of my teenagers was no longer using as they got a slightly newer phone recently. I had not yet wiped out the device and while the SIM card had been removed, it was still connected to WiFi. So, in between the two backups, my teenager had used a Voice Shortcut on their active phone and the in world of connected devices, Apple/iOS dutifully updated the older iPhone 6 with the still logged in iCloud account.

At that point, I felt quite comfortable that the iOS backup feature in macOS Catalina's Finder was essentially identical to the iTunes iOS backup feature on Mojave and earlier. Apple will almost certainly change the backup over time so the key is likely to focus in on the Backup Version that Apple tracks in the Manifest.plist file.

Pitch for DART

If you've made it this far, I would be remiss in mentioning that finding the VoiceShortcuts.sqlite file and understanding it's metadata is a key example of why I developed the Discovery, Analysis & Research Tool (DART) for forensic analysts. In a nutshell, the amount of data a forensic analyst (and forensic tool) has to take into account is both staggering and ever growing. By leveraging crowdsourced data and analysis, we can build a tool that plays a critical role in the future of forensic analysis. Please check it out and drop us a line if you have any questions or feedback.