Saturday, January 25, 2020

WhatsApp messages in Non-Rooted Android Devices


I needed to extract a series of WhatsApp conversations from a Samsung Galaxy S 10+ running Android 9. Since the device was not rooted, I was only able to get logical and file system extractions - I was able to extract the backup databases containing the messages but as expected, they were encrypted and I did not have access to the decryption key (again, because the device was not rooted). 

Some factors to consider:

·       I had consent from the owner to access the information that was stored on the phone, but I did not have the authority to log in with the What’s App account on another device to restore the messages to it and get a full physical extraction. 
·       Many of the key messages in the case were voice messages sent within the WhatsApp chat threads, so taking manual photographs only was not an option. XRY has a program called Photon that takes pictures of WhatsApp chats in an automated way and generates a report. I did not have access to Photon and it would not have worked for the voice messages.


WhatsApp, like many other mobile apps, uses SQLite databases to store information. However, one of the things that makes WhatsApp so secure is that it uses end-to-end encryption. This very feature that makes the app so attractive to users can be a big headache for us forensicators. 

Messages and related information such as timestamps, information about attached media, etc. are stored in msgstore.db. wa.db stores information about the user’s contacts, such as contact IDs, display names, phone numbers, etc. These databases are located under /data/data/com.whatsapp/databases/ . I was not able to access any of these files as the device was not rooted and I was not able to get a physical extraction.

WhatsApp backups (backups of msgstore.db) are stored in encrypted databases with the filename format msgstore-####-##-##.#.db.crypt**, where the number denoted by ** varies depending on the version of the encryption algorithm used. (In this case, I was dealing with crypt12). These encrypted backups are located in /mnt/sdcard/WhatsApp/Databases if the user has a physical SD card or in /data/media/0/WhatsApp/Databases in case of emulated storage. 

Figure 1 - Sample of encrypted backup databases

The decryption key for these databases is located at data/data/com.whatsapp/files/key. However, to get the decryption key the device would need to be rooted or we would need a physical extraction, which was our problem to begin with. 

Also, since WhatsApp uses a relay service and end-to-end encryption, even with legal process the company wouldn’t be able to provide message content. 

The attachments sent and received through the app are not encrypted and are saved on the device (or micro sd card if there is one), however, retrieving just the attachments without the context of the entire conversation may not make much sense for an investigation. 

If there is no physical micro SD card present:

The voice messages can be found at data/media/0/WhatsApp/Media/WhatsApp Voice Notes. The filename format is PTT-YYYYMMDD-WA####.opus, where YYYYMMDD means the date in Year, Month, and Day format and ## are digits from 0 to 9. 

Pictures can be found at /data/media/0/WhatsApp/Media/WhatsApp Images/  The filename format for the pictures is IMG-YYYYMMDD-WA####.jpg

Videos can be found at /data/media/0/WhatsApp/Media/WhatsApp Video/ The filename format for the videos is VID-YYYYMMDD-WA####.mp4

After following my standard procedures such as photographing the device and documenting all the steps, I obtained file system and logical extractions with CelleBrite’s UFED Touch2.  I also obtained a quick extraction with Magnet’s Axiom.  After verifying that I was not able to obtain the WhatsApp messages with any of these extractions (just like I expected), I proceeded to research other possible alternatives. None of the free tools or scripts that I could find online to extract the decryption key would work, as the phone was non-rooted and was running Android 9. 

Other options suggested in some forensic forums included:
·       If the device’s phone number was the number associated with the WhatsApp account, you should be able to put that SIM card inside a test phone (rooted or one where you could get a physical extraction). You could then get the key file from the test phone and use it to open the encrypted database. NOTE: I did not have permission from the phone’s owner to do this.

·       Downgrading the app appeared to work with older versions of the OS, but not with Android 9 at this moment. 

·       The WhatsApp account on the phone was set up to back up the subject’s Google account - but I was not able to do that unless I connected the phone to the network, which I wasn’t able to do either. 

My next option would be to export each chat thread to my forensic laptop using Bluetooth. Before doing this, I made sure I had the approval to do so from the lead detective, and documented all the steps, as I was interacting directly with the phone content. 

For each conversation (yes, you have to export one thread at a time with this method), click on the three dots (“More options”) on the top right corner of the screen  > More > Export chat. Then, select whether you want to export the media (pictures, videos, voice messages) or just the text. In this case, I needed everything, since I had many voice messages containing what seemed to be relevant information - otherwise I would have just taken pictures of the conversations. When prompted how I wanted to export the conversation, I selected “Bluetooth”.

Figure 2 - Select "More options" (three dots)

Figure 3 - Options to export the chat

The messages and attachments were then exported to a folder on my forensic laptop. I chose to name each folder with the same name listed in the WhatsApp (whether this was the contact name or group name).

For each thread, a .txt file is created containing the text conversation. Any media attachments are also exported to that folder with the following format (see Figure 4 below):



Voice messages

NOTE: The WhatsApp FAQ page mentions there is a limit to the number of messages that can be exported via email. “When exporting with media, you can send up to 10,000 latest messages. Without media, you can send 40,000 messages. These constraints are due to maximum email sizes.” I could not find any information as to whether there was a limit on the number of messages that could be exported using Bluetooth, but I did notice it was approximately 16-18 mb worth of media (starting with the newest attachments).

This is not a problem, as I still have these files from the CelleBrite extraction, so if an older media file that had not been exported was needed we could still find it, but keep this in mind if you are skipping that step.

It can be good practice to hash the exported files and create an L01 image to keep a copy of them with your case data.

My next problem was how to present all this information to the lead detective. I asked my friend and mentor Alexis Brignoni (@AlexisBrignoni) for suggestions and he quickly wrote a script that processes all the extracted folders and generates HTML reports for each message thread. 

You can find the awesome script here:


A few things about this awesome script:

- The script runs in Python3… you may need to install a dependency such as PySimpleGUI (pip3 install PySimpleGUI).

- Make sure you make a folder for each of the conversations you export. (I just exported one conversation in the example shown below – JavaVonMutt). Place all the folders with the different conversations within another folder (in this case, the WhatsApp2 folder), and place this folder in the same folder that has the Python script and the logo.

Figure 4 - Sample directory structure

-       Make sure you point the script to the main folder where you have all your chats (in this case, WhatsApp2)

Figure 5 - WhatsApp Manual Extractor Report Generator GUI

-       At this time, the reports do not open correctly in Safari. I used Chrome and it looks beautiful!

Figure 6 – Report for the Java Von Mutt chat thread

Figure 7- Image hyperlinked within the report


Note: This post is focused on WhatsApp on regular Android devices. The types of artifacts generated by WhatsApp in other operating systems may vary. According to my research, in iOS, WhatsApp data can be found on iTunes backups without any further encryption (you just need the iTunes backup password - or reset it if you don’t have it… but that’s a topic for another day.)

As always:
Double check your work. Don’t just rely on one tool. Whenever possible, test your tools and test your results. 
Document, document, document. 
The fact that your tool of choice can’t parse an artifact at the moment doesn’t mean it is the end of the world. We are examiners, not robots. Think outside the box!
Share your findings with the community. This is how we grow. 

Until next time!



Katalov, V. (2018, Dec. 20). A New Method for Decrypting WhatsApp Backups. Retrieved from

Mikhailov, I. (2019, July 19). WhatsApp in Plain Sight: Where and How You Can Collect Forensic Artifacts. Retrieved from

Sunday, September 29, 2019

A "Quick Look" into iOS Snapshots

I can’t believe I am finally publishing a blog. I have started writing about at least 5 or 6 different subjects, but I often get distracted and move on to research something else, and forget to go back and finish what I was doing. ***SQUIRREL!!!***

Oftentimes**, when a user swipes up on the screen while using an application in an iOS device, or presses the home button (on those devices that still have one), or if they receive a call while using an application, the active application is sent to the background. A “snapshot” of the current screen is taken in order to provide a smooth visual transition while changing screens.  

** Developers can choose to disable this, to use an overlay image, or to hide certain fields, for security reasons, for example.

From iOS 10 on, these snapshots have been stored as KTX files. KTX is a Khronos Group compression format that provides a container for multiples textures or images. This format usually requires less memory and is faster and more efficient than other types, presenting an advantage for mobile devices.  A more detailed review of the KTX format is beyond the scope of this post, but the specs can be found on the Khronos Group website.

These snapshots can be located at:



Through research I found that the relationship information for these snapshots was stored in the applicationState.db, located in /private/var/mobile/Library/FrontBoard… but of course, it wasn’t stored in a simple way… it was stored in a blob within the database – you guessed it! In a binary plist within a binary plist.

I could go manually parsing the snapshots information for each of these applications one by one, but I would probably fall asleep halfway through the second one. I needed to find a way to automate this process, so I talked to my good friend and mentor Alexis Brignoni (@AlexisBrignoni), since he is very familiar with bplist inception, Python, and mobile devices in general. Our solution?


I have always said that the best way of forensically examining a Mac is by using a Mac. I think this also extends to iOS devices. There are several tools out there that do a fantastic job of parsing iOS extractions, but what do we do when the tool does not support a specific artifact? Or even when the tool does support it, it is our responsibility to understand where the reported values come from, and to make sure they are correct, especially if someone’s freedom depends on it.

So far, my favorite way of viewing KTX files has been to “Quick Look” them with Finder (while being a responsible forensic examiner and making sure they are write protected so I don’t step all over the evidence).

Brigs wrote a Python script ( that would extract all the KTX snapshots from the iOS extraction. I then created an Automator Quick Action that converts KTX files to PNG for usability purposes. Finally, Brigs created This script first identifies and extracts the incepted bplists related to our snapshots from within the ApplicationState.db. Then, it makes an HTML report for every application that contains snapshots in our iOS device. This is just a quick summary of the methodology we used - for a detailed explanation please check out Brigs’s blogpost.

By the way, iOS Snapshots remind me of Recent Tasks in Android – If you don’t know what I am talking about, here is a great post by Brigs, you  might be missing out on great evidence for your cases.

Forensic Implications/Case Scenario

Imagine a case where our suspect (John Doe, of course) has recorded a video of himself committing a crime using the native Camera app of his shiny brand new iPhone. In the middle of it, Mr. Doe suspends the application (maybe he received a phone call while he was recording or maybe he got paranoid and decided to get rid of the evidence). Of course, the suspect knows his way around technology and also emptied his “Deleted photos” folder within the native iOS app. We know iOS devices are not too forgiving with deleted data.

While examining the full file system extraction of Mr. Doe’s phone, we recover several KTX snapshots from different applications. These snapshots, along with other awesome files such as KnowledgeC, plists, etc. can help us paint a better picture of what was being done on the phone around the time of the crime.

In particular, we recover the following snapshot from /private/var/mobile/Library/Caches/Snapshots/

While this video may no longer be there, it might prompt us to further investigate… The timestamp associated with the KTX file might give us some perspective. Or maybe it could provide additional clues for our investigation. Maybe he shared this video with someone, uploaded it into social media, or moved it into a secret app. Maybe we could serve a search warrant to Apple for iCloud backups. Maybe, just maybe, we might get lucky and find a video approximately 21 seconds long, recorded around the time indicated in the timestamp. 

“Every contact leaves a trace.”- Professor Edmond Locard

Even though Locard’s Exchange Principle is often applied to tangible evidence such as DNA or blood splatters, it very much applies to digital evidence as well.

It is extremely important that we train our forensic personnel or first responders to limit their interactions with digital evidence to the minimum necessary to preserve it. You don’t want to be explaining to the jury why these snapshots have timestamps dated after the police was on scene, or even worse (in my opinion), have a murderer walk away free because we destroyed a key piece of evidence for not being careful.

Note: Our research has been primarily focused on iOS 11 and 12, but we are planning on expanding it to include other versions. We are also currently doing additional research on the timestamps located within the bplists. As always, please validate, validate, validate! Also please feel free to chime in if you have any additional info, because this is how we grow as a forensic community.

48 65 6c 6c 6f 20 57 6f 72 6c 64

…It wouldn’t be a proper geek blog if it didn’t have that title…

Now that we have that out of the way, thank you for visiting my blog. After so many months of putting it off, I finally gave in and decided to create a blog to share my thoughts and findings with the #DFIR community. Any posts and opinions stated here are mine, unless otherwise specified.

Stay tuned for my first actual post soon!

- G.

WhatsApp messages in Non-Rooted Android Devices

Problem I needed to extract a series of WhatsApp conversations from a   Samsung Galaxy S 10+ running Android 9. Since the device was...