[Q] How to restore wiped files?
- Thread starter thekkk
- Start date
It told me that personal settings will be deleted, and i thought that only would be settings, etc...
and in the tutorial i've read there was no warning for this
No the bootloader unlock screen says personal data (not settings) will be wiped which include the virtual sdcard (/data/media/0)
btw this also deleted stock apps like flashlight, calculator, sound trimmer, tuneIn, SoundHound etc.... which are stored in /data/preload
Last edited:
It doesnt matter how difficult it is, but somehow i'm sure there must be a way, the question is how. Because every recovery software cant be used because of de MTP-mode
Sure. I just personally think that you'll give up, given those circumstances
Just being realistic... Sent from my HTC One using Tapatalk
The first step is to not boot the phone until you get a dump of your data partition. Booting to a custom recovery is okay--a full Android boot is not.
In recovery (using the ADB shell), umount data and get a dump of the data partition (/dev/block/mmcblk0p37) using "dd". Since you can't write to the data partition while making its dump, you'll need to write to /system. Since /system isn't very big, you'll need to do the dump in pieces of about 350 MB each (depends on how much free space you have in /system).
The "dd" parameters you'll need are "bs" to speed things up, "skip" to tell it where to start the chunk, and "count" to determine how big the chunk is. Since /data is 25.6 GB, you'll need to do this 60-70 times, and after each chunk, use "adb pull" to copy the chunk to your computer. When you have all the chucks, reassemble them and make sure it's the same size as /dev/block/mmcblk0p37. Make sure it's a valid ext4 filesystem. Then you can start using data recovery tools.
So put your money where your mouth is and do it.
The first step is to not boot the phone until you get a dump of your data partition. Booting to a custom recovery is okay--a full Android boot is not.
In recovery (using the ADB shell), umount data and get a dump of the data partition (/dev/block/mmcblk0p37) using "dd". Since you can't write to the data partition while making its dump, you'll need to write to /system. Since /system isn't very big, you'll need to do the dump in pieces of about 350 MB each (depends on how much free space you have in /system).
The "dd" parameters you'll need are "bs" to speed things up, "skip" to tell it where to start the chunk, and "count" to determine how big the chunk is. Since /data is 25.6 GB, you'll need to do this 60-70 times, and after each chunk, use "adb pull" to copy the chunk to your computer. When you have all the chucks, reassemble them and make sure it's the same size as /dev/block/mmcblk0p37. Make sure it's a valid ext4 filesystem. Then you can start using data recovery tools.
So put your money where your mouth is and do it.
That sounds like something, first of all thanks for your input!
But how should i run this command without booting into android (I'm in clockwork-touch recovery, but doesnt seem to work)? This command works (when booted into android), i've tried it with 'dd', so i guess thats the correct way!
=> If i have to boot into android anyway to do this, i would also have an OTG plus USB-Stick (32GB), then i could do it in about 2 parts to save it directly to the usb-stick. Would that be the better aproach instead of writing it to the /system? because i don't know what action writes to the /sdcard
Just to clarify, i have to execute the following command one after the other(?) :
$ dd if=/dev/block/mmcblk0p37 bs=367001600 count=1 skip=0 of=/system/chunk1.img
adb pull /system/chunk1.img .
$ dd if=/dev/block/mmcblk0p37 bs=367001600 count=1 skip=1 of=/system/chunk2.img
adb pull /system/chunk2.img .
$ dd if=/dev/block/mmcblk0p37 bs=367001600 count=1 skip=2 of=/system/chunk3.img
adb pull /system/chunk3.img .
Do i have to make something special that i can reassemble them later or are there programms out there for that problem?
Last edited:
Um, every time you boot to android you are rewriting the very flash memory you are trying to recover.
The ratio of the amount of work required vs the chances of success is not a favorable one. Unless you are trying to recover video of 'baby's first steps' or a bitcoin private key, I would let this go..
Sent from my HTC One using xda app-developers app
The ratio of the amount of work required vs the chances of success is not a favorable one. Unless you are trying to recover video of 'baby's first steps' or a bitcoin private key, I would let this go..
Sent from my HTC One using xda app-developers app
There were memories on it, and it would be a pity if they're all gone now
I'm not that type of guy to give up, I have the motivation and the time to do it. I will give it at least a try, I have nothing to loose, except time - but that doesnt matter because I wanna have these data's back
The only one problem I see now is that if I read the block step by step and save this, I don't know how I should reassemble all these files. Anyone has an idea? Reading a block and pull it out of the phone isnt the problem
That looks exactly right, except that normally people use "bs" as a smaller value and "count" and "skip" as a multiple of that value--I'm not sure whether it makes a difference in the real world. (I.e., instead of bs=4096 count=1 skip=1, people normally write bs=1024 count=4 skip=4.)
You are awesome. I was sure you'd give up.
And using a USB stick is a very good idea, but since you only have one USB port you can't type the commands on your computer using ADB. And yes, ADB should work fine when you're booted into recovery. If CWM doesn't work, you could try TWRP instead. TWRP will actually let you type the commands on the phone's screen (no need for ADB), so you can attach the USB stick.
If the chunks line up exactly (they will if you use dd like you are), on OSX or Linux you can use a program called "cat" to just dump them into one file: "cat a.txt b.txt" prints both files to the screen, so "cat part1 part2 part3 > combined" will join files into a new one (the new file is overwritten, so be careful). I would have to search online for how to join files on windows. If the chunks overlap, this forum post has a short python script that will detect a matching region at the end of one file and the start of the next and join them to a new file.
Note also that this doesn't guarantee your data will be recoverable. I wish you the best of luck, but flash storage is even trickier than hard drives, because due to wear leveling, it's possible the data you want isn't even being exposed as visible to the OS, with different NAND blocks shown instead.
Last edited:
If that doesnt work on windows I have no problem to get a linux machine. What really causes concern, is that i allready saved multiple chunks with 350mb and also about 4GB and opened them in DiskInternals Linux Reader, but there was ever the same content, multiple folders and 2 files, but nearly everything about on 0kb, so it was nearly empty. Is that only because the files aren't dumped in one file?
What I actually don't get is that your writing 4*1024, but that are just 4096 Bytes, but before you talked about 350MB. I found out that for this I could also use bs=350M (M for megabytes), but I dont know if that really is a problem, couldn't explain to myself why, but you never know.
When I write directly to the USB, I'm also able to scale the size up to 4GB, because of the file-system-restriction. That would go faster. But I will try to firstly create the 60-70 chunks with 350MB and try to dump them into one file. Hope this will get me where I want to go.
Last edited:
What I wrote was just an example--I'm not actually suggesting you get the dump in 4 KB chunks.
As far as the chunk sizes, you just need to make sure they line up. If you start with a 350 MB chunk that was made with "bs=1M count=350", you can make the second chunk (a bigger one) with "bs=1M skip=350 count=4000". The problem is that since you used exact byte numbers for BS, it's more complicated to get them to line up correctly. For example, 1M is probably 1000000 bytes in this program, but it could also be 2^20 bytes. Basically, chuck size doesn't matter as long as they're properly lined up. Also, I wouldn't worry about the recovery tool failing until you have all or most of the chunks. However, I see that DiskInternals Linux Reader is a filesystem browser, not a recovery tool. You need a recovery tool, since the files are technically deleted (actually, the filesystem is wiped). You need a tool that looks for the data (all bytes), not what the filesystem officially says is present.
What I wrote was just an example--I'm not actually suggesting you get the dump in 4 KB chunks.
As far as the chunk sizes, you just need to make sure they line up. If you start with a 350 MB chunk that was made with "bs=1M count=350", you can make the second chunk (a bigger one) with "bs=1M skip=350 count=4000". The problem is that since you used exact byte numbers for BS, it's more complicated to get them to line up correctly. For example, 1M is probably 1000000 bytes in this program, but it could also be 2^20 bytes. Basically, chuck size doesn't matter as long as they're properly lined up. Also, I wouldn't worry about the recovery tool failing until you have all or most of the chunks. However, I see that DiskInternals Linux Reader is a filesystem browser, not a recovery tool. You need a recovery tool, since the files are technically deleted (actually, the filesystem is wiped). You need a tool that looks for the data (all bytes), not what the filesystem officially says is present.
I'm trying it now with the following:
$ dd if=/dev/block/mmcblk0p37 of=/system/chunk1.img bs=1048576 count=350 skip=350
One sentence i don't understand, what do you mean by "properly lined up"? Are they not properly lined up when i use the above 1048576 Bytes (exactly 1 MB)?
For the recovery tool i will have a look, thanks for the tipp, if i remember correct, there was stated that this also can recover
That's fine. But you were on to something with the USB stick idea--if I were you, I'd much rather make two dump chunks than 60.
What I mean by "lining up" is that this the following two chunks will not line up--they will have a gap between with missing data:
dd if=/dev/block/mmcblk0p37 of=/system/chunk1.img bs=1M count=350 skip=0
dd if=/dev/block/mmcblk0p37 of=/system/chunk2.img bs=1048576 count=350 skip=350
These two chunks will have overlapping data:
dd if=/dev/block/mmcblk0p37 of=/system/chunk1.img bs=1048576 count=350 skip=0
dd if=/dev/block/mmcblk0p37 of=/system/chunk2.img bs=1M count=350 skip=350
It's not an issue if you're starting from chunk 0 and using the same "bs", but if you wanted to keep the chunks you already made (with a very specific size), and continue making 4GB chunks after that, it might be tricky to get bs/count/skip right so the chunks don't overlap with your data and don't skip any, either. This is "lining up" properly.
Thanks for explenation
So i have my 77 .img chunk-files all on my pc. Btw, Windows does have "cat" also, but only in Windows Powershell, and it's soooo slow... and somehow the combined files are bigger
I'll use it in linux, better approach i guess After I have my final image, I mount that into my ubuntu machine and then try to recover, right? You said something about a "valid EXT4" filesystem, what do I have to pay attention for this? Unfortunatly I'm not a linux-Guru, but should be able to handle it with some help. I think first I try the recover tool from ubuntu that is built-in, because I havn't searched for an alternative. I don't think that i need a special one explicit for Android-files?
Many thanks that you take time and try to help me :good:
, I don't think I'm wide away from my goal now. I hope that I'm a lucky guy and I can restore, at least, some files.
So i have my 77 .img chunk-files all on my pc. Btw, Windows does have "cat" also, but only in Windows Powershell, and it's soooo slow... and somehow the combined files are bigger
if you want to use windows to combine multiple files, in a normal command prompt:
copy /b file1.img + file2.img + file3.img [+ etc] outputfile.img
@fenstre, couldn't he have mounted a 64GB OTG Stick and dd the entire partition there in one go?
Thanks that with windows-command promt worked without any problem
Because of the OTG Stick, the filesystem has a restriction of 4GB files, so I can't dd the entire partition in one go. And I also have the partition now in one .img file. But now I'm really stucked at how to recover this, with something from Windows or Linux? Tried DMDE, it showed me the partition but I couldn't really find some old files
Someone know's whats possible and which programms do you suggest? I have a EXT4 .IMG file with about 27GB and I wanna restore wiped files.
Yep, I'm not so smart. Even a 32 GB stick is big enough. He would still need to reformat the stick as EXT3/4 to get around the 4GB size limit, then he'd have to jump through hoops to read the data on his computer.
I've never used one--I just searched for "ext4 undelete". I suspect that Linux will have more options than Windows. This page also lists several utilities you can try:
https://wiki.archlinux.org/index.php/File_Recovery
Let us know how it goes!
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
2
What I wrote was just an example--I'm not actually suggesting you get the dump in 4 KB chunks.
As far as the chunk sizes, you just need to make sure they line up. If you start with a 350 MB chunk that was made with "bs=1M count=350", you can make the second chunk (a bigger one) with "bs=1M skip=350 count=4000". The problem is that since you used exact byte numbers for BS, it's more complicated to get them to line up correctly. For example, 1M is probably 1000000 bytes in this program, but it could also be 2^20 bytes. Basically, chuck size doesn't matter as long as they're properly lined up. Also, I wouldn't worry about the recovery tool failing until you have all or most of the chunks. However, I see that DiskInternals Linux Reader is a filesystem browser, not a recovery tool. You need a recovery tool, since the files are technically deleted (actually, the filesystem is wiped). You need a tool that looks for the data (all bytes), not what the filesystem officially says is present.1
The first step is to not boot the phone until you get a dump of your data partition. Booting to a custom recovery is okay--a full Android boot is not.
In recovery (using the ADB shell), umount data and get a dump of the data partition (/dev/block/mmcblk0p37) using "dd". Since you can't write to the data partition while making its dump, you'll need to write to /system. Since /system isn't very big, you'll need to do the dump in pieces of about 350 MB each (depends on how much free space you have in /system).
The "dd" parameters you'll need are "bs" to speed things up, "skip" to tell it where to start the chunk, and "count" to determine how big the chunk is. Since /data is 25.6 GB, you'll need to do this 60-70 times, and after each chunk, use "adb pull" to copy the chunk to your computer. When you have all the chucks, reassemble them and make sure it's the same size as /dev/block/mmcblk0p37. Make sure it's a valid ext4 filesystem. Then you can start using data recovery tools.
So put your money where your mouth is and do it.1
There were memories on it, and it would be a pity if they're all gone now
I'm not that type of guy to give up, I have the motivation and the time to do it. I will give it at least a try, I have nothing to loose, except time - but that doesnt matter because I wanna have these data's back
The only one problem I see now is that if I read the block step by step and save this, I don't know how I should reassemble all these files. Anyone has an idea? Reading a block and pull it out of the phone isnt the problem1
That looks exactly right, except that normally people use "bs" as a smaller value and "count" and "skip" as a multiple of that value--I'm not sure whether it makes a difference in the real world. (I.e., instead of bs=4096 count=1 skip=1, people normally write bs=1024 count=4 skip=4.)
You are awesome. I was sure you'd give up.
And using a USB stick is a very good idea, but since you only have one USB port you can't type the commands on your computer using ADB. And yes, ADB should work fine when you're booted into recovery. If CWM doesn't work, you could try TWRP instead. TWRP will actually let you type the commands on the phone's screen (no need for ADB), so you can attach the USB stick.
If the chunks line up exactly (they will if you use dd like you are), on OSX or Linux you can use a program called "cat" to just dump them into one file: "cat a.txt b.txt" prints both files to the screen, so "cat part1 part2 part3 > combined" will join files into a new one (the new file is overwritten, so be careful). I would have to search online for how to join files on windows. If the chunks overlap, this forum post has a short python script that will detect a matching region at the end of one file and the start of the next and join them to a new file.
Note also that this doesn't guarantee your data will be recoverable. I wish you the best of luck, but flash storage is even trickier than hard drives, because due to wear leveling, it's possible the data you want isn't even being exposed as visible to the OS, with different NAND blocks shown instead.1
That's fine. But you were on to something with the USB stick idea--if I were you, I'd much rather make two dump chunks than 60.
What I mean by "lining up" is that this the following two chunks will not line up--they will have a gap between with missing data:
dd if=/dev/block/mmcblk0p37 of=/system/chunk1.img bs=1M count=350 skip=0
dd if=/dev/block/mmcblk0p37 of=/system/chunk2.img bs=1048576 count=350 skip=350
These two chunks will have overlapping data:
dd if=/dev/block/mmcblk0p37 of=/system/chunk1.img bs=1048576 count=350 skip=0
dd if=/dev/block/mmcblk0p37 of=/system/chunk2.img bs=1M count=350 skip=350
It's not an issue if you're starting from chunk 0 and using the same "bs", but if you wanted to keep the chunks you already made (with a very specific size), and continue making 4GB chunks after that, it might be tricky to get bs/count/skip right so the chunks don't overlap with your data and don't skip any, either. This is "lining up" properly.
New posts
-
-
-
[CLOSED] Should I enable enforce sulist on Kitsune Mask?- Latest: Oswald Boelcke
-
Question Is there a way to install two diffrent versions of a app?- Latest: iwanttoroota11walmart
-
