Deleted Data Recovery on Mobile Devices

Nearly every forensically significant database on a mobile device uses SQLite: SMS and MMS stores, WhatsApp and Signal message databases, call logs, browser history, contact databases, and application preference files. SQLite organises data into fixed-size pages, with the default size being 4 096 bytes and the configurable range 512 bytes to 65 536 bytes. When the application deletes a row, SQLite does not zero the storage. It adds the page to an internal free-page list, which is tracked in the database file header as a linked list of page numbers. The page's previous content remains intact in the file until SQLite decides to reuse that page for new data.

Forensic tools such as Cellebrite UFED, Oxygen Forensic Detective, and AXIOM parse the free-page list from the SQLite header and read the raw bytes of each listed page. Because the SQLite file format is documented and stable, this parsing is reliable. A recovered free page typically contains a complete or near-complete row, including all text fields, integer values, and BLOB references. What is missing is the row ID index entry: deleted rows no longer appear in the B-tree index, so queries against the live database do not find them. The examiner reads the raw page content directly.

The volume of recoverable data depends on how active the application is. A messaging app that sends and receives hundreds of messages per day reuses free pages quickly, and deleted messages may survive for only minutes before their page is overwritten with new content. A call-log database that receives only a few entries per week may retain deleted records in free pages for months. This asymmetry means the examiner should always note the activity level of the relevant application when reporting confidence in deleted-record recovery.

NAND flash memory is organised into pages (the smallest writable unit, typically 4 KB to 16 KB) and erase blocks (the smallest erasable unit, typically 256 KB to 4 MB). A block can only be written from the erased state, meaning all bits set to 1. To overwrite data, the controller must first erase the entire block containing it. This is expensive in time and wear cycles, so controllers defer erasure using wear-levelling and garbage-collection algorithms. When a file is deleted by the file system, the file's pages are marked as invalid in the flash translation layer (FTL), but the block is not erased until the controller decides it is needed for new writes.

Physical acquisition of the raw NAND, either through JTAG, ISP (in-system programming), or chip-off, can read these unallocated but not-yet-erased blocks. The examiner then runs file carving tools such as Foremost, Scalpel, or PhotoRec against the raw image. File carvers identify known file headers and footers (JPEG SOI/EOI markers, MP4 ftyp boxes, PDF %PDF headers) and reconstruct files regardless of whether the file system has an entry for them. This approach recovers media files, documents, and application data containers from deleted files.

Not all data in unallocated blocks is from recently deleted files. Wear levelling may move old data to blocks that are currently marked unallocated from the file system's perspective, creating a situation where content from months or years ago coexists in the same unallocated region as content from last week. Examiners should not assume that all carved content is contemporaneous with the incident under investigation. Timestamps embedded in file metadata (EXIF, MP4 creation boxes) provide the primary basis for dating carved files, but these can be manipulated.

Thumbnail caches are a consistent source of evidence in cases involving images and video. When a user opens the camera roll, a gallery application, or a file browser, the OS or application generates a small preview image for each media file and stores it in a dedicated cache. The cache is maintained separately from the media library and is evicted according to its own schedule, which on most devices is based on age and total cache size rather than on the deletion status of the source file. This means that when a user deletes an image, the original file is removed from the file system and its NAND blocks become candidates for erasure, but the thumbnail typically remains in the cache database for days to weeks.

On Android, the primary thumbnail store moved from a hidden .thumbnails directory in DCIM to a MediaStore database entry from Android 10 onward. The thumbnails themselves are stored as JPEG blobs within the MediaStore SQLite database at /data/data/com.android.providers.media/databases/ or in the external storage equivalent. The MediaStore database is itself a SQLite file, so deleted thumbnail entries follow the free-page recovery path described above. On iOS, the Photos framework maintains thumbnail pyramids in the PhotoData directory within the photo library bundle. These are not individually accessible through a logical acquisition but are retrievable in a file-system or physical acquisition.

Third-party applications maintain their own caches independently of the OS media store. WhatsApp stores received media thumbnails in its private data directory under /sdcard/WhatsApp/Media/.Statuses/ and analogous paths. Telegram caches preview images in its application support directory. Instagram and other social applications similarly maintain internal thumbnail stores. Each of these represents an independent evidence source that may retain image previews after the in-app deletion of the corresponding message or post.

Encryption is the single largest barrier to deleted-data recovery on modern mobile devices. iOS has encrypted all user data with hardware-backed AES keys since iPhone 3GS (2009). Android moved from optional full-disk encryption (FDE) to mandatory file-based encryption (FBE) starting with Android 7.0 and made FBE the default from Android 10 onward. Under both regimes, data written to NAND flash is always ciphertext. A chip-off acquisition of an encrypted device yields a block image that cannot be read without the cryptographic key material.

iOS derives per-class keys from the device's UID (burned into the Secure Enclave at manufacture) and the user's passcode. Data Protection classes (Complete, Complete Unless Open, Protected Until First User Authentication, No Protection) determine when each key is accessible. Content in the Complete class is encrypted with a key that is destroyed when the device locks; a chip-off of a locked iOS device cannot recover any Complete-class data. The SQLite databases containing messages and call logs are typically in the Complete class on iOS 16 and later, which means logical acquisition through an unlocked device or a known passcode is the only viable path.

Android FBE adds a further complication: different directories use different keys. Credential-encrypted (CE) storage, which covers most application data, requires the user's PIN, pattern, or password to decrypt. Device-encrypted (DE) storage covers only the minimal data needed before first unlock (lock screen assets, alarm state). A forensic extraction that bypasses Android authentication but cannot supply the user credential recovers only DE data. The practical result is that on a modern, patched Android device with an unknown PIN, deleted SQLite rows from messaging applications are effectively unrecoverable.

The probability of recovering deleted data from unallocated NAND blocks decreases as a function of time, write activity, and TRIM aggressiveness. Android has issued fstrim commands through the vold daemon since Android 4.3, with the idle maintenance window (typically 2 to 5 hours after the device goes idle) being the primary trigger. From Android 8.0, Inline Encryption and more aggressive FTL garbage collection further reduced the practical window. iOS performs TRIM-equivalent operations through its own storage layer; the exact scheduling is not publicly documented, but empirical testing by forensic researchers has consistently shown that unallocated block content on iOS devices becomes sparse within 24 to 48 hours of deletion under normal usage.

Older OS versions retain deleted content longer. An Android 4.x device without regular fstrim activity may contain recoverable file fragments months after deletion. An iOS 8 or 9 device may yield substantially more from unallocated blocks than an iOS 16 device acquired under the same conditions. This version dependence is important for historical investigations where the device was running an older OS at the time of the events in question, even if it has since been updated. The update itself may have triggered a TRIM pass, but data written before the update on older blocks may still be present.

The most reliable way to preserve the recovery window is to power off the device at seizure or place it in airplane mode and keep it charged, then acquire it as quickly as possible. Powering off stops TRIM from running in the idle window. The trade-off is that powering off also transitions the device to BFU state, which may lock out physical extraction tools that depend on AFU key availability. First-responder guidance therefore varies by case context: for encryption-unlocked devices where NAND recovery is the primary goal, power off and acquire; for locked devices where AFU exploitation is the only path, maintain power and isolate from networks.

The choice of acquisition method determines what recovery is possible. Logical acquisition extracts data through the device's operating system API or backup protocol (iTunes backup on iOS, ADB backup or Android Debug Bridge file pull on Android). It delivers application databases, including free-page content, but cannot access unallocated blocks or files that the OS does not expose. File-system acquisition, available on jailbroken iOS devices and rooted Android devices, delivers a fuller directory tree including application container directories, but still does not provide a raw NAND image. Physical acquisition delivers a bit-for-bit image of the storage device, enabling file carving of unallocated blocks, but requires either chip removal (chip-off), an ISP connection to the eMMC or UFS chip, or JTAG access.

For SQLite free-page recovery, logical or file-system acquisition is usually sufficient: the free pages are inside the database file, and the database file is accessible at those acquisition levels. For unallocated block recovery, physical acquisition is required. For thumbnail cache recovery, the answer depends on the device: on Android, the MediaStore database is accessible at file-system level; on iOS, the PhotoData directory requires file-system or physical acquisition.

The admissibility of evidence recovered from deleted locations has been tested in courts across multiple jurisdictions. In the United Kingdom, courts have accepted SQLite free-page evidence when the examiner demonstrates that the forensic tool did not modify the database and that the recovery methodology is reproducible, following the principles in the ACPO Good Practice Guide for Digital Evidence (now replaced by the Digital Evidence framework under the Forensic Science Regulator). In the United States, Daubert standard challenges to mobile deleted-data recovery have generally succeeded when the tool and method are validated and documented. Indian courts, operating under the Bharatiya Sakshya Adhiniyam 2023, require electronic evidence to be accompanied by a certificate under Section 63 from the examiner attesting to the device state and acquisition method.