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.