Android devices vary based on the device and manufacturers, making forensic acquisition and analysis challenging if you’re relying on tools that simply provide support for one file system, manufacturer, or version of Android. The commercial vendors have made drastic headway on forensic acquisition of these devices, but examiners need to be prepared to manually dig for artifacts once the file system is extracted for analysis. Examiners must also be prepared for limited support on Android Pie v9+ devices. Don’t assume you will only be dealing with EXT. Don’t assume your version of Android will be supported. Don’t expect to extract a ton of data unless you get at least a full file system extraction. Expect the unexpected and be ready to interact with the device in order to extract the most data. We hope this course prepares you with an arsenal of methods to tackle the Android devices that land on your desk.
User data may be stored internally and externally on Android devices. The internally stored data is saved to the NAND flash memory. The NAND is non-volatile memory, which means the data is not lost when the smartphone loses power. The NAND stores the bootloader, operating system, and user data. Although application data may be open and present in RAM, it is only temporarily stored in RAM while in use. The actual application data is stored on the NAND flash memory, or the SD card inserted in the device. A RAM capture was possible on older Android devices that had root access. We have hope that tools like Cellebrite Premium and GrayKey will eventually support this type of extraction.
Android devices use NAND flash memory for internal storage. The operating system is based on variations of the Linux kernel’s long-term support (LTS) branches (depending on the device) and the software stack has evolved with versions. Further details on the operating system version and software stack can be found on https://en.wikipedia.org/wiki/Android_(operating_system)#Linux_kernel.
Historically, Android Runtime (ART) used ahead-of-time (AOT) technology, which boosted performance. Marshmallow (v6) uses the Linux kernel 3.18.10 and ART, while Nougat (v7) leverages Linux kernel 4.4.1 and ART.1 With the introduction of Oreo (v8), Google for the first time specified a requirement for the Linux kernel being used, requiring that at least Linux kernel 4.4 be used. Android Pie (v9) runs on Linux versions 4.4, 4.9, or 4.14, where the version is dependent upon the device. Android 10, 11, and 12 have continually progressed and the Android OS Wiki mentioned in the previous slides has detailed descriptions for each. As new versions of Android are released, it’s important to understand the underlying components.
Some devices may use SELinux (Security-Enhanced Linux), a version of Linux developed by the National Security Agency that was designed to push the security control to the kernel level.2 SELinux protects the device from breaches or unauthorized access via applications on the device. The PrivatOS, which runs on the Blackphone and Blackphone II, offers additional restrictions to protect the user’s data and offer full disk encryption.3
The four major file systems are discussed in the upcoming slides. Keep in mind that, although only four major file systems exist, multiple file systems function on Android devices. Essentially, if it can be mounted in Linux and run on an Android, you have yourself another file system. Android has always been known for being open source and making the code available for anyone to modify and use via the Apache license. You will find that newer devices are becoming more restrictive but remain open source. Most of the artifacts we discuss in this section will be SQLite databases and XML files. Just like Linux systems, Android sandboxes the applications to protect the user. The applications are sandboxed at the kernel level and are assigned a unique user ID (UID) to keep track of the applications being run. These files are some of the easiest to examine, as the formats are consistent and multiple tools will provide access to the data contained within the files. The skills you learned earlier in Section 1 will assist you with your Android examinations. The hard part is obtaining an acquisition method that is capable of extracting these mentioned files.
The introduction of Lollipop (v5) was an eye opener for Android. New levels of security and encryption were introduced. The changes in Lollipop and current versions introduced are discussed throughout this section. One major change that was first introduced with new devices (with Lollipop installed with shipment) was that the user does not have to dive into the system settings on the device to enable encryption, as it is often offered the minute the user first powers on a device during initial setup. For devices to be fully encrypted, the device must have enough memory and AES processing power for the encryption to stick. Currently, we haven’t seen full disk encryption causing us issues on too many devices, even on the devices running Android 7, due to the decryption support available by tools like Cellebrite and services like CAS (Cellebrite Advanced Services). While Android versions 9–12 prove to be more difficult to acquire due to security patches, we are chugging along and trying to get crafty with our techniques to access user data.
For devices with file-based encryption, we can only expect it to cause further issues during acquisition and analysis. The various encryption options on smartphones are covered in this section and throughout the rest of this course. Our goal is to prepare you, so you are ready to handle the tough issues that end up on your desk!
References:
[1] Tamma, Skulkin, Mahalik, and Bommisetty, Practical Mobile Forensics, Third Edition (Birmingham, UK: Packt, 2018).
[2] https://for585.com/linux (SELinux)
[3] https://for585.com/privat (Silent Circle)
From a user perspective, we function from the tip of the pyramid and dive down. The device functions from the base up. Overall, all the architectural components are important, whether you realize it or not. This course teaches you that the outliers of data will sometimes be the missing link for which you were looking.
The user space is comprised of the Applications layer. This includes the primary phone applications like Contacts, Home, Phone, Browser, and all user functionality features.
The system is comprised of the framework, libraries, and the Linux kernel. A comprehensive breakdown of these components is defined in detail in Practical Mobile Forensics, Second Edition. The framework and libraries are essentially the glue that ties everything together and can be explained as follows:
| Application Framework: Activity Manager Window Manager Content Providers View System Package Manager Telephony Manager Resource Manager Location Manager Notification Manager Libraries: Surface Manager OpenGL SGL Media Framework FreeType SSL SQLite WebKit Libc |
Android Runtime: Core Libraries Dalvik Virtual Machine (DVM) Linux Kernel controls the smartphone drivers and power. This includes:1 Display Driver Camera Driver Flash Memory Driver Binder Driver Keypad Driver Wi-Fi Driver Audio Drivers Power Management [1] Andrew Hoog, Android Forensics: Investigation, Analysis and Mobile Security for Google Android (Waltham, MA: Elsevier, 2011). |
The Linux kernel area is often overlooked by examiners, but it may contain pertinent information. It is recommended to acquire all “spaces” of the device and narrow your analytical search from there. It’s best to start with everything and limit the scope instead of starting with just the user space and realizing you need the kernel and framework data.