Device Backup Forensics

When a user backs up an iPhone or iPad to a Mac or Windows computer via iTunes (or Finder on macOS Catalina and later), the backup lands in a fixed directory: on macOS at ~/Library/Application Support/MobileSync/Backup/, and on Windows at %APPDATA%\Apple Computer\MobileSync\Backup\. Each device gets a subfolder named after its UDID (Unique Device Identifier), a 40-character hex string. Inside that folder the structure is always the same.

Every backed-up file is stored with a filename that is the SHA-1 hash of its domain and relative path concatenated, for example the hash of HomeDomain-Library/SMS/sms.db. The file is placed in a two-level directory: the first two characters of the hash name the subdirectory, and the full 40-character hash is the filename. So the SMS database might live at bd/bd192c...40chars. This flat layout means the backup folder contains no human-readable filenames. Without Manifest.db, the data is present but uninterpretable.

Manifest.db contains two main tables. The Files table maps each file's fileID (the SHA-1 hash), domain, relativePath, flags, and file metadata stored as a binary plist in the file column. The Properties table holds device metadata. From Files, a forensic tool can reconstruct the full path for every backed-up file and extract it to a logical directory tree. The root folder also contains Info.plist (device identifiers, last backup date, iOS version), Status.plist (backup state and date), and Manifest.plist (backup settings and device encryption flag).

Apple's backup encryption is optional for local iTunes backups and is always enabled for iCloud backups. When local encryption is enabled, each file is encrypted with a unique 256-bit AES key. Those per-file keys are wrapped by class keys, which are in turn protected by the backup keybag. The keybag is encrypted using a key derived from the user-chosen backup password via PBKDF2-SHA256. In iOS 10.2 Apple increased the iteration count to around 10 million, making brute-force attacks on modern backups very slow even on GPU hardware.

The backup password is completely separate from the device passcode. A six-digit passcode does not help recover a long backup password, and vice versa. This is a common source of confusion in investigations where the device has been unlocked using a court order or a biometric but the backup remains encrypted under an unknown password. Commercial tools such as Elcomsoft Phone Breaker, Passware Kit Mobile, and open-source options such as iphone-backup-decrypt target the PBKDF2 derivation step. Against short or common passwords, recovery is feasible. Against a random twelve-character password on a post-iOS-10.2 device, GPU brute force is not practical.

iCloud Backup is enabled by default on iOS devices and backs up automatically over Wi-Fi when the device is plugged in and locked. The backup covers SMS and iMessage databases, call history, app data (for apps that opt in), device settings, Health data, and voicemail. It excludes data already stored in iCloud: photos if iCloud Photos is enabled, files if iCloud Drive is enabled, and third-party app data if the app's iCloud sync is active. This exclusion logic means that examining only the iCloud backup can miss large volumes of content that requires separate iCloud Drive or iCloud Photos requests.

Apple retains up to three backup snapshots per device. When a new backup completes, the oldest is deleted. For an active device that backs up daily, investigators may have access to content from three days ago, three days before that, and three days before that, each snapshot potentially containing data deleted in the intervening periods. The retention window is device-specific and depends on backup frequency.

Investigative access to iCloud backups follows two paths. The first is legal process: a preservation request to Apple (using Apple's law enforcement portal) followed by a content request under the applicable legal authority. Apple's Legal Process Guidelines state that iCloud backup content is provided to law enforcement with a valid search warrant. The second path is direct acquisition using credentials: if the Apple ID username and password (or a valid authentication token) are known, tools such as Elcomsoft Phone Breaker can download the backup directly, bypassing legal process but raising admissibility questions if the credentials were not lawfully obtained.

Apple introduced end-to-end encryption for iCloud backups as an opt-in feature called Advanced Data Protection, released in December 2022. When this is enabled, Apple cannot decrypt the backup even in response to a legal order. Only the account holder, using a device enrolled in the account, holds the decryption keys. As of 2024 this option is available in most markets, and its uptake among privacy-conscious users means investigators must determine whether Advanced Data Protection is enabled before assuming a legal request to Apple will yield plaintext content.

Android does not have a single backup format equivalent to iTunes. The platform provides two main mechanisms: ADB backup for local extraction over USB, and Google One Backup (formerly Android Backup Service) for cloud storage. Manufacturers including Samsung and Huawei also implement proprietary backup solutions that have their own formats and forensic tools.

An ADB backup is produced by issuing adb backup -apk -shared -all -f backup.ab from a computer connected to the device. The device must have USB debugging enabled, and the user must confirm the backup on the device screen. The output file begins with a plaintext header: the string ANDROID BACKUP, a version number (typically 5), a flag for whether the data is compressed (1 or 0), and a flag for encryption type (none, AES-256). The remainder is a deflate-compressed TAR archive. Each TAR entry corresponds to a file in an app's sandbox or on external storage, with the path structured as apps/[package name]/[subdir]/[filename]. The archive can be extracted with standard tools after decompression.

Forensic yield from ADB backups varies significantly by app. Applications that set android:allowBackup="false" in their AndroidManifest.xml are excluded entirely. Historically, high-value targets including WhatsApp, Signal, and many banking apps have used this flag. Signal's exclusion is intentional privacy design. WhatsApp uses its own proprietary backup mechanism (to Google Drive or local storage) rather than ADB. Investigators must therefore combine ADB backup analysis with direct acquisition of the Google Drive backup and manual extraction from the device's external storage directory.

The forensic value of a backup extends well beyond a simple copy of the live device state. Backups often contain deleted records that survive in SQLite databases as rows where the deletion flag is set but the data has not yet been overwritten, app caches that may not exist in the same form on the current live device, and snapshots of settings at an earlier point in the investigation timeline. The deleted data recovery on mobile devices topic covers SQLite WAL recovery in detail; the same techniques apply directly to the database files extracted from a backup.

Key artefact categories in iOS backups include: the SMS database (HomeDomain-Library/SMS/sms.db), which holds SMS, MMS, and iMessage threads with sender, receiver, timestamps, read status, and attachment references; the call history database (HomeDomain-Library/CallHistoryDB/CallHistory.storedata); Safari browsing history and bookmarks; Photos metadata in the PhotoData domain; Health data in the AppDomain-com.apple.Health domain (encrypted backups only); and third-party app databases in their respective AppDomain directories. The voicemail database and audio files are also included in local backups, which is often overlooked.

In Android ADB backups, the equivalent artefacts are the telephony provider database (com.android.providers.telephony), contacts provider database (com.android.providers.contacts), call log provider (com.android.providers.contacts for call history), and app-specific databases for installed applications that permit backup. WhatsApp stores its message database in a proprietary format at /sdcard/WhatsApp/Databases/; that directory is captured in the -shared flag of adb backup and in Google Drive backup separately. Telegram similarly stores a local database that can be extracted from the app's data directory if the device is not encrypted or if a physical acquisition is combined with the backup.

Backups also preserve app installation records, which is relevant when an app has been uninstalled before the device was seized. An old backup may show the app was installed, when it was installed, and what data it contained at the time. This is one reason investigators routinely request all available backup history rather than only the most recent snapshot.

Commercial forensic platforms handle iTunes and iCloud backup parsing as a built-in workflow. Cellebrite UFED Physical Analyzer imports an iTunes backup folder and produces a parsed report of messages, calls, contacts, and app data. Oxygen Forensic Detective and MSAB XRY have equivalent capabilities. These tools automate manifest parsing, file extraction, and SQLite analysis, but examiners should understand the underlying structure so they can verify tool output and recover data the tools miss.

For manual examination of iTunes backups, the open-source iphone-backup-decrypt library (Python) decrypts encrypted backups using the known password and produces a plaintext copy with the original directory structure restored. The iBackupBot (macOS/Windows) and BackupTrans tools provide graphical interfaces for browsing unencrypted backups. For deeper SQLite work, the DB Browser for SQLite or the command-line sqlite3 tool can query the manifest and artefact databases directly. Autopsy has an iTunes Backup module that integrates backup parsing into a wider case file.

For Android ADB backups, the ab-to-tar.py script or the Android Backup Extractor (Java, open source) converts the .ab file to a standard TAR, which can then be extracted with any archive tool. Autopsy's Android Analyzer module ingests the extracted file system. The Android backup files for individual apps are SQLite databases, SharedPreference XML files, and binary files, all of which can be examined with standard forensic and database tools after extraction. See also the call logs, SMS and messaging app artefacts topic for guidance on parsing specific app databases once they are extracted.