Imaging an Android device

Imaging an Android device - Selamat datang di situs media global terbaru Xivanki, Pada halaman ini kami menyajikan informasi tentang Imaging an Android device !! Semoga tulisan dengan kategori ini bermanfaat bagi anda. Silahkan sebarluaskan postingan Imaging an Android device ini ke social media anda, Semoga rezeki berlimpah ikut dimudahkan Allah bagi anda, Lebih jelas infonya lansung dibawah -->


(It's not magic)


All blog posts to date
Introduction
First things first, what does it mean to “image” a piece of digital storage? A “digital image”, or just an “image”, is a digital replica of … something. That something can be a hard drive, a partition, a phone or tablet, RAM, or more.

Imaging a hard drive is a straight forward process. We can easily create a digital image of an entire drive. This image will be a single file (or a collection of files) which is a bit-to-bit representation of the physical hard drive. It is the beginning to the end of the drive in one file, including all deleted space. The drive can be imaged behind a “write blocker”, which prevents writes to the drive. It allows us to image the drive without the risk of accidentally writing anything to it. We can also calculate a mathematical hash on both the original drive and the created image to ensure that we have a 100% authentic image of the drive.

Imaging an Android device is not so straight forward. There are a few differences.
  • a drive is storage. Not a complete computer system, just storage. It does not have an operating system giving it commands to read and write if unattached to a computer. Even if the drive stores an operating system, it cannot execute the operating system without being attached to a computer.  If a computer asks the drive to export a file, or an image of the entire drive, it just executes the command.
    • a phone (or tablet) is a complete system which includes storage. If we want to image a phone the way we do a hard drive, we need to open up the phone and remove the chip which contains all the storage and connect it to a highly specialized system to do the extraction, at great risk of damaging the data and at great damage to our wallets as this is a process which requires a specialist.
    • instead, we connect the phone to a computer and treat it as a computer and issue it commands to image.
  • we can connect a write blocker between a computer and a hard drive. As stated before, a hard drive is just storage.
    • there is no write blocker to connect to a phone. We can issue commands to a phone from a computer via a USB cable (and you can connect a write blocker there if you really want but it is neither necessary nor desirable in most cases). However, the phone itself can and always does issue read and write commands to its internal storage. We cannot block those writes.
  • when a drive is connected to a computer via a write blocker, no bits on the drive change. This allows us to calculate a hash to make sure we have an authentic image of the drive.
    • a phone is a complete system. It is constantly issuing those write commands. The state of the phone's storage changes during the imaging process as the phone is constantly logging.

So, we treat a phone as a complete computer. We do not extract the storage chip and read it directly (though if you have a good reason to do that, I know some people who are experts in this process and can direct you their way.) So how do we image a phone? Do we connect it to a computer and hit a single button? Not exactly. To image a phone, we need three things:
  1. A connection between our computer and the phone. We will be using the Linux environment, and we connect via USB. Easy.
  2. An exploit to the phone. The phone is a Linux-based device that has Linux-based security, and one security measure disallows us to simply dump the phone's storage. We need some kind of security exploit which allows us root access to the device. This exploit may be a live exploit where we gain root access to the device while it is booted, or it may be a “dead” exploit where the phone is booted into a different mode entirely and we have root access.
  3. A command to image. We need to be able to run a command as root which images the device and passes the image one bit at a time across the USB cable to our computer where we store it in a set location.

As I said in point 2, these steps are the same whether we are “live” or “dead” imaging, though the exploits are completely different. And that raises a point … what are these exploits?

An exploit is a piece of code which takes advantage of a security vulnerability and gives us root access. (If you do not know what root access is, go ahead and Google “Linux permissions” and “Linux root.” Linux permissions are good to study but not something I intend to cover. But for the quick definition, root access means god-like access to be able to do and see anything on the device.) Now as I described repeatedly, these Android devices are full computers. One Android device is not the same as the next. Different versions of Android, different manufacturers and their custom code baked into the system, and different devices have their own exploits. There has never been a catch-all Android exploit … until recently, which I will go over in the live imaging page.

As I previously alluded to, there can be “live” and “dead” exploits.

A live exploit is a piece of code that executes while the device is booted into Android. This piece of code runs and exploits a vulnerability in the system and gives you root access to the device, all while Android is running and all your apps are doing their things. Imaging a device while it is live means that you will be creating an image while the device is active. (Note of forensic soundness: many computer forensic examiners are currently cringing while reading this. I personally advise live imaging if you are comfortable with the process and comfortable with Android and command line. The actual exploit you will be loading is very small. Yes, it means you are “changing the evidence,” but we're talking about small files here. Document what you have done so you are accountable for any changes and you should be fine.)

A dead exploit, meanwhile, entails booting the device into another state. If you have installed a custom recovery mode, like ClockwordMod, then you have installed a dead exploit to the device. You can reboot to recovery and now you have a root shell. If you use a Cellebrite Physical, you are using a dead exploit. The Cellebrite kit uses bootloader runtime exploits, meaning it attacks the bootloader and does not write any code. Dead exploits are very device specific. There are some devices where we just do not have a dead exploit. In many devices, loading a custom recovery mode involves wiping all user data on the device, so if you are going for forensic soundness, you could probably see a minor issue here. Until recently, there was no universal live exploit either, but we now have a universal live exploit, or at least universal for all devices released prior to the exploit.

I will not be doing a page dedicated to dead imaging, unless the demand is there.  Dead imaging either relies on an expensive tool like a Cellebrite Physical or it requires loading a custom recovery mode and those are different device to device.  I will be doing a full guide on live imaging.

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
  • We cannot image a phone or tablet like a hard drive.  We treat it as a whole system.
  • Imaging an Android device requires
    • A data connection between the device and the computer
    • An exploit
    • An imaging command
  • We have live and dead exploits for live and dead imaging

Now that I've explained what exploits are and the differences between live and dead imaging, it is time to image. In the next post, we will live image a device.

Questions, comments, suggestions, or experiences?  Leave a comment below, or send me an email.



Demikian info Imaging an Android device, Semoga dengan adanya postingan ini, Anda sudah benar benar menemukan informasi yang memang sedang anda butuhkan saat ini. Bagikan informasi Imaging an Android device ini untuk orang orang terdekat anda, Bagikan infonya melalui fasilitas layanan Share Facebook maupun Twitter yang tersedia di situs ini.

Previous Post Next Post