I unlocked my HTC One Bootloader, but all my files got wiped :crying:
How can i restore files? I lost all my photos and whatsapp chat history. There must be a possibility?! But how?
I don't think you can recover. It told you this when unlocking.
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
Yeah I don't think you'll get anything back easily at all. Keep that phone backed up in the future!
Sent from my HTC One using Tapatalk
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
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.the question is how. Because every recovery software cant be used because of de MTP-mode
So put your money where your mouth is and do it.It doesnt matter how difficult it is, but somehow i'm sure there must be a way,
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.
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
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.)=> 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 .
You are awesome. I was sure you'd give up.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.
What I wrote was just an example--I'm not actually suggesting you get the dump in 4 KB chunks.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)...
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.
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.
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.I$ 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)?
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.
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
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?
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.@fenstre, couldn't he have mounted a 64GB OTG Stick and dd the entire partition there in one go?
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: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.
What I wrote was just an example--I'm not actually suggesting you get the dump in 4 KB chunks.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)...
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.
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.the question is how. Because every recovery software cant be used because of de MTP-mode
So put your money where your mouth is and do it.It doesnt matter how difficult it is, but somehow i'm sure there must be a way,
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
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.)=> 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 .
You are awesome. I was sure you'd give up.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'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.I$ 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)?