Dirty Cow

A potential game changer in forensics

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

About two and a half years ago, I wrote a post on live imaging an Android device.  Based on the view stats I see on this blog, it seems like this post has a lot of popularity.

Fast forward some time and several operating system revisions, and the post is now quite obsolete.  The post relied upon TowelRoot, which is an exploit that has been patched for over two years.

Now what is not obsolete is the general method.  Data connection between the forensic computer and the device, exploit, imaging command.  These concepts are still the same.  The problem is, I don't have an exploit for new Android devices.

Dirty Cow

Enter cve-2016-5195, or "Dirty Cow".  The link in the previous sentence is to the official documented exploit.  In short, it is a Linux exploit that is also in the Android kernel.  It could potentially be used as a root vulnerability.

Several developers have released open source versions of Dirty Cow for Android, but all as proof-of-concepts.  To the best of my knowledge, nobody has released a version of Dirty Cow specifically for rooting devices.  I have tried several techniques on my personal phone and still no root shell.  The source is open in C and can be compiled using the Android NDK.  Now I personally have C experience, but the last time C was my primary language, the top selling phone worldwide was the Motorola Razr and Barack Obama was a little known senator from Illinois.  And the world still hated Tom Brady and the Patriots, so I guess some things never change.  Didn't I mention in my previous post that I'm officially a dinosaur?

Implications

If anybody gets Dirty Cow working on Android like Towel Root, meaning a do-all root program, then suddenly we as forensic examiners can use the live imaging guide to image any current Android device, or at least until Dirty Cow is patched and the patch is wide spread.

As I am using a Galaxy S6 running 6.0, I have not rooted my phone.  That may come as a shock to many.  The reason is I do not have a way to root my phone without tripping the Knox warranty bit.  I would like to keep that intact but still gain a root shell.

And of course, where there are forensic implications, there are also security implications.  If I can image anyone's phone, then so can anyone else.  And anyone can access and take privileged information from a device.


Community Work

So here comes the point of this post.  Who out there is working on Dirty Cow or other new exploits?  If anyone reading this is interested in Android forensics and is working on gaining root shells, I'd sure like to hear about it, whether you are using Dirty Cow or something else entirely.  If you are able to, please share.  I am happy to collaborate or point you in the direction of someone who can collaborate as well.

And, have you had any success with Dirty Cow or any other current exploit?  If so, how did you do it, what device, any troubles, etc?

I personally would be very interested in getting an exploit for newer Android phones up and running.  The purpose here is for forensic research so I can share with the digital forensics community community continuing results.

Summary

• TowelRoot is obsolete.
• Dirty Cow is a a possible way to gain an equivalent root shell on newer devices.
• Collaboration?

Questions, comments?  Any research you wish to share?  Leave a comment below, or send me an email.

Interpreting data from apps

Lots of apps means lots of data

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

In Android, just about all the data you care about will be app data.  Text messages?  App data from the SMS app.  Phone logs?  App data from the phone app.  Facebook chats?  App data from the Facebook app.

Now I think of myself as being a young guy.  At least, I'm not old, or too old.  I am a millennial.  So you could imagine the surprise when I heard the following comment from a college-aged family member:

Mark, you still text?  You are such a dinosaur.

Yes, I am a dinosaur for still texting.  Now I can remember literally laughing out loud when I first received a text from my father.  He had finally graduated from placing a phone call for even the simplest of messages to convey to sending a short message over SMS.   Fast forward a few years and I am a dinosaur for not graduating beyond texting.  But graduating to what?

Well, that college-aged family member said he and all his peers use apps to message each other.  Facebook, WhatsApp (which is now owned by Facebook), and I'm sure others.  C'mon, I asked him, what's wrong with texting?

And why use Facebook instead of texting?

Can you send photos over these apps the way I do with MMS?

And what exactly is WhatsApp?

Now beyond the young kids who dance on their elders' fossils for using a technology which my elders only recently began using (poorly), there are others who, for better or worse, use apps for communicating.  For a dramatic example, the terrorist organization ISIS famously uses the app Telegram for spreading propoganda.  Now you may think that the owners of Telegram may consider it a responsibility to shut down ISIS usage.  And Telegram has in fact made an effort to ban terrorist usage of their app, but that was only after laughing off the notion with the following line: I propose banning words. There’s evidence that they’re being used by terrorists to communicate.

Also sadly in the news was the app Kik  In the recent tragic murder and kidnapping at Virginia Tech, the perpetrators used the app Kik to lure in their prey.  The story is horrifying on so many levels.

Now what about other apps?  Games, sharing apps, social media, etc.  Might those apps store some significant data too?  This post is all about how to parse and interpret data from third-party apps.  Why is this significant?  If you get all the SMS and call logs and other traditional evidence, you may have missed the device owner's primary method of communication.

Now this post will not be a specific how-to-parse-this-app post.  Instead, this is a generic guide for parsing that may be of help.  I hope to convey methods apps store data and how to access and read this data.  I believe the challenge of parsing and interpreting app data is or will soon become more tedious than imaging devices.

Where do apps store data?
First, Android security prohibits users from accessing the userdata partition, which is where all apps store their data.  (Some apps may also store some data on the SD card, but this is "unprotected" data.  Not the "good stuff.")  You either need an image of the device (and you can create an image using my post on live imaging an Android device) or you need root access.  In this post, I am working from an image of a device.

Android by default stores user data in the /userdata partition in the directory /data.  The below screenshot is from a screenshot of FTK Imager looking at the data directory.

You'll see that within the data directory are directories containing package names.  The directory air.WatchESPN stores user data associated with the WatchESPN app.  The directory com.google.android.youtube stores data associated with the YouTube app.  The directory com.android.chrome will story web history and other data associated with the Chrome browser.

What kinds of data?
By default, most user data is stored in SQLite databases.  For a writeup on viewing SQLite data, check out my previous post on SQLite databases.

Most apps use SQLite in some fashion or another.  And if the app you are trying to parse stores all its data in SQLite with no encryption of any kind, you are good to go.

Other types of data can also be found.  The following is a screenshow of the YouTube app's storage:  

All of the directories above store data associated with the YouTube app.  The databases directory will contain SQLite databases.  The directory shared_prefs stores XML files which may be interesting or not.  Depending upon the app, the XML files may store data about the user, such as usernames or maybe even passwords if the developer has a poor grasp on security.  The XMLs can also be pretty much useless.  XMLs can be opened in any text editor of choice.

There also is a "files" directory.  This directory can store anything.  A developer can store images, videos, text, or even more databases in the files directory.

So if your app stores only databases in a nice SQLite format, some user information in XMLs in shared_prefs, and some images or other interesting files in the files directory, you can easily interpret all of this data.  But what about challenging data?  I will highlight two challenges to consider with app parsing.

Encryption

Many apps use encryption to store sensitive data.  In some cases, you open a SQLite database and are parsing through and you get to a table with nothing but random-looking junk stored in rows.  If you come across such a finding, you may have found some encryption.  This is an example of encrypted content within a database.  And if you find such content, you will need to find a way to decrypt the data to make any sense of it.  I am no crypto expert, so I would consult one if I came across such a finding.

And a side note.  If you come across a string that looks like the following:
TWFyaywgYXMgaW4gdGhhdCBuZXJkIHdobyB3cml0ZXMgaHR0cDovL2ZyZWVhbmRyb2lkZm9yZW5zaWNzLmJsb2dzcG90LmNvbSwgaXMgc3VjaCBhIGRpbm9zYXVyIQ==

you have come across Base64 encoded text.  This is not encryption and can easily be decoded.  Base64 encodes anything into a random set of uppercase, lowercase, numbers, and some symbols, and if padding is required, the string ends with equals signs.  Here is a Wikipedia page on Base64.  You can come across Base64 in databases, XML files, URLs, or just about anyplace.

Some apps also encrypt their databases entirely.  WhatsApp, for example, encrypts their entire database.  If you come across an app that you know is storing a good amount of data on the device and yet you cannot find a database but you find entire files of random-looking data, you may have found encrypted databases.  Again, consult a crypto expert.

Non-standard data storage

App developers are developers, and developers like to develop things.  What do I mean?  I mean that developers often get tired of using built-in functions, like SQLite, and so they choose to implement a different database format, or they make their own.  I have plenty of jokes to make at my engineer friends' expenses about over-engineering everything.

So while SQLite is a nice and easy format to parse, there are other database formats out there for Android.  Here is a list of ten known and available non-SQLite database formats.  If you come across an app with a non-SQLite database, you will need to find a way to interpret all the data.  If there is not a parser available, you can use a hex editor to simply view the database and make sense of it, or you can (or have a developer) write a parser so that next time you come across such a database, you will be ready.

Strategies

So big picture.  What do you do when you find an app on a device and you are unfamiliar with it?  Here is a list of steps you can do to make sure you get all the possible data.

• Examine all the data files.  View SQLite databases.  Open XMLs in a text editor.  Open unknown files in hex editors.  View any media.  Make sure you view everything.
• Check out the file /data/system/packages.xml.  This is a file which stores information about all apps installed on the device, including device permissions.  See any permissions that stand out?  If you see camera permissions, be on the lookout for photos associated with the app.  In a previous post, I detailed the file.
• Reverse engineer the app.  Look at the source.  It may help you understand what the app does and how it stores data.  Here is a previous post on reverse engineering.
• Once you have made sense of the data, report it in a standardized and readable format.
• If you think you may come across this app again, consider writing a program to parse through data based on your findings so you can do this process automatically.

Resources available

There are plenty of resources available for interpreting data from the diverse apps out there.  I will list out a few.

• Mobile forensic tool vendors.  I was recently at Mobile Forensics World in South Carolina.  There were many vendors presenting similar information to this post.  Everybody in the mobile forensics community is dealing with all these third party apps.  For example, the company Magnet Forensics sometimes releases findings of different third party apps.  Here is an excellent writeup on data within the app Skype.
• dex2jar.  In my post on reverse engineering, I show how to use this program to reverse an app to a Java jar.
• Java Jar decompilers.  With the Java jar from dex2jar, a decompiler can interpret the jar as Java source for reverse engineering.
• Wireshark.  Especially with chatting or social apps, you may need to understand data coming over the air to the device.  Wireshark can help you capture data in transit.
• JEB.  An app decompiler.  This is most definitely not free software.  If you need to decompile and debug an Android app to see from the "app's perspective" how data on the device is created, JEB can do the trick.

Summary

• There are so many apps out there which store important data on the device.  If you only look at SMS and call logs, you may miss the most important conversations on the device.
• Apps store data in the userdata partition.  You need either an image of the device or root access to get at it.
• Data can be stored in challenging format.  If you come across encryption and you are not a crypto expert, you may need to call one in.
• There are resources out there.  Everybody in the community is dealing with this challenge.

Questions, comments?  Any other dinosaurs out there?  Leave a comment below, or send me an email.

Some non-root methods to learn about a device

Sometimes you cannot image or root 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 will be a bit of a change of gears.  Most of the rest of my posts involve imaging the device in question and examining the image.  And of course, imaging requires three things:  

• Data connection between the device and the computer
• Exploit
• Imaging command

Now what if you cannot or choose not to exploit (root) your device?  This is a real situation.  So long as you have the ability to adb shell into the device, there still are some ways to get useful data from the device.  This post is all about some simple ways to gain some insight into the device.

Determine if the device has been compromised
A common fear with Android devices is that the device can be rooted without the user knowing.  This is a legitimate concern, and it can be addressed with an adb shell to the device.  Also this takes a couple little pieces of knowledge:

• The system partition, mounted at /system, is mounted read only
• Normal users cannot modify anything in this partition without a root exploit
• The root binary, su, is typically found in the system partition
• Which all means that if the device is compromised, there is most likely evidence of it found in /system

Shell into the device and cd to /system.  Then do an ls -al.  The -l part of ls will get a listing of all the files and directories at the /system directory including last modified times, and the -a will list any hidden files so you do not miss anything.  Here are the results from my Nexus 5:

shell@hammerhead:/ $ cd /system
shell@hammerhead:/system $ ls -al
drwxr-xr-x root     root              1970-11-15 06:44 app
drwxr-xr-x root     shell             1970-11-15 06:44 bin
-rw-r--r-- root     root         4065 2015-04-17 13:34 build.prop
drwxr-xr-x root     root              2015-06-25 22:10 etc
drwxr-xr-x root     root              2015-04-17 13:34 fonts
drwxr-xr-x root     root              2015-04-17 13:34 framework
drwxr-xr-x root     root              1970-11-15 06:44 lib
drwx------ root     root              1969-12-31 19:00 lost+found
drwxr-xr-x root     root              2015-04-17 13:34 media
drwxr-xr-x root     root              2015-04-17 13:34 priv-app
-rw-r--r-- root     root        89346 2015-04-17 13:34 recovery-from-boot.p
drwxr-xr-x root     root              2015-04-17 13:34 usr
drwxr-xr-x root     shell             2015-04-17 13:34 vendor
drwxr-xr-x root     shell             2015-06-25 22:10 xbin

As the timestamps show, most directories were last altered 2015-04-17, which is when I last flashed a version of Android onto my device.  Yes, I am behind the times.  Intentionally.  I like Android 5.1.1 and I'm sticking with it for now.

But you will also see some oddities.  Namely two directories that were updated two months later on 2015-06-25.  What is going on with etc and xbin?  Let's find out.

So I cd to etc and do another ls -al.

shell@hammerhead:/system $ cd etc
shell@hammerhead:/system/etc $ ls -al
-rw-r--r-- root     root            2 1970-11-15 06:44 .installed_su_daemon
-rw-r--r-- root     root         1472 2015-04-17 13:34 DxHDCP.cfg
-rw-r--r-- root     root       277097 2015-04-17 13:34 NOTICE.html.gz
(A bunch more files ....)
-rw-r--r-- root     root           38 2015-06-25 22:10 resolv.conf
(A bunch more files ....)
drwxr-xr-x root     root              2015-04-17 13:34 updatecmds
drwxr-xr-x root     root              2015-04-17 13:34 wifi
shell@hammerhead:/system/etc $

You will see that the file resolv.conf, which can only be read and written but not executed (explanation found here), was last modified 2015-06-25. So what is in that file and should I care?

I also can see that the file is only 38 bytes.  Small file.  So I just cat it.

shell@hammerhead:/system/etc $ cat resolv.conf                                
nameserver 8.8.4.4
nameserver 8.8.8.8
shell@hammerhead:/system/etc $

The contents of the file are pretty simple. For an explanation of what "nameserver 8.8.4.4" means, quite literally consult Google.

So on the one hand, you have a file which basically just says use Google for DNS, so nothing of real significance.  On the other hand, why was that file modified when it was?  If you remember, at the same date and time that the resolv.conf file was modified, the /system/xbin partition was modified.  Let's cd to that and get an ls -al.

shell@hammerhead:/system/etc $ cd ../xbin
shell@hammerhead:/system/xbin $ ls -al
lrwxrwxrwx root     root              2015-06-25 22:10 [ -> /system/xbin/busybox
lrwxrwxrwx root     root              2015-06-25 22:10 [[ -> /system/xbin/busybox
lrwxrwxrwx root     root              2015-06-25 22:10 acpid -> /system/xbin/busybox
.....
-rwxr-xr-x root     root      1095836 2015-06-25 22:10 busybox
.....
-rwxr-xr-x root     root        75364 1970-11-15 06:44 su-rwxr-xr-x root     root        75364 1970-11-15 06:44 sugote
-rwxr-xr-x root     root       157412 1970-11-15 06:44 sugote-mksh
.....
lrwxrwxrwx root     root              2015-06-25 22:10 zcat -> /system/xbin/busybox
lrwxrwxrwx root     root              2015-06-25 22:10 zcip -> /system/xbin/busybox
shell@hammerhead:/system/xbin $

So what does this all mean?  It means that on 2015-06-25 at 22:10 EST, I installed busybox on my device.  Busybox installed all these logical links at /system/xbin which point to busybox, and busybox additionally changed the /system/etc/resolv.conf to point to Google.

Additionally, you can see that on November 15, 1970, I rooted my device as you can see the su binary.

Wait, what?  In 1970, neither the device nor me existed.  Google didn't exist, cellular connectivity didn't exist, computers used punch cards as input, and bell bottom jeans were hot fashion

No, most likely, I rooted my phone in June 2015.  However, I rooted my phone via recovery mode, which does not use the Android clock, so all activity appears to take place in 1970.  I hate to disappoint you all, but I am in fact not a time traveler.  Additionally, this explains the file /system/etc/.installed_su_daemon as seen above, also modified in 1970.

So quick takeaways.  If you are worried that your phone might be compromised, do an ls -l in /system and see if anything looks like it was modified at strange times.  Additionally, see if /system/xbin/su exists.

Now some caveats:

• The system clock can be changed.  Easily.
• A smart attacker can change the clock around and do changes so that a simple analysis as seen above will not uncover changes made.
• The su binary need not be called su and placed in /system/xbin
• It could be elsewhere and called something else.  As long as it has the right permissions, the file can be placed anywhere on the device with execute privileges.

As always, if you are concerned there is some advanced attacking going on against your device which may employ some clock modification or a hidden root, you can contact me for further assistance with your device.


See what apps have been installed and if there are any you do not recognize
You install apps on your phone and you know what you've installed.  Or you install so many apps that you forgot what you've installed but the fact is you did personally install the app and you can account for it.

But what if somebody else gets their paws on your phone and installs something? We've all read articles about scares over spyware on phones, and we've all seen those movies where the bad guy gets the good guy's phone and installs something nasty which lets the bad guy listen on and everything the good guy is doing.  The truth is the Android development environment can be exploited to allow such apps to run.

So what if you think somebody has "tapped" your phone?  There is a good chance that if your phone has not been rooted and yet somebody put something on your phone, the little gift they left for you is an app.  It may be hidden, but it can be found with some simple command lines.

I'll give a quick and simple method which gets a list of all user-installed apps and then another method which tells details of all apps on the device.

So the quick way first.  Adb shell into your phone and type the following command:

pm list packages -3

pm is a command which stands for "package manager".  It does just as you may think - it manages packages, or apps, on the device.  The command above lists all third party apps, or user-installed apps.  The output from my phone is as follows:

shell@hammerhead:/ $ pm list packages -3
package:stericson.busybox
package:com.redfin.android
package:com.weather.Weather
... a bunch more third party apps ...
package:com.google.android.apps.chromecast.app
package:com.lookout
package:com.fandango
package:com.hp.android.printservice
shell@hammerhead:/ $

If any of the apps listed look like something you do not recognize, perhaps you should look into it.  I personally recognize all the apps installed.  stericson.busybox is a shortcut way to install busybox.  I care about the weather, hence a weather app.  My wife and I went to go see Deadpool last week, hence the Fandango app.

Now let's say you want to look into a specific app.  You can use the dumpsys command, which accesses all types of system logs.  For example, let's do a look into the WatchESPN app.  I may be a massive nerd, but I love my sports.

I enter the following line ...

dumpsys package air.WatchESPN

And I get the following info about the WatchESPN app

shell@hammerhead:/ $ dumpsys package air.WatchESPN                            
... a bunch of developer related activity at the top ... Packages:
  Package [air.WatchESPN] (2f619c56):
    userId=10111 gids=[3003, 1028, 1015]
    pkg=Package{2ab5f4d7 air.WatchESPN}
    codePath=/data/app/air.WatchESPN-2
    resourcePath=/data/app/air.WatchESPN-2
    legacyNativeLibraryDir=/data/app/air.WatchESPN-2/lib
    primaryCpuAbi=armeabi
    secondaryCpuAbi=null
    versionCode=2100103 targetSdk=22
    versionName=2.4.1
    splits=[base]
    applicationInfo=ApplicationInfo{36a34671 air.WatchESPN}
    flags=[ HAS_CODE ALLOW_CLEAR_USER_DATA ALLOW_BACKUP ]
    dataDir=/data/data/air.WatchESPN
    supportsScreens=[small, medium, large, xlarge, resizeable, anyDensity]
    timeStamp=2015-10-31 08:03:15
    firstInstallTime=2015-10-10 15:09:36
    lastUpdateTime=2015-10-31 08:03:16
    installerPackageName=com.android.vending
    signatures=PackageSignatures{155cf1c4 [2bd4d8ad]}
    permissionsFixed=true haveGids=true installStatus=1
    pkgFlags=[ HAS_CODE ALLOW_CLEAR_USER_DATA ALLOW_BACKUP ]
    User 0:  installed=true hidden=false stopped=false notLaunched=false enabled=0
    grantedPermissions:
      android.permission.INTERNET
      android.permission.READ_EXTERNAL_STORAGE
      android.permission.READ_PHONE_STATE
      android.permission.ACCESS_NETWORK_STATE
      android.permission.WRITE_EXTERNAL_STORAGE
      android.permission.ACCESS_WIFI_STATE
shell@hammerhead:/ $  

So what does all this mean?  Let's break down some important highlights.

• codePath=/data/app/air.WatchESPN-2
• The apk is in the /data/app/air.WatchESPN-2/ directory
• legacyNativeLibraryDir=/data/app/air.WatchESPN-2/lib
• Any native libraries are in /data/app/air.WatchESPN-2/lib/
• dataDir=/data/data/air.WatchESPN 
• Data associated with the app is stored in /data/data/air.WatchESPN - though you need to be root to access that data
• firstInstallTime=2015-10-10 15:09:36
• I installed the app in October 2015.  I'm guessing it was to watch this game.  My Bowling Green Falcons put on a show on offense.
• lastUpdateTime=2015-10-31 08:03:16
• The app was last updated on Halloween 2015.  The update must have been scary.
• installerPackageName=com.android.vending
• The app was installed by the standard method, not by ADB or other manual methods
• grantedPermissions
• The app has the following permissions:
•       android.permission.INTERNET
•       android.permission.READ_EXTERNAL_STORAGE
•       android.permission.READ_PHONE_STATE
•       android.permission.ACCESS_NETWORK_STATE
•       android.permission.WRITE_EXTERNAL_STORAGE
•       android.permission.ACCESS_WIFI_STATE

So this app is obviously legit.  And if this information looks awfully familiar, it is because the same information shows up in the packages.xml file.

You can also type the following command:

dumpsys package

and you will get a similar listing for every app installed on the device.  Now I would recommend catting this all out to a file.  The way to do that is get out of your adb shell and cat the output to a file on your computer.  It would look like the following, and note that I am shelled into my computer, not my phone:

adb shell dumpsys package > dumpsyspackage.txt

You will have a file on your computer called dumpsyspackage.txt with a full listing of every app on your device.

Now let's say I found something in the listing for the WatchESPN app that bothered me. I may want to reverse engineer the app.  I can pull the app without root access.  Here would be the line to pull the app onto the local computer:

adb pull /data/app/air.WatchESPN-2/base.apk

Based on the output above, the app is in the directory /data/app/air.WatchESPN-2/, and I happen to know the apks for third party apps in Android 5 get installed in that directory as the file base.apk.  The above command pulls that file to your local computer.

Continuing with that nifty dumpsys command ... 

Fun with dumpsys

As I said before, dumpsys is a command which accesses system logs.  It can tell you a whole lot more than just what apps are installed.

Now if all you want to do is obtain an entire system log, do a similar command as the previous command to dump all package logs to a single file.  Type the following command ...

adb shell dumpsys > dumpsys.txt



... and go grab a drink because it will run for a while.

The resulting file dumpsys.txt will be quite large, unorganized, and difficult to prod through.  So let's get a finer view of it.  ADB shell into the device and type the following:

dumpsys -l

I get the following output:

shell@hammerhead:/ $ dumpsys -l
Currently running services:
  DockObserver
  SurfaceFlinger
  accessibility
  account
  activity
  alarm
  android.security.keystore
  appops
  appwidget
  assetatlas
  audio
  backup
  battery
  batteryproperties
  batterystats
  bluetooth_manager
  ... a bunch more services ...   voiceinteraction
  wallpaper
  webviewupdate
  wifi
  wifip2p
  wifiscanner
  window
shell@hammerhead:/ $   

It is a list of all running services that can be dumped.  So let's say I want to find out about my wifi.  I can enter the following command from the computer, similar to previously dumping all app info.

adb shell dumpsys wifi > dumpsyswifi.txt

And I will get an output about what WiFi I am connected to, packet usage, etc.  You can do the same for any of these running services.  Want to know what your bluetooth is up to?  You know what to do now.

dumpsys is a good tool to play around with and it works on live running devices.  This is not something you can do to an image.  An image is just a file, a dead, flat file.  A device is a live, running computer that you can interact with, or in the above cases, interrogate.

Summary

• There are some ways to get useful information from a live device, even without rooting or imaging.
• Looking at files in your system partition by timestamp can be an indicator if your device has been compromised, though remember that timestamps can be faked with relative ease.
• Dumpsys is a useful tool.
• You can use dumpsys to learn about what apps are installed on a device, and you can use an adb pull to remove the app and examine if you wish.

Questions, comments?  Sports memories?  Leave a comment below, or send me an email.

Identifying your Userdata Partition

In case you only want to image one partition

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

For starters, I'm sorry I haven't posted anything in a long time.  And really, there is a main reason.  You, the reader, may also be able to help.

The reason I haven't posted in a long time is because I have not come up with many great posting topics.  I look for several qualifications in a topic ...

• A topic which which is consistent with other topics on my blog
• A topic which is not overly well covered and known on the Internet
• A topic which somebody with some good Linux and mobile knowledge can do.  In other words, a topic which does not require a mobile forensics expert to do.

So if you have a topic you would like me to cover, please reach out to me.  Crowd-sourcing is very popular these days!

Anyways, this topic comes from a question I field often.  A lot of people reach out to me wanting help imaging specifically the userdata partition.  In my post on live imaging an Android device, I said to reach out to me to find the exact block to image if you want to image userdata.

This posts presents a general way to find the right block to image.  This post is NOT meant to be a replacement for reaching out to me with imaging questions.  If you are working on imaging your Android device and are having issues or have questions, go ahead and send me an e-mail.

Imaging your entire device vs Imaging your Userdata partition
First, do you want to image the entire device, do you want to image just your userdata partition, or do you not know?

If you create an image of your entire device, the result will be a file representing your entire internal storage.  This image file will contain your boot image, recovery image, radio software, system partition, userdata partition, and depending upon the make and model can have a lot more blocks too.  Check out a full image of a Samsung Galaxy S5 sometime if you want to be overwhelmed with partitions and blocks!

If you create an image of your userdata partition, you will have a file representing one partition of the device from beginning to end.  This partition is the "userdata" partition, which contains evidence of user activity.  It contains call and SMS records, contacts, user-installed apps, app data, settings, and so-on-and-so-forth.  In most newer phones, it also is likely to contain photos and videos and other user-generated files unless an external SD card is present.

And if you want to image an external SD card, I would recommend a good ol' fashioned write blocker and traditional forensic techniques.  If you need more information on this, reach out to me.  My skill set is not restricted to Android forensics!

If you do not know which type of image you want to create, go for the full image.  It takes more space because the image file contains all the device partitions instead of just one.  The full image will give you a greater insight into the device - and you may learn a thing or two about how Android devices work!

How to image the entire device
If you've not checked out my post on live imaging an Android device, go ahead and check it out.  This current post will probably not make a whole lot of sense without the knowledge on the live imaging page.

I said on my live imaging post that you should image a block on the device and the command you enter via adb shell to the device looks something like this ...

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

This line reads all of the contents of the block /dev/block/mmcblk0 and passes it to the computer via netcat.  And as you saw on the post, this command only works if the device is rooted and busybox is installed.

The block /dev/block/mmcblk0 in most cases refers to the very first sector of the device.  By reading this block, you read the entirety of the device's internal storage.  Imaging this block gets you a physical image of the entire device.

Note: I did not say in all cases the block /dev/block/mmcblk0 refers to the very first sector of the device.  All it takes is one device to have a different naming convention to make a liar out of me if I said the block /dev/block/mmcblk0 is the first sector of the device in all Android devices.

How to image the userdata partition
If you only want to image the one partition, you need to know what block to read.  We do this with the mount command.

Open an adb shell to the device.  Type the following:

mount

You will get several lines of output.  Each of these lines represents mounted partitions.  On my Nexus 5, I receive the following as output of the mount command:

rootfs / rootfs ro,seclabel,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,seclabel,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,seclabel,relatime 0 0
selinuxfs /sys/fs/selinux selinuxfs rw,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
none /sys/fs/cgroup tmpfs rw,seclabel,relatime,mode=750,gid=1000 0 0
tmpfs /mnt/asec tmpfs rw,seclabel,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,seclabel,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,seclabel,relatime,data=ordered 0 0
/dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4 rw,seclabel,nosuid,nodev,noatime,nomblk_io_submit,noauto_da_alloc,errors=panic,data=ordered 0 0
/dev/block/platform/msm_sdcc.1/by-name/cache /cache ext4 rw,seclabel,nosuid,nodev,noatime,nomblk_io_submit,noauto_da_alloc,errors=panic,data=ordered 0 0
/dev/block/platform/msm_sdcc.1/by-name/persist /persist ext4 rw,seclabel,nosuid,nodev,relatime,nomblk_io_submit,nodelalloc,errors=panic,data=ordered 0 0
/dev/block/platform/msm_sdcc.1/by-name/modem /firmware vfat ro,context=u:object_r:firmware_file:s0,relatime,uid=1000,gid=1000,fmask=0337,dmask=0227,codepage=cp437,iocharset=iso8859-1,shortname=lower,errors=remount-ro 0 0
/dev/fuse /mnt/shell/emulated fuse rw,nosuid,nodev,noexec,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0

Look specifically at the following line:

/dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4 rw,seclabel,nosuid,nodev,noatime,nomblk_io_submit,noauto_da_alloc,errors=panic,data=ordered 0 0

This line indicates that the block /dev/block/platform/msm_sdcc.1/by-name/userdata is mounted read/write (as opposed to read only) at the directory /data and the partition is formatted ext4.

That means the block /dev/block/platform/msm_sdcc.1/by-name/userdata is my userdata block.  I can substitute /dev/block/platform/msm_sdcc.1/by-name/userdata for /dev/block/mmcblk0 in my imaging command.

Now I fully understand that typing /dev/block/platform/msm_sdcc.1/by-name/userdata is a bit cumbersome.  There is a shortcut.  I can enter the following command (and you might need to be root):

ls -l /dev/block/platform/msm_sdcc.1/by-name/userdata

I get the following output:

lrwxrwxrwx root     root              1971-03-18 07:17 userdata -> /dev/block/mmcblk0p28

You may notice a timestamp from the year 1971.  That is nothing to be concerned over - I am in fact not a time traveler.  That timestamp is an artifact of Linux timestamp convention.

This output indicates that the block /dev/block/platform/msm_sdcc.1/by-name/userdata is a reference to /dev/block/mmcblk028.
So, I can substitute /dev/block/mmcblk0p28 for /dev/block/mmcblk0 in my imaging command.
If I want to image just the user partition, the imaging command I enter in an adb shell to the device would look like this:

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

I hope this all makes sense.  Feel free to reach out to me if you need further assistance.
And now some frequently asked questions
Seeing as this post started with answering a FAQ, I will answer a couple more FAQs.

"Can I use the live imaging technique in Windows?"

Not without some serious hacking around.  The technique I show is a Linux technique that also works on Mac.  This is because the technique relies upon the netcat utility.  Netcat is on both Linux and Mac; it is not on Windows.

Now maybe you are familiar with Cywgin.  Cygwin allows you to run Linux commands in Windows.  I have never tried this imaging technique out on a Cygwin-enabled Windows computer using the Cygwin version of netcat.  If anybody out there tries this out, let me know!  I'd love to know the results.

"I found this specific rooting technique for this specific device.  I have not tested it out yet.  Will it work?"

Sometimes I get asked if a rooting technique works on a certain phone.  And I always look into it and will provide the best answer I can.  The trick is, whatever the phone is, I probably do not have one conveniently laying around to try the technique out myself.

The issue with rooting is sometimes you can accidentally wipe device data you plan to image.  Example: the most common method for rooting Nexus devices is to unlock the bootloader and install ClockworkMod and root through CWM.  This technique works great except for one minor little detail: as a security feature, unlocking the bootloader on a Nexus device wipes all user data on the device.  I would not exactly call that forensically sound.

Similarly, some techniques on newer Samsung phones can result in flipping the warranty bit.  If you root your Samsung phone and then see the following in the bootloader interface:

Then the warranty on the device is void.  If you have a problem with the device, service centers are likely to turn it away.  That may or may not matter to you.  However, without that warranty bit, the device can never have a Knox container.  Again, this may or may not matter to you.  However, I would generally avoid flipping the warranty bit.

So when I get these questions, I research what I can to determine if your rooting technique is likely to safely work.  But as I said on my live imaging post, I am not liable if you harm your device.

"I am interested in a career in digital forensics.  How can I start?"

First, this is a fun career!  It is challenging because technology changes all the time, but there are great rewarding opportunities if the curious minds out there.  If you are thinking of university education in the field, I can point out some great programs - and there are new programs opening every year it seems because we need digital forensics experts. But if you are not sure and want to explore around before truly going down this career path, I can give you a few pointers ...

• Learn command line.  I cannot stress this enough.  In any area of computer science / technology, being comfortable in a command line interface is such an asset
• Learn Linux.  Whether you install Ubuntu and use it to browse the web or you go low level with Linux and do some fun hacks, Linux is good to know.
• Download the free tools.  Try FTK Imager and Autopsy.  Learn how they work.  Try examining your own computer.  Try using a Linux live environment by booting from disk and image your drive onto an external.  Just do anything you can to learn using the tools you already have.
• Read.  There is a great academic community in digital forensics publishing some cutting-edge research.  But before getting into the new stuff, read about the basics.  I can point you in the direction of some good papers.  If you are thinking about a BS or MS in this field, you will certainly read academic papers and do research of your own, so reading academic work beforehand can only help.
• Mobile device forensics specific:  hack around with your own phone.  Or preferably, if you have an old phone, don't sell it - hack around with it.  
• Android forensics specific:  Root the device and learn how it works.  Flash ClockworkMod and adb into the device in recovery mode.  Just hack around with the phone and don't be afraid to take risks, especially if it is not your day-to-day phone.  And don't hack around with somebody else's phone without their permission!  That can get you into trouble!
• Write.  In any field, the ability to do the work and obtain results is of course of great importance.  What so often sets apart leaders in a field is the ability to effectively communicate work and results.  Our universal way of communicating in just about any field is writing.  So write your work in a journal as you go.  Practice writing reports.  If you do not have a template to work from, create your own template.  Polish your writing style.  I know this bullet point sounds on the un-technical side but I cannot stress the importance of writing and effective communications enough.

"Do you consult?"

Yes.  If you have a need for digital forensics services (Android or not, mobile or not) or other Android/mobile related needs and you feel based off this blog I am a person you would like to work on the problem, e-mail me.  I do not take every case as I do this in my side time, but I take side work from time to time.  I can discuss privately how I work, needs you have, and my terms.

"Can you do speaking engagements / guest lectures?"

Yes, if scheduling works.  I have done guest lectures and simple Q&As at universities, including remotely over Skype.  I enjoy connecting with the academic community.


Summary

• If you are not sure whether to image a device's entire internal storage or just the userdata partition, image the entire device
• Use the mount command to find the block to image if you plan to image just the userdata partition

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

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.