Monday, October 20, 2014

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
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
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.


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.


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.


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?


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.


  • 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.


  1. Hi, Can you please explain what tools did you use to extract the data from the memory? I am trying to read android memory like what we do in windows and am using the WinHex but it does not work!

    1. Phones are different from hard drives. Read my guide: