Mobile forensics is a branch of digital forensics which is evolving in today's digital era. Android forensics deals with extracting, recovering and analyzing the data present on an Android device through various techniques. However, it is important to have a clear understanding of the platform and other fundamentals before we dive in and find out how to extract data. In this chapter, we will cover the following topics:
Mobile forensics
Mobile forensics approach
Android architecture
Android security
Android hardware components
Android boot process
The world today is experiencing technological innovation like never before. This growth is almost exponential in the field of mobile devices. Gartner, a technology research and advisory firm, in their forecasts published in June 2014, predicted that mobile phone shipments are soon set to break 2.4 billion units. This statistic alone reflects the unprecedented growth of mobile devices. Mobile phones have not only increased in number but also have become more sophisticated in terms of functionality.
The following screenshot referenced from http://en.wikipedia.org/wiki/File:Mobile_phone_subscribers_1997-2014_ITU.svg shows the increase in graph of mobile phone subscribers per 100 inhabitants from 1997 to 2014:
Mobile phone subscribers per 100 inhabitants from 1997-2014
Within mobile phones, smart phones are very much becoming the norm. Improvements in the computing power and data storage of these devices enable us to perform a wide range of activities. We are increasingly becoming dependent on these mobile devices for most of our activities. Apart from performing routine tasks such as making calls, sending messages, and so on, these devices also support other activities such as sending e-mails, surfing the Internet, recording videos, creating and storing documents, identifying locations with Global Positioning System (GPS) services, managing business tasks, and much more. In other words, mobile devices are now a repository of sensitive personal information, containing a wealth of user data. Quite often, the data sitting on a device is more valuable than the device itself. For instance, calls made from a device could be valuable information for law enforcement agencies. The fact that mobile forensics played a crucial role in solving high-profile cases, such as the 2010 Times Square car bombing attempt and the Boston marathon bombings, reaffirms the increasing role of mobile forensics in many government and law enforcement cases.
Mobile device forensics is a branch of digital forensics which deals with extracting, recovering and analyzing digital evidence or data from a mobile device under forensically sound conditions. Simply put, it deals with accessing the data stored on devices which includes SMS, contacts, call records, photos, videos, documents, application files, browsing history and so on, and also recovering data deleted from devices using various forensic techniques. It is important that the process of recovering or accessing details from a device is forensically sound, if it has to be admitted in a court of law and to maintain the integrity of the evidence. If the evidence has to be admitted in a court of law, it is important that the original device is not tampered with.
Note
The term forensically sound is often used in the digital forensics community to clarify the correct use of a particular forensic technology or methodology. Mobile forensics, especially Android forensics, is evolving fast, owing to the fact that it has a market share of 84 percent (as per market research firm IDC).
As explained by Eoghan Casey in his book Digital Forensics and Investigation, forensic soundness is not just about keeping original evidence unaltered. Even the routine task of acquiring data from a hard drive using a hardware write-blocker may cause alterations (for example, making a hidden area of the hard drive accessible) on the drive. One of the keys to forensic soundness is documentation. Documenting how the device is handled from the beginning is very important. Hence, an investigation can be considered forensically sound if the acquisition process preserves the original data and its authenticity and integrity can be validated. Evidence integrity checks ensure that the evidence has not been tampered with from the time it was collected. Integrity checks are done by comparing the digital fingerprint of the evidence taken at the time of collection with the digital fingerprint of the evidence in current state.
There is a growing need for mobile forensics due to several reasons. Some of the prominent reasons are:
Use of mobile phones to store personal information
Increased use of mobile phones to perform online activity
Use of mobile phones in several crimes
Mobile forensics on a particular device is primarily dependent on the underlying operating systems. Thus we have different fields such as Android forensics, iOS forensics, Blackberry forensics, and so on.
Once the data is extracted from a device, different methods of analysis are used based on the underlying case. As each investigation is distinct, it is not possible to have a single definitive procedure for all cases. However, the overall process can be broken into five phases as shown in the following diagram:
Phases in mobile forensics
The following section discusses each phase in detail:
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:
With increasing user awareness on security and privacy, most of the devices now have screen lock enabled. During the time of seizure, if there is a chance to do so, disable the passcode. Some devices do not ask the user to re-enter the passcode while disabling the lock screen option.
If the device is unlocked, try to change the settings of the device to allow greater access to the device. Some of the settings that can be considered to achieve this are as follows:
Enable USB debugging: Enabling this option gives greater access to the device through Android debug bridge (adb) connection. We are going to cover adb connection in detail in Chapter 2, Setting Up Android Forensic Environment. This will greatly aid the forensic investigator during the data extraction process. In Android devices, this option is usually found under Settings | Developer options, as shown in the following screenshot. In later Android versions starting from 4.2, the developer options are hidden by default. To enable them, navigate to Settings | About Phone and tap on Build number 7 times.
Enable stay awake setting: Enabling this option and charging the device will make the device stay awake which means that, it doesn't get locked. In Android devices, this option is usually found under Settings | Developer options, as shown in the following screenshot:
Stay awake and USB debugging options
Increase Screen timeout: This is the time for which the device will be active once it is unlocked. Depending on the device model, this time can be set up to 30 minutes. In most devices, it can be accessed under Settings | Display | Screen timeout, as shown in the following screenshot:
Note
Please note that the location to access this item changes across different versions and models of Android phones.
Screen timeout option on an Android device
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.
Tip
Have you thought about remote wipe options that do not require internet access? Mobile Device Management (MDM) software provides a remote wipe feature just by sending an SMS. Isolating the device from all communication options is crucial.
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:
Manual acquisition: This is the simplest of all acquisition methods. The examiner uses the user interface of the phone to browse and investigate. No special tools or techniques are required here, but the limitation is that only those files and data that are visible through a normal user interface can be extracted. Data extracted through other methods can also be verified using this.
Logical acquisition: This is also called logical extraction. This generally refers to extracting the files that are present on a logical store such as a filesystem partition. This involves obtaining data types, such as text messages, call history, pictures and so on, from a phone. The logical extraction technique works by using the original equipment manufacturer's APIs for synchronizing the phone's contents with a computer. This technique usually involves extracting the following evidence:
Call Logs
SMS
MMS
Browser history
People
Contact methods
Contacts extensions
Contacts groups
Contacts phones
Contacts setting
External image media (metadata)
External image thumbnail media (metadata)
External media, audio, and misc. (metadata)
External videos (meta data)
MMSParts (includes full images sent via MMS)
Location details (GPS data)
Internet activity
Organizations
List of all applications installed, along with their version
Social networking apps data such as WhatsApp, Skype, Facebook, and so on.
Filesystem acquisition: This is a logical procedure and generally refers to the extraction of a full file system from a mobile device. File system acquisition can sometimes help in recovering deleted contents (stored in SQLite files) that are deleted from the device.
Physical acquisition: This involves making a bit-by-bit copy of the entire flash memory. The data extracted using this method is usually in the form of raw data (as a hexadecimal dump), which can then be further parsed to obtain file system information or human readable data. Since all investigations are performed on this image, this process also ensures that original evidence is not altered.
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:
Date and time the examination started
Physical condition of the phone
The status of the phone when received (ON/OFF)
Make, model, and operating system of the phone
Pictures of the phone and individual components
Tools used during the investigation
Data documented during the examination
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.
With the increased usage of Android devices and the wider array of communication platforms that they support, demand for forensic examination has automatically grown. While working with mobile devices, forensic analysts face a number of challenges. The following points shed light on some of the mobile forensics challenges faced today:
Preventing data alteration on the device: One of the fundamental rules to remember in forensics is to not modify the evidence. In other words, the forensic techniques that are applied to a device to extract any information, should not alter the data present on the device. But this is not practical with respect to mobile forensics because simply switching ON a device might also change certain state variables that are present on the device. With mobile devices, background processes always run and a sudden transition from one state to another can result in the loss or modification of data. Therefore, there is a chance that data may be altered either intentionally or unintentionally by the forensic analyst. In addition to this, there is a high possibility that an attacker can remotely change or delete the content present on the device. As mobile phones use different communication channels (cellular, Wi-Fi, Bluetooth, infrared, and so on) the possibility of communicating through them should be eliminated. Features such as remote data wiping would enable an attacker to remotely wipe the entire device just by sending an SMS or by simply pressing a button that sends a wipe request to the Android device. Unlike computer forensics, mobile device forensics requires more than just isolating the device from the network.
Wide range of operating systems and device models: The wide range of mobile operating systems available in the market makes the life of a forensic analyst more difficult. Although Android is the most dominant operating system in the mobile world, there are mobile devices which run on other operating systems, including iOS, Blackberry, Windows, and so on, which are often encountered during investigations. Also for a given operating system, there are millions of mobile devices available that differ in OS versions, hardware, and various other features. For example, within the Android operating system, there are around 10 versions, and for each version, there are different customizations made by different manufacturers. Based on the manufacturer, the approach to acquiring forensic artifacts changes. To remain competitive, manufacturers release new models and updates so rapidly that it's hard to keep track of all of them. Sometimes within the same operating system the data storage options and file structures also change, making it even more difficult. There is no single tool that can work on all the available types of mobile operating systems. Therefore, it is crucial for forensic analysts to remain updated on all the latest changes and techniques.
Inherent security features: As the concept of "privacy" is increasingly gaining importance, mobile manufacturers are moving towards implementing robust security controls on devices, which complicates the process of gaining access to the data. For example, if the device is passcode protected, the forensic investigator has to first find a way to bypass the passcode. Similarly, full disk encryption mechanisms that are implemented on some of the latest devices prevent law enforcement agencies and forensic analysts from accessing the information on the device. Apple's iPhone encrypts all the data present on the device by default, using hardware keys built into the device. It is very difficult for an examiner to break these encryption mechanisms using techniques such as brute force.
Legal issues: Mobile devices can be involved in crimes that span across the globe and can cross geographical boundaries. In order to tackle these multijurisdictional issues, the forensic examiner needs to be aware of the nature of the crime and also regional laws.
Before we proceed with the internals of Android forensics, this section introduces you to Android as an operating system and covers various fundamental concepts that need to be understood to gain experience in the area of forensics.
Any operating system (desktop or mobile) takes responsibility for managing the resources of the system and provides a way for applications to talk to hardware or physical components in order to accomplish certain tasks. The Android operating system is no different. It powers mobile phones, manages memory and processes, enforces security, takes care of networking issues, and so on. Android is open source and most of the code is released under the Apache 2.0 license. Practically, this means that mobile phone device manufacturers can access it freely, modify it, and use the software according to the requirements of any device. This is one of the primary reasons for its popularity.
The Android operating system consists of a stack of layers running on top of each other. Android architecture can be best understood by taking a look at what these layers are and what they do. The following diagram referenced from http://elinux.org/images/c/c2/Android-system-architecture.jpg, shows the various layers involved in the Android software stack:
Android architecture
Android architecture is in the form of a software stack comprising kernel, libraries, runtime environment, applications, middleware, and services. Each layer of the stack (and also elements within each layer) is integrated in a way that provides an optimal execution environment for mobile devices. The following sections focus on the different layers of the Android stack, starting at the bottom with the Linux kernel.
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.
Note
This later prompted Oracle to file a case in court against Google claiming that its copyrights and patents were violated. But the jury finally declared that Google did not infringe on Oracle's patents, and the trial judge ruled that the structure of the Java APIs used by Google was not copyrightable.
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:
Activity manager: This service controls all aspects of the application lifecycle and activity stack.
Content providers: This service allows applications to publish and share data with other applications.
Resource manager: This service provides access to non-code embedded resources such as strings, color settings, and user interface layouts.
Notifications manager: This service allows applications to display alerts and notifications to the user.
View system: This service provides an extensible set of views used to create application user interfaces.
Package manager: The system by which applications are able to find out information about other applications currently installed on the device.
Telephony manager: This service provides information to the application about the telephony services available on the device such as status and subscriber information.
Location manager: This service provides access to the location services allowing an application to receive updates about location changes.
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:
System apps: These are applications that are pre-installed on the phone and are shipped along with the phone. Applications such as default browser, e-mail client, contacts, and so on, are examples for system apps. These cannot be uninstalled or changed by the user as they are read-only on production devices. These are usually present mounted in the
/systemdirectory. Until Android 4.4, all apps present under/systemwere treated equally. But from Android 4.4 onward, apps installed in/system/priv-app/are treated as privileged applications and are granted permissions with protection level signatureOrSystem to only privileged apps.User-installed apps: These are the applications that are downloaded and installed by the user from various distribution platforms such as Google Play. Google Play is the official app store for the Android operating system, where users can browse and download the applications. Based on December 2014 statistics from AppBrain, there are around 1,418,453 Android apps in the Play Store. These apps are presently found in the
/datadirectory. More information about how security is enforced between them is discussed in the following sections.
Android as a platform has certain features built into its architecture that ensure the security of users, applications, and data. Although they help in protecting the data, these security features sometimes prevent investigators from gaining access to necessary data. Hence, from a forensic perspective, it is first important to understand the inherent security features so that a clear idea is established about what can or cannot be accessed under normal circumstances. The security features and offerings that are incorporated aim to achieve three things:
To protect user data
To protect system resources
To make sure that one application cannot access the data of another application
The next sections provide an overview of the key security features in the Android operating system.
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:
|
Android Version |
Linux Kernel Version |
|---|---|
|
1.0 |
2.6.25 |
|
1.5 |
2.6.27 |
|
1.6 |
2.6.29 |
|
2.2 |
2.6.32 |
|
2.3 |
2.6.35 |
|
3.0 |
2.6.36 |
|
4.0 |
3.0.1 |
|
4.1 |
3.0.31 |
|
4.2 |
3.4.0 |
|
4.3 |
3.4.39 |
|
4.4 |
3.8 |
Linux kernel used in various Android versions
The Linux kernel provides Android with the below key security features:
A user-based permissions model
Process isolation
Extensible mechanism for secure IPC
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. |
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.
Starting with Android 4.3, Security-Enhanced Linux (SELinux) is supported by the Android security model. Android security is based on discretionary access control, which means that applications can ask for permissions, and users can grant or deny those permissions. Thus, malware can create havoc on phones by gaining permissions. But SE Android uses mandatory access control (MAC) which ensures that applications work in isolated environments. Hence, even if a user installs a malware app, the malware cannot access the OS and corrupt the device. SELinux is used to enforce MAC over all processes, including the ones running with root privileges.
SELinux operates on the principle of default denial. Anything that is not explicitly allowed is denied. SELinux can operate in one of two global modes:
permissive mode, in which permission denials are logged but not enforced, and
enforcing mode, in which denials are both logged and enforced. As per Google's documentation, in the Android 5.0 Lollipop release, Android moves to full enforcement of SELinux. This builds upon the permissive release of 4.3 and the partial enforcement of 4.4. In short, Android is shifting from enforcement on a limited set of crucial domains (installd, netd, vold and zygote) to everything (more than 60 domains).
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
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.
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.
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.
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.
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).
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.
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 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:
Boot ROM code execution
The boot loader
The Linux kernel
The init process
Zygote and Dalvik
The system server
We will examine each of these steps in detail.
Before the device is powered on, the device CPU will be in a state where no initializations will have taken place. Once the Android device is powered on, execution starts with the boot ROM code. This boot ROM code is specific to the CPU the device is using. As shown in the the following diagram, this phase includes two steps:
When, boot ROM code is executed, it initializes the device hardware and tries to detect the boot media. Thus, the boot ROM code scans till it finds the boot media. This is similar to the BIOS function in the boot process of a computer.
Once the boot sequence is established, the initial boot loader is copied to the internal RAM. After this, the execution shifts to the code loaded into the RAM.
Android boot process: Boot ROM code execution
The boot loader is a piece of program that is executed before the operating system starts to function. Boot loaders are present in desktop computers, laptops and mobile devices as well. In an Android boot loader, there are two stages—initial program load (IPL) and second program load (SPL). As shown in the following diagram, this involves three steps explained as follows:
IPL deals with detecting and setting up external RAM.
Once external RAM is available, the SPL is copied into the RAM and execution is transferred to it. The SPL is responsible for loading the Android operating system. It also provides access to other boot modes such as fastboot, recovery, and so on. It initiates several hardware components such as console, display, keyboard and file systems, virtual memory, and other features.
After this, the SPL tries to look for the Linux kernel. It will load this from the boot media and copy it to the RAM. Once the boot loader is done with this process, it transfers the execution to the kernel.
Android boot process: The boot loader
The Linux kernel is the heart of the Android operating system and is responsible for process management, memory management, and enforcing security on the device. After the kernel is loaded, it mounts the root file system (rootfs) and provides access to system and user data, as described in the following steps:
The init is the very first process that starts and is the root process of all other processes.
The init process will look for a script named
init.rcthat describes the system services, file system, and any other parameters that need to be set up.The
initprocess can be found at:<android source>/system/core/init..The
init.rcfile can be found in source tree at<android source>/system/core/rootdir/init.rc.Tip
More details about the Android file hierarchy will be covered in Chapter 3, Understanding Data Storage on Android Devices.
The
initprocess will parse theinit.rcscript and launch the system service processes. At this stage, you will see the Android logo on the device screen.
Android boot process: The init process
Zygote is one of the first init processes created after the device boots. It initializes the Dalvik virtual machine and tries to create multiple instances to support each android process. As discussed in earlier sections, the Dalvik virtual machine is the virtual machine which executes Android applications written in Java.
Zygote facilitates using a shared code across the VM, thus helping to save the memory and reduce the burden on the system. After this, applications can run by requesting new Dalvik virtual machines that each one runs in. Zygote registers a server socket for zygote connections, and also preloads certain classes and resources. This Zygote loading process has been more clearly explained at http://www.kpbird.com/2012/11/in-depth-android-boot-sequence-process.html. This is also explained as follows:
Load ZygoteInitclass: This class loads theZygoteInitclass. Source Code:<Android Source>/frameworks/base/core/java/com/android/internal/os/ZygoteInit.java.registerZygoteSocket(): This registers a server socket for zygote command connections.preloadClasses(): This is a simple text file containing the list of classes that need to be preloaded will be executed here. This file can be seen at<Android Source>/frameworks/base.preloadResources(): This deals with native themes and layouts. Everything that includes theandroid.Rfile will be loaded using this method.
Android boot process: The Zygote
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.
