Book Image

Learning Android Forensics - Second Edition

By : Oleg Skulkin, Donnie Tindall, Rohit Tamma
Book Image

Learning Android Forensics - Second Edition

By: Oleg Skulkin, Donnie Tindall, Rohit Tamma

Overview of this book

Many forensic examiners rely on commercial, push-button tools to retrieve and analyze data, even though there is no tool that does either of these jobs perfectly. Learning Android Forensics will introduce you to the most up-to-date Android platform and its architecture, and provide a high-level overview of what Android forensics entails. You will understand how data is stored on Android devices and how to set up a digital forensic examination environment. As you make your way through the chapters, you will work through various physical and logical techniques to extract data from devices in order to obtain forensic evidence. You will also learn how to recover deleted data and forensically analyze application data with the help of various open source and commercial tools. In the concluding chapters, you will explore malware analysis so that you’ll be able to investigate cybersecurity incidents involving Android malware. By the end of this book, you will have a complete understanding of the Android forensic process, you will have explored open source and commercial forensic tools, and will have basic skills of Android malware identification and analysis.
Table of Contents (12 chapters)

Android architecture

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

Hardware abstraction level

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.

Android Runtime

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.

Native C/C++ Libraries

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

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 application layer

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.