Slurp a disk image of the data partition on an Android device

Question

I hope it won't sound like I'm up to no good -- I'm actually motivated by this problem -- but I'm trying to slurp down a raw disk image of the data partition of an Android device. Ie, not just the files stored there but all the orphaned file fragments and everything.

If I can achieve that then I can write some code to sift through that raw data and do some data forensics.

(I hope the recovery part of this question is sufficiently programming-related. I don't think I'm going to get an answer anywhere else and I intend to offer a large bounty for any answers here.)

Answer 1

It is unfortunate that the data is on the built-in storage. Does your phone automatically provide USB Mass storage mode access to the hardwired storage when you plug it into a computer? If so, you might be in luck still.

I'd suggest using a Linux machine and make sure that udevd(8) won't try to mount the drive when you plug it in -- you want to mount it read-only, which won't be the default. (Depending upon your distribution, it might have some other mechanism to automatically mount filesystems on USB mass storage drives when they are attached. If so, find them and turn them off.) Maybe service udev stop or /etc/init.d/udev stop are sufficient to stop udevd(8) from pretending it knows better.

Check dmesg(1) output to find the device name that the hardware takes when it is plugged in. I'll pretend it reports /dev/sde.

dd if=/dev/sde of=~/android_backup bs=4096
chmod 400 ~/android_backup

The if specifies the input file, the of specifies the output file, and bs asks for a blocksize of 4096. (There's nothing magical about 4096 -- it is the size of a memory page on many platforms, so blocks of this size can sometimes be moved around more efficiently than smaller blocks.)

The chmod(1) command makes it more difficult to modify the backup by removing write permission.

This makes a copy of the entire "drive" -- all the filesystems. This might be more difficult for programs to handle, so grab the specific partition your data is on while it is mounted -- it'll never be easier than now:

dd if=/dev/sde1 of=~/android_partition bs=4096
chmod 400 ~/android_partition

(If there are multiple, maybe grab them all. Disk space is cheap.)

Once you've got the image, you need to figure out how to salvage the data from it. It might be there, it might not be there, but there are some immensely helpful tools available that can help.

I've used Autopsy (part of The Sleuth Kit) before to recover deleted images from FAT-based camera storage. Granted, FAT is an easier problem, but they claim to support many filesystems, and it would be my first choice.

I haven't used Scalpel but it looks promising. It uses binary magic numbers to identify and slurps files out. It claims to be suitable for forensics use, but I don't know happily it will recover data from deleted files. (Since it claims it can handle raw partitions, I've got a good feeling about it.)

I've fiddled around with debugfs(8) before, but never used it when the stakes mattered. It looked amazing -- but also looked like it requires the user to have more advanced knowledge of ext* filesystems to do anything really useful. Read the manpage and guess if you think it's worth trying.

And don't forget you're not alone -- companies are available that can help recover data. (I've selected this specific company because I know Erik from this company and know him to be careful, thoughtful, and good at what he does. There are more companies than just this one but it'd be nice to find one that does more than just run Autopsy on images. You can do that.)

Answer 2

Can't be done on "normal" devices via application: http://developer.android.com/guide/topics/security/security.html

Possibly it can be done on rooted devices, but this will depend on particular ROM. I guess you'd need a dd command.