Some hidden artifacts in a physical image

Always get a physical image

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 my previous post, I discussed the differences between a physical image and the results of a basic Android forensics tool.  This post is a dive into some artifacts of a physical image which a logical extraction tool will not find.  Note:  this is a basic dive, not a deep dive.  The results should not be too surprising, but this post demonstrates some good reasons to obtain a physical image and browse the image in depth.


Initialization

For ease sake, I used an Android emulator instead of a physical device.  If anybody would like, I can redo the process on a physical phone.  Just let me know if that is important to you and I'll get on it.

I loaded the following PNG picture to the phone's /sdcard partition at the root.

Pirate Android!!

And then I sent a text message.  (This is an emulator, so the message doesn't actually go anywhere, but the emulator will store data just the same way regardless.)

I deleted the Pirate Android image, and then I deleted the text message.

Extractions

I performed some basic extractions.  First, I ran the Open Source Edition of viaForensics' viaExtract tool, which is included free with Santoku.  viaExtract is a basic logical extraction tool that can extract SMS.

Then I used the Android shell to browse through the Android emulator to see what files exist and do not exist.

And finally, I emulated a physical image of the device.  What I mean by an emulated physical image is I copied the files which represent the emulator's storage and viewed them with a hex editor.  On Linux, these files are stored at /home/<username>/.android/avd/

The above extractions represent a logical extraction, logical browsing, and a physical extraction.


Results

The viaExtract tool did not detect the deleted text message.  viaExtract uses device APIs to extract data and stores the extracted data in CSV files.  The below image is the CSV file containing discovered SMS messages, which in this case is none.  (And for what it is worth, I have run this tool on emulators before and I can confirm that viaExtract can successfully extract SMS from an Android emulator, so the results from viaExtract do not represent an error.)

When browsing through the emulator's SD card, the Pirate Android file is gone, predictably, as I deleted the file previously.

The physical image contained some more interesting results.  First, I used a hex editor to explore the userdata partition and found in slack space the deleted SMS.

The deleted message clearly contains the deleted text ("You will never find this message!" and the "recipient" ("678-9").

I also found a PNG image in the image of the SD card.

So I copied the beginning to the end of the PNG file I found in slack to a new file and opened the resulting file as a graphical file and ...

Pretty cool, huh?

Discussion

So what can explain all of these results, and what does it all mean?

viaExtract is a basic logical extraction tool and relies upon device APIs to extract data.  The device presents an API to extract SMS messages, but there is no API to extract deleted messages.  There is no way that any logical extraction tool will be able to leverage only device APIs to extract deleted SMS.

Note:  the tool from viaForensics is a basic logical extraction tool.  viaForensics has some true experts who can do the dive demonstrated in this post and way, way better.  The folks at viaForensics are definitely experts in mobile forensics.  I personally respect the company greatly.  I chose the viaExtract tool because it is a basic logical extraction tool and it is free with Santoku.

It should not be a surprise that a deleted file does not show up when shelling into the emulator.  As seen above, the Pirate Android image is not in the device according to the shell.  A device shell can only display what files the file system knows exist, and the file system knows that the Pirate Android image is deleted.

So why was I able to recover a deleted text message and a deleted picture?  The reason is simple: the deleted text message and the deleted picture were not overwritten or destroyed.  As long as data is not overwritten, it can be found in a physical image using a hex editor.

The big picture of this post is that you really want a physical image, and you also really need to examine the image using a hex editor.  It can be hard to find artifacts, but these artifacts are there. A digital forensics expert should be proficient with a hex editor.

There are some ways automate finding artifacts, such as file carving.  I recommend using a variety of automated tools, and I have a relevant example here.  I used scalpel, an open source file carving tool, and scalpel actually did not recover the Pirate Android image.  I would bet that if I tried several other file carving tools, at least one tool would have recovered the Pirate Android.  Not all tools work all the time, but the more tools you try, the better results you will get.  But of course, you can always use a hex editor and take a lot of time to find as many artifacts manually as you can.

Summary

• Logical extraction tools rely upon device APIs which limits their effectiveness
• Obtain a physical image of the device if you can
• All kinds of artifacts can lie in the hex of an Android device
• Use automated tools but do not rely on just one

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