Pages

Sunday, August 10, 2014

Live imaging an Android device

Not as hard as it sounds if you break it down


All blog posts to date
Introduction Acquisition Analysis
Introduction Imaging an Android Device Examining the image
Picking a Toolkit Live imaging an Android device Some hidden artifacts in a physical image
Why not load ClockworkMod or TWRP to image a device? Using Autopsy to examine an Android image
Identifying your Userdata Partition Some artifacts in the /data/system/ directory
Some non-root methods to learn about a device Viewing SQLite Databases
A quick note on imaging newer Android devices Facebook for Android Artifacts
Using Windows to Live Image an Android device Interpreting data from apps
Obtaining all files in the data partition without a physical image Waze for Android forensics
Magnet Forensics App Simulator
App Reversing Other Topics
Reverse Engineering an Android App File The differences between a physical image and a logical extraction
Fun with Apktool Dirty cow
Deep dive into an app Imaging and examining an Android car stereo
Unpacking boot and recovery kernels
MTPwn
Introduction
Live imaging an Android device is a complicated process but I'll 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, I'm going to address forensic soundness here. (To skip over a discussion of forensic soundness, skip over a bit)

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 drive's data. (Note: when the drive is powered on, it spins, so the drive's 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. Let's 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. Here's an official read-up on it. developer.android.com/tools/help/adb.html

Next, we need to treat the device as a debug device. There's 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 system's 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 don't know what I'm talking about, I recommend including adb in your PATH. Check out this website for an explanation: http://www.linfo.org/path_env_var.html and if you would like further clarification, Google it, post in the comments section, or contact me and I'll help you out.

Now, if when you type “adb devices”, you see something along these lines:
~$ adb devices
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached
03************17 device
then adb has found your phone. Great. If you type “adb devices” and all you see is the following:
~$ adb devices
List of devices attached 
then something went wrong and your computer is not seeing your device. Reach out to me and I'll try to walk you through.

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 I'll do my best to get you out of your rut.

To run the exploit, all you have to do is install the app. Once you've 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. Don't 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. We'll 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.

I also advise installing a root manager. I recommend SuperSU. Here's a writeup on it: http://lifehacker.com/5895134/supersu-for-android-manages-root-permissions-so-you-dont-have-to and here's 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. It's 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. Don't screw up, or else you may convert your phone into an expensive paperweight. If you're 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.  I'll 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 device's 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.

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 there's 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.

Summary
  • Imaging an Android device requires three things:
    • A data connection between the device and the computer
    • An exploit
    • An imaging command
  • You've read over how to image my device.
  • Reach out to me to help find the imaging command for your personal device

That’s all for now. Next page (which I'll post when ready) examines your image.

Questions, comments, suggestions, or experiences?  Other preferred ways to image Android devices without expensive kits?  Leave a comment below, or send me an email.

99 comments:

  1. This comment has been removed by the author.

    ReplyDelete
    Replies
    1. Live Imaging An Android Device >>>>> Download Now

      >>>>> Download Full

      Live Imaging An Android Device >>>>> Download LINK

      >>>>> Download Now

      Live Imaging An Android Device >>>>> Download Full

      >>>>> Download LINK Zj

      Delete
  2. Cool blog and very useful set of information. I’ve managed to dump images of Android phone partitions on Windows, with Ncat and recommended software for Android. However, I’ve got a problem at opening image of data partition and image of whole ROM in Autopsy. Data partition image – Autopsy hangs forever on processing data source (step 3 of adding source). Tried different ingest modules and alone Android ingest module. Full ROM image – Autopsy cannot determine file system (Sector Offset: 0). No such problems with system partition image. I can view contents of data, system and whole ROM in FTK Imager.

    Is this a problem with finding the right block to start dumping image? Phone is Samsung GT S5570 Galaxy Mini, system – Android 2.2.1, kernel – 2.6.32.9-perf. Partitions where taken from /dev/block. Searched them only by mount and ls commands. I think that data partition is at stl13, system partition is at stl12. Whole ROM of this phone is – according to info from some flashers – at bml0 (but there is only blm0!c in /dev/block). I’ve dumped bml0!c to about 500 MB image.

    Any tips how to start acquiring images at right block and reading data partition or full ROM images with Autopsy?

    Some edit. On Github/SleuthKit/Autopsy forum some guy wrote that it is possible to avoid error: Autopsy cannot determine file system (Sector Offset: 0) - by adding image with Add logical file option. I've tried this right now, but analysis have almost no results - only almost empty LogicalFileSet.

    ReplyDelete
    Replies
    1. Pawel,
      Thanks for checking out the blog and for the compliment!
      You're trying out Autopsy and having problems? I'm not familiar with your particular device. Correct me if I'm wrong - you loaded the entire device image and the data file system could not be interpreted, and then you loaded the data partition individually and it could not be interpreted. Autopsy reported that it could not interpret the file system on the data partiton.
      Is the data partition formatted ext4 or is it yaffs?
      How to determine: go back to your shell on the device and type "mount". You'll get a list of all mounted partitions. Here is my data partition on my gs5 as the mount command reports:
      /dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4
      As you can see by the last bit of that entry, the partition is formatted ext4. Try out the mount command and let me know what you get. If the partition is formatted yaffs2, I'll need to do some digging because I've not found a reliable yaffs2 interpreter but I haven't needed to look for one in a while.

      Delete
  3. Thanks for the reply. I think this is RFS file system.
    Mount command gives that:

    # mount
    mount
    rootfs / rootfs ro,relatime 0 0
    tmpfs /dev tmpfs rw,relatime,mode=755 0 0
    devpts /dev/pts devpts rw,relatime,mode=600 0 0
    proc /proc proc rw,relatime 0 0
    sysfs /sys sysfs rw,relatime 0 0
    tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
    /dev/stl14 /cache rfs rw,nosuid,nodev,relatime,vfat,llw,check=no,gid/uid/rwx,iocharset=utf8 0 0
    /dev/stl13 /data rfs rw,nosuid,nodev,relatime,vfat,llw,check=no,gid/uid/rwx,iocharset=utf8 0 0
    /dev/stl12 /system rfs ro,relatime,vfat,log_off,check=no,gid/uid/rwx,iocharset=utf8 0 0

    Anyway, I've succeeded with pulling info with the help of FTK Imager extract file function. For extracted databases SQLite Manager was a good choice. For full ROM image - FTK Imager had displayed only Unrecognized file system and a single 500 MB file in it - Unallocated space. I've extracted this file and opened it in better hex editor (with bookmarked search results for text etc.). And then needed text results were obtained.

    ReplyDelete
    Replies
    1. Pawel,

      First, great work!
      If I'm gathering correctly, you loaded the data partition alone into FTK imager and Imager read it fine. But when you loaded the entire device image into FTK imager, imager could not read the data partition. That is strange, but good feedback to hear.
      The partition is a fat32 partition. The data partition line in your mount command results indicates "vfat" which means a fat partition. With how universal fat32 is, I'm really surprised that your data partition tripped up either FTK imager or Autposy. Again, good feedback, and I'm glad you got a workaround. Did you find everything you need? If not let me know if I can give you some more pointers. Great work!

      -Mark

      Delete
  4. Hey there. I'm trying to recover data from an HTC One M7 that I have unlocked and rooted. Unfortunately a factory reset was done before I got my hands on it. I have tried a myriad of data recovery tools and haven't been able to pull any data from the phone. I'm mainly concerned with the SMS from a particular number. I have been doing IT work for 15 years but I am new to digital forensics. Any assistance would be greatly appreciated.

    ReplyDelete
    Replies
    1. So I am not familiar with that specific phone's wipe method. Some phones, generally older ones, left all kinds of artifacts in storage after a factory reset that show up in a forensic image. Some newer ones do a better job at sanitizing.

      So what I would do is image the device. The image allows you to preserve device storage as is. Any deleted data could be overwritten the next time you change or create a file.

      Then if you know the number, search the hex of your image for that number. If you find some hits, take note of the context.

      Also, look at the hex of the SMS database from the image. /data/data/com.android.providers.telephony/databases/smsmms.db. Not that the SMS will be there because this database will only contain post-wipe messages. But looking at the hex will give you an idea of how messages are stored. Look for a known message and number in the hex, see how the number is stored / how the message is stored / how the timestamp is stored, etc. Then if you get a hit on your phone number in the hex of the forensic image, you have some context to work with.

      Does that all make sense? Best of luck!

      -Mark

      Delete
    2. Hey Mark..Thanks so much for the reply. Yes, what you said made sense. The weird thing is the phone doesn't have the (/data/data/com.android.providers.telephony/databases/smsmms.db). There are a handful of folders with the com.android extension, but nothing for sms or mms. You also mentioned that each phone has a different imaging command. Are you familiar with the one for the HTC One M7 (AT&T). Also, one last question; what software do you recommend to try to retrieve lost of deleted data (specifically texts in my case)? Thanks again for you blog and you assistance.
      Bethani

      Delete
    3. So I literally just in the last hour or so put up a post on how to find the userdata partition. Figured I'd share my way of figuring out the imaging command if you want just userdata. Hopefully this helps some ... http://freeandroidforensics.blogspot.com/2015/10/identifying-your-userdata-partition.html

      The com.android.providers.telephony is the standard location for SMS. I'd be quite a bit surprised if the directory is not there, but Android has surprised me quite a bit many times before. It is possible HTC wrote SMS to a different location. I do not have an HTC laying around to check but if I did I would.

      For recovering lost SMS, I really can't recommend any software. That kind of carving is an inexact science. Basically I personally wouldn't trust any carver - they're just not that advanced. I would definitely go manual on this one. Search for the phone number. Simplest way you can - instead of 1-222-333-4444, just search 2223334444. If you can find the SMS database look at that one both in a sqlite viewer and in a hex editor so you can see how phone numbers are formatted. Then you can search consistently with the expected format.

      Not gonna lie - you're in for a real challenge. But if you can find just one message, you know there could be a bunch more.

      Delete
    4. Mark,
      Thanks so much for everything. Your blog is very helpful and full of amazing info. I am grateful I ran across it and found you. I'll let you know how it goes. I like a good challenge ;)
      Bb

      Delete
    5. Hi, just wondering if there's a tool that can perform a hex based search for printable strings according to user specified criteria such as "minimum string length: 10" etc..

      It seems like I remember seeing one out there.. Or would that even be applicable in this situation?

      Delete
    6. Eddie - I'm sure there are some tools along those lines out there but I cannot think of one off the top of my head. It sounds to me like a good scripting challenge. Are you a scripter? And do you know string / regex operations?

      Delete
  5. Hey Mark...Me again. I double checked, and the smsmms.db directory is non-existent. I could send you a screen shot, but without it, I'm at a total loss. Any ideas?

    ReplyDelete
    Replies
    1. Yes, please send me a screenshot - marklbgsu@gmail.com. Also a directory listing of /data/data might be helpful. I'll take a look and might have a couple more things for you to check out.

      Thanks,
      Mark

      Delete
  6. Hey Mark Lohrum. Now im doing my Final Year Project. And my project is relating to Android Imaging. Is there any possibility for me to Image the Android phone only using Flash Drive (USB OTG) itself? Only the smartphone and the Flash Drive through USB OTG.

    Thanks,
    Myka

    ReplyDelete
    Replies
    1. Myka,

      I am unfamiliar with USB OTG protocols so I would not know where to begin. But it sounds like an innovative topic!.Good luck and if you get something to work, publish it!

      Thanks,
      Mark

      Delete
    2. Thanks for the reply, Mark.

      I write the command in my terminal apps from my phone:
      dd if=/dev/block/mmcblk0 of=/storage/usbdisk.img bs=4096

      and it works!
      (Im newbie, and of course im proud for this small thing ;) )

      Im really hope that you can help me to prepare a script that will run this command automatically once i insert the flash drive to my phone.

      Thanks,
      Myka

      Delete
    3. Good stuff Myka! Best of luck getting the automating down!

      Delete
  7. I want to bump this up and thank you for the solid article. I also wanted to mention when taking a physical image of an Android filesystem that lives on flash storage that is soldered in(.DD or RAW) on a running device; there are times where the disk partition might not be recognized when you try to look at the filesystem structure metadata with FDISK or a forensic tool like Sluethkit's MMLS. This is sometimes due to the way the OS lives on disk (mmcblk0 - mmcblk(??) and how the image copy doesn't have a correct partition header. I've had success with testdisk and rebuilding the EFI GPT partition. If someone runs into this problem, I'm hoping this helps.

    ReplyDelete
    Replies
    1. Thanks for the comment Jared! You are right on, there are some difficult devices out there. I wrote this post as a "generic" guide that works on most of the common devices. There are some difficult devices out there that need more specific instructions - I've seen some bizarre configurations. With those devices I handle them case-by-case. This is a frustration because Android is not like iOS - there is no one-size-fits-all because of the diversity of devices out there. But these challenges keep us all busy, right?

      Delete
  8. Current Android devices have locked bootloader.
    The question : Is it necessary to unlock the bootloader first before proceed to Rooting process?

    ReplyDelete
    Replies
    1. Myka,
      It depends. If you can root the device with TowelRoot or something similar, no need to unlock the bootloader.
      Note: depending upon the device, unlocking the bootloader may wipe out all user data. Research the device before unlocking.

      Good luck,
      Mark

      Delete
  9. Thanks Mark.
    Some other site, they put "bs" after the filename. For example:

    dd if=/dev/block/mmcblk0 of=/storage/usbdisk/device_image.dd bs=4096

    Is this make any difference?

    ReplyDelete
    Replies
    1. That is for specifying the block size. In some cases you may want to specify but for what we're doing the default block size is fine.

      Good question.

      Delete
  10. Hi I'm Anna,
    Im doing Mtech in Cyber Forensics & Security,my Project is related to android forensics.To image the full device i tried
    dd if=/dev/block/mmcblk0 of=/storage/extSdCard/device_image.dd bs=4096 bt its showing
    /dev/block/mmcblk0: cannot open for read: Permission denied..pls reply what to do..i have already rooted before using iRoot s/w.its urgent for me..someone pls do respond

    ReplyDelete
    Replies
    1. The error indicates you are not root. You may have rooted your device but you have to gain root privileges for your session before imaging.

      You rooted your device? Make sure you type su first to start a root shell. Then to test your root shell, type ls /data - if you get a permissions error, you are not working as a root user.

      Delete
    2. This comment has been removed by the author.

      Delete
  11. Firstly thanking you Sir for your reply for my previous query & now I had some dbts..i imaged my phone memory using dd tool directly into sd card and also over netcat nd then done adb pull to my workstation..nw i trying to analyze the dd image..tried with recoverjpeg tool and foremost ..its showing about 3.2 GB files restored in command prompt..bt not even jpg files are opening when we analyze the folder...so wht to do..is something regarding android or can u pls suggest a better tool for android image analyzing..

    ReplyDelete
    Replies
    1. Are you trying to recover deleted images? I'd give scalpel a run.

      Delete
    2. sir i want full artifacts including deleted & existing files,encrypted chats,voip call logs,linked accounts credentials ..whatever can be obtained..

      Delete
    3. Look through all sqlite databases of relevant apps, run scalpel for any file types you care about, and use Autopsy. It is a good suite and also free.

      Delete
    4. This comment has been removed by the author.

      Delete
  12. Can I use the dd command to dump the RAM of an android device?

    ReplyDelete
    Replies
    1. Great question. RAM imaging is tricky and very device dependent. Some kernels prefect RAM. You can try imaging any /dev block that looks like it could be RAM bit no saying if it will work. You can look into lime forensics if you are interested in learning more about RAM imaging. Lime is a kernel module that you have to compile for your phone, it is complicated, but I've had success with it before.

      Delete
    2. yup,I too tried with Lime to dump RAM in accordance with some useful videos..but its not working,can u please explain that since u had success & i have seen your blog really worthy for security students like myself..well very neatly explained..thank you sir

      Delete
    3. Lime is finicky to compile and you need the kernel source and build configurations. Depending upon the device you may or may not have those. I used Lime on a Nexus device with an Android build that I compiled from AOSP. This was a research project, not a device examination.
      If you're interested in Android research, I generally recommend sticking with the Nexus devices since you can compile Android and push to the device so easily.

      Delete
  13. I tried to pull the RAM using LiME.But Iam getting an error while giving the command 'make ARCH=arm CROSS_COMPILE=arm-eCross-eabi- modules_prepare'.The error is make: *** No rule to make target `modules_prepare'. Stop.

    ReplyDelete
    Replies
    1. I need some context to answer the question. Do you have the kernel source and the kernel build configuration?

      Delete
    2. I was following a video tutorial on LiME. I tried the command sudo ./adb pull /proc/config.gz. I didnt get the output. So I tried another alternative from a forum. I searched in the source code directory in kernel/arch/arm/configs, but with .defconfig extension and I renamed that directory, into .config and moved it in kernel directory.

      Delete
    3. So what you're running into is the intersection of LiME, a more theoretical research-oriented project, and the reality of commercial Android devices. The file you are trying to pull is the kernel build configurations. Most of the time, the OEM compiles the kernel to not include the build configurations. If you're trying to use LiME on an investigation of a device, it can be awfully finicky. If you are doing research, I'd suggest compiling Android from AOSP and pushing to a Nexus device or creating an AVD. In either way, you can get the build config. I know, it's a pain!

      Delete
  14. This comment has been removed by the author.

    ReplyDelete
  15. can you suggest any tool other than LiME for Android RAM acquisition & Analysis..I tried a lot with LiME but i got stuck with the above make command.

    ReplyDelete
    Replies
    1. If you are root you may be able to dd any block in /dev/ that looks like it could be RAM. All depends on the kernel. Some kernels hide the RAM blocks or disallow reads. RAM is frustrating.

      Delete
  16. thank you for your blog. its been very useful

    ReplyDelete
  17. I acquired the internal memory of my android phone using dd command.I tried to open the dump using autopsy tool. But I couldnt read some of the files of google chrome and firefox browsers as I think they were encrypted.Please suggest me a way to read those files.

    ReplyDelete
  18. This comment has been removed by the author.

    ReplyDelete
  19. Hi,
    We have acquired RAM image using LiME & trying to analyze with volatility framework.we have volatility & now created a profile for our Android kernel.Till that its working fine.But now we are stuck in the below command.Can some one please help

    'python vol.py --profile=LinuxGT_S7582ARM -f /root/Desktop/space/ram.lime linux_psaux'

    we are getting this o/p
    Volatility Foundation Volatility Framework 2.5
    Pid Uid Gid Arguments
    No suitable address space mapping found
    Tried to open image as:
    MachOAddressSpace: mac: need base
    LimeAddressSpace: lime: need base
    WindowsHiberFileSpace32: No base Address Space
    WindowsCrashDumpSpace64BitMap: No base Address Space
    WindowsCrashDumpSpace64: No base Address Space
    HPAKAddressSpace: No base Address Space
    VirtualBoxCoreDumpElf64: No base Address Space
    VMWareMetaAddressSpace: No base Address Space
    VMWareAddressSpace: No base Address Space
    QemuCoreDumpElf: No base Address Space
    WindowsCrashDumpSpace32: No base Address Space
    AMD64PagedMemory: No base Address Space
    IA32PagedMemoryPae: No base Address Space
    IA32PagedMemory: No base Address Space
    OSXPmemELF: No base Address Space
    MachOAddressSpace: MachO Header signature invalid
    MachOAddressSpace: MachO Header signature invalid
    LimeAddressSpace: Invalid Lime header signature
    WindowsHiberFileSpace32: PO_MEMORY_IMAGE is not available in profile
    WindowsCrashDumpSpace64BitMap: Header signature invalid
    WindowsCrashDumpSpace64: Header signature invalid
    HPAKAddressSpace: Invalid magic found
    VirtualBoxCoreDumpElf64: ELF Header signature invalid
    VMWareMetaAddressSpace: VMware metadata file is not available
    VMWareAddressSpace: Invalid VMware signature: 0xc0002588
    QemuCoreDumpElf: ELF Header signature invalid
    WindowsCrashDumpSpace32: Header signature invalid
    AMD64PagedMemory: Incompatible profile LinuxGT_S7582ARM selected
    IA32PagedMemoryPae: Failed valid Address Space check
    IA32PagedMemory: Failed valid Address Space check
    OSXPmemELF: ELF Header signature invalid
    FileAddressSpace: Must be first Address Space
    ArmAddressSpace: Failed valid Address Space check

    ReplyDelete
  20. Urgh I really want to give this a go, unfortunately I do not have Linux.

    ReplyDelete
    Replies
    1. Ha ha, I've come to realise about VM's since I wrote the above comment earlier today.

      Delete
    2. All I use is Linux! None of my computers run Windows.

      Delete
  21. A little help!

    I'm an Android Dev, so I have all the Android Tools, SDK, etc., installed in my Arch box. My device is showing up in adb devices, I can push and pull to and from it, etc., but it does not show up as a block device:

    [tfry@arch Downloads]$ adb devices
    List of devices attached
    0dd54a42 device

    [tfry@arch Downloads]$ lsblk
    NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
    sda 8:0 0 465.8G 0 disk
    ├─sda1 8:1 0 200M 0 part /boot
    └─sda2 8:2 0 465.6G 0 part
    └─MyStorage 254:0 0 465.6G 0 crypt
    ├─MyStorage-rootvol 254:1 0 50G 0 lvm /
    ├─MyStorage-varvol 254:2 0 12G 0 lvm /var
    └─MyStorage-homevol 254:3 0 403.6G 0 lvm /home
    sr0 11:0 1 620.7M 0 rom
    [tfry@arch Downloads]$ ls -hal /dev/block
    total 0
    drwxr-xr-x 2 root root 200 Jul 15 14:35 .
    drwxr-xr-x 21 root root 3.4K Jul 15 14:56 ..
    lrwxrwxrwx 1 root root 6 Jul 11 17:39 11:0 -> ../sr0
    lrwxrwxrwx 1 root root 7 Jul 14 14:29 254:0 -> ../dm-0
    lrwxrwxrwx 1 root root 7 Jul 14 14:29 254:1 -> ../dm-1
    lrwxrwxrwx 1 root root 7 Jul 14 14:29 254:2 -> ../dm-2
    lrwxrwxrwx 1 root root 7 Jul 14 14:29 254:3 -> ../dm-3
    lrwxrwxrwx 1 root root 6 Jul 7 18:57 8:0 -> ../sda
    lrwxrwxrwx 1 root root 7 Jul 7 18:57 8:1 -> ../sda1
    lrwxrwxrwx 1 root root 7 Jul 7 18:57 8:2 -> ../sda2
    [tfry@arch Downloads]$

    I've searched and searched the forums and cannot figure out why it might not be showing up... Can anyone point me in the right direction?

    Thanks in advance!

    ReplyDelete
    Replies
    1. In your adb shell, execute the mount command. What is the output?

      Delete
    2. First, is there some good way to publish a block of code in a Blogger comment? It wont take a "code" tag and four spaces (like Superuser) doesn't work either.

      The output is below, and I apologize for it being a mangled mess! Thanks for the help though... :-D

      [tfry@arch ~]$ adb shell
      shell@kltevzw:/ $ mount
      rootfs / rootfs ro,seclabel,relatime 0 0
      tmpfs /dev tmpfs rw,seclabel,nosuid,relatime,size=865588k,nr_inodes=128410,mode=755 0 0
      devpts /dev/pts devpts rw,seclabel,relatime,mode=600 0 0
      proc /proc proc rw,relatime 0 0
      sysfs /sys sysfs rw,seclabel,relatime 0 0
      selinuxfs /sys/fs/selinux selinuxfs rw,relatime 0 0
      debugfs /sys/kernel/debug debugfs rw,seclabel,relatime 0 0
      none /acct cgroup rw,relatime,cpuacct 0 0
      none /sys/fs/cgroup tmpfs rw,seclabel,relatime,size=865588k,nr_inodes=128410,mode=750,gid=1000 0 0
      tmpfs /mnt tmpfs rw,seclabel,relatime,size=865588k,nr_inodes=128410,mode=755,gid=1000 0 0
      tmpfs /mnt/secure tmpfs rw,seclabel,relatime,size=865588k,nr_inodes=128410,mode=700 0 0
      tmpfs /mnt/secure/asec tmpfs rw,seclabel,relatime,size=865588k,nr_inodes=128410,mode=700 0 0
      none /dev/cpuctl cgroup rw,relatime,cpu 0 0
      /dev/block/platform/msm_sdcc.1/by-name/apnhlos /firmware vfat ro,context=u:object_r:firmware_file:s0,relatime,uid=1000,gid=1000,fmask=0337,dmask=0227,codepage=cp437,iocharset=iso8859-1,shortname=lower,errors=remount-ro 0 0
      /dev/block/platform/msm_sdcc.1/by-name/modem /firmware-modem vfat ro,context=u:object_r:firmware_file:s0,relatime,uid=1000,gid=1000,fmask=0337,dmask=0227,codepage=cp437,iocharset=iso8859-1,shortname=lower,errors=remount-ro 0 0
      /dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,seclabel,relatime,data=ordered 0 0
      /dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4 rw,seclabel,nosuid,nodev,noatime,discard,journal_checksum,journal_async_commit,noauto_da_alloc,data=ordered 0 0
      /dev/block/platform/msm_sdcc.1/by-name/cache /cache ext4 rw,seclabel,nosuid,nodev,noatime,discard,journal_checksum,journal_async_commit,noauto_da_alloc,data=ordered 0 0
      /dev/block/platform/msm_sdcc.1/by-name/persist /persist ext4 rw,seclabel,nosuid,nodev,noatime,discard,journal_checksum,journal_async_commit,noauto_da_alloc,data=ordered 0 0
      /dev/block/platform/msm_sdcc.1/by-name/efs /efs ext4 rw,seclabel,nosuid,nodev,noatime,discard,journal_checksum,journal_async_commit,noauto_da_alloc,data=ordered 0 0
      /dev/block/platform/msm_sdcc.1/by-name/persdata /persdata/absolute ext4 rw,seclabel,nosuid,nodev,relatime,data=ordered 0 0
      /dev/block/platform/msm_sdcc.1/by-name/carrier /vzw ext4 rw,seclabel,nosuid,nodev,relatime,data=ordered 0 0
      tmpfs /storage tmpfs rw,seclabel,relatime,size=865588k,nr_inodes=128410,mode=755,gid=1000 0 0
      /data/knox/tmp_sdcard /mnt/knox sdcardfs rw,seclabel,nosuid,nodev,relatime,mask=0077 0 0
      /data/knox/sdcard /mnt/knox/default/knox-emulated sdcardfs rw,seclabel,nosuid,nodev,relatime,low_uid=1000,low_gid=1000,gid=9997,multi_user,mask=0006 0 0
      /data/knox/sdcard /mnt/knox/read/knox-emulated sdcardfs rw,seclabel,nosuid,nodev,relatime,low_uid=1000,low_gid=1000,gid=9997,multi_user,mask=0027 0 0
      /data/knox/sdcard /mnt/knox/write/knox-emulated sdcardfs rw,seclabel,nosuid,nodev,relatime,low_uid=1000,low_gid=1000,gid=9997,multi_user,mask=0007 0 0
      /data/knox/secure_fs/enc_media /mnt/shell/enc_media sdcardfs rw,seclabel,nosuid,nodev,relatime,low_uid=1000,low_gid=1000,gid=9997,multi_user,reserved=20MB 0 0

      Delete
    3. If you want to image the whole device, image /dev/block/mmcblk0. If you want just the userdata partition, image /dev/block/platform/msm_sdcc.1/by-name/userdata

      Delete
    4. OMG...thank you. Duh. I was looking for adb tools to have the phone show up in my linux box's /dev/block like fuser might.

      I totally missed the part of the sentence, "Next, IN THE SHELL TO YOUR PHONE, type the following..."

      Thanks for realigning my perspective! :-)

      Delete
  22. Hi can you help how i can search for emails deleted and undeleted on gmail please

    ReplyDelete
  23. Hi can you help how i can search for emails deleted and undeleted on gmail on Android nexus 7 please.

    ReplyDelete
    Replies
    1. E-mails are hard to recover. They are stored in a database so you would be looking at recovering a deleted database or strings of deleted messages. And in general not many full emails are cached.

      E-mail is a cloud service. Best shot is getting messages off the actual original server. If you are law enforcement and this is a case, you can get a court order to retrieve a suspect's messages.

      Delete
    2. Hi,for any search related with the email u need to get the datatabase emailprovider.db.I think u can use tools like Autopsy or Andriller for doing this Internal Memory Analysis.

      Delete
  24. Hi there. Nice post. Having trouble getting the device to root through. Running android 6.0.1 and towelroot states it does not support it. I've done a bit of further research to no avail. Thanks.

    ReplyDelete
  25. Hi there. Nice post. Having trouble getting the device to root through. Running android 6.0.1 and towelroot states it does not support it. I've done a bit of further research to no avail. Thanks.

    ReplyDelete
    Replies
    1. Too new for towel root. Lots has happened in the world since I put up this page. I'm watching Dirty Cow - it may work out to be the new towel root. Dirty Cow cannot currently obtain root but with modifications it may. Will make a post if I get it up and running

      Delete
  26. Hi, this blog is really illuminating.
    I am trying to image a vernee thor phone.
    I dont really have idea which the main block is or how to find out that.
    So, any help? I will post the list with the blocks in a short while if necessary.
    Regards

    ReplyDelete
    Replies
    1. actualy I have made the image it was exactly the same block as the one in the example :)
      I want to say that this blog is the best sofar and I have red through first 4-5 pages of google search on android forensics...
      Thank you!

      Delete
  27. Hi, I have found this blog very interesting. I want to image an Android device. I will try your method this afternoon, but reading it I have a question.
    How can I get a hash of the device in order to compare it with obtained file so I can demonstrate the image is exactly as original evidence.


    Best regards

    ReplyDelete
    Replies
    1. This is live imaging so the device may change some during imaging - your hash may be different. But if you want, busybox has md5 functionality. Use that against the block you are imaging.

      Delete
    2. What is the command to use busybox functionality

      Delete
    3. busybox md5sum /dev/block/whatever_you_are_hashing
      Note, it appears not all versions of busybox have md5sum. I have it on two different devices - one has it, the other doesn't. Need to be root to get the hash of a /dev/block

      Delete
  28. This comment has been removed by a blog administrator.

    ReplyDelete
  29. adb shell
    error:closed

    stock locked (everything...go ahead ask NO THAT'S LOCKED but what about NO LOCKED!) and 2 smoking barrels Nexus 4 w/pin and "CM SECURITY"
    -if I had the pin...if I only could get to the pin
    -can't load zips or apks
    -recovery - choose "apply update from adb" then adb devices sees it
    -times out after 5 minutes
    -yes, there's a huge long ugly story behind this
    Even a frakkin' IMAGE of the thing I could pick at would be fine

    ReplyDelete
    Replies
    1. So the Nexus 4 has locked bootloader, is pin locked and you don't know the pin, and adb is not enabled? At that point this tutorial is not going to work. You might want to consider some commercial solutions.

      Delete
  30. Hi Mark, thanks for the solid write up. I've factory reset my Samsung Galaxy A7 (model no.: SM-A720F/DS). There are some photos in the internal memory which I never do any backup. Is this method going to work in my case? Also, there is a pre-installed Apps called Knox. I was told that the apps is able to detect rooted phone. Do I need to disable it before rooting my phone? Thanks in advance.

    ReplyDelete
  31. How do i calculate hash value while executing dd command

    ReplyDelete
    Replies
    1. busybox md5sum /dev/block/whatever_you_are_hashing
      Note, it appears not all versions of busybox have md5sum. I have it on two different devices - one has it, the other doesn't. Need to be root to get the hash of a /dev/block

      Delete
    2. Thanks it worked... I also wanted to know whether we can use write blocker while creating image so as to block write access. If so what would be command for that

      Delete
    3. There's no write blocking. If you hook the phone up to a write blocker, adb commands won't work. Live imaging is inherently different from dead imaging like a hard drive hooked up to a write blocker.
      My first real lab in my first digital forensics class was imaging a hard drive. Write blocker, md5 hashes, all that fun stuff. So it was quite a leap to live image a phone instead.
      The best equivalent to the hard drive imaging is to perform a chipoff and read the chip like a drive via a reader. And that all requires a lot of experience, expensive equipment, and if it doesn't work you've got no turning back.
      I hope that all makes sense!

      Delete
    4. Ohk got it thanks for the help. I have created image but not entire image of motoG3 device the data in it I could recover with foremost but autopsy tool is not displaying any data

      Delete
    5. You might need to image userdata separately. http://freeandroidforensics.blogspot.com/2017/05/a-quick-note-on-imaging-newer-android.html

      Delete
    6. This comment has been removed by the author.

      Delete
  32. This comment has been removed by the author.

    ReplyDelete
  33. I have made entire image of my mobile in autopsy the dd file is scanned bt in image log it is showing"errors occurred while ingesting image
    1.Cannot determine filesystem type(Sector:81920, Partiton type:sbl1) 2.Cannot determine filesystem type(Sector:8320, Partiton type:DDR)"

    ReplyDelete
    Replies
    1. Run the mount command and email me the results

      Delete
    2. Autopsy tool has recovered my multimedia & office files successfully but I am not able to search com.android.providers.telephony file where can I search for that in autopsy

      Delete
    3. Is there any way to extract database file(.db) from dd image

      Delete
    4. I wrote an entire post about it. http://freeandroidforensics.blogspot.com/2015/01/viewing-sqlite-databases.html

      Delete
  34. Hello,

    I have a rooted HTC 10 running Android 7.0 with busybox and supersu and I imaged my device in a couple of ways (one being the excellent tutorial "Using Windows to Live Image an Android device") but when ran through Autopsy, FTK Imager, Scalpel, or TestDisk it yields zero results.

    I have imaged the entire device with mmcblk0 as a DD file, as well as what I assume is the userdata partition(?) dm-0 as a DD file. The internal memory is 23.7 GB with 10.9 GB currently being used, however the entire device image I get from it is consistently 58.7 GB, and the dm-0 was something like 40+ GB (maybe almost 50 GB? I have limited hard drive space to work with so I have already deleted it, apologize).

    Autopsy gives me the error "Errors occurred while ingesting image 1. Cannot determine file system type (Sector offset: 0)", FTK Imager tells me the dd file is not valid evidence and it could not find a valid image, Scalpel doesn't find any of the file types I'm looking for, and testdisk doesn't find any partitions.

    Autopsy CAN, however, open the mmcblk0 DD file as a logical file or unallocated space image file, where it has 3851538 pages I can view in hex or strings.

    ...So for some reason unbeknownst to me, my image files cannot be detected as such. The DD files seem to have been created correctly, is it a device system compatibility thing? Something with it being Android 7.0? I just don't get it. My endgame with this project is to see if videos, images, and text messages deleted off of my phone are retrievable BTW. The most important are the text messages (text message rough drafts to be specific, I'm not sure where those are allocated to in the memory but I will cross that bridge when I come to it), then the videos, and the least important would be the images/photos.

    ReplyDelete
    Replies
    1. You might need to image your userdata separately. Check out this post... http://freeandroidforensics.blogspot.com/2017/05/a-quick-note-on-imaging-newer-android.html

      Delete
  35. hi mark lohrum

    I want to ask, why when I do live imaging on my mobile get a data transfer speed of 2.7MB / s?

    is there a way to increase the speed of data transfer during the imaging process?

    I want to know what can affect the speed of data transfer during the imaging process?

    ReplyDelete
    Replies
    1. Not really unless you just want a file system pull ... http://freeandroidforensics.blogspot.com/2018/04/obtaining-all-files-in-data-partition.html

      Delete
  36. Hi Mark Lohrum,
    I have to recover some deleted files of an app from Samsung tablet.
    I want to know if I have to image the whole tablet for that.

    Thanks in advance.

    ReplyDelete
    Replies
    1. Recovering deleted files takes a physical image. But you should probably first read over this one: http://freeandroidforensics.blogspot.com/2017/05/a-quick-note-on-imaging-newer-android.html

      Also in the years since I wrote this post, recovering deleted files has become much harder between encryption and some devices handling deletion better.

      Delete
  37. First thing, Thank you for all the great information Mark,
    I hope you still check these comments lol.
    I am in the middle of trying to create an image of a samsung s6 edge that has a password enabled on it and does not currently have developer mode enabled. So i am stuck on being able to use adp on the device. Any advice on what i could do?

    ReplyDelete
  38. This post is so helfull and inforamtive .keep updating more information...
    Android Training Course
    Scope Of Android

    ReplyDelete

  39. Spy Camera India - Offering smart sourcing tools for buyers to find China Products, Manufacturers & Suppliers. Mobile Network Blocker - Find Quality Manufacturers, Products & Suppliers.

    ReplyDelete
  40. Live Imaging An Android Device >>>>> Download Now

    >>>>> Download Full

    Live Imaging An Android Device >>>>> Download LINK

    >>>>> Download Now

    Live Imaging An Android Device >>>>> Download Full

    >>>>> Download LINK zB

    ReplyDelete

  41. The blog on live imaging an Android device is a pivotal guide for digital forensics professionals and enthusiasts. It skillfully navigates through the intricacies of capturing real-time images of Android devices, shedding light on crucial methods and tools. https://www.mobilezmarket.com/

    ReplyDelete