Mobile Forensics: Discovering the Undiscovered

Recently Joshua Hickman (@josh_hickman1) author of the Binary Hick released the latest in his series of WELL DOCUMENTED images for the public, and Android 10 image. A week later, he shared an amazing post on Android’s Digital Wellbeing timeline. Every day forensic researchers, like Josh, are finding, documenting and sharing the new artifacts they find — which is awesome. So how do you know when there is something new that might be helpful on a case?

One of the things I like to focus on as a forensic examiner, adjunct professor, and researcher is finding the undiscovered — particularly in mobile examinations. We all know that forensic tools cannot be relied upon to find every piece of evidence from every type of application on every operating system for a myriad of reasons. These reasons include the constant change due to the sheer number of applications, app updates, the time it takes for commercial tools to respond, the fact that your bad actor may be using an “unsupported app” intentionally.

In this blog series, I would like to share the method I have use over the years to find new artifacts and share them. This method can work regardless of your experience. In addition to sharing this methodology and showing how you can apply this to research using all Open Source and free methods, I will also show some features in Magnet AXIOM that aid in helping me with the process, often times faster than without the features. Regardless of if you use AXIOM or not, there is value to be found in this series. This is a process I have been using since before I worked for Magnet Forensics and before AXIOM existed.

So, what is this methodology? Well there are five steps to the process – Discover, Test, Find, Parse, and Script. I have been using this process since I was an examiner in a lab where my job was to find artifacts that were missed by commercial tools. So, lets delve into the first step: Discover.

Discover on Android

The first part of the Discover set is to have a Physical of File System mobile image.  This is important because with a logical image, you are likely to have only data that is supported by the file system. If possible, even after taking a logical image

Once you have your image, you will want to look at it. So, let’s look at the image contributed to the community by Josh Hickman. The image and accompanying documentation can be found here. Josh has done an incredible job sharing a host of images with the community over the last year.  One of the best things about Josh’s images are that they are well documented. Because this image is available to everyone and well documented, it means you can follow along with the process as well.  If in your search, you identify a new artifact, I hope you will share it with the community.

One of the first things I want to know about a device is what applications are installed.  That way I can compare what was found to the tool(s) that I have already ran against the image. For Android there are some key areas to look this includes packages.list (data\system\packages.list), packages.xml (data\system\packages.xml), and  com.vending.Android (data\data\com.android.vending\databases\library.db). 

Packages.list provides a listing of the applications, but little additional information. If you just want to quickly see what is installed on the device, this is a great place to start. You can compare the third-party applications to what was parsed on your device to quickly see if there are applications of potential interest. By looking at packages.list we can see apps such as Instagram, MeWe, Wire, and Kik.  

However, I tend to look towards packages.xml to get more information to determine what apps may be of interest that weren’t parsed by my commercial tool. Why? Because packages.xml shows me not only the name of the package, but what permissions it has and access. Looking at com.wire and com.mewe I see access to things of interest such as com.google.android.c2dm.permission.RECEIVE. This allows the application to receive messages.  This is typical of communication applications. A source that can be used to understand the permissions you see here is the Android Permissions website.

Com.android.vending is a commonly referenced source.  The library.db of com.android.vending appears to have interesting information in the database including the user, application, and time of download.  This is the app that tracks your purchases. However, for users who have changed devices, it can track applications that existed on the previous device and not the device under examination. Also be careful in trusting the attribution to the account. I have done some testing that shows that when two accounts are on the same device, sometimes an app purchase is attributed to the first account (0) when purchased by a different account (i.e. 11). But what is valuable here is this may be a source of discovering applications that have been deleted. There is a great presentation on discovering deleted apps from Alexis Brignoni (@AlexisBrignoni) and Christopher Vance (@cScottVance) from the 2019 SANS DFIR Summit, Tracking traces of deleted applications:

Another place to look is at the files in the data/data directory itself. This contains the folder structure for all the apps. This will only show apps that have data stored here. We will talk about where to find stored data in future parts of this series.  Here is what this looks like in the fil system.

Okay, so those locations talk about applications installed on the device or purchased by the user, but what about apps they have been using? That could be of absolute value in discovering what apps you may want to dig deeper into. For Android there are several artifacts that can help us do that on Android devices includes usagestats (\data\system\usagestats\0\…\daily, \monthly, \ weekly, \yearly),  usage-history (\data\system\usagestats\usage-history.xml), Batterystats (\data\data\com.google.android.gms\shared_prefs\Baterystats. Xml  and /system/baterystats-daily.xml), recent_images (data\system_ce\0\recent_tasks), and snapshots (\data\system_ce\0\shorcut_service\snapshots). For more information on these artifacts, check out my presentation on this research I shared at the SANS DFIR Summit in 2018 and can be found here:

Alexis Brignoni has incorporated these artifacts and others in his Open Source tool ALEAPP. Alexis also has incorporated support for Android 10 usagestats with the help of additional research from with Yogesh Khatri (@SwiftForensics) regarding the protobuf format that is now used in usagestats in Android 10. All these artifacts will help you see the applications that have been being used, some recently, as well as some understanding of frequency. You can then quickly see if some of those artifacts are not being parsed by your forensics tool.

You may have quickly noticed that each of these files does not list a common name for an app, but rather it lists the package name, which appears to look like a reverse domain name. So how do you figure out what application you see in each one of these sources is? The simple answer is: you Google it. The package name is used in the play store as part of the URL for the application. I was curious as to what com.wire was as I hadn’t seen it before. Typically, what I will do is a search for the package name plus the words “play store”. Instantly, I see that it is a secure messaging app. A quick check and, while my forensic tool parsed many chat applications, it did not parse this application.

My next step is to look at the features of the app on the Google Play store.  The link above will bring me to the Google Play store and show me all the features of the app. It is important to read the description and about the features, so you know some of the features for when you get to the next phase of Test. From the description, I learn that there are private and group conversations, you can share files, documents, and links, and you can set up guest rooms. The application utilizes end-to-end encryption and that it is available on a variety of Operating Systems. I also see from the pictures that group conversations can be video conferences, that you can share locations, and that you can leave voice attachments. These are all features that can be tested. Sometimes reading reviews also exposes features to test including ones not in the description and bugs in the platform that may be of interest, such as a location sent from an iOS device doesn’t appear on an Android device but will Android to Android. I didn’t see this for this app but have in previous analysis of other applications.

Additional methods to get data that has been deleted.

Using AXIOM to Find New Apps of Interest

So now you have discovered your app of interest. However, I do want to share some examples of ways that you can use Magnet AXIOM to surface discoverable more quickly. First, there are several artifacts that can help with this including Google Play Installed Applications, Google Play Application Details, Google Play Searches and Installed Applications. You can quickly compare these parsed results to the applications that were parsed by the forensic tool.

AXIOM has artifacts for Android Usage History and Android Power Usage that cover the usage artifacts and battery artifacts. AXIOM places activity related to recent tasks in an artifact called Application Activity.  This is useful because it will also include the screenshots as applicable that were saved as part of the recent_taks artifact. This could include otherwise hard to find activity such as Google Pay, an application download, or a chat message. All of these can be found by looking at this artifact on Josh Hickman’s Android 10 image.

Additionally, you can use the Dynamic App Finder (DAF) when processing in AXIOM to find SQLite databases of potential interest. DAF looks for databases that aren’t already parsed related to conversations, geolocation data, website URLs, and person identifiers.  Once the search is complete you can view and configure what was recovered and turn it into an instant artifact. DAF showed me several potential interesting pieces of data from com.wire. I was able to see this as soon as processing was completed, before I started hunting for unsupported apps. More details related to Dynamic App Finder are available in this quick video from Martin Barrow.

While the result wasn’t perfect, it did quickly find some chat data that my tool wouldn’t have otherwise parsed. In the result below I can see that there were messages and calls sent using Wire.  In the next few parts of the series we will discuss the next steps to parsing this content.

Now that you have identified an app of interest, what next? This series will continue with posts explaining how to Test, Find, Parse, and Script for data of applications you have deemed potentially valuable. Want to know more?  Check out this upcoming webinar, Android Application Artifacts from Tarah Melton on March 31. Look for future methodology posts for parsing unsupported apps!

Let me know if you have questions by reaching out to me via email jessica.hyde@magnetforensics.com.