iOS devices have always been tough to extract data from due to Apple’s hardened encryption methods to keep us out. Receiving an iPhone on your desk with a passcode on it could mean a total halt on your investigation (unless you have access to a GrayKey device).
However, there is an alternative! What if your suspect has backed up their device to their desktop which you have an image of? Then you’re in business, because even on encrypted iOS backups, there’s still a ton of artifacts that we can parse out, and even more on unencrypted backups!
The research I performed here is what I base my iTunes_Backup_Analyzer script off of.
iPhone X – iOS 12.1.2
iPhone 6s – iOS 12.1.2
Windows Host & MacBook Pro for backups
Making the Backup
iTunes backups are created when a user plugs in their iDevice and iTunes is launched, creating the backup automatically. A user can skip this, or engage the backup manually by pressing the “Back Up Now” button. Another important aspect of the iTunes backup is the ability to encrypt the contents. We’ll talk later about the data you can still get from encrypted backups, but for now we’re going to focus on unencrypted backups. Another artifact to note is that we can see the Latest Backup date right in the iTunes menu.
Location of the Backup
We made the backup to This Computer, so where does the backup actually get stored?
Mac OS: /Users/Library/Application Support/MobileSync/Backup
Windows 10: \Users\AppData\Roaming\Apple Computer\MobileSync\Backup
Structure of the Raw Backup
Naming conventions and folder/file layout
The structure of the iTunes backup stays the same between Mac OS and Windows 10 machines, which is good for us. Once inside the backup folder, there’s a single folder per device backed up, named as a SHA-1 hash. Unfortunately, I did not figure out what identifiers are used to make the hash, but it’s persistent, as in the same device, renamed, and backed up to another computer with a different Apple ID will have the same SHA-1 hash folder name as the original backup, this is called its Unique Identifier.
In the root of the per device backup folder, we have a ton of folders all named with two characters, ranging from 00 to ff, each containing files with no extension, named from a fileID which we’ll talk about later. Accompanying these files are the Info.plist, Manifest.plist, Status.plist, and the Manifest.db. If you don’t know what plists are, they’re very similar to XML files, read more about them on Apple’s Official Documentation. The three plist files are not encrypted when encryption is set on a backup, which is great for an examiner because there is a ton of useful data!
The Info.plist houses a lot of artifacts about a backup. Here’s a picture of the overview of the Info.plist:
As you can see, the time of the Last Backup Date matches with the time shown on the iTunes Backup Menu.
There’s many more artifacts to be seen in the Info.plist. Under Applications we can see all of the apps that were installed via the App Store (note that some sideloaded apps may not appear here).
Each application contains three data values: ApplicationSINF, PlaceholderIcon, & iTunesMetadata
Looking at the binary, we can see the full name of the Apple ID associated with the specific app install. The name persists even when the previous Apple ID has been signed out, and a new Apple ID is signed. Whatever Apple ID is used to download an app, the full name associated with the Apple ID will stay in the ApplicationSinf, unless it’s deleted and redownloaded with a different AppleID. This was tested and confirmed by signing out of my own Apple ID and signing in with a new one, installing an app, backing the phone up, and checking the ApplicationSINF:
There’s a bunch of other data present in the ApplicationSINF, however I am unable to make sense out of the rest of it. There’s also no evidence I could find of apps that were deleted off the device in the Info.plist.
Like the name suggests, this holds the application icon for the specific app:
The iTunesMetadata is actually a nested plist inside of the Info.plist:
We can see a variety of interesting artifacts about each specific app such as:
- itemName = App Name
- artistName = Publisher Name
- AppleID = Apple ID of purchaser
- purchaseDate = Date of purchase
- bundleVersion = App Version
- + More
It’s important to note that some sideloaded apps may not have the ApplicationSINF, PlaceholderIcon, & iTunesMetadata keys!
Back in the root of the Info.plist, there’s another array named Installed Applications:
You may ask yourself, “why bother looking at this data when everything we needed and more was in the Applications dictionary?”
To get a complete overview of all apps installed on a device, both the Installed Applications and the Application keys must be examined.
I have yet to be able to parse any of the data inside of the IC-Info.sidv file.
The data residing in the PhotoFolderAlbums is an frpd file which contains folders that are inside of the directory used to sync photos from the computer to the iOS device:
PhotosFolderName & PhotosFolderPrefs
The data seen here is the local path and the absolute path of the directory chosen to sync photos from the computer to the iOS device:
iTunesPrefs & iTunesPrefsPlist
These two keys actually contain much of the same data. In my script to parse this out, I make sure to check the data between these two pieces of data just to ensure that they are really the same (so far they have been in my test cases).
The iTunesPrefs is a binary frpd file that contains the last computers and computer user that the specific iOS device has been backed up to. While the iTunesPrefs.plist is a nested plist that contains (for my testing) empty arrays, and the same copy of the binary frpd iTunesPrefs renamed as iPodPrefs. In my devices, I have noticed that it starts to overwrite after 3 computers, however, I’ve seen another backup where 4 recently used computers have been kept on disk.
The data in iTunes Settings is very interesting and something I have not researched too much into. The RestoreApplications key indicates the application org.coolstar.electra1131. This application was used to jailbreak my device on iOS 11, however, my device has been restored to complete factory settings since using that application, and it no longer resides on my device because of that. WiFiSyncingUserIDs I can only imagine be apart of allowing the iOS device to sync with iTunes over WiFi, but more testing needs to be done to confirm that.
Inside the Manifest.plist there’s some data that we have already seen from Info.plist, as well as some new data such as:
- IsEncrypted = If the iTunes backup is encrypted
- WasPasscodeSet = If the device has a password lock
- Date = The first sync date for the device
- Lockdown/com.apple.mobile.data_sync = Can contain a string that tells the user the syncing source for each item, such as the string “iCloud”
- ManifestKey & BackupKeyBag
- Applications = More evidence of installed applications
The Status.plist contains much less data than the other two plists, but includes:
- IsFullBackup = Flag to represent if the backup is a full backup
- Date = Seemingly always a few seconds behind the last backup date found in the Info.plist
The Manifest.db is the part where things get tricky. When a backup is encrypted, this database is encrypted. However, when it’s not encrypted we can see the full contents of it, so lets do that.
The Manifest.db is a normal SQLite database which can be opened normally in DB Browser for SQLite or whatever viewer you like best. The database contains two tables; Files & Properties. The Filestable is the one we are most interested in, and the Properties table I have yet to find any data residing in on my backups.
The Files table contains every single file that is backed up to the computer, however, they’re stored as fileIDs which correlate to a folder and file in the directory where the iTunes backups are stored.
The domain is the specific app that the file is coming from. The relativePath is the actual file or folder that resided on the device. The flags shows if the item is a file or folder:
1 = File
2 = Folder
4 = Unknown, and not actually present in the backup folders
file is actually a plist inside the database for each file and folder, which has some interesting data:
Here we can see the size of the file, as well as some timestamps correlated to it. The LastModified timestamp is a Unix timestamp that does indeed correlate with the last modified time of the file on the device itself. To confirm this I used Filza on my jailbroken iPhone X to check the last modified timestamp, as well as using PuTTY to ssh in and check:
So now since we have all the information we need, we can start putting the filesystem back together.
- Recursively go through each fileID that has a flag of 2 and make a folder named after the domain and the relativePath. Once this is done, you should have a basic skeleton of the folder structure, just with no files:
- Recursively go through each fileID that has a flag of 1
- Take the first two characters from the fileID, that is the folder in the root of the iTunes backup that that specific file is in
- The file in the folder will have the same name as the full fileID that was found in the Manifest.db
- Change the name of the file from the fileID to the name of the file in the relativePath
- The relativePath, like the name suggests, has the path as well as the filename. Split the string so that you only have the filename, and the excess string of the relativePath should have already been created in the previous step, but always check to make sure
- Congrats, you have now recreated the file structure for the iTunes backup!