A Triumph for Forensics!

I was asked to process a Motorola Triumph Android smartphone recently.  It was pattern locked and usb debugging wasn't enabled, so pushing exploits through the Android Debug Bridge was out.  I the day before, I updated the system rom on a Motorola Droid, and in the process I learned a bit more about the various boot modes of Android devices.

Recovery Mode

The original Motorola Droid provided the ability to create a simple (user data and system) or advanced backups (adds additional user selected partitions to the backup).  Nandroid is the backup mechanism.  I performed the backup to the installed MicroSD card without any difficulty, despite the device being pattern locked and unrooted.  I wondered: do all Android devices have an inherent backup option in recovery mode?  Could it be that easy to get data from a device?  Of course not!  Most recovery images do not allow for backups to be created, which is why you will find a thriving recovery image culture on the web.

Flashing a custom recovery image, like clockworkmod, replaces the stock recovery image with the custom image.  There are a myriad of ways to do this, and I don't recommend you do this willy nilly.  For the purposes of this post, I don't need to go into the details.  Suffice it to say, I was able to flash a modified recovery image to the Droid and get greater access to the device, so I considered flashing the recovery image of the Triumph to add the ability to backup the data.  My thinking: create a backup on an sd card of my own, and extract the gesture.key to decode the pattern lock.

Download Mode

The first step to flashing a recovery image is to put the device in download mode.  The purpose of download mode is to flash firmware to the device.  I discovered the method to enter download mode, and then plugged the device into my Linux workstation once download mode was active.  This is where things got really exciting: By simply plugging the device into the workstation while in download mode, I had access to the phone's NAND memory as a block device and the ability to mount seven partitions!

Don't believe me?

$ fdisk -luDisk /dev/sdh: 1912 MB, 1912602624 bytes
1 heads, 62 sectors/track, 60250 cylinders, total 3735552 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
   Device Boot      Start         End      Blocks   Id  System
/dev/sdh1               1      204800      102400    c  W95 FAT32 (LBA)
/dev/sdh2   *      204801      205800         500   4d  QNX4.x
/dev/sdh3          205801      208800        1500   46  Unknown
/dev/sdh4          208801     3735551     1763375+   5  Extended
/dev/sdh5          212992      229375        8192   48  Unknown
/dev/sdh6          229376      245759        8192   50  OnTrack DM
/dev/sdh7          245760      753663      253952   82  Linux swap / Solaris
/dev/sdh8          753664     2998271     1122304   83  Linux
/dev/sdh9         2998272     3162111       81920   6c  Unknown
/dev/sdh10        3162112     3227647       32768   6a  Unknown
/dev/sdh11        3227648     3637247      204800   6b  Unknown
/dev/sdh12        3637248     3653631        8192   7b  Unknown
/dev/sdh13        3653632     3670015        8192   7a  Unknown
/dev/sdh14        3670016     3686399        8192   78  Unknown
/dev/sdh15        3686400     3702783        8192   79  Unknown
/dev/sdh16        3702784     3719167        8192   7c  Unknown
/dev/sdh17        3719168     3735551        8192   7d  Unknown

$ blkid
/dev/sdh1: SEC_TYPE="msdos" LABEL="MOBILE" UUID="4C5A-5671" TYPE="vfat"
/dev/sdh7: LABEL="system" UUID="d3e843eb-0c62-4ab6-83c6-eeb31f8c556e" TYPE="ext3"
/dev/sdh8: LABEL="userdata" UUID="c62a3dda-8776-4fb2-a8a2-bd1a02f45440" TYPE="ext3"
/dev/sdh9: LABEL="cda" UUID="c0de041c-c97b-489d-9f6e-81b4e1be8665" TYPE="ext3"
/dev/sdh10: LABEL="hidden" UUID="676aed0f-cb4d-4214-b34d-a0dbb04fcccf" TYPE="ext3"
/dev/sdh11: LABEL="cache" UUID="27ade4a2-1415-46fc-87e8-3682c396a9fd" TYPE="ext3"
/dev/sdh12: LABEL="caivs" UUID="b5719119-11a8-4cfc-a250-74a68b0e2d10" SEC_TYPE="ext2" TYPE="ext3" 

I didn't have a yaffs module installed at the time of this post, but it wouldn't surprise me if the 'Unknown' partitions were formatted yaffs.  To make a quick discussion of this, I was able to successfully image /dev/sdh, mount the partitions, even recover deleted files (note the mountable partitions in the blkid output are fat or ext).

Getting the Data

To make a quick discussion of this, I was able to successfully image /dev/sdh, mount the partitions, even recover deleted files (note the mountable partitions in the blkid output are fat or ext).  I used libewf to make the image and photorec to recover deleted files from unallocated blocks.

I didn't have a mechanism to quickly mount seven partitions read-only, but I intended to create a tar of all the logical files for easy access and distribution of files.  I thought I'd share the nifty way I quickly mounted all seven partitions and extracted the files:

1. Create the mount points:
   
   $ mkdir -p mount/{MOBILE,system,userdata,cda,hidden,cache,caivs}
   
2. Mount the partitions read-only:
   
   $ for i in $(ls mount); do p=$(sudo findfs LABEL=$i); sudo mount -o ro $p mount/$i; done
   
3. Archive all the files:
   
   $ sudo tar -cavf logical.tar.gz mount/
   
4. Unmount the partitions:
   
   $ for i in $(ls mount); do sudo umount mount/$i; done

I'm currently exploring the concept of flashing recovery images modified to allow data backups, and its promising, though a bit like crossing mine-laden ground for the forensic examiner.  But, in the case of the Motorola Triumph, no flashing is necessary.  Now just hope that every device that lands on your desk for examination is a Motorola Triumph!