Anyway I struggled with the Froyo upgrade for months before finally getting Kies to work albeit with a newer ‘improved’ version of Kies (v2). I’ve documented the steps below. These also apply to the recent Gingerbread 2.3.3. Do note that Google recently (April 2011) put a stop to any further downloads of Gingerbread for the Galaxy S due to unknown reasons but knowing Samsung’s track record it doesn’t really surprise me. The update was subsequently reinstated and having run Gingerbread on my Galaxy S for a few weeks already it’s well worth the effort. It’s given new life to my oldish phone and I’ve put off any future Android purchase until Ice Cream Sandwich is available later this year.

So here goes:

Preparation:

+ Remove any One Click Lag Fixes (OCLF). This step is critically important as you can brick your phone trying to do an upgrade if you don’t remove all OCLFs.

+ Some people say to unroot your phone if it’s rooted but I didn’t do this and had no issues. You will lose root however and you will need to reapply it after the upgrade.

+ Charge the phone fully to 100%. Actually the upgrade appears to work as long as you are somewhere above 50% charge.

+ Ensure 3GB free space on the Windows PC being used to do the upgrade or you’ll get errors.

+ Remove any home screens and revert back to twlauncher default. You don’t need to uninstall. I use the home switcher app in Marketplace to switch between Launcher Pro and TWLauncher. If you’re on Froyo there’s a Froyo version of Home Switcher but the older Eclair version worked fine for me.

+ Remove the external sd card from the phone. This is quirk with MTP protocol that can send the phone (and you) loopy.

+ Finally if you use your phone for critical communications like work you may want to keep an old spare phone at hand in case the upgrade fails on you.

+ Download and install the latest version of Samsung Kies (v2)

Steps:

+ Close Kies

+ Put the phone in USB Debugging Mode (Settings, Applications, Development)

+ Connect phone to the Windows PC and allow Windows to install the relevant drivers

+ Check Device Manager for proper install

+ The following screenshots show correct installation in Device Manager

+ Now take the phone out of USB debugging mode

+ Put the phone into Kies Mode under USB Settings

+ Put the phone at the Idle screen and unlock any lock pattern

+ Connect the phone to the PC

+ Wait for the Connected message from MTP on the phone

+ You must have the Connected message before going any further. If the phone sits at Initialising and never moves to Connect try rebooting the PC and then the phone is still having issues.

+ Now open Kies.

+ Don’t touch Kies when you see it in the Taskbar. Don’t maxmize it. Not sure what difference this makes and maybe it doesn’t on the majority of machines but it caused issues for me if I maximized it.

+ Kies should pop up a dialog that your phone needs a firmware upgrade and prompt you to click Update .

+ If you are on Eclair you will need two upgrades – one to Froyo and a second to Gingerbread and again this is confirmed by a dialog box.

+ The following screens are shown on the PC.

Then a big yellow “Downloading. Do not turn off target” graphic appears on the phone screen with a blue progress indicator. A progress indicator also appears in Kies.

Phone reboots by itself after some final installation steps scroll past on the phone display.
Kies confirms that upgrade is complete and provides backup/restore message.
The phone can take a long time to reboot after the upgrade. Much longer than usual. Be patient.

When the phone reboots it asks questions like:

1. Setting On-screen keyboard settings
2. Internet connection (3G network or wifi)
3. Whether you wish to use google location services (no thanks I uncheck this)

Then finally it scans all media files on the sd card which can take a minute or so.

To confirm your firmware update go to Settings, About Phone and check the Firmware version.

To update to Gingerbread you need to go through the same steps again with Kies.

That’s it. Good luck.

So here it goes:

Tableau T35e SATA bridge

1. Firstly prepare a forensics jump bag. There are plenty of web sites that list the basics of a jump bag and in time you’ll customize your own. Don’t pilfer from the bag when not in use. Have it beside you at all times so you can pick it up and go at a moment’s notice. Include the following items at a minimum:

- Pens
- Paper
- Notepads where you can’t easily remove pages. No ring pads.
- Name cards
- LAN/cross cables (clearly marked as such)
- Forensics CDs (Helix, Backtrack, Linen)
- Thumb drives
- Screwdriver set
- IDE/SATA cables
- Evidence labels
- Cheap Digital camera

2. Have a forensics laptop separate from your production laptop. Install Encase, FTK, Sleuthkit, Tableau software and any other forensics tools you need. Avoid using it as your production laptop. i.e. No email, Microsoft Office, Web Browsing.

3. Bring documented procedures to double check your approach against. Also bring soft and hard copies of Chain of Custody and Acquisition Seizure Log documents. Have everything written down even for the most simple tasks. You’d be amazed at how much and how quickly you forget things even from a recent engagement.

4. Test carry your forensics field kit through airport customs in advance of any engagement to ensure you have anticipated questions or security/customs issues. The last thing you want is to arrive on site without your Tableau or Webetech hardware write blockers. If you are in a geographically dispersed region (as I am in Asia) it pays to understand how different customs practices differ between countries. You may be good-to-go in one country but hopelessly stymied in another. It’s not practical to test every location so some background research might be the only other option.

5. When imaging take two sets of images and send one set back via company internal mail or courier. Password-protect the other set of images and hand carry back with you to the office. This means that if customs take possession of your hand-carried set at least the couriered set should make it to the office within a couple of days. Also make allowances for the additional time needed for taking two sets instead of one.

6. Make sure you have IT support available on the other end especially if it’s over a weekend and you need access to machine rooms, other secure areas or information about other peculiarities of the IT setup at your destination.

7. Make sure there isn’t a building power down the weekend of your engagement. (yes this happened to me once). If there is then ensure you arrange for a UPS protected area to do your work.

8. There will be cases when you go on-site and are faced with a completely new set of circumstances. However try to test different scenarios in the lab as much as possible. It’s impossible to preempt all situations but have the basic stuff tested and documented and be comfortable with it.

9. Know your tools. Know their strengths and just as important – know their weaknesses. Stick with what you know works. A customer engagement isn’t the best time for experimenting.

10. Have an agreed means of contacting your other team members should the need arise. You can’t know everything about every scenario and some situations require group-think to resolve.

Note: Make sure you know where to buy snacks and drinks. If you need to work into the night get the phone number of a food delivery service from the local staff or stock up on sandwiches and chocolate before all the stores close for the day.

The below image shows the T35e connected to a 2.5″ 120GB Western Digital drive. The Tableau is then connected to an imaging workstation (out of picture) via the provided USB cable. Power is provided to the WD drive via the Tableau device as shown. For correct connectivity the IDE Detect, Host Detect and Write Block LEDs should be illuminated.

Below screenshot shows the Tableau software on the imaging workstation confirming Tableau connectivity to the target drive.

Note that under ‘Forensic Bridge Information’ the entry for the T35e says ‘Read Only Mode’. On the underside of the Tableau there is a 4-position DIP switch that can be used to set a variety of configurations. The switches are accessed by removing a small knockout panel on the bottom edge of the bridge’s plastic enclosure. The default READ-ONLY mode can be used to take forensically sound images from subject hard disks. In most circumstances Windows XP handles Tableau READ-ONLY bridges correctly with switches 2 and 3 in the OFF (default) state. See the T35e User’s Guide for more details.

Imaging was done using Encase and is detailed in the following screenshots.

1. Launch Encase

2. Create a New Case

3. Click Add Device

4. Uncheck ‘Sessions’ check box

5. Blue check ‘Local Drives’

6. Allow Encase to process locally attached drives

The following screenshot shows the list of local drives processed by Encase.

7. Blue check the drive to be Previewed and then Click Next and Finish as in the screenshot below.

8. The activity LED on the Tableau device should flicker red as the drive is being previewed

9. When completed the preview will be added to the case

10. You can then acquire a physical image of the drive by right clicking and choosing ‘Acquire’

A full bit for bit, forensically sound image will be taken of your target drive. The image is stored in Encase E01 format. Make sure to save the case before you exit.

There are plenty of complicated regex expressions for parsing URLs and extracting domains but Python provides a much more elegant way to do this using its ‘urlparse’ module. The following sample code takes a single proxy log file as input and extracts only the domain portion of the URL for further analysis.

[usage: python parseurl.py logfilename]

#!/usr/bin/python
import re
import sys
from urlparse import urlparse

for line in f.readlines():
 line = re.findall(r’(https?://\S+)’, line)
 if line:
  parsed=urlparse(line[0])
  print parsed.hostname
f.close()

You can carry out further log reduction by piping the results through ‘uniq’.

$ python parseurl.py proxylog-zeus-10.1.1.1-2011.02.16_15.54.csv

bits.wikimedia.org
upload.wikimedia.org
geoiplookup.wikimedia.org
en.wikipedia.org
bits.wikimedia.org
en.wikipedia.org
ad.doubleclick.net
s0.2mdn.net
ad.doubleclick.net
s0.2mdn.net
tools.google.com
library.municode.com
tools.google.com
15february.adina-blog.co.cc
freephoenixbirdspace.com
www.adb.cba.pl

[SNIP]

The last three domains look like they need further investigation.

I now have a new addition to my Android family of devices namely the Galaxy Tab. I had a play around with the device to see if there were any differences between it and the Galaxy phone from a forensics analyst point of view. I didn’t expect to find many. The Tab ships by default with Android 2.2 Froyo. My Galaxy phone came with Android 2.1 and the responsiveness of 2.2 is immediately obvious. None of the infamous 2.1 lag.

Unlike the Samsung Galaxy phone the back of the Tab is sealed. The SIM and SD Card slots are situated along the right edge together with the power/screen lock and volume rocker. It’s not immediately obvious how to orient the SIM card when you slot it in for the first time. I had to find an online diagram to assist me. The SIM card itself (as with the Galaxy phone) is the traditional SIM size and not the micro SIM that the iPad uses.

The device doesn’t have the standard micro USB connector that the Galaxy phone sports. On its underside it does however have a proprietary Samsung 30-pin connector which allows you (along with the shipped USB cable) to connect a Galaxy tab to a PC or Mac. The connector looks similar to the Apple iPad / iPhone connector but it is in actual fact different.

Apparently Samsung did consider using a standard microUSB port instead, but that would’ve ruled out accessories such as HDMI cables, so they went for the proprietary connector. Once connected via USB to my Mac I was able to connect to the device via ./adb and the Android SDK as I did previously with the Galaxy phone.

One item of note with the Galaxy Tab (maybe it’s an Android 2.2 thing, not sure) but on the Tab if you connect the device to your workstation via USB first and then try to enabled USB Debugging you’ll find the option dimmed. The solution is to remove the USB cable between the Tab and your workstation then go into Settings/Applications first, enable USB Debugging then reconnect the Tab. Once you do this you can run ./adb devices and you’ll see the Tab show up in the list of attached devices.

$ ./adb devices
List of devices attached
10000c22c5e5 device

$

- Turning off radio devices

Use ‘Flight Mode’ to turn off wireless and data network access on a seized Galaxy Tab. This prevents any data being received by the phone externally. This means an examiner can avoid turning off a phone which when turned on again may present a PIN password prompt. Turning off and on a phone may also interfere with date and time stamps of files on the phone. The ‘Flight Mode’ menu can be accessed on the Galaxy Tab by pressing and holding the power button for 2 seconds.

Remember that you should only submit as evidence data recovered from the phone before it was seized so it’s important to drop the phone in a Faraday bag or turn off radio devices as soon as possible after the phone is seized.

- Rooting the Tab

Pulling data off the Tab requires admin access so although it’s not ideal as a forensically sound approach we do need to ‘root’ the Tab to gain superuser privileges. I used the Z4Root one click root from ZDA to root the phone. It’s decidedly easier than the 2.1 root process of rebooting into recovery mode and downloading and applying the required update.zip. With Z4Root you have the option of a temporary root until the next reboot or a permanent root. You also have the option of unrooting the phone. Z4Root used to be available on the Marketplace but it was pulled. You can still find it online through Google. The .apk file installs an app in the Applications folder which you then tap on to root the phone. Following is a screenshot of Z4Root after rooting my Tab. The install screen looks similar.

When an application requests superuser privileges z4root pops up the following request dialog:

- Forensic Analysis

Circling back to my earlier Android forensics blog posts here and here I first wanted to see if the ViaForensics and MobilEdit applications installed and ran without issue on the Galaxy tab. They both did and I won’t recycle the earlier work for this blog post.

Once the phone was rooted the next thing I did was to run ./adb shell from the Android SDK and su to root then run mount. I noticed that the /data folder was not mounted as loop0 as it was with the Galaxy phone. On my Tab it was mounted as /dev/block/mmcblk0p2. I found this unusual so I did some research and 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 lag issues. To test I removed the OCLF from my Galaxy phone and after removal my /data folder was no longer mounted on /dev/loop0 but mounted as /dev/block/mmcblk0p2.

So the default device for /data on the Galaxy Tab or Galaxy S phone is /dev/block/mmcblk0p2 – (where ‘mmc’ refers to MultiMediaCard – a flash memory card standard and is a block specific device and on the Galaxy tab is formatted as vfat).

The following shows the results of issuing the mount command on the Tab.

$ su
# mount
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,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
/dev/block/stl6 /mnt/.lfs j4fs rw,relatime 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/stl9 /system rfs ro,relatime,vfat,log_off,check=no,gid/uid/rwx,iocharset=utf8 0 0
/dev/block/mmcblk0p2 /data rfs rw,nosuid,nodev,relatime,vfat,llw,check=no,gid/uid/rwx,iocharset=utf8 0 0
/dev/block/stl10 /dbdata rfs rw,nosuid,nodev,relatime,vfat,llw,check=no,gid/uid/rwx,iocharset=utf8 0 0
/dev/block/stl11 /cache rfs rw,nosuid,nodev,relatime,vfat,llw,check=no,gid/uid/rwx,iocharset=utf8 0 0
/dev/block/stl3 /efs rfs rw,nosuid,nodev,relatime,vfat,llw,check=no,gid/uid/rwx,iocharset=utf8 0 0
/dev/block/vold/179:1 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0

We then try to image /data. As you can see below the process for imaging the /data folder is no different to the process we followed for the Galaxy S phone. The only slight difference is that sdcard is mounted on /mnt/sdcard.

# cd /mnt/sdcard

# ls -l
drwxrwxr-x system sdcard_rw 2005-01-01 00:00 svox
drwxrwxr-x system sdcard_rw 2010-11-06 03:45 Android
drwxrwxr-x system sdcard_rw 2010-11-06 03:46 LOST.DIR
drwxrwxr-x system sdcard_rw 2010-11-06 03:46 external_sd
drwxrwxr-x system sdcard_rw 2010-12-13 22:18 DCIM
drwxrwxr-x system sdcard_rw 2010-12-14 00:23 download
drwxrwxr-x system sdcard_rw 2010-12-07 19:30 mabilo
drwxrwxr-x system sdcard_rw 2010-12-31 17:00 data
drwxrwxr-x system sdcard_rw 2010-12-13 22:18 ScreenCapture
drwxrwxr-x system sdcard_rw 2011-01-22 15:33 screenshots
drwxrwxr-x system sdcard_rw 2010-12-13 23:40 Video
drwxrwxr-x system sdcard_rw 2010-12-14 13:33 SpeedSoftware
-rwxrwxr-x system sdcard_rw 8 2010-12-14 13:47 devicefriendlyname.txt
drwxrwxr-x system sdcard_rw 2010-12-22 23:10 Music
#

# pwd
/mnt/sdcard

Create a new directory on the sdcard called ‘forensics’ to take the new image file then ‘dd’ the /data folder.

# mkdir forensics

# dd if=/dev/block/mmcblk0p2 of=/mnt/sdcard/forensics/imagefile.dd
3932032+0 records in
3932032+0 records out
2013200384 bytes transferred in 360.356 secs (5586698 bytes/sec)
#

We then exit back to our Mac Terminal prompt and issue an ./adb pull to copy the image file off the phone and back to our forensics workstation.

#exit
$exit

$ ./adb pull /mnt/sdcard/forensics/imagefile.dd /Applications/android-sdk-mac_x86/tools
5821 KB/s (2013200384 bytes in 337.709s)
$

- Investigating the ‘System’ Folder

In certain circumstances it may be worth while imaging the /system folder. /System contains operating system files and configuration details and is mapped to /dev/block/stl9.

#mount

[snip]

/dev/block/stl9 /system rfs ro,relatime,vfat,log_off,check=no,gid/uid/rwx,iocharset=utf8 0 0

Let’s go ahead and image the /system folder.

# dd if=/dev/block/stl9 of=/mnt/sdcard/forensics/imagefile_sys.dd
656384+0 records in
656384+0 records out
336068608 bytes transferred in 38.858 secs (8648633 bytes/sec)
# exit
$ exit

Again we pull the resulting image back to our forensics workstation.

#
$./adb pull /mnt/sdcard/forensics/imagefile_sys.dd /Applications/android-sdk-mac_x86/tools
3533 KB/s (336068608 bytes in 92.888s)
$

The system folder is unlikely to see major file activity so it may be worthwhile creating a timeline of file system activity on this folder to detect unusual activity especially if you’re dealing with a malware investigation. You can create a rudamentary timeline using the ‘ls’ command and sorting by date. This will sort files by subfolder so it’s not ideal. A more efficient approach is to use the Sleuthkit’s ‘fls’ and ‘mactime’ tools to respectively create a Bodyfile and resulting Timeline. In the example below there are very few files with date stamps later than the date the phone was installed. This doesn’t of course mean malware couldn’t manipulate time stamps to hide among system files but a timeline is still a good place to start.

# ls -latrR /media/android >> timeline.android
# gedit timeline.android

[snip]

- Android 2.2 and applications on SD card

With Android 2.2 a user now has the ability to install apps on an external SD card. By default, applications continue to be installed in internal memory however in the Settings/Applications menu you can move apps to the SD Card with one click if the application itself supports it. This is something to keep in mind when investigating the use of Android applications. The application itself may be found in one of two different locations on the phone. Note however that the application data continues to reside on internal memory in the /data folder.

The following screenshot shows the “Move to SD card” option for the Skype application on Android 2.2.

- Conclusion

Apart from the different physical attributes of the Galaxy Tab over the Galaxy phone there is very little difference in the way the two are approached from a forensics standpoint. The underlying OS on both devices is Linux and the File system format is VFAT so many of the open source Linux based forensics tools work well on the Samsung Android devices.

There is talk in the industry of Google standardizing on the EXT4 filesystem for all future releases of the Android OS. This should make life a little easier for forensic examiners confronted with the YAFFS flash filesystems used on certain other Android smartphones. As of the date of publishing of this article neither Encase nor Sleuthkit currently support EXT4.

Pricing for the Forensics Edition is USD600 for unlimited phones and unlimited updates. A trial version is available with the Reporting Module disabled. It appears only to be available to Law Enforcement.

With MobilEdit the approach to analysing an Android phone is very similar to the ViaForensics method described in an earlier blog post. A small .apk file is provided which installs an application called “Backup ME” on the Android phone. Running the application extracts phone data into a .mea file on the phones internal sd card which is then used by MobilEdit to create a Forensics Report. Let’s step through the process. Again we’re interacting directly with the phone as we did before.

On the phone itself open your browser of choice and navigate to http://download.mobiledit.com/MeReports.apk and click “Save” to begin download.

Once the .apk file has downloaded click ‘Open’ to install it. Confirm the install by tapping the Install button.

Locate the “Backup ME” application in the Android Applications folder. Tap on the application icon to run it.

In the resulting screen click “Backup Now”.

A progress indicator shows progress of the backup process. The application creates a file in the root of the sdcard on the phone with the naming convention mereport_YYMMDD.mea.

Confirmation that the backup was successful and the time taken to run.

You now need to connect the Android phone under investigation to your forensics workstation. The internal sdcard where the .mea file is stored is auto dismounted when you connect the phone via USB cable. Pull down the Notifications tray and mount the sd card. On a Windows machine launch the MobilEdit application. When you first launch the application the wizard should appear automatically. Alternatively you can run the Connection Wizard from the File menu. As mentioned above the Reporting Module is disabled unless you’ve purchased and activated the full product.

The Connection wizard then launches. Click “Connect a Phone” to continue.

In the resulting screen click on “Cell Phone (Mobile Phone)” and click Next>.

Then choose the “File (Android Phones)” option.

The next screen reminds you to install and run the “Backup ME” Android application that we ran earlier. Click Next> on this screen.

You will then be prompted to browse to the earlier created .mea file on the phone.

Once you choose the .mea file the application generates the Forensics report. I don’t have the full version of MobilEdit so I’m not able to show the resulting report.

The Android Marketplace provides an Android version of Wireshark called “Shark for Root”. The “Root” simply means you need a rooted phone for it to capture packets. There’s also a Shark Reader which gives rudimentary ability to view .pcap files captured from Shark. Shark Reader can be launched independently of Shark or from within the Shark App itself. Below is a screenshot from the MarketPlace showing both apps.

Once the apps are installed they appear on your phone as follows:

Now launch Shark for Root. The default parameters are for verbose capture and snap length 0 which gives the entire packet. Click Start and start capturing packets. The app is ad supported so you’ll need to put up with the adverts on the top of the screen. You can also see the option I mentioned earlier to open Shark Reader from within Shark for Root.

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

$ 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
$

$

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.

1. Download and install the Android SDK. I installed the x86 version for Mac OSX.

2. On the phone go to Settings>Applications>Development and turn on USB Debugging.

3. Copy the Update.zip (here) to the root of your internal SD card. This is /sdcard on your phone.

4. Connect the phone to the Mac via USB cable.

5. Go to a Terminal prompt

5. cd to /Applications/android-sdk-mac_x86/tools

6. Run ./adb reboot recovery

7. The phone will reboot into Recovery Mode.

8. Use the Volume rocker to highlight the option to apply Update.zip and then hit the Home key. The phone will reboot.

9. Once the phone reboots check for the existence of the Ninja icon with the sniper rifle in Applications. See screenshot below.

A sample of applications requiring Superuser access are:

1. Root Explorer – Allows you to browse protected areas of the file system.
2. One Click Lag Fix – Fixes Lag issues on the Samung Galaxy
3.

Once your phone is rooted and you try to run a program that requires root privileges a dialog will pop up asking you to confirm su access for the application and if we should continue to provide root access in future whenever the application is launched. The below screenshot shows Root Explorer requesting superuser privileges.

Note: You won’t see any files in the data folder if you try to browse using Astro or the built in File Manager as you require root privileges to browse this folder. With a rooted phone and a Marketplace app called Root Manager you will see these hidden files.