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
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.

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 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.

71 comments:

  1. This comment has been removed by the author.

    ReplyDelete
  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
  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