Home > Uncategorized > Android Browser Forensics

Android Browser Forensics

Introduction

Reconstructing browser history is a well worn forensics task whether it be Internet Explorer, Firefox or Safari history and whether on Windows, Linux or Mac OSX. Occasionally we are faced with updating our skill sets and tools for example when Firefox switched from Mork to sqlite format for its browser history storage. With the steady flow of new devices especially in the mobile space the learning curve has become steep again. The following looks at some of the basics of browser history on Android mobile phones.

Hardware

The following analysis was done on the Samsung Android Galaxy S i9000 phone. The Galaxy is the international version of the U.S. Samsung Vibrant but they’re essentially the same phone. My Galaxy came with 16GB of internal memory. The card is formatted as a vfat file system and can be removed and imaged in the traditional way.

Software

The Samsung Galaxy runs a Linux 2.6 kernel and comes with a 1Ghz ARM processor. Currently I’m running Android 2.1 Eclair and the phone was rooted using the instructions at XDA and as detailed in my previous blog post. I have also pre-installed the Android SDK on my Mac OSX machine. You’ll find links to the different SDKs for your version of Android here including install instructions.

Internet browsing on Android

There are a number of different browser applications available for Android. All store their browser history in sqlite .db format. Some of the more common browsers include:

1. Firefox Mobile
2. Android Browser (default on all Android phones)
3. Dolphin
4. Opera Mini
5. Opera Mobile
6. Skyfire

During a forensics examination you may come across and need to account for browsing activity from one or a combination of the above. It’s advisable to determine in advance of an investigation what browsers you’re dealing with to ensure a thorough investigation.

Android Security Model

Under the Android security model an application’s (i.e. browser) process runs in a security sandbox. This ensures that no application has permission to perform any operations that would negatively impact other applications or the operating system. Each application gets its own unique User ID and Group ID and files for that application are sandboxed. This includes the applications .db files. Android also provides the developer with “Content Providers” which allow developers to share data across applications but this is beyond the scope of this article. This sandbox security model creates challenges for the forensics investigator. Browser history files are only available to the browser application itself or with root access to the phone. The below screenshot shows the User and Group IDs (app_108) for the Skyfire browser application.

The paths to the .db files for each browser above are as follows:

1. /data/data/org.mozilla.fennec
2. /data/data/com.android.browser
3. /data/data/??????
4. /data/data/com.opera.mini.android
5. /data/data/opera.browser
6. /data/data/com.skyfire.browser

Approaches

We examine a number of approaches to acquiring and reconstructing the browser history from an Android phone and where relevant the downsides of each approach.

First we look at pulling the browser history files directly off the device using the Android SDK and adb (the Android Debug Bridge). Adb is available once you install the Android SDK. For my Mac OSX install it’s found under /Applications/android-sdk-mac_x86/tools

First we open a Terminal Window and change directory to /Applications/android-sdk-mac_x86/tools. After putting the phone in USB Debug mode (Settings>Applications>Development>USB Debugging) and connecting it to the Mac via USB cable we issue the following command to confirm we have connectivity to the phone.

$ ./adb devices
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached
90000a7896ac device

$ ./adb shell

$ id
uid=2000(shell) gid=2000(shell) groups=1003(graphics),1004(input),1007(log),1011(adb),1015(sdcard_rw),
3001(net_bt_admin),3002(net_bt),3003(inet)

We don’t have superuser permissions and shouldn’t be able to pull browser history files from the device. Let’s test.

$ ./adb pull /data/data/com.skyfire.browser/databases/webviewCache.db
failed to copy ‘/data/data/com.skyfire.browser/databases/webviewCache.db’ to ‘./webviewCache.db': Permission denied
$

So confirmed by default we don’t have permissions to pull browser history for Skyfire from the device. Let’s try su to root and give ourselves read permissions.

$ su
#

Make sure the connected phone is not on the lock screen and when prompted confirm to allow super user permissions.

Change directory into the /databases folder and chmod webviewCache.db so that ‘everyone’ has read permissions.

# cd /data/data/com.skyfire.browser/databases
# ls -l
-rw-rw—- app_108 app_108 25600 2010-11-17 17:51 webview.db
-rw-rw—- app_108 app_108 27648 2010-11-17 17:52 webviewCache.db
-rw-r–r– app_108 app_108 8192 2010-10-28 10:33 skyfire.db
#

# chmod 664 webviewCache.db
# ls -l
-rw-rw—- app_108 app_108 25600 2010-11-17 17:51 webview.db
-rwxrwxrwx app_108 app_108 27648 2010-11-17 17:52 webviewCache.db
-rw-r–r– app_108 app_108 8192 2010-10-28 10:33 skyfire.db
# exit
$ exit

Let’s then go back to Terminal and using adb we try again to pull the web browser history file off the device and onto the local Mac OSX machine.

$ ./adb pull /data/data/com.skyfire.browser/databases/webviewCache.db /Applications/android-sdk-mac_x86/tools
666 KB/s (27648 bytes in 0.040s)
$

This time it works. Once we have the web cache file we can dump the history using the sqlite client.

$ sqlite3 webviewCache.db “SELECT * FROM cache;”
1|http://my.skyfire.com/|00a44035|||1290073890765|Thu, 18 Nov 2010 09:51:31 GMT|text/html|utf-8|200||10950|
2|http://my.skyfire.com/css/style-min.css|73742daa|Fri, 17 Sep 2010 22:58:52 GMT||1292406691342|Fri, 17 Dec 2010 09:51:32 GMT|text/css||200||3901|
3|http://my.skyfire.com/js/jquery/jquery-1.4.2.min.js|85dbb447|Fri, 17 Sep 2010 22:58:42 GMT||1292579491526|Fri, 17 Dec 2010 09:51:32 GMT|application/x-javascript||200||72174|
4|http://www.google-analytics.com/ga.js|7daacc1c|Mon, 08 Nov 2010 08:48:36 GMT||1290073892505|Wed, 17 Nov 2010 20:06:48 GMT|text/javascript||200||24505|
5|http://my.skyfire.com/js/jquery/jquery.cookie.min.js|5575125f|Fri, 17 Sep 2010 22:58:42 GMT||1292579492915|Fri, 17 Dec 2010 09:51:34 GMT|application/x-javascript||200||693|
$

From left to right the fields are:

_id
url
filepath
lastmodify
etag
expires
expirestring
mimetype
encoding
httpstatus
location
contentlength
contentdisposition

ok so this works but it’s not ideal. First off you would need a rooted phone to pull the web cache file. You’re also giving additional permissions to the browser history file. Neither would be considered sound forensic approaches.

Traditional Forensics approach

The traditional approach to a forensics investigation of a device is to take a bit for bit copy of the entire physical device, mount the copy as read only and examine it. With a mobile device such as an Android phone one challenge is the inability to remove a drive, attach a write-blocker and image the drive in this traditional way. A certain amount of interaction with the phone is necessary.

The Android phone uses NAND flash memory. However Linux only understands character and block devices. With Linux on flash, because flash memory devices are not seen as character or block devices a Flash Transition layer called Memory Technology Device (MTD) provides the interface between the Linux OS and the physical flash device.

Interestingly the Samsung Galaxy, unlike The Nexus G1 and HTC phones, mounts the /data folder on /dev/loop0 as an ‘ext2′ filesystem. If you do a cat /proc/mtd you get nothing. This makes it slightly easier for an examiner as the /data folder is not stored in the mtd memory on the phone.

If we run ‘mount’ on the phone we see /data mounted as /dev/loop0.

UPDATE: While doing further analysis it appears that the One Click Lag Fix (OCLF) for Android makes use of loopback mounts and I had run OCLF on my Galaxy phone to help with the known lag issues with the Galaxy and it subsequently reconfigured the OS to mount /data as loop0. /data is mounted as /dev/block/mmcblk0p2 on my Samsung Galaxy Tab and I expect that prior to applying OCLF that my Galaxy phone also used this mmc block device.

# mount
rootfs / rootfs rw 0 0
tmpfs /dev tmpfs rw,mode=755 0 0
devpts /dev/pts devpts rw,mode=600 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
/dev/block/stl6 /mnt/.lfs j4fs rw 0 0
tmpfs /sqlite_stmt_journals tmpfs rw,size=4096k 0 0
none /dev/cpuctl cgroup rw,cpu 0 0
/dev/block/stl9 /system rfs rw,vfat,llw,check=no,gid/uid/rwx,iocharset=utf8 0 0
/dev/block/mmcblk0p2 /data rfs rw,nosuid,nodev,vfat,llw,check=no,gid/uid/rwx,iocharset=utf8 0 0
/dev/block/stl10 /dbdata rfs rw,nosuid,nodev,vfat,llw,check=no,gid/uid/rwx,iocharset=utf8 0 0
/dev/block/stl11 /cache rfs rw,nosuid,nodev,vfat,llw,check=no,gid/uid/rwx,iocharset=utf8 0 0
/dev/block/stl3 /efs rfs rw,nosuid,nodev,vfat,llw,check=no,gid/uid/rwx,iocharset=utf8 0 0
/dev/block/mmcblk0p2 /dbdata/rfsdata rfs rw,nosuid,nodev,noatime,nodiratime,vfat,llw,check=no,gid/uid/rwx,iocharset=utf8 0 0
/dev/loop0 /dbdata/ext2data ext2 rw,noatime,nodiratime,errors=continue 0 0
/dev/loop0 /data ext2 rw,noatime,nodiratime,errors=continue 0 0
/dev/block/mmcblk0p2 /data/gps rfs rw,nosuid,nodev,noatime,nodiratime,vfat,llw,check=no,gid/uid/rwx,iocharset=utf8 0 0
/dev/block/mmcblk0p2 /data/misc rfs rw,nosuid,nodev,noatime,nodiratime,vfat,llw,check=no,gid/uid/rwx,iocharset=utf8 0 0
/dev/block/mmcblk0p2 /data/wifi rfs rw,nosuid,nodev,noatime,nodiratime,vfat,llw,check=no,gid/uid/rwx,iocharset=utf8 0 0
/dev/block/mmcblk0p2 /data/local rfs rw,nosuid,nodev,noatime,nodiratime,vfat,llw,check=no,gid/uid/rwx,iocharset=utf8 0 0
/dev/block/mmcblk0p2 /data/property rfs rw,nosuid,nodev,noatime,nodiratime,vfat,llw,check=no,gid/uid/rwx,iocharset=utf8 0 0
/dev/block//vold/179:1 /sdcard vfat rw,dirsync,nosuid,nodev,noexec,uid=1000,gid=1015,fmask=0102,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
#

We can then ‘dd’ the /data folder across to our /sdcard.

# dd if=/dev/loop0 of=/sdcard/forensics/imagefile.dd
1776592+0 records in
1776592+0 records out
909615104 bytes transferred in 458.374 secs (1984438 bytes/sec)
#

The resulting image file is approx 909MB. We then exit back to our host Mac OSX machine to the /tools folder and pull the .dd file to our local analysis machine.

$ ./adb pull /sdcard/forensics/imagefile.dd /Applications/android-sdk-mac_x86/tools
4395 KB/s (909615104 bytes in 202.080s)
$

We mount the image as we would any typical forensics image file and do our analysis.

$ sudo mount -o loop imagefile.dd /media/galaxy
$ cd /media/galaxy/data/data/com.skyfire.browser/databases/
$
$ ls -l
-rw-r–r– 1 10108 10108 8192 2010-10-28 10:33 skyfire.db
-rw-rw-r– 1 10108 10108 27648 2010-11-17 17:52 webviewCache.db
-rw-rw—- 1 10108 10108 25600 2010-11-17 17:51 webview.db
$

$
$ file webviewCache.db
webviewCache.db: SQLite 3.x database, user version 3
$

The same approach as we used earlier to extract the browser history will work for us.

# sqlite3 webviewCache.db “SELECT * from cache;”
1|http://my.skyfire.com/|00a44035|||1290073890765|Thu, 18 Nov 2010 09:51:31 GMT|text/html|utf-8|200||10950|
2|http://my.skyfire.com/css/style-min.css|73742daa|Fri, 17 Sep 2010 22:58:52 GMT||1292406691342|Fri, 17 Dec 2010 09:51:32 GMT|text/css||200||3901|
3|http://my.skyfire.com/js/jquery/jquery-1.4.2.min.js|85dbb447|Fri, 17 Sep 2010 22:58:42 GMT||1292579491526|Fri, 17 Dec 2010 09:51:32 GMT|application/x-javascript||200||72174|
4|http://www.google-analytics.com/ga.js|7daacc1c|Mon, 08 Nov 2010 08:48:36 GMT||1290073892505|Wed, 17 Nov 2010 20:06:48 GMT|text/javascript||200||24505|
5|http://my.skyfire.com/js/jquery/jquery.cookie.min.js|5575125f|Fri, 17 Sep 2010 22:58:42 GMT||1292579492915|Fri, 17 Dec 2010 09:51:34 GMT|application/x-javascript||200||693|
[snip]
#

The advantage of taking an image in this manner is that we have access to the full /data folder and can extend our investigation and analyze data storage for multiple applications if necessary.

Open Source Android browser framework

It’s worth mention an open source Android forensics framework by a company called ViaForensics. The application is installed and runs on the Android phone itself and pulls – among other things – browsing history from the phone. The application appears to only be available to law enforcement although there was some mention of it being made available to the public. For now it doesn’t appear to be possible to download the .apk from its Google Code site. In addition it’s my understanding that it only works for the default Android Browser.

$ ./adb devices
List of devices attached
90000a7896ac    device
$

$ ./adb install AndroidForensics.apk
21 KB/s (20138 bytes in 0.907s)
pkg: /data/local/tmp/AndroidForensics.apk
Success

$

Under Applications you’ll find an icon for the newly installed Android Forensics app called ViaForensics.

Click on the application and you’re presented with the following screen.

Each option is checked by default. Click Capture. A folder is created on the internal sdcard called ‘forensics’ with 6 .csv files.

You can then use the Android SDK and adb as we did earlier to pull the resulting csv files off the sdcard onto your host machine.

$ ./adb pull /sdcard/forensics /Applications/android-sdk-mac_x86/
pull: building file list…
pull: /sdcard/forensics/20101112.2331.SMS.csv -> /Applications/android-sdk-mac_x86/20101112.2331.SMS.csv
pull: /sdcard/forensics/20101112.2331.People.csv -> /Applications/android-sdk-mac_x86/20101112.2331.People.csv
pull: /sdcard/forensics/20101112.2331.Organizations.csv -> /Applications/android-sdk-mac_x86/20101112.2331.Organizations.csv
pull: /sdcard/forensics/20101112.2331.ContactMethods.csv -> /Applications/android-sdk-mac_x86/20101112.2331.ContactMethods.csv
pull: /sdcard/forensics/20101112.2331.CallLogCalls.csv -> /Applications/android-sdk-mac_x86/20101112.2331.CallLogCalls.csv
pull: /sdcard/forensics/20101112.2331.Browser.csv -> /Applications/android-sdk-mac_x86/20101112.2331.Browser.csv
6 files pulled. 0 files skipped.
15 KB/s (92966 bytes in 5.857s)
$

Then it’s a simple matter to load up the CSV files in something like OpenOffice for analysis.

Conclusion

Although there is some good research in the field, Android forensics in general is quite new. Research in this area is moving fast however and there’s rumours of an Android forensics book in the making so keep an eye on Amazon. In my next blog post I may look at further analysis of the android dd image above including Skype and Meebo chat logs.

About these ads
Categories: Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: