Private Chat Applications: Anything of Forensic Value Beyond Manufacturer-Claimed Encryption?

The everyday rise in third party applications across different app stores, mobile operating systems, mobile hardware, and application versions themselves has not only prompted but to a certain degree, necessitated the digital forensics community and digital forensics researchers to investigate various applications that are not inherently supported and parsed by commercial forensics tools. Apart from the capabilities associated with various forensic tools, depending on the case, many forensicators may come across most unthought-of third party applications for investigation. The only questions then would be: 1) How to parse such data?, 2) Is there anything of a forensic value?, and 3) Some third party application manufacturers claim that they encrypt data. However, due to the lack of time and technology, in some instances, when there is no access to or knowledge of decryption method, where and how to find data pertinent to the investigation?

Depending on the circumstances mentioned above, it is crucial to come to a firm conclusion about how and where some data resides for certain third-party applications, regardless of what the manufacturers claim. There is a plethora of third-party applications out right now that are utilized by people for a variety of purposes, whether it is for good or bad. Oftentimes, as forensics practitioners, it is our job to dig down and hunt for data that can give us some insight into what was going on in the device, related to a particular application. These applications may offer capabilities such as geolocations, communications, network-related artifacts, etc., that can be of value to certain cases.

Specifically, from the private chat applications point of view, there are many applications that are secure or claim to be secure due to the utilization of an encryption mechanism; this is great because who does not want robust security around the aspect of privacy! However, in this blog, I intend to show how certain data can still be recovered despite encrypted databases that can certainly bring some forensic value as opposed to having absolutely no data. My aim is to also stress the point that just because the main databases, which are storing all the crown jewels, are encrypted, does not mean you do not go through the rest of the data to find something of relevance, if such data exists.

Out of the many private chat applications, Dust: The safe place to text, is one of those that caught my attention. I came across Patrick Siewert and Heather Mahalik’s research, Cyber Dust Privacy Claims Debunked blog post — Pro Digital Forensic Consulting and SANS DFIR Webcast: Smartphone Security is Getting Stronger Are Your Forensic Methods Getting Weaker from 2015, in which they questioned Mark Cuban, co-founder of Dust, by asking “Has any testing been done against mobile forensic data recovery tools?” and he responded stating “there is nothing to recover. It never touches a hard drive anywhere”. This statement was taken as a challenge and in the SANS DFIR Webcast, Heather revealed how she was able to uncover messages within “Cache.db-wal” file that were double base64 encoded (what a great discovery!!), while the actual Cache.db encrypted. She also stressed the point of never trusting claims or your tools, which was very fascinating at that time.

Since then, many versions of Dust, along with software updates related to iOS, and different Apple devices have been released. Has anything changed since Heather’s discovery? In the quest to address this question, I utilized Joshua Hickman’s iOS 14.3 test image, to parse the populated data associated with Dust because during my research, I did not come across any post about forensic extraction from Dust v7.0.31183 RC running on Apple device with the 14.3 software update.

During this testing, I solely utilized Autopsy v4.19.2, Hex Editor Pro v6.54, and MongoDB Realm Studio v11.1.1. The data populated by Joshua Hickman related to Dust is below in Table 1. As stated earlier, he populated this data on an iPhone SE running iOS v14.3 and Dust application version 7.0.31183 RC. Again, the goal is to find really anything apart from data that we expect to be encrypted as Dust claims.

Table 1: Dust Application Data Population by Joshua Hickman

Below are my findings:

First, I downloaded the forensic image, “iOS 14–3 — Apple iPhone SE.tar”, and extracted it so I can process it as a logical folder into Autopsy for parsing as shown in Figure 1 below.

Figure 1: Image Downloading and Extraction

Below is the display of the file system folders associated with this image.

Figure 2: Display of the File System Within Autopsy v4.19.2

I located the folder associated with this application, with its ID, as shown in Figure 3 below:

“Private/var/mobile/Containers/Data/Application/8AE5A3DC-0439–4C06–954F-C9C90EE6225B”, in which I wanted to first locate the databases containing the crown jewels and ensure they were encrypted.

Figure 3: Locating the Application Data Folder With its ID

Since I already knew that this application claims to encrypt user chat data and as shown by Heather in 2015, I decided to first find that database and verify it is encrypted. I located the “Cache.db”, “Cache.db-shm”, and “Cache.db-wal” files within the “Private/var/mobile/Containers/Data/Application/8AE5A3DC-0439–4C06–954F-C9C90EE6225B/Library/Caches/com.mentionmobile.cyberdust” path as shown in Figure 4 below.

Figure 4: “Cache.db”, “Cache.db-shm”, and “Cache.db-wal” Files

As expected, the “Cache.db” was encrypted, as shown in Figure 5 below.

Figure 5: “Cache.db” File Content

The “Cache.db-shm” file was also not readable, as shown in Figure 6 below.

Figure 6: “Cache.db-shm” File Content

The “Cache.db-wal” file where Heather found double encoded base64 messages in 2015 were not there anymore, as shown in Figure 7 below (Obviously, since it was reported and the Dust developers fixed it).

Figure 7: “Cache.db-wal” File Content

Then, I wanted to locate the “Dust-sqlite” database and validate that it was encrypted. I located the
“Dust.sqlite”, “Dust.sqlite-shm”, and “Dust.sqlite-wal” files within the “Private/var/mobile/Containers/Data/Application/8AE5A3DC-0439–4C06–954F-C9C90EE6225B/Library/Application Support” path, as shown in Figure 8 below.

Figure 8: Locating “Dust.sqlite”, “Dust.sqlite-shm”, and “Dust.sqlite-wal” Files

Clearly, as shown below in Figure 9 below, upon trying to read data within database, nothing was viewable due to encryption. This is where all the chat messages and their timestamps, etc., are stored. The “Dust.sqlite-shm” and “Dust.sqlite-wal” files did not contain anything of forensic value either.

Figure 9: Empty “Dust.sqlite” Database

Going back to the main question, now it is 2021, and things have changed in terms of Dust app software version, iOS software version, and Apple devices, so is there anything part from encrypted data that I can locate? Because if yes, then it defeats the entire purpose of having encrypted databases.

I targeted the “contacts.json” file located within the “Private/var/mobile/Containers/Data/Application/8AE5A3DC-0439–4C06–954F-C9C90EE6225B/Documents” path, as shown in Figure 10 below.

Figure 10: Locating “contacts.json” File

Once loading the “contacts.json” file into the Hex Editor and analyzing it manually, I came across data displayed below in Figure 11 below (I put it nicely as it was little messy otherwise). It can be seen that the phone numbers were clearly not in plaintext, but the first two phone number strings were the same and last two were different. This made me look for 3 unique phone numbers going forward. The contact names were clearly in plain text: “This is DFIR Two” and “Josh Hickman”.

Figure 11: “contacts.json” content

Then, I decided to analyze “default.realm”, located within the “Private/var/mobile/Containers/Data/Application/8AE5A3DC-0439–4C06–954F-C9C90EE6225B/Documents” directory, to find anything of value.

Figure 12: Locating “default.realm” File

Once loading the “default.realm” file into the Hex Editor, as shown in Figure 13 below, and analyzing it manually, I came across strings listed and highlighted below.

• “This Is DFIR Two”
• “Josh Hickman”
• “+19198887386”
• “+19195790479”
• “+19193912507”

Figure 13: “default.realm” Content

“thisisdfir100” which was the username during data population, as shown in Figure 14 below.

Figure 14: “default.realm” Content Cont’d

At this point, while few phone numbers and user IDs were spotted in the plain text via analyzing it within the Hex Editor. All of those data points still need to be correlated to make sense based on the artifacts received from the “contacts.json” file.

Alexis Brignoni wrote an excellent blog post related to parsing “.realm” files. Based on that, I further loaded the “default.realm” file into the Realm Studio v11.1.1 tool for the additional parsing purposes. As shown in Figures 15–16 below, after loading the file into Realm Studio, I extracted and saved data in the JSON format for the readability purposes.

Figure 15: Processed “default.realm” File Within Realm Db Viewer & Saving the Content as JSON Format

Figure 16: Saved “default.json” File

Upon opening the “default.json” file, I was able to locate a few more artifacts that can help correlate data found so far. As shown in Figure 17 below, the user account information for this particular application included listed here.

• username: “thisisdfir100”
• id string: “myrk8mlSYPbeH9rn1jN9NYzxIuN2”
• phone : “6e0c91cd65dcd9b80c67780a82bfbe6a0a68b101d13f3552aae542b746834480”

Figure 17: “default.json” File Content: Dust Account Information

Then, as shown in Figure 18 below, the “Conversation / DSTContact” category revealed critical artifacts for the correlation perspectives. I was able to locate following.

• Contact name: “This Is DFIR Two”
• Associated phone number: “+19198887386”
• Contact Created Timestamp: “2021–02–02T18:44:04.493Z”
• Contact Updated Timestamp: “2021–02–02T18:44:04.493Z”

Figure 18: “default.json” File Content: Dust Conversation Contact Information

As shown in Figure 19 below, the “Conversation / DSTContact” category revealed another contact related critical artifacts for the correlation perspective. I was able to locate following.

• Contact name: “Josh Hickman”
• Associated phone number: “+19195790479”
• Contact Created Timestamp: “2021–02–02T18:44:04.496Z”
• Contact Updated Timestamp: “2021–02–02T18:44:04.496Z”

Figure 19: “default.json” File Content: Dust Conversation Contact Information Cont’d

As shown in Figure 20 below, the “Conversation / DSTContact” category revealed another contact related critical artifacts for the correlation perspective. I was able to locate following.

• Contact name: “Josh Hickman”
• Associated phone number: “+19193912507”
• Contact Created Timestamp: “2021–02–02T18:44:04.496Z”
• Contact Updated Timestamp: “2021–02–02T18:44:04.496Z”

Figure 20: “default.json” File Content: Dust Conversation Contact Information Cont’d

I also located a few artifacts related to the Profile Picture Metadata. There were three accountIDs listed along with the associated SyncTimeStamp as shown and listed below in Figure 21. While the below artifacts do not relate to timestamps with any of the messages, they certainly provide insight into activities related to this app on February 19, 2021 and February 20, 2021.

Account 1

• ID: dFR1nXSk7camPhIG7MqTmYWNlQL2
• Timestamp converted to Local (EST): Friday, February 19, 2021 3:31:26.340 PM

Account 2

• ID: crX8qklVvFT0TsmmFNNGiL3iOWt2
• Timestamp converted to Local (EST): Friday, February 19, 2021 3:31:26.216 PM

Account 3

• ID: myrk8mlSYPbeH9rn1jN9NYzxIuN2 (this was the ID for the Dust application account)
• Timestamp converted to Local (EST): Wednesday, February 3, 2021 3:50:06.802 PM

Figure 21: “default.json” File Content: ProfilePictureMetadata

At this point, as shown in Figure 22, phone numbers associated the below profiles were successfully attributed.

Figure 22: Correlation Among Accounts and Associated Phone Numbers

Next, as shown in Figure 23 below, within the “Private/var/mobile/Containers/Data/Application/8AE5A3DC-0439–4C06–954F-C9C90EE6225B/Library” folder, I could not find anything of forensic value within “/WebKit”, “/Saved Application State”, and “/Cookies” directory paths.

Figure 23: Files Within the “/Library” Directory

However, as shown in Figure 24 below, within the “/SplashBoard/Snapshots/sceneID_com.mentionmobile.cyberdust-default” directory, I saw two images and a folder called “downscaled”, which I further investigated.

Figure 24: Files Within the “/SplashBoard” Directory

Turns out that both images found above were the exact same and they were the last snapshot of the app running on the device which showcased some of the chat messages, as shown in Figure 25 below. Clearly, at this point, we already obtained some of the chat conversation that took place on this device via the Dust application.

Readable messages:

• “… me on Cult of Mac”
• “Wow. Some sites really don’t want to get spammed, do they.”
• “No, and I can’t blame them.”
• “Here comes a picture”

Additional insight:

• an image that was sent to the user towards the bottom of the image that had the text “Tap to view”

Figure 25: Content of the Images Located Within the “/Splashboard” Directory

Then, I extracted and loaded the interesting looking file “com.radicalapplic.dust.contacts.friends.store”, located within the “Private/var/mobile/Containers/Data/Application/8AE5A3DC-0439–4C06–954F-C9C90EE6225B/tmp” directory, into the Hex Editor, as shown in Figure 26 below, to find something of relevance, if there even is anything.

Figure 26: Files Within the ““Private/var/mobile/Containers/Data/Application/8AE5A3DC-0439–4C06–954F-C9C90EE6225B/tmp” Directory

As shown in Figures 27–30 below, I came across the following strings:

• “josh_hickman9”
• “Josh Hickman”
• “+19195790479”
• “This Is DFIR Two”
• “+19195790479”
• “+19198887386”

Figure 27: “com.radicalapplic.dust.contacts.friends.store” File Content

Figure 28: “com.radicalapplic.dust.contacts.friends.store” File Content Cont’d

Figure 29: “com.radicalapplic.dust.contacts.friends.store” File Content Cont’d

Figure 30: “com.radicalapplic.dust.contacts.friends.store” File Content Cont’d

Then, I processed the “com.radicalappllc.dust.conversation.store” file into the Hex Editor to hunt for anything of further relevance, as shown in Figure 31 below.

Figure 31: “com.radicalappllc.dust.conversation.store” File Location

I came across these strings: “thisisdfir2” and “josh_hickman9”, once analyzing its content, as shown in Figure 32 below.

Figure 32: “com.radicalappllc.dust.conversation.store” Content

After that, I processed the “com.radicalappllc.dust.message.store” file into the Hex Editor to hunt for anything of relevance, as shown in Figure 33 below.

Figure 33: “com.radicalappllc.dust.message.store” File Location

I came across the following strings upon analyzing the file’s content, as shown in Figures 34–41 below:

Readable messages:

• “Onion Browser is really slow.”
• “Here comes a picture.”
• “Really?”
• “I know. The proxies. And it gets blocked on some websites.”
• “Yes. Cloudflare blocked me on Cult of Mac.”
• “No, and I can’t blame them.”
• “Man, I got tired of Firefox Focus and Onion Browser real quick.”
• “Wow. Some sites really don’t want to get spammed, do they.”

Additional insight:

• Potential reference to two image (.jpeg) files which could have been the ones sent and received during the data population.
• Multiple reference to the strings such as “Delivered” and “Read” that provides insight into chat conversation in which messages were indeed delivered and read by the user.

Figure 34: “com.radicalappllc.dust.message.store” Content

Figure 35: “com.radicalappllc.dust.message.store” Content Cont’d

Figure 36: “com.radicalappllc.dust.message.store” Content Cont’d

Figure 37: “com.radicalappllc.dust.message.store” Content Cont’d

Figure 38: “com.radicalappllc.dust.message.store” Content Cont’d

Figure 39: “com.radicalappllc.dust.message.store” Content Cont’d

Figure 40: “com.radicalappllc.dust.message.store” Content Cont’d

Figure 41: “com.radicalappllc.dust.message.store” Content Cont’d

In conclusion, associated phone numbers, user ID of the application, the name of the user populating data, various accounts interacting with the application, and all the messages were recovered, even though the database (containing various application-related data) was encrypted. Yes, I agree that no timestamps were recovered in plain text during parsing related to exact messages; however, putting together and correlating all the messages found within the snapshot of the application with the rest of the strings and other artifacts provides a lot of forensic value if this application (with the version specified earlier in the blog post) is part of an investigation. It is important to point out that yes, while Dust encrypts data, there are still remnants of data that are in plaintext that cannot be ignored. Users may trust the manufacturers entirely not knowing their data is still recoverable. Lastly, third party apps like Dust that claim to be very secure, often overlook the fact that despite their encryption, there is still data that remains in plain text. The only difference was that those messages were among a lot of other data. Thus, seeking forensic value in noise is critical especially for these kinds of applications.