Android Messaging Forensics – SMS/MMS and Beyond

There are a lot of third-party chat apps available for iOS and Android. Just look at the Google Play Store and iTunes Store and you’ll see more chat applications than you’ll ever be able to use and each target a different type of user, age group, region, or lifestyle. The most popular ones tend to be WhatsApp, Kik, WeChat, Facebook Messenger, and many others, but text messaging still reigns supreme in many areas. Why? Because it’s simple to use, cross-platform (so everyone has it), and it’s installed on every handset by default.

Most forensic examiners would think that analyzing text messages would be easy to do — simply look up the SMS database, read the message, sender, receiver, and timestamp and report on anything of value and some investigations are that easy. However, there are many types of messages beyond just SMS that get bucketed along with it and this post will dive into the different types of messages you may get when dealing with a standard text message investigation.

SMS/MMS – mmssms.db

Most forensic examiners know to look at the MMSSMS.db for SMS/MMS data on almost any device. Android devices typically store this data in the telephony folder here:

/data/data/com.android.providers.telephony/databases/mmssms.db

Mmssms.db is an SQLite database and is supported by most forensic tools or read by any SQLite viewer. There are several tables of interest but for the most part the key information will be in the message content, message timestamp, and sender/recipient.

The SMS/MMS database may be included in an ADB backup on some devices but often it is not included and must be pulled in another manner by using content providers.

Content Providers

Third-party apps may also access the SMS/MMS data for their own purpose. Apps like Facebook Messenger, BBM, WhatsApp, etc. will often ask for permissions to access your contacts or SMS/MMS messages, etc. in order to enhance the integration between the apps and your data. Android allows this access via content providers.[1] In order to acquire additional data that may not be included in a standard ADB backup, tools may choose to install an app or an agent on the user’s phone, collect all the content provider data, and then extract it as part of their own app data. Some tools will extract an ADB backup and agent data as two separate acquisitions, Magnet AXIOM and ACQUIRE will automatically do both as part of a Quick/Logical acquisition.

Image shows ADB backup as “adb-data.tar” and content provider data in the “Agent Data” folder.

Depending on the acquisition method used to pull the SMS/MMS data, AXIOM will label it a few different ways. Most of the time you’ll either see artifacts listed as either “Android SMS” and “Android MMS” but occasionally you’ll see them combined as “Android SMS/MMS (Content Provider)” to indicate that the ACQUIRE agent pulled that data via the content providers and then rebuilt the database during the acquisition. You may also see them stored as “Android SMS/MMS (Google Play Services)” when your acquisition was able to get a full physical or file system image of the device. All the relevant SMS/MMS data should be present in each method, we just distinguish each method to let the examiner know how it was acquired as how it was stored on the backend may differ slightly between methods.

Android SMS/MMS – Google Play Services – Icing_mmssms.db

For devices in which you have privileged access to the entire file system (physical acquisition and/or full file system), you may also come across SMS/MMS data in a different database called icing_mmssms.db. AXIOM and IEF call this “Android SMS/MMS – Google Play Services”.

RCS Messages

Rich Communication Services (RCS) is newer protocol meant to replace standard SMS.[1] It has added functionality and features including multimedia, group chat, voice/video calling, as well as several others. While it’s not fully adopted and supported by all carriers, many are starting to support RCS messages on their network alongside or as a replacement for SMS. AT&T/T-Mobile/Sprint in the US, Rogers in Canada, Vodaphone in Europe as well as many others have all supported RCS messaging with many more carriers aiming to add support in the near future. While Apple has implemented iMessage for similar reasons of added functionality beyond SMS, it’s one main limitation is that it is not cross platform so you can only use iMessage to chat with other iPhone users. RCS is a protocol that is being adopted at the carrier level and should be supported across any device that chooses to have an app that supports it. Google has created the Android Messages app just for this purpose.

Android Messages – Bugle_db

Android also has its own messaging app in the Google Play Store called “Android Messages” which supports a number of different message formats including SMS/MMS and RCS messages.[2] Now depending on the model, and OS, several carriers are using Android Messages as the default messaging app as opposed to the regular SMS/MMS app created and installed by manufacturers such as Samsung. You may also encounter both apps installed where the user has chosen to forgo the standard SMS/MMS app for Android Messages. The android.XML file will indicate what the default messaging app is for a given device.

Data for the Android Messages app can be found here:

/data/data/com.google.android.apps.messaging/databases/bugle_db

While structured differently than the mmssms.db, the investigative value is similar in the sense that you’ll want to collect at a minimum the sender, recipient, message, and timestamp of the message. You’ll also want to distinguish if a message was SMS, MMS, or RCS as well. The messages, participants, and parts tables can be of value to your investigation.

Samsung Text Message Logs

Another type of messages you may encounter are specific to Samsung devices. Samsung stores message logs here:

/data/data/com.sec.android.provider.logsprovider/databases/logs.db

These messages may include some duplicates from regular SMS/MMS but often you will find additional message data here as well. While the data is only built for logging so you may only get snippets of data, it can be quite valuable as a secondary source of information, especially if the user has deleted many of their messages.

The Samsung text message logs are often overlooked by examiners focusing on just the mmssms.db and can hold vital information to your investigation.

Overall, it’s important for examiners not to overlook the other messaging types beyond SMS/MMS and other popular third-party chat apps like WhatsApp, Facebook Messenger, Kik, etc. While the average user may just use the default messaging app, other times, the default app might have changed for a given device or the user could be using multiple chat applications intentionally or unintentionally to avoid detection.

If you have any additional questions, feel free to reach out at jamie.mcquaid@magnetforensics.com

Thanks,

Jamie McQuaid

[1] https://en.wikipedia.org/wiki/Rich_Communication_Services

[2] https://play.google.com/store/apps/details?id=com.google.android.apps.messaging

[1] https://developer.android.com/guide/topics/providers/content-providers

Update: Gabriele Zambelli pointed out another great spot to identify SMS message data on Android by looking at the call log database (calllog.db) which has changed in Android 7 and 8. The database contains a table called “m_content” which contains the first 50 characters of a SMS message. This info isn’t typically pulled via content providers or included in an ADB backup so would only be available in full physical or file system images of an Android device but still valuable and may be missed by your forensic tools. For more information, check out Gabriele’s blog here: https://forensenellanebbia.blogspot.com/2018/10/calllogdb-and-sms-data-on-android-70.html.