And why it can be a good call
All blog posts to date
Introduction
In my previous post, I made a major announcement. Spoiler alert, I'm going to be a dad!
I have since learned, well, a lot. If I were to boil down everything I've learned so far, it would be as follows:
- The words "crib", "pack 'n play", and "bassinet" are not synonymous.
- Strollers are in fact fashion items for parents, not vehicle for children, and are priced accordingly.
- There are many brands of baby bottles. And they are different. And your baby decides which one he or she likes, regardless of how many of a different brand you have purchased.
- Baby monitor systems are nothing short of security camera marvels. And as a security person, I am leery of every claim made regarding wireless security.
- Kids don't come pre-programmed to sleep through the night. And there is no golden guide to expediting the learning process.
- Consignment shops are great places to buy baby stuff. So long as you don't think about drool from other children.
- A bouncer is not just a big guy outside of a bar.
- A rocker is not just a cool guy with a guitar.
- Rockers either go left to right or front to back. And babies only want one or the other, regardless of which one you have already purchased. Or sometimes they want both.
- Car seats are like food. They have expiration dates. And you don't want to buy them used.
So as you can imagine, this has been quite the learning curve! I wish somebody would write a good guide to this whole parenting thing meant for us computer guys, except I know us computer guys never read manuals. Unless they are short.
So on that note, here's a nice short post on obtaining all the user data files from an Android device instead of a physical image. And why you may do such a thing.
Why would I want to do such a thing?
So in what scenario would you want to skip the process of physically imaging an Android device in lieu of a file system dump? Well first, what exactly am I talking about?
A physical image is a file (or set of files) representing the beginning to end of a storage volume, such as a hard drive, or in this case, an Android device. It contains every bit of data, stored just as stored on the device itself. Done properly, a physical image is an authentic duplicate of the device in question.
A file system dump is a copy of all the files in a specific volume. It contains just files. No deleted records, no slack space, just files.
In Android, all user data is stored in a partition called userdata. If you only had to pick out one area of the device to image, you would pick userdata, every single day. That is where all databases, user activity, installed apps, all app data, and logs are stored. And assuming there is no external SD card, it is also where photos, videos, and other media files are stored. So this post is about acquiring all the files from userdata. Not slack, just files.
So why would we do that? Here are some possible reasons:
- You are in a rush
- This is not a criminal case, it is only for research
- You already obtained a physical image but are having a hard time parsing a file system (more on that later)
How do we do it?
Now that I've explained what we are doing and why, let's get it done. First, just like in obtaining a physical image, your device needs to be rooted, and you also need busybox installed. Hook up your rooted Android device to your Linux or Mac computer.
Now we are going to use multiple terminals the way we do in live imaging a phone. Open up two terminals.
Terminal 1 will be for interacting with the device. We are going to port forward, effectively making a network connection between the computer and the device over the USB cable. We will create the archive file and pass it over that USB cable to the computer.
Port forward to create that network.
adb forward tcp:8888 tcp:8888
Open up an adb shell with your phone using the following command:
adb shell
Once shelled in, gain root.
su
Then we will begin making the archive.
busybox tar -cvz /data | busybox nc -l -p 8888
If all goes well, the screen should freeze. This command copies all of /data into an archive file and passes it over the USB wired network connection to whoever is listening. Which leads us to Terminal 2.
Terminal 2 will be for interacting with the computer and receiving the archive file. First, go to the directory you want the archive to arrive.
cd /path/to/desired/location
Now use netcat to listen to the USB network connection and receive the archive.
nc 127.0.0.1 8888 > data.tar.gz
If all goes well, the screen should freeze. This command listens to local port 8888, as set up previously with the adb forward command, and passes whatever comes out to the file data.tar.gz.
You can optionally open a third terminal for monitoring progress. Navigate to the same location as terminal 2 and use ls -l to check the file size.
When all is done, you will have the file data.tar.gz, containing all the user files. No slack, just files.
f2fs
And finally, a note on f2fs, or Flash Friendly File System. f2fs is an alternate file system to ext4. f2fs seems to perform far faster than ext4 and may someday be the default on Android devices. As is, only a few devices have f2fs support. But I know this is problematic because I have received several emails asking for f2fs assistance. To that, I say two things. One, thank you for letting me know. This post is largely because of calls for f2fs support. Such emails keep me posted on what all issues are out there. And two, f2fs support forensically is currently not good.
FTK Imager does not have f2fs support as of right now. Neither does Autopsy. Some of the pricey tools have f2fs support, but the free tools are lacking. There is Linux support for f2fs, but I've had limited success.
So, if you are trying to image device where userdata is formatted f2fs, my suggestion is as follows. Use this post to obtain a file system dump of the data partition. Then if you would like, obtain a physical image for searching through slack.
Summary
- You can obtain a file system dump of an Android device's data partition, and in some circumstances, this is just what you are looking for.
- The process is similar to obtaining a physical image.
- Without good f2fs support, consider this process if you are working with an f2fs-enabled device.
Questions, comments? Dad advice? Leave a comment below, or send me an email.
