Why not load ClockworkMod or TWRP to image a device?

Alternate recovery modes are useful, but maybe not for imaging a device

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

This post comes from a question I've fielded a few times.  A lot of people, like me, who hack around with their Android devices install a custom recovery mode in place of the default recovery mode.  So the question is, why not install ClockworkMod or another custom recovery mode on a device and use the custom recovery mode as a method to image the device?

So, let's get some terminology out of the way because I threw a lot of information in that first paragraph which you may or may not understand.  Part of the Android architecture is recovery mode.  The user can boot into recovery mode instead of Android in order to perform some basic recovery operations, including installing official updates and factory resets.  Recovery mode is a small operating system with a basic kernel.  The source is available online if you would like to browse.

Users can install a custom recovery mode, such as ClockworkMod or Team Win Recovery Project (TWRP).  These custom recovery modes are also operating systems and the user can boot into this alternate recovery mode instead of Android in order to access recovery functionality.  Extra functionality within these alternate recovery modes allow users to backup their devices, recover from backup, install non-official operating systems, and other advanced features.

Recovery mode runs by default as root.  Recovery options must run as root or else they would not have the proper permissions to execute.  In the stock recovery mode, the user cannot use these root privileges to image the device.  However, the alternate recovery modes allow the user to access a full shell as root privileges via ADB.  As I mentioned in my post on imaging a device, you need a root exploit to image the device.  You can treat an alternate recovery mode as a root exploit, then boot into recovery mode and image the device while the Android operating system is not even running.

This all sounds great, right?  So do I recommend install ClockworkMod or TWRP in place of the default recovery mode in order to image a device?  It depends upon why you want to image the device. In this post, I'll show how to install alternate recovery modes, how to image a device using an alternate recovery mode, and why this method of imaging may or may not be appropriate.

How to install an alternate recovery mode

Installing an alternate recovery mode is very device specific.  Honestly, the best way to figure out how to install an alternate recovery mode is to Google it.  Here are a few search terms:

• clockworkmod nexus 5
• clockworkmod galaxy s5
• twrp htc one

For example, here is how to install ClockworkMod on a Nexus 5.  Note that unlocking the bootloader results in all user data gone.  Note and remember for later in this post.

Here is a guide for more advanced users for installing TWRP on a Galaxy S4.

In short, I can't guide how to install ClockworkMod or TWRP on each and every device.  It is a device specific project.  Search online to find how to install an alternate recovery mode on your own device, and you can always contact me for help.

How to image in recovery mode

Now let's say you've got ClockworkMod installed on your device.  My personal device is a Nexus 5, so I'll use my phone as a guide device.

Disclaimer:  you can cause big problems on your device if you do some of these steps wrong.  I am not liable for any damages done to any devices as a result of reading this page or any other pages on this blog.

First, boot the device into recovery.  If you're not sure of how to do that, search online.  If your device is booted into Android and you have adb enabled, you can try the following command

adb -d reboot recovery

Your device should reboot into recovery.  Then if you enter

adb devices

you should get a response along the lines of ...

03xxxxxxxxxxxx17        recovery

If you get a strange response with a bunch of question marks, try entering the following

adb kill-server

sudo adb start-server

And then try adb devices again and see if you get a better response.

In my post on imaging Android devices, I said you need the following three things

1. Data connection between the computer and the device
2. Exploit
3. Imaging command

If you've followed along so far, we've got all three satisfied

1. You can communicate with the device in an alternate recovery mode over ADB
2. The alternate recovery mode gives full root access to the device
3. Imaging command below

Next, you'll need netcat, or nc, in the recovery mode.  I mentioned before that recovery mode is its own operating system.  As an alternate recovery mode allows a shell to the device, the alternate recovery mode operating system contains commands the user can use.  ClockworkMod and TWRP should both have netcat installed as they both should include busybox.  To make sure, open an ADB shell to the device in recovery mode and type the following:

busybox nc

If the output includes something along these lines:

Usage: nc [-iN] [-wN] [-l] [-p PORT] [-f FILE|IPADDR PORT] [-e PROG]

Then you are set.  If not, contact me and I'll help you get netcat installed.

Now, just like on my post on live imaging an Android device, we'll image the device using netcat.  I'll go over the instructions again.  Note, I'm basically just copying and pasting from the post on live imaging.

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.

Next, in the shell to your phone, type the following:

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.


A quick note on crypto.  If the device's data is encrypted, the image will be of encrypted junk.  You are imaging the device while the data partition is inactive.  If the image appears to be encrypted, you'll need to acquire data while the device is live.

Now that I've explained how to image a device using recovery mode, I'll go over whether or not it is a good idea.

Why recovery mode to image a device can be a good idea

Digital forensics is a big community containing many realms.  Digital forensics can be involved in law enforcement, federal government, research, and IT security.  Digital forensics can also be practiced by individuals wanting to learn more about how their devices operate.  What I'm saying here is the purpose of imaging the device dictates whether or not using recovery mode to image your device is a good idea.

If you are an advanced Android user, you may very well have an alternate recovery mode on your device.  I have ClockworkMod or TWRP on all of my personal devices.  If you are imaging your device in order to do some research on some files or a process, then using an alternate recovery mode is a great idea.  You can image the device while it is not booted into Android, the data partition is not actively in use while imaging.

If you are a security researcher working on mobile work, I definitely recommend installing a custom recovery mode (unless doing so interferes with research).  You may have good uses for some of the advanced functionality which the alternate recovery mode offers.  So if I've described your job and you need to image a device, I recommend the method on this page.

If you are imaging a device where the device is evidence in a case and the device already has an alternative recovery mode loaded, then you can use the alternative recovery mode to image the device.  In doing so, the device is not booted into Android so no user data on the device is changing or even loaded when imaging.  I say this paragraph with a caveat: users can write their own alternative recovery modes, and it is conceivable that an advanced user could bake some special sauce into recovery mode to, say, wipe the device.  While I find such a scenario unlikely, it is conceivable.  And this caveat works as a perfect segue into my next section.

Why recovery mode to image a device can be a bad idea

I said before that the purpose of imaging the device determines whether or not installing a custom recovery mode is a good idea.  I'm going to detail why installing the custom recovery mode can be a bad idea.

If you are imaging a device where the device is evidence in a case and the device does not already have an alternative recovery mode loaded, I definitely do not recommend installing an alternative recovery mode.  If you do choose to install one, you are doing so at your own risk.  There are two reasons why I do not recommend this action.

1. Installing an alternative recovery mode involves overwriting the previous recovery mode.  If it appears that the stock recovery mode is installed, it is most likely not a problem to overwrite the recovery mode.  Users by default cannot access the recovery mode to store data there.  I would not call replacing a stock recovery mode (which you can download easily from the Internet) a material change.  However, it is conceivable that an advanced user could write their own recovery mode to include some extra data or functionality and make it appear identical to the stock recovery mode.  In the unlikely but possible case where you have such a device, overwriting recovery mode means overwriting important data.
2. And this one is just a minor detail.  Installing a new recovery mode often involves factory resetting the device, or wiping all user data.  As in, deleting all case data from the device.  This process is what I would call an RGE, or a Resume Generating Event.  Minor detail, right?

So to sum up the above points, if you are imaging a device because you need to retain the data on the device as you found it, I absolutely do not recommend installing an alternative recovery mode to image the device.

Summary

• Alternative recovery modes, such as ClockworkMod or TWRP, are useful for Android hackers like myself
• Alternative recovery modes provide the user a root shell so imaging the device using an alternative recovery mode is a very similar process to live imaging a device
• It may or may not be recommended to use this method to image a device.  If it is essential to maintain the data on the device as you found it, such as in an investigation, do not use this method for imaging a device.  Live image the device or use a commercial forensic tool

Questions, comments, suggestions, or experiences?  Any RGEs you care to (or not care to) share?  Leave a comment below, or send me an email.