Google implemented ADB backup functionality, beginning in Android 4.0 Ice Cream Sandwich. This allows users (and forensic examiners) to backup application data to a local computer over ADB. This process does not require root, and is therefore highly useful for forensic purposes. However, it does not acquire every application installed on the device. When a developer makes a new app, it is set to allow backups by default, but this can be changed by the developer. In practice, it seems the vast majority of developers leave the default setting, which means that backups do capture most third-party applications. Unfortunately, most Google applications disable backups; full application data from apps such as Gmail and Google Maps will not be included.
The format of the ADB backup command is:
adb backup [-f <file>] [-apk|-noapk] [-obb|-noobb] [-shared|-noshared] [-all] [-system|-nosystem] [<packages...>]
The flags are as follows:
-f: Names the path for the output file. If not specified, defaults tobackup.abin present working directory.[-apk|noapk]: Choose whether or not to back up the.apkfile. Defaults to-noapk.[-obb|-noobb]: Choose whether or not to back up.obb(APK expansion) files. Defaults to-noobb.[-shared|-noshared]: Choose whether or not to back up data from shared storage and the SD card. Defaults to-noshared.[-all]: Include all applications for which backups are enabled.[-system|-nosystem]: Choose whether or not to include system applications. Defaults to-system.[<packages>]: Explicitly name application packages to be backed up. Not needed if using-allor-shared.
An example ADB backup command to capture all possible application data would be:
adb backup –f C:/Users/Cases/Case_0001/backup.ab –shared –all
Alternatively, an example ADB backup command to capture a specific application's data would be:
adb backup –f C:/Users/Cases/Case_0001/facebook.ab com.facebook.katana
You should see something like:
When performing a backup, the user must approve the backup on the device. This means that backups cannot be performed without bypassing screen locks:
Accepting the backup on the device
Depending on the number of applications installed, the backup process may take a significant amount of time.
The resulting backup data is stored as a .ab file, but is actually a .tar file that has been compressed with the
Deflate algorithm. If a password was entered on the device when the backup was created, the file would also be AES encrypted. It should also be mentioned that these files may exist on a suspect's computer, and can be analyzed using the same methods.
There are many free utilities to turn the .ab backup file into a .tar that can be viewed. One such utility is the Android Backup Extractor, found at http://sourceforge.net/projects/adbextractor/.
To use the Android Backup Extractor, simply extract its files into the directory with the backup. The command to run the utility is:
java -jar abe.jar unpack backup.ab backup.tar
If the command runs properly, the command line will display as follows:
The first line of the output informs the examiner that the file was not encrypted. Had it been encrypted, the examiner would have to pass the password as an argument at the end of the command line. As seen in the output, the backup created in the previous section is approximately 4 GB, even though it is still compressed. The .tar file will be at the path specified on the command line or the current working directory if no path is specified. Decompressing the .tar file may be done manually on a Linux command line or with one of the many Windows archive utilities, such as WinRAR or 7Zip:
Directories within the backup, seen in Windows Explorer
Now that the backup has been converted to a .tar file and then extracted, the examiner can view the data contained in the backup. In our example, there are two directories found in the root of the backup:
apps: This folder contains data from/data/datafor applications that were included in the backup.shared: This folder contains all data from SD card, only present if the –shared argument was passed at the command line.
Note that the files within the apps directory are stored in directories by their package name (just as seen in /data/data from within the ADB shell), and the shared directory is exactly what the user would see if they accessed the SD card by plugging it into a computer.
For a benign example of user data that was pulled from the backup, the user's Pandora activity is shown below. Pandora is a streaming music service with millions of downloads in the Google Play Store. Pandora's application data will be contained in the apps folder of the backup in the folder named com.pandora.android.
The Pandora directory from the backup
This is a fairly standard layout for an Android application, as discussed in Chapter 2, Setting Up an Android Forensic Environment. The application's databases will be in the db folder:
Files within the db folder of the Pandora backup
XML configuration settings will be in the sp folder:
Files within the sp folder of the Pandora backup
Using a database viewer to view pandora.db reveals stations that the user has created, as well as the timestamp for when it was created:
Contents of pandora.db from the backup
Looking in the XML preferences file, the timestamp of the app installation can be found under firstInstallId. Note that the exact method for converting the timestamps is shown in Chapter 7, Forensic Analysis of Android Applications:
Contents of the XML preferences file
If, for some odd reason, the user's Pandora usage was a major question in the investigation, what could an examiner determine from these two seemingly innocuous files?
Firstly, the lastTransmission and firstInstallID timestamps are within milliseconds of each other, indicating that the application was never used after it was installed. Furthermore, the creation dates of each station precede the installation of the application, in some cases, by years. This would be an indicator that the user has used Pandora on other devices, which may be highly relevant to the investigation.
While Pandora is generally not germane to digital forensic investigations, it is an example of data that can be gleaned from a simple backup over ADB. A more detailed application analysis will be presented in Chapter 7, Forensic Analysis of Android Applications.