The role that a Digital Forensics Investigator (DFI) is rife with continuous learning opportunities, especially as technology expands and proliferates into every corner of communications, entertainment, and business. As a DFI, we deal with a daily onslaught of new devices. Like cell phones or tablets, many of these devices use common operating systems that we need to be familiar with. Certainly, the Android OS is predominant in the tablet and cell phone industry. Given the predominance of the Android OS in the mobile device market, DFIs will run into Android devices in many investigations. While several models suggest approaches to acquiring data from Android devices, this article introduces four viable methods that the DFI should consider when gathering evidence from Android devices.
A Bit of History of the Android OS
Android’s first commercial release was in September 2008 with version 1.0. Android is the open-source and ‘free to use’ operating system for mobile devices developed by Google. Importantly, early on, Google and other hardware companies formed the “Open Handset Alliance” (OHA) in 2007 to foster and support the growth of Android in the marketplace.
The OHA now consists of 84 hardware companies, including giants like Samsung, HTC, and Motorola (to name a few). This alliance was established to compete with companies who had their own market offerings, such as competitive devices offered by Apple, Microsoft (Windows Phone 10 – which is now reportedly dead to the market), and Blackberry (which has ceased making hardware). Regardless if an OS is defunct or not, the DFI must know about the various versions of multiple operating system platforms, especially if their forensics focus is in a particular realm, such as mobile devices.
READ MORE :
Linux and Android
The current iteration of the Android OS is based on Linux. Keep in mind that “based on Linux” does not mean the usual Linux apps will always run on an Android, and, conversely, the Android apps that you might enjoy (or are familiar with) will not necessarily run on your Linux desktop. But Linux is not Android. Please note that Google selected the Linux kernel, the essential part of the Linux operating system, to clarify the point to manage the hardware chipset processing. Google’s developers wouldn’t have to be concerned with the specifics of how processing occurs on a given set of hardware. This allows their developers to focus on the broader operating system layer and the user interface features of the Android OS.
The Android OS has a substantial market share of the mobile device market, primarily due to its open-source nature. An excess of 328 million Android devices was shipped as of the third quarter in 2016. According to netwmarketshare.com, the Android operating system had the bulk of installations in 2017 — nearly 67% — as of this writing.
As a DFI, we can expect to encounter Android-based hardware in the course of a typical investigation. Due to the open-source nature of the Android OS in conjunction with the varied hardware platforms from Samsung, Motorola, HTC, etc., the variety of combinations between hardware type and OS implementation presents an additional challenge. Consider that Android is currently at version 7.1.1. Yet, each phone manufacturer and mobile device supplier will typically modify the OS for the specific hardware and service offerings, giving an additional layer of complexity for the DFI since the data acquisition approach may vary.
Before we dig deeper into additional attributes of the Android OS that complicate the approach to data acquisition, let’s look at the concept of a ROM version that will be applied to an Android device. As an overview, a ROM (Read Only Memory) program is low-level programming close to the kernel level, and the unique ROM program is often called firmware. If you think in terms of a tablet in contrast to a cell phone, the tablet will have different ROM programming compared to a cell phone, since hardware features between the tablet and cell phone will be different, even if both hardware devices are from the proper hard drive destruction. Complicating the need for more specifics in the ROM program, add in the specific requirements of cell service carriers (Verizon, AT&T, etc.).
While there are commonalities of acquiring data from a cell phone, not all Android devices are equal, especially in light that there are fourteen major Android OS releases on the market (from versions 1.0 to 7.1.1), multiple carriers with model-specific ROMs, and additional countless custom user-complied editions (customer ROMs). The ‘customer compiled editions’ are also model-specific ROMs. In general, the ROM-level updates applied to each wireless device will contain operating and system basic applications that work for a particular hardware device, for a given vendor (for example, your Samsung S7 from Verizon), and particular implementation.
Even though there is no ‘silver bullet’ solution to investigating any Android device, the forensics investigation of an Android device should follow the same general process for the collection of evidence, requiring a structured process and approach that address the investigation, seizure, isolation, acquisition, examination, and analysis, and reporting for any digital evidence. When a request to examine a device is received, the DFI starts with planning and preparation to include the requisite method of acquiring devices, the necessary paperwork to support and document the chain of custody, the development of a purpose statement for the examination, the detailing of the device model (and other specific attributes of the acquired hardware), and a list or description of the information the requestor is seeking to acquire.
Unique Challenges of Acquisition
Mobile devices, including cell phones, tablets, etc., face unique challenges during evidence seizure. Since battery life is limited on mobile devices and it is not typically recommended that a charger be inserted into a device, the isolation stage of evidence gathering can be critical in acquiring the device. Confounding proper acquisition, the cellular data, WiFi connectivity, and Bluetooth connectivity should also be included in the investigator’s focus during acquisition. Android has many security features built into the phone. The lock-screen feature can be set as PIN, password, drawing a pattern, facial recognition, location recognition, trusted-device recognition, and biometrics such as fingerprints. An estimated 70% of users do use some security protection on their phone. Critically, the user may have downloaded available software, which can give them the ability to wipe the phone remotely, complicating acquisition.
It is unlikely during the seizure of the mobile device that the screen will be unlocked. If the device is not locked, the DFI’s examination will be easier because the DFI can promptly change the phone settings. If access is allowed to the cell phone, disable the lock-screen and change the screen timeout to its maximum value (which can be up to 30 minutes for some devices). Remember that of key importance is to isolate the phone from any Internet connections to prevent remote wiping of the device. Place the phone in Airplane mode. Attach an external power supply to the phone after placing it in a static-free bag designed to block radio-frequency signals. Once secure, you should later enable USB debugging, which will allow the Android Debug Bridge (ADB) that can provide good data capture. While it may be important to examine RAM artifacts on a mobile device, this is unlikely to happen.
Acquiring the Android Data
Copying a hard drive from a desktop or laptop computer in a forensically sound manner is trivial compared to the data extraction methods needed for mobile device data acquisition. Generally, DFIs have ready physical access to a hard-drive with no barriers, allowing a hardware copy or software bit stream image to be created. Mobile devices have their data stored inside of the phone in difficult-to-reach places. Extraction of data through the USB port can be a challenge but can be accomplished with care and luck on Android devices.