Mobile device forensics is a branch of digital forensics that 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 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's important to work only on the image file and not on the original device itself.

As explained by Eoghan Casey, in his book Digital Forensics and Investigation, forensic soundness is not just about keeping the 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 its current state.

There is a growing need for mobile forensics due to several reasons, some of which include the following:

• Use of mobile phones to store personal information
• Increased use of mobile phones to perform online activities
• Use of mobile phones in several crimes

Mobile forensics on a particular device is primarily dependent on the underlying operating system. Hence, we have different fields such as Android forensics, iOS 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 of the cases. However, the overall process can be broken down into five phases, as shown in the following diagram:

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 chain of custody, ownership information, device model, purpose, information that the requestor is seeking, and so on. 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 damage 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. The following are some of the points that need to be considered while handling an Android device during this phase:

• With increasing user awareness of security and privacy, most devices now have screen lock enabled. During the time of seizure, if there is a chance (for instance, the phone is recovered unlocked), disable the passcode. Some of the devices don't ask the user to reenter 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. The following are some of the settings that can be considered to achieve this:
  • Enable USB debugging: Enabling this option gives greater access to the device through the Android Debug Bridge (ADB) connection. We are going to cover the ADB in detail in Chapter 2, Setting Up the 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. On newer Android versions starting from 4.2, developer options are hidden by default. To enable them, navigate to Settings | About Phone (or Settings | System | About Phone on Android 8.0 or higher)and tap on the Build number seven times.
  • Enable the Stay Awake setting: Enabling this option and charging the device will make the device stay awake; in other words, it doesn't get locked. In Android devices, this option is usually found under Settings | Developer options, as shown in the following screenshot:

• • 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.

In mobile forensics, it is of crucial 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) doesn't 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 a wireless radio network. As mentioned earlier, there is a high probability that an attacker can issue remote wipe commands to delete all of the data including emails, applications, photos, contacts, and other files on the device.

The Android Device Manager 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. Using this software, an attacker can also locate the device that could pose a security risk. For all of 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 we have access to the device. Airplane mode disables a device's wireless transmission functions such as cellular radio, Wi-Fi, and Bluetooth. However, as Wi-Fi is now available in airplanes, some devices now allow Wi-Fi access in Airplane mode. The following screenshot shows the quick settings available by dragging down the top menu bar from the lock screen:

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. One concern with these isolation methods is that, once they're employed, it is difficult to work with the phone because you cannot see through it to use the touchscreen or keypad. For this reason, Faraday tents and rooms exist, as shown in the following screenshot:

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

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

• Manual acquisition is the simplest of all of the 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 the files and data visible through the normal user interface can be extracted. Data extracted through other methods can also be verified using this. It should be noted that this option can very easily modify data on the device (for instance, opening an unread SMS will mark it as read), so these changes should be documented as thoroughly as possible.
• Logical acquisition, also called logical extraction, generally refers to extracting the files that are present on a logical store such as a file system partition. This involves obtaining data types such as text messages, call history, and pictures from a phone. The logical extraction technique works by using the original equipment manufacturer Applications Programming Interfaces (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 and their versions
  • Social networking app data such as WhatsApp, Skype, and Facebook
• File System acquisition 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 the contents (stored in SQLite files) that are deleted from the device.
• Physical acquisition involves making a bit-for-bit copy of an entire flash storage device, equivalent to a full image of a hard drive. The data extracted using this method is usually in the form of raw data (as a hexadecimal dump) that 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 an original evidence is not altered.

In this phase, different software tools are used to extract the data from the memory image. In addition to the tools, an investigator may also need the help of a hex editor, as tools do not always extract all of 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 are a few points that might be documented by an examiner:

• The date and time the examination started
• The physical condition of the phone
• The status of the phone when received (ON/OFF)
• The make, model, and operating system of the phone
• Pictures of the phone and individual components
• The tools used during the investigation (including the version number)
• 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 are visually compelling to a jury.

With the increased usage of Android devices and the wider array of communication platforms they support, the demand for forensic examination automatically has 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 preserve the original evidence. In other words, the forensic techniques that are applied on a device to extract any information should not alter the data present on the device. However, this is usually not practical with respect to mobile forensics because simply switching on a device might also change certain state variables 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. Hence, there's a chance that data may be altered either intentionally or unintentionally by the forensic analyst. Apart from this, there is a high possibility that an attacker (or the user) can remotely change or delete the contents of 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, and phones cannot always be left powered off during examination.
• The 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 that run on other operating systems including iOS, Blackberry, and Windows, that 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. Based on manufacturer, the approach to acquire forensic artifacts changes. To remain competitive, manufacturers release new models and updates so rapidly that it's hard to keep a 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's no single tool that can work on all the available types of mobile operating systems. Hence, it is crucial for forensic analysts to remain updated on all of the latest changes and techniques, and to understand the underlying concepts in this book so they can succeed when the tools fail.

• 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 implemented on many modern devices prevent law enforcement agencies and forensic analysts from accessing the information on the device. Apple's iPhone encrypts all of the data present on the device by default using hardware keys built into the device. Beginning with Android Nougat, Android forces full disk encryption by default (though it can vary if the OS is modified by the manufacturer). At Google's 2017 I/O conference, they announced that 80% of Android 7.0 Nougat devices were encrypted and 70% used a secure lock screen. These numbers will likely continue to grow as encryption is forced by more manufacturers during the initial setup process. 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 multi-jurisdictional issues, the forensic examiner needs to be aware of the nature of the crime and regional laws.

Before we proceed with the internals of Android forensics, this section will introduce you to Android as an operating system and will cover various fundamental concepts that need to be understood to gain experience in the area of forensics.

Any operating system (desktop or mobile phone) assumes the 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 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 spread in popularity.

The Android operating system consists of a stack of layers running one above the other. Android architecture can be best understood by taking a look at what these layers are and what they do. The following screenshot (courtesy of http://developer.android.com), shows the various layers involved in the Android software stack:

Android architecture is in the form of a software stack comprising kernels, libraries, runtime environment, applications, middleware, and services. Each layer of the stack and elements within each layer, are integrated in a way to provide the optimal execution environment for mobile devices. The following sections focus on different layers of the Android stack, starting at the bottom with the Linux kernel.

The 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 take a photo using the camera button on your mobile device? At some point, the hardware instruction (pressing a button) has to be converted into a software instruction (to take a picture and store it in the gallery). The kernel contains drivers that 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 previous screenshot, the kernel contains drivers related to Wi-Fi, Bluetooth, USB, audio, display, and so on.

All of the core functionalities of Android, such as process management, memory management, security, and networking are managed by the Linux kernel. Linux is a proven platform when it comes to both security and process management. Android has leveraged 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. Currently, Google requires devices shipped with the Android 8.0 Oreo OS to have at least Linux kernel version 4.4.

The hardware abstraction level or HAL allows the higher level, Java API framework, to work with mobile device's hardware with help of standard interfaces. This can be done thanks to multiple library modules, which provide interfaces for different types of hardware components, like Bluetooth or camera.

Since Android 5.0 each application runs in its own process and with its own instance of the Android Runtime (ART). It allows run multiple virtual machines on low-memory devices by executing DEX (Dalvik Executable) files. It's important to note that prior to version 5.0 Dalvik was Android Runtime, so applications developed for Dalvik should work when running with ART.

Many core Android system components and services, including those mentioned earlier, like HAL and ART, are built from native code, so they require native libraries written in C and C++.

Java API framework allows developers to create applications using modular system components and services as building blocks:

• View System allows to build application's user interface, and includes lists, grids, text boxes, buttons, and so on.
• Resource Manager provides access to non-code components of an application, like localized strings, graphics and layout files.
• Notification Manager allows applications to display custom alerts.
• Activity Manager manages the lifecycle as applications, and their back stack - the order in which each activity is opened.
• Content Providers allows applications to access other applications data, and share their own.

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, as discussed here:

• System apps: These are applications that are pre-installed on the phone and are shipped along with the phone. Applications such as default browser, email client, and contacts are examples of system apps. These generally cannot be uninstalled or changed by the user as they are read-only on production devices, though some devices offer the ability to disable these applications. If a system application is disabled, the app and all of its data remain on the device on the system partition, the application icon is simply hidden from the user. These applications can usually be found in the /system partition. Until Android 4.4 Kit Kat, all apps present under /system were treated equally. Beginning in Android 4.4, apps installed in /system/priv-app/ are treated as privileged applications and are granted permissions with protection-level signatureOrSystem to 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 2017 statistics from Statista, there are around 3.5 million Android apps in the Play Store. These apps are present under the /data partition. More information about how security is enforced between them is discussed in the following sections.

Android as a platform has certain features built into the architecture that ensure the security of users, applications, and data. Although they help in protecting the data, these security features sometimes prevent investigators from getting access to necessary data. From a forensic perspective, it is first important to understand the inherent security features so that a clear idea is established about what can be 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 decades, Linux has evolved as a secure operating system trusted by many corporations across the world for 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 the 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 following 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. In older versions of Android, the user was presented with a full list of permissions requested by the application prior to installation.

Newer versions of Android prompt the user the first time each permission is required while the app is in use. This model allows a user to use an app without granting all permissions requested by the application, though functionality may be decreased.

Unlike a desktop environment, this provides an opportunity for the user to know in advance what 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.

As mentioned before, developers have to identify the 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:

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 have access to the data of another. 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. For example, the following screenshot referenced from http://www.ibm.com/developerworks/library/x-androidsecurity/ shows the sandbox mechanism:

By default, applications can't 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, the operating system protects against this because Application A does not have the appropriate user privileges. Since the application sandbox mechanism is implemented at the kernel level, it applies to both native applications and OS applications. Hence, 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 the 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 applications can ask for permissions, and users can grant or deny those permissions. Hence, malware can create havoc on the phones by gaining permissions. Android uses SELinux to enforce mandatory access control that ensures applications work in isolated environments; this includes applications running as root or superuser. Hence, even if a user installs a malicious app, the malware cannot easily access the OS and corrupt the device. SELinux is used to enforce Mandatory Access Control (MAC) over all of the processes, including the ones running with root privileges. SELinux operates on the principle of default denial. Anything that isn't 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 their 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 that 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:

As discussed in the previous 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. Hence, in order to organize data and signals between these processes, an Inter-Process 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, and sending file descriptors across processes. Let's suppose the application in Process A wants to use certain behavior exposed by a Service that 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 screenshot:

All communications between the processes using the Binder framework occur through the Linux kernel driver, /dev/binder. The permissions to this device driver are set to world readable and writable, meaning any application may write to and read from this device driver. All communications between 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 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, which can be done 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. Hence, 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 hence 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. Hence, the security is enforced and the Binder token acts as a security token as it is unique across all of the processes.

Android is compatible with a wide range of hardware components. The Linux kernel made this easy, as Linux supports a 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. Hence, understanding the hardware components and device types will greatly help in understanding Android forensics.

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

The CPU, also known as the 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, a 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 smartphones, we come across the following terminologies: ARM, x86 (Intel), MIPS, Cortex, and A5 or 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 A series mentioned before. Based on these architectures, chip makers release their own series of chipsets (Snapdragon, Exynos, and so on) that are used in mobile devices. Newer 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 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 component.

Android phones, just like normal computers, use two primary types of memory: RAM and ROM. Although most users are familiar with these concepts, there is some confusion, however, when it comes to mobile devices.

RAM stands for Random Access Memory. It is volatile, which means contents are deleted 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. The number of applications and processes that can be run simultaneously depends on this RAM size.

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

Note that the part of memory that is used for the boot loader and Android is normally locked and can only be changed through a firmware upgrade. The remaining part of the memory is termed by some of the 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 often manufactured into a single component known as a Multi-Chip Package (MCP).

The SD card has great significance with respect to mobile forensics because quite often data that is stored on it can be vital evidence and can be accessed even if the device is locked or encrypted. Many Android devices have a removable memory card commonly referred to as a 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 them even when they're 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 an SD card. In order to interoperate with other devices, SD cards implement certain communication protocols and specifications.

In some mobiles, although an SD card interface is present, some portion of the onboard 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 an actual SD card or an emulated SD card. SD memory cards come in several different sizes. The 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. The following is a brief description of some of the widely used types of mobile screens.

• TFT LCD stands for Thin Film Transistor Liquid Crystal Display and is the most common type of screen found in mobile phones. These screens have a light underneath them that shines through the pixels to make them visible.
• AMOLED stands for Active-Matrix Organic Light-Emitting Diode; this 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.

These are described at http://www.in.techradar.com/news/phone-and-communications/mobile-phones/Best-phone-screen-display-tech-explained/articleshow/38997644.cms.

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

• Lithium Ion (Li-Ion) 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-Poly) batteries have all of the attributes of a Lithium Ion battery but with ultra slim geometry and simplified packaging. They are the latest technology and found only in few mobile devices.
• Nickel Cadmium (NiCd) batteries are old technology batteries and suffer from memory effect. As a result, the overall capacity and life span of the battery are reduced. In addition to this, nickel cadmium batteries are made from toxic materials that are not environmentally friendly.
• Nickel Metal Hydride (NiMH) batteries are the same as nickel cadmium batteries, but can contain higher energy and can run for between 30 and 40 percent longer. They still suffer from memory effect but comparatively less than the Nickel Cadmium (NiCd) Batteries. They are widely used in mobile phones and are affordable.

The battery type can be known by looking at the details present on its body.

Often, the SD card is located behind the battery. During forensic analysis, accessing a SD card may require removing the battery, which would power off the device. This can have certain implications that will be discussed in details in later chapters.

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

• Global Positioning System (GPS)
• Wi-Fi
• Near Field Communication (NFC)
• 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 that 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 the necessary firmware, OS, application data, and so on into memory. The following information is compiled from the original post published at https://community.nxp.com/docs/DOC-102546.

The following is the sequence of steps involved in the Android boot process:

1. Boot ROM code execution
2. The bootloader
3. The Linux kernel
4. The init process
5. Zygote and Dalvik
6. 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 have been done. 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 demonstrated in the following screenshot, this phase includes two steps, A and B:

• Step A: When the boot ROM code is executed, it initializes the device hardware and tries to detect the boot media. Hence, the boot ROM code scans until it finds the boot media. This is almost similar to the BIOS function in the boot process of a computer.
• Step B: 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 RAM:

The bootloader is a small program that is executed before the operating system starts to function. Bootloaders are present in desktop computers, laptops, and mobile devices as well. In the Android boot loader, there are two stages—Initial Program Load (IPL) and Second Program Load (SPL). As shown in the following screenshot, this involves the three steps explained here:

• Step A: IPL deals with detecting and setting up the external RAM.
• Step B: Once the external RAM is available, SPL is copied into the RAM and execution is transferred to it. SPL is responsible for loading the Android operating system. It also provides access to other boot modes such as fastboot and recovery. It initiates several hardware components such as the console, display, keyboard, file systems, virtual memory, and other features.
• Step C: SPL tries to look for the Linux kernel. It will load this from boot media and will copy it to the RAM. Once the boot loader is done with this process, it transfers the execution to the kernel:

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 filesystem (rootfs) and provides access to system and user data:

• Step A: When the memory management units and caches have been initialized, the system can use virtual memory and launch user space processes.
• Step B: The kernel will look in the rootfs for the init process and launch it as the initial user space process:

Init is the very first process that starts and is the root process of all other processes:

• Step A: The Init process will look for a script named init.rc. This is a script that describes the system services, filesystem, and other parameters that need to be set up:
  • init process can be found at: <android source>/system/core/init.
  • init.rc can be found at: <android source>/system/core/rootdir/init.rc.

• Step B: The init process will parse the init script and launch the system service processes. At this stage, you will see the Android logo on the device screen:

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 that executes Android applications written in Java.

Zygote facilitates using a shared code across the VM, hence, helping to save the memory and reduce the burden on the system. After this, applications can run by requesting new Dalvik virtual machines. Zygote registers a server socket for zygote connections and preloads certain classes and resources. This zygote loading process has been more clearly explained at https://elinux.org/Android_Zygote_Startup:

• Load ZygoteInitclass: This loads the ZygoteInit class.
  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 a list of classes that need to be preloaded will be executed here. This file can be seen at this location: <Android Source>/frameworks/base.
• preloadResources(): This deals with native themes and layouts and everything that includes the android.R file will be loaded using this method:

All of 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 screenshot:

The following are some of the core services that get 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.

As explained earlier, several manufacturers use Android operating systems on their devices. Most of these device manufacturers customize the OS based on their hardware and other requirements. 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 security model is crucial to having a proper understanding of Android forensics. The inherent security features in Android OS such as application sandboxing and permission models safeguard the device from various threats and pose as an obstacle for forensic experts during an investigation. With this knowledge of Android internals, we will discuss more about what data is stored on the device and how it is stored in the next chapter.