To say that Samsung Kies is a poor piece of software is an understatement. You only need to trawl through the Android or Samsung forums to see the frustration it causes people. It’s buggy, unstable and in many cases just doesn’t do what it’s supposed to do especially in terms of firmware upgrades. If you are plagued by lag issues on Eclair and Froyo then you’ll probably argue that Samsung just can’t write software at all – for all their prowess in the hardware space.
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:
+ 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)
+ 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.
This is less of a blog entry and more of a reference image for correct cable connectivity when attaching a SATA drive to a Tableau T35e USB to SATA forensic bridge.
So here it goes:
This is my first non-technical blog post but arguably on a topic of similar importance to technical ability namely the importance of being prepared in advance of a forensics engagement. Rather than write an essay I’m going to put this down in ten bullet points.
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:
- 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 Tableau T35e is a SATA/IDE forensic write blocker and allows imaging of 3.5″ and 2.5″ IDE and SATA drives. The kit comes with a 2.5″ hard drive adapter for imaging notebook drives.
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.
During a malware investigation it helps to be able to extract the domain portion of a URL from a web proxy log to identify the communications between a compromised host and an external botnet command and control server. This assumes you know the URL being used for outbound communication, have an infrastructure where all outbound http traffic is routed through a proxy under control of your organization or have access to the logs from the proxy server.
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]
from urlparse import urlparse
f = open(sys.argv, “r”)
for line in f.readlines():
line = re.findall(r’(https?://\S+)’, line)
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
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
- 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.
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
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.
$ ./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.
/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)
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
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 ..
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
- 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.
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.
MobilEdit Forensics edition is a Forensics investigation tool for Mobile devices allowing recovery of SMS/Call Logs/Calendar Data and more from a comprehensive range of mobile phones.
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.