Is there easier way to have access to internal card and recover files? This tutorial makes things complicated, maybe today is easier?
[GUIDE] Internal Memory Data Recovery - Yes We Can!
- Thread starter Wartickler
- Start date
STEPS - Recovering Deleted Data from an Android Device (using a Windows PC)
In case anyone finds this useful, here are some detailed steps for an Android device data recovery method we've used at our shop for quite a while. The first part (imaging) is extremely similar to Wartickler's excellent guide in this current thread, and the last part (recovery using the image) is more oriented to a Testdisk/Photorec recovery approach.
I thought I'd post our procedure here, for the benefit of people looking for more info on individual steps, or who are running into issues with other methods. Hope this helps someone!
---------------------------------------------------------------------
STEPS - Recovering Deleted Data from an Android Device (using a Windows PC)
Scenario: The Android device is still bootable/functional, but files have been lost or deleted from its internal memory.
FIRST, PRECAUTIONS AND BACKUP!
• First, disable phone/Wifi on the device (or just put it into flight mode), and take out the SIM. You don't want the system or apps being able to download updates or write anything else to the unallocated space.
• Make a full backup of everything still on the device (contacts, photos, texts, etc). This won't back up anything already deleted, but it'll make sure you don't lose the rest, in case something goes wrong during the recovery process. DO NOT SKIP THIS, unless you seriously don't care about anything left on the device.
Then, prepare for recovery:
• First, in the device options, enable Developer Mode and then turn on USB debugging on the device. This is required for the next stages of recovery. If you're not sure how to enable USB Debugging, google your device model number + "usb debugging" for instructions.
• Note down the IMEI, serial number, and model/product number of the device. You can obtain this info either in Settings -> About Device, or on a sticker inside the battery compartment. Write them down. (As well as for your jobnotes, you may need this info for recovery later.)
STAGE 1 ANALYSIS - Consumer level software.
• In many cases it's worth looking at it with a quick and easy consumer level software first, as long as it's reputable. This may bring back what the person wants straight away, without getting too complicated or time consuming.
• If that doesn't work (e.g. the device won't connect, isn't detected by the software, can't find the correct deleted files, wants you to reflash the firmware to proceed further, etc), move on to next level recovery first to get a forensic image before risking anything. DON'T try to root or reflash the device through the consumer software - only try the simple non-invasive options. If something goes wrong and you manage to accidentally brick the device with consumer software before you've got your forensic image, any hope of a successful data recovery is probably toast.
STAGE 2 ANALYSIS - Forensic imaging of the device memory.
Get the device ready:
• Ensure that USB debugging is enabled on the device, and that you've already done a backup of anything valuable which is still left on the device (contacts etc).
• Root the Android device, if it isn't rooted already. You can use something like Kingo Root (https://www.kingoapp.com/ ) or a reputable rooting utility of your preference.
• On the device, go to the Play Store and install BusyBox by Stephen Stericson (https://play.google.com/store/apps/details?id=stericson.busybox).
Get your PC ready:
• On your computer, install Cygwin 32-bit version (https://cygwin.com/install.html) to c:\cygwin. Don't install the 64 bit version, as it sometimes results in problems later such as 0-byte image files). When it prompts for extra packages, install these two:
• Install ADB (the Android Debug Bridge tool).
Create the forensic image:
• In most cases we want to go after the entire device memory block "/dev/block/mmcblk0", to make sure we get absolutely everything on all partitions (not only the userdata partition). In this case, the instructions below are to capture the whole block (with all partitions), as a RAW image file, into the "C:\Cygwin\image" directory.
• Connect the device to the computer via USB cable, and unlock the screen. Watch the screen for the "Allow USB Debugging?" prompt and make sure you check "Always allow from this computer" before tapping OK.
• On the PC, open a Cygwin Terminal and enter the following commands:
• At this point, the device screen may prompt for SuperSu permission - allow if so. Then enter the next command (assuming BusyBox is installed at /system/xbin/busybox):
• Open a second Cygwin Terminal window, and enter the following commands:
• NOTE: If you get any errors on any of these lines, odds are you either haven't connected the device properly, or haven't installed the required tools properly, or you haven't entered the PATH environment variable properly, or you forgot to run BusyBox on the device after installing, or you didn't give root permission on the device when prompted, or there is some other incompatibility on your particular system. Go back, re-check everything, try installing the tools again, install a different version of them if available (e.g. netcat, pv, adb etc), try a different USB port, try a different computer, etc.
• Leave both Cygwin terminal windows running. Once the imaging process has started, it'll take ages to finish, usually 1-4 hours. Once it's done, you have yourself a complete RAW image saved in c:\Cygwin\image\. Your image file should end up with a size close to or equal to the whole device capacity (e.g. 14.7GB for an advertised 16GB device).
• The finished output in the first Cygwin terminal should look something like:
• Once the image is done, you're finished with the Android device now - you can disconnect it from the computer and turn it off.
Mount the forensic image on the computer for analysis:
• Now, we need to convert the image file from RAW to a virtual hard drive that Windows will recognise. We do this by using VHDTool to put a VHD footer onto the end of the .RAW file, and then rename the file extension to VHD (which avoids mount point errors in some Windows versions).
• Open a Windows administrative command prompt, and enter these commands:
• Now we can mount the converted image in Windows Disk Management:
• From here, you can now proceed to use your favorite forensic data recovery processes/software on the mounted image.
• NOTE - we have not assigned any drive letters or tried to format it at this stage. We recommend using the free TestDisk and/or Photorec tools, which don't require that you interfere with the image by quick-formatting it or assigning a drive letter first, and are extremely thorough for recovery. (This is why we don't really recommend Recuva, although Recuva is certainly easier to use. If you've made it this far though, you can probably easily handle a more advanced program like TestDisk).
Testdisk Data Recovery - if you know your own way around TestDisk already, just go for it! If not, here is one procedure you can follow for an Android recovery analysis (mileage will vary):
• Download TestDisk and PhotoRec from http://www.cgsecurity.org/wiki/TestDisk_Download and unzip somewhere on your computer.
• Right click Testdisk (testdisk_win.exe) and choose "Run as Administrator" to start. Remember input is keyboard only (no mouse). ALWAYS carefully look at the menu of keyboard options down the bottom of the screen, as they change for each page. (They are also CASE SENSITIVE - "C" and "c" are different!)
• Choose No Log and press Enter. TestDisk will bring up a list of all disks it can see attached to your computer.
• Select the freshly mounted VHD from your list of disks, and choose Proceed. The VHD will look something like this:
• Select EFI/GPT as the partition table type.
• Choose "Analyse". You should see a list of partitions, including one named [userdata] at the end if you arrow down, which will look something like:
• Move the selection to the [userdata] partition and check the bottom list of options to see if it gives you a "P: List Files" option for that partition.
• If yes, type a capital P, and you should see a list of files/folders inside.
• If not:
• TestDisk will then jump over to its own parent folder (it wants to know where to save the recovered data to). You can save the recovered data directly in TestDisk's parent folder if you like, or if you want to put it somewhere else, you can. In Windows Explorer, create yourself a new folder called "Recovered-TestDisk" under C drive, and then back in TestDisk, use the arrow/Enter keys to navigate to it (see the keyboard navigation options at the bottom). When you're in the right place, press capital C again, and TestDisk will copy your file(s) there.
• TestDisk will report "Copy done!" in green text when finished. You can then continue finding and copying more files until you're done.
• When finished, quit TestDisk properly by hitting 'q' until TestDisk exits (instead of just closing the window).
• Open your "C:\Recovered-TestDisk" folder in Windows Explorer and check out your recovered files.
Photorec Data Recovery - if TestDisk didn't work for you, or if you just want to try another method anyway (it's definitely worth a go), try Photorec too. Photorec ignores filesystems and folder structures, and blindly rips everything that looks vaguely like a useful file out of raw memory. It's excellent for last ditch data recovery (all kinds, not just photos, despite its name). Folder locations and filenames are not recovered, only the files themselves, but often that's all you need.
• From the same folder as Testdisk: right click Photorec (photorec_win.exe) and choose "Run as Administrator" to start. Same principles with keyboard navigation etc apply.
• Select the VHD from your list of disks, and choose Proceed. The VHD will look something like this:
• A list of partitions will appear. Arrow down to the [userdata] partition.
• OPTIONAL: At this point, if you want to limit the types of files that Photorec is looking for (for example if you're only after photos or music files etc), you can tell Photorec to ignore everything else, by selecting only certain file types under "File Opt" at the bottom. Otherwise, it will attempt to recover everything it finds.
• With the [userdata] partition selected, check that "Search" is selected at the bottom, and press Enter.
• Select "Other" as the filesystem type.
• Photorec then jumps straight over to its own parent folder (like Testdisk, it's asking you to know where to save the recovered data to). In Windows Explorer, create a new "C:\Recovered-Photorec" folder, then in Photorec, navigate to it. When you're there, press capital C, and Photorec will start the recovery to that folder.
• Recovery may take a while, so be patient. When it's finished, Photorec will report "Recovery completed".
• When finished, quit Photorec properly by hitting 'q' until Photorec exits (instead of just closing the window).
• Check your "C:\Recovered-Photorec" folder in Windows Explorer to see what it managed to get back. You'll see a bunch of recup_dir folders with random file contents. Hopefully your lost files will be in there somewhere. Remember the original filenames will be gone, so you're relying on file extensions and thumbnails to identify what they are.
• If there are too many files to sort out manually, you can:
When you're finished with everything, remember to cleanly unmount the VHD image in Disk Management, by right-clicking the disk name to the left and choosing "Detach VHD". Store a copy of the VHD image file in a safe place, in case you ever want to re-mount it again for further recovery attempts.
Good luck!
In case anyone finds this useful, here are some detailed steps for an Android device data recovery method we've used at our shop for quite a while. The first part (imaging) is extremely similar to Wartickler's excellent guide in this current thread, and the last part (recovery using the image) is more oriented to a Testdisk/Photorec recovery approach.
I thought I'd post our procedure here, for the benefit of people looking for more info on individual steps, or who are running into issues with other methods. Hope this helps someone!
---------------------------------------------------------------------
STEPS - Recovering Deleted Data from an Android Device (using a Windows PC)
Scenario: The Android device is still bootable/functional, but files have been lost or deleted from its internal memory.
FIRST, PRECAUTIONS AND BACKUP!
• First, disable phone/Wifi on the device (or just put it into flight mode), and take out the SIM. You don't want the system or apps being able to download updates or write anything else to the unallocated space.
• Make a full backup of everything still on the device (contacts, photos, texts, etc). This won't back up anything already deleted, but it'll make sure you don't lose the rest, in case something goes wrong during the recovery process. DO NOT SKIP THIS, unless you seriously don't care about anything left on the device.
• For Samsungs, you can use the Samsung Kies or Kies3 software to do the backup.
• For other devices, search for the manufacturer's native backup app, or use a reputable third party one.
• If you're not going to be attempting the actual recovery for a while, turn the device off in the meantime. • For other devices, search for the manufacturer's native backup app, or use a reputable third party one.
• NOTE: On a lot of modern Android devices, e.g. devices running Android v4.3 and later, TRIM support is enabled on the userdata partition. The means that TRIM functions will run periodically in the background to "clean up" the device memory, zero-filling any unallocated space. For device operating efficiency this is excellent, but for data recovery, it can be a disaster. As far as we've been able to tell, if the device detects that it has been left idle for an hour or so, TRIM functions may kick in. YOU DO NOT WANT THIS TO HAPPEN! Unfortunately though, it's often already happened before the device reaches us, which limits what we can get back. (Recovery is still worth trying though.) If there's a chance that TRIM hasn't affected the device yet, try to avoid it kicking in while you're working on it, by making sure the device is not left idle for too long and that it's kept turned off when you're not using it.
Then, prepare for recovery:
• First, in the device options, enable Developer Mode and then turn on USB debugging on the device. This is required for the next stages of recovery. If you're not sure how to enable USB Debugging, google your device model number + "usb debugging" for instructions.
• Note down the IMEI, serial number, and model/product number of the device. You can obtain this info either in Settings -> About Device, or on a sticker inside the battery compartment. Write them down. (As well as for your jobnotes, you may need this info for recovery later.)
STAGE 1 ANALYSIS - Consumer level software.
• In many cases it's worth looking at it with a quick and easy consumer level software first, as long as it's reputable. This may bring back what the person wants straight away, without getting too complicated or time consuming.
• If that doesn't work (e.g. the device won't connect, isn't detected by the software, can't find the correct deleted files, wants you to reflash the firmware to proceed further, etc), move on to next level recovery first to get a forensic image before risking anything. DON'T try to root or reflash the device through the consumer software - only try the simple non-invasive options. If something goes wrong and you manage to accidentally brick the device with consumer software before you've got your forensic image, any hope of a successful data recovery is probably toast.
STAGE 2 ANALYSIS - Forensic imaging of the device memory.
Get the device ready:
• Ensure that USB debugging is enabled on the device, and that you've already done a backup of anything valuable which is still left on the device (contacts etc).
• Root the Android device, if it isn't rooted already. You can use something like Kingo Root (https://www.kingoapp.com/ ) or a reputable rooting utility of your preference.
• On the device, go to the Play Store and install BusyBox by Stephen Stericson (https://play.google.com/store/apps/details?id=stericson.busybox).
• If the device has an SD card, see if you install BusyBox to that, instead of writing to the internal device memory. (If not, too bad, you'll have to install BusyBox to the internal memory and hope it doesn't overwrite anything important).
• After installing BusyBox, don't forget to run it, and go through the prompts onscreen. This gives it root access and creates the correct directory structure on the device.
• At the top of the screen it will display the location of the installation, e.g. /system/xbin/busybox or /system/bin/busybox. Take note of this.
• After installing BusyBox, don't forget to run it, and go through the prompts onscreen. This gives it root access and creates the correct directory structure on the device.
• At the top of the screen it will display the location of the installation, e.g. /system/xbin/busybox or /system/bin/busybox. Take note of this.
Get your PC ready:
• On your computer, install Cygwin 32-bit version (https://cygwin.com/install.html) to c:\cygwin. Don't install the 64 bit version, as it sometimes results in problems later such as 0-byte image files). When it prompts for extra packages, install these two:
• PV
• util-linux
• Download Netcat in zip file (http://www.daemon.de/Netcat). Extract the "nc.exe" file from the zip, and put it into c:\cygwin\bin.• util-linux
• Install ADB (the Android Debug Bridge tool).
• OPTION 1 - Either install the full Android SDK Tools which includes ADB but is very large, 90MB+ (https://developer.android.com/studio)
• OPTION 2 - Or alternatively, just try installing the small 2MB "Minimal ADB and Fastboot Tool" instead (http://xdaforums.com/showthread.php?t=2317790)
• Then whichever one you install, add the folder location path of "adb.exe" in to the Windows "PATH" environment variable (Control Panel -> System -> Advanced System Settings -> Advanced tab -> Environment Variables -> System Variables -> select PATH -> Edit -> New). Copy and paste the folder location of your adb.exe from the installation above in there, e.g. "C:\android-sdk\platform-tools" or "C:\Program Files (x86)\Minimal ADB and Fastboot", and save. Now you can run adb.exe via command line from anywhere. You can test that it works by running this command from a CMD prompt: adb devices
• Download Microsoft VHDTool.exe. Create a new folder "C:\cygwin\image" and put VHDTool.exe there. (The original MS download link http://archive.msdn.microsoft.com/vhdtool appears to be dead, but it's still available from http://www.techieshelp.com/downloads/VhdTool.exe).• OPTION 2 - Or alternatively, just try installing the small 2MB "Minimal ADB and Fastboot Tool" instead (http://xdaforums.com/showthread.php?t=2317790)
• Then whichever one you install, add the folder location path of "adb.exe" in to the Windows "PATH" environment variable (Control Panel -> System -> Advanced System Settings -> Advanced tab -> Environment Variables -> System Variables -> select PATH -> Edit -> New). Copy and paste the folder location of your adb.exe from the installation above in there, e.g. "C:\android-sdk\platform-tools" or "C:\Program Files (x86)\Minimal ADB and Fastboot", and save. Now you can run adb.exe via command line from anywhere. You can test that it works by running this command from a CMD prompt: adb devices
Create the forensic image:
• In most cases we want to go after the entire device memory block "/dev/block/mmcblk0", to make sure we get absolutely everything on all partitions (not only the userdata partition). In this case, the instructions below are to capture the whole block (with all partitions), as a RAW image file, into the "C:\Cygwin\image" directory.
• Connect the device to the computer via USB cable, and unlock the screen. Watch the screen for the "Allow USB Debugging?" prompt and make sure you check "Always allow from this computer" before tapping OK.
• On the PC, open a Cygwin Terminal and enter the following commands:
Code:
adb forward tcp:5555 tcp:5555
adb shell
su
Code:
/system/xbin/busybox nc -l -p 5555 -e /system/xbin/busybox dd if=/dev/block/mmcblk0
Code:
adb forward tcp:5555 tcp:5555
cd /image
nc 127.0.0.1 5555 | pv -i 0.5 > mmcblk0.raw• Leave both Cygwin terminal windows running. Once the imaging process has started, it'll take ages to finish, usually 1-4 hours. Once it's done, you have yourself a complete RAW image saved in c:\Cygwin\image\. Your image file should end up with a size close to or equal to the whole device capacity (e.g. 14.7GB for an advertised 16GB device).
• The finished output in the first Cygwin terminal should look something like:
Code:
root@klte:/ # /system/xbin/busybox nc -l -p 5555 -e /system/xbin/busybox dd if=/dev/block/mmcblk0
55 -e /system/xbin/busybox dd if=/dev/block/mmcblk0
30777344+0 records in
30777344+0 records out
15758000128 bytes (14.7GB) copied, 4092.340537 seconds, 3.7MB/sMount the forensic image on the computer for analysis:
• Now, we need to convert the image file from RAW to a virtual hard drive that Windows will recognise. We do this by using VHDTool to put a VHD footer onto the end of the .RAW file, and then rename the file extension to VHD (which avoids mount point errors in some Windows versions).
• Open a Windows administrative command prompt, and enter these commands:
Code:
cd c:\cygwin\image
copy mmcblk0.raw mmcblk0-backup.raw
VhdTool.exe /convert mmcblk0.raw
ren mmcblk0.raw mmcblk0.vhd• Open Disk Management
• Click Action -> Attach VHD
• Enter the VHD image file location: c:\cygwin\image\mmcblk0.vhd
• Tick "Read Only"
• Click OK
• The drive should now be mounted as read-only in Disk Management, and will show multiple partitions inside (seeing as we captured the whole block, not just the single UserData partition). The UserData partition should be the largest one displayed (probably around 11GB on a 16GB device).• Click Action -> Attach VHD
• Enter the VHD image file location: c:\cygwin\image\mmcblk0.vhd
• Tick "Read Only"
• Click OK
• From here, you can now proceed to use your favorite forensic data recovery processes/software on the mounted image.
• NOTE - we have not assigned any drive letters or tried to format it at this stage. We recommend using the free TestDisk and/or Photorec tools, which don't require that you interfere with the image by quick-formatting it or assigning a drive letter first, and are extremely thorough for recovery. (This is why we don't really recommend Recuva, although Recuva is certainly easier to use. If you've made it this far though, you can probably easily handle a more advanced program like TestDisk).
Testdisk Data Recovery - if you know your own way around TestDisk already, just go for it! If not, here is one procedure you can follow for an Android recovery analysis (mileage will vary):
• Download TestDisk and PhotoRec from http://www.cgsecurity.org/wiki/TestDisk_Download and unzip somewhere on your computer.
• Right click Testdisk (testdisk_win.exe) and choose "Run as Administrator" to start. Remember input is keyboard only (no mouse). ALWAYS carefully look at the menu of keyboard options down the bottom of the screen, as they change for each page. (They are also CASE SENSITIVE - "C" and "c" are different!)
• Choose No Log and press Enter. TestDisk will bring up a list of all disks it can see attached to your computer.
• Select the freshly mounted VHD from your list of disks, and choose Proceed. The VHD will look something like this:
Code:
Disk /dev/sdb - 15 GB / 14 GiB - Msft Virtual Disk• Choose "Analyse". You should see a list of partitions, including one named [userdata] at the end if you arrow down, which will look something like:
Code:
>26 P Unknown 6420480 30777310 24356831 [userdata]• If yes, type a capital P, and you should see a list of files/folders inside.
• If not:
• Make sure "Quick Search" is selected at the bottom, and press Enter. Let TestDisk run through its quick partition finding process (be patient). When it finishes you'll see a list of partitions again, but probably with less info and no names.
• Arrow down to the largest one (the biggest number under "Size in Sectors"), which is the [userdata] partition - it will probably look something like
• Select that partition, and the options at the bottom should now include the the "P: List Files" option. Type a capital P, and you should see a list of files inside. (Common mistake: pressing Enter instead of P, which means you have to go back and do it again.)
• Now that you can see the files inside the [userdata] partition, browse around and see where your lost files are. Useful info:• Arrow down to the largest one (the biggest number under "Size in Sectors"), which is the [userdata] partition - it will probably look something like
Code:
>P MS Data 6420480 30777271 24356792• The most likely location for personal data (photos etc) is under the /media/0/ directory. Look for the DCIM folder (photos taken with your device camera), Pictures folder (other images/albums), Music folder, etc.
• Normal files/folders come up in white. Deleted files/folders will come up in RED.
• IMPORTANT NOTE: If you're using a modern Android device/OS with TRIM enabled, unfortunately the odds are that the deleted file space has already been zero-filled, and so many files won't be recoverable, such as deleted photos from your Camera roll (under the DCIM folder). If you got your hands on the device soon enough, before TRIM ran, you might get lucky and the original photos might still be there inside the DCIM/Camera folder, showing up in red to indicate they were deleted but are still there. If not, all that might be left under DCIM could be the thumbnails (which although small are still better than nothing).
• Once you've found the data you want to recover, select it (use the colon symbol ':' to select/deselect single files, or the 'a' key to select all in a folder). Then type capital C to tell TestDisk you want to copy it. • Normal files/folders come up in white. Deleted files/folders will come up in RED.
• IMPORTANT NOTE: If you're using a modern Android device/OS with TRIM enabled, unfortunately the odds are that the deleted file space has already been zero-filled, and so many files won't be recoverable, such as deleted photos from your Camera roll (under the DCIM folder). If you got your hands on the device soon enough, before TRIM ran, you might get lucky and the original photos might still be there inside the DCIM/Camera folder, showing up in red to indicate they were deleted but are still there. If not, all that might be left under DCIM could be the thumbnails (which although small are still better than nothing).
• TestDisk will then jump over to its own parent folder (it wants to know where to save the recovered data to). You can save the recovered data directly in TestDisk's parent folder if you like, or if you want to put it somewhere else, you can. In Windows Explorer, create yourself a new folder called "Recovered-TestDisk" under C drive, and then back in TestDisk, use the arrow/Enter keys to navigate to it (see the keyboard navigation options at the bottom). When you're in the right place, press capital C again, and TestDisk will copy your file(s) there.
• TestDisk will report "Copy done!" in green text when finished. You can then continue finding and copying more files until you're done.
• When finished, quit TestDisk properly by hitting 'q' until TestDisk exits (instead of just closing the window).
• Open your "C:\Recovered-TestDisk" folder in Windows Explorer and check out your recovered files.
Photorec Data Recovery - if TestDisk didn't work for you, or if you just want to try another method anyway (it's definitely worth a go), try Photorec too. Photorec ignores filesystems and folder structures, and blindly rips everything that looks vaguely like a useful file out of raw memory. It's excellent for last ditch data recovery (all kinds, not just photos, despite its name). Folder locations and filenames are not recovered, only the files themselves, but often that's all you need.
• From the same folder as Testdisk: right click Photorec (photorec_win.exe) and choose "Run as Administrator" to start. Same principles with keyboard navigation etc apply.
• Select the VHD from your list of disks, and choose Proceed. The VHD will look something like this:
Code:
Disk /dev/sdb - 15 GB / 14 GiB - Msft Virtual Disk• OPTIONAL: At this point, if you want to limit the types of files that Photorec is looking for (for example if you're only after photos or music files etc), you can tell Photorec to ignore everything else, by selecting only certain file types under "File Opt" at the bottom. Otherwise, it will attempt to recover everything it finds.
• With the [userdata] partition selected, check that "Search" is selected at the bottom, and press Enter.
• Select "Other" as the filesystem type.
• Photorec then jumps straight over to its own parent folder (like Testdisk, it's asking you to know where to save the recovered data to). In Windows Explorer, create a new "C:\Recovered-Photorec" folder, then in Photorec, navigate to it. When you're there, press capital C, and Photorec will start the recovery to that folder.
• Recovery may take a while, so be patient. When it's finished, Photorec will report "Recovery completed".
• When finished, quit Photorec properly by hitting 'q' until Photorec exits (instead of just closing the window).
• Check your "C:\Recovered-Photorec" folder in Windows Explorer to see what it managed to get back. You'll see a bunch of recup_dir folders with random file contents. Hopefully your lost files will be in there somewhere. Remember the original filenames will be gone, so you're relying on file extensions and thumbnails to identify what they are.
• If there are too many files to sort out manually, you can:
• Use the Windows search function on the whole "Recovered-Photorec" folder to find all files of a certain type (e.g. Pictures, or *.jpg, etc) and move them into a separate folder together.
• Check out the various sorting options here: http://www.cgsecurity.org/wiki/After_Using_PhotoRec.
• Check out the various sorting options here: http://www.cgsecurity.org/wiki/After_Using_PhotoRec.
When you're finished with everything, remember to cleanly unmount the VHD image in Disk Management, by right-clicking the disk name to the left and choosing "Detach VHD". Store a copy of the VHD image file in a safe place, in case you ever want to re-mount it again for further recovery attempts.
Good luck!
Last edited:
Thank you, but is there normal tutorial? This one does not cover it all, especially some steps.
Doing it all manually is so counterproductive, Android is really useless sometimes. Automatic configuration tool would be great instead of that bible.
Doing it all manually is so counterproductive, Android is really useless sometimes. Automatic configuration tool would be great instead of that bible.
HELP :crying:
Guys i lost all my data accidentally while flashing a ROM.
I am using OnePlus2 and it has 64 gb Internal memory that is mounted as an MTP device. I have read many articles and found there is no way to recover data from MTP device.
This tutorial works on MTP Devices???
I just want to recover photos. Dont need any other data
Guys i lost all my data accidentally while flashing a ROM.
I am using OnePlus2 and it has 64 gb Internal memory that is mounted as an MTP device. I have read many articles and found there is no way to recover data from MTP device.
This tutorial works on MTP Devices???
I just want to recover photos. Dont need any other data
Yes, the tutorial above (http://xdaforums.com/showpost.php?p=66972563&postcount=1383) should work, as long as your device is still bootable. All the steps are there. Follow the instructions very carefully to obtain a forensic image from the device. Once you have that, you can use both TestDisk and PhotoRec from your PC to analyse the image and recover data from it.
If your device is Android v4.3 or later, it was probably running TRIM (not good news for photo data recovery). It's still worth running a recovery though, in case TRIM didn't get a chance to kick in.
In my observations TRIM doesn't seem to wipe out thumbnails, only the main images under DCIM, and thumbnails are better than nothing (on most Android devices they're surprisingly large).
Dude...what do you want, the OP to come over to your house and do the work for you while gently stroking your hair and whispering "It's going to be OK."?
I mean...do you have a better solution, versus "doing it manually". Do you even understand what is happening here??
Let me illuminate some key points:
1. Android, by nature, is designed to keep the /data partition secure. As we've gone from Lollipop>Marshmallow>Nougat, this is only getting to be more true. Now devices are usually encrypted by default, and you can't even run ADB as root on production devices.
2. These guides are telling you how to capture the entire disk image (of a Linux-based OS), mount it to a windows PC, and scan it with commercial data-recovery tools. You are stepping outside the realm of "any putz can do this". The instructions are complex because WHAT YOU'RE TRYING TO DO IS COMPLEX!!
3. "Android is really useless sometimes". No, I think what you meant to say is "your level of skill and knowledge is really useless sometimes". Android is an Operating System, and a very powerful one at that. If you'd like a prime example of a "useless" OS, look to iOS, where you can't even begin to think about doing something like this. Raw access to userdata storage? Yeah, good luck with that.
4. "Automatic configuration tool would be great..." - SO WRITE ONE THEN. The OP wrote this years ago, and zyph13 was kind enough to update these instructions *again*, which is significantly more love than a lot of these aging threads get. You should be thanking him for even replying to your first complaint.
That being said, I would suggest that instead of complaining about something being complicated, you take the time to understand the process and learn why and how you're doing what you're doing. There's a reason for all of this, as I illustrated above, and complaining that it's too hard or too complicated only tells everybody else that you're just lazy, ignorant, or both.
zyph13 said:
To add to the original discussion - I found that redirecting the output with Cygwin doesn't seem to work. It shows a 0 counter in the "second" cygwin window, and then the first window stops executing the dd command.
I was (well, it's still dumping) able to overcome this by doing an ADB shell into the device, getting root, and then doing
Code:
dd if=/dev/block/XXX of=/mnt/extSdCard/data1.rawThis obv. requires you have an external SD card slot and a card big enough to hold a copy of your /userdata part., but I've used it in the past to dump partitions with no issue. Zyph, I'm curious if you have any insight as to what I'm doing wrong? I'm running win10. It is an insider preview and I do have the Windows Subsystem For Linux installed (Bash on Windows, yes it's a thing now.
), so I'm wondering if I pooched something there. It seems like it *wants* to run, but isn't grabbing the output correctly...
That'd be nice.
I understand more-less. Enough to do basics, not enough to do whole process even with tutorial as it does not cover all noobs problems I encountered.
A lot of things in Android made me hard life because of the encryption, because problems with kernels or just changing (modding look of it) GUI. It is not simple.
I do not think I am too lazy or ignorant. I am just shocked how much effort one must put into recovery image operation.
Knowledge about that won't make me smarter as knowing Linux won't make you better than Windows user.
I reformatted and installed another rom on tablet, soon changing it to Windows one, as Android tablets are just bigger phones.
Just make sure don't use cywin 64bit it got 0 file size problem, i got same case and switched to 32bit and solved.
I'm having the same issue, and I solved it by running the last command (busybox) in the first terminal and then immediately running the last command (busybox) in the second terminal.
I'm stuck on 5th stage. Everything is done right but anyway it doesn't work. [Galaxy S6]
$ adb shell
shell@zeroflte:/ $ su
su
root@zeroflte:/ # /system/bin/busybox nc -l -p 5555 -e /system/bin/busybox dd if=/dev/block/sda3
/bin/busybox nc -l -p 5555 -e /system/bin/busybox dd if=/dev/block/sda3 <
dd: writing 'standard output': Connection reset by peer
87+0 records in
86+0 records out
44032 bytes (43.0KB) copied, 0.032679 seconds, 1.3MB/s
$ adb shell
shell@zeroflte:/ $ su
su
root@zeroflte:/ # /system/bin/busybox nc -l -p 5555 -e /system/bin/busybox dd if=/dev/block/sda3
/bin/busybox nc -l -p 5555 -e /system/bin/busybox dd if=/dev/block/sda3 <
dd: writing 'standard output': Connection reset by peer
87+0 records in
86+0 records out
44032 bytes (43.0KB) copied, 0.032679 seconds, 1.3MB/s
I was able to mount raw file using vhd.
Recuva detected 27 files and those were undeleted ones.
My mobile (Asus ZenFone 2 Laser ZE550KL) was mistakenly formatted by me.
Used EaseUS Data recovery and it found many small files but two big files , namely , FILE079.FCPEVENT and FILE001.FCPEVENT.(Both are of 4GB each).
Now what to do next??
Recuva detected 27 files and those were undeleted ones.
My mobile (Asus ZenFone 2 Laser ZE550KL) was mistakenly formatted by me.
Used EaseUS Data recovery and it found many small files but two big files , namely , FILE079.FCPEVENT and FILE001.FCPEVENT.(Both are of 4GB each).
Now what to do next??
data recovery on droid turbo (quark)
@Wartickler @scandiun @hakneo @VieiraS @iHack13
Does fstrim write log, in case of bootloader unlock process in persistent log file?
Objective to check if fstrim has already cleared the data.
https://www.reddit.com/r/Android/comments/1rws2c/is_my_trim_working/
problem this is only works in normal boot mode and not in fastboot or twrp recovery. I am hesitant to boot into normal mode, as i am guessing fstrim will start background.
Is it good idea to rename fstrim binary (temporary)?
In twrp console,
works but no fstrim related log entries.
Device : Droid Turbo (quark)
@Wartickler @scandiun @hakneo @VieiraS @iHack13
Does fstrim write log, in case of bootloader unlock process in persistent log file?
Objective to check if fstrim has already cleared the data.
https://www.reddit.com/r/Android/comments/1rws2c/is_my_trim_working/
Code:
adb logcat -d | grep -i fstrimIs it good idea to rename fstrim binary (temporary)?
In twrp console,
Code:
dmesgDevice : Droid Turbo (quark)
Last edited:
Writing to Update :
Device : Droid Turbo (quark)
I tried different methods mentioned in the thread and https://www.dflund.se/~jokke/androidfilerecovery/ with testdisk & photorec.
Unfortunately deleted/formatted files are not recoverable for me. In my case, bootloader unlock process trigger wipe (trim) /data.
Starting using flickr & google drive to sync your files & photos.
Device : Droid Turbo (quark)
I tried different methods mentioned in the thread and https://www.dflund.se/~jokke/androidfilerecovery/ with testdisk & photorec.
Unfortunately deleted/formatted files are not recoverable for me. In my case, bootloader unlock process trigger wipe (trim) /data.
Starting using flickr & google drive to sync your files & photos.
nexus 7 2012 softbrick - recoverable?
Like many others here I have a file I need but that I didn't back up (I know, I know).
I went to bed on Friday with a working nexus 7 2012 and woke up on Saturday with a soft bricked device. I have no idea why - it just book loops.
It is stock.
- boot loader locked
- stock recovery
- Android 4.2.2
- not rooted
From what I have been able to understand there is no way to recover data since the nexus 7 bootloader will destructively over-write memory as soon as I unlock.
I don't believe there is any way to get to adb other than the cut down "sideload" version in recovery and that just seems to abort once I download a new update.
Is anyone aware of any method that might work for me to recover data?
I can't fastboot a new image since the bootloader is locked.
Thank you
Like many others here I have a file I need but that I didn't back up (I know, I know).
I went to bed on Friday with a working nexus 7 2012 and woke up on Saturday with a soft bricked device. I have no idea why - it just book loops.
It is stock.
- boot loader locked
- stock recovery
- Android 4.2.2
- not rooted
From what I have been able to understand there is no way to recover data since the nexus 7 bootloader will destructively over-write memory as soon as I unlock.
I don't believe there is any way to get to adb other than the cut down "sideload" version in recovery and that just seems to abort once I download a new update.
Is anyone aware of any method that might work for me to recover data?
I can't fastboot a new image since the bootloader is locked.
Thank you
Yes you can recover lost data from internal memory without having any trouble
Source: http://www.file-recovery.com/android_recovery.htm
Source: http://www.file-recovery.com/android_recovery.htm
Similar threads
- Locked
Top Liked Posts
-
There are no posts matching your filters.
-
306This method does not seem to work on newer phones that apply TRIM or some other type of partition clearing implementation. If anyone has recovered their data on a device newer than Android 4.3 please pm me and let me know.
The Preamble
Did you delete all your SDCard data?
Are you pissed because no one told you before you unlocked your bootloader what would happen?
Did you lose valuable pictures of cats doing wondrously funny things? :laugh:
Well now there's a convenient new way for you to get that data back Buckaroo!
The Problem
Internal Memory doesn't mount as a drive like external memory does. External memory would allow you to use data recovery tools that scan for deleted files and return them to a usable state. These tools work because most operating systems don't go through and set all of those 1's and 0's to just 0's when you delete a file. Usually the operating system will just delete the reference pointer in the index that says that a file exists with such-and-such name and it's located at this position on the hard disk / memory location. There are destructive delete tools out there that will overwrite the spot of a deleted file multiple times to discourage recovery in just this manner. The issue is that data recovery tools need an actual mounted drive in order to dig deep and unearth those funny pictures of cats you so tragically deleted by accident. These newest batches of phones don't have external SDcards which are super easy to mount as drives. Internal memory mounts as MTP/PTP which is not treated as a mounted drive and cannot be scanned by these data recovery tools. But, cry no more cream-puff! :crying:
The Process
My phone is the Samsung Galaxy Nexus (toro) though I imagine this should work for ANY phone with Internal Memory. We will be using a Windows 7 machine to:
- back up the entire internal memory partition to your computer as a single, massive .RAW file,
- convert the .RAW file output to a VHD,
- mount the VHD as a disk in Disk Manager,
- scan the attached VHD volume for files that have been deleted and recover them,
- ?
- profit! :good:
The Requirements
- A rooted Android phone, (try to root with a non-destructive method as this appears to protect those who must root from wiping the device data a second time),
- BusyBox installed on your device,
- Cygwin installed to [c:\cygwin] with pv and util-linux from the repo. Make sure to open Cygwin once to make sure that the /bin folder is created. Also, I made a folder at [c:\cygwin\nexus] to put the exported .RAW file,
- Netcat (download the ZIP file and extract nc.exe to [c:\cygwin\bin]),
- ADB (make sure adb.exe is in your path),
- USB Debugging enabled on your device,
- VHD tool from the mighty M$. Put the VhdTool.exe file in [c:\cygwin\nexus],
- Piriform Recuva or your favorite data recovery tool, (it appears Recuva only finds the more common file types like images, videos, etc. Those were the file types in which I was interested. If you are after more exotic file types perhaps you might share the software you used.)
- A calm sense of peace and serenity that you will get your files back... :fingers-crossed:
The Work
- *****Based on the number of people having trouble with this step it is now my recommendation that you choose to recover your entire memory block instead of just the data partition. In my phone's case that is mmcblk0. Please discover if yours is different.***** Identify which block/partition you want to recover. For our purpose here we are seeking to recover the userdata partition: /dev/block/mmcblk0p12
- Turn on your phone
- Connect the phone in ADB mode
- Unlock the screen.
- Open a Cygwin terminal and enter (This assumes your BusyBox installation is at [/system/bin/busybox]. It may be at [/system/xbin/busybox]):
Code:adb forward tcp:5555 tcp:5555 adb shell /system/bin/busybox nc -l -p 5555 -e /system/bin/busybox dd if=/dev/block/mmcblk0p12 - Open another Cygwin terminal and enter:
Code:adb forward tcp:5555 tcp:5555 cd /nexus nc 127.0.0.1 5555 | pv -i 0.5 > mmcblk0p12.raw - Run around the house a few times. For 32GB internal memory this is going to take 3+ hours. That's a lot of running. When it's done...
- We need to convert the .RAW file to a virtual hard drive. VhdTool.exe basically just puts a VHD footer on the end of the .RAW file. Open a Windows command prompt, go to [c:\cygwin\nexus], and type:
Code:
VhdTool.exe /convert mmcblk0p12.raw - Now we need to mount the VHD in Windows. Select the Start button-->right-click Computer-->select Manage.
- Select Storage-->Disk Management.
- In the menu select Action-->Attach VHD.
- For Location enter [c:\cygwin\nexus\mmcblk0p12.raw] and select the OK button.
- Right-click on the name (e.g. "Disk 1") to the left of the Unallocated space and select Initialize Disk.
- Select the GPT (GUID Partition Table) radio button and select the OK button.
- Right-click on the Unallocated space and select New Simple Volume...
- In the Wizard select Next>, leave the default for the volume size, select Next>, select a drive letter (e.g. K), select Next>, MAKE SURE to select the 'Do not format this volume' radio button, select Next>, select Finish.
- A box will pop up asking you to format the drive. You DO NOT want to format the drive at this time.
- Right-click on the RAW space and select Format... MAKE SURE to change the File system to FAT32. Set the Allocation unit size dropdown to 'Default.' MAKE SURE that the Perform a quick format checkbox is CHECKED. You do not want to overwrite the entire new drive with all zeroes (0's) and destroy your data. Quick Format means that it will only attempt to destroy the index for the drive by establishing a new index. Without this box checked the Windows operating system will write zeroes (0's) across the entire volume, potentially destroying your data. Select the OK button.
- A box will pop up saying that Formatting this volume will erase all data on it. That would be doubly true if you actually didn't check the 'Perform a quick format' checkbox. Double check that you actually did check the box and select the OK button. (Don't worry. This essentially leaves the volume in the exact same state that your phone's internal memory is living in right now: there is data on the drive...you just can't see it. It's coming back, I promise!)
- Open the Piriform Recuva application. In the wizard select the 'Next >' button. Select the 'Other' radio button and select Next >. Select the 'In a specific location' radio button and enter: k:\ (assuming K is the drive letter you chose...) Select the Next > button. Select the Enable Deep Scan checkbox. This is the magical setting that finds files that have been deleted...but not really deleted. Select the Start button.
- The application may take about an hour to do the 'Deep Scan.' It's time for more laps around the house! Once the application has returned its results you can choose which files to recover using the checkboxes. Select the 'Recover...' button and choose the location to which you wish to output your files.
- ?
- Profit! :victory:
The Appendix
The following links helped me to create this modern marvel - mad props to scandiun! :
- [GUIDE] How to make a nandroid backup directly to your computer without using sdcard
- [Info] List of Samsung Galaxy Nexus GT-I9250 devices and partitions
- How to Create and Attach a Virtual Hard Disk in Windows 7
Good luck!31I forgot to mention, but run commands inside android as superuser or may fail (just after adb shell):
Code:adb forward tcp:5555 tcp:5555 adb shell [B]su[/B] /system/bin/busybox nc -l -p 5555 -e /system/bin/busybox dd if=/dev/block/mmcblk0p12
And greetings for the guide, I didn't know of VHD Tool, congratulations!.22VHD tool download
For people who are unable to get hands on VHD tool,
Exe: https://www.mediafire.com/?f96bmsvjz4qdvbu
Same thing in zip: https://www.mediafire.com/?f96bmsvjz4qdvbu
Regards15Success! Thanks to everybody!
After reading some posts I want to resume in one reply users contribution like advices or notes including my own contribution about "0 byte issue", "cygwin 64 bits vs 32 bits" and other issues of this topic.
1) Remember that could be important DO NOT use the phone neither Internet neither app which could WRITE at inner memory. The less use, the better.
2) Remember the possibility to download directly the APK playstore applications from your computer as busybox using an APK downloader instead of downloading directly from your device to prevent write on the inner memory.
Therefore transfer the APK using USB cable to the external SD card to prevent write data to the inner memory.
3) Remember that you could have busybox installed in bin, xbin or other folder applying these commands following the steps
4) Check if ADB shell and busybox have "allow access" in the SuperSU at your phone
5) Check if the phone is screen blocked with PIN. You need to unblocked it to allow connection between computer and your device
6) Remember to ACCEPT the RSA fingerprint appear as a popup window on your device when you init the connection using ADB. If this does not appears try to move between USB modes as UTP and PTP till some event trigger it.
7) It seems NO communication using nc command on cygwin64. Use ncat.exe instead.
NOTE about "Cygwin 32 bit, instead of the 64 bit" issue: it is not mandatory to install cygwin (32 bits). Using ncat.exe (32 bits) instead of nc at cygwin 64 bits goes on.
How to install ncat.exe into cygwin64:
a) Download nmap-6.46-win32.zip from nmap website. Nmap contains ncat.exe application for Windows
b) Open and extract ZIP file into a temp folder
c) Copy ncat.exe, libeay32.dll and ssleay32.dll to the C:\cygwin64\bin folder (Assumed you installed cygwin in that path)
d) Restart cygwin64 terminal to have the changes on.
Then, change nc to ncat in this step:
$nc 127.0.0.1 5555 | pv -i 0.5 > mmcblk0p12.raw
$ncat 127.0.0.1 5555 | pv -i 0.5 > mmcblk0p12.raw
8) It is not necessary to log as root inside cygwin. Only run cygwin as Windows Administrator.
9) Remember to have ADB access at PATH environment var to allow cygwin execute Windows ADB without issues
10) Remember to use su and absolute paths at first shell.
$adb shell su /system/xbin/busybox nc -l -p 5555 -e /system/xbin/busybox dd if=/dev/block/mmcblk0p12
if it shows the error "can't open permission denied" this means that the device is blocked. See steps 4), 5) and 6)
11) You will obtain something like that after dump all data from inner memory to the raw file. It is necessary to complete with a non error process:
##### gywin first shell ###############
rober@machine9873
$ adb shell su /system/xbin/busybox nc -l -p 5555 -e /system/xbin/busybox dd if=/dev/block/mmcblk0p12
24182784+0 records in
24182784+0 records out
12381585408 bytes (11.5GB) copied, 2836.886444 seconds, 4.2MB/s
###############################
##### gywin second shell ############
$ ncat 127.0.0.1 5555 | pv -i 0.5 > mmcblk0p12.raw
close: No error [4,21MiB/s] [ <=> ]
11,5GiB 0:47:17 [4,16MiB/s] [ <=>
###############################
12) Remember to rename mmcblk0p12.raw to mmcblk0p12.vhd AFTER applying vhdtool /convert. Better for recognize VHD files on Windows Disk Management.
13) AFTER Initialize Disk it is not mandatory create any volume neither quick format the disk although for piriform recuva could be necessary. However some other software as PhotoRec or Diskinternals Partition Recovery are able to READ the Initialized disk and unallocated space to recover files directly. The less manipulation on the VHD, the better.
14) Remember that the recover utilities have file type defined. But, how about if you want to recover a special file type? In PhotoRec you can define custom file extension to be recovered. More info at cgsecurity.org.
15) Keep calm and enjoy the process!
_______________________
#Computer
Computer OS Windows 7 64 bits
CPU Intel Core 2 Duo E6600@2.40GHz
#Device
Model GT-I9300
Android 4.3
Baseband I9300XXUGNA8
Kernel 3.0.31-2429075
dpi@HP20 #1
Thu Jan 16 23:47:54 KST 2014
Build JSS15J.I9300XXUGNA5
Rooted CF-Auto-Root-m0-m0xx-gti9300.zip
SuperSU 1.93
Busybox 1.22.113alright. I think I found the solution for the 0 Byte issue.
I tried everything now and it finally worked.
The culprit for me was the whole 64 bit thing. Just go 32bit. (Only thing that is 64 bit on my setup is JDK 8 right now.)
I also want to note that I am on Windows 8 Pro (64bit)
I quickly want to summarize the important steps where a lot of people seem to make mistakes or oversee something:
1) get Cygwin 32 bit and NOT 64 bit
http://cygwin.com/install.html ->> setup x86.exe
Install it. when Installing click next until you get to the packages window. See screenshot for that . Scroll down to Utils
add the packages pv and util-linux (by clicking on skip and checking both boxes)
then complete your installation.
you should now have a bin folder now.
2) go grab the adb (adt bundle) from google.
unzip it and copy the whole content from \adt-bundle-windows-x86_64-20140321\sdk\platform-tools
to your C:\cygwin\bin folder
3) grab netcat zip from http://www.daemon.de/Netcat
and follow their instructions. its only the nc file (nc.exe to be precise) that you want to copy to your cygwin\bin folder
thats basically it. these are the most important steps where you could have made mistakes.
for me personally the 64 bit was the only culprit. Everything works fine with the 32 bit cygwin for me. but the 64 bit one still says 0 Bytes.. so scr*w it
also if you want to know your partition, you might have different values like I do. mine was
Code:su ls -l/dev/block/platform/dw_mmc/by-name/
to get your own value type
it should output a folder name . the value that you are looking for .Code:su cd /dev/block/platform/ ls
Code:ls -l/dev/block/platform/(ENTER_THE_VALUE_THAT_WAS_OUTPUTTED_BY_THE_LS_CMD_BEFORE)/by-name/
And that should show you which names are assigned to which patitions (system, user ,data etc)
And last but not least. I am just an average guy with few skills but I try to punch myself through stuff by learning and trying to do my best.
I am not trying to brag or convince anybody and I know that there are nerds who might want to bash me. I dont care. I had the 0 byte problem myself and read through the forums and the problem was never really solved.
Now that I solved it for myself I could ve left without sharing my success in solving this problem (for my case at least but I hope its a general one)
But I took my time to share it with the guys in need.
I hope it will help you and many of you have precious data that needs to be restored. I would be happy if I can contribute something to save your pics from family etc and other cases that were mentioned a few times in this thread.
Also Thanks to the Topic Starter , but I dont recommend the recovery software that he recommend. I'd go for testdisk / photorec personally.
There was another software that was recommended somewhere in this thread . you might want to test that one maybe if testdisk is too hard for you.
one last request: I think my post is going to be long. so PLEASE dont quote all of it if you answer
