Home > Uncategorized > Investigating the Samsung Galaxy Tab

Investigating the Samsung Galaxy Tab

– Introduction

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

/media/android:
total 144
drwxr-xr-x 14 root root 4096 1970-01-01 08:00 .
drwxr-xr-x 5 root root 28672 2010-10-02 01:24 lib
drwxr-xr-x 2 root root 4096 2010-10-02 01:24 xbin
drwxr-xr-x 4 root root 4096 2010-10-02 01:24 media
drwxr-xr-x 7 root root 4096 2010-10-02 01:24 usr
drwxr-xr-x 2 root root 8192 2010-10-02 01:24 framework
drwxr-xr-x 2 root root 4096 2010-10-02 01:24 fonts
drwxr-xr-x 11 root root 4096 2010-10-02 01:24 etc
-rwxr-xr-x 1 root root 227 2010-10-02 01:24 default.prop
drwxr-xr-x 2 root root 4096 2010-10-02 01:24 cameradata
-rwxr-xr-x 1 root root 2276 2010-10-02 01:24 build.prop
drwxr-xr-x 3 root root 4096 2010-11-06 03:45 wallpaper
-rwxr-xr-x 1 root root 1104 2010-11-06 03:45 SW_Configuration.xml
-rwxr-xr-x 1 root root 12 2010-11-06 03:45 CSCVersion.txt
-rwxr-xr-x 1 root root 278 2010-11-06 03:45 CSCFiles.txt
drwxr-xr-x 16 root root 4096 2010-11-06 03:45 csc
drwxr-xr-x 3 root root 16384 2010-12-14 00:58 bin
drwxr-xr-x 2 root root 32768 2010-12-14 00:58 app
drwxr-xr-x 14 root root 4096 2011-02-03 14:49 ..

/media/internal/lib:
total 57364
drwxr-xr-x 14 root root 4096 1970-01-01 08:00 ..
-rwxr-xr-x 1 root root 75136 2010-10-02 01:24 libz.so
-rwxr-xr-x 1 root root 2012648 2010-10-02 01:24 libXt9core.so
-rwxr-xr-x 1 root root 42752 2010-10-02 01:24 libxml2wbxml.so
-rwxr-xr-x 1 root root 9492 2010-10-02 01:24 libwpa_client.so
-rwxr-xr-x 1 root root 5870 2010-10-02 01:24 libwmx_oma.so
-rwxr-xr-x 1 root root 116232 2010-10-02 01:24 libwmlscriptcore.so
-rwxr-xr-x 1 root root 342360 2010-10-02 01:24 libwmdrm.so
-rwxr-xr-x 1 root root 13544 2010-10-02 01:24 libwmdrm_jni.so
-rwxr-xr-x 1 root root 29812 2010-10-02 01:24 libwlservice.so

[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.

Advertisements
Categories: Uncategorized
  1. FN
    September 27, 2011 at 4:52 pm

    You are dd and writing the image file to the SDcard on the galaxy tab?
    Won’t that override deleted data on the device?
    I use netcat to throw the image to my mac, its on the adhoc wifi network but i think it
    will override some sectors too.

  2. September 28, 2011 at 10:16 am

    Fair point. Thanks for the comment and suggestion.

  1. February 20, 2012 at 2:04 am

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

%d bloggers like this: