If you have ever performed mobile forensics, chances are you’ve come across Facebook’s Messenger app. For those of you unfamiliar, Facebook decided to better handle their traffic [and business model] by creating the standalone “Messenger” application for all non-browser direct messages. The app reached a billion users in 2017 and has been steadily increasing ever since (forbes).
A typical smartphone device contains the ‘com.facebook.katana’ database, which is codename for the messenger project. Numerous tables exist within this local database (as of July 2018) that contain mountains of user data. Contacts, message conversations, timestamps, etc are all ripe for the investigator’s picking. Unfortunately, Facebook Messenger is not as friendly on the Windows 10 OS.
What data is stored in Facebook Messenger from the Windows 10 App Store?
To my surprise, this application uses a beautiful blend of both local and cloud storage. I went into this Windows app overview thinking I would find databases somewhat similar to those present on mobile devices. Although some sqlite database files do exist on Windows, they greatly differed from those on the mobile version. Along my careful search I found only four database files that have the ability to indirectly serve as possible case evidence. These are fbomnistore.db, orca2.db, p2p_transfer.db, and searchstore.db.
The majority of the data you will retrieve from this database is focused around user account logs and app details. It can be found at path:
Of the 29 tables within this database, only three are of relevance to us. The first is “client_activity_log”. This table displays application data for the user account such as the last time the application ‘refreshed’ its different data. Possible logs entries may include the user’s client requesting a snapshot for contact/message collection or queuing. An investigator may be able to deduce particular actions such as when a message was pulled into the application and the last time the application had run an update request for messages, contacts, and threads.
“collection_index#” is the preface to a collection of tables that deal with contacts, calls, etc. An investigator can see phone calls that have occurred on the system, along with more detailed info on any messenger contacts. It provides semi-valuable fields such as a contacts name, if they are a friend, and even their phone number that is linked to Facebook.
“library_metadata” is the last useful table in this database. Here you can find entries for the last times specific actions occurred. This includes the last check for messages, contacts, calls, and updates.
Many forget that Facebook has its own embedded point-to-point payment system. Within this table you can retrieve information on past payment requests and successful transactions. The path to this database is:
All payment requests made to the user’s account are logged in the “p2p_requests” table. Here you will find the Facebook id of the person who is requesting money, the id that is associated with this request, who the payment is being requested of, and the transfer id will appear for any completed transfers. There will also be a declined/accepted request status, the currency that is expected, request creation time and updated time, along with the memo attached to the request and url/Facebook thread id of the request.
“p2p_transfers” holds much of the same information for instances where the client’s user account has sent money to another Facebook id.
Finally we arrive at the database responsible for handling user messages. The path to this database is:
Unfortunately, you will not find any actual message content within this database. It appears that Facebook stores all of a user’s messages on their servers and then assigns it a “msg_id” within the “messages” table to link specific messages. Thankfully, the table does give you a thread id and a timestamp of the message. The “thread_summaries” table goes one step further and provides the name for all Facebook message threads, the timestamp of the last message in the thread, and the custom name of the group. All “fbid_from_thread_key” entries can be individually placed at the end of the URL “www.facebook.com/messages/t/” to directly open the message thread. *Note, the user must be signed into Facebook to properly view this thread and its content.
“folder_type” is a field entry within the “thread_summaries” table that tells the current state of the message thread. So far, I have uncovered the meanings of the following flags:
- Flag: 1 = Messages are present in the thread
- Flag: 2 = Messages are in the pending state and have not been Accepted or Declined
- Flag: 5 = No messages have been sent or received in this thread
Based on my findings, this database holds all instances when the user account has search for -or viewed the profile of- a Facebook user. The path to this database is:
Tables “blob_storage” and “search_tokens” hold the significant data in this database. By going to “search_tokens“, you can find the name of the Facebook users this host’s account has searched for or visited the profile of, and their associated fbid. You can then go to the “blob_storage” table and look for this same fbid to find the timestamp of last search/profile view.
Unlike the application on mobile devices, the majority of Facebook Messenger’s user content and data is stored in the cloud. I see the main use for this metadata as an initial justification on whether or not a subpoena to Facebook would be useful in an investigation. For example, the efforts of submitting a subpoena would be useless if there were no messages ever sent. It should also be noted that these databases could only be found through a forensic image or by traversing the folder structure on the machine. Since Windows has them on constant call, they will not populate in a certain situations like FTK Imager’s physical drive mount feature.