What is this file called inside an iPhone backup?

A local iPhone backup keeps no folder tree and no file names. Every file is stored under a hexadecimal name, and that name is SHA-1 of the domain, a hyphen, and the path inside that domain. The messages database, Library/SMS/sms.db in HomeDomain, is therefore the digest of the literal string HomeDomain-Library/SMS/sms.db, which is 3d0d7e5fb2ce288813306e4d4636395e047a3d28.

There is no secret in the formula and nothing device-specific about it: the same file has the same name in every backup, on every phone.

Calculate a name

The digest is computed in this browser. Nothing is sent anywhere, and there would be nothing to send: the input is a path, not your data.

Where that name actually sits

Four layouts are in circulation, and a file that is present can be in any of them:

• <backup>/3d/3d0d7e5f…, the normal case since iOS 10: files are spread across 256 subfolders named after the first two characters of the digest.
• <backup>/3d0d7e5f…, flat, in backups older than that.
• <backup>/Snapshot/3d/3d0d7e5f… and the flat version of the same. A backup still being written, or one made by a tool other than Apple's, keeps its live tree in Snapshot. Software that only looks in the first two places reports the file missing from a backup that plainly contains it.

On Windows the backup folders themselves are %USERPROFILE%\Apple\MobileSync\Backup for the Apple Devices app and %APPDATA%\Apple Computer\MobileSync\Backup for classic iTunes, one subfolder per device, named after its UDID.

Two things that silently produce the wrong digest

Attachment paths carry a ~/ prefix that is not part of the hash. The filename column in sms.db holds something like ~/Library/SMS/Attachments/ab/11/…/IMG_0042.HEIC, and the backup name is the digest of that path without the leading ~/. Hash the string as it appears in the column and you get a name that exists nowhere, for a photo that is sitting right there.

A digest that matches nothing on disk usually means the file was never backed up. That is ordinary rather than suspicious: attachments deleted on the phone, and anything the backup was told to exclude, have no entry to find. It is worth knowing which of the two you are looking at before writing it down as a gap.

What is not renamed, and what encryption changes

The files at the root of the backup keep their own names: Info.plist, Manifest.plist, Status.plist and the Manifest.db index that lists the domain and path of everything else. Reading that index is the other way to find a file, and the reliable way to find one whose path you do not already know.

An encrypted backup uses the same names. Encryption is applied to the contents and to the manifest, not to the naming rule, so this calculator answers the same question either way, and the file it points at will need the backup password before it reads as anything.

Related

Timestamps in the database that this file name leads to are counted from 2001 rather than 1970: the converter for those is here. The backup layout, the manifest and what an encrypted backup does and does not give up are documented in our public knowledge repository, github.com/ChatExport/ChatExportKnowledge, under CC BY 4.0.

ChatExport does all of this for you on a Windows PC when what you want is the conversation as a document rather than the file: it finds the backup, reads the database, resolves the attachments, and writes a PDF with a SHA-256 beside it that the recipient can check without installing anything.