|
I've noticed that it's fairly easy to recover accidentally deleted files from spinning hard drives using any decent recovery software (for example, Recuva or Testdisk/Photorec), as long as I don't wait too long after deletion. But recovering accidentally deleted files from flash drives, SD cards, or SSDs in the same way seems impossible, even if I try to do it right after deletion. The recovery programs can see the files names and meta data, but the recovered files are gibberish. Opening them up in a hex editor shows random bytes. Why does this happen? Does flash storage do something weird with unallocated sectors or wear leveling that prevents standard data recovery programs from working? I thought that wear leveling, etc. happen only on write, so theoretically recovering deleted files should work in the same way. Anyone have any ideas?
|
#
?
Nov 10, 2014 18:53
|
|
|
|
| # ? Apr 19, 2024 01:26 |
|
|
Have you tried photorec/testdisk
|
|
#
?
Nov 10, 2014 19:02
|
|
|
Don Lapre posted:Have you tried photorec/testdisk Unfortunately yes, as I mentioned in the OP. Testdisk has the same behavior as Recuva (sees filenames and metadata, but recovered files are gibberish), and PhotoRec scans but doesn't find files.
|
|
#
?
Nov 10, 2014 19:07
|
|
|
sincx posted:Unfortunately yes, as I mentioned in the OP. Testdisk has the same behavior as Recuva (sees filenames and metadata, but recovered files are gibberish), and PhotoRec scans but doesn't find files. photorec always works for me with flash drives. Dont know why you are having an issue, maybe try a different machine? it may not get their file names back but the data is generally in great shape.
|
|
#
?
Nov 10, 2014 19:28
|
|
|
You can't recover data from SSDs because on most systems a TRIM command is sent to actually erase the flash blocks that previously held the file. The same thing does not happen on most USB drives or memory cards so you CAN recover the data unless it has been overwritten, just like a harddrive. Some tools/utilities are aware of this and will intentionally overwrite files when deleting them, however. Phones used as external storage will TRIM their own eMMC internal storage, but not any microSD card inserted. If some of the internal storage is mapped as /microsd it will get TRIMmed so data will not be recoverable after deletion. Edit: Actually some modern USB flash drive chipsets do support TRIM now, so I would say there's a good chance that data may not recoverable from USB 3.0 flash drives. Alereon fucked around with this message at 20:47 on Nov 10, 2014 |
|
#
?
Nov 10, 2014 20:45
|
|
|
I don't think TRIM usually actually deletes the data, as that would cause unnecessary excess wear, as minimal as it may be. The real problem is that TRIM marks blocks as empty, and that, combined with wear leveling, causes the mappings to get changed. The data you recover from what was the desired data's addresses is actually data from what is essentially other random locations that have been mapped in by the wear leveling mechanism. If you attempt the recovery quickly enough, your data is still likely on the drive, but it's randomly shuffled about in 512 byte or 4 KB chunks. You'd need either intimate knowledge of the drive's internal algorithms and state, or an incredible amount of luck, skill, and patience to find them all and piece them back together, if you can even reach all of the blocks as some of them might have been shuffled off into unaccessible reserve space. I believe there are some drives that will only return blank data on attempts to read TRIMed space before it's been written to again, as that is a sensible security feature, but if you're getting gibberish back instead of zeros it's almost certainly the previous explanation. XK fucked around with this message at 15:16 on Nov 11, 2014 |
|
#
?
Nov 11, 2014 15:08
|
|
|
From a data recovery perspective, TRIM and overwriting a file on flash memory are very similar: the mapping between the logical block and the physical flash page is broken, and the physical flash page is marked as garbage in the drive's page table. The difference is that in an overwrite a new mapping is immediately made to a clean flash page that is then written to, after a TRIM this doesn't happen until that logical block is next written to. At this point the original data is still sitting there in the flash page marked as garbage, but there's no way to ask the drive for it because there are no logical blocks mapped to that page.* Pages marked as garbage are periodically erased (garbage collected) when the drive has a chance, but this happens over seconds to minutes, so the data isn't sitting around hours later even if nothing else changed on the drive. Actually erasing the flash memory immediately doesn't shorten lifespan at all because at that point it unavoidably needs to be erased before it can be used again, doing it sooner rather than later just means you don't have to wait for that erase before you write data again. That's the performance benefit of TRIM, it lets the drive keep the free space actually free, in terms of erased physical flash. Drives without TRIM behave a lot like harddrives, in that deleting a file doesn't affect the mapping between the logical block and physical flash pages, the drive knows nothing about what you did with the Recycle Bin. Only when you go to overwrite the file does the drive go "oh well if he's overwriting it he must not need it anymore!" *This does mean that if you have low-level access to the flash or controller you could theoretically retrieve the data during the brief window between when it was marked as garbage but before the garbage was collected.
|
|
#
?
Nov 11, 2014 15:44
|
|
|
|
| # ? Apr 19, 2024 01:26 |
|
|
Presumably, one of the reason there were so many reports of deleted nude selfies being retrieved from cellphone memory, was because Android didn't operate TRIM at that time? It's a slight off-topic, but I guess now that it DOES support TRIM, this may be less of a problem. (Also, encryption is enable by default on Android 5, I believe)
|
|
#
?
Nov 12, 2014 12:34
|
|
