- Crime Lab
- Crime Scene
- Death Penalty
- Digital Forensic Insider
- Digital Forensics
- Evidence Collection
- Expert Forensic Voices
- Forensic Anthropology
- Forensic Psychology
- Impression Evidence
- Medical Examiner
- Mobile Forensics
- Police Procedure
- Sexual Assault Investigations
- Witness Testimony
Mobile device forensics is a branch of digital forensics that relates to the recovery of digital evidence or data from a mobile device under forensically sound conditions (http://en.wikipedia.org/wiki/Mobile_device_forensics).
As discussed in Chapter 1, mobile devices today are a different beast. They are used for all kind of communications, transactions, and tasks. The following kinds of personal information are typically found on a smartphone: contacts, photos, calendars, notes, SMS, MMS, e-mail, browser history, GPS locations, social media information, financial data, passwords, and so forth. You get the idea! If we have a device that is evidence in a legal investigation or needs to be analyzed for a security investigation, it can provide a goldmine of information, provided one knows how to extract this information carefully. Our focus in this chapter is on extracting as much information as we can, rather than “extracting under forensically correct” conditions. The latter is a topic for a different book.
To perform forensics on Android devices, it is important to understand the Android system. We have already covered Android architecture and the security model. In this chapter, we will walk through file system specifics (directories, files, mount points, and file systems). We need to understand how, where, and what type of data is stored on the device, to perform the actual extraction of useful information. Data can be stored on a file system as files, in application/system-specific formats, or in SQLite DBs.
Android File System
In this section, we will review the Android File System by looking at various mount points (Figure 8.1) on a typical Android device, as well as its directory structure, which might be of interest to us for gathering useful information.
Figure 8.1: Mount Points on an Android Device
Figure 8.2: Directory Structure of an Android Device (ADB)
Let’s look at various partitions on an Android device and analyze relevant ones for their directory structures. Typing “adb shell mount” (Figure 8.2) shows mounted file systems on the device, whereas typing “adb shell cat /proc/filesystems” gives us a listing of supported file systems (see Figure 8.3). Table 8.1 shows various partitions and their descriptions.
Figure 8.3: File Systems on an Android Device
Table 8.1: Overview of Mounted File Systems on an Android Device
Android supports quite a few file systems (based on the Linux kernel). One can obtain a list of supported file systems by typing “cat /proc/filesystems” at the command line. As can be seen from Figure 8.3, the nodev entry next to file system indicates that there is no physical device associated with that particular file system, thus making a nodev virtual file system. Note that Android supports ext2, ext3, and ext4 file systems (used by Linux systems) and the vfat file system used by Windows-based systems. Since it is targeted for mobile devices, Android supports YAFFS and YAFFS2 file systems (needed to support NAND chips used in these devices). Table 8.2 provides more information on these file systems.
Table 8.2: Different Kinds of File Systems on Android
Let’s look at the directory structure of a typical Android device. One can access the file system through the command line (adb) or through Eclipse/DDMS (Figure 8.4). There are three main directories that are of interest to us: /system, /sdcard, and /data. As mentioned earlier, /system holds most of the Operating System (OS) files, including system applications, libraries, fonts, executables, and so forth. /sdcard is a soft link to the /mnt/sdcard and refers to the SD card on the device. /data directory contains user data. More specifically, each application has an entry in /data/app/, and user data resides in /data/data/. On the device itself, one would not be able to access the /data folder, as it is accessible only to the system user (as opposed to the shell user). We use an emulator to demonstrate the contents of the /data directory. Since user data for an application resides in /data/data/, it is important that only that application has access to that particular folder. This is accomplished through user permissions (each application has its own UID, and only that UID/user has permissions to access the folder). Table 8.3 provides a summary of important files/directories on Android that an application might interact with. We will cover the structure of the /data/data/ folder later in this chapter.
Figure 8.4: Directory Structure of an Android Device (DDMS)
Table 8.3: Important Files/Directories on Android
Android Application Data
In this section, we cover how applications can store persistent data and also review the contents of the /data/data folder and how they can be used to retrieve useful information.
Android provides multiple options whereby an application can save persistent data (depending on the application’s needs). Table 8.4 shows various options for storing data.
Table 8.4: Overview of Storage Options for Android Applications
Now that we have covered options available to an application for storing data, let’s examine some real-world applications and analyze their /data/data/ directory. We installed the Seesmic application, which allows you to connect you to multiple social media accounts. Figure 8.5 shows subdirectories of the /data/data/com.seesmic application. The Seesmic application has three folders: databases, libs, and shared_prefs. Accessing the /data/data directory on the device would not be possible, as permissions are restricted to the system owner (as opposed to the shell user). One has to either root the phone or image it to be able to obtain access to the contents of this directory.
Figure 8.5: Directories Inside /data/data for the Seesmic Application
Looking at the folder structure suggests that the application might be storing some data in SQLite databases, as well as in the form of Shared Preferences. It might be worthwhile to investigate these files and see if we can gather more information. Browsing to the shared_prefs directory and performing “cat” on one of the XML files, we get information used by the application (key-value pairs). Please note Figure 8.6. One of the key-value figures defined in the file is req_token_secret, and another is req_token. If application developers are not careful, they might store all kinds of sensitive information in here (including passwords in plaintext).
Figure 8.6: Contents of One of the XML Files in the shared_prefs Folder
We have noted that there is a database folder inside /data/data/com.seesmic. Browsing to the folder, we find a database named twitter.db, indicating that the user of the device had a twitter account. Let’s see if we can get details of the twitter account from the database. This can be done through the sqlite3 command line utility. As seen from Figure 8.7, we can understand the schema of the database and then query different tables to retrieve information.
Figure 8.7: Contents of SQLite DB
Rooting Android Devices
Android, by default, comes with a restricted set of permissions for its user. These restrictions have been carefully designed to prevent malicious applications (and users) to circumvent controls provided by the Android security model. They are also sometimes used to prevent a particular functionality from being accessed or changed (e.g., tethering or installing proxy, and so forth). Rooting an Android device can be useful when we need to analyze a device. When we log on to a shell (through adb shell), the UID of the user is “shell.” We can’t really access directories such as /data, as we don’t have sufficient permission. Thus, we need to elevate our privileges to super user. The process of getting these is called rooting. Typically, a vulnerability in the system when exploited successfully allows us to become a super user. One can download corresponding <version>Break. apk files from the Web and root a device. In the following, we walk a user through rooting the Android Froyo 2.2.
1. Determine the version of the Android OS running on your device. This can be found by going to “Settings” -> “About Phone.” This should give you the Android and kernel version details.
2. Connecting through the adb shell and executing the “ID” command should show you as a “shell” user (UID = 2000 [shell]).
3. Download Gingerbreak.apk (given you are running Android Froyo 2.2.2, Honeycomb, Gingerbread).
4. Enable USB Debugging.
5. Install Gingerbreak on the phone by executing the following command “adb install gingerbreak.apk.”
6. Open the Gingerbreak application on the phone. This will install the super user application.
7. Now, connect to the device using the command line (adb) and execute the su command. You should now be rooted on the device and be able to browse to directories such as /data/data.
It is sometimes useful to create an image of the Android device and analyze it using various tools available on your workstation. This is especially true in the case of an investigation where the original file system needs to be preserved for evidence/future reference. We may also not want to work directly off the device but, rather, a copy of it for investigation/analysis. Below are instructions for imaging an Android device:
1. Download mkfs.yaffs2 and copy it onto the SD card connected to your device, through the following command: adb push mkfs.yaffs2 /mnt/sdcard/tmp
2. Open adb shell and change to root user (su). Change the permission of /mnt/sdcard/tmp/yaffs2 file to 755 chmod 755 /mnt/sdcard/tmp/mkfs.yaffs2
3. Create an image of the Android device by executing the command that follows. This will create data.img, which will contain the image of the Android device /mnt/sdcard/tmp/mkfs.yaffs2 data.img.
4. Pull data onto your workstation by using the “pull” command from adb shell adb pull /mnt/sdcard/tmp/data.img
Now that you have the device image on your workstation, you can use tools such as yaffey to analyze the image, browse through different directories, review files, and so forth. Yaffey is available at the following URL: http://code.google.com/p/yaffey/.
Accessing Application Databases
As discussed earlier in the chapter, applications can store structured data in SQLite databases. Each application can create DB files under the /data/ data/<appname>/databases folder. Although we can root a device and analyze databases through the sqlite3 command line utility, it is convenient to image the device and analyze it using workstation tools such as yaffey and the SQLite browser. Below are steps to retrieve the database files and view them in SQLite:
1. Root and image the /data partition on your phone (as shown in the previous section).
2. Download and install SQLite browser from http://sqlitebrowser. sourceforge.net/index.html.
3. Browse to the SQL database of an application through yaffey and pull the application database onto your workstation or execute the command below: adb pull /mnt/sdcard/tmp/twitter.db.
4. Open twitter.db in the SQLlite database browser.
Extracting Data from Android Devices
In the previous section, we showed how to root an Android device and obtain useful information stored on it. While we can certainly do this piece-by-piece, there are tools that can help us to do this more efficiently—for example, the MOBILedit application. On a rooted device, MOBILedit allows us to extract all kinds of information from the device (contact information, SMS messages, databases from different applications, and so forth). Below are steps to extract information from a device using this application:
1. Make sure your device is rooted (see previous sections in this chapter).
2. Download and install the MOBILedit application.
3. Input your device’s IP address into the MOBLedit application.
4. Once the application connects to your device, you can download/view information, including call data, SMS messages, photos, and so forth.
5. You can also download data from the MobilEdit and use the techniques described in the previous sections to do a further analysis analysis.
In this chapter, we described different file systems used by Android. We reviewed relevant partitions and mount points that would be of interest to security professionals to analyze a device or applications. We reviewed different mechanisms through which an application can store persistent data (databases, preferences, files, and so forth) and how to obtain and analyze these bits. We covered steps to root an Android device (though this will be different from release to release) and how to use third-party applications to retrieve data from Android devices.