Introduction to Android forensics (aka CSI: Android)
Digital forensics is a branch of science which deals with the recovery and investigation of materials found in digital devices. Forensics is usually mentioned in connection with crime, vaguely similar to criminal investigations on TV shows like CSI: Crime Scene Investigation and NCIS. However, several experiments (1, 2), including this one, use methods of digital forensics as proof that people do not pay attention to what happens with their personal data when replacing their digital devices (computers, hard drives, cell phones). In this blog post series we will reveal what we managed to dig out from supposedly erased devices. The sensitive information includes pictures (even very private ones!), videos, contacts, SMS messages, Facebook chat logs, Google searches, GPS location coordinates, and more.
What happens to the file when it is “deleted”
When people want to delete a file, most will use the standard features that come with their operating system. After it’s done, they consider the unwanted data to be gone forever. However, this is not true. When a file is deleted, the operating system merely deletes the corresponding pointers in the file table and marks the space occupied by the file as free. The reality is that the file is not deleted and the data it contained still remains on the drive. With regular usage of the drive, the remaining data will sooner or later be overwritten with different data. The same thing happens on your PC.
The following screenshots show the scenario. We used the program FTK Imager to mount the image of a partition containing user data. The first figure shows a [root] directory followed by [unallocated space]. Although all the sensitive files were deleted in the regular way, something still remained in unallocated space. In this particular example, we managed to dump 251 blocks of unallocated data and to recover interesting messages, for example from a Facebook chat. The seller of this HTC Sensation cell phone thought that his personal was cleared out, but the figures below show that he/she was tragically mistaken.
The task of the Android forensics team is to utilize several different methods to search and recover as much data as possible from the deleted files and the blocks of unallocated space.
Types of analyses
Although there are some specialized hardware devices which perform forensic analysis of a cell phone, we did not order any of those and stuck just with software analysis. There are three main methods of analysis we used to discover deleted data: Mass storage mount; Logical analysis; and Low level analysis.
1) Mass storage mount
It might seem unbelievable, but some sellers still don’t store their data on removable micro SD cards or internal storage devices. In such cases, an investigator can simply attach the cell phone via USB cable to a computer and it mounts storage as Removable Storage. The figure below shows an example from a Motorola Droid Razr XT912, which reports its presence by mounting three storage methods – CD Drive (F:) MotoCast containing drivers, MOT (G:) internal storage, and Removable Disk (H:) a removable SD card. As you can see from the ratio of free/total available space, a lot of personal data was recovered from this particular example.
However, not all devices support mass storage mounting. Some devices need to be rooted and a mass storage application needs to be installed. Media Transfer Protocol (MTP) is usually used for transmitting media files to and from the portable device.
b) Logical analysis
As mentioned among others on the xda developers forum, it is possible to backup all the present data in a cell phone without unlocking/rooting using Android Debug Bridge (adb backup command). The command adb backup -apk -shared -system -all -f %1.backup created a backup file which was later converted to .tar archive with the help of an Android Backup Extractor using the command java -jar abe.jar unpack %1 %1.tar
The archive contains a directory structure with all currently installed applications, which may contain several directories; db among others. The Db directory (if it exists) contains SQLite database files, which may be viewed for example by SQLite viewer.
c) Low level analysis
If both of the above mentioned methods resulted in no interesting data, a low level analysis was performed. Low level analysis is based on exact, bit to bit, copy of userdata partition. After the copy, this partition is stored as a single file (usually a few GBs in size) which is later used as input for other analysis tools. Only a root user can make such a copy, so the phone must have been rooted at first.
i) What is rooting?
Rooting is a process of overcoming limitations imposed by manufacturers on smartphone or tablet owners. It gives an owner the ability to replace and/or alter system applications and settings, run applications requiring administrator-level privileges, and, in general, run any operation which is not allowed to be executed by a normal user. This includes listing active mounted partitions and cloning them for further purposes of forensic analysis as discussed in the coming subsections.
ii) How we rooted
We needed to root most cell phones. Forums like xda developers gave us enough guidance to perform the process of rooting simply. Programs like RazrBlade and Saferoot did their job smoothly without any problems. All we needed to do was to follow the instructions in the manual. After the successful rooting, the SuperSU application was installed on our Motorola Droid. From now on, we have a root access to the device and can execute privileged operations.
With administrator privileges (root), mount command (after invoking shell console with adb shell) can be run via Android Debug Bridge. It produces lists of mounted partitions. The Userdata partition (on some devices the same partition is just simply called data) was the most interesting one for us, so we needed to find out what block device file it mapped to. Ls command gave us the right answer. The listings below show a partition with user data and the device file it references in bold letters.
root@android:/ # mount
mount
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/platform/omap/omap_hsmmc.1/by-name/system /system ext4 ro,relatime,barrier=1,data=ordered 0 0
/dev/block/platform/omap/omap_hsmmc.1/by-name/userdata /data ext4 rw,nosuid,nodev,noatime,resuid=1000,barrier=1,data=ordered,noauto_da_alloc 0 0
/dev/block/platform/omap/omap_hsmmc.1/by-name/cache /cache ext4 rw,nosuid,nodev,noatime,barrier=1,data=ordered 0 0
/dev/block/platform/omap/omap_hsmmc.1/by-name/divxkey /dvp ext4 rw,nosuid,nodev,noatime,barrier=1,data=ordered 0 0
/dev/block/platform/omap/omap_hsmmc.1/by-name/persist /persist ext4 rw,nosuid,nodev,noatime,barrier=1,data=ordered 0 0
/dev/block/platform/omap/omap_hsmmc.1/by-name/mlt /mpt ext4 rw,nosuid,nodev,relatime,barrier=1,data=ordered,noauto_da_alloc 0 0
/dev/fuse /storage/sdcard0 fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
/sys/kernel/debug /sys/kernel/debug debugfs rw,relatime 0 0
root@android:/ # ls -l /dev/block/platform/omap/omap_hsmmc.1/by-name/userdata
ls -l /dev/block/platform/omap/omap_hsmmc.1/by-name/userdata
lrwxrwxrwx root root 2014-04-30 06:59 userdata -> /dev/block/mmcblk0p11
root@android:/ #
iii) dd command and disc cloning
We cloned the userdata partition with the old known Unix dd command. It is necessary to have one spare (micro) SD card which is used as a destination device for the cloned image. When dumping userdata files bigger than 4GB, we reached the limit of FAT32 filesystem which allows only 4GB as a maximal possible file size. To overcome this issue, it is a good idea to format a memory card to exFAT filesystem, however this filesystem is supported only by newer devices. This table emphasizes the advantages of exFAT filesystem.
The figure below show a 13GB image of userdata cloned from Samsung Galaxy S3. The extension tells us that the image file has internal structure formatted to ext4 filesystem.
iv) Sysinternals strings command + regexp analysis
After the process of cloning the partition, we ended up with a huge file, several GBs in total. We did not know where exactly particular files within the filesystem began (suppose we look at the binary file with a standard hex editor), or where they ended. We did not know whether these files are stored continuously or whether they are fragmented, whether the data are valid or were already deleted. The only thing we have is a huge blob of binary data. A very helpful tool to overcome this scenario is strings from Sysinternals, which according to the documentation “searches for ANSI and UNICODE strings in binary images.” Strings.exe extracts a text file (several hundred MBs) from a binary clone (several GBs), which we used as an input file for a bunch of commands based on regular expressions.
As examples of such regexps, we you can see a few following lines:
_msg.*nonefrom server
which extracts lines containing messages sent via Facebook chat
facebook.com/photo.php.*$
which extracts viewed Facebook photos
google.com/search?q=.*$
which extracts lines containing keywords sought by Google search engine
We constructed a few more regexps to extract SMS messages, geographical location, etc. For electronic business cards (vCard), we programmed our own Python script for extracting contacts from string file dumps.
v) scalpel tool + db format modification
After the analysis of text strings was done, we were still curious if any files with known format are present in the cloned image. For this purpose we used Scalpel, a data carving tool which is a part of Sleuth Kit. We used the default configuration of the scalpel tool, and chose to dump known file formats like JPG and PDF. We also added our custom definition of db file format which is SQLite database. The listing below shows the configuration used for carving the SQLite database files. The third number is the number of dumped bytes after the fourth sequence was found within the clone file.
db y 409600 SQLite\x20format
The output of the scalpel tool was a bunch of directories, each containing files of a certain type. In the example below, you can see the output of the run of the scalpel tool which resulted in successfully recovering of JPG images and PDF documents.
Conclusion
The combination of all the above mentioned methods helped us to discover a lot of personal data and helped us to reconstruct several personal stories. Although at first glance the phones appeared thoroughly erased, we were able to recover a lot of private data. In most cases, we got to the low level analysis, which helped us recover SMS and chat messages.
Acknowledgement
The Android forensic analysis was jointly accomplished by Jaromir Horejsi and David Fiser.
Thank you for using avast! Antivirus and recommending us to your friends and family. For all the latest news, fun and contest information, please follow us on Facebook, Twitter and Google+. Business owners – check out our business products.