WhatsApp forensics in 2026 and what survives end-to-end encryption | Andrea Fortuna

In March 2026, WhatsApp told roughly 200 people in Italy that their phones had been compromised by a fake client masquerading as the real app. Meta traced the campaign, publicly named Spyrtacus, back to a lawful-interception vendor, a story covered extensively by SecurityAffairs and other outlets. A few months earlier, Russian investigators extracting data from a seized phone in the Cellebrite-Pivovarov case (documented forensically by the Citizen Lab) pulled messages straight out of WhatsApp, Telegram, and Viber, then searched them for the names of opposition figures.

Two very different stories, one shared lesson: end-to-end encryption protects the wire, not the endpoint. Once a device is in your hands, WhatsApp leaves behind more forensic material than most users assume, and knowing exactly where to look separates a productive examination from a wasted evening staring at a locked SQLite file.

In brief

WhatsApp’s E2E encryption (based on the Signal Protocol) secures messages in transit, but on-device storage remains the real target for forensic acquisition.

Android stores conversations in msgstore.db, contacts in wa.db, and encrypted backups in the evolving crypt12/crypt14/crypt15 formats.

iOS consolidates almost everything into a single ChatStorage.sqlite file, which simplifies parsing once you have filesystem access.

Decryption always requires the key, which lives on the device or in an escrowed backup, never a bypass of the underlying cryptography.

Open-source tools like wa-crypt-tools and whapa now handle the full crypt15 pipeline, reducing the gap with commercial suites.

Timeline correlation across install provenance, accessibility permissions, and network beaconing matters more than the message table alone, especially in spyware cases like Spyrtacus.

How WhatsApp actually protects your messages (and where that stops)

WhatsApp implements the Signal Protocol for message transport, based on the cryptographic framework detailed in the company’s encryption whitepaper. Every message is encrypted client-side before it leaves the sender’s device and decrypted only on the recipient’s. This has been true since 2016, and it is not going away. What it does not do is protect data once it lands on disk. The app still needs to render your chat history when you open it, which means a fully decrypted, human-readable copy of every conversation sits in local storage at all times.

This distinction matters enormously for forensic work. Cracking Signal’s Double Ratchet is not on the table, and does not need to be. The actual objective for a forensic examiner is straightforward: get access to the device’s filesystem, then get access to the key material that protects the local database or its backup. As a TechNadu LinkedIn post about wa-crypt-tools put it bluntly:

“The weakest link is never the algorithm, it’s access.”

That single sentence explains why lawful intercept vendors, state-sponsored spyware operators, and DFIR practitioners investigating a compromised laptop all converge on the same target: the device, not the wire.

Android artifacts from msgstore.db to the crypt15 puzzle

On Android, WhatsApp data is split across several files, and the split has grown more complex with each protocol revision:

/data/data/com.whatsapp/databases/msgstore.db, the live, unencrypted message database (chats and messages tables), accessible only with root or a full filesystem extraction.

/data/data/com.whatsapp/databases/wa.db, which stores the contact list.

/sdcard/WhatsApp/Databases/msgstore.db.crypt15 (or the older .crypt12/.crypt14), the encrypted local backup WhatsApp writes daily.

/data/data/com.whatsapp/files/key, a 64-byte key file used to decrypt the backup, present only if the examiner has application-level access.

Older crypt12 backups used a static key derivation that made recovery trivial once you had the key file. crypt14 added versioning and a slightly different header structure. crypt15, now the default, moved to a protobuf -encoded key file with rotating parameters, which broke a lot of older single-purpose decryptors and forced the community to catch up. The most actively maintained answer today is wa-crypt-tools by ElDavoo, a Python toolkit that understands all three formats end to end.

A typical decryption pass looks like this:

pip install wa-crypt-tools

wa-crypt-tools-decrypt15 \<br>--key-file /path/to/extracted/key \<br>--input msgstore.db.crypt15 \<br>--output msgstore_decrypted.db

Once decrypted, msgstore_decrypted.db is a plain SQLite file. From there, standard SQL gets you a working timeline in minutes:

SELECT<br>m.timestamp,<br>m.key_remote_jid AS contact,<br>m.data AS message_body,<br>m.media_wa_type AS media_type<br>FROM messages m<br>WHERE m.timestamp BETWEEN 1735689600000 AND 1738368000000<br>ORDER BY m.timestamp ASC;

Pairing the decrypted database with whapa adds structured reporting and media correlation on top, which saves...