A quick note on imaging newer Android devices
A quick note on imaging newer Android devices
Actually a quick note
All blog posts to date
Introduction
Picking a Toolkit
Imaging an Android Device
Live imaging an Android device
Examining the image
Reverse Engineering an Android App File
The differences between a physical image and a logical extraction
Some hidden artifacts in a physical image
Using Autopsy to examine an Android image
Some artifacts in the /data/system/ directory
Viewing SQLite Databases
Facebook for Android Artifacts
Why not load ClockworkMod or TWRP to image a device?
Identifying your Userdata Partition
Some non-root methods to learn about a device
Interpreting data from apps
Dirty cow
Waze for Android forensics
Fun with Apktool
A quick note on imaging newer Android devices
Using Windows to Live Image an Android device
Imaging and examining an Android car stereo
Unpacking boot and recovery kernels
MTPwn
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 Ill make this one not so long-winded.
In a previous post, I demonstrated how to make a physical image of a device. So lets 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 youve wasted two plus hours. Im here to save you from wasting further hours.
Now users can set up more complicated encryption. If thats the case, I dont think the method below is going to work. Im talking about devices where the user just uses a simple pin or fingerprint lock, not a fully-encrypted device.
In a previous post, I demonstrated how to make a physical image of a device. So lets 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 youve wasted two plus hours. Im 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 thats the case, I dont think the method below is going to work. Im 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.
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 wont do you any good. Can anyone out there confirm? Once youve 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 youd 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
- Dont jump straight to chip-off. You might end any real chance at imaging the userdata partition
Comments
Post a Comment