Inside an iPhone backup: the folders, the hashed names, Manifest.db

An iPhone backup on a PC looks like nothing at all: a folder named after the phone’s identifier, holding folders with two character names, holding files with forty character names and no extensions. It is one naming rule applied to every file, and once you know the rule the folder becomes readable.

The identifier itself comes in two shapes. Older iPhones use forty hexadecimal characters. From the iPhone XS, XS Max and XR onward it is twenty-five characters including a hyphen, and a folder named that way is just as much a backup as one with forty characters.

Where does Windows keep iPhone backups?

In one of two folders, depending on which Apple program made the backup:

Path	Written by
%USERPROFILE%\Apple\MobileSync\Backup	Apple Devices, or iTunes installed from the Microsoft Store
%APPDATA%\Apple Computer\MobileSync\Backup	The traditional iTunes for Windows, not the Store version

Both can exist at once. Because the backup folder is named after the phone, the same phone can appear in both roots under the same folder name. To choose between two copies, compare the Last Backup Date in each copy’s Info.plist, then run the finished check further down on the newer one.

What are the files with no names?

They are the phone’s own files, each renamed to a hash of where it lived on the phone and, on iOS 10 and later, filed in a subfolder named after the first two characters of that hash. Beside them, four files keep their real names and describe the backup itself:

File	Contents
Manifest.db	A SQLite database whose Files table has one row per file, with the columns fileID (the hashed name), domain, relativePath (the original path), flags and file (a block of file metadata)
Manifest.plist	Properties of the backup as a whole, including whether it is encrypted
Info.plist	The device: its name, iOS version, phone number and the date of the last backup
Status.plist	The state of the latest backup run, including whether it finished

Why is the messages database called 3d0d7e5f and not sms.db?

Because every file apart from those four is renamed to the SHA-1 hash of its domain and its path joined by a hyphen. The messages database lives at Library/SMS/sms.db in HomeDomain, so its name is the hash of the string HomeDomain-Library/SMS/sms.db, which is:

3d0d7e5fb2ce288813306e4d4636395e047a3d28

Neither the domain nor the path changes from one iPhone to the next, so neither does the name. The file can then sit in one of two places:

<backup>/<first two characters of the hash>/<hash>     iOS 10 and later
<backup>/<hash>                                        before iOS 10

A lookup that checks only one of them misses every backup made in the other layout. If you want the hashed name for some other file, this site has a browser tool that computes an iOS backup file id from a domain and a path, without uploading anything.

Why do the attachments seem to be missing?

Because attachment paths need two corrections before hashing, not one, and getting either wrong fails without an error. The paths stored in the messages database start with ~/, the on-device shorthand for the home folder, and the hash is computed over the path without it. And attachments are filed under MediaDomain, not under HomeDomain where sms.db sits. Hash with the database’s domain, or with the ~/ left on, and you get well-formed names that match nothing.

What does Manifest.db actually do?

It maps every hashed name back to its domain and its original path: query its Files table for a relativePath and the fileID column gives you the name on disk, without applying the hashing rule file by file. One caveat matters: on an encrypted backup made by iOS 10.2 or later, Manifest.db is itself encrypted, with its key kept in Manifest.plist behind the backup password. Until the password is supplied you cannot list the contents of the backup at all.

How do you tell a finished backup from an abandoned one?

Check that Status.plist says finished in its SnapshotState value and that the messages database is actually in the folder, under its hashed name. For a run you have just made, also check that Manifest.db is newer than the moment the run started.

The flag on its own does not prove that any files arrived: pymobiledevice3, an open-source backup tool, writes finished into Status.plist when it sets up a full backup, or any backup that has no Status.plist yet, before a single file has been copied. The messages database is the second half of the test because it is the file you came for. And a Manifest.db whose modification time is older than the start of your run means that run never completed.

ChatExport opens a backup only when the first two checks pass, and after a backup it made itself it also tells you whether the phone sent everything or only the changes. After the first full backup the phone sends the files that changed or were added and tells the computer which ones to remove, so a second run that copies far less than the first is the expected result.

The notes this page started from are our own and public: ChatExportKnowledge, this project’s own notes repository on Apple’s formats. For what to do with the backup once you have found it, the full guide to backing up iPhone text messages to a PC without iCloud covers making one and reading it, and where Windows stores iPhone backups is the shorter answer to the folder question alone.