Supporting the Unsupported: Locating and Analyzing Information from New Mobile Apps
By Christopher Vance, Magnet Forensics Trainer. Read more about Christopher in this Trainer profile.
There are currently millions of applications on the iOS App Store and Google Play marketplace. With millions of third party applications available to people, there’s a limitless source of applications that could appear in forensic investigations. Due to the sheer number of sources, there’s no way that a single forensic tool could support every application on the market. Because of this fact, it’s important for examiners to be able to locate and analyze this information on their own at times. In the AX300 Advanced Mobile Forensics class, Magnet Forensics instructors hope to be able to impart this knowledge to others and to help examiners develop a quick, efficient, and repeatable workflow for dealing with new artifacts.
As a brief example of part of the file system analysis, application identification, and artifact creation that goes into the four-day AX300 course, this blog will take a look at an unsupported application and show a piece of the process. In our example, we’ll be looking at the application “Anti-Chat” on iOS. The application boasts an “anonymous” chat room experience with over 1.6 million users. From my personal days as an analyst who worked a lot of ICAC cases, this seemed like the exact type of application that would end up on my desk. But how anonymous is it? Can users that the local user has chatted with be tracked? Are chats as “self-destructive” as the developers claim? Let’s find out.
The first thing examiners have to do is find the installed applications. This lets them “gameplan” what they want to go after. To do this, we’ll use the “Info.plist” file that’s part of any iTunes style backup. This particular application happens to be called “com.NH.Secret-Messenger” in the file system. It’s not quite as easy as looking for the bundle ID in Android, but can be done by comparing records in the info.plist and manifest.plist files.
Figure 1: The Info.plist file listing all installed applications.
Figure 2: The manifest.plist file showing that “Anti Chat.app” comes back to “com.NH.Secret-Messenger”
Now that we know the target application is “com.NH.Secret-Messenger” we can search for this in the file system to see what’s returned. A folder is returned called “AppDomain-com.NH.Secret-Messenger” which is where we’ll target our investigation. Inside an AppDomain folder, it’s common to find a “Library” and a “Documents” folder. Both of these are good places to search for data. We’ll start in the Library folder and look for a subfolder called Preferences. In the preferences folder, there’s usually a binary formatted property list file that is a good source of information. In our case, the com.NH.Secret-Messenger.plist file found in AppDomain-com.NH.Secret-Messenger/Library/Preferences/. This binary formatted property list file stores some user information in this case such as the user’s number they used, how many times they launched the app, when they last launched the app, and their password (stored in plain text no less.)
Figure 3: Binary plist storing user information. This “login” field shows the number the user entered in Anti Chat. It’s not “verified” by the service however.
The thing to search for is any sqlite databases that may store these “self-destructing” messages. Buried within the folder AppDomain-com.NH.Secret-Messenger/Library/Application Support/Stores there’s a SQLite database called Secret_Messegner.sqlite. Within this database, there are multiple tables which look promising. The ZUSERS table stores users that the local user has interacted with. An “ObjectID” ties to the ZMESSAGES table that stores the messages from users and timestamps. Locally sent messages are also identified thanks to the ObjectID item. The ZTOPCHATS table stores the chat rooms and direct messages that the user has joined as well.
Figures 5-7: Screenshots of three major tables in the database that contain relevant records.
Now that we’ve identified what records are worth capturing in this case, we’d like to not have to do this process manually again. In this case, we can capture these records using a custom artifact. On the plus side, once the artifact is built, it will work for every case we find this application on as long as it’s running on the same platform. AXIOM allows for a user to build a quick custom artifact in XML that can pull this data into AXIOM Examine for tagging and reporting.
After building an artifact targeting the users, room names, and messages, the data can be rescanned using AXIOM. And the best part? The next time we run across this same app, our work is already done!
So what are the steps to reproduce this easily?
- Identify installed applications.
- Locate applications of interest.
- Search by name.
- Identify key storage files. (SQLite DBS / PLists / XML Files)
- Decide what data to extract.
In our AX300 course, not only will instructors teach the detailed way of walking through this workflow, but students will also learn how to make other custom artifacts that will make the process even easier!