Communication data can be recovered from the Android device through multiple forms of acquisition. Call logs, contacts, and messages are commonly acquired communication methods on smartphones. As with other smartphones, Android devices have specific locations for storing communication data.
Call logs are stored in the USERDATA/data/com.android.providers.contacts/databases directory on many Android devices. The primary database to be examined is the contacts2.db, which contains the call log information. Some fields of interest in the calls table include:1
Number: Phone number
Date: UNIX Epoch date-timestamp
Duration: Length of call, in seconds
Type: 1 = Incoming
2 = Outgoing
3 = Missed
4 = Voicemail
For Androids running Nougat (v7) or later, the USERDATA/data/com.android.providers.contacts/databases also contains the calllog.db database. The table of interest for this database is calls. The screenshot shows the calllog.db database. Some devices may populate this database, while others seem to have it, but it’s empty. Should you find this database, refer to your class notebook (access will be provided in Section 5, so be patient) for the query to parse it. Some highlights here are shown in the case statements. Notice that there are more fields we would want to include in the contacts2.db. Also keep in mind that your tools may not parse this file correctly!
SQLite Query for Calllog.db
select
_id,
number,
name,
datetime(date/1000,'unixepoch') as "Timestamp",
duration as “Duration_in_Seconds”,
CASE
when type = 2 then "outgoing"
when type = 1 then "incoming"
when type = 4 then "voicemail"
end as "Call Type",
subscription_id,
phone_account_address,
geocoded_location,
formatted_number,
CASE
when deleted = 1 then "deleted"
else "NA"
end as "Deleted",
CASE
when dirty = 1 then "Dirty"
else "NA"
end as "Valid Entry",
transcription
from calls
The calllog.db also stores SMS responses to incoming calls. This will be covered in lab 2.1A of this section. Take NOTE of “Type 300”. It matters because the tools don’t handle this information the same way.
calls.logtype=100 THEN "Call"
calls.logtype=200 THEN "MMS"
calls.logtype=300 THEN "Message"
Reference:
[1] Andrew Hoog, Android Forensics: Investigation, Analysis and Mobile Security for Google Android (Waltham, MA: Elsevier, 2011).
NOTE: The USERDATA/data/com.android.providers.contacts/contacts2.db contains a plethora of information in various tables. For example, email accounts, synced applications, application status updates (Facebook), dates and times of contact communication, starred contacts, and more can be found in this database.
Google Fi accounts will also contain voicemail transcripts in the table “calls”. The transcript may not be 100% accurate, but still a good indicator of the message. Samsung devices (at least on Android 11) will also show SMS traffic (ingoing/outgoing) and a snippet of the text message. If the message is short enough, the message will be stored in its entirety. This behavior seems to be similar to what was observed in USERDATA/data/com.sec.android.providers.logsprovider on older devices.