This post will be covering the use of the Android Debug Bridge (ADB) command-line tool on Linux. Focusing on the extraction of forensically relevant data from mobile devices packaged with the Android Operating System developed by Google.
Android devices have become increasingly popular in recent years amongst consumers for their usability and extendable functionality. From a forensic perspective, this means an Android device could potentially contain a wealth of information relevant to an investigation, including but not limited to:
An interesting fact that always manages to surprise people when I tell them is that Android is based on the Linux kernel and you can even pull up a command-line shell (with standard Linux commands!) using certain applications. Furthermore; forensic examiners can utilise a command-line tool called the Android Debug Bridge (ADB), which enables them to connect with an Android device from a host system, traditionally via a cable connection. As per the official developer page, ADB is capable of; “a variety of device actions, such as installing and debugging apps, and it provides access to a Unix shell that you can use to run a variety of commands on a device”.
Installing the Android Debug Bridge is fairly simple on Linux systems as most of the main distributions have the ‘adb’ tool incorporated into a package within their core repositories. The actual name of the package which contains ADB varies slightly between distributions but they are relatively easy to find. The following provides a list of installation commands for ADB on common Linux systems (accurate at the time of writing):
For Arch and CentOS distributions, please ensure the correct repositories are enabled first, as specified in the brackets above. Some articles/tutorials I came across online mentioned the need for other packages, such as Android-SDK, to be installed as well. From my testing, I was only required to install the single ‘android-tools’ package to be able to utilise the funtionality of ADB, but this may differ depending on the Linux distribution you choose to use.
It is also possible to install ADB on Windows systems and use the tool from a command line just as you would in Linux, but this post will focus solely on using Linux as the host system connecting to the Android device.
Before we get started with ADB, there are a few important preparatory facts worth covering. If we are to assume that an Android device has been seized as part of a forensic investigation, it is vital to ensure that it has been handled properly before any data acquisition with ADB is attempted.
The standard operation when dealing with Android devices is to ensure that they are isolated from the network, preventing any possibility of a remote device wipe. This can be achieved by removing the SIM card, turning airplane mode on and making certain Wi-Fi is disabled. Note that Android devices vary in their methods for enabling airplane mode; some allow a long press of the power button to bring up an options menu, while others may require the handler to enter the device network settings.
Finally, in order to successfully connect the Android device to our host system via a USB cable, the option “USB Debugging” must be allowed in the settings. Generally, this option can be found under; Settings → Developer Options. If you do not see ‘Developer Options’, (hidden by default as of Android version 4.2) you may need to activate it by navigating to; Settings → About Device, and then tapping on ‘Build Number’ 7+ times. These options may not be the same across all Android devices and versions.
Once the necessary preparations are complete, the Android device can be connected to the host system, ready to be queried by ADB. On Linux systems, once the relevant package has been installed, the ADB tool can be accessed through a terminal. Simply typing the command ‘adb’ with no other parameters will bring up a long list of options available for ADB. For the scope of this post, only the following ‘adb’ commands will be used:
Once connected to the host system, the device may prompt you to allow an ‘MTP connection’, as well as verify the “RSA key fingerprint” for the host system before the connection is fully established.
On Linux systems, you can check the output of ‘dmesg’ to ensure that the Android device has been recognized by the host. In my testing, the Android device was assigned “/dev/ttyACM0” (USB communication device), as figure 1 depicts:
Before we start acquiring data with ADB, I will quickly run through the extended options and functionality of the aforementioned ‘adb’ commands. Starting with ‘adb devices’; this command will detect any Android devices that are currently attached to the host, displaying their serial number (which you can cross-check with the ‘dmesg’ output) and will also start the ‘adb’ daemon if not running already. The output from this command is depicted in Figure 2:
The ‘adb shell’ command will execute a remote interactive shell. This allows the user to access the contents of the Android device, where standard Linux commands can be issued. Initially, the command ‘adb shell’ will connect as a non-privileged user named ‘shell’, starting in the root directory (/). To return to the host terminal, simply type ‘exit’ or use ‘CTRL+D’. Figure 3 shows ‘adb shell’ in action, the ‘-d’ option was used to direct the command to the only connected USB device:
The ‘abd backup’ command is commonly utilised when performing a logical extraction of an Android device, known as the ‘ADB Backup Method’. Generally, a standard user might use ADB to backup their device data, which they can restore at a later time. Luckily, forensic examiners can take advantage of this, as ADB provides some very useful options when performing a backup:
From these options, we can form our full ADB backup command, complete with relevant options, depicted in Figure 4:
Since only the single Android device is connected to the host system, there is no need to specify it within the command. However, in cases where multiple Android devices are connected at the same time, you can individualise them using the flag; ‘-s <serial_no>’. The next section (see Logical Acquisition with ADB) will go into more detail regarding logical acquisition of Android devices using the ADB backup command.
The ‘adb pull’ command simply allows the user to copy a file or directory from the device to their host system. This can be very useful for forensic examiners in cases where only specific data stored on the device is needed. There only exists a single parameter for the ADB pull command, yet it is very important that it be used whenever data is copied from the device in a forensic setting:
Bear in mind that access to parts of the Android directory hierarchy will be restricted depending on whether the device is rooted or not (see Rooted VS non-Rooted Android Devices). However, this does not mean that a non-rooted device does not contain forensically relevant data, as there is still a large portion of the file system that can be accessed.
In the example below; the ADB pull command was used to extract a screenshots directory on the Android device, found in the internal storage, with their original timestamps intact:
Finally, the ‘adb install’ command allows for *.apk packages to be installed on the Android device from the host system. Traditionally intended as an easy way for Android developers to easily install their custom applications to a device, forensic examiners can also utilise this feature.
For example, an examiner could install a special *.apk file to the Android device that makes collecting the data stored on the device easier, such as AFLogical. This will be explored further in the next section (see Logical Acquisition with ADB).
Now that we have an understanding of the ADB command-set and what it is capable of, the next step is to perform a logical acquisition of an Android device using the methods discussed previously.
Throughout this section, I shall be using a non-rooted Samsung Galaxy Note 4 with Android version 6.0.1 (Handset) for testing a logical acquisition with ADB. For preparation; I have removed the SIM card, turned on airplane mode, enabled USB debugging and connected the device to my Fedora Linux system.
To start with, the ADB backup method as seen in the previous section will be used to obtain a logical image of the device.
Once the device was detected by ADB, the backup command was executed as demonstrated in Figure 6. Upon running this command, the device prompted for confirmation, after which the ADB full backup took around 10 minutes to complete and resulted in a 721MB file. It should also be noted that if your Android device is encrypted, the backup will not proceed unless it is also encrypted with a passcode set by the examiner.
Once we have generated a backup file of the Android device, it can be imported into a preferred analysis tool to parse the data and present it in a readable format.
Another method of logical acquisition would be to install the ‘AFLogical’ application onto the device with ADB install. This application would gather relevant information into a directory on the device, which can then be copied onto the host system with ADB pull. Installing applications onto Android devices may not always be desirable in a forensic setting due to the manipulation of evidence. However, it should be considered that some commercial mobile forensic hardware/software have the ability to downgrade certain apps to previous versions to make extracting their individual data easier. Additionally, mobile forensic platform XRY can perform logical extractions of supported Android devices using an agent-based approach, whereby it will automatically install the agent on the device and remove it once the acquisition is complete. Therefore, I would not consider the installation of an application to be detrimental to an investigation, but this will of course depend on the individual case itself.
As shown in Figure 7; firstly, ADB was used to install the AFLogical application file onto the connected Android device. The resulting newly-created application, called ‘AFLogical OSE’ was accessed on the device itself, where it presented the following data to be captured:
The ‘Capture’ option was then selected on the AFLogical OSE application and the subsequent data was automatically saved into a directory on the device under ‘/sdcard/forensics/’. The ADB pull command was then utilised to extract the contents of this directory to our host system for further analysis.
The extracted data contained CSV files with call logs and SMS message details, as well as an XML file containing a plethora of device information. The ‘SMS.csv’ file contained sender phone numbers, timestamps, the message itself and the message type. From what I could gather, a type of value ‘1’ means the message was received and value ‘2’ means it was sent by the device owner. The ‘info.xml’ file contained the IMSI, ICCID and IMEI values, low-level device information (board and display numbers) and a list of installed applications, including the location of their data directories.
Browsing the file system of a non-rooted Android device using ADB shell is somewhat restricted due to the user privilege level. For example, on a non-rooted device it is not possible to browse or copy the contents of the “/data/” partition, which contains useful forensic information such as; user information (/data/data/) and application executables (/data/app). Ideally, a forensic examiner would image these file system partitions as part of the investigation, but in many cases this is not possible.
A rooted Android device opens up a wealth of opportunities for a forensic examiner, including physical acquisitions. Rooting is the process of obtaining privileged access (known as ‘root’) to the Android Operating System; allowing access to the entire file system, recovery of all Apps and data, as well as previously deleted data depending on the file system. Rooting is a lot more commonly used on older Android devices running older operating system versions. Some commercial tools, such as the aforementioned XRY, contain the in-built option to temporarily root supported Android devices for data extraction until the next device power down.
Since we have already looked at data acquisition of a non-rooted Android device using ADB, this section will cover a popular ADB forensics technique used on rooted devices. I shall be using a previously rooted Samsung Galaxy Note 10.1 (Tablet) with Android version 5.1.1 to test a physical acquisition of a device partition using ADB. This section will not delve into how the device was rooted, but this information can be easily obtained through search engines.
Following the same steps as the non-rooted device; the tablet was first placed into airplane mode and then USB debugging was enabled using the same process discussed previously. Once the device is connected to our host system, the standard prompts for USB debugging will be displayed on the screen. The device can then be accessed with ADB shell and we can switch to the root user as depicted in Figure 8:
Once we have obtained an ADB shell, it will still be using the standard non-privileged ‘shell’ user. However, since this device is rooted, we can easily log into the root account by running the ‘su’ command. If the SuperSU application is installed on the rooted device, you may receive a prompt to allow root access for ‘adb shell’, simply grant access and you can now browse the entire rooted device. This means we can now extract data from the previously off-limits ‘/data/’ partition, among others.
Interestingly, most Android Operating Systems will have the ‘dd’ (Data Dump/Duplication) command built-in, only usable by privileged accounts. This offers forensic examiners a unique path for extracting the now-accessible data on the device using the ADB shell. Figure 9 shows the ‘dd’ command being used to extract data from the rooted device:
The ‘mount’ command was used to find the names of the block devices associated with the partitions of interest, in this case for ‘/cache/’ and ‘/data/’. For simplicity, the cache partition was imaged using ‘dd’ and the resulting output file stored in ‘/mnt/sdcard/Download/’. This output file was then copied from the device to the host system using ADB pull. This output file containing the extracted data can then be analysed like any other with tools such as those provided in the sleuthkit.
Of course, with a rooted device, there is a lot of potential evidence that can be gathered by forensic examiners, since the whole Android system can be accessed and manipulated. Although not covered in this post, there are many more forensic techniques that can be applied to a rooted Android device. Such techniques may include:
The Android Debug Bridge is an excellent tool for any forensic investigator when dealing with Android devices. This post covered the logical extraction of a non-rooted device using the ADB backup method. As well as the physical extraction of an Android file system partition on a rooted device using both ADB shell and ADB pull commands.
The quantity of data that can be acquired from Android devices is dependent on whether or not the device is rooted before extraction, as both of the methods used in this post vary in their output. Judging whether or not this output is forensically relevant to an investigation is at the discretion of the examiner, as it may not always be necessary to obtain all of the physical data.
Nevertheless, rooting a device will certainly produce more information, as a physical extraction means examiners can potentially recover deleted or hidden data. However, this does not mean that a logical backup extraction is useless, in fact, there is still a lot of information that can be accessed on non-rooted devices. For example, when browsing the file system of the non-rooted Android phone, in addition to the data extracted previously, I could also access/copy the following information:
1. All of the pictures taken with the built-in camera application. Other pictures taken with third-party apps or screenshots are stored elsewhere (/storage/self/primary/Pictures). The ‘camera’ pictures could be extracted from the following location:
2. Any documents or files that had been downloaded onto the device. For example, a file downloaded through a browser on the device will default to the following location:
3. WhatsApp Database files containing *.db.crypt12 files which contain chat messages, as well as a Media folder containing videos, pictures and audio files. The encrypted files can be decrypted using a third-party tool like WhatCrypt. The folders were found in the following locations:
Please bear in mind that the forensic techniques covered in this post, as well as the locations of the data extracted from the devices used, will vary heavily depending on the Android version that the device is running. Newer Android versions such as 7.0 Nougat introduce a lot of new security measures that are presenting a challenge in the Android forensics field. Additionally, as of Android 6.0 Marshmallow, full-disk encryption must be enabled by default, meaning that rooting the device may be a mandatory requirement for certain data.
Thank you for reading and I hope this post has taught you something new!
While doing extra research for the content covered in this post, I found these online resources to be particularly insightful. I have also added a brief description of each one for convenience:
Cyberforensicator — Paper covering open-source tools for Android forensics.
Elcomsoft Post — Useful information about encryption on Android devices.
Gary Kessler Paper — Useful paper covering more forensic methods for rooted Android devices.
InfoSec Institute — A very useful resource covering many aspects of practical Android forensics.
InfoSec Institute — Another resource covering basic ADB commands and SD card imaging.
Magnet Forensics — Recent paper discussing forensic challenges related to Android 7.0.
SANS Whitepaper — Covers more techniques for rooted devices as well as network traffic analysis on Android.
Santoku Linux — A Linux distribution built purely for mobile forensics.
Santoku Linux Post — Tutorial covering the usage of AFLogical.