Risk Management

Volatility

Since version 2.2, Volatility has been available for Linux, as well as for Android and Mac OS X since the beta 2.3.1. Quickly creating a memory dump of the Android system proves more problematic than running Volatility. As on Linux, each kernel and each version of Android needs customized Lime drivers, and building them can frighten even die-hard Linux specialists. Thank goodness test images are available for Volatility  [17].

If you download the Rodeo2012.tgz file from the Google repository (link to DFRWS 2012 Rodeo ) and uncompress, you will find two files: Evo4GRodeo.lime and Evo4G.zip. The first is the memory dump created with Lime; the second is the profile [16], which according to the Volatility project, is copied to the plugins/overlays/linux directory. If the profile matches the image, you can get started:

[root@pc]# vol.py --info | grep Linux
Volatile Systems Volatility
  Framework 2.3_beta
LinuxEvo4GARM - A Profile for
  Linux Evo4G ARM

Listing 5 shows the filesystems mounted at the time of the dump; the linux_dentry_cache command helps you search for files, such as browser.db, which is perhaps not stored on the hard disk.

01 [root@pc]# vol.py -f Evo4GRodeo.lime --profile=LinuxEvo4GARM linux_mount
02 Volatile Systems Volatility Framework 2.3_beta
03 WARNING : volatility.obj      : Overlay structure tty_struct not present in vtypes
04 tmpfs                     /app-cache  tmpfs   rw,relatime
05 tmpfs                     /mnt/obb    tmpfs   rw,relatime
06 tmpfs                     /mnt/asec   tmpfs   rw,relatime
07 /dev/block/vold/179:1     /mnt/secure/asec/.android_secure    vfat     rw,relatime,nosuid,nodev,noexec
08 /dev/block/mtdblock5      /cache      yaffs2  rw,relatime,nosuid,nodev
09 /dev/block/mtdblock6      /data       yaffs2  rw,relatime,nosuid,nodev
10 none                  /acct        cgroup rw,relatime
11 tmpfs                 /mnt/sdcard/.android_secure  tmpfs  ro,relatime
12 htcfs                 /data/htcfs  fuse   rw,relatime,nosuid,nodev
13 /dev/block/vold/179:1 /mnt/sdcard  vfat   rw,relatime,nosuid,nodev,noexec
14 none                  /dev/cpuctl  cgroup rw,relatime
15 tmpfs                 /dev         tmpfs  rw,relatime
16 devpts                /dev/pts     devpts rw,relatime
17 /dev/block/mtdblock4  /system      yaffs2 ro,relatime
18 sysfs                 /sys         sysfs  rw,relatime
19 /sys/kernel/debug     /sys/kernel/debug       debugfs    rw,relatime
20 proc                  /proc        proc   rw,relatime

[root@pc]# vol.py -f Evo4GRodeo.lime \
  --profile=LinuxEvo4GARM linux_dentry_cache> filelist

The filelist file contains the information you need, but only in the body file format, which is a raw data format that MACB-Time (from Sleuth Kit) converts into a readable MACB format (mactime -d filelist > filelist.mac). Figure 7 shows how a

Figure 7: Browser histories from the Android device's memory. Similar data is available for every app.

grep browser.db filelist.mac

command line provides the desired information. Volatility then provides the number of inodes required for the administrator to restore a file:

[root@pc]# vol.py linux_find_file \
  -F "/data/data/com.android.browser/databases/browser.db"
[...]
[root@pc]# vol.py linux_find_file -i 0xd3aebd20 -O browser.db

In contrast to Sleuth Kit, the virtual inode 0xd3aebd20 is used for identification purposes. You could use sqlitebrowser here, but the command line is also good for the analysis. Figure  8 shows a successful operation with sqlite3 browser.db and the list of tables contained (.tables). As you can see, the database obviously contains HTC bookmarks. They are revealed by a select * from htctopbookmarks; (Listing 6).

01 1|HTC|http://www.htc.com/|2|11|h|ht|htc
02 2|Google|http://www.google.com/|2|11|g|go|goo
03 3|Facebook|http://www.facebook.com/|2|11|f|fa|fac
04 4|Yahoo!|http://www.yahoo.com/|2|11|y|ya|yah
05 5|YouTube|http://www.youtube.com/|2|11|y|yo|you
06 6|Windows Live|http://www.live.com/|2|11|l|li|liv
07 7|Wikipedia|http://www.wikipedia.org/|2|11|w|wi|wik
08 8|Blogger.com|http://www.blogger.com/|2|11|b|bl|blo
09 9|Baidu.com|http://www.baidu.com/|2|11|b|ba|bai
10 [...]

Figure 8: The browser configuration from the memory of the running system can also be analyzed at the command line.

The Memory Dump Problem

If you want to create your own memory dumps, the process currently involves a huge amount of manual work related to source code, kernel, modules, and more. The following example describes a procedure that worked in our lab with Android 4.4 (KitKat uses kernel 3.4) and an HTC device. An illustrative – but not always consistent – guide from Google itself can be found online [18]. The prerequisite for success is the Android SDK, developer tools, and a cross compiler.

The example does not use the cross compiler from Google's Native Development Kit (NDK) [19], but the existing Ubuntu GNU cross compiler for ARM, because it was easier to talk this tool into cooperating. Just before a deadline, the authors received reports of success from employees of the Swiss Federal Office for Computer Science and Telecommunications, who managed to extract memory dumps using the NDK compiler. For Ubuntu, Listing 7 shows how to retrieve the Android kernel sources from Google's Git.

01 [root@pc]# aptitude install gcc-arm-linux-gnueabi
02 [...]
03 [root@pc]# git clone https://android.googlesource.com/kernel/goldfish.git /opt/android-source
04 [...]
05 [root@pc]# cd /opt/android-source/
06 [root@pc]# git branch -a
07 * master
08   remotes/origin/HEAD -> origin/master
09   remotes/origin/android-goldfish-2.6.29
10   remotes/origin/android-goldfish-3.4
11   remotes/origin/linux-goldfish-3.0-wip
12   remotes/origin/master
13 [...]
14 [root@pc]# git checkout -t remotes/origin/android-goldfish-3.4 -b goldfish-3.4
15 [...]
16 [root@pc]# export ARCH=arm
17 [root@pc]# export SUBARCH=arm
18 [root@pc]# export CROSS_

Now for the tricky bit: Before you compile the kernel sources, you need the right config for the kernel. This is zipped under /proc/config.gz on most devices; other manufacturers make life difficult for the forensic scientist by not installing the file. You sometimes even have to grab it from the source code archives. If the configuration files cannot be found either in forums or in installable open source mods, your only remaining option is painstaking trial and error.

Such a file should also reside on each virtual guest machine (that can launch the SDK); in rare cases, you might even find the file you need in the smartphone recovery system. Once you overcome this hurdle, you can unpack and edit the config file. You typically just need to insert or edit the three MODULES lines:

CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULES_UNLOAD=y
CONFIG_MODULES_FORCE_UNLOAD=y
CONFIG_BLOCK=y

Next, save the file in the source directory and call Make. If the kernel resides in /opt/android-source/arch/arm/boot/, for example, then the command (when run in this directory)

[root@pc]# svn checkout http://lime-forensics.googlecode.com/\
  svn/trunk/lime-android

downloads the Lime driver for Android, including the Makefile for Linux environments, heralding the start of individual problems with the specific devices.

As a general rule, KDIR_GOLD := /opt/android-source must point to the right path, but even the CROSS_COMPILE instruction options differ from device to device. What the approaches have in common is that they both do

ARCH=arm CROSS_COMPILE=$(CCPATH)/arm-linux -gnueabi

to invoke the cross compiler.

Loading the Lime Module

Referring to the example of an Android emulated by the SDK, Listing  8 shows how the Lime module ends up on the smartphone. Immediately after the module is loaded (once only, not on each restart; thus, insmod instead of modprobe), it saves a dump on the (virtual) SD card, which can be downloaded with the usual tricks.

01 [root@pc]# emulator -avd goldfish -kernel  /opt/android-source/arch/arm/boot/zImage -show-kernel -verbose
02 [root@pc]# adb push lime-goldfish.ko /sdcard/lime.ko
03 [root@pc]# adb shell
04 [shell@android]## insmod /sdcard/lime.ko "format=lime path=/sdcard/goldfish.lime"

Here, it makes sense to set up a Netcat connection (nc), if only because the data transfer is faster than going through the SD card.

Even if all of these steps have worked, however, Volatility still needs the correct extensions. Similar to the Linux kernels in a previous article [16], you need to run Make to produce system.map and module.dwarf, which end up as ZIP files in the Volatility profile directory. After entering

zip Goldfish-3_4.zip module.dwarf /opt/android-source/System.map

Vol.py now finds the new profile named Goldfish (Figure 9).

Figure 9: The first step has been taken: Volatility recognizes the Android profile.

After doing this and selecting the correct settings for your device in the makefiles and the kernel config, you can now start analyzing the memory dump. The command:

vol.py -f goldfish.lime \
  --profile=LinuxGoldfish-3_4ARM linux_mount

lists the existing mounts, even on Android, as described above.