Sunday, August 10, 2014

Imaging an Android device

(It's not magic)

All blog posts to date

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.

  • 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.


  1. Another quick question: From the few things that I've read so far it seems that the make and model of the phone doesn't seem to be a big deal within the context of Android Forensics. What if you are trying to image partitions on a Motorola Moto-X (ATT) with all the updates? As far as I know there still is no way to root (aside from the guy in China who claims to know the secret, and is holding it for ransom) these (xt1058 I think).

    To further confound things, there is no SD card. at least not that I can see... and the phone batt is not user serviceable and it appears to have the case glued together.

    Obviously if the phone was suspected to contain key evidence in a high profile case, well - the phone would be rooted somehow, no? Would this just be a process that results in the destruction of the phone?

    1. The make and model really matters most when rooting the device. You may have the ability to root a 4.4 device, but you may have a device with a kernel which contains security measures beyond the standard 4.4 Android security.

      I do not have a Moto X. I wish I did. So I'm not personally familiar with rooting that one.

  2. Or am I confusing "rooting a phone" with "obtaining root access" and these are not the same thing?

    1. Eddie - when I say obtain root access - I mean you must have the ability to gain a root shell. Either the phone has to be rooted (there are phone-specific guides out there though not all phones are supported) or you use an exploit to gain a temporary root shell. Some of the older Android builds (ICS and older) had these sorts of exploits though I don't see these exploits on the newer builds and devices.

      So if you're using a newer device, you'll most likely need to root your phone to gain an image using these live imaging techniques. Or if you happen to have ClockworkMod, you can use that to image.

    2. Thanks so much (belated as my thanks may be) for taking the time to reply to my questions. Has there been any progress in the Android-forensics world?

      I'd still like to find an all-in-one suite or distro for making a raw 1:1 copy of an Android device's internal storage or memory that can be mounted and examined for various types of recoverable data or even viewed with a hex editor.

      Does such a suite exist?

    3. If you're looking a commercial tool, try Magnet Forensics - Magnet Acquire. It is basically a tool version of this post. Community Edition is free.

  3. BTW as far as I know, the Moto X is still a nightmare to root.

  4. Hi Mark

    Thoroughly enjoying your articles/ Bloggs. Thank you for taking the time to share your experience.

    I'm a user of Magnet Axiom and while I absoloutely love the product and the results it achieves, I'm finding that certain phones cannot be acquired with the passcode in place and consequently only a logical dump is available.

    I've been directed to look at cellebrite as an alternate means of acquisition and then doing analysis via magnet. Seems like a pretty expensive work around.

    I have worked with cellebrite before and the little cable-sets are like magic tools that just unlock phones. Can you expound on how the cables/jigs work?

    Would it be possible to use the cellebrite cables/jigs to place the phone into a dead recovery state and then link to them via magnet for example? or is it better to work directly on the phone with a linux toolset?


    1. Both good tools. I've used both and have contacts at both.

      So as an example to answer your question with Cellebrite cables, if you attach a yellow Micro USB adapter to cable A and plug into a Samsung Galaxy phone you see the phone boot to download mode. As I understand it, that yellow adapter has a resistor in it which triggers the phone to boot to DL mode.

      Now regarding your Magnet Cellebrite combination, could you specify a type or brand of phone and a use case? I could try to expand upon it.