Data Persistence and Evidence Locations on Mobile Devices

iOS organizes user data under /var/mobile/. The most forensically productive subtrees are the Containers directory, which holds all app sandboxes, and the Library directory, which holds system-level databases for phone calls, SMS, voicemail, and Safari. A logical extraction exposes the file system as seen by the OS and reaches most of these paths. A full file system extraction, obtained via a jailbreak or a bootrom exploit such as checkra1n, exposes additional paths including the keychain database and some system directories that logical extraction omits.

Within an app's sandbox container, the standard subdirectory layout is: Documents/ for user-generated files the app intends to be visible or exportable; Library/ for persistent app data the user does not typically access directly (which includes Library/Application Support/ for databases and Library/Caches/ for temporary data); and tmp/ for files the app intends to discard after the current session. Forensically, Library/Application Support/ is the most valuable: it commonly holds the app's SQLite database with all structured records.

The mapping between a UUID-named container directory and a specific app requires the BundleMetadata.plist file inside the container or the iTunesMetadata.plist in the app bundle. Forensic suites such as Cellebrite UFED Physical Analyzer and Magnet AXIOM perform this mapping automatically during parsing, but an examiner working with a raw extraction must perform it manually or with a scripted lookup. Without the mapping, artifacts extracted from /var/mobile/Containers/Data/Application/3F2A1B09-.../Library/Application Support/database.sqlite cannot be attributed to a specific app.

Android stores app data under /data/data/<package.name>/ on older versions and /data/user/0/<package.name>/ on Android 9 and later with multi-user support. Each package directory contains databases/, shared_prefs/, files/, and cache/ subdirectories. The databases/ directory holds SQLite databases; shared_prefs/ holds XML-format key-value preference files analogous to iOS plists. Because /data/ is protected storage, accessing it directly requires root access or an Android Debug Bridge (ADB) backup on older Android versions.

The system telephony provider stores SMS and MMS in a database accessible at /data/data/com.android.providers.telephony/databases/mmssms.db. Call logs reside in /data/data/com.android.providers.contacts/databases/calllog.db or contacts2.db depending on the Android version. Third-party messaging apps such as WhatsApp maintain their own message databases: WhatsApp stores chat history in /data/data/com.whatsapp/databases/msgstore.db, which uses SQLite with AES encryption on more recent versions. Signal stores encrypted message databases in /data/data/org.thoughtcrime.securesms/databases/. Decrypting these requires the app's encryption key, which is itself stored in protected storage on the device.

External storage (/sdcard/ or /storage/emulated/0/) is not app-sandboxed on Android and holds photos, downloaded files, and media. It is accessible without root on most devices. Many apps write backup or cache files to external storage as well, so it is forensically valuable even when internal app databases are inaccessible.

SQLite is the dominant database format on mobile devices. Its file format is fully documented and stable: a 100-byte header identifies it as SQLite version 3, followed by fixed-size pages that hold the B-tree index and table data. Because SQLite writes in pages, partial updates leave residual data in pages that are allocated to the free list but not yet reused. This free-list data, sometimes called SQLite slack or unallocated SQLite space, is a primary target for deleted record recovery.

Common forensic artifacts within SQLite databases include: message content with timestamps and sender/recipient identifiers (SMS, iMessage, WhatsApp, Signal, Telegram databases); call records with duration, direction, and contact linkage; browser history and bookmarks with visit timestamps; location check-ins and route history from navigation apps; purchase and transaction history from e-commerce apps; and social media posts, likes, and connection records from their respective app databases. The schema for each app's database is not standardized: forensic tools rely on vendor-supplied schema maps or community-maintained parsers.

When a row is deleted from an SQLite table, the database marks the page containing it as free but does not immediately zero the data. The row's content remains readable in the free page until a new write operation reclaims that page. Tools such as Epilog, SQLite Forensic Explorer, and the open-source Undark utility parse the free-list pages directly to recover deleted rows. The effectiveness of this technique depends on whether the app has called VACUUM on the database (which compacts and zeroes free pages) and on how much subsequent write activity has occurred.

Plist files appear throughout the iOS file system. System preference plists record network connections (com.apple.wifi.known-networks.plist stores SSIDs and last connection timestamps), application usage patterns, and notification history. App-level plists in Library/Preferences/<bundle.id>.plist store settings, last-sync timestamps, account identifiers, and feature flags. For an examiner, plists are fast reads: convert binary format to XML with plutil -convert xml1 or with a forensic suite's built-in parser, then search for timestamps, email addresses, phone numbers, and account tokens.

The iOS keychain stores items in four classes based on when they are accessible: Always (accessible even when locked), AfterFirstUnlock (accessible after first post-boot authentication), WhenUnlocked (accessible only when unlocked), and WhenPasscodeSetThisDeviceOnly (accessible only on the specific device with a passcode set, and never backed up). Forensically relevant entries include Wi-Fi passwords, VPN credentials, email account passwords, and OAuth tokens that authenticate to cloud services. Extracting keychain data requires a full file system extraction and the correct decryption keys; the GrayKey device and Cellebrite Premium service claim to extract keychain items from supported iOS versions, subject to legal authorization.

Cached media is stored in Library/Caches/ within app containers. Photo apps cache thumbnails; messaging apps cache received images, audio, and video before the user saves them; browsers cache page content. Cache directories are intended to be expendable: iOS may purge them under storage pressure, and apps may clear them on launch. However, in many investigations the cache contains the only copy of received media that the user never explicitly saved to the photo library, making it forensically significant. Timestamps on cache files can also help reconstruct a timeline even if the content has been partially cleared.

NAND flash stores data in pages (typically 4 KB to 16 KB) grouped into blocks (typically 256 to 512 pages). Writing new data to a page requires that the page be blank; erasing operates only at the block level. The flash controller therefore cannot overwrite a single page in place. Instead, it writes the new version of the data to a different blank page, marks the old page as invalid, and eventually erases the entire block when all pages in it are invalid. This block-level erasure model is fundamental to why deleted data persists longer on flash than on magnetic media.

Wear-leveling is the process by which the controller selects which physical block to write to next, aiming to distribute writes evenly. When a file is deleted, the file system marks its pages as free and the controller notes them as invalid, but the physical data in those pages is not erased until the controller's garbage collection process decides to reclaim the block. Garbage collection runs in the background, typically during idle periods. The time between deletion and physical erasure varies from minutes to weeks depending on device load, available free space, and controller firmware behavior.

The practical implication for examiners is that isolation of a device at seizure is essential. A device left powered on and connected to a network will continue generating writes (push notifications, background app refreshes, iCloud sync) that accelerate garbage collection and reduce the recovery window. Airplane mode and a Faraday bag should be applied at seizure, before transport. For devices where the screen is already off, the question of whether to power off at seizure requires a judgment call: powering off stops writes but also locks the keychain, potentially preventing a logical extraction without the passcode.

Mobile devices routinely back up to cloud services, and those backups may hold data that has been deleted from the device, data from a device that is no longer available, or data from an older version of the app before a schema migration cleared records. iCloud backups include the contents of most app sandboxes (apps can opt out), SMS and iMessage databases, photos, call history, and keychain items (with a separate, weaker encryption key). Google One backups for Android include SMS, call history, app data for participating apps, and photos.

Obtaining cloud backup data requires a legal process targeting the cloud provider. In the United States, the Stored Communications Act (18 U.S.C. Chapter 121) governs access to stored electronic communications; law enforcement must obtain either a warrant or a court order depending on the age and type of the content. In the European Union, the EU e-Evidence Regulation (Regulation 2023/1543), which entered force progressively from 2026, allows cross-border production orders to cloud providers. In India, Section 94 of the Bharatiya Nagarik Suraksha Sanhita 2023 authorizes production orders for documents and records held by persons or entities, which courts have applied to cloud providers, but the framework for cross-border requests remains less codified than the EU mechanism. The UK uses the Investigatory Powers Act 2016 and, post-Brexit, bilateral Mutual Legal Assistance Treaties for US data.

iTunes and local backups created by the device owner are also forensically important. An unencrypted iTunes backup exposes almost all of the same file system locations that a logical extraction reaches, without requiring a specialized tool or a jailbreak. An encrypted iTunes backup requires the backup password to decrypt, but if the password is known or recoverable, it also includes keychain items that unencrypted backups omit. Forensic tools including Oxygen Forensic Detective and Elcomsoft Phone Breaker can parse both encrypted and unencrypted iTunes backups and extract the same artifact categories available from a direct device extraction.