I've seen a trend in recovered stolen devices over the past few years: the bad guys are rapidly restoring devices to factory settings to prevent them from being tracked by the owner or law enforcement. That leaves me with a problem, though: how do I determine the owner of a device that has been restored? Allocated data that could show ownership is deleted upon a system restore. Since, I've discussed other devices in the past, today I'll focus on Androids.
Dispossessed Androids
I've had uneven success with Androids in the past. This may be due in part to the fact that I've not always know what to look for. But I received two more such devices this week and decided to apply myself, once again, to the problem of identifying the owners. Since I became an Android owner myself over the past 18 mos, I had a device with known data with which to experiment.
Nearly all data that contains identifying information is stored in the 'data' partition. When a device is restored or 'wiped' through the Android recovery system, personal data is removed. This process is usually quite fast, which leads me to believe that 'wiping' user data is a simple delete in most cases. There are custom recoveries where this might not be true, but a study of unallocated data in a wiped device reveals a rich data field.
In Unix-like systems, physical storage devices are attached to the operating system through special files (drivers) called device nodes. These nodes provide raw access to devices and their partitions. Thus, if a device node, also referred to as a block device, is addressed, all content is accessible, allocated and unallocated alike. Block devices can be thought of and addressed by software tools as files. To access block devices, however, one must have root access to the operating system. I will not be discussing the various ways to achieve root access to an Android device in this article, however. I will continue on the assumption that the device has been rooted.
Tinkering under the hood
Access to a running Android device is done through the Android Debug Bridge (adb). In a stock recovery or Android operating system, adb provides shell user access to the file system. The shell user has limited access to the device and commands, but the root user has full access. Root access, when not immediately granted through the adb shell command, is obtained by the su command.
shell@device:/ $
shell@device:/ $ su
root@device:/ #
Block device files are found in the /dev/block directory. The file representing the entire NAND flash is the /dev/block/mmcblk0 file. Partitions are represented as /dev/block/mmcblk0p1, /dev/block/mmcblk0p2, etc. A paritial directory listing in my device, for example, is:
/dev/block/mmcblk0
/dev/block/mmcblk0p1
/dev/block/mmcblk0p10
/dev/block/mmcblk0p11
/dev/block/mmcblk0p12
/dev/block/mmcblk0p13
/dev/block/mmcblk0p14
/dev/block/mmcblk0p15
/dev/block/mmcblk0p16
/dev/block/mmcblk0p17
/dev/block/mmcblk0p18
/dev/block/mmcblk0p19
We could address the entire memory storage device through mmcblk0, but it would be more efficient to address just the data partition. But which of these is the data partition? There are several ways to figure this out, and while not all of the following methods will work on every device, at least one should.
- If the data partition is mounted, such as would occur in a rooted and running operating system, simply issue the mount command:
# mount | grep /data
/dev/block/mmcblk0p25 on /data type ext4 (ro,relatime,barrier=1,data=ordered) - Check the contents of the /etc/fstab file:
# cat /etc/fstab
/dev/block/mmcblk0p24 /system ext4 rw
/dev/block/mmcblk0p25 /data ext4 rw
/dev/block/mmcblk0p26 /cache ext4 rw
/dev/block/mmcblk1p1 /sdcard vfat rw
/dev/block/mmcblk0p28 /emmc vfat rw
/dev/block/mmcblk1p2 /sd-ext rw
/dev/block/mmcblk0p21 /efs ext4 rw - Look for the 'by-name' directory somewhere in the /dev/block/platform subtree:
# ls /dev/block/platform/msm_sdcc.1/by-name/ -l | grep data
lrwxrwxrwx root root 2014-06-24 03:10 data -> /dev/block/mmcblk0p25
Note that the 'by-name' data file is actually link to the /dev/block/mmcblk0p25.
Getting to the Point
Ok, we know how to identify and address the data partition, but for what do we search? After some experimentation with my own device, it appears that a very profitable target are application license files. The com.application.vending domain contains application licensing information. On my device, I found 16 binary files in the /data/data/com.android.vending/cache/main/ directory that appear to be application licenses from applications downloaded from the Google Play store. While I could not find specific information about these files, a reading of Android developer page for licensing applications suggests this files purpose. Importantly all contained my username in the form of:
account="androiduser@gmail.com"
Crafting a search of the data partition of a restored device with this knowledge is fairly simple:
# strings mmcblk0p25 | egrep -o 'account="?.{1,25}@gmail.com"?'
Note: the strings and egrep commands are available through busybox which can be temporarily installed to the /dev/ folder (a temporary file system in RAM) if not already present in your environment using the adb push busybox /dev/ command.
Output of the search can be sorted and counted using a sort | uniq pipeline for clean results.
# strings -td mmcblk0.raw | \egrep -o 'account="?.{1,25}@gmail.com"?' | \sort | uniq -c | sort -n
1 account=user1@gmail.com
13 account=user2@gmail.com
970 account="user2@gmail.com"
2161 account="user1@gmail.com"
From the output, we can see there have been two user accounts. Did they both exist on the system at the same time. Has the device changed hands? We don't know, but we have two email addresses for contacting people who might know!
No comments:
Post a Comment