One thing that has piqued my interest the past few months is pulling out as much data as I can from each of the Google applications. As they continue to pivot away from Android exclusives to broaden their application usage to iOS, I will take a look at both versions of the facetime calling application Google Duo.
With the pandemic still roaring forward we continue to see a rising shift to video chat application usage. Duo is a simple application from the get go. The one click friendliness of being able to communicate with someone in your contact list is pretty appealing. Other things you can do is also just use voice calls or chats to the person which may seem useful if you don't have a cellphone plan as it works over wifi. But enough about the features and let's dive into what really matters, the data.
Android Analysis
As of at least as far back as Android 10, the Duo app folder per version 145.0.385228731.duo.android_20210711.00_p1is located here:
data\data\com.google.android.apps.tachyon
The main files of interest is in the "databases" folder naturally called "tachyon.db". This houses the meat of what we can look at from an analysis perspective. We get a good amount of tables to sift through as you can see below from the DB Browser screenshot:
Figure 1: Tachyon.db Tables
Using Josh Hickman's test images as well as my own personal test phone, I found useful information populated in the following tables:
- activity history - main activity history, including types of interactions
- duo_users - the user contacts, including the local user
- media_download - media images downloaded after being sent to the user
- media_upload - media images uploaded to be sent to another user
- messages - non video chats / pictures
Activity History
The main timeline of events contain a few interesting columns:
- other_id - the remote user's ID, can be a phone number or email address
- activity_type - type of activity that occurred
- 1 = Call
- 2 = Note, basically like a Snapchat still image with a caption
- 4 = Reaction, emojis can be used to "react" to a conversation
- timestamp_usec - timestamp of the entry in Unix Epoch format in microseconds
- activity_metadata - shows emojis and some other user info, not easily readable
- self_id - the local user's ID, whether it's a phone number or email address
- call_state - call status basically
- 0 = Left Message
- 1 = Missed Call
- 2 = Answered
- 4 = TBD **saw this once on a sample image but not sure how it was generated yet**
- outgoing - direction of the call
- 0 = Incoming
- 1 = Outgoing
Duo Users
Basically a full list of contacts that the user communicates with through the app, including the local user's information:
- user_id - can be a phone number or email address
- id_type - identifies what is used for user_id
- 1 = phone
- 16 = email
- contact_display_name - name used in the contacts, "Josh Hickman"
- system_contact_last_update_millis - last time the contact was updated, in Unix Epoch millisecond format
- contact_phone_type_custom - can pull from other apps? One of Josh's contacts had a phone number listed and it was labeled "TextNow"
- contact_id - unique ID for each contact, if a contact has multiple items such as an email and multiple phone numbers associated with an account, they will all have the same ID here
Messages
Since uploads and downloads all show in the Messages table here, I will just lump them together for this blog post, but it's worth noting you may get statuses for images that may have not finished uploading or downloading from the other tables.
- sender_id - phone number or email of the sender
- sender_type - type of the senders ID
- 1 = phone
- 16 = email
- recipient_id - phone number or email of the recipient
- recipient_type - type of the recipients ID
- 1 = phone
- 16 = email
- sent_timestamp_millis - timestamp of when the message was sent in Unix Epoch milliseconds format
- received_timestamp_millis - timestamp of when the message was received in Unix Epoch milliseconds format
- content_uri - file path on the local phone to the image file
- seen_timestamp_millis - timestamp of when the message was seen in Unix Epoch milliseconds format
- initial_insert_timestamp_millis - timestamp of when the message was first insert in Unix Epoch milliseconds format
- content_size_bytes - size of the content sent / received
- message_metadata - has some text format of a Note
- saved_status - whether or not the message was saved to the phone specifically
- 0 = No
- 1 = Yes
There is still more testing to be done for the most part we get a good picture of what can be pulled from the Duo app on Android. You can get the latest build of ALEAPP that includes a parser for this.
Figure 2: Duo Call History
Figure 3: Duo Notes
Now onto what the iPhone has in store for Google Duo.
iOS Analysis
Per the Application State DB for Josh's test image, the Google Duo sandbox folder lives at the following path:/private/var/mobile/Containers/Data/Application/7AB8E0C5-77B8-4393-AADE-7B27190FC1BC
Navigating through to the Library > Application Support folders, we get to the data we want to look at. The "DataStore" file is actually just a SQLite database so we can open it in our favorite DB Browser (remember to get those -wal files too!).
Figure 4: DataStore Tables
Tables of interest here include:
- call_history - the main table for call conversation history
- contact - the local user's contacts list from Duo
- media_clip_v2 - contains info on Clips (iOS naming convention for Notes?)
- message_reaction - my assumption is this includes the emoji reactions like from Android, but I don't have any test data here to go off of (hoping to get some generated eventually)
Call History
Similar to the Activity History on Android, we get some of the call history and actions taken in the application here:- call_history_other_user_id - remote user ID, a phone number or email address
- call_history_timestamp - timestamp of the call in Unix Epoch format
- call_history_is_outgoing_call - call direction
- 0 = Incoming
- 1 = Outgoing
- call_history_user_action - TBD, lots of various values seen in this column
- 2 = Call
- call_history_duration - length of the call in seconds, interesting that I didn't see this on Android anywhere
- call_history_is_video_call - whether the call was a video call or not
- 0 = No
- 1 = Yes
- call_history_local_user_id - local user ID, a phone number or email address
Contact
Of course we have a table with user contact information, which ties nicely back to the call history:
- contact_id - a phone number or an email address
- contact_name - full name of the contact, ex. "Josh Hickman"
- contact_number_label - similar to contact_phone_type_custom from Android, ex. TextNow or "mobile" or "home", not sure if this is set by the regular Contact Book or not
- contact_sync_date - last date a contact was synced in Unix Epoch microseconds format
- contact_reg_data_timestamp - I believe this to be the timestamp a contact was registered but not 100% confident on this, timestamp is in Unix Epoch microseconds format
Media Clips V2
Here we get information on media clips that were created (basically the Notes from the Android version):
- media_clip_clip_id - ID of the media clip, this can be used to correlate to the Clip Cache folder (more on that below)
- media_clip_remote_user_id - ID of the remote user, a phone number or an email address
- media_clip_content_size - size of the file (I assume locally)
- media_clip_transferred_size - size of the file being transferred
- media_clip_creation_date - creation timestamp of the media, in Unix Epoch microseconds format
- media_clip_local_id - ID of the local user, a phone number or an email address
- media_clip_message_date - timestamp of the media message itself, in Unix Epoch microseconds format
- media_clip_viewed_date - timestamp of when the media was viewed, in Unix Epoch microseconds format
- media_clip_text_representation - text overlay extraction of the Clip
I'm sure much more data can be extracted from the DataStore database file but I thought this was the most relevant for the data set I had at hand. With more sample evidence, we could look at further pulling out other items that may be useful for an investigation.
Clips Cache
Inside the Application Support folder is another folder called "ClipsCache". Inside contains cached images of Clips that were sent or received. The file names can be correlated back to the "media_clip_clip_id" found in the DataStore > media_clips_v2 table.
Figure 5: Sample ClipsCache file