Android - SMS Applications and that Syncing Feeling

When it comes to Android, one of the behaviors I have always found most interesting is that data gets duplicated all over the place. Calls, contacts, and SMS are among the prime examples that I usually find duplicated among other locations than where I would expect them to be. One of the reasons behind this is that Android allows for other applications to take control of primary functions on the device. Users can choose which app they want as their default browser, launcher, and most importantly, their SMS/messaging client! When this happens, Android needs a way to manage the data between the services.

For SMS/MMS messages the regular path for the core storage is: /data/com.android.providers.telephony/databases/mmssms.db or possibly: /user_de/0/com.android.providers.telephony/databases/mmssms.db in version 7 and higher of Android. This sis where we actually usually expect to find the data. However, you may very well find this data duplicated in multiple other locations depending upon what application has been used as the default messaging app.

This will likely turn into a series of posts exploring different messaging clients into Android. There were some apps that I used in this post I hadn’t seen before and I didn’t see a lot of support for so I thought it would be interesting to figure out how to parse them. In this post, I set out to install several applications on an Android version 9 device and see which ones asked to take over the default SMS functionality, what they report back to the main mmssms.db and if any would continue to receive messages even when they were NOT set as the default messaging application. My testing was to launch an app, see if it presented the option to be used as the new “Default SMS Application” and/or if it asked for permissions for the Android’s SMS, send a message with the app, receive a message with the app, repeat with the next app. If it didn’t ask to be the messaging client, see if it at least could send an SMS on behalf of the app to invite users to the service.

When opening up the mmssms.db database, the SMS data we usually care about is in the table “sms” which makes total sense. There is a column in this table called “creator” which will reveal the application BundleID or package name of the application that was responsible for feeding this data into the database. In many cases, unless the manufacturer is putting their own application on there for messaging (I’m looking at YOU Samsung), the recommended default application I’ve seen is Android Messages or com.android.apps.messaging.  This application can send and receive RCS messages in addition to the standard SMS/MMS messages.

The behavior you would expect to happen is that when an application is switched to being the default, it will carry over all of the messages from the app(s) used before it. In my testing, I switched to the "Verizon Messages" app next. When this app is launched, it immediately asks to become the default SMS application.

To find those messages, we'll use the BundleID mentioned in the creator column "com.verizon.messaging.vzmsgs" to find the path /data/com.verizon.messaging.vzmsgs/databases/messages.db where all of the SMS and other messages are stored. A quick query will reveal the messages for us to examine.

Sample query: SELECT message.time, message.thread_id, message.outbound, message.from_addr, message.to_addr, message.seen, message.read, text_content.c1body FROM message JOIN text_content ON message._id = text_content.docid

The interesting thing is that Verizon Messages was the second app I tested. Which means only the SMS transferred to the device before it becoming the default, and messages sent while it is the default should be listed here. Comparing this to the Android Messages app that was used prior, the last two records in the database are from the messages sent with the Android Messages app and none of the apps after it.

After the Verizon Messages app, I moved through several others. A lot of these will be covered more in depth in later posts, but I wanted to give the highlights about whether they did or didn't end up in the mmssms.db and if they stored data outside of their use. 

Android Messages - Allows SMS - Set as default on my Pixel 3a - Only synced messages when it was the default. 

Verizon Messages - Allows SMS - Continued to sync ALL SMS even when not default app. 

Facebook Messenger - Allows SMS - Couldn't locate where SMS are being stored currently. More testing required.
Facebook Messenger Lite - Didn't allow SMS
WhatsApp - Didn't allow SMS
Viber - Didn't allow SMS
Pulse SMS - Allows SMS - Continued to sync SMS after not being default app
Textra - Allows SMS - Continued to sync SMS
Mood Messenger - Allows SMS - Synced SOME messages but not ALL messages of apps used after
imo HD - Didn't allow SMS
goSMS - Allows SMS - Seems to not track SMS when it's not the default app. More testing required. No messages were able to be recovered even ones sent with this app.
Handcent Next SMS - Allows SMS - Synced SOME of the messages of apps coming after but not all.
Chomp SMS - Allows SMS - Seems to not track SMS when it's not the default app. More testing required. No messages were able to be recovered even ones sent with this app.
WeChat - Didn't allow SMS
Telegram - Didn't allow SMS
Signal - Didn't prompt to become default SMS client. SMS is capable in Signal, more testing is needed.
Kakao - Allows SMS - Could only locate partial SMS messages. More testing required.


As you can see, there's some erratic behavior from these apps. Some applications will only sync data when they're the default. Some will sync SOME data when they're not the default, others will continue to sync ALL data when they're not the default. Some apps may completely drop their records when they're not the default SMS app.

Conclusion and Roundup: 
Time to try and round up all this stuff into something that makes sense for examiners. Any time you review the data in mmssms.db and see the creator column reflecting any BundleID (and hopefully your forensic tool of choice is showing you this data), you should probably go dig into that app's data folder and see what's there. When messages are deleted from one app, it does not mean that the data will get deleted from all of the apps that have synced this data to their databases. If your user has bounced between multiple apps trying to settle on the right one for themes, stickers, or whatever other feature they were looking for, that means more data for you! Who doesn't love free data?! [Don't forget the Call Log database can do this too!]

All of the apps tested called back to the main mmssms.db. This is great news as this is probably the main place you go to look for messages, but I'm not sure that all apps will do this. Especially ones more focused on security like Signal. I was really surprised to find Kakao in here!

Another point to mention is that in some of my testing I saw where apps that can't actually send SMS got SMS messages with their bundleID as the creator column. An example of this was GroupMe. Even when GroupMe didn't have SMS functionality turned on, it still was able to send an SMS when an invite code was generated for another user. If the app has permission to read and write the SMS database, it may still send messages on its behalf even if the user isn't sending full SMS messages through it.

Further testing will include going back to take a look at several of the apps that didn't seem to keep their data around (Mood, Handcent, goSMS, and Kakao), apps that don't prompt to be used as the default (GroupMe and Signal), and some other apps I didn't get around to as well (like Samsung's default messenger). I'll continue to update this post series and hopefully come back with new links to the other parts. I'll also take a deeper dive into some of the apps to provide DB queries and other analysis info in case it's ever needed by someone.