Imaging an Android device

(It's not magic)

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
First things first, what does it mean to “image” a piece of digital storage? A “digital image”, or just an “image”, is a digital replica of … something. That something can be a hard drive, a partition, a phone or tablet, RAM, or more.

Imaging a hard drive is a straight forward process. We can easily create a digital image of an entire drive. This image will be a single file (or a collection of files) which is a bit-to-bit representation of the physical hard drive. It is the beginning to the end of the drive in one file, including all deleted space. The drive can be imaged behind a “write blocker”, which prevents writes to the drive. It allows us to image the drive without the risk of accidentally writing anything to it. We can also calculate a mathematical hash on both the original drive and the created image to ensure that we have a 100% authentic image of the drive.

Imaging an Android device is not so straight forward. There are a few differences.

• a drive is storage. Not a complete computer system, just storage. It does not have an operating system giving it commands to read and write if unattached to a computer. Even if the drive stores an operating system, it cannot execute the operating system without being attached to a computer. If a computer asks the drive to export a file, or an image of the entire drive, it just executes the command.
• a phone (or tablet) is a complete system which includes storage. If we want to image a phone the way we do a hard drive, we need to open up the phone and remove the chip which contains all the storage and connect it to a highly specialized system to do the extraction, at great risk of damaging the data and at great damage to our wallets as this is a process which requires a specialist.
• instead, we connect the phone to a computer and treat it as a computer and issue it commands to image.
• we can connect a write blocker between a computer and a hard drive. As stated before, a hard drive is just storage.
• there is no write blocker to connect to a phone. We can issue commands to a phone from a computer via a USB cable (and you can connect a write blocker there if you really want but it is neither necessary nor desirable in most cases). However, the phone itself can and always does issue read and write commands to its internal storage. We cannot block those writes.
• when a drive is connected to a computer via a write blocker, no bits on the drive change. This allows us to calculate a hash to make sure we have an authentic image of the drive.
• a phone is a complete system. It is constantly issuing those write commands. The state of the phone's storage changes during the imaging process as the phone is constantly logging.

So, we treat a phone as a complete computer. We do not extract the storage chip and read it directly (though if you have a good reason to do that, I know some people who are experts in this process and can direct you their way.) So how do we image a phone? Do we connect it to a computer and hit a single button? Not exactly. To image a phone, we need three things:

1. A connection between our computer and the phone. We will be using the Linux environment, and we connect via USB. Easy.
2. An exploit to the phone. The phone is a Linux-based device that has Linux-based security, and one security measure disallows us to simply dump the phone's storage. We need some kind of security exploit which allows us root access to the device. This exploit may be a live exploit where we gain root access to the device while it is booted, or it may be a “dead” exploit where the phone is booted into a different mode entirely and we have root access.
3. A command to image. We need to be able to run a command as root which images the device and passes the image one bit at a time across the USB cable to our computer where we store it in a set location.

As I said in point 2, these steps are the same whether we are “live” or “dead” imaging, though the exploits are completely different. And that raises a point … what are these exploits?

An exploit is a piece of code which takes advantage of a security vulnerability and gives us root access. (If you do not know what root access is, go ahead and Google “Linux permissions” and “Linux root.” Linux permissions are good to study but not something I intend to cover. But for the quick definition, root access means god-like access to be able to do and see anything on the device.) Now as I described repeatedly, these Android devices are full computers. One Android device is not the same as the next. Different versions of Android, different manufacturers and their custom code baked into the system, and different devices have their own exploits. There has never been a catch-all Android exploit … until recently, which I will go over in the live imaging page.

As I previously alluded to, there can be “live” and “dead” exploits.

A live exploit is a piece of code that executes while the device is booted into Android. This piece of code runs and exploits a vulnerability in the system and gives you root access to the device, all while Android is running and all your apps are doing their things. Imaging a device while it is live means that you will be creating an image while the device is active. (Note of forensic soundness: many computer forensic examiners are currently cringing while reading this. I personally advise live imaging if you are comfortable with the process and comfortable with Android and command line. The actual exploit you will be loading is very small. Yes, it means you are “changing the evidence,” but we're talking about small files here. Document what you have done so you are accountable for any changes and you should be fine.)

A dead exploit, meanwhile, entails booting the device into another state. If you have installed a custom recovery mode, like ClockwordMod, then you have installed a dead exploit to the device. You can reboot to recovery and now you have a root shell. If you use a Cellebrite Physical, you are using a dead exploit. The Cellebrite kit uses bootloader runtime exploits, meaning it attacks the bootloader and does not write any code. Dead exploits are very device specific. There are some devices where we just do not have a dead exploit. In many devices, loading a custom recovery mode involves wiping all user data on the device, so if you are going for forensic soundness, you could probably see a minor issue here. Until recently, there was no universal live exploit either, but we now have a universal live exploit, or at least universal for all devices released prior to the exploit.

I will not be doing a page dedicated to dead imaging, unless the demand is there.  Dead imaging either relies on an expensive tool like a Cellebrite Physical or it requires loading a custom recovery mode and those are different device to device.  I will be doing a full guide on live imaging.

Summary

• We cannot image a phone or tablet like a hard drive.  We treat it as a whole system.
• Imaging an Android device requires
• A data connection between the device and the computer
• An exploit
• An imaging command
• We have live and dead exploits for live and dead imaging

Now that I've explained what exploits are and the differences between live and dead imaging, it is time to image. In the next post, we will live image a device.

Questions, comments, suggestions, or experiences?  Leave a comment below, or send me an email.