Welcome to Farley Forensics

Start exploring

Forensic Analysis of iTunes Backups


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.

Devices Used

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.

iTunes Backup 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.

Per Device Backup Folder

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:

High Level of 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).

Applications in the Info.plist

Each application contains three data values: ApplicationSINF, PlaceholderIcon, & iTunesMetadata

Binary view of the ApplicationSINF for Proton Mail App

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:

Full Name of another Apple ID after new sign in and install

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:

PlaceholderIcon for Proton Mail

The iTunesMetadata is actually a nested plist inside of the Info.plist:

iTunesMetadata nested plist for Proton Mail

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!

Installed Applications

Back in the root of the Info.plist, there’s another array named Installed Applications:

Installed Applications array in the Info.plist

You may ask yourself, “why bother looking at this data when everything we needed and more was in the Applications dictionary?”

This array can actually store apps that were not found in the Applications dictionary! An example would be sideloaded apps through Cydia Impactor, or the popular sideloading site Ignition.

To get a complete overview of all apps installed on a device, both the Installed Applications and the Application keys must be examined.

iTunes Files
iTunes Files and associated fields
IC-Info.sidv inside iTunes Files

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:

Folders inside the directory syncing photos from PhotoFolderAlbums
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:

Local path of the synced photos from PhotosFolderName
Absolute path of the synced photos from PhotosFolderPrefs
iTunes Menu for photo sync
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.

Last computers and computer usernames backed up to from iTunesPrefs iTunesPrefs.plist/iPodPrefs
iTunes Settings
Keys in the iTunes Settings

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.


High level view of Manifest.plist

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


High level view of Status.plist

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
  • Version
  • UUID
  • 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.

Files Table
High level view of Manifest.db

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:

High level view of plist blob inside Manifest.db

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:

Decoded timestamp using DCode.exe
Filza Last Modified Timestamp
SSH Last Modified Timestamp

So now since we have all the information we need, we can start putting the filesystem back together.

  1. 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:
  2. Recursively go through each fileID that has a flag of 1
  3. 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
  4. The file in the folder will have the same name as the full fileID that was found in the Manifest.db
  5. Change the name of the file from the fileID to the name of the file in the relativePath
    1. 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
  6. Congrats, you have now recreated the file structure for the iTunes backup!
Visual process of file recreation

15 thoughts on “Forensic Analysis of iTunes Backups

  1. Great Work! please share the possibility of data recovery (Photos / Videos) for the encrypted backup. I tried to rename the file but it didn’t worked as expected

    1. Yes renaming the file won’t work as expected because everything will be encrypted. I’ve actually been trying to see if I can write a script to decrypt the backup when the user knows the password but I’ve been running into some problems! However, there’s many commercial tools that can decrypt the backup!

      1. Great article. I have another level of encryption trouble. My daughter made a mistake and reset her pw in iTunes which locked out being able to recover an earlier backup. Apple says the previous encrypted files are deleted, but I can see they are still there. There’s no way to open them with existing software, even though I have the old pw. I can use the new ‘reset’ pw, but that only opens new files that were saved at the time of resetting the pw. Any thoughts on this?

        1. Hello! If there’s certain files that still exist I believe it’s possible to decrypt them with a few different software like imazing, imactools, and iphonebackupextractor. I think I tested one of these and it was able to decrypt my backup.

  2. Thanks Jack for your response.

    In my case, Manifest.db file got overwritten, where as I could see all the folders 00-ff still have files with old time stamp (the ones of the encrypted backup). I have been searching for tools, but most of them work if we have a consistent backup with all the required files (*.plist and Manifest files).

    Can you suggest any tool which can just help to decrypt individual media files in the folders 00-ff?

    1. Hello, sorry for the late reply. But if the files are still encrypted there’s commercial tools like Magnet Axiom which can decrypt the backup with a known password. There’s other commercial software that has a free trial like PhoneRescue (that software seems a bit sketchy). If you still have access to the device I recommend just taking another backup unencrypted if you don’t have access to tools that can decrypt the backup.

    2. Hallo Jack,
      how far did you get. I have the same problem and am looking
      for a solution.
      Best regards

  3. Hi Jack,

    Is it possible to decrypt a photo in backup folder(00-ff) in the future? I have a non-encrypted itunes backup that contain encrypted photos, I think itunes created a abnormal backup during encrypt and decrypt process and I have checked the photos with hex viewer, it looks like encrypted.

    Beside the fist situation I recovered a old encrypted backup from a hard drive but the Manifest.plist is broken. Is it possible to a decrypt photo without Manifest.plist?

    1. If the backup itself was not encrypted then the photos should not be encrypted. It’s odd that you’re seeing the photos being encrypted. It should be possible to get the original photo from the backup without the Manifest.plist, but you do need the Manifest.db

  4. Hi There! I am so desperate! I dont know what to do anymore… I´ve spend like 200 Dollar on decrypting my password through the Internet (programms, websites…) with no results! As I read you are creating a code to decrypt the backup from iTunes Version 10 and higher? I try every day every possible combination I can think of for almost two months now and I am not able to remember it :(! I got a looot of photos and videos on my backup and I would looking forward if you could help me!
    Thank you so much in advance!!!

    1. Hi Tom,

      This tool does not decrypt iTunes backups as there has not been any open source development into decrypting iTunes backups, even with the password. Besides brute forcing the backup like you have been doing I do not know of a better way. Try checking all your passwords saved in your browser (Chrome/FireFox/Safari) and see if any of them will decrypt your backup. If you do find the key you can try using Magnet Axiom’s free trial to enter your key and get your data .

      I’m sorry about your situation, definitely sucks!

  5. Hi

    Do you know if there is any way to decrypt an incomplete backup? My backup was interrupted and could not complete and my phone is now in recovery mode. I don’t want to lose everything but my phone memory is full so I can’t update it (via iTunes recover steps) Please help!

    1. Hello! As long as you have a manifest.db file in your backup folder you should be able to put it back together. If it’s an encrypted backup there’s some third party tools like iPhonebackupextractor and iMobie, but they seem a bit sketchy.

Leave a Reply