Investigating WhatsApp has brought forth significant results. In the case of Kik, data was generated using WhatsApp on an iOS and an Android device. The two devices were used to send messages to one another, utilizing the full spectrum of WhatsApp’s abilities, including text messages, video messages, audio messages, and pictures. Artifacts for all these message types were found and recovered.
Most relevant information from WhatsApp is stored in one of two SQLite databases. These are named ZWAMESSAGE and ZWAMEDIAITEM, and both can be found inside “ChatStorage.sqlite”.
This database contains the text contents of exchanged messages, with the exception of media captions. If a multimedia message is sent, and paired in the same message with text, this is not where that text will appear in storage. This is somewhat contrary to other apps we have examined. However, this content can be found elsewhere. In ZWAMESSAGE, you can find message content. A record of all sent messages is contained here. Messages sent with multimedia, regardless of whether the media was captioned or not, appear as empty in this particular table. Blank lines represent media messages. The emojis used in conversation can be seen in the text logs below, alongside the text they were sent with.
Additionally, this database contains the names and contact information of those who contacted you. Your contact is uniquely identified by the phone number you used to register @s.whatsapp.net. This has been partially blocked out below. You can also see the sent times stored as EPOCH timestamps, as well as numbers that index each text message sent and each media message sent. This can be used for future reference.
This is the other most important database for understanding stored WhatsApp artifacts. ZWAMEDIAITEM indexes all kinds of media sent in a way that corresponds to the numerical identifiers used in ZWAMESSAGE, as shown above. This is where media captions are stored. Under the header ZTITLE, you can see the text a piece of media was sent with. This database also contains a number of properties for each media item, including file size, and the number message it was sent in. Some other properties are only available under specific circumstances. For example, in our case, geolocation data was unavailable, but this table did contain spaces for storing it. Also, if the media in question was a video, the app stored how many seconds long it is in this table. Perhaps most importantly, this table contains file paths for the media it stores, and as a result, the media sent in WhatsApp was all fully recoverable.
Unlike iOS, most of the artifacts on Android are all contained in one central location: inside the msgstore database. Specifically, inside a table named “messages” inside msgstore is where the bulk of the information is. Shown below are some of the contents, including the text message content, contact information, and EPOCH timestamps.
Once again, the blank lines represent messages that contained media. Regardless of whether or not the media was captioned, this space is blank because the captions are stored elsewhere. Inside the same table, there are columns denoting the properties of sent media files. Specifically, the file type, the number of bytes large it is, the name the media was given if it was saved locally, and the captions for these pieces of media.
Also similar to the iOS version of WhatsApp, this table contains a space for saving geolocation data, which is also blank in this case for the same reason: it was not provided during data generation.
All media sent and received in WhatsApp was stored locally, and was fully recoverable.
We continue to be satisfied with the level of recoverable data from Kik and WhatsApp. Data has been stored in WhatsApp in a way that is similar but not identical to Kik. Further investigation into other similar apps will help to determine a general idea of what is standard practice and storage for this kind of data. Our goal is to continue in this research and pursue more results. Our next subject will be the GroupMe app.