Actually a quick note
All blog posts to date
Introduction
I was on the phone with a good friend of mine earlier this week. He called me long-winded. According to my wife, my family, my friends, and my coworkers, the statement was accurate. So I'll make this one not so long-winded.
In a previous post, I demonstrated how to make a physical image of a device. So let's say you have a rooted newer device, like Android 7.0 or newer, and you follow that guide and image /dev/block/mmcblk0. You open the image in FTK Imager or any other viewer of choice, and it all looks good until you get to the userdata partition. You get the dreaded "cannot read filesystem" or "unknown file system" or other such error. You get ticked off because you just spent an hour plus imaging the device, and now it looks like the most important partition by a long shot imaged wrong. So you go back and do it again and receive the same results. Now you've wasted two plus hours. I'm here to save you from wasting further hours.
File by file encryption
By default, many newer builds of Android include file-based encryption on the userdata partition. The long and short of it is the entire partition is not encrypted, but each file is. So if you capture the partition with no attempt to decrypt or otherwise circumvent the encryption, you will not be able to view the data.
Now users can set up more complicated encryption. If that's the case, I don't think the method below is going to work. I'm talking about devices where the user just uses a simple pin or fingerprint lock, not a fully-encrypted device.
So when you image /dev/block/mmcblk0, you image the entire internal storage, beginning to end. The problem here is imaging that entire internal storage grabs an encrypted version of userdata. So we need to image a decrypted version.
Check out my previous post on identifying your userdata partition. In the post, I explain how to use the "mount" command to find the block mounted at /data. That block is your userdata, and if you image that, you get just the userdata partition.
As it works out, that same method can bypass the Android 7.0 file based encryption (again, so long as the device is not fully encrypted).
So if you have such a device, adb shell into it and type the following command:
Point is, find the one mounted at /data. Image just that one. See if you get a cleaner version of the userdata partition.
I fully expect that if you were to do a chip-off forensic imaging process of a newer device, you would get the same garbled output as you would if you imaged /dev/block/mmcblk0. So if you get newer devices, chip-off probably won't do you any good. Can anyone out there confirm? Once you've got the chip removed, it is difficult if not impossible to put it back in place. Chip-off is a rather one-way method.
Note: I can do a screenshot demo of the above, or maybe even a video demo. However, I currently do not have an Android 7.0 capable "hack-around" phone or tablet. I had been using a Nexus 7 (2013) and a Nexus 5 as hack devices. The Nexus 7 is no longer supported on new Android versions, and the Nexus 5 has ... seen better days. Those were pretty cheaply manufactured phones and 3.5 years of daily use did little good. So if you'd like to see some demos, consider clicking on the PayPal link on the right side and making a small donation to help offset the cost of a newer hack-around device.
See? Not so long winded, huh?
Summary
I was on the phone with a good friend of mine earlier this week. He called me long-winded. According to my wife, my family, my friends, and my coworkers, the statement was accurate. So I'll make this one not so long-winded.
In a previous post, I demonstrated how to make a physical image of a device. So let's say you have a rooted newer device, like Android 7.0 or newer, and you follow that guide and image /dev/block/mmcblk0. You open the image in FTK Imager or any other viewer of choice, and it all looks good until you get to the userdata partition. You get the dreaded "cannot read filesystem" or "unknown file system" or other such error. You get ticked off because you just spent an hour plus imaging the device, and now it looks like the most important partition by a long shot imaged wrong. So you go back and do it again and receive the same results. Now you've wasted two plus hours. I'm here to save you from wasting further hours.
File by file encryption
By default, many newer builds of Android include file-based encryption on the userdata partition. The long and short of it is the entire partition is not encrypted, but each file is. So if you capture the partition with no attempt to decrypt or otherwise circumvent the encryption, you will not be able to view the data.
Now users can set up more complicated encryption. If that's the case, I don't think the method below is going to work. I'm talking about devices where the user just uses a simple pin or fingerprint lock, not a fully-encrypted device.
So when you image /dev/block/mmcblk0, you image the entire internal storage, beginning to end. The problem here is imaging that entire internal storage grabs an encrypted version of userdata. So we need to image a decrypted version.
Check out my previous post on identifying your userdata partition. In the post, I explain how to use the "mount" command to find the block mounted at /data. That block is your userdata, and if you image that, you get just the userdata partition.
As it works out, that same method can bypass the Android 7.0 file based encryption (again, so long as the device is not fully encrypted).
So if you have such a device, adb shell into it and type the following command:
mountYou will see a list of all mounted partitions. One of them might look something like this (mind the edits for making it a bit generic) ...
/dev/block/platform/something/dm-0 /data ext4 rw,bunch of other mount commands
Point is, find the one mounted at /data. Image just that one. See if you get a cleaner version of the userdata partition.
I fully expect that if you were to do a chip-off forensic imaging process of a newer device, you would get the same garbled output as you would if you imaged /dev/block/mmcblk0. So if you get newer devices, chip-off probably won't do you any good. Can anyone out there confirm? Once you've got the chip removed, it is difficult if not impossible to put it back in place. Chip-off is a rather one-way method.
Note: I can do a screenshot demo of the above, or maybe even a video demo. However, I currently do not have an Android 7.0 capable "hack-around" phone or tablet. I had been using a Nexus 7 (2013) and a Nexus 5 as hack devices. The Nexus 7 is no longer supported on new Android versions, and the Nexus 5 has ... seen better days. Those were pretty cheaply manufactured phones and 3.5 years of daily use did little good. So if you'd like to see some demos, consider clicking on the PayPal link on the right side and making a small donation to help offset the cost of a newer hack-around device.
See? Not so long winded, huh?
Summary
- Many newer devices likely include file-based encryption, resulting in garbled user data if you image the entire device
- Use the mount command to find the right partition and you should be in good shape
- Don't jump straight to chip-off. You might end any real chance at imaging the userdata partition
