Rabu, 28 Maret 2018
Live imaging an Android device
Live imaging an Android device
Not as hard as it sounds if you break it down
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 kernelsIntroduction
Live imaging an Android device is a complicated process but Ill do my best to break it down.First, I mentioned in my previous post that many computer forensic experts are rather opposed to live imaging. So before I get into the technicals, Im going to address forensic soundness here. (To skip over a discussion of forensic soundness, skip over a bit)
Forensic soundness considerations
Forensic soundness considerations
Forensic soundness is not a completely well defined term. In a paper titled �The Impact of Full Disk Encryption on Digital Forensics� by Eoghan Casey and Gerasimos J. Stellatos (Digital Investigation 01/2011; 8:129-134), the authors addressed forensic soundness in acquiring a live encrypted system, and stated the following:
�Setting an absolute standard that dictates preserve everything but change nothing is not only inconsistent with other forensic disciplines but also is dangerous in a legal context. Conforming to such a standard may be impossible in some circumstances and, therefore, postulating this standard as the best practice only opens digital evidence to criticisms that have no bearing on the issues under investigation.�
Forensic examiners often consider DNA typing a �gold standard� to which other forensic disciplines should strive, but when collecting biological samples for DNA analysis, the scene from which the biological samples are collected is altered, and the biological samples are actually destroyed during the analysis. This is a roundabout way of saying that �alter nothing� and �forensic soundness� do not mean the same thing.
In the realm of hard drive forensics, we are truly spoiled. With a write blocker and hashing techniques (like SHA-256), we can image a hard drive and authenticate the image as an exact copy of the original without altering the original drives data. (Note: when the drive is powered on, it spins, so the drives state changes at a physical level, but if hooked to a write blocker the data does not change.) Other digital forensic disciplines are often held to the same standard as hard drive forensics in terms of forensic soundness, for better or for worse.
Live imaging absolutely requires altering the device data. What I recommend is to document every step of the way if you pursue live imaging and be careful as to avoid unnecessary changes to the device. The files we will load to the device to do the imaging are very small, and I would recommend documenting the size of these files before loading them to the device.
Imaging the device
Now that is all out of the way. As I stated in a previous blog post, imaging a device (whether dead or live) requires three things: a data connection between the device and the computer, an exploit, and the imaging command. Lets knock one out at a time.
Data connection between the device and the computer
Connect the phone you want to image to the Linux computer. If you have not installed the Android SDK, do so now. (Update: I more recently posted on how to use Windows to make an image, but I do not fully endorse the method.)
We will be communicating with the phone using the Android Debug Bridge tool, or adb. Heres an official read-up on it. developer.android.com/tools/help/adb.html
Next, we need to treat the device as a debug device. Theres a good official writeup here: developer.android.com/tools/device.html
Follow the above link, then open up a terminal window. If you have installed adb and it is in your systems PATH, type the following:
adb devices
If adb is not in your PATH, then navigate to the directory including your adb binary and type the following:
./adb devices
If you dont know what Im talking about, I recommend including adb in your PATH. Check out this website for an explanation: http://www.linfo.org/path_env_var.htmland if you would like further clarification, Google it, post in the comments section, or contact me and Ill help you out.
Now, if when you type �adb devices�, you see something along these lines:
~$ adb devicesthen adb has found your phone. Great. If you type �adb devices� and all you see is the following:
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached
03************17 device
~$ adb devicesthen something went wrong and your computer is not seeing your device. Reach out to me and Ill try to walk you through.
List of devices attached
If your computer recognizes your device, then you in fact have a data connection between your computer and phone.
Exploit
Note: In this section, I will explain my personal way of rooting a phone and installing busybox. If you have a preferred method or if you find a way specific to your phone online that you would like to try, go for it. At the end of this section, you will need your phone rooted and have busybox installed, and there are multiple means to this end.
In 2009 and 2010 when the newest Android devices ran Android 2.2 and 2.3, security was a bit of a problem. You could run all kinds of one-click root exploits and gain an easy root shell. It was simple.
Then the developers at Google tightened the kernel quite a bit. In the newest versions of Android, there is not a public universal live Android exploit �
� until recently. A known security researcher wrote a tool called Towel Root, available at https://towelroot.com/. The exploit is a universal Android exploit that should work on all kernels released prior to June 2014. Download exploit at the following link: https://towelroot.com/tr.apk
A few notes on rooting your device:
- you may void your warranty
- root privilege is a powerful thing. You can easily make a mistake and �brick� your device
- if you render your device useless while following my blog or my advice, I am not responsible. You root your phone at your own risk. If by chance you do damage your device, contact me and Ill do my best to get you out of your rut.
To run the exploit, all you have to do is install the app. Once youve downloaded the app, run the following command from your command line on your Linux computer connected to your device:
adb -d install /path/to/tr.apk (where obviously /path/to is not a literal)
That command installs towelroot on your device. Dont run the app yet, but we will soon. Go ahead and verify it is on your device. It will appear in your app menu.
Next, install Busybox Installer from the Google play store. https://play.google.com/store/apps/details?id=com.jrummy.busybox.installer&hl=en. Busybox installs some extra Linux commands that are not installed by default on Android. Well need the netcat, or nc, command, which is included in Busybox.
You also can download busybox and install the APK via sideloading. You can find this apk by a Google search and install it via Android Debug Bridge. I say this option because if you have a phone without a Google account, you cannot use the Play Store.
You also can download busybox and install the APK via sideloading. You can find this apk by a Google search and install it via Android Debug Bridge. I say this option because if you have a phone without a Google account, you cannot use the Play Store.
I also advise installing a root manager. I recommend SuperSU. Heres a writeup on it: http://lifehacker.com/5895134/supersu-for-android-manages-root-permissions-so-you-dont-have-toand heres a link to SuperSU � https://play.google.com/store/apps/details?id=eu.chainfire.supersu
Now. Go to your Towelroot app and follow the instructions to root. Assuming no errors, you are rooted. Its a fast process. Next, open your Busybox app and follow the instructions to install. Again, assuming no errors, you have buybox.
Now it is time to have some fun. On your Linux computer, type the following:
adb -d shell
This starts up a shell session with your phone, allowing you to type commands to your phone and interact with it. From here on (or until you end the session), commands you type are issued to the phone. Refer to the previous adb link to see a writeup about shell commands on the phone.
Now type the following:
su
If you installed SuperSU, you may need to push an OK button on the phone, as mentioned in the lifehacker writeup. Assuming no errors, all of the next commands until you end this session run as root. Just to check to see if you are in fact root, type the following:
ls /data
If you get some kind of error, you are not root, because only the root user can read the /data directory. If you are root, you can see and edit the entire directory. Dont screw up, or else you may convert your phone into an expensive paperweight. If youre all set to this point, you have successfully exploited your phone. Give yourself a pat on the back for making it this far.
Imaging command
At this point, you are root and all ready to image. We will be using the dd command, which allows us to read and write device block files, and the netcat command, which allows us to forward commands across ports, to read the device block representing the entire device and write it to your computer across the USB connection. Easy, right?
Read over the following link on the /dev directory and device blocks. It will help make some sense: http://www.linuxjournal.com/article/2597
The actual command you will be using to image the device is rather specific to the device you have. It is because we need to image the right block. Reach out to me to find the right block for your device and I will give you an imaging command. You may want to image the entire device or just a certain partition and I can guide you through an imaging command as needed. For my personal phone (Nexus 5), the head block of the device is /dev/block/mmcblk0. Ill write a guide for how to image my personal device.
To image the device, you need to do some commands in two different sessions: one shell session to the device, and one shell session to your computer. Open up a terminal window and adb into your device. Then open up a new terminal window (it will open as a shell to your computer, not your phone) and navigate to the directory where you intend to store your image. Note: if you create the image in a volume formatted FAT32, the maximum file size is 4 gigabytes, so imaging the device would require splitting the file. For ease sake, I suggest imaging to a volume formatted ext or NTFS. Also, make sure the volume has enough space for the device image, which will be as large as the devices storage. For my phone, I need 32 gigabytes of storage to image.
Now, in the shell to your computer in the directory of your choosing, type the following:
adb forward tcp:8888 tcp:8888
This command allows adb to communicate via netcat on port 8888.
Next, in the shell to your phone, type the following:
dd if=/dev/block/mmcblk0 | busybox nc -l -p 8888
This command reads the contents of /dev/block/mmcblk0 (the head block of my device) and writes it via port 8888 across adb using netcat.
Finally, back in the shell to the computer, type the following:
nc 127.0.0.1 8888 > device_image.dd
This command saves the output of the contents across port 8888 (which will be the results of reading /dev/block/mmcblk0 on the device, or the complete image of the device) to the file device_image.dd.
If theres no errors, you are imaging the device. The window will �freeze�, or not allow any more commands because it is busy executing this command. When the imaging process is done, you will be able to type commands into this shell window again. To confirm, open a new terminal window, navigate to the directory where you are saving the image, and type ls -l. This will get a file listing, including file size. If the size of your file is increasing, you are successfully imaging your device.
Give yourself another pat on the back.
Forensic 4Cast awards
I would be humbled and honored if you would consider nominating my blog, Free Android Forensics, for the award "Digital Forensic Blog of the Year" presented by Forensic 4Cast.
Forensic 4Cast is an excellent resource for all things digital forensics. They run an annual awards ceremony for digital forensics achievements for the year.
2017 was a banner year for Free Android Forensics. From imaging an Android car stereo to studying the Waze app to imaging newer devices and some other fun topics, there was a lot to cover last year. I continually hope to serve the forensic community well by providing interesting topics.
As always, I thank you for reading. If you found my content useful, insightful, interesting, or maybe even funny, please consider nominating Free Android Forensics for Digital Forensic Blog of the Year.
Questions, comments, suggestions, or experiences? Other preferred ways to image Android devices without expensive kits? Leave a comment below, or send me an email.
Forensic 4Cast awards
I would be humbled and honored if you would consider nominating my blog, Free Android Forensics, for the award "Digital Forensic Blog of the Year" presented by Forensic 4Cast.
Forensic 4Cast is an excellent resource for all things digital forensics. They run an annual awards ceremony for digital forensics achievements for the year.
2017 was a banner year for Free Android Forensics. From imaging an Android car stereo to studying the Waze app to imaging newer devices and some other fun topics, there was a lot to cover last year. I continually hope to serve the forensic community well by providing interesting topics.
As always, I thank you for reading. If you found my content useful, insightful, interesting, or maybe even funny, please consider nominating Free Android Forensics for Digital Forensic Blog of the Year.
Summary
That�s all for now. Next page (which Ill post when ready) examines your image.- Imaging an Android device requires three things:
- A data connection between the device and the computer
- An exploit
- An imaging command
- Youve read over how to image my device.
- Reach out to me to help find the imaging command for your personal device
Questions, comments, suggestions, or experiences? Other preferred ways to image Android devices without expensive kits? Leave a comment below, or send me an email.
Langganan:
Posting Komentar (Atom)
Tidak ada komentar:
Posting Komentar
Catatan: Hanya anggota dari blog ini yang dapat mengirim komentar.