Pages

Friday, November 21, 2014

Some artifacts in the /data/system/ directory

A few nice artifacts


All blog posts to date
Introduction Acquisition Analysis
Introduction Imaging an Android Device Examining the image
Picking a Toolkit Live imaging an Android device Some hidden artifacts in a physical image
Why not load ClockworkMod or TWRP to image a device? Using Autopsy to examine an Android image
Identifying your Userdata Partition Some artifacts in the /data/system/ directory
Some non-root methods to learn about a device Viewing SQLite Databases
A quick note on imaging newer Android devices Facebook for Android Artifacts
Using Windows to Live Image an Android device Interpreting data from apps
Obtaining all files in the data partition without a physical image Waze for Android forensics
Magnet Forensics App Simulator
App Reversing Other Topics
Reverse Engineering an Android App File The differences between a physical image and a logical extraction
Fun with Apktool Dirty cow
Deep dive into an app Imaging and examining an Android car stereo
Unpacking boot and recovery kernels
MTPwn
Introduction

In a previous post, I demonstrated how to image an Android device and then I made two different posts on how to examine the image.  You can see by examining an image that your device is divided into partitions.

Android devices are partitioned, and the following partitions should be in every image:

  • data - the partition with user-related data, which may also include a directory representing an SD card
  • system - pre-loaded apps, libraries, settings, images, and more
  • boot - the Android system kernel
  • recovery - the Android recovery kernel

And other devices may have all kinds of other partitions.  Try imaging a Galaxy S4 and see how many partitions FTK Imager and Autopsy recognize.

As you may have reasoned, the data partition is where an investigator will be examining the most.  This partition contains data about the user.  Within the data partition will be a few directories of note:

  • data - data related to installed apps, including the user's text message history, web browsing history, call logs, contacts, Facebook messages, calendar events, etc.
  • app - apps which the user installed.  This directory will contain the actual apk files which the user downloaded or sideloaded and installed
  • media - older devices may not have this directory, but newer Android devices will contain the media directory, which represents an SD card.  This directory will contain photos, unless there is an external SD card in the device, and may contain all kinds of user files.  This directory also includes files the user downloaded using a web browser.

As you also may have reasoned, the data directory is where an investigator will be spending a lot of time.

This post focuses on another directory within the data partition.  This directory is system, which contains more information about user behavior.  This directory contains useful logs that the user is unlikely aware of yet can say a good amount about the user.  I will detail just a few artifacts.  There are far more artifacts than these, but I will detail some useful ones and can field questions about others.

To get to these artifacts, you'll either need to have an image of the device, or you will  need root access.  Non-root users cannot access these files through a shell.


List of installed apps
Check out the file /data/system/packages.xml.  (Note:  The device I used here runs Lollipop, or a newer version of Android.  The packages.xml may contain different data for older versions of the operating system, like Gingerbread and older.)  This file contains a list of all apps installed, plus some extra information about each app.  Here is the entry for ES File Explorer in my /data/system/packages.xml file.

<package name="com.estrongs.android.pop" codePath="/data/app/com.estrongs.android.pop-2.apk" nativeLibraryPath="/data/app-lib/com.estrongs.android.pop-2" flags="4767300" ft="146b6659890" it="14346b1705b" ut="146b665d076" version="212" userId="10109" installer="com.android.vending">
    <sigs count="1">
        <cert index="77" key="3082(bunch of hex ...)733f" />
    </sigs>
    <perms>
        <item name="android.permission.READ_EXTERNAL_STORAGE" />
        <item name="com.android.launcher.permission.INSTALL_SHORTCUT" />
        <item name="android.permission.CHANGE_WIFI_MULTICAST_STATE" />
        <item name="android.permission.SET_WALLPAPER" />
        <item name="android.permission.WRITE_EXTERNAL_STORAGE" />
        <item name="android.permission.ACCESS_WIFI_STATE" />
        <item name="com.android.launcher.permission.UNINSTALL_SHORTCUT" />
        <item name="android.permission.READ_PHONE_STATE" />
        <item name="android.permission.ACCESS_SUPERUSER" />
        <item name="android.permission.BLUETOOTH" />
        <item name="android.permission.INTERNET" />
        <item name="android.permission.WRITE_SETTINGS" />
        <item name="android.permission.CHANGE_WIFI_STATE" />
        <item name="android.permission.VIBRATE" />
        <item name="android.permission.BLUETOOTH_ADMIN" />
        <item name="android.permission.WAKE_LOCK" />
        <item name="android.permission.ACCESS_NETWORK_STATE" />
    </perms>
    <signing-keyset identifier="3" />
    <signing-keyset identifier="5" />
    <signing-keyset identifier="4" />
    <signing-keyset identifier="2" />
    <signing-keyset identifier="1" />
    <signing-keyset identifier="6" />
</package>

There will be such an entry for every installed app.  I'll go over what some of these entries mean.

  • package name="com.estrongs.android.pop" - This is the package name of the app.  Here is quick documentation on what the package name is. 
  • codePath="/data/app/com.estrongs.android.pop-2.apk" - This is the path to the APK, or the application install file.  If you need to investigate an app, or reverse engineer the app, here is the file you should be examining.
  • nativeLibraryPath="/data/app-lib/com.estrongs.android.pop-2" - This is the path to a directory containing native libraries which the app uses.  In my phone, the directory /data/app-lib/com.estrongs.android.pop-2 contains two native library files.  If you are interested in reversing native executables, you can reverse these files and examine.
  • <item name="android.permission.READ_EXTERNAL_STORAGE" (and a bunch more) /> - There are a bunch of entries of Android permissions.  This app contains 17 permissions, ranging from reading and writing to external storage to Internet access to using the vibrate function.  If you ever browse through the packages.xml file and find an app with an extraordinary amount of permissions or some permissions that just seem odd, like a game that has the permission to send and receive SMS, then you might want to take a close look.

The packages.xml file is a useful file to see what all files the user has installed on the device.  This file also lists associated permissions with each app which can be a useful hint to malicious apps, and each app entry also includes a path to the actual APK file so you can reverse the app if you need.


Log of last usage of an app Next, look at the file usagestats/usage-history.xml.  This file contains log entries with the last time a user used an app.  Here is the entry in my phone for the Chrome app.  Note: I imaged my phone in late October 2014.

<pkg name="com.android.chrome">
    <comp name="com.google.android.apps.chrome.ChromeTabbedActivity" lrt="1414545913713" />
    <comp name="com.google.android.apps.chrome.bookmark.ManageBookmarkActivity" lrt="1398440159237" />
    <comp name="com.google.android.apps.chrome.ManageBookmarkActivity" lrt="1391453561436" />
    <comp name="com.google.android.apps.chrome.Main" lrt="1414545745091" />
</pkg>


What you see here are four different activities within the app. Activities, in Android lingo, are basically different screens allowing for user activity.  Each activity above also contains a timestamp in Epoch time of the last time the activity ran.  Here's a handy writeup on Epoch time, in case you are unfamiliar, and here is a nifty Epoch converter.

Based on the log, here is the last time I used each of these activities before I imaged the phone:

  • com.google.android.apps.chrome.ChromeTabbedActivity: Wed, 29 Oct 2014 01:25:13 GMT
  • com.google.android.apps.chrome.bookmark.ManageBookmarkActivity: Fri, 25 Apr 2014 15:35:59 GMT
  • com.google.android.apps.chrome.ManageBookmarkActivity: Mon, 03 Feb 2014 18:52:41 GMT
  • com.google.android.apps.chrome.Main: Wed, 29 Oct 2014 01:22:25 GMT

Apparently I do not use bookmarks very often!  Note, these timestamps are all in GMT.  You'll need to convert this timestamp to the local timezone.
The usage-history.xml file is a useful file.  It will not let the investigator know the complete history for an app, but it will indicate the last time each activity was used.  If a user indicates that he/she has never used an app yet the usage-history.xml file indicates that the app was used yesterday, you may want to investigate some.
Database of accounts on the device Finally, open the file system/users/0/accounts.db in a SQLite browser.  (I intend to at some point do a post on SQLite databases but have not yet.  If you're not sure how to open a SQLite database file, contact me and I'll help you out.)  Here's what the "accounts" table of my accounts.db file looks like in a SQLite browser (with personal information blacked out):


This database file includes a table called "accounts", which is a list of accounts associated with the device.  The three accounts seen above are a Google account, a Facebook account, and a LinkedIn account.

Each entry has three columns of data: name, type, and password.  Name is the username associated with the account, and in all three cases above the username is an email address.  The type is the account provider.  You can see above that my accounts are clearly Google, Facebook, and LinkedIn.  And the password contains a hashed version of the password.  The actual password in plaintext is not included.

This file is a useful list to see what services a user frequently uses.  I can't say I am on LinkedIn all that frequently, but I use Google and Facebook frequently.


Other artifacts There are all kinds of other useful artifacts - battery stats, process states, network states, the wallpaper image, and some more.  If you are an Android enthusiast, I highly enjoy exploring the /data/system directory further.  You may find some more useful artifacts.

Finally, do you have some insights into useful artifacts in /data/system?  If so, comment below.  I'd be happy to field questions and I also am always eager to learn more.

Summary
  • The /data/system directory includes useful logs about the user and user behavior
  • The file /data/system/packages.xml contains a list of installed apps including the APK path and a list of permissions
  • The file /data/system/usagestats/usage-history.xml contains logs of the last time a user used an app
  • The file /data/system/users/0/accounts.db contains a list of accounts and associated usernames and service providers
Questions, comments, suggestions, or experiences?  Leave a comment below, or send me an email.

3 comments:

  1. Will usage history still show the last time someone used an app EVEN if they uninstalled it afterwards?

    ReplyDelete
    Replies
    1. Good question. I'm pretty sure the uninstall process will clear out usage history stats.

      Delete
  2. Some Artifacts In The /Data/System/ Directory >>>>> Download Now

    >>>>> Download Full

    Some Artifacts In The /Data/System/ Directory >>>>> Download LINK

    >>>>> Download Now

    Some Artifacts In The /Data/System/ Directory >>>>> Download Full

    >>>>> Download LINK po

    ReplyDelete