One Way to Use a Linux Computer to Recover Files from an Android Device

Sometimes you accidentally delete files on your mobile phone and need to run recovery software. With USB Mass Storage in the older devices, one could simply attach the device (or the memory card) to a computer and run some data recovery tool to fix things. With modern Android phones there is no USB Mass Storage anymore, and with an internal memory only-device things get somewhat more complicated. Still, not impossible.

Perhaps you have already read various very good guides on this. I have. But the ones I have seen use Windows, while I prefer to do things directly in my Linux environment without having to start my virtual machine with Windows. In order for myself to remember how to do this the next time I need to, I have created this web page. Perhaps it can be useful for someone else too, so I put it on the WWW for everyone to read.

Now, this is one way to do this kind of recovery. There are other ones as well, but this is the one I used.

NB! This guide was based on recovery on an Android 4.0 device. I grew tired of always having to do things like this now and then using Android, and ditched Android shortly after this web page was made and went for iOS instead. iOS and its ecosystem have many flaws, but none of them annoy me. Android annoys me. I never had to root my iPhone in order to make things happen. I never had to do recovery stuff like this on the iPhones I've had. While Android has seen many improvements since 4.0, I had to do some maintenance on a device with Android 5.0 and 6.0 a while ago and realized all things that annoy me with Android were still the same.

The Overall Plan

The plan is to use adb to dump out the entire file system to the computer. Then we can run recovery tools on those dumps and recover our files. Typically, the data partition (mounted as SD Card) is a FAT32 system. Other partitions are probably ext3. We will find out and use different recovery tools accordingly.


The programs in the last bullet are probably included in your Linux distribution. If you use Debian, just run

# apt-get install testdisk pv extundelete


  1. Activate USB Debug on your device (in order to connect with adb)

  2. Attach your device to the computer via the USB cable

  3. Open a terminal on your computer, go to the Android SDK directory's subdirectory sdk/platform-tools (where adb is located)

  4. Log in to your phone with adb shell:
    $ ./adb shell
    (NB: You might have to implicitly call adb start-server as root first if the command above fails.)

  5. Now we can either use the mount command to find out what partition holds the SD Card data and dump that one, or we just dump out the entire memory content and skip the thinking part. I find the latter preferable, since the thinking part involved in the first approach is always prone to fail. So then you want to search for a block device called something like /dev/block/mmcblk0:
    shell@android:/ # ls /dev/block
    shell@android:/ # 
    Here we see that there are several partitions within mmcblk0, but we leave it for TestDisk to take care of the partitions later.

  6. Exit the shell to go back to the Android SDK directory's subdirectory sdk/platform-tools on your computer.

  7. Now let us dump the content of that /dev/block/mmcblk0 that we found to the computer. With adb shell we can become superuser and execute cat to dump the content like this:
    $ ./adb shell su -c "cat /dev/block/mmcblk0" | pv > mmcblk0.raw
    Pipe Viwer (pv) is optional, but I like to see the transfer progress information it provides.
    (And of course you can change mmcblk0.raw to some other directory/filename if you want to.)

    Addition: André Paixão wrote to me that he just got an empty file with the command above. He solved it by using adbd insecure.

    Addition: Daniel Jeliński wrote to me that he ran into issues with LF encoding. The solution that worked for him was:
    ./adb shell su -c "cat /dev/block/mmcblk0" | pv | sed 's/^M$//' > mmcblk0.raw
    ...where ^M is what you get by pressing Ctrl+V followed by Ctrl+M.

    Addition: Marc also ran into the LF problems, but solved it this way:
    ./adb shell "su -c 'stty raw; cat /dev/block/mmcblk0'" | pv > mmcblk0.raw
    Addition: Tim de Waal wrote to me that he prefers using netcat/gzip instead:

    On the Android device (adb shell with su), run:
    dd if=/dev/block/mmcblk0 | gzip -9 | nc -l 5555
    On the computer, run:
    nc [AndroidIP] 5555 | pv -b > mmcblk0.img.gz
  8. Now wait until the transfer is done. For a 8 GB device it does not take too long, but still there is time to check some e-mails and browse the web while it finishes.

  9. With the dump on the Linux machine's file system, now we can let TestDisk take it from there:
    $ testdisk mmcblk0.raw
  10. First restore the GPT partition table. Select mmcblk0.raw in the TestDisk interface and choose Proceed:

    Choose EFI GPT partition map:

    Then select Analyse in order for TestDisk to find the partitions:

    Choose Quick Search:

    Hopefully the search will return a nice table like this:

    Then just press enter to continue.

    Select Write to write this new(ly recovered) partition table. Then confirm with Y:

    You will then be informed that you need to reboot. But in our case there is no need for that. Just press enter to continue:

    Now the partition table is restored, and we can go on and try to recover the files.

  11. Select Advanced to use TestDisk's Filesystem Utils section:


    Select the partition where you want to do the recovery. In this example, we want to recover photos from the FAT32 SD Card partition with the Undelete option:

    Now we can browse the filesystem for files that can be recovered:

    In the /DCIM/100ANDRO directory, where my Android device stores its camera images, we find a lot of files that can be recovered. Select all or some of them, and use either C or c to recover them to one of the Linux computer's file systems (e.g. your home directory):

  12. Done!


Hopefully this will help me in the future, when I have forgotten the steps. And perhaps someone else can benefit from this information as well.
Please feel free to e-mail me if you have positive comments or concrete suggestions of changes or updates.


Thank you very much Mathias Brodala, Piotr Biesiada, André Paixão, Marc, Daniel Jeliński and Tim de Waal for sharing your valuable update suggestions and corrections.