Always get a physical image
All blog posts to date
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
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
