Overview
Mobile forensics is a field of digital forensics which is focused towards mobile devices which are growing very fast. Due to the exponential growth of the mobile market, Importance of mobile forensics has also increased. Mobile phones generally belong to a single person so analysis of it could reveal lots of personal information. Due to the rapid growth, it also introduced challenges. The ratio of new models designed and launched is very high which makes very difficult to follow similar procedures. Each case or investigation of the new model needs to consider differently and requires following steps which could be different and unique to the case. With these challenges in mobile forensics, syncing mobiles phone to a computer using software becomes easy. One could extract data like SMS, contacts, installed applications, GPS data and emails, deleted data. As per the definition of the carrier in 2006, Digital Evidence is data that supports or refutes a hypothesis about digital events. Forensic sound manner should be used while collecting, preserving, and analyzing digital evidence to present it in court. Preserving mobile device without altering data is nearly impossible because mobile device constantly transmits data using the network, Wi-Fi, or Bluetooth. That is why it is necessary to document each and every small detail about steps taken starting from seizure, collection, preservation, analysis with the presentation in court.
Collection
Below steps are recommended to follow during collection of mobile device
Note location from where mobile has been collected. It is good practice to take the picture using the camera of the location and mobile phone before starting any progress. Note the status of the device. Whether it’s powered off or on. If it is power on then, check the battery status, network status. Check where the screen is locked. Search for the SIM package and if any cables are located around
Preservation
Preservation of evidence is a very crucial step in digital forensics. If it is very important to maintain evidence integrity throughout the investigation. For mobile forensics below steps are good practice to follow
It is possible that attacker could remotely wipe data or any new activity could override the existing data. So, the first step should be to isolate the mobile device from the network. There are several ways that could be followed according to the scenario. Forensic Investigator can remove SIM card, Switch to Airplane mode or Use Faraday’s Bag or Jammer Chain of Custody – Chain of custody is the document to maintain each record of the Digital evidence from the collection to presentation. It includes details like serial no, case no, locker no, investigator’s name, time and date during each step, details of evidence transportation. It is crucial because it keeps track of the Digital evidence. Hashing – Hashing is the method used to prove the integrity of the evidence. MD5 or SHA are widely used algorithms to calculate the Hash values of the evidence. As previously mentioned it is almost impossible to interact mobile device without altering it. But we could calculate the hash value of the extracted data through logical extraction or of the image file extracted through physical extraction.
Acquisition
There are three methods used for the data extraction from the Android devices. Below overview has been given about each.
Physical – It is a bit-to-bit copy of the device and allow to recover deleted data. Unfortunately, with mobile forensic always it is not possible to use this method. File system – This method would extract files which are visible at file system level. Logical – This method allows extracting particular files from the file system like a backup. Sometimes needs to perform offensive techniques like password cracking and Rooting.
Android OS comparison
Below Table list out the various Android Version and compare important features added in the new version –
Android security
Android by default runs on Linux kernel. Linux kernel provides Android with following security features – MIDI support Storage Access Framework Hardware Sensor Batching GLES2.0 SurfaceFlinger Chromium WebView Audio monitoring Wi-Fi certified Miracast New Bluetooth profile IR Blasters API Wi-Fi Tunneled Direct Link Setup (TDLS) support Tools for analyzing memory use (procstats, on-device memory status, and profiling) Nested fragments Video call support
User-based permissions model – Android OS has implemented permission model for individual apps. Applications must declare a list of permissions they require in a file called manifest.xml. When a user installs the application, Android presents a permission list to the user so that they can view the list to allow or disallow the installation as shown below
Note – We cannot install an android application with few permissions. Either we have to accept all the permissions or decline to install it.
Application sandboxing – Android by default, make use of Linux user-based protection model. Every android application is assigned is a unique UID and is run as a different process. In Android, by default, an application cannot access data of other application. So, if an application tries to do something malicious, it can do within its context and permission it has been assigned by the OS.
SELinux in Android – From Android 4.3, SELinux (Security Enhanced Linux) is supported by Android. SE android uses MAC (Mandatory Access Control) which ensures Application runs in an isolated environment. With SELinux Android, if a user installs the malicious app, malware cannot access the OS and corrupt the device.
Application Signing – All android apps are signed by the developer/owner to determine the author of the app. The key store and private key which is used during signing need to be protected for pushing a new update to the application.
Secure interposes communication – As discussed above, sandboxing is obtained between the processes using UID assigned to the process. But if an application wants to access data of other application using Intent or Content Provider it is done safely using Binder Mechanism. Suppose Process “A” wants to access data of Process “B.” “A” is the client, and “B” is the Service.
All the request/interaction between Client and Service happens through Proxy on Client side and Stub on Service Side. All the request/interaction are monitored by the kernel for ensuring the security.
Android forensics lab setup
We assume the reader has installed and setup Android Studio, Android SDK, and Android Emulator. If not, please refer – For SDK – https://developer.android.com/studio/install.html For Android Emulator – https://developer.android.com/studio/run/emulator.html https://www.embarcadero.com/starthere/xe5/mobdevsetup/android/en/creating_an_android_emulator.html In this paper, we are using Android 4.4 Why we need Emulator – Emulator allows an investigator to understand how certain applications behave and how the installation of an application affects the device. Another advantage is that you can design an emulator with the desired version. This is especially helpful when working with devices running on older versions of Android. Also, AVD comes with root as default. Rooting Android Phone – Rooting is the process of letting the users of Android phones gain the highest privilege i.e. Root user privilege on an Android Phone. Android is based on Linux as discussed. Thus, gaining root access is same as gaining root user access or administrative access on Linux OS. Rooting is needed to understand the internals of the device. It also helps to overcome the certain limitations and barrier in the investigation. By rooting an Android device, you can alter or replace system applications and settings, run specialized apps that require administrator-level permissions or perform operations that are otherwise inaccessible to a normal Android user. However, from a forensic point of view, the main reason for rooting is to gain access to those parts of the system that are normally not accessible. Most of the public root tools will result in a permanent root. In this, the changes persist even after rebooting the device. In the case of a temporary root, the changes are lost once the device reboots. Temporary roots should always be preferred over permanent for forensic investigation. Why Root an Android Phone – As discussed, in Android each application is assigned a UID and is run as a separate process, and each application is segregated so that one application does not access the data of another application. UID’s assigned to the application are stored in packages.XML file in /data/system folder. This file, in addition to storing UIDs, stores the Android permissions of each program as well. The private data of each application is stored in the /data/data location and is accessible only to that application. Hence, during the course of the investigation, the data present at this location cannot be accessed if the phone is not rooted since a normal user cannot access the application data. However, rooting a phone will allow us to access the data present in any location. Thus, it is necessary to root the Android Phone. Recovery and Fastboot – It is necessary to understand recovery, bootloader, and Fastboot modes in Android. The following sections explain these in detail – Recovery Mode – Any Android phone has three main partitions: boot loader, Android ROM, and recovery. The boot loader is present in the first partition and is the first program that runs when the phone is powered on. The primary role of the Boot Loader is to take care of low-level hardware initialization and boot the device into other partitions. It usually loads the Android partition, commonly called as Android ROM. Android ROM contains all the operating system files that are necessary to run the device. The recovery partition, commonly called as stock recovery, is used to delete all user data and files or to perform system updates. Example – When we do a factory reset on our phone, recovery boots up and erases the files and data. Similarly, with updates, the phone boots into the recovery mode to install the latest updates that are written to the Android ROM partition. Hence, the recovery mode is the screen we always see when we install any official update on the device. Screenshot – Stock Recovery Mode on Android
Stock Recovery Mode Options
The stock Android recovery is intentionally very limited in functionality. It has the options to reboot the system, apply updates from adb and SD card, factory reset, etc. However, custom recovery offers many more options.
Custom recovery – Custom recovery is a third-party recovery environment. Flashing this recovery environment onto your device replaces the default stock recovery environment with a third-party, customized recovery environment.
Most common features included in custom recovery:
Full backup and restore functionality Allow unsigned update packages or allow signed packages with custom keys Selectively mounts device partitions and SD card Provide USB mass storage access to SD card or data partitions Provide full ADB access, with the ADB daemon running as root Fully featured BusyBox binary (Busybox is a collection of powerful command-line tools in a single binary executable)
There are several custom recovery images available in the market today, such as ClockworkMod Recovery, TeamWin Recovery Project, and so on. Screenshot – Below screenshot shows the options available with ClockworkMod Recovery:
Custom recovery Options
Fastboot mode – Fastboot is a protocol which can be used to reflash partitions on your device. It is one of the tools that come along with the Android SDK. It is an alternative to the recovery mode to do installations and updates and also to unlock the boot loader in some cases. While in fastboot, you can modify the file system images from a computer over a USB connection. Hence, it is one of the ways to install the recovery images and just boot in some cases. Once the phone is booted into fastboot, you can flash image files in the internal memory.
Locked and unlocked boot loaders – Boot loaders may be locked or unlocked. Locked boot loaders do not allow us to perform modifications to the device’s firmware by implementing restrictions at the boot loader level. In other words, to run any recovery image or our own operating system, the boot loader needs to be unlocked first.
Some devices have ways to unlock them officially. For these devices, the boot loader can be unlocked by putting the device into the fastboot mode and running – “fastboot oem unlock command.” This will unlock the boot loader of the Android device.
Some other manufacturers provide unlocking through different means, for instance, through their websites and so on. The following screenshot shows the HTC website providing support to unlock HTC devices:
Unlocking Boot Loader from HTC Official Website How to root – In this section, we will learn how to Root an Android Phone. Gaining root access on a device with an unlocked boot loader is very easy but gaining root access on a device with a locked boot loader is not so straightforward. Rooting unlocked Boot-Loader – The process of rooting mainly involves copying the superuser (su) binary to a location in the current process’s path (/system/xbin/su) and granting it executable permissions with the chmod command. Hence, the first step here is to unlock the boot loader. As explained in the earlier section, depending on the device manufacturer, unlocking a boot loader can be done either through the fastboot mode or by following vendor-specific boot loader unlock procedure. The su binary comes along with an Android application, such as Superuser, that provides a graphical prompt each time an application requests root access. In our case, we will root Lenovo mobile which I have with me. Rooting steps for Android mobile will vary as per the mobile manufacturer so the steps may vary from your mobile manufacturer. There are many tools available for rooting any device, and it varies from a different manufacturer. In our case, we will use Lenovo K3 Note Manager.
Enabling USB Debugging
Selecting Device on K3 Note Manager
Device Connected Notification
Rooting in Progress
Rooting in Progress
Device Rooted Successfully
SuperSU Installed Successfully
Root Access on device Note – From Android 4.1, a new feature called the sideload mode has been introduced. This feature allows us to apply an update zip over ADB without copying it to the device beforehand. To sideload an update, run the adb sideload su-package.zip command, where su-package.zip is the filename of the update package on your computer. Alternately, you can also modify a factory image to add a su binary. This can be done by unpacking an ext4 formatted system image, adding a su binary, and repacking it. If this image is flashed, it will contain the su binary, and the device will be rooted. The main motive of forensic analysis is to extract necessary data from the device. Hence, for effective forensic analysis, it is important and necessary to know what kind of data is stored on the device, where it is stored, how it is stored, and the details of the filesystems on which the data is stored. This knowledge is very important to a forensic analyst to make an informed decision about where to look for data and the techniques that can be used to extract the data. In this section, we will cover the following topics:
Android partition layout and file hierarchy Application data storage on the device An overview of the Android filesystem
Android partition layout and file hierarchy – The partition layout varies between device manufacturers and versions. However, few partitions are present in all the Android devices. Some of the common partitions found in most of the Android devices.
Boot loader – This partition stores the phone’s boot loader program. This program takes care of initializing the low-level hardware when the phone boots. Thus, it is responsible for booting the Android kernel and booting into other boot modes, such as the recovery mode, download mode, and so on
Boot – As the name suggests, this partition has the information and files required for the phone to boot. It contains the kernel and RAM disk. So, without this partition, the phone cannot start its processes.
Recovery – Recovery partition allows the device to boot into the recovery console through which activities such as phone updates and other maintenance operations are performed. For this purpose, a minimal Android boot image is stored. This boot image serves as a failsafe.
Userdata – This partition is usually called the data partition and is the device’s internal storage for application data. A bulk of user data is stored here, and this is where most of our forensic evidence will reside. It stores all app data and standard communications as well.
System – All the major components other than kernel and RAM disk are present here. The Android system image here contains the Android framework, libraries, system binaries, and preinstalled applications. Without this partition, the device cannot boot into normal mode.
Cache – This partition is used to store frequently accessed data and various other files, such as recovery logs and update packages downloaded over the cellular network.
Radio – Devices with telephony capabilities have a baseband image stored in this partition that takes care of various telephony activities.
Android Debug Bridge(ADB) – In Android forensics, ADB plays an important role. It is present in <sdk_path>/platform-tools folder. For an example – C:AndroidSDKplatform-tools. There you will find an executable called adb.exe as shown
Android Debug Bridge as the name suggests it acts as a bridge between computer and the mobile phone. So, if we want to communicate with the phone from the computer, we do it via ADB. I hope role of ADB is clear. To work with ADB, USB debugging options should be enabled on the phone. On Lenovo phone, it can be done by selecting developer option as shown in the below figure
Fig 1 – Selecting Developer Options
Fig 2 – Enabling USB Debugging However, it will vary with other devices, and USB Debugging option should be enabled accordingly. Note – On some Smart Phones, the Developer options menu is hidden. It can be turned on by tapping on the Build Number field in Settings > About Device seven times. ADB usually runs with a non-privilege shell account. Thus, it will not provide access to internal application data. But on a rooted phone, ADB will run with root shell account and provide access to internal application data and OS files and folders. Using ADB to access the device – Connect the device to the computer. After connecting the device to the computer and before issuing adb commands, it is helpful to know whether the mobile phone is connected to the adb server. This can be done using the “adb.exe” devices command. This command lists out all the devices that are connected to the computer, as shown in the following command. This will also list the emulator if it is running at the time of issuing the command Command – C:Program Files (x86)Androidandroid-sdkplatform-tools>adb.exe devices List of devices attached 4df16ac5115e4e04 device Issuing Shell Commands to the Mobile Phone – As stated above Android runs on Linux and provides a way to access the shell. Using ADB, we can access or gain a shell on Android Phone. Once we access or gain shell, we can run most of the Linux commands. We can gain shell access on mobile using adb.exe command as shown below – C:Program Files (x86)Androidandroid-sdkplatform-tools>adb.exe shell shell@android:/ $ After executing a shell command, shell prompt is displayed to the user. In this shell prompt, commands can be executed on the device. For instance, as shown in the below command line, ls command can be used to view all the files within a directory. C:Program Files (x86)Androidandroid-sdkplatform-tools>adb.exe shell shell@android:/ $ ls ls acct cache config dd ata default.prop dev efs etc factory fstab.smdk4x12 Installing an Application – During the investigation, it may happen that we need to install some applications on the device for extracting data from the device. It can be done by issuing the command: adb.exe install name_of_the_application.apk Example – C:Program Files (x86)Androidandroid-sdkplatform-tools>adb.exe install test.apk 4311 KB/s (13855934 bytes in 3.138s) pkg: /data/local/tmp/test.apk Success Pulling Data from Device – If there is any need to pull the data from the mobile, it can be done using adb pull command. Syntax – adb pull path_to_file_on_android_device path_to_file_on_local_computer Note – On a normal Android phone, we won’t be able to download all the files using the adb pull command, because of the inherent security features provided by the Android operating system. Example – Files present under the /data/data folder cannot be accessed on an Android device that is not rooted. Pushing data to the device – If there is any need to push the data to the mobile, it can be done using adb push command. Syntax – adb push path_to_file_on_local_computer path_to_file_on_android_device ADB on a rooted device – We have seen how the ADB tool can be used to interact with the device and execute certain commands on the device. However, on a normal Android phone, certain locations, such as /data/data, cannot be accessed. Example – The following command-line output appears when we try to access /data/data on a normal device: C:Program Files (x86)Androidandroid-sdkplatform-tools>adb.exe shell shell@android:/ $ cd /data/data cd /data/data shell@android:/data/data $ ls ls opendir failed, Permission denied This is because the private data of all the applications are stored in this folder. Thus, the security is enforced by Android. Only the root user has access to this location. Hence, on a rooted device, we will be able to see all the data from this location, as shown in the following commands: C:Program Files (x86)Androidandroid-sdkplatform-tools>adb.exe shell shell@android:/ # ls /data/data ls /data/data android.googleSearch.googleSearchWidget com.android.MtpApplication com.android.Preconfig com.android.apps.tag com.android.backupconfirm com.android.bluetooth com.android.browser com.android.calendar com.android.certinstaller com.android.chrome com.android.clipboardsaveservice com.android.contacts com.android.defcontainer com.android.email com.android.exchange com.android.facelock com.android.htmlviewer com.android.inputdevices com.android.keychain com.android.mms As shown in the above command, the private data of all the applications can now be seen easily by navigating to the respective folders. Hence, the ADB tool on a rooted device allows an examiner to access all the data of applications installed on the device. Note Sometimes, even on a rooted phone, you will see the permission-denied message. In such cases, after executing the adb shell command, try entering the superuser mode by typing su. If the root is enabled, you will see # without asking for a password.
Android file hierarchy
A basic understanding of how Android organizes its data in files and folders helps a forensic analyst narrow down his research to specific locations. If you are familiar with Unix-like systems, you will understand the file hierarchy in Android very well. Based on the device manufacturer and the underlying Linux version, the structure of this hierarchy may have a few insignificant changes. To see the complete file hierarchy, you need to have root access. Here is the sample screenshot –
Directories Overviews
Acct – This is the mount point for the acct cgroup (control group) that provides for user accounting.
Cache – This is the directory (/cache) where Android stores frequently accessed data and app components. Wiping the cache doesn’t affect your personal data, but simply deletes the existing data there. There is also another directory in this folder called lost+found. This directory holds recovered files (if any) in the event of filesystem corruption, such as incorrectly removing the SD card without unmounting it and so on. The cache may contain forensically relevant artifacts, such as images, browsing history, and other app data.
d – This is a symbolic link to /sys/kernel/debug. This folder is used to mount the debugfs filesystem and to debug kernel.
data – This is the partition that contains the data of each application. Most of the data belonging to a user, such as the contacts, SMS, dialed numbers, and so on, is stored in this folder. This folder has significant importance from a forensic point of view as it holds valuable data. The following screenshot shows the folders present in this partition:
Important sub-directories under data folder
dalvik-cache – This folder contains several logs that might be useful during the examination, depending on the underlying requirements. data – The /data/data partition contains the private data of all the applications. Most of the data belonging to the user are stored in this folder. This folder has significant importance from a forensic point of view as it holds valuable data.
dev – This directory contains special device files for all the devices. This is the mount point for the tempfs filesystem. This filesystem defines the devices available to the applications.
init – When booting the Android kernel, the init program is executed. This program present under this folder.
mnt – This directory serves as a mount point for all the filesystems, internal and external SD cards, and so on.
proc – This is the mount point for the procfs filesystem that provides access to the kernel data structures. Several programs use /proc as the source for their information. It contains files that have useful information about the processes.
root – This is the home directory for the root account. This folder can be accessed only if the device is rooted.
sbin – This contains binaries for several important daemons. This is not of much significance from a forensic perspective.
misc – As the name suggests, this folder contains information about miscellaneous settings. Information about hardware settings, USB settings, and so on can be accessed from this folder.
sdcard – This is the partition that contains the data present on the SD card of the device.SD card can be either removable storage or non-removable storage. Any app on your phone with the WRITE_EXTERNAL_STORAGE permission may create files or folders in this location. There are some default folders, such as android_secure, Android, DCIM, media, and so on, present in most of the mobiles.
Digital Camera Images (DCIM) – It is the default directory structure for digital cameras, smartphones, tablets, and related solid-state devices. Some tablets have a photos folder that points to the same location. Within DCIM, you will find photos you have taken, videos, and thumbnails (cache) files. Photos are stored in /DCIM/Camera. system – This directory contains libraries, system binaries, and other system-related files. The pre-installed applications that come along with the phone are also present in this partition. The following screenshot shows the files present in the system partition on an Android device:
Here are some of the interesting files and folders present in the /system partition that are of interest to a forensic investigator – build.prop This file contains all the build properties and settings for a given device. For a forensic analyst, this file gives an overview of the device model, manufacturer, Android version, and many other details. Contents of this file can be viewed by issuing a cat command, as shown in the following screenshot:
As shown in the preceding output, you can find out the product model, CPU details, and Android version by viewing this file content. On a rooted device, tweaking the build.prop file could lead to a change in several system settings. app This folder contains system apps and preinstalled apps. This is mounted as read only to prevent any changes. The following screenshot shows various system-related apps that are present in this folder:
Along with the APK files, you might have also noticed .odex files in the preceding output. In Android, applications come in packages, with the .apk extension. These APKs contain .odex files whose supposed function is to save space. The .odex files are a collection of certain parts of an application that are optimized before booting. framework This folder contains the sources for the Android framework. In this partition, you can find the implementation of key services, such as the system server with the package and activity managers. A lot of the mapping between the Java application APIs and the native libraries is also done here. ueventd.goldfish.rc and ueventd.rc These files contain configuration rules for the /dev directory. Application Data Storage – Android devices store a lot of sensitive data through the use of apps. Here is a more detailed split of various sources of Data on Android –
Apps that come along with Android Apps installed by the manufacturer Apps installed by a wireless carrier Apps installed by the user
All of these store different types of data on the device. Application data often contains a wealth of information that is relevant to the investigation. Here is a sample list of possible data that can be found on an Android device:
SMS MMS Chat messages Backups E-mails Call logs Contacts Pictures Videos Browser history GPS data. Files or documents downloaded Data that belongs to installed apps (Facebook, Twitter, and other social media apps) Calendar appointments
Data belonging to different applications can be stored either internally or externally. In the case of external storage (SD card), data can be stored in any location. However, in the case of internal storage, the location is predefined. To be more specific, internal data of all the apps present on the device (either system apps or user-installed apps) is automatically saved in the /data/data subdirectory, named after the package name. For example, the default Android email app has a package named com.android.email, and the internal data is stored in /data/data/com.android.email. Android provides developers with certain options to store data to the device. Data that belongs to applications can be stored in one of the following locations:
Shared preferences Internal storage External storage SQLite database Network
Let’s understand all these in details. Shared Preferences – Shared Preferences provides a framework to store key-value pairs of primitive data types in the .xml format. Primitive data types include Boolean, float, int, long, and string. Strings are stored in the Universal Character Set Transformation Format-8 (UTF-8) format. These files are typically stored in the application’s /data/data/<package_name>/shared_prefs path. Screenshot for Shared Preference –
All the data in the key-value pair is stored in a file. Looking into the file will help the investigator to obtain sensitive data. Internal storage – The files here are stored in the internal storage. These files are located typically in the application’s /data/data subdirectory. Data stored here is private and cannot be accessed by other applications. Even the device owner is prevented from viewing the files (unless they have root access). The following screenshot shows the details of the apps stored with their package name in the /data/data directory:
Internal data for each of the app is stored in respective folders. Usually, the databases, lib, shared_pref, cache folders are created for most of the applications.
Folder description –
shared_prefs – XML file of shared preferences contains data in a key-value pair.
lib – Custom library files required by app
files – Developer-saved files
cache – Files cached by app
databases – SQLite and journal files
External storage – Files can also be stored by the apps in external storage. External storage can be a removable media, such as an SD card or non-removable storage that comes with the phone. In the case of a removable SD card, data can be used on other devices just by removing the SD card and inserting it into any other device. SD cards are usually formatted with the FAT32 filesystem, but other filesystems, such as EXT3 and EXT4, are also being used increasingly. Data stored in SD Card are public and can be accessed by other applications, provided the requesting apps have the necessary permissions. Large files, such as images and videos, loaded by the apps are usually stored in the external storage for faster retrieval
SQLite database – SQLite is a popular database format present in many mobile systems. SQLite databases are a rich source of forensic data. The SQLite files used by the apps are generally stored at /data/data/
Android filesystem overview
Understanding the filesystem is very important in Android forensics, as it helps us gain knowledge of how the data is stored and retrieved. This knowledge about properties and the structure of a filesystem will prove to be useful during forensic analysis. Viewing filesystems on an Android device – The filesystems supported by the Android kernel can be determined by checking the contents of the filesystems file that are present in the proc folder. The content of this file can be viewed using the following command – cat /proc/filesystems Common Android filesystems – The filesystems present in Android can be divided into three main categories, which are as follows:
Flash memory filesystems Media-based filesystems Pseudo filesystems
Flash memory filesystems – Flash memory is a type of constantly-powered non-volatile memory that can be erased and reprogrammed in units of memory called blocks. Common flash memory filesystems are – Extended File Allocation Table (exFAT), Flash Friendly File System (F2FS ), Journal Flash File System version 2 (JFFS2), Yet Another Flash File System version 2 (YAFFS2), Robust File System (RFS). Media-based filesystems – Media-based filesystems supported by android are – EXTended file system (EXT2/EXT3/EXT4), File Allocation Table (FAT), Virtual File Allocation Table (VFAT). Pseudo filesystems – Pseudo filesystems can be thought of as logical groupings of files. Some of the important pseudo filesystems found on an Android device are – control group (cgroup), rootfs, procfs, sysfs, tmpfs One can use the mount command to see different partitions and their filesystems available on the Device. Extracting Data Logically from Android Devices – The term logical extraction means extractions of data that do not recover deleted data, or do not include a full bit-by-bit copy of the evidence. Using this method, a forensic examiner cannot be sure whether they have recovered all of the data possible since the operating system is choosing which data it allows the examiner to access. In simple word, logical extraction is analogous to copying and pasting a folder to extract data from a system. This process will only copy files that the user can access and see. If any hidden or deleted files are present in the folder being copied, they will not be in the pasted version of the folder. What kind of data can be recovered – Almost all kind of data can be recovered through logical extraction. The bulk of this data is stored in SQLite databases, so it is even possible to recover large amounts of deleted data through a logical extraction. When forensically analyzing an Android device, the limiting factor is whether forensic investigator has the ability to access all the data on the android phone i.e. whether the investigator has root access or not. Since the majority of the data is stored in /data/data folder, if the forensic investigator does not have root access, he/she won’t be able to access all the data of the application. In this, we will assume forensic investigator already has root access to the Android Phone. Manual Extraction using ADB – The “ADB pull” command can be used to pull single files or entire directories directly from the device on to the forensic examiner’s computer. This method is especially useful for small examinations where the file size is small. For this method, USB Debugging should be enabled on the device. Enabling USB Debugging has been discussed earlier. Note – before Android 4.2.2, enabling USB debugging was the only requirement to communicate with the device over ADB. In Android 4.2.2, Google added Secure USB debugging option. The Secure USB debugging option adds an additional requirement of selecting to connect to a computer on the device’s screen; this prevents ADB access to locked devices from untrusted computers. If Always allow from this computer is selected, the device will store the computer’s RSA key, and the prompt will not appear on future connections to that computer, even if the device is locked. Once USB debugging has been enabled and the Secure USB debugging check passed (depending on Android version), the device is ready for examination. To verify that the device is connected and ready to use ADB, execute the following command: adb devices This should list your device. If not, please enable USB Debugging and install device driver if needed. If everything is running correctly, the device status should show the name of the device as shown below –
Using ADB shell to determine if a device is rooted – The simplest method to determine if a device is rooted is to use the “adb shell” command. Open a terminal on the local computer and run the command “adb shell.”
The shell will appear one of two ways, either with $ or #
The # symbol is used to indicate a root user, and the $ symbol indicates a non-root user. If the shell returns showing #, the shell has root access. If the shell returns $, try running the command “su.”
Extracting Data using ADB pull – ADB pull command is used to transfer files from the device to the local workstation. The format for the ADB pull command is –
adb pull [-a] path_of_file_on_phone path_of_file_on_computer
The optional -a flag will copy the file’s timestamp and mode
Example – If we run the following command – “adb pull/data/data/com.android.providers.telephony/databases/mmssms.db C:/sms_data”
This command would pull the SMS database file from the device, and write it to sms_data directory. The database can now be examined with a SQL Browser or any other forensic tool.
ADB backup extractions – Google implemented ADB backup functionality, beginning in Android 4.0 Ice Cream Sandwich. This allows 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
When performing a backup, the user must approve the backup on the device. This means that backups cannot be performed without bypassing screen locks. Parsing ADB Backup – 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 were entered on the device when the backup was created, the file would also be AES encrypted. 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. It can be 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. 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 as shown below
Now that the backup has been converted to a .tar file and then extracted, the examiner can view the data contained in the backup for forensic investigation.
Bypassing android lock screens
Lock screens are the most challenging aspect of Android forensic examinations. While there are methods to bypass them, this can be highly dependent on the OS version, device settings, and capability of the examiner. Commercial forensics tools such as Cellebrite and XRY have fairly robust bypass capabilities but are far from infallible. Lock screen types – Various type of lock screen are
None/Slide Pattern PIN Password
Smart Lock
Trusted Face Trusted Location Trusted Device
General bypass information – In all cases, bypassing the lock screen will require retrieving a file from the device. The files that need to be pulled to crack a PIN/password on devices before Android 4.4 are: /data/system/password.key /data/data/com.android.providers.settings/databases/settings.db The files that need to be pulled to crack a PIN/password on devices running Android 4.4 and higher are: /data/system/password.key /data/system/locksettings.db Only one file needs to be pulled to crack a Pattern lock on all versions of Android: /data/system/gesture.key Many tools exist that will bypass lock screens automatically. We will use Andriller which can be downloaded from – https://andriller.com/ Cracking an Android pattern lock – Now we have gesture.key, which contains the pattern lock information, let’s take a look at the file contents:
The hex contents of the file are an unsalted SHA-1 hash of the swipe pattern. The simplest method for cracking this hash is a dictionary attack since there is a limited number of the pattern (4 minimum and 9 maximum). CCL Forensics, based in the UK, provides a free Python script to create the hash dictionary. It can be downloaded at http://www.cclgroupltd.com/product/android-pattern-lockscripts/ The file is GenerateAndroidGestureRainbowTable.py. To run it, Python 3 must be installed on the examiner’s system. Python 3 can be downloaded at https://www.python.org/downloads/. Many forensics tools provide Python support or use it themselves, so an examiner may already have it installed. To execute the file, simply navigate to the directory containing it and run:
Once it completes, there should now be a file called AndroidLockScreenRainbow.sqlite in the same directory as the GenerateAndroidGestureRainbowTable.py script. Now that we have a database containing the hash of every possible Android pattern, we simply need to look up the hash we found in the gesture.Key file. This can be done manually with an SQLite viewer or even SQL commands. However, CCL Forensics also provides Android_GestureFinder.py, a script that will look up the hash in the database created previously. Ensure that the AndroidLockScreenRainbow.sqlite and gesture.Key files are in the same directory as Android_GestureFinder.py, and run the following script:
The output should return very quickly, as it is performing a simple lookup in the hash database. The Hash column shows the hash value that was found, and the Pattern is the corresponding lock screen pattern which is 0 4 8 7 6. Another method of doing this is by looking up the hash value in the hash database. The hash value can be searched over the internet, or it can be read using DB browser for SQLite. Cracking an Android PIN/Password – To crack the PIN/Password lock, we’ll need to take a look at the contents of the files pulled earlier. Password.key is very similar to gesture.key; it contains a hash of the password as shown in the following screenshot:
CCL Forensics provides a useful Python script for this purpose. Other cracking tools, such as hashcat, could also be used. The CCL Forensics PIN/Password tool can be downloaded for free at http://www.cclgroupltd.com/product/android-pin-password-lock-tool/. Two files will be downloaded, BruteForceAndroidPin.py and RecoverAndroidPIN.py. RecoverAndroidPIN.py is for locating the necessary files within a physical image; we won’t be needing it for our purposes.
The format for BruteForceAndroidPIN.py is:
python BruteForceAndroidPIN.py
The PIN from this example was 2587 as indicated in the output.
Extracting data physically from android devices
Physical extraction is an exact bit-for-bit image of the electronic media. It involves removing the evidence drive from the suspect’s computer and imaging it via a write blocker. The output is frequently referred to as a raw image, or simply a bin (binary) file. To manually image a device, we are going to have to execute commands on the device from the ADB shell, and these will require root permissions. If root access cannot be obtained, the SD card can generally still be imaged. Extracting data physically with dd – dd command is frequently used in forensics to create bit-by-bit images of entire drives. The format of the dd command is as follows – dd if=/dev/block/mmcblk0 of=/sdcard/blk0.img bs=4096 conv=notrunc, noerror, sync Flags Meaning –
If: the path of the input file to read from. of: the path of the output file to write to. bs: It specifies the block size. It defaults to 512 bytes if not specified. conv: It specifies the conversion options as its attributes: notrunc: It does not truncate the output file. noerror: It continues imaging if an error is encountered. sync: In conjunction with the noerror option, this option writes x00 for blocks with an error. It is important for maintaining file offsets within the image.
Determine what to Image – When imaging a computer, an examiner must first find what the drive is mounted as; /dev/sda, for example. The first step is to launch the ADB shell and run the cat /proc/partitions command as shown below –
mmcblk0 is the entirety of the flash memory on the device. P1-p29 are the size of the partitions. To obtain a full image of the device’s internal memory, we would run the dd command with mmcblk0 as the input file. Most of these partitions are unlikely to be forensically interesting. To view the corresponding names for each partition, we can look in the device’s by-name directory. This does not exist on every device and is sometimes on a different path, but for this device, it is found at /dev/block/msm_sdcc.1/by-name. By navigating to that directory and running the ls –al command, we can see to where each block is symbolically linked as shown in the following screenshot:
If our investigation was only interested in the userdata partition, we now know that it is mmcblk0p28, and could use that as the input file to the dd command. If the by-name directory does not exist on the device, it may not be possible to identify every partition on the device. However, many of them can still be found by using the mount command within the ADB shell. Writing dd output to SD Card – The output file of the dd command can be written to the device’s SD card. On newer devices, the /sdcard partition is actually a symbolic link to /data/media. To determine where the SD card is symbolically linked to, simply open the ADB shell and run the ls -al command. If the SD card partition is not shown, the SD likely needs to be mounted in recovery mode. After determining which block to read and to where the SD card is symbolically linked, image the /data partition to the /sdcard, using the following command – dd if=/dev/block/mmcblk0p28 of=/sdcard/data.img bs=512 conv=notrunc, noerror, sync The output is shown below –
Now, an image of the /data partition exists on the SD card. It can be pulled to the examiner’s machine with the ADB pull command or simply read from the SD card. Note – The partitions which we have seen above is Multimedia Card (MMC) blocks, which is typically seen in newer devices. Very Older devices more likely consist of Memory Technology Device (MTD) blocks. In this case, dd command may not work, and we can use the nanddump command for reading and extracting data from MTD blocks. Analysis of Extracted Image – For Analyzing full image we can make use of tools such as Cellebrite, XRY, Mobile Phone Examiner, etc. But these are not free. So, we will have to make use of the free open source tool. The most popular analysis tool that is the free and open source is Autopsy. Autopsy – Autopsy can be downloaded at http://www.sleuthkit.org/. Once the image has been loaded, expanding the image will show all the volumes that Autopsy found, as shown in the following screenshot –
One of the volumes will contain data partition which contains data of all the application as discussed earlier. As each application is installed, a directory is created for it, and the forensic investigator can go through the directories created for each application for analyzing the data present in it. Imaging RAM – The most common tool for Android RAM acquisition is the Linux Memory Extractor (LiME), previously known as DMD. It works only on Linux system only. It isn’t highly user-friendly as it requires the user to compile it from the source code. The compilation process must also be done for each specific version of Android for each device being examined. This is necessary because it is a kernel module that must be built specifically for each kernel it will be loaded into. If usage of Lime is not possible, then mem tool can also be used for Imaging RAM. The mem tool can be downloaded at http://sourceforge.net/projects/androidforensics-mem/files/. Mem is an executable binary that needs to be pushed to the device. Acquiring Android SD cards – Physically imaging an SD card is very similar to the physical imaging using dd. We just have to extract the SDCard partition and analyzing process is same as discussed above. Advance Forensics method using JTAG and Chip-off – JTAG – It is used to communicate with the processor through a specialized interface for testing purposes. For forensic examiners, it also allows them to communicate directly with the processor and retrieve a full physical image of the flash memory. JTAG has two advantages –
It does not require the device to be powered on and so:
Can be successful even if the device is damaged There are no RF-shielding concerns Does not require root, ADB or USB debugging
It can be used to recover device PINs/passwords and so:
Can image the entire flash memory and recover/crack password files
Many of the common ones used for mobile forensics can be found at http://teeltech.com/mobile-device-forensic-tools/jtag-equipment/. The RIFF box listed on the site is probably the most frequently used for mobile forensics. Chip-off – Chip-off involves heating the device’s circuit board until the solder holding the components to the board melts, and then removing the flash memory chip. The memory chip can then be read using commercial tools, resulting in a full physical image. The process of melting the solder (commonly called reflow or rework) is used to place and remove components from a circuit board, and the readers used to acquire the memory are used to both read and write to memory chips, often in bulk quantities.
Recovering deleted data from device
When a user deletes any data from the device, the data is not actually erased. What gets deleted is the pointer to this data. All filesystems contain metadata that maintains information about the hierarchy of files, file names, and so on. Hence, it is possible to recover the deleted data. Recovering data deleted from an SD card – SDCard runs on the FAT32 filesystem. If the SD card is removable, it can be mounted as a drive by connecting it to a computer using a card reader. In forensics, to make sure that the original evidence is not modified, a physical image of the disk is taken, and all further experimentation is done on the image itself. Similarly, in the case of SD card analysis, an image of the SD card needs to be taken. After obtaining the image using tool such as dd, we can make use of a free tool such as FTK Imager for extracting the data present in it. The image file has to be imported in FTK imager, and the data get extracted. This extracted data can be used for further analysis. Example – Image shown below contains all the deleted data recovered using FTK Manager
Deleted Data from FTK Manager Apart from this, we can make use of another tool called Scalpel. Once we have the image of the phone, we can make use of scalpel for analysis. This tool analyzes the block database storage and identifies the deleted files and recovers them. Scalpel is filesystem independent and is known to work on various filesystems including, FAT, NTFS, EXT2, EXT3, HFS, and so on. While some pictures are recovered completely, some are not recovered to a full extent, as shown in the following screenshot:
Recovered Image using Scalpel
Forensic analysis of android applications
There are many ways an application can store data on the phone. In app analysis, forensic investigator understands what the app was used for and find user data. Why app analysis – Almost all of them uses standard phone functions, such as contacts, calls, internet surfing, SMS, etc. All these activities are done through applications on Android devices. Second, a person’s app usage can tell you a lot about them: – where they’ve been, when they were there, who they’ve communicated with, and even what they may be planning in the future. We will be doing an analysis of 2 application – WeChat, SMS, and MMS analysis. Also, we have used Linux in this section. WeChat Analysis – WeChat is a text and voice messaging service developed in China. The application can be used both on smartphones such as Android, iPhone, Windows Phone, BlackBerry as well as on web-based operating systems like Windows and OS X. The following sections deal with the demo on the extraction of WeChat messages from its default storage database. Step 1: Use apk2java to Decompile Android .apk to Java source code.
Step 2: Using apk2java tool, we get approximate source code of java
Fig: APK extracted using apk2java Step 3: Extraction of WeChat application
Step 4: WeChat does not make use of a database directory. On the contrary, MicroMag serves to be its equivalent. The directory present in the MicroMag contains the ‘EnMicroMsg.db.’ database. This database is encrypted by using SQLCipher. It’s an open source extension that is used for encrypting the entire database with 256-bit AES encryption. Nevertheless, the positive aspect about this encryption is that the key for decrypting the file is present on the device itself.
/MicroMsg/ CompatibleInfo.cfg /EnMicroMsg.db There are 4 different parameters, which are used to encrypt and decrypt the data stored in EnMicroMsg.db. PRAGMA key: KEY This parameter is used for setting the key that needs to be used with the database. PRAGMA cipher_use_hmac: off This disables the use of per-page HMAC checks for compatibility with SQLCipher 1.1. PRAGMA cipher_page_size: 1024 This is used for changing the default size of the page to improve performance. PRAGMA kdf_iter: 4000 This parameter changes the count of iterations that are used with PBKDF2 key derivation. Step 5: EnMicromsg.db. It’s an encrypted database. As Shown Below:
Fig: Encrypt data of EnMicromsg.db Step 6: The encryption algorithm used in WeChat EnMicromsg.db is a set of MD5 combination of IMEI + WeChat UIN that MD5 value is also known as Pragma Key. The pragma key in the first 7 character of MD5 (IMEI + WeChat UIN). It’s very easy to calculate MD5 for that first figure out the IMEI of the device. Step 7: Dial *#06# in your mobile to get your IMEI Number. Take off back cover and battery, and you could see some info including IMEI. Step 8: Now, find out the WeChat UIN. UIN is the unique id# of WeChat account. The UIN is inside the file system_config_prfs.xml.
Fig: system_config_prfs.xml
Fig: UIN value Step 9: Input the IMEI and UIN string, be careful there is no need to add any symbol between these two strings. Generate the MD5 value. The key is the first 7 character as below: 9C751DC
Fig: MD5 Checksum tool Step 10: Now will use the most important tool – SQLCipher to decrypt the EnMicromsg.db with the pragma key we found. Use SQLCipher 2.1 to open EnMicromsg.Db and input the pragma key for extracting the database as shown –
Fig – Entering Pragma Key
Fig: Decoded – WeChat data SMS Analysis SMS and MMS are stored in the same location in android Text messages are stored in an SQLite database named mmssms.db.It is stored typically under the /data/data/com.android.providers.telephony/databases/mmssms.db. Step 1: Find SMS database file location in connected device/emulator
The telephony.db database is small but contains one potentially useful source of information. In that, it contains siminfo directory which contains historical data for all SIMs that have been used in the device, including the ICCID, Phone number (if it was stored on the SIM), and the mobile country code (MCC) / mobile network code (MNC),
Step 2: Pull SQLite database file with ADB For pulling the data following command can be used – adbpull /data/data/com.android.providers.telephony/databases/mmssms.db mmssms.db With this step, whole SMS database is copied locally in your working directory! Step 3: After getting a copy of SMS database manually check for fragments using a Hex viewer, or an SQLite Viewer like oxygen forensic SQLite viewer. This SQLite Viewer show blocks of allocated SMS data:
Step 4: mmssms.db contain database contains all information regarding SMS and MMS messages. It contains the following in the directory Part: This contains information about files attached to an MMS. Each message will have at least two parts: an SMIL header and the attachment. This can be seen in the mid and ct columns, as well as the file type attached. The _data column provides the path to find the file on the device. Pdu: This contains metadata about each MMS. The date column identified when the message was sent or received, in the Linux epoch format. The _id column specifies for the image. The msg_box column shows the direction of the message 1 for received and 2 for sent message. The address column shows the phone number of the remote user, regardless of whether it was a sent or received the message. The date column showed the timestamp when a message was sent in the Linux epoch format. The type column shows the direction of the message 1 for received and 2 for sending. The body column displays the content of the message. The seen column indicates whether or not the message was read 0 for and unread 1 for reading; all sent messages will be marked as unread. Words, words_content, words_segdir This appears to contain duplicate content of messages; the exact purpose of this table is unclear. Sample schema for SMS
Conclusion
The forensics analysis of Android phone and Android application involves different technique than traditional forensics, as the version or security upgrades new methods are to be researched for Android forensics. Apart from other challenges like extracting data, bypassing screen lock and password and recovering deleted data, maintaining the integrity of mobile data and application data is the biggest challenge faced in any Android Forensics. Though lots of tools are available for Forensics, there are gaps to be filled, and a lot needs to be done in this direction.
