Forensic Duel: Exploring Deleted WhatsApp Messages—iOS vs Android
Introduction
Deleted data is a crucial aspect of digital evidence. While suspects' chats and files provide valuable insights, finding out what they attempted to hide can be pivotal in solving a case. In mobile forensics, where physical acquisition is a rare possibility, hunting for deleted data can be a tricky task for both forensic tools and investigators. The diversity of mobile applications adds to the complexity—even the same application can manage data storage differently in different operating systems.
In this article, which is part of our WhatsApp forensics series, we will explore the mechanics behind data storage and deletion in WhatsApp databases. We will also examine the application data with the help of Belkasoft X and discover whether it is possible to retrieve deleted chats from the WhatsApp database in iOS and Android.
SQLite and deleted records
Like many other mobile applications, WhatsApp relies on the SQLite format to store its data. We have covered the forensically interesting SQLite features in the "SQLite Forensics with Belkasoft X" article. One key takeaway from that article is the potential to recover deleted records from SQLite databases. In particular, SQLite incorporates several features for managing deletions, including:
- Freelists: a dedicated section within an SQLite database that houses recently deleted data
- Journal and Write-Ahead Log (WAL) files: transactional files that can store recently added or recently modified or deleted data
- Unallocated space: this SQLite feature allows finding deleted data even outside of freelists
To understand whether these features can help with deleted WhatsApp messages, we should first explore the application database in different operating system contexts.
iOS WhatsApp database
To investigate the databases, we created a conversation between an iOS and an Android device user and then intentionally deleted several messages. WhatsApp offers two deletion options: "for Everyone" (only for some time) and "for Me." In this test, we used the "for Everyone" option on two messages, and the remaining messages were deleted "for Me." Below, you can see how they appeared on our test iPhone.
Next, we obtained the full file system copy of the iPhone through the checkm8-based acquisition method in Belkasoft X. Although WhatsApp data can also be obtained from an iTunes or iCloud backup, the full file system copy typically provides a more comprehensive dataset. You can learn more about iOS WhatsApp acquisition methods and forensic peculiarities in this article.
We also used Belkasoft X to analyze and examine the acquired image. When we located our test chat, we found the following artifacts parsed from the database:
Those messages mirrored the content available on the device at the time of the acquisition. No items deleted "for Me" were present, and empty message bubbles denoted items deleted "for Everyone." But what if the tool was unable to parse the deleted records? Let us delve into the database itself. Belkasoft X has a powerful SQLite viewer that allows you to recover all types of database records, including freelists, write-ahead logs (WAL), and unallocated space.
We located the ChatStorage.sqlite database that contains WhatsApp conversations. The full file system copy of the device includes WhatsApp databases in ..\private\var\mobile\Containers\Shared\AppGroup\, in the subfolder named after the GUID that the system assigned to the application when it was installed on the device. Message details are part of the ZWAMESSAGE table.
Our initial step involved sorting the table by the Record type column, but we found no freelist or WAL records. Subsequently, we examined the Unallocated space section of the database, where we did discover a few records, though none of them held any significant information. Our next step was to sort the data by the primary key to locate our chat messages.
The database presented an identical picture to the artifact view, with no traces of deleted records. However, keen observers may notice gaps in the Z_PK (primary key) values. In our experience, primary key values increase by one for each new record, such as a sent or received message. When records are deleted, they are removed from the database along with their corresponding primary key values. Together with the ZSORT column that identifies the chronological order of messages within a conversation, the primary key numbers can help identify if there are gaps in user's chats.
Based on these findings, we can conclude that iOS WhatsApp databases are unlikely to help recover deleted messages. Nonetheless, you can still gain insights on the removal of records from conversations by analyzing the Z_PK and ZSORT columns in the ZWAMESSAGE table.
Android WhatsApp database
Our next step was to obtain data from the Android phone involved in the test conversation. Below you can see how the messages looked before and after deletion:
We acquired the device with the "Android file system copy" method and analyzed it using Belkasoft X. Then, we located our test chat within the "Artifacts" window of the tool.
As you can see, Belkasoft X was able to recover the majority of the deleted messages.
Now, you might be wondering why we could retrieve these deleted messages in Android while none of them were present in iOS. To gain a deeper understanding, let us look into the Android WhatsApp database.
Android devices store WhatsApp message data in the msgstore.db file located in ..\data\data\com.whatsapp\databases\. The message table contains the records of the user's chats. Let us sort the table by the _id column to find our test conversation:
Here, you can observe that some of the primary key values are duplicated, and one number is missing. At the same time, a number of records originate from the WAL file, as the Record type column informs. What does it all have to do with deleted messages?
Write-ahead log
Write-Ahead Log (WAL) is a mechanism used in SQLite to manage database records. It involves initially writing changes to a separate WAL database file. This way, when records are added or changed, the database engine starts reading WAL records instead of the main database to retrieve the latest available data.
The process continues in this manner until a checkpoint occurs. During a checkpoint, the changes recorded in the WAL file are merged into the main database, and the WAL file is subsequently removed. Checkpoints can be triggered automatically when WAL files reach a certain number of records, or they can be initiated by sending a specific command to the database. The choice of the checkpoint triggers to use depends on the application developer's preferences for their database.
WAL files include all changes made to records between two checkpoints. Even if a record is deleted, WAL preserves its original state. It means that WAL records can help recover modified and deleted data from application databases, but only when captured before a checkpoint.
If we scroll back and look at the Android database WAL records, we can see the database transactions that occurred during the conversation between the WhatsApp users and the time when they deleted the incriminating messages. Belkasoft X's SQLite Viewer displays the records from the WAL file together with the main database records so that you can view the history of the changes in one place.
Belkasoft X is able to retrieve these records because the WAL checkpoint that would purge transactional data from Android WhatsApp had not occurred by the time of the acquisition. What is notable, though, is that one of the messages deleted "for Me" by the Android user was completely removed from the database anyway. WhatsApp is based on proprietary code, and we cannot figure out exactly how it has the WAL mechanism configured in Android, but based on the test, it is still more cooperative in Android than in iOS.
Conclusion
In our investigation of deleted WhatsApp messages on iOS and Android, we found clear differences in how the same application stores its data on these platforms. iOS WhatsApp databases proved less cooperative, showing no signs of deleted records. However, we could deduce record removal by noting missing primary key values in the corresponding database table, although the content of deleted messages remained unavailable.
On the other hand, Android provided a more promising outcome. We successfully recovered most deleted Android messages using Belkasoft X. Android's usage of a write-ahead logging (WAL) mechanism, along with fewer checkpoints, facilitated the recovery of deleted data and offered valuable insights into the deleted part of the conversation history.
These findings underscore the importance of comprehending the unique database structures and mechanisms for forensic analysis and data recovery, as well as using the appropriate tools for forensic extraction and analysis.