Android devices store a lot of sensitive data through the use of apps. Although we have earlier categorized apps as system and user-installed apps, here is a more detailed split:
All of these store different types of data on the device. Application data often contains a wealth of information that is relevant to the investigation. Here is a sample list of possible data that can be found on an Android device:
Data belonging to different applications can be stored either internally or externally. In the case of external storage (SD card), data can be stored in any location. However, in the case of internal storage, the location is predefined. To be specific, internal data of all apps present on the device (either system apps or user-installed apps) is automatically saved in the /data/data
subdirectory, named after the package name. For example, the default Android e-mail app has a package named com.android.email
, and the internal data is stored in /data/data/com.android.email
. We will discuss this in detail in the upcoming sections, but for now, this knowledge will be sufficient to understand the following details.
Android provides developers with certain options to store data to the device. The option that can be used depends on the underlying data that is to be stored. Data that belongs to applications can be stored in one of the following locations:
The following sections provide a clear explanation about each of these options.
This location provides a framework to store key-value pairs of primitive data types in the .xml
format. Primitive data types include boolean, float, int, long, and string. Strings are stored in the
Universal Character Set Transformation Format-8 (UTF-8) format. These files are typically stored in the application's /data/data/<package_name>/shared_prefs
path. For instance, the shared_prefs
folder for the Android e-mail app contains less than six .xml
files, as shown in the following screenshot:
As explained in Chapter 2, Setting Up an Android Forensic Environment, contents of these files can be viewed using the cat
command. The following screenshot shows the contents of the com.android.email_preferences.xml
file:
As seen in the preceding screenshot, the data is stored in name-value pairs. Perhaps in the preceding .xml
file, account_name
, account_password
, recent_messages
are some of the interesting parameters from a forensic point of view. Many applications use shared peferences to store sensitive data, because it is light weight. Thus, they can be a key source of information during a forensic investigation.
The files here are stored in the internal storage. These files are located typically in the application's /data/data
subdirectory. Data stored here is private and cannot be accessed by other applications. Even the device owner is prevented from viewing the files (unless they have root access). However, based on the requirement, the developer can allow other processes to modify and update these files.
The following screenshot shows the details of the apps stored with their package name in the /data/data
directory:
Internal data of each app is stored in their respective folders. For instance, the following screenshot shows the internal storage that belongs to the Twitter app on an Android device:
Usually, the databases
, lib
, shared_pref
, cache
folders are created for most of the applications. The following table provides a brief description of these folders:
Sub directory |
Description |
---|---|
shared_prefs |
XML file of shared preferences |
lib |
Custom library files required by app |
files |
Developer-saved files |
cache |
Files cached by app |
databases |
SQLite and journal files |
Folders other than these are custom folders created by the app developer. The databases
folder is the one that contains crucial data that helps in forensic investigations. As shown in the following screenshot, data in this folder is stored in SQLite files:
This data can be viewed using tools such as SQLite Browser. More details about how to extract data is covered in detail in Chapter 4, Extracting Data Logically from Android Devices.
Files can also be stored by the apps in external storage. External storage can be a removable media, such as an SD card or non-removable storage that comes with the phone. In the case of a removable SD card, data can be used on other devices just by removing the SD card and inserting it in any other device. SD cards are usually formatted with the FAT32 filesystem, but other filesystems, such as EXT3 and EXT4, are also being used increasingly. Unlike internal storage, external storage does not have strict security enforcements. In other words, data stored here is public and can be accessed by other applications, provided the requesting apps have the necessary permissions.
For example, the Twitter app discussed earlier also stores certain files on the SD card in the /Android/data
location. Large files, such as images and videos, loaded by the apps are usually stored in the external storage for faster retrieval.
SQLite is a popular database format present in many mobile systems and is used for structured data storage. SQLite is open source, and unlike many other databases, it is compact and offers lot of functionality. Android supports SQLite through dedicated APIs, and hence, developers can take advantage of it. SQLite databases are a rich source of forensic data. The SQLite files used by the apps are generally stored at /data/data/<ApplicationPackageName>/databases
. For example, in the case of the Android e-mail app, the following screenshot shows the SQLite files present in its databases
folder. We will examine these files in more detail in the upcoming sections. From a forensic point of view, they are highly valuable since they often store a lot of important data handled by the application. The contents of the databases
folder can be seen in the following screenshot:
You can use the network to store and retrieve data on your own web-based services. To do network operations, the classes in the java.net.*
and android.net.*
packages can be used. These packages provide developers with the low-level APIs that are necessary to interact with the network, web servers, and so on.