This phase begins when a request for examination is received. It involves preparing all of the paperwork and forms required to document the chain of custody, ownership information, the device model, its purpose, the information that the requestor is seeking, and so on. The chain of custody refers to the chronological documentation or paper trail, showing the seizure, custody, control, transfer, analysis, and disposition of physical or electronic evidence. From the details submitted by the requestor, it's important to have a clear understanding of the objective for each examination.

Handling the device during seizure is one of the important steps while performing forensic analysis. The evidence is usually transported using anti-static bags which are designed to protect electronic components against damages produced by static electricity. As soon as the device is seized, care should be taken to make sure that our actions don't result in any data modification on the device. At the same time, any opportunity that can aid the investigation should also not be missed.

Following are some of the points that need to be considered while handling an Android device during this phase:

In mobile forensics, it is of critical importance to protect the seized device so that our interaction with the evidence (or for that matter, an attacker's attempt to remotely interact with the device) does not change the evidence. In computer forensics, we have software and hardware write blockers that can perform this function. But in mobile forensics, since we need to interact with the device to pull the data, these write blockers are not of any use. Another important aspect is that we also need to prevent the device from interacting with wireless radio networks. As mentioned earlier, there is a high probability that an attacker can issue remote wipe commands to delete all data, including e-mails, applications, photos, contacts, and other files on the device.

The Android Device Manager (ADM) and several other third-party apps allow the phone to be remotely wiped or locked. This can be done by signing into the Google account that is configured on the mobile device. Using this software, an attacker can also locate the device, which could pose a security risk. For all these reasons, isolating the device from all communication sources is very important.

To isolate the device from a network, we can put the device in Airplane mode if there is access to the device. Airplane mode disables a device's wireless transmission functions, such as cellular radio, Wi-Fi, and Bluetooth. However, this may not always be possible because most of the devices are screen-locked. Also, as Wi-Fi is now available in airplanes, some devices now allow Wi-Fi access in Airplane mode. Hence, an alternate solution would be to use a Faraday bag or RF isolation box, as both effectively block signals to and from the mobile phone. But, one concern with these isolation methods however, is that once they're employed, it is difficult to work with the phone because you cannot see through them to use the touch screen or keypad. For this reason, Faraday tents and rooms exist, as shown in the following screenshot (taken from http://www.technicalprotection.co.uk/), but are very expensive.

Pyramid-shaped Faraday tent

Even after taking all these precautions, certain automatic functions, such as alarms can trigger. If such a situation is encountered, it must be properly documented.

The acquisition phase refers to the extraction of data from the device. Due to the inherent security features of mobile devices, extracting data is not always straight forward. Depending on the operating system, make, and model of the device, the extraction method is decided. The following types of acquisition methods can be used to extract data from a device:

In this phase, different software tools are used to extract the data from the memory image. In addition to these tools, an investigator would also need the help of a hex editor, as tools do not always extract all the data. There is no single tool that can be used in all cases. Hence, examination and analysis requires a sound knowledge of various file systems, file headers, and so on.

Documentation of the examination should be done throughout the process, noting down what was done in each phase. The following points might be documented by an examiner:

The data extracted from the mobile device should be clearly presented to the recipient so that it can be imported into other software for further analysis. In the case of civil or criminal cases, wherever possible, pictures of data, as it existed on the cellular phone, should be collected, as they can be visually compelling to a jury.

Android OS is built on top of the Linux kernel with some architectural changes made by Google. Linux was chosen as it is a portable platform that can be compiled easily on different hardware. The Linux kernel is positioned at the bottom of the software stack and provides a level of abstraction between the device hardware and the upper layers. It also acts as an abstraction layer between the software and hardware present on the device. To understand this better, consider the case of a camera click. What actually happens when you click a photo using the camera button on your mobile device? At some point, the hardware instruction, such as pressing a button, has to be converted to a software instruction such as to take a picture and store it in the gallery. The kernel contains drivers which can facilitate this process. When the camera button click is detected, the instruction goes to the corresponding driver in the kernel, which sends the necessary commands to the camera hardware, similar to what occurs when a key is pressed on a keyboard. In simple terms, the drivers in the kernel control the underlying hardware. As shown in the preceding figure, the kernel contains drivers related to Wi-Fi, Bluetooth, USB, audio, display, and so on.

All the core functionalities of Android, such as process management, memory management, security, and networking, are managed by Linux kernel. Linux is a proven platform when it comes to security and process management. Android has taken leverage of the existing Linux open source OS to build a solid foundation for its ecosystem. Each version of Android has a different version of the underlying Linux kernel. As of September 2014, the current Android version 4.2 is built upon Linux kernel 3.4 or newer, but the specific kernel version depends on the actual Android device and chipset.

On top of Linux kernel are Android's native libraries. It is with the help of these libraries that the device handles different types of data. For example, the media framework library supports the recording and playback of audio, video and picture formats. These libraries are written in the C or C++ programming languages and are specific to a particular hardware. Surface Manager, Media framework, SQLite, WebKit, OpenGL, and so on are some of the most important native libraries.

Android applications are programmed using the Java programming language. The main reason for choosing Java is because it's a well-known language and has a massive developer base. Android wanted to take advantage of this existing developer community, rather than coming up with a new language.

When a Java program is compiled, we get byte code. A Java virtual machine (JVM) (a virtual machine is an application that acts as an operating system) can execute this byte code. In the case of Android, this Java byte code is further converted to Dalvik byte code by the dex compiler. This Dalvik byte code is then fed into Dalvik virtual machine (DVM) which can read and use the code. Thus, the .class files from the Java compiler are converted to .dex files using the dx tool. Dalvik byte code is an optimized byte code suitable for low-memory and low-processing environments. Also, note that JVM's byte code consists of one or more .class files, depending on the number of Java files that are present in an application, but Dalvik byte code is composed of only one .dex file. Each Android application runs its own instance of the DVM. The following diagram shows the difference between the program compilation of a Java application and an Android application.

JVM vs DVM

Since Android 5.0, Dalvik has been replaced by Android Run Time (ART) as the platform default. The ART was introduced in Android 4.4 on an experimental basis. Dalvik uses just-in-time (JIT) compilation which compiles the byte code every time an application is launched. However ART uses ahead-of-time (AOT) compilation by performing it upon the installation of an application. This greatly reduces the mobile device's processor usage, as the overall compilation during the operation of an application is reduced.

Android applications are run and managed with the help of an Android application framework. It is responsible for performing many crucial functions such as resource management, handling calls, and so on. The Android framework includes the following key services, referenced from http://fp.edu.gva.es/av/pluginfile.php/745396/mod_imscp/content/2/1_overview_of_the_android_architecture.html:

The topmost layer in the Android stack consists of applications (called apps) which are programs that users directly interact with. There are two kinds of apps discussed as follows:

The Android operating system is built on top of the Linux kernel. Over the past few years, Linux has evolved into a secure operating system trusted by many corporations across the world for its security. Today, most of the mission critical systems and servers run on Linux because of its security. By having the Linux kernel at the heart of its platform, Android tries to ensure security at the OS level. Also, Android has built a lot of specific code into Linux to include certain features related to mobile environment. With each Android release the kernel version also has changed. The following table shows Android versions and the corresponding Linux kernel version:

The Linux kernel provides Android with the below key security features:

Permission model

Android implements a permission model for individual apps. Applications must declare which permissions (in the manifest file) they require. When the application is installed, as shown in the following screenshot, Android will present the list to the user so that they can view the list to allow installation or not:

Sample permission model in Android

Unlike a desktop environment, this provides an opportunity for the user to know in advance which resources the application is seeking access to. In other words, user permission is a must to access any kind of critical resource on the device. By looking at the requested permission, the user is more aware of the risks involved in installing the application. But most users do not read these and just give away a lot of permissions, exposing the device to malicious activities.

Note

It is not possible to install an Android app with a few or reduced permissions. You can either install the app with all the permissions or decline it.

As mentioned earlier, developers have to mention permissions in a file named AndroidManifest.xml. For example, if the application needs to access the Internet, the permission INTERNET is specified using the following code in the AndroidManifest.xml file:

<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.rohit">

  <uses-permission android:name="android.permission.INTERNET" />

</manifest>

Android permissions are categorized into four levels which are as follows:

Permission Type	Description
Normal	This is the default value. These are low risk permissions and do not pose a risk to other applications, system or user. This permission is automatically granted to the app without asking for user approval during installation.
Dangerous	These are the permissions that can cause harm to the system and other applications. Hence, user approval is necessary during installation.
Signature	These are automatically granted to a requesting app if that app is signed by the same certificate as the one that declared/created the permission. This level is designed to allow apps that are part of a suite, or otherwise related, to share data.
Signature/System	A permission that the system grants only to the applications that are in the Android system image, or that are signed with the same certificate as the application that declared the permission.

Application sandboxing

In order to isolate applications from each other, Android takes advantage of the Linux user-based protection model. In Linux systems, each user is assigned a unique user ID (UID) and users are segregated so that one user does not access the data of another user. All resources under a particular user are run with the same privileges. Similarly, each Android application is assigned a UID and is run as a separate process. What this means is that even if an installed application tries to do something malicious, it can do it only within its context and with the permissions it has.

This application sandboxing is done at the kernel level. The security between applications and the system at the process level is ensured through standard Linux facilities such as user and group IDs that are assigned to applications. This is shown in the following screenshot, referenced from http://www.ibm.com/developerworks/library/x-androidsecurity/.

Two applications on different processes on with different UID's

By default, applications cannot read or access the data of other applications and have limited access to the operating system. If application A tries to read application B's data, for example, then the operating system protects against this because application A does not have the appropriate privileges. Since the application sandbox mechanism is implemented at the kernel level, it applies to both native applications and OS applications. Thus the operating system libraries, application framework, application runtime, and all applications run within the Application Sandbox. Bypassing this sandbox mechanism would require compromising the security of Linux kernel.

Application Signing

All Android apps need to be digitally signed with a certificate before they can be installed on a device. The main purpose of using certificates is to identify the author of an app. These certificates do not need to be signed by a certificate authority and Android apps often use self-signed certificates. The app developer holds the certificate's private key. Using the same private key, the developer can provide updates to his applications and share data between applications. In debug mode, developers can sign the app with a debug certificate generated by the Android SDK tools. You can run and debug an app signed in debug mode but the app cannot be distributed. To distribute an app, the app needs to be signed with your own certificate. The key store and the private key which are used during this process need to be secured by the developer as they are essential to push updates. The following screenshot shows the key store selection option that is displayed while exporting the application:

Keystore selection while exporting Android app

Secure interprocess communication

As discussed in the above sections, sandboxing of the apps is achieved by running apps in different processes with different Linux identities. System services run in separate processes and have more privileges. Thus, in order to organize data and signals between these processes, an interprocess communication (IPC) framework is needed. In Android, this is achieved with the use of the Binder mechanism.

The Binder framework in Android provides the capabilities required to organize all types of communication between various processes. Android application components, such as intents and content providers, are also built on top of this Binder framework. Using this framework, it is possible to perform a variety of actions such as invoking methods on remote objects as if they were local, synchronous and asynchronous method invocation, sending file descriptors across processes, and so on. Let us suppose the application in Process 'A' wants to use certain behavior exposed by a service which runs in Process 'B'. In this case, Process 'A' is the client and Process 'B' is the service. The communication model using Binder is shown in the following diagram:

Binder Communication Model

All communication between the processes using the Binder framework occurs through the /dev/binder Linux kernel driver. The permissions to this device driver are set to world readable and writable. Hence, any application may write to and read from this device driver. All communications between the client and server happen through proxies on the client side and stubs on the server side. The proxies and the stubs are responsible for sending and receiving the data, and the commands, sent over the Binder driver.

Each service (also called a Binder service) exposed using the Binder mechanism is assigned with a token. This token is a 32-bit value and is unique across all processes in the system. A client can start interacting with the service after discovering this value. This is possible with the help of Binder's context manager. Basically, the context manager acts as a name service, providing the handle of a service using the name of this service. In order to get this process working, each service must be registered with the context manager. Thus, a client needs to know only the name of a service to communicate. The name is resolved by the context manager and the client receives the token that is later used for communicating with the service. The Binder driver adds the UID and the PID value of the sender process to each transaction. As discussed earlier, each application in the system has its own UID and this value is used to identify the calling party. The receiver of the call may check the obtained values and decide if the transaction should be completed. Thus, the security is enforced, with the Binder token acting as a security token as it is unique across all processes.

Android is compatible with a wide range of hardware components. Having a Linux kernel made this easy, as Linux supports large variety of hardware. This gives manufacturers a lot of flexibility as they can design based on their requirement, without worrying about compatibility. This poses a significant challenge for forensic analysts during investigations. Thus, understanding the hardware components and device types would greatly help in understanding Android forensics.

Core components

The components present in a device change from one manufacturer to another and also from one model to another. However, there are some components which are found in most mobile devices. The following sections provide an overview of the commonly-found components of an Android device.

Central processing unit

The central processing unit (CPU), also known as processor, is responsible for executing everything that happens on a mobile device. It tells the device what to do and how to do it. Its performance is measured based on the number of tasks it can complete per second, known as a cycle. For example, 1 GHz processor can process one billion cycles per second. The higher the capacity of the processor, the smoother the performance of the phone will be.

When dealing with smart phones, we come across the following terminologies—ARM, x86 (Intel), MIPS, Cortex, A5, A7, or A9. ARM is the name of a company that licenses their architectures (branded Cortex) with different models coming up each year such as the aforementioned A series (A5, A7, and A9). Based on these architectures, chip makers release their own series of chipsets (Snapdragon, Exynos, and so on) which are used in mobile devices. The latest smartphones are powered by dual core, quad core and even octa core processors.

Baseband processor

Smartphones today support a variety of cellular protocols, including GSM, 3G, 4G and 4G LTE. These protocols are complicated and require a large amount of CPU power to process data, generate packets and transmit them to the network provider. To handle this process, smartphones now use a baseband modem which is a separate chip included in smartphones that communicates with the main processor. These baseband modems have their own processor called the baseband processor and run their own operating system. The baseband processor manages several radio control functions such as signal generation, modulation, encoding, as well as frequency shifting. It can also manage the transmission of signals.

The baseband processor is generally located on the same circuit board as the CPU but consists of a separate radio electronics component.

Memory

Android phones, just like normal computers, use two primary types of memory–random access memory (RAM) and read-only memory (ROM). Although most users are familiar with these concepts, there is some confusion when it comes to mobile devices.

RAM is volatile, which means its contents are erased when the power is removed. RAM is very fast to access and is used primarily for the runtime memory of software applications (including the device's operating system and any applications). In other words, it is used by the system to load and execute the OS and other applications. So the number of applications and processes that can be run simultaneously depends on this RAM size.

ROM (commonly referred to as Android ROM) is non-volatile, which means it retains the contents even when the power is off. Android ROM contains the boot loader, OS, all downloaded applications and their data, settings and, so on.

Note that the part of memory that is used for the boot loader is normally locked and can only be changed through a firmware upgrade. The remaining part of the memory is termed by some manufacturers as user memory. The data of each application stored here will not be accessible to other applications. Once this memory gets filled up, the device slows down. Both RAM and Android ROM are manufactured into a single component called as Multichip Package (MCP).

SD Card

The SD card has great significance with respect to mobile forensics because, quite often, data that is stored in these can be vital evidence. Many Android devices have a removable memory card commonly referred to as their Secure Digital (SD) card. This is in contrast to Apple's iPhone which does not have any provision for SD cards. SD cards are non-volatile, which means data is stored in it even when it is powered off. SD cards use flash memory, a type of Electrically Erasable Programmable Read-Only Memory (EEPROM) that is erased and written in large blocks instead of individual bytes. Most of the multimedia data and large files are stored by the apps in SD card. In order to interoperate with other devices, SD cards implement certain communication protocols and specifications.

In some mobile devices, although an SD card interface is present, some portion of the on-board NAND memory (non-volatile) is carved out for creating an emulated SD card. This essentially means the SD card is not removable. Hence, forensic analysts need to check whether they are dealing with the actual SD card or an emulated SD card. SD memory cards come in several different sizes. Mini-SD card and micro-SD card contain the same underlying technology as the original SD memory card, but are smaller in size.

Display

Mobile phone screens have progressed dramatically over the last few years. Below is a brief description of some of the widely used types of mobile screens as described at http://www.in.techradar.com/news/phone-and-communications/mobile-phones/Best-phone-screen-display-tech-explained/articleshow/38997644.cms.

The thin film transistor liquid crystal display (TFT LCD) is the most common type of screen found in mobile phones. These screens have a light underneath them which shines through the pixels to make them visible.

The active-matrix organic light-emitting diode (AMOLED) is a technology based on organic compounds and known for its best image quality while consuming low power. Unlike LCD screens, AMOLED displays don't need a backlight; each pixel produces its own light, so phones using them can potentially be thinner.

Battery

Battery is the lifeblood of a mobile phone and is one of the major concerns with modern smartphones. The more you use the device and its components, the more battery is consumed. The following different types of batteries are used in mobile phones:

• Lithium Ion (Li-ion): These batteries are the most popular batteries used in cell phones as they are light and portable. They are well known for their high energy density and low maintenance. However, they are expensive to manufacture compared to other battery types.
• Lithium Polymer (Li-Polymer): These batteries have all the attributes of a Lithium Ion battery but with ultra slim geometry and simplified packaging. They are the very latest and found only in few mobile devices.
• Nickel Cadmium (NiCd): These batteries are old technology batteries and suffer from memory effect. As a result, the overall capacity and the lifespan of the battery are reduced. In addition to this, NiCd batteries are made from toxic materials that are not environment-friendly.
• Nickel Metal Hydrid (NiMH): These batteries are same as the NiCd batteries, but can contain higher energy and run longer, between 30 and 40 percent. They still suffer from memory effect, but comparatively less than the NiCd batteries. They are widely used in mobile phones and are affordable too.

The battery type can be found by looking at the details present on its body. For example, the following is an image of a Li-ion battery:

Lithium-ion battery

Most SD cards are located behind the battery. During forensic analysis, accessing an SD card would require removing the battery which would power off the device. This can have certain implications which will be discussed in detail in later chapters.

Apart from the components described above, here are some of the other components that are well known:

• Global Positioning System
• Wi-Fi
• Near field communication
• Bluetooth
• Camera
• Keypad
• USB
• Accelerometer and gyroscope
• Speaker
• Microphone

Understanding the boot process of an Android device will help us to understand other forensic techniques which involve interacting with the device at various levels. When an Android device is first powered on, there is a sequence of steps that are executed, helping the device to load necessary firmware, OS, application data, and so on into memory. The following information is compiled from the original post published at http://www.androidenea.com/2009/06/android-boot-process-from-power-on.html.

The sequence of steps involved in Android boot process is as follows:

We will examine each of these steps in detail.

System server

All the core features of the device such as telephony, network, and other important functions, are started by the system server, as shown in the following diagram:

Android boot process: System server

The following core services are started in this process:

• Start Power Manager
• Create Activity Manager
• Start Telephony Registry
• Start Package Manager
• Set Activity Manager Service as System Process
• Start Context Manager
• Start System Context Providers
• Start Battery Service
• Start Alarm Manager
• Start Sensor Service
• Start Window Manager
• Start Bluetooth Service
• Start Mount Service

The system sends a broadcast action called ACTION_BOOT_COMPLETED which informs all the dependent processes that the boot process is complete. After this, the device displays the home screen and is ready to interact with the user. The Android system is now fully operational and is ready to interact with the user.

As explained earlier, several manufacturers use the Android operating system on their devices. Most of these device manufacturers customize the OS based on their hardware and other requirements. Hence, when a new version of Android is released, these device manufacturers have to port their custom software and tweaks to the latest version.

Understanding Android architecture and its security model is crucial to having a proper understanding of Android forensics. The inherent security features in Android OS, such as application sandboxing, permission model, and so on, safeguard Android devices from various threats and also act as an obstacle for forensic experts during investigation. Having gained this knowledge of Android internals, we will discuss more about what type of data is stored on the device and how it is stored, in the next chapter.