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.