Facebook Messenger

The first application that I have looked at is Facebook Messenger (version 2.2.5-release) which can be found here. This application is a way to access the chat platform built into Facebook and is currently very popular on Android. As of today (2/13/2013) it is the fifth top free application on the Google Play store.

I decided to look into GPS artifacts created by this application due to its popularity and its ability to include location data with each message sent. Location data can be enabled/disabled on a per conversation basis.

Location On

The first step I took in analysis was investigating Android system logs to determine what happens on a system level when a message with location settings on is sent.

Logs

To accomplish this I connected my phone (HTC Droid Incredible 2) to my computer and then launched the Android Debug Bridge, or adb. Included as part of the Android SDK, adb is a useful means for developers to debug their applications. More information on adb can be found here.

One of the features of adb is the ability to view live system logs on the host computer. Using the 'adb logcat -v time' command I watched what happened when I opened Facebook Messenger. The first thing that I noticed was that as soon as a conversation was opened, the Android GPS activity notification showed that it was looking for a GPS signal. I imagine this is to speed up adding coordinates to a message. Sending a message will also generate this notification. This command generated a large amount of activity within the logs so I transferred the text into notepad to facilitate sorting through it. The first relevant entry I found was:

As this lists the pid of the process it's possible to link this specific GPS request with the program that called it. I accomplished this using the 'adb shell' command which opened a shell session on the phone. I then ran 'top' to get a list of the processes.

According to this, Facebook Messenger was the process which called for GPS. Looking farther down past this log entry were numerous entries related to GPS. It appeared to be getting coordinates multiple times, each time getting more accurate.

First set of coordinates

Once the final coordinates are acquired the 'intermediate' is replaced with 'final'. I am unsure why this screenshot shows that the accuracy was reported at 42. My best guess is that being indoors decreased the communication with the satellites, however I did check the latitude and longitude on Google Maps and found them to be accurate.

 

Final set of coordinates

Shortly after the final coordinates are entries to end the GPS request.

This behavior seems to be consistent with figure two located here.

At times I noticed that coordinates were being appended to messages even though I could not see any activity for GPS in the logs. This behavior seems to be consistent with the Android documentation on location as it can use a cached location to prevent high battery usage.

I also noticed that with GPS turned off from the system settings, Facebook Messenger still gets coordinates presumably from Wi-Fi and mobile networks. With all location options turned off in the system settings, you are unable to turn on location services from within Facebook Messenger. I did not see any activity in the logs showing it how it acquired the location.

It is possible to use logs to link GPS coordinates with specific dates, times, and pids, but I do not believe it has real world practicality. This is due to a specific pid not being tied to an application. I am also unsure how long these log files last, they appear to be a fixed length and get overwritten quite quickly  However, this is useful for testing what actions generate GPS requests. 

adb

Browsing through directories on the device, I found that applications store data within /data/data on the protected system partition. Root is required to access data stored here. Within this directory I found a com.facebook.orca directory. Using 'adb pull' I was able to extract this directory for examination on my computer.

To verify that 'adb pull' did not change the files, I compared hash values from before and after running the command. I calculated the initial md5 hash of an individual file using the 'md5' command from within a shell opened through adb.

Calculating the md5 has using the md5 command

I then pulled the file off of the phone using 'adb pull' and calculated the hash using FTK Imager. The hashes matched. I then calculated the hash of the file on the phone again using 'md5' and found that it had not changed. During an actual investigation acquiring a full forensic image of the device would be the best course of action however, pulling individual directories or files off using this method allowed me to conduct tests faster than waiting for full images.

This command can also be used to pull individual files

threads_db2

Databases

I began my search with the 'databases' directory as I felt it had the highest probability of containing the kind of data I was looking for. Within this directory were six different SQLite databases along with a -journal file for each one. The full list can be seen in the above screenshot. 

I used SQLite Database Browser to analyze these databases. I began with looking in threads_db2 as it was the largest in size.This database contains a large amount of data and the various fields can be seen on the right. The 'messages' field immediately jumped out to me and upon expanding it I found that it contained some really cool data.

Within 'messages' I found every message ever sent. Not only was the sender of each message contained, but also the full text, timestamp, and the exact GPS coordinates amount other fields. The screenshot on the right lists every field within messages. The screenshot below shows the coordinates field. 

coordinates field

Conversation Order

As I began to test the behavior of this database I noticed that messages were not always in the order that they took place in the conversation. The order appeared to correct itself after a short amount of time. However, it is possible using only the data within this database to manually sort the messages. 

thread id

The screenshot on the left shows the thread id field. As you can see there are two different id's: one that ends in 89, and one in 47. Each thread id related to a different conversation, and for each thread id a message with an action id of 0 is created. Using the thread id you can take individual message and sort them into a single conversation. 

timestamp column

To ensure that the conversation is in the correct chronological order you can use the timestamp field, which can be seen in the screenshot on the right. These times are in Unix time and can be easily converted using your tool of choice. The first entry, 1359854896387, is:  Sun, 03 Feb 2013 01:28:16 GMT. 

Using these two fields is simple, if tedious, to manually ensure that the conversations are in the correct chronological order. SQLite Database Browser has an option to export the entire table as a CSV file, so this step can be sped up using Excel. 

Recipients

One important piece of information that is not immediately available is who the message was sent to. While it is possible to deduce this information by seeing who else sent messages in the thread, this won't help you if no response was sent. By changing tables in SQLite Database Browser to 'threads' you can see the participants in each thread id. This table will also tell you if it was a group chat or not, the single recipient thread cell will be 0 for a group chat.

threads table

Also present in the 'threads' table is a way to determine if a thread contains messages that have not been read by the user. This can be checked in the 'unread' column.

Previous Messages

source

I also tested if this database would contain messages sent before Facebook Messenger was installed on the device. I tested this by sending a message from the Facebook website and then logged into the Android application for the first time. As the screenshot below shows, upon logging into the application it pulled entries for the database from the Facebook Server. It also pulled the timestamp for this message, which is not shown in this screenshot.You can tell whether the message was sent from the website or the Messenger app by checking the source field, pictured right. Not shown in this picture is 'mobile' which indicates that the message was sent from the Facebook mobile application (com.facebook.katana on Android). I am unsure if there are other sources. 

Message Content

Message Length

I tested if the full content of the message was stored in the database. Until this point I had only been sending short messages to test. I sent a message of 3079 characters long and it all was present in the database. This message was too long for SQLite Database Browser to display normally and required you to open the cell into a new window which displayed the full text. 

Facebook chat also supports the sending of attachments, such as images, with messages. To test this I attached an image from within Facebook Messenger and sent it. There are two fields relevant to attachments. The first field, attachments, contains general information about the attachment and can be seen below. The second field, pending send media attachment, contains the path to the temporary file on the local device. I am unsure how long this file will reside there, currently it has been there for over a week. 

attachments

pending send media attachment

Deleted Messages

I conducted two different tests to see what happens when a message is deleted. One message was deleted from the Facebook website, and one from the Facebook Messenger application.

Deleting from the Facebook website resulted in the message only being removed from the user's message history on the website. The message still showed up in the Facebook Messenger application and in the recipients message history.

Deleting a message directly from the Facebook Messenger application removed the message from both the Messenger application, message history on the website, as well as from the database. The message is fully removed from the database, it is not just simply marked as having been deleted. It still existed in the recipients message history.

Manipulating threads_db2

Once I had a decent understanding of how Facebook Messenger utilizes this database to store messages sent and received from this device I decided to see if it was possible to manipulate this database. 

Force Stopping Messenger

To do this, I began by adding an entry to the database using SQLite Database Browser by clicking the 'New Record' button in the top right of the window. I then filled out the fields by copying what was in real messages and increasing the value by 1 where appropriate. Once I had everything filled out, I then pushed the updated database to the phone. I began by closing Facebook Messenger on the phone to prevent it freaking out when its database was deleted and replaced. I accomplished this by going to Settings -> Apps and then locating Messenger and tapping 'Force stop' as seen on the right.

I then opened a shell on the phone and navigated to /data/data/com.facebook.orca/databases and deleted 'threads_db2' using the 'rm' command. Then I pushed the updated 'threads_db2' to the phone using 'adb push'.

adb push

Upon opening Facebook Messenger I found that the manually added message was listed in the conversation.  This message was not synced to the Facebook account and could only be seen on the device.

Editing an entry and then pushing the updated database to the phone resulted in the message containing the relevant changes, but nothing was synced to the server.

Unsent message as seen from Messenger

Next, I looked into attempting to get a manually added message to sync. My first clue into doing this was noticing messages that were marked as 'msg type' 901. These stood out to me as I had only seen types 0 (for normal messages) and -1 (parent of each thread). Upon looking at these messages on the phone to determine what was different about them, I realized that they were messages that had not been sent. When tapped, the red error icon attempts to send the message again.

Maybe William  Riker has been to Mt. Erebus, but I haven't

I added a message, including fake latitude and longitude, to the database and marked it as 'msg type' 901. I then pushed the database to the phone and opened Facebook Messenger. After tapping the error icon and resending the message, not only did the message show up in Facebook Messenger it also appeared in the message history on Facebook for both the send and receiver. This included the fake location coordinates. Timestamps, however, are replaced with the time that the message is resent.

I also attempted this method with a message that I had received from a different account. Unfortunately (fortunately?) the conversation list initially displays that thread with the symbol indicating that a message was not sent, but upon loading the full conversation the message is removed. It is also removed from the database.

As of yet I have not found a way to verify that messages were actually sent and not manipulated. While it is possible to verify that a message was added to the database by checking the message history on the Facebook website, someone could claim that the message was deleted from the website by both users and only remains on that device. It may be possible to analyze the 'msg id' or 'action id' of the message to determine that they were not calculated normally, but I am unsure how these values are determined. They may even be completely random.

For messages marked as 901 and then resent, I am unsure how to verify that that took place. One way would be to check if the phone is rooted or not. If it is not, these database could not be edited. On the other hand it may be possible to unroot the phone without having to wipe all data. With cellular devices you could check the coordinates against what the carrier has logged for that device.





I'm sure I only scratched the surface with the Facebook Messenger databases but I what I found I feel is enough to determine with some degree of certainty that a user sent a message from a specific location assuming that users have not manipulated anything. Feel free to leave comments!