Examining the image

See what's underneath the hood

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

At this point, you have an image of the device. I hope you've patted yourself on the back by now because you have done more in the field of Android forensics than most people ever will.

(If you don't know what a file system is, go ahead and check out this link.)

There are some good free Windows tools for examining an image.  Any good forensic tool will allow an examiner to browse around an image file and will not alter the image file in any way.  This post will detail FTK Imager by AccessData.  So copy your image over to your Windows environment and install FTK Imager.  You can find it on this page.

(Note:  If you would prefer to work on Linux, you can run FTK Imager Lite in Wine.  If you have Windows, I suggest running it natively in Windows instead of in Linux using Wine.)

Open FTK Imager, go to File → add evidence item → image, and open the image. You'll see that the image has opened in Imager, and you'll see all of your partitions. Here's what I see:

And zoomed in on the left side looks like this:

At minimum, you will see the partitions boot, recovery, system, and userdata. Depending on your device, you could see all kinds of other ones.   My phone is a Nexus 5, which as you can see above has a lot of partitions.

Expand the “userdata” partition as seen in the following image:

The image above indicates that “userdata” contains an unnamed ext4 file system. Ext4 is a Linux file system, and FTK Imager can read this file system perfectly.

Navigate around the userdata partition. (If by chance you have encrypted userdata, you may or may not be able to make heads or tails of this partition. If you encrypt your userdata and you don't see a file system and want help decrypting, contact me.) You'll see directories at the root of the partition, some of which are quite important. You'll see /data, /app, and you might see /media. /data stores all of the data associated with your installed apps, /app stores all apps you have installed, and if there is a /media, then that is an “internal sd card”, or a directory which acts like an SD card.

Browse around the directory data and find the directory com.android.providers.telephony. This directory stores data associated with your text messages. Within is a directory called databases and file called smsmms.db. That is a database file which stores all of your text messages. Pretty cool, huh? In a future post, I'll show how to open database files. You can export files by right-clicking on a file as seen below.

Navigate around the system partition and go the directory app. This directory stores default installed apps. Just seeing filenames, you'll probably see some familiar names.

With FTK imager, you can navigate around an image. You can also extract files so you can interact with them in another tool. You can also view the hex of an image. Though it is difficult to make sense of hex, it is important to look at files and even device images in hex.

For example, you may have deleted a photograph you took with your camera and cannot recover it (or so you think.) You may be able to find the photograph in the hex. It takes an experienced examiner, or a curious tech mind, to do this. It also helps to have some good forensic tools at your disposal.

Looking at the hex of files allows you to understand the file at a deeper level.  A photograph file opens by default in an image viewer, but the image viewer will not display geolocation data or data related to the camera which took the photograph if it is embedded in the file.  Viewing the hex of the file may reveal this kind of data.

Previously I mentioned that you can export a file to your computer.  Go ahead and export a photograph if you can find one.  You may find some in the userdata partition at /media/0/DCIM, which is your camera directory (assuming your userdata partition acts like an SD card, and most modern phones work this way.) Pick out a photograph you've taken and export it to a location on your computer.  If you've not installed a Hex editor, go ahead and install a hex editor.  I personally use HxD Hex Editor, though there are many other wonderful ones.

Open the photograph you extracted in a hex editor.  You'll notice the first few bytes of the image look something like this:

All JPG files begin with this header.

Quick forensics lesson: file headers and footers. The way we traditionally identify a file type is by the extension. We see a .jpg file, it's a picture. We see a .docx file, it's a word document. (It's actually a ZIP file. Seriously, try it out. Rename a .docx file to .zip and open it up.) However, that is not how files actually work. When a .jpg file is encoded and saved, the first few bytes, or the file header, are FF D8 FF as seen above.  There are equivalencies with other file types, like ZIP archives, PDF documents, and executables. If you have a nasty piece of malware and rename it with a .docx extension, it may pass under some basic file scanners, but good forensic tools will identify this renamed file as suspicious and indicate that you should check into it. Here is a good writeup on file carving, or putting together files based off of headers and footers.

FTK Imager is a powerful, free tool which allows the user to examine a forensic image.  The image of your phone is a file which Windows, Microsoft Office, or any other program you frequently use could not possibly understand, but FTK Imager parses through it perfectly.  Android uses the ext4 filesystem, which is a Linux file system that Windows cannot understand, but FTK Imager can parse through it with ease.

FTK Imager, however, is limited.  It is not a full forensic tool; it is a tool for understanding filesystems.  FTK is AccessData's powerful forensic suite, and it is expensive.  It is a wonderful tool that I have used for years, but this is a blog about free tools.

A free alternative to FTK is Autopsy. I will not be covering Autopsy on this post, but I might do a rundown of it in the future.  It is a very powerful, free, open source tool with great support.  I've had some good luck with Autopsy on Android devices.

Summary

• FTK Imager can allow the examiner to easily take a look at the image
• No forensic tool will alter an image
• Headers and footers, not file extensions, determine the file type
• Viewing files at the hex level allows for a great understanding of the file

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

Live imaging an Android device

Not as hard as it sounds if you break it down

All blog posts to date

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

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

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

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

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

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

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

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

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

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

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

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

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

adb devices

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

./adb devices

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

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

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

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

~$ adb devices
List of devices attached 

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

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

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

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

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

A few notes on rooting your device:

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

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

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

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

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

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

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

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

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

adb -d shell

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

Now type the following:

su

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

ls /data

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

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

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

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

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

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

adb forward tcp:8888 tcp:8888

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

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

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

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

nc 127.0.0.1 8888 > device_image.dd

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

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

Give yourself another pat on the back.

Summary

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

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

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

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.

Picking a Toolkit

And some power tools

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
My dad is a handyman. He is a handyman around the house, in the garage, in the yard, and he even has renovated and sold four houses, one of which was in decrepit shape and required a complete overhaul. Like a good father does, he taught me all I need to know to be a handyman around the house and in the garage. Did I retain it all? Debatable. One thing I absolutely learned is that I need a good set of tools.

When I was growing up, he had two entire walls of the garage covered in tools, including an impressive set of mechanic's wrenches, a drill press, several handheld power drills including a 1970's era drill in perfect condition that would still take your arm off if you hold it wrong, a good table saw, a radial arm saw, sanders, paint brushes, rollers, more screwdrivers than I know how to count, all matters of screws, nails, bolts, and other hardware, and the list just keeps going. So what defines a good set of tools? Here's some criteria …

• appropriate for the jobs at hand. It's great to have a top of the line lawnmower, but it won't do you much good if the current task is to replace drywall.
• high quality. There's a reason I buy good tools by the best brands. They hold up best and get the job done most efficiently.
• collected and maintained throughout the years. While it is natural to replace tools with better ones when needed, some of the best tools are the ones you bought for a job a decade or more ago. Any handyman has some especially old tools and can tell you exactly what job he was doing which required him to buy a specific tool and some success stories which would not be possible without that specific tool.
• organized in a way that makes sense for you and you alone. You should create a toolkit and continually add to it and keep it organized in a way that allows you to find whatever tool you need quickly and store it in a place that just seems right. I can’t tell you the number of times my family has said that my tool bench makes no sense, but it works for me. I use no tool more frequently than my good power drill, so it is the easiest thing for me to grab.

In the world of digital forensics, every examiner develops a toolkit. The toolkit includes all kinds of forensic tools, cables, kits, and of course a forensic computer. The forensic computer, where the examiner acquires a digital image, examines it to find files which are considered of value, analyzes evidence found (from the digital media being examined and also relationally with evidence from other sources), and saves all findings and analyses in a report. And of course, a good examiner documents all along the way.

A forensic computer needs an operating system (OS). Before diving into tools, I need to discuss operating systems. As I said previously, a good toolkit should be organized in a way that makes sense for you, so in that vein, I will not specify an exact operating system. However, all of the tools I will be going over are either Windows or Linux, so you will need access to both a Windows machine and a Linux machine. You can run either or both of these in virtual machines (VMs) if you wish, or you can do what I do and have a computer with multiple hard drives and choose an operating system at boot.

Linux comes in a lot of varieties. A common variant of Linux is Ubuntu (www.ubuntu.com) and is an excellent OS to use if you are new to Linux. There are distributions of Linux designed for specific purposes, ranging from penetration testing to multimedia production. Believe it or not, there are even versions of Linux designed specifically for mobile forensics. Two great ones are Santoku (santoku-linux.com) by the group ViaForensics out of Chicago, and Open Source Android Forenics (OSAF) (www.osaf-community.org). Both of these distributions come loaded with all kinds of good mobile forensic tools. I personally use Santoku for my OS in my main computer.

I’m not here to recommend on OS over another. Try out whatever Linux variant you care to try, and pick whatever you like. Santoku and OSAF both come loaded with much of what I will be going over in this blog, so if you pick another OS you will need to download and install the tools I demonstrate. Again, I’m not here to recommend any OS and am not a representative of any OS distribution effort.

Getting started
To get started, you’re going to need your toolkit, and your toolkit starts with an OS. For what I will demonstrate on this blog, you will need both a Linux environment and a Windows environment. You can install either or both in VMs or on physical machines.

You also will need a method to transfer files, possibly particularly large files, from your Linux to your Windows environment and perhaps vice versa. Please be advised, if you use external storage, like a flash drive or external hard drive, and you have formatted it FAT32, the max file size you can copy to the drive is 4 gigabytes, and chances are you’ll be creating larger files than that.

You will also need some tools. I will go over more of these as I go on, but for now I will highlight two that I use all the time.

• FTK Imager for Windows. Great and free tool for examining a digital image. It also has some other great uses, including imaging a volume or a physical drive, but I don’t intend to go over those capabilities. It is on this page: www.accessdata.com/support/product-downloads
• Android SDK for Linux. developer.android.com/sdk/index.html - download the link that says Linux 32 & 64 bit and follow the instructions to install at developer.android.com/sdk/installing/index.html?pkg=tools. (Note, this is included in the distributions I highlighted.)
• You can also set up the SDK in the Windows environment if you like. I personally prefer to interact with the phone in Linux because the way I will demonstrate how to live image uses Linux tools.

Summary

• You'll need both a Linux and a Windows environment
• Pick a Linux distribution you like, and I've recommended a couple
• Go ahead and download and install both FTK Imager for Windows and the Android SDK for Linux

That’s all for now. Next page introduces imaging a device.

Questions, comments, suggestions, or experiences?  House projects you may be working on right now?  Leave a comment below, or send me an email.

Introduction

In the form of Q&A

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
Thank you for visiting my blog! This website is devoted to documenting free Android forensics techniques. In lieu of a mission statement of this blog, I'm going to provide a Q&A for what this blog is, what I intend it to be, and how you, the reader, can help.

What is this blog about?
This blog is a website for me to document some free Android forensics techniques. In the world of mobile forensics, there are all kinds of expensive tools that claim to handle all your mobile-related needs, like this, this, and this. It is my goal with this blog to demonstrate that there is (generally) another way. With some Linux knowledge (or willingness to learn it), a Windows computer and a Linux computer (or virtual machines), some free software (and I actually mean free, not 30 day trials), and some spare time and motivation to learn, you can do some outstanding work with Android forensics.

Who is the intended reader of this blog?
For starters, you. Thank you for reading! I wrote this blog for the following audiences:

• intending to target anybody who wants to do some Android forensics
• anyone who needs to do Android forensics on a budget (and if you do, I respect you and please do not hesitate to contact me for any help)
• smartphone enthusiasts
• researchers
• anyone stuck trying to get past an Android related challenge
• the curious person who just wants to learn more about their phone
• If this is you, you are awesome and keep doing what you are doing

Will this blog contain information specific to XYZ phone?
Normally not, but sometimes. I'll be looking at Android in a more general way, but I may reference a specific device from time to time. I am more likely to reference a specific version of Android. That being said, if you are looking for help with a specific phone, please reach out to me!

Will you cover mobile operating systems besides Android?
No, but I am knowledgeable in others. I have done a fair amount of iOS work, I won an award for best paper at an international forensics conference for work on the Maemo OS, I've dabbled around with Blackberry, but I've worked with Android far, far more than any other mobile OS. If you have a question about other mobile operating systems, contact me and I might either know the answer or know who to have you contact.

Will this be more of a technical blog or more about admissibility / best practices / forensic soundness?
This will be technical.
The word “forensics” has a lot of connotations when proceeded by the words “cyber,” “computer,” or “mobile.” The word “forensics” in its purest sense means the application of science to law. “Computer forensic science” is the study of digital media and its relation with court of law. Computer forensic examiners always think about admissibility in a court of law and follow documented best practices in order to avoid having digital evidence being declared inadmissible by a judge.
In the world of IT security, “forensics” is more often comparable to the words / phrases “incident response”, “exploits,” or “reverse engineering.” Traditional forensic examiners cringe when they hear IT folks toss the word “forensics” around.
Regardless of your perspective on “forensics,” you will need a strong technical background to be successful in the field of “Android forensics.”
To be honest, the best term to use to describe this blog is “CELLEX”, or “Cellular Phone Exploitation.” CELLEX is the technical field of creating tools and techniques to exploit the security of cellular phones and use those exploits to extract data. So ...

Why am I calling this blog “Free Android Forensics” instead of “Free Android-based CELLEX”?
I went with “Free Android Forensics” because the word “Forensics” is a better known word than CELLEX.

What is your background?
My background includes extensive work in mobility with a strong slant towards Android, including forensics, security, and research, in academia and in industry. Please check out my about the author page.

How can I help?
I am always looking for input from the field. The Android community is large and diverse. Every page on my blog has a comments page, and I encourage comments and interaction from the field. If you have a real life story similar to the content of the page, please post! If you have a question, please post! If you have a question but do not want it made public, contact me! If you have a different strategy than I use, post it! If you see an error in my work, please post and I'll address it.
Android forensics is a community, and collaboration is key to any community. I would like this blog to be a place where anyone can ask Android forensics questions, and if I cannot answer, I hope somebody else out there can.

Now for my posting regulations. I do not like policing comments and do not intend to do so, but if I must, I will. I'm a tech enthusiast and spend a lot of time on tech message boards searching for answers to specific problems, so I know how us tech people can be online.  So I only ask one rule:
Be nice and courteous to everybody.

All right! The basics are all out of the way. My first technical blog post will be on picking a forensic toolkit!

Questions, comments, suggestions, or experiences?  I do my best to keep up with the Android forensics community and am happy to chat with others in the field or anybody looking for some help in this field.  Leave a comment below, or send me an email.