Live imaging an Android device

Not as hard as it sounds if you break it down

All blog posts to date

Introduction	Acquisition	Analysis
Introduction	Imaging an Android Device	Examining the image
Picking a Toolkit	Live imaging an Android device	Some hidden artifacts in a physical image
	Why not load ClockworkMod or TWRP to image a device?	Using Autopsy to examine an Android image
	Identifying your Userdata Partition	Some artifacts in the /data/system/ directory
	Some non-root methods to learn about a device	Viewing SQLite Databases
	A quick note on imaging newer Android devices	Facebook for Android Artifacts
	Using Windows to Live Image an Android device	Interpreting data from apps
	Obtaining all files in the data partition without a physical image	Waze for Android forensics
		Magnet Forensics App Simulator
App Reversing	Other Topics
Reverse Engineering an Android App File	The differences between a physical image and a logical extraction
Fun with Apktool	Dirty cow
Deep dive into an app	Imaging and examining an Android car stereo
	Unpacking boot and recovery kernels
	MTPwn

Introduction
Live imaging an Android device is a complicated process but I'll do my best to break it down.

First, I mentioned in my previous post that many computer forensic experts are rather opposed to live imaging. So before I get into the technicals, I'm going to address forensic soundness here. (To skip over a discussion of forensic soundness, skip over a bit)

Forensic soundness considerations
Forensic soundness is not a completely well defined term. In a paper titled “The Impact of Full Disk Encryption on Digital Forensics” by Eoghan Casey and Gerasimos J. Stellatos (Digital Investigation 01/2011; 8:129-134), the authors addressed forensic soundness in acquiring a live encrypted system, and stated the following: 

“Setting an absolute standard that dictates 'preserve everything but change nothing' is not only inconsistent with other forensic disciplines but also is dangerous in a legal context. Conforming to such a standard may be impossible in some circumstances and, therefore, postulating this standard as the 'best practice' only opens digital evidence to criticisms that have no bearing on the issues under investigation.”

Forensic examiners often consider DNA typing a “gold standard” to which other forensic disciplines should strive, but when collecting biological samples for DNA analysis, the scene from which the biological samples are collected is altered, and the biological samples are actually destroyed during the analysis. This is a roundabout way of saying that “alter nothing” and “forensic soundness” do not mean the same thing.

In the realm of hard drive forensics, we are truly spoiled. With a write blocker and hashing techniques (like SHA-256), we can image a hard drive and authenticate the image as an exact copy of the original without altering the original drive's data. (Note: when the drive is powered on, it spins, so the drive's state changes at a physical level, but if hooked to a write blocker the data does not change.) Other digital forensic disciplines are often held to the same standard as hard drive forensics in terms of forensic soundness, for better or for worse.

Live imaging absolutely requires altering the device data. What I recommend is to document every step of the way if you pursue live imaging and be careful as to avoid unnecessary changes to the device. The files we will load to the device to do the imaging are very small, and I would recommend documenting the size of these files before loading them to the device.

Imaging the device
Now that is all out of the way. As I stated in a previous blog post, imaging a device (whether dead or live) requires three things: a data connection between the device and the computer, an exploit, and the imaging command. Let's knock one out at a time.

Data connection between the device and the computer
Connect the phone you want to image to the Linux computer. If you have not installed the Android SDK, do so now.  (Update:  I more recently posted on how to use Windows to make an image, but I do not fully endorse the method.)

We will be communicating with the phone using the Android Debug Bridge tool, or adb. Here's an official read-up on it. developer.android.com/tools/help/adb.html

Next, we need to treat the device as a debug device. There's a good official writeup here: developer.android.com/tools/device.html

Follow the above link, then open up a terminal window. If you have installed adb and it is in your system's PATH, type the following:

adb devices

If adb is not in your PATH, then navigate to the directory including your adb binary and type the following:

./adb devices

If you don't know what I'm talking about, I recommend including adb in your PATH. Check out this website for an explanation: http://www.linfo.org/path_env_var.html and if you would like further clarification, Google it, post in the comments section, or contact me and I'll help you out.

Now, if when you type “adb devices”, you see something along these lines:

~$ adb devices
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached
03************17 device

then adb has found your phone. Great. If you type “adb devices” and all you see is the following:

~$ adb devices
List of devices attached 

then something went wrong and your computer is not seeing your device. Reach out to me and I'll try to walk you through.

If your computer recognizes your device, then you in fact have a data connection between your computer and phone.

Exploit
Note:  In this section, I will explain my personal way of rooting a phone and installing busybox.  If you have a preferred method or if you find a way specific to your phone online that you would like to try, go for it.  At the end of this section, you will need your phone rooted and have busybox installed, and there are multiple means to this end.

In 2009 and 2010 when the newest Android devices ran Android 2.2 and 2.3, security was a bit of a problem. You could run all kinds of one-click root exploits and gain an easy root shell. It was simple.

Then the developers at Google tightened the kernel quite a bit. In the newest versions of Android, there is not a public universal live Android exploit …
… until recently. A known security researcher wrote a tool called Towel Root, available at https://towelroot.com/. The exploit is a universal Android exploit that should work on all kernels released prior to June 2014. Download exploit at the following link: https://towelroot.com/tr.apk

A few notes on rooting your device:

• you may void your warranty
• root privilege is a powerful thing. You can easily make a mistake and “brick” your device
• if you render your device useless while following my blog or my advice, I am not responsible. You root your phone at your own risk. If by chance you do damage your device, contact me and I'll do my best to get you out of your rut.

To run the exploit, all you have to do is install the app. Once you've downloaded the app, run the following command from your command line on your Linux computer connected to your device:

adb -d install /path/to/tr.apk (where obviously /path/to is not a literal)

That command installs towelroot on your device. Don't run the app yet, but we will soon. Go ahead and verify it is on your device. It will appear in your app menu.

Next, install Busybox Installer from the Google play store. https://play.google.com/store/apps/details?id=com.jrummy.busybox.installer&hl=en. Busybox installs some extra Linux commands that are not installed by default on Android. We'll need the netcat, or nc, command, which is included in Busybox.

You also can download busybox and install the APK via sideloading.  You can find this apk by a Google search and install it via Android Debug Bridge.  I say this option because if you have a phone without a Google account, you cannot use the Play Store.

I also advise installing a root manager. I recommend SuperSU. Here's a writeup on it: http://lifehacker.com/5895134/supersu-for-android-manages-root-permissions-so-you-dont-have-to and here's a link to SuperSU … https://play.google.com/store/apps/details?id=eu.chainfire.supersu

Now. Go to your Towelroot app and follow the instructions to root. Assuming no errors, you are rooted. It's a fast process. Next, open your Busybox app and follow the instructions to install. Again, assuming no errors, you have buybox.

Now it is time to have some fun. On your Linux computer, type the following:

adb -d shell

This starts up a shell session with your phone, allowing you to type commands to your phone and interact with it. From here on (or until you end the session), commands you type are issued to the phone. Refer to the previous adb link to see a writeup about shell commands on the phone.

Now type the following:

su

If you installed SuperSU, you may need to push an OK button on the phone, as mentioned in the lifehacker writeup. Assuming no errors, all of the next commands until you end this session run as root. Just to check to see if you are in fact root, type the following:

ls /data

If you get some kind of error, you are not root, because only the root user can read the /data directory. If you are root, you can see and edit the entire directory. Don't screw up, or else you may convert your phone into an expensive paperweight. If you're all set to this point, you have successfully exploited your phone. Give yourself a pat on the back for making it this far.

Imaging command
At this point, you are root and all ready to image. We will be using the dd command, which allows us to read and write device block files, and the netcat command, which allows us to forward commands across ports, to read the device block representing the entire device and write it to your computer across the USB connection. Easy, right?

Read over the following link on the /dev directory and device blocks. It will help make some sense: http://www.linuxjournal.com/article/2597

The actual command you will be using to image the device is rather specific to the device you have.  It is because we need to image the right block.  Reach out to me to find the right block for your device and I will give you an imaging command.  You may want to image the entire device or just a certain partition and I can guide you through an imaging command as needed.  For my personal phone (Nexus 5), the head block of the device is /dev/block/mmcblk0.  I'll write a guide for how to image my personal device.

To image the device, you need to do some commands in two different sessions: one shell session to the device, and one shell session to your computer. Open up a terminal window and adb into your device.  Then open up a new terminal window (it will open as a shell to your computer, not your phone) and navigate to the directory where you intend to store your image. Note: if you create the image in a volume formatted FAT32, the maximum file size is 4 gigabytes, so imaging the device would require splitting the file. For ease sake, I suggest imaging to a volume formatted ext or NTFS. Also, make sure the volume has enough space for the device image, which will be as large as the device's storage. For my phone, I need 32 gigabytes of storage to image.

Now, in the shell to your computer in the directory of your choosing, type the following:

adb forward tcp:8888 tcp:8888

This command allows adb to communicate via netcat on port 8888.

dd if=/dev/block/mmcblk0 | busybox nc -l -p 8888

This command reads the contents of /dev/block/mmcblk0 (the head block of my device) and writes it via port 8888 across adb using netcat.

Finally, back in the shell to the computer, type the following:

nc 127.0.0.1 8888 > device_image.dd

This command saves the output of the contents across port 8888 (which will be the results of reading /dev/block/mmcblk0 on the device, or the complete image of the device) to the file device_image.dd.

If there's no errors, you are imaging the device. The window will “freeze”, or not allow any more commands because it is busy executing this command. When the imaging process is done, you will be able to type commands into this shell window again. To confirm, open a new terminal window, navigate to the directory where you are saving the image, and type ls -l. This will get a file listing, including file size. If the size of your file is increasing, you are successfully imaging your device.

Give yourself another pat on the back.

Summary

• Imaging an Android device requires three things:
• A data connection between the device and the computer
• An exploit
• An imaging command
• You've read over how to image my device.
• Reach out to me to help find the imaging command for your personal device

That’s all for now. Next page (which I'll post when ready) examines your image.

Questions, comments, suggestions, or experiences?  Other preferred ways to image Android devices without expensive kits?  Leave a comment below, or send me an email.