The Boundary Most People Get Wrong

Encryption in transit and storage on disk are two separate problems. Once a message lands on a phone and gets rendered in a chat window, it has to be stored somewhere the app can read it back. On Android that somewhere is almost always SQLite.

WhatsApp keeps messages in msgstore.db and contacts in wa.db under /data/data/com.whatsapp/databases/. Instagram direct messages live in a SQLite store (the direct.db database) under /data/data/com.instagram.android/databases/, though Meta reshuffles this storage more often than most. These are plaintext-readable databases sitting inside the app sandbox. The cryptography that protected the message on the wire does not re-encrypt it field by field inside the local store.

So the question is never "is this app encrypted." It is "can I reach the app sandbox in the device state I have." Those are completely different questions, and confusing them is where investigations stall.

Metadata Is Never in the Envelope

Even where you cannot recover content, E2E was never designed to hide the metadata, and on a seized device you have direct access to it.

Who talked to whom. When. How often. Message timestamps, thread participants, the cadence of a conversation at 2 a.m. for three nights running. Call logs with duration. None of that is protected by the content encryption, because the app needs it to function. A thread that goes silent the day before an arrest tells a story that the message bodies sometimes cannot.

For a lot of investigations the relationship graph and the timeline carry the case. Content is corroboration. Treat metadata as primary evidence, not as a consolation prize.

SQLite Does Not Forget

Deletion inside these databases does not mean erasure. When a row is removed from a SQLite B-tree, the page goes onto the freelist, but the bytes stay there until that space is reused or someone runs VACUUM. Most messaging apps almost never VACUUM their stores.

The Write-Ahead Log is the other half of this. The -wal file holds pre-commit state, including page versions that may contain records no longer visible in the main database. Parse msgstore.db, msgstore.db-wal, and msgstore.db-shm together. Pull the main database alone and you can miss messages that were never committed back or were deleted but still sit in the log.

This is independent of E2E entirely. The encryption protected the message from the carrier. It did nothing to stop the app from leaving deleted-row residue on the freelist of a database you are now holding in your hand.

Backups Are the Soft Spot

WhatsApp encrypted backups, the crypt14 and crypt15 files, are genuinely encrypted at rest. But encryption only matters if the key is out of reach, and frequently it is not. The backup key, or the material to derive it, can live on the same device or in an account backup the user enabled. When you have both the encrypted backup and access to the key material, the backup decrypts. The lock is only as strong as where the key sits.

This is worth checking on every Android device with WhatsApp. The local msgstore.db covers the current install, but crypt backups can reach further back than what the live database retains.

State Decides Everything on iOS

On iOS the deciding factor is data protection class, not the messaging app's marketing. Most user data, including Messages, falls under Protected Until First Authentication. PFUA data is accessible after the first unlock since boot, even while the screen is locked.

That is the practical point. An AFU iPhone that has been unlocked once and then locked again still has its message store reachable, because the class keys were unwrapped at first unlock and stay available. The chat app being "encrypted" does not change the data protection class governing its files.

Which is exactly why you never reboot a seized phone, and why the auto-reboot clock matters. iOS 18.1 and later reboot after roughly 72 hours idle. Recent Google builds restart after 3 days locked. Both push a device back toward BFU and re-seal everything PFUA was giving you. The encryption you should worry about is not the app's. It is the disk encryption that re-engages when the state changes underneath you.

Where the Wall Is Real

Be honest about the limits, because overclaiming gets evidence thrown out. Telegram's cache4.db is standard SQLite and you can open it in DB Browser, but the message content sits in TL-serialized binary blobs in the data field rather than plain columns, so you need a parser that understands that structure to read the tables meaningfully. Secret chats are also device-local and genuinely E2E, and the app deliberately leaves little behind. Cloud chats are a different matter, since Telegram holds those keys server-side, but that is not something you decode off the device.

The discipline is knowing which wall you are actually facing. "The app uses E2E" is not a wall. "This specific store uses non-standard encoding I cannot parse" might be. "The device went BFU before I imaged it" definitely is.

The Takeaway for Monday

Stop reading "encrypted" as "empty." E2E is a transit guarantee, and your evidence problem is a storage and state problem. Assess the device state first, reach the app sandbox, parse the database alongside its WAL, check for recoverable backups, and build the timeline from metadata that the encryption never touched. The phone almost always knows more than the label suggests.