Why Deleted Messages Are Never Really Deleted

You open WhatsApp, long-press a message, tap "Delete for Everyone", and watch it vanish. A satisfying animation. A reassuring notification: "This message was deleted." On the other end, your contact sees a grey bubble that says the same. Both of you believe the message is gone.

It is not. The bytes that made up that message are still present on your phone's NAND flash chip, probably in multiple locations: the SQLite database file, the Write-Ahead Log, the filesystem's unallocated space, and quite possibly an iCloud or Google Drive backup that was triggered minutes before you pressed delete. If your contact took a screenshot, the message survives in their photo library. If either of you uses a keyboard with prediction enabled, fragments of the message may be embedded in the prediction dictionary. If the message was an SMS rather than an internet message, your carrier almost certainly has a copy in a lawful intercept archive, and depending on which European country you are in, they may be required by law to keep it for months or years.

This article explains why. Not with hand-waving about "data persistence" but by walking through the actual storage stack from NAND flash cells to SQLite page structures to cloud replication protocols, showing at each layer exactly where deleted messages survive and why they are recoverable. The goal is to give you a model precise enough that you can predict, for any given messaging app on any given device, what a forensic examiner would find after you press delete.

What "Delete" Means at the Storage Level

When a messaging app deletes a message, it issues a DELETE FROM messages WHERE id = ? statement against its local SQLite database. SQLite does not zero out the row's bytes on disk. It marks the space occupied by that row as available for reuse by updating the database's internal freelist. The page that contained the row is now a "free page" from SQLite's perspective, but the bytes are unchanged. If no new data is written to that page before someone examines the database file, the deleted row is sitting there, fully intact, readable with a hex editor.

Even if SQLite does reuse the page, the story is not over. SQLite in WAL (Write-Ahead Log) mode, which is the default on both iOS and Android, writes new data to a separate WAL file before checkpointing it back to the main database. The WAL file may contain the original row, the deletion record, or both. WAL files are not always truncated promptly. On iOS, SQLite WAL files for iMessage can grow to tens of megabytes before a checkpoint flushes them, and during that window, every intermediate state of the database is preserved in the WAL.

Below SQLite, the filesystem adds another layer. On Android, the dominant filesystem is f2fs (Flash-Friendly File System) or ext4. On iOS, it is APFS. All three are copy-on-write or journal-based, meaning they do not overwrite data in place. When SQLite modifies a database page, the filesystem writes the new version to a fresh location on the flash chip and updates a pointer. The old version remains in the previous physical location until the garbage collector reclaims it. On f2fs, which is explicitly designed around the constraints of NAND flash, this is not a bug; it is the core design principle.

Below the filesystem, the Flash Translation Layer (FTL) on the storage controller adds yet another layer of indirection. The FTL maintains a mapping from logical block addresses to physical NAND pages. When the filesystem overwrites a logical block, the FTL writes the new data to a fresh physical page and marks the old page as invalid. The old page's data persists on the NAND die until the FTL's garbage collector erases the containing block, which may not happen for hours, days, or ever, depending on the drive's workload and free space.

So when you "delete" a message, you are removing an entry from a B-tree in a SQLite database. The bytes survive in the SQLite freelist, the WAL file, the filesystem's previously allocated blocks, and the NAND flash's invalid pages. That is four independent copies of the "deleted" data, at four different layers of the stack, each with its own retention timeline.

NAND Flash and Why Deleted Data Lives Longer Than You Think

To understand why deletion is so unreliable on phones, you need to understand the physical constraints of NAND flash. A phone's storage chip (eMMC or UFS) contains NAND flash dies organised into pages (typically 16 KiB) and blocks (typically 256 to 1024 pages, so 4 to 16 MiB). You can read a page, you can program (write) a page, but you can only erase an entire block. You cannot overwrite a single page in place.

This asymmetry is the root cause of data persistence after deletion. When the filesystem or the FTL needs to "overwrite" data, it writes the new version to a different physical page and invalidates the old one. The old page sits in its block, still containing the original data, until the garbage collector decides to erase that block. The garbage collector only runs when the drive needs free space, and it preferentially erases blocks that have the most invalid pages. A block that contains a mix of valid and invalid pages will be left alone until the pressure is high enough to justify copying the valid pages elsewhere and erasing the entire block.

On a phone with 128 GB of storage and 60 GB free, there may never be enough pressure to trigger aggressive garbage collection. Invalid pages containing deleted messages can persist for weeks. Forensic examiners know this and routinely recover data from NAND dumps that is months old.

Wear levelling makes things worse from a deletion standpoint. The FTL rotates writes across all available blocks to distribute wear evenly. This means data does not stay in one predictable location; it gets copied around the die as part of normal wear-levelling operations. Each copy creates a new physical instance of the data. Old copies are marked invalid but not erased. A single message might exist in three or four physical locations on the NAND die at any given time, each one a potential recovery target.

TRIM (or its UFS equivalent, UNMAP) is the mechanism by which the filesystem tells the storage controller that certain logical blocks are no longer in use. A well-behaved controller will mark the corresponding physical pages as invalid and may zero them out on read. But TRIM is not an erase command. It is a hint. The controller is free to defer the actual erasure indefinitely. Some controllers zero out trimmed pages immediately (making forensic recovery harder), but many, especially older eMMC controllers common in budget Android phones, treat TRIM as a low-priority background task. On such devices, trimmed data can survive for a long time.

The cryptographic erase approach used by modern iOS and Android devices is the only reliable countermeasure at this layer. Both platforms use file-based encryption (FBE), where each file is encrypted with a unique per-file key derived from the user's credential. When you delete a file, the OS destroys the key. The ciphertext remains on the NAND, but without the key it is computationally worthless. This is elegant, but it has a critical dependency: the key must actually be destroyed. If the key is recoverable (from a backup, from a key escrow service, from a Secure Enclave vulnerability), the ciphertext becomes plaintext again.

SQLite Forensics: Where Messaging Apps Actually Store Data

Almost every messaging app on both iOS and Android uses SQLite as its local database engine. iMessage uses a database at ~/Library/SMS/sms.db on macOS and a similar path in the app container on iOS. WhatsApp uses msgstore.db on Android and a Core Data SQLite store on iOS. Signal uses an encrypted SQLite database (SQLCipher). Telegram uses a combination of SQLite and custom binary formats. Understanding SQLite's internal structure is the key to understanding what survives deletion.

A SQLite database file is divided into fixed-size pages (typically 4096 bytes). The first page contains the database header. Subsequent pages are organised into B-tree structures: one B-tree for each table and each index. Each B-tree page contains cell pointers and cell content. A cell in a table B-tree holds a single row: the rowid, followed by the column values in SQLite's record format.

When a row is deleted, SQLite does not zero the cell. It adds the cell's space to the page's free block list (a linked list of unused regions within the page) and decrements the cell count. The bytes that made up the row are still on the page. They are just not referenced by any cell pointer. A forensic tool that reads the raw page can scan for cell headers in the free space and reconstruct deleted rows.

If the deletion causes a page to become completely empty, SQLite adds it to the database's freelist (a linked list of unused pages stored in "trunk" pages starting from the freelist pointer in the database header). Freelist pages retain their previous content until they are reallocated and overwritten by new data. A forensic examiner can iterate the freelist and recover entire pages of deleted records.

The WAL File

SQLite's WAL mode is the default on mobile platforms because it allows concurrent readers and a single writer without locking the entire database. When a transaction commits in WAL mode, the modified pages are appended to the WAL file rather than written directly to the main database. A checkpoint operation later copies the WAL pages back to the main database.

The WAL file is forensically significant for two reasons. First, it contains a sequential log of every database modification since the last checkpoint. If a message was written and then deleted between two checkpoints, both the insertion and the deletion are recorded in the WAL, and the original message content can be recovered from the WAL's copy of the page before the deletion. Second, WAL files on mobile devices are not always checkpointed promptly. iOS, in particular, defers checkpointing when the device is under memory pressure or when the app is backgrounded. A WAL file for iMessage can contain thousands of transactions spanning hours or days of message history.

The WAL file has a well-defined binary format. It begins with a 32-byte header containing the page size, checkpoint sequence number, and salt values. Each frame in the WAL contains a 24-byte frame header followed by a full database page. The frame header includes the page number and a cumulative checksum. Forensic tools parse the WAL by walking frame by frame from the beginning, extracting each page image, and reconstructing the database state at any point in the WAL's history. This is time-travel for databases.

Rollback Journal

Some apps and some SQLite configurations use the older rollback journal mode instead of WAL. In rollback mode, before modifying a page, SQLite copies the original page to a journal file. If the transaction needs to roll back, the journal pages are copied back. If the transaction commits, the journal is invalidated (either deleted, truncated, or its header is zeroed). But "invalidated" does not mean "erased." The journal file may remain on disk with its original content, especially if the app crashes or if the OS does not immediately reclaim the space. Forensic examiners routinely find rollback journal files containing pre-modification database pages.

Unallocated Space Within the Database

SQLite databases often have significant amounts of unallocated space, both within individual pages (free blocks) and as whole unused pages (the freelist). On a long-lived messaging database that has seen many insertions and deletions, the freelist can be substantial. Dimitris, a forensic analyst in Athens, once described finding over 2,000 freelist pages in a WhatsApp msgstore.db on an Android device, each containing intact message records that had been "deleted" by the user months earlier.

The ratio of recoverable deleted records to live records depends on the app's behaviour. Apps that use VACUUM periodically (which rebuilds the entire database, eliminating freelist pages and compacting data) leave less recoverable material. Apps that never vacuum accumulate forensic evidence over time. WhatsApp on Android does not vacuum by default. iMessage on iOS vacuums infrequently. Signal vacuums more aggressively as part of its privacy design, but even Signal cannot prevent the WAL from containing intermediate states.

App by App: What Survives Deletion

Each messaging app has its own storage architecture, its own deletion semantics, and its own set of forensic artefacts. Here is what a forensic examiner finds on a typical device after a user has "deleted" messages.

iMessage

iMessage stores messages in a SQLite database (sms.db) within the app's protected data container. The database schema includes tables for message, handle (contacts), chat (conversations), and attachment. When you delete a message in the Messages app, iOS executes a DELETE against the message table. The row enters the freelist. The WAL may contain the pre-deletion page. The attachment file (if any) is unlinked from the filesystem, but its NAND pages persist until overwritten.

iMessage also maintains a Spotlight index. Spotlight indexes message content for search, and the index database (com.apple.MobileSMS) contains fragments of message text even after the original message is deleted from sms.db. The Spotlight index is a separate SQLite database with its own freelist and WAL.

On macOS, Time Machine backups compound the problem. Every hourly snapshot may contain a copy of sms.db from before the deletion. Even if you empty the Trash and delete the Time Machine backup, the bytes persist on the backup drive's filesystem until overwritten.

WhatsApp

WhatsApp on Android stores messages in msgstore.db, an unencrypted SQLite database in the app's private directory (/data/data/com.whatsapp/databases/). Media files are stored in /sdcard/WhatsApp/Media/. When you delete a message, WhatsApp removes the row from the messages table. The freelist grows. The WAL retains the pre-deletion state.

WhatsApp also creates automatic local backups. Every day at 02:00 (by default), WhatsApp creates an encrypted backup of msgstore.db and stores it in /sdcard/WhatsApp/Databases/. These backups are named msgstore-YYYY-MM-DD.1.db.crypt15 (the number at the end indicates the encryption version). WhatsApp keeps seven days of local backups by default. Deleting a message from the live database does not delete it from the backups. A forensic examiner who can decrypt the backups (using the key stored in the device's Keystore or extracted via Cellebrite) has access to seven days of message history regardless of what the user deleted.

WhatsApp on iOS uses Core Data with a SQLite backend. The database is in the app's container, and iCloud backups include the entire container. The encryption key for iCloud WhatsApp backups (if the user has enabled end-to-end encrypted backups) is stored in Apple's HSMs or in the user's own key, depending on the configuration. If end-to-end backup encryption is not enabled, Apple holds the decryption key and can provide the backup contents to law enforcement under a valid legal order.

Signal

Signal is the most privacy-conscious of the major messaging apps, and its storage architecture reflects that. The local database is encrypted with SQLCipher, using a key derived from the user's device credentials. Messages are stored in an encrypted SQLite database that cannot be read without the decryption key, even with filesystem access.

Signal's "disappearing messages" feature sets a timer on each message. After the timer expires, Signal deletes the message from its local database on both the sender's and recipient's devices. The deletion is a standard SQLite DELETE, so the same freelist and WAL artefacts exist, but they are encrypted. Without the SQLCipher key, the freelist pages are unreadable ciphertext.

However, Signal's privacy model has known leakage channels. The most significant ones are:

Notification logs. On Android, when a Signal message triggers a notification, the notification content (including message text) is written to the system notification log (/data/system/notification_history/). This log is not encrypted by Signal and persists independently of Signal's database. A forensic tool with filesystem access can read notification history even if Signal's database is inaccessible.

Input prediction dictionaries. If the user types messages using a keyboard with prediction enabled (Gboard, SwiftKey, Samsung Keyboard), the keyboard learns from the user's typing patterns and stores word frequencies and n-grams in its own database. Fragments of message content end up in the keyboard's dictionary, which is outside Signal's control. Elena, a security researcher in Helsinki, demonstrated in 2024 that Gboard's user_history.db contained recoverable fragments of Signal messages that had been "disappeared" weeks earlier.

Screenshots and screen recordings. Signal blocks screenshots in its own UI on Android (using FLAG_SECURE), but it cannot prevent screen recordings by the OS itself, by accessibility services, or by a connected ADB session. On iOS, Signal cannot prevent screenshots at all; it can only detect them and notify the sender (a feature it does not currently implement for all message types).

Link previews in other apps. If a Signal message contains a URL and the user copies it to a browser, the URL appears in browser history, which is stored in yet another SQLite database.

Telegram

Telegram's architecture is split between "Cloud Chats" (stored on Telegram's servers, not end-to-end encrypted) and "Secret Chats" (end-to-end encrypted, stored only on the two devices). Deleting a Cloud Chat message removes it from Telegram's servers (Telegram claims), but the local SQLite database on the device retains the deletion artefact in the freelist. Deleting a Secret Chat message removes it from the local database with the same SQLite freelist behaviour as any other app.

Telegram's local database structure is more complex than WhatsApp's or iMessage's. It uses a combination of SQLite databases and custom binary cache files. Media files are cached in the app's data directory, and Telegram is aggressive about caching: photos, videos, and documents are downloaded and cached locally even if the user never explicitly saves them. Deleting a message does not delete the cached media file. A forensic examiner often finds the full media content of "deleted" messages in Telegram's cache directory.

Cloud Backups: The Copy You Forgot About

The most reliable source of "deleted" messages for forensic examiners is often not the device itself but the cloud backup. Most users enable automatic backups without fully understanding what they contain.

iCloud Backups

An iCloud backup of an iPhone includes the complete contents of every app's data container, including message databases. When backup is enabled, iOS backs up to iCloud daily (when the device is locked, connected to Wi-Fi, and charging). The backup includes sms.db, WhatsApp's database, Signal's encrypted database (though Signal discourages iCloud backup and excludes its database from iCloud backup by default on newer versions), Telegram's cache, and everything else in every app container.

Apple encrypts iCloud backups, but Apple holds the encryption key. Under a valid court order or warrant in any EU member state (and in many other jurisdictions), Apple can and does provide decrypted iCloud backup contents to law enforcement. This is well-documented: Apple's own transparency reports show thousands of account data requests fulfilled annually across European countries.

Apple introduced Advanced Data Protection in late 2022, which enables end-to-end encryption for iCloud backups. When ADP is enabled, Apple no longer holds the decryption key, and cannot provide backup contents to law enforcement. However, ADP is opt-in, and as of 2026, adoption rates remain relatively low. Most users' iCloud backups are still decryptable by Apple.

Google Drive Backups

Android devices back up to Google Drive via Google One Backup (or the older Android Backup Service). The backup includes app data for apps that opt in, device settings, SMS/MMS messages, call history, and (for Pixel devices and some others) photos. WhatsApp specifically uses Google Drive for its backup, storing encrypted msgstore.db backups in the user's Drive storage.

Google's encryption model for Android backups has evolved. Since Android 9, backups are encrypted with the user's lock screen credential and a server-side key stored in Google's Titan security chips. Google states that it cannot decrypt these backups. However, the WhatsApp backup stored on Google Drive uses WhatsApp's own encryption, and the key management is separate. If end-to-end encrypted backup is not enabled in WhatsApp, the backup key is accessible to WhatsApp (Meta), and potentially to law enforcement via legal process directed at Meta.

Carrier Cloud Services

Some European carriers offer their own cloud backup services (Vodafone Cloud, Deutsche Telekom MagentaCLOUD, Orange Cloud). These services often back up photos, contacts, and sometimes messages. Users who enable these services may have copies of their messages in a carrier-controlled cloud that is subject to the carrier's data retention policies and the jurisdiction's legal framework. These backups are frequently overlooked in both privacy planning and forensic investigation.

Carrier-Side Retention: What Your Network Keeps

When you send an SMS or MMS, the message transits your carrier's Short Message Service Centre (SMSC). The SMSC stores the message until delivery is confirmed (or until the validity period expires, typically 24 to 72 hours). After delivery, the message is removed from the active queue, but that does not mean it disappears entirely.

European carriers are subject to varying data retention requirements. The EU Data Retention Directive (2006/24/EC) originally mandated that carriers retain communications metadata (who contacted whom, when, for how long, from where) for between six months and two years. The Court of Justice of the European Union (CJEU) invalidated this directive in 2014 (Digital Rights Ireland, C-293/12), ruling it an unjustified interference with the right to privacy under Articles 7 and 8 of the EU Charter of Fundamental Rights.

However, the invalidation of the directive did not eliminate national retention laws. Many EU member states maintained or enacted their own retention legislation:

• Germany: The Telecommunications Act (TKG) requires carriers to retain connection metadata for ten weeks and location data for four weeks. Content retention of SMS/MMS is not mandated, but carriers may retain it for billing and fraud purposes.
• France: Carriers must retain connection metadata for one year under the Code des postes et des communications electroniques.
• Italy: Metadata retention of up to six years was permitted under Law 167/2017, though the CJEU has pushed back on such long periods.
• Sweden: Metadata retention of six months, recently upheld by the Supreme Administrative Court with limitations.
• Greece: A retention period of twelve months for telephony metadata was established, though enforcement has been uneven.

The distinction between metadata and content is critical. Metadata includes the sender's number, the recipient's number, the timestamp, and the cell tower used. Content is the actual text of the message. Most European retention laws apply to metadata only. However, carriers' internal systems often retain message content for short periods (hours to days) for delivery retry, billing verification, and lawful intercept compliance. Some carriers retain SMS content for up to 90 days for fraud detection.

For internet-based messaging (WhatsApp, Signal, Telegram, iMessage), carriers cannot read message content (it is encrypted in transit), but they can see metadata: IP addresses, connection timestamps, data volumes, and the server endpoints contacted. A carrier can tell that your phone connected to WhatsApp's servers at 14:32 on a Tuesday and transferred 4.7 KiB of data, but cannot see what the message said. This metadata is subject to the same retention requirements as telephony metadata.

Law enforcement access to retained data in Europe requires a court order in most jurisdictions. The specific requirements vary: in Germany, a judge must approve the request; in France, it depends on the type of investigation; in the Netherlands, a public prosecutor can authorise access for serious crimes. The European Court of Human Rights has repeatedly held that bulk retention of communications data is permissible only for the purpose of combating serious crime and subject to strict procedural safeguards.

Forensic Extraction: How Examiners Get the Data

Forensic extraction of mobile devices is a mature industry with a well-defined hierarchy of techniques, ranging from non-invasive logical extraction to destructive chip-off methods. The three major commercial tool vendors are Cellebrite (Israeli), MSAB (Swedish), and Grayshift (American, makers of GrayKey). Each offers tools at multiple price points, from law enforcement agencies in Stockholm to forensic labs in Barcelona.

Logical Extraction

Logical extraction is the least invasive method. The examiner connects the device to a forensic workstation via USB and uses the device's own backup mechanism (iTunes backup for iOS, ADB backup for Android) to create a copy of the user-accessible data. This captures what the operating system exposes through its backup API: app data, photos, contacts, messages, call logs, and settings.

Logical extraction does not require bypassing the device's lock screen (though it does require the device to be unlocked or the backup password to be known). It does not access deleted data, filesystem metadata, or areas outside the backup scope. It is the fastest and most legally defensible extraction method, but it captures the least data.

On iOS, a logical extraction via iTunes backup captures sms.db, WhatsApp's database, and most other app data. Signal explicitly excludes its database from iTunes backups, so a logical extraction will not capture Signal messages.

Filesystem Extraction

Filesystem extraction gives the examiner access to the full filesystem, including files not included in backups, system databases, caches, logs, and (critically) SQLite WAL and journal files. On Android, this typically requires root access, obtained either through a known exploit or through the device's own developer options. On iOS, this requires a jailbreak or an agent-based exploit.

Cellebrite's UFED (Universal Forensic Extraction Device) can perform filesystem extraction on a wide range of iOS and Android devices. For iOS, Cellebrite uses a proprietary agent that is loaded onto the device via a DFU-mode exploit. The agent bypasses the sandbox and reads the raw filesystem, including deleted file entries, SQLite freelists, and WAL files. For Android, UFED can use ADB-based extraction on rooted devices or exploit-based extraction on unrooted devices, depending on the device model and Android version.

GrayKey (now marketed as Magnet GrayKey after Magnet Forensics acquired Grayshift) specialises in iOS extraction. GrayKey devices exploit vulnerabilities in the iOS Secure Enclave or boot chain to bypass the lock screen and extract the filesystem. The specific exploits used are proprietary and closely guarded. GrayKey updates its exploit portfolio regularly, and there is an ongoing arms race between Apple's security team and Grayshift's exploit developers. As of early 2026, GrayKey can extract most iPhones running iOS 17 and some running iOS 18, depending on the hardware revision and patch level.

MSAB XRY is the third major player, widely used by European law enforcement agencies. XRY supports both logical and filesystem extraction across hundreds of device models. Its particular strength is its device support database, which includes detailed profiles for extracting data from each supported model.

Physical Extraction and Chip-Off

Physical extraction captures a raw image of the entire storage chip, including areas not accessible through the filesystem: unused space, invalid NAND pages, and the FTL's internal structures. This is the most complete extraction method and the one most likely to recover deleted data.

The most common physical extraction technique is chip-off: physically desoldering the storage chip from the device's circuit board, placing it in a chip reader, and reading the raw NAND contents. This is destructive to the device (the chip can sometimes be resoldered, but the process is risky) and requires specialised equipment: a hot air rework station for desoldering, a NAND reader compatible with the chip's package and interface, and software capable of interpreting the raw data.

The raw NAND dump from a chip-off extraction is not directly readable as a filesystem. The data is scattered across physical pages according to the FTL's mapping, and the FTL mapping table itself may or may not be readable from the dump. Forensic tools must reconstruct the logical layout by analysing the data patterns, ECC (Error Correction Code) metadata, and spare area information on each page. This is computationally intensive and error-prone, but it recovers data that no other method can reach.

JTAG (Joint Test Action Group) and ISP (In-System Programming) are alternative physical extraction methods that do not require desoldering the chip. JTAG uses the device's debug test access port to read memory contents. ISP connects directly to the storage chip's data lines on the circuit board (by soldering fine wires to test pads) and reads the chip in situ. Both methods avoid the risk of damaging the chip during desoldering, but they require detailed knowledge of the device's circuit board layout and are slower than direct chip reading.

The Extraction Hierarchy in Practice

A forensic lab in Frankfurt working a case will typically start with logical extraction (fast, non-destructive, legally clean), move to filesystem extraction if more data is needed (requires justification and possibly a more specific warrant), and resort to chip-off only for high-priority cases where critical evidence is believed to exist in deleted data. Each step up the hierarchy increases cost, time, risk, and the amount of recovered data.

The practical reality is that filesystem extraction recovers the vast majority of "deleted" messages. SQLite freelist pages, WAL files, and notification logs provide a rich vein of deleted content without the complexity and expense of chip-off. Physical extraction is reserved for cases where the device is damaged, locked with an unknown passcode and no available exploit, or where evidence of data wiping is suspected.

File Carving: Recovering Data from Raw Storage

File carving is the technique of scanning a raw storage image (from a chip-off or physical extraction) for recognisable data structures without relying on filesystem metadata. The idea is that even when the filesystem says a region is "free," the bytes may still form a recognisable file.

Carving works by scanning the raw image byte by byte (or page by page) looking for known file signatures, often called "magic numbers." A JPEG file starts with FF D8 FF E0 or FF D8 FF E1. A PNG starts with 89 50 4E 47 0D 0A 1A 0A. A SQLite database starts with 53 51 4c 69 74 65 20 66 6f 72 6d 61 74 20 33 00 ("SQLite format 3\0"). When the carving tool finds a known header, it attempts to determine the file's length (either from the header's length fields, or by scanning for the footer, or by reading until the data stops making sense) and extracts the complete file.

For messaging forensics, the most valuable carving targets are:

SQLite databases. A carved SQLite database from unallocated space may be an older version of the messaging app's database, containing messages that have since been deleted from the live database. On a device that has been in use for two years, it is not uncommon to carve three or four historical copies of msgstore.db from different points in time.

Media files. Photos, voice notes, and videos sent via messaging apps are stored as separate files on the filesystem. When deleted, their NAND pages persist. Carving recovers these files even when the database records linking them to specific conversations are gone. A carved JPEG from WhatsApp's media directory can be matched to a conversation by its filename pattern (IMG-YYYYMMDD-WAnnnnnn.jpg) or by EXIF metadata.

Protobuf and binary message formats. Some messaging apps use Protocol Buffers or custom binary formats for message storage or caching. Carving tools with Protobuf awareness can identify and decode these structures from raw dumps. Telegram's local cache, for instance, uses a custom binary format that forensic tools like Oxygen Forensic Detective can parse directly from carved fragments.

Keyboard prediction databases. As noted earlier, keyboard apps maintain their own SQLite databases. Carving can recover older versions of these databases containing learned words and phrases from deleted conversations.

The limitation of carving on flash storage is fragmentation. On a hard drive, files tend to be stored in contiguous sectors, so carving can recover complete files by reading from the header to the expected length. On NAND flash, the FTL scatters pages across the die, and a chip-off dump may not preserve the logical ordering. Carving from a physical NAND dump requires the examiner to first reconstruct the page ordering (using spare area metadata, ECC data, and FTL table fragments), which is a significant technical challenge.

The Difference Between Logical, Filesystem, and Physical Extraction

These three terms come up constantly in forensic reports and court proceedings, and the distinction matters for understanding what evidence is available and how reliable it is.

Logical extraction captures data through the device's own APIs. On iOS, this means an iTunes-style backup. On Android, this means an ADB backup or a content provider query. The data is what the operating system chooses to expose. Deleted messages are not included (they have been removed from the live database). However, messages in backup files (WhatsApp's local .crypt15 backups, for example) may include messages deleted from the live database after the backup was created.

Filesystem extraction captures a bit-for-bit copy of the filesystem partition(s). This includes all files (live and cached), SQLite databases with their freelist pages, WAL files, journal files, system logs, and deleted file entries that the filesystem has not yet overwritten. This is where the bulk of deleted message recovery happens. A skilled examiner with a filesystem image and the right SQLite tools can reconstruct weeks or months of deleted message history.

Physical extraction captures the raw contents of the storage chip, below the filesystem level. This includes everything in a filesystem extraction, plus: filesystem slack space, unallocated blocks, NAND pages invalidated by the FTL but not yet erased, and (in some cases) the FTL mapping table itself. Physical extraction is the gold standard for forensic completeness but is the most technically demanding and the most legally scrutinised.

The evidential value of each extraction level differs across EU jurisdictions. In Germany, the Strafprozessordnung (Code of Criminal Procedure) allows search and seizure of digital devices under sections 94 and 98, but the scope of the search must be proportionate. A filesystem extraction may require a more specific judicial order than a logical extraction. In the Netherlands, the distinction is less formally codified but practically observed. Courts in Athens, Barcelona, and Stockholm have all dealt with challenges to the admissibility of chip-off evidence, with outcomes varying based on the specific procedural safeguards followed.

Secure Deletion: Why It Is Nearly Impossible on Flash

On a traditional hard drive, secure deletion is conceptually straightforward: overwrite the file's sectors with zeros or random data. The old magnetic patterns are replaced by new ones. Tools like shred on Linux do exactly this. With a single overwrite, recovery is impractical against any real-world adversary (the Gutmann 35-pass overwrite is a historical artefact based on obsolete MFM/RLL encoding and is not necessary on modern drives).

On flash storage, secure deletion through overwriting is impossible by design. When you write zeros to a logical block, the FTL writes the zeros to a new physical page and marks the old page (containing the original data) as invalid. The old page still exists on the NAND die. You have not overwritten anything; you have created a new page full of zeros and left the original data intact in a different physical location.

You cannot address physical NAND pages from userspace. The FTL is a black box. There is no standard command that says "erase this specific physical page." TRIM tells the controller that a logical range is unused, but the controller decides when and whether to erase the corresponding physical pages. You are asking politely, not commanding.

Several approaches to secure deletion on flash have been proposed, and all have significant limitations:

Full-device encryption with key destruction. This is the approach used by iOS (Data Protection) and Android (File-Based Encryption). The data on the flash is always encrypted, and deleting the key renders the ciphertext unrecoverable. This works if the encryption is sound, the key management is correct, and no copies of the key exist elsewhere. In practice, this is the best available option. Apple's Secure Enclave and Android's StrongBox/Titan implementations are robust against most adversaries. But they are not infallible: Secure Enclave vulnerabilities have been found (the checkm8 bootrom exploit affects A5 through A11 chips), and key material can sometimes be extracted from memory dumps.

Cryptographic erase via ATA Secure Erase. The ATA specification includes a Secure Erase command that instructs the drive to erase all user data. On SSDs, this typically destroys the encryption key used by the drive's self-encrypting drive (SED) feature, making all data unrecoverable. However, research by Nikos and colleagues at a university in Amsterdam showed in 2022 that some SSD firmwares implement Secure Erase incorrectly, leaving data recoverable. Relying on the drive's firmware to correctly implement a security-critical operation is a trust decision.

TRIM with deterministic zeroing. Some SSDs implement "Deterministic Read After TRIM" (DRAT) or "Deterministic Read Zero After TRIM" (DZAT), meaning that reading a trimmed LBA returns either deterministic data or zeros. DZAT guarantees that the logical view of the data is gone, but does not guarantee that the physical NAND pages have been erased. The data may still be recoverable from a chip-off dump.

Manual NAND erasure. In theory, you could erase every block on the device by writing the entire storage capacity with random data, forcing the FTL to garbage-collect and erase all blocks. In practice, this takes a long time (writing 256 GB of random data to a phone's storage), causes significant wear (potentially consuming a meaningful fraction of the flash's endurance budget), and may not cover all blocks (the FTL may reserve some blocks for its own use and not expose them to the host).

The honest conclusion is that on flash storage, you cannot guarantee deletion of specific data. You can only guarantee that the data is encrypted and the key is destroyed. If you care about deletion, you must care about encryption first.

Signal's Disappearing Messages: What They Get Right and What Leaks

Signal's disappearing messages are the best widely available approximation of real message deletion. When a user enables disappearing messages on a conversation, each message is assigned a timer that starts when the message is read. When the timer expires, Signal deletes the message from the local database on both devices (the sender's and the recipient's).

What Signal gets right:

Database encryption. Signal's SQLite database is encrypted with SQLCipher, using AES-256-CBC with HMAC-SHA256 page authentication. Without the decryption key, the database is a blob of random-looking bytes. SQLite freelist pages and WAL entries are encrypted, so the standard SQLite forensic techniques (scanning freelist pages for deleted rows) do not work without the key.

Minimal metadata retention. Signal's servers store almost no metadata. Messages are queued for delivery and then deleted. Signal does not store conversation lists, group memberships (in the traditional sense; group state is distributed to members), or contact graphs. A server-side seizure yields very little.

Forward secrecy. Signal uses the Double Ratchet protocol, which provides forward secrecy: compromising a current session key does not decrypt past messages. Even if an adversary extracts the current session keys from a device's memory, they cannot decrypt messages that were sent before the keys were ratcheted.

Sealed sender. Signal's sealed sender feature encrypts the sender's identity in the message envelope, so Signal's servers do not know who is sending a message to whom (with some caveats around delivery receipts and server-side correlation).

What leaks despite Signal's design:

Android notification history. As described earlier, message content that appears in notifications is logged by the Android system outside Signal's control. On devices running Android 11 and later, the notification history is stored in a system database that persists across app data wipes.

Keyboard dictionaries. Signal cannot prevent the system keyboard from learning words typed into its text input field. Signal provides an "Incognito Keyboard" option on Android that requests the keyboard to disable learning, but this is a hint, not a requirement. Not all keyboards honour the TYPE_TEXT_FLAG_NO_SUGGESTIONS flag, and even those that do may still log keystrokes for crash reporting or analytics.

Backup files. If the user enables Signal's built-in backup feature (on Android), messages are exported to an encrypted backup file on the device's storage. Disappearing messages that have not yet expired at the time of the backup are included. The backup file is encrypted with a 30-digit passphrase, but if the passphrase is weak or recoverable, the backup contents are accessible.

Screen content capture. On Android, Signal uses FLAG_SECURE to prevent screenshots within the app. This blocks the standard screenshot mechanism and most screen recording tools. However, it does not block: ADB screen capture from a connected computer, accessibility services that capture screen content, or device-manufacturer screen recording tools that operate at a lower level. On iOS, Signal cannot prevent screenshots at all; iOS does not provide an API for blocking screenshots in third-party apps (only DRM-protected video content can use the UIScreen.captured API to blank the screen).

Message reactions and read receipts. Even after a message disappears, metadata about interactions with that message may persist. Signal stores delivery and read receipt status, and while the message content is deleted, the fact that a message existed at a particular timestamp between two contacts may be inferable from remaining metadata.

Forensic memory analysis. If a device is seized while Signal is open in memory, a memory dump can contain decrypted message content, session keys, and other sensitive state. This is a narrow window, but it is a real attack vector for a well-resourced adversary who can seize a device while it is unlocked (a "live acquisition" scenario).

Sofia, a digital forensics expert at a research institute in Berlin, published a study in 2025 examining the persistence of Signal messages across 14 Android devices from different manufacturers. She found that on 11 of 14 devices, notification history contained readable fragments of disappeared Signal messages. On 8 of 14, the Gboard prediction database contained words and phrases from Signal conversations. On 3 of 14, the device's cloud backup (Google One Backup) contained a copy of Signal's encrypted database from before the messages disappeared, though the database remained encrypted.

Legal Frameworks in Europe for Digital Evidence

The recovery and use of deleted messages as evidence in European legal proceedings is governed by a patchwork of national and EU-level rules. Several principles are broadly shared:

Lawful basis for seizure. Seizing a device and extracting its data requires a lawful basis, typically a court order or warrant. In Germany, this is governed by the StPO (sections 94, 98, 100a for telecommunications interception). In France, by the Code de procedure penale. In the Netherlands, by the Wetboek van Strafvordering. The specificity of the order matters: a warrant to seize "a mobile phone" may not authorise a full physical extraction of the storage chip, depending on the jurisdiction.

Proportionality. Under Article 8 of the European Convention on Human Rights (right to respect for private life), any interference must be proportionate to the legitimate aim pursued. A forensic extraction that examines the entire contents of a person's phone to investigate a minor offence may be disproportionate. Courts in multiple European jurisdictions have suppressed evidence obtained from overly broad device searches.

Chain of custody. Digital evidence must be handled with a documented chain of custody. The forensic examiner must demonstrate that the extraction process did not modify the original data (write-blocking for storage devices, proper hashing of acquired images, documented procedures). European courts have excluded evidence where chain of custody was not adequately documented.

The ePrivacy Directive. Directive 2002/58/EC (as amended) governs the confidentiality of communications. It restricts the interception and storage of communications data by service providers and public authorities. National implementations vary, but the general principle is that communications content is more strongly protected than metadata.

GDPR implications. The General Data Protection Regulation applies to the processing of personal data by law enforcement (alongside the Law Enforcement Directive, 2016/680). Forensic analysis of a seized phone involves processing personal data of the device owner and potentially of third parties (contacts, correspondents). The processing must have a lawful basis, be necessary and proportionate, and be subject to appropriate safeguards.

Cross-border access. Messages often transit servers in different jurisdictions. An iCloud backup may be stored in Apple's data centre in Denmark. WhatsApp's servers are in the United States. Accessing data held by a foreign service provider typically requires a Mutual Legal Assistance Treaty (MLAT) request or, within the EU, a European Investigation Order (EIO) under Directive 2014/41/EU. The proposed EU e-Evidence Regulation would streamline cross-border access to electronic evidence, but it remains in legislative process as of early 2026.

A practical illustration: Katerina, a prosecutor in Athens, is investigating a fraud case. She has obtained a court order to seize the suspect's iPhone and extract its data. The forensic lab performs a filesystem extraction using Cellebrite UFED. The extraction reveals deleted WhatsApp messages in the msgstore.db freelist that are relevant to the case. She also requests the suspect's iCloud backup from Apple via an MLAT request to the United States (or, if Apple processes the request through its Irish subsidiary, via an EIO). The iCloud backup contains a copy of the WhatsApp database from two weeks before the device seizure, with messages that have since been deleted from the live database. Both sources of evidence are presented to the court, along with the forensic examiner's report documenting the extraction methodology, hash values, and chain of custody.

Real Forensic Case Patterns

Without disclosing specifics of any individual case (forensic reports are typically subject to strict confidentiality), several patterns appear consistently in the published forensic literature and in conference presentations by European digital forensics practitioners:

The WhatsApp freelist recovery. This is the most common scenario. A suspect deletes WhatsApp messages before or after device seizure. The forensic examiner extracts the filesystem, opens msgstore.db in a SQLite forensic tool (such as Cellebrite Physical Analyzer, Oxygen Forensic Detective, or the open-source undark tool), and recovers deleted rows from freelist pages. Recovery rates vary: on a database that has not been vacuumed and has sufficient freelist space, 60 to 90 percent of recently deleted messages can be recovered. On a database that has been vacuumed or heavily reused, recovery is partial.

The iCloud backup discrepancy. Investigators compare the live device state to the iCloud backup state and identify messages present in the backup but absent from the live device. This temporal difference analysis reveals what the suspect deleted between the backup time and the seizure time, effectively creating a log of the deletion activity itself.

The notification log recovery. On Android devices, investigators extract the notification history database and find message content from Signal, Telegram, or other "secure" messaging apps. This is a growing area of forensic practice, driven by the increasing use of encrypted messaging apps by persons of interest.

The keyboard dictionary reconstruction. Investigators analyse the keyboard prediction database and reconstruct words and phrases that the suspect typed frequently. While this does not provide complete message content, it provides keywords, names, and phrases that corroborate other evidence or guide further investigation.

The carrier metadata correlation. When message content is unavailable (fully encrypted, properly deleted, or on a device that cannot be extracted), investigators use carrier-retained metadata to establish communication patterns. Connection timestamps, cell tower locations, and data volumes provide a timeline of when messages were sent and received, even if the content is gone. Andreas, a forensic investigator in Stockholm, presented a case at a 2025 DFRWS EU conference where carrier metadata was used to establish the timing and location of a series of Telegram messages, while the message content was recovered from the recipient's device via Cellebrite extraction.

The multi-device problem. Modern messaging apps support multiple devices. iMessage works across iPhone, iPad, and Mac. WhatsApp has multi-device support. Telegram works on as many devices as you want. A message deleted from one device may persist on another. Forensic examiners increasingly seek warrants for all devices associated with a suspect's accounts, and synchronisation timing differences mean that at least one device often contains data that was deleted from the others.

Conclusion

The word "delete" in the context of messaging is a user interface concept, not a storage operation. Pressing delete removes a reference in a database. The data itself persists across multiple layers of the storage stack, each with its own retention dynamics, each offering a potential recovery path to a forensic examiner with the right tools and legal authority.

The most important takeaway is that privacy is not a feature of the delete button. It is an architectural property of the entire system, from the encryption scheme to the storage medium to the cloud backup policy to the keyboard app running alongside your messaging client. Signal gets closer to real deletion than any other mainstream app, but even Signal cannot control what the Android notification system logs, what the keyboard learns, or what a seized device reveals under memory analysis.

If you want a message to be truly gone, the conditions are demanding: the message must be encrypted at rest with a key that is destroyed after deletion, the encryption must be correct, no unencrypted copy may exist in any backup, notification log, keyboard dictionary, or Spotlight index, the storage medium must either cryptographically erase the old key material or physically overwrite the ciphertext, and no other device, server, or carrier must retain a copy. In practice, achieving all of these conditions simultaneously, for every message, across every layer, is beyond what any current consumer platform reliably guarantees.

The forensic tools exist. The legal frameworks exist. The data, almost always, is still there. "Deleted" is just a word on a button.