2

This comes from a long story of trying to recovering a TrueCrypt volume from a hardware failure (thanks, WD). I ended up with an unencrypted 3TB image that had the files that I want to recover.

Unfortunately, after using testdisk and extundelete, I guessed the directory entry that leads to the descriptors (of the additional directories) that I want to recover has been overwritten.

However, I think that its subdirectories may have their entries still intact. I would like to know how can I search throughout the disk image for directory entries in unallocated blocks, in order to recover their files (with their proper names, which would be much better than using foremost, photorec and the like).

I know that extundelete with a default --recover-all doesn't look further than the tree that spawns from the root directory. Okay, what if one of the branches is broken but I know that the subfolders entries are somewhere?

Just in case I didn't express myself clearly, imagine that the entry lost is [root]/information. The root directory has the 'information' entry, but it points to overwritten data. Its directory entry is gone, but I want to scan for its subdirectories, [root]/information/personal, and [root]/information/business, and so on. (the name of those subdirectories was in the 'information' entry- I don't care about that name but their whole structure)

Improve this question
6
  • 2
    A round of fsck should gather recoverable files in lost+found...
    – vonbrand
    Mar 4, 2014 at 0:40
  • Using e2fsck -f image.dd gave no bad blocks, 688092 inodes used, 593789 regular files, etc. Everything alright... because fsck doesn't care about deleted entries, right? Maybe I can try to manually set the 'information' entry in [root] as undeleted? (well, still its children will be marked as deleted, right?) Mmm....
    – huff
    Mar 4, 2014 at 0:52
  • 1
    If the file was correctly deleted, it won't be recovered. Only files that got disconnected illegaly will be recovered.
    – vonbrand
    Mar 4, 2014 at 2:06
  • Then you need to take a look at forensic tools. E.g. once I was able to recover most images from a thrashed disk, salvaging the hard-to-redo part of a colleague's presentation using a tool that just identified headers/footers of images, and copied out everything in between.
    – vonbrand
    Mar 4, 2014 at 2:09
  • Yeah, like the ones that I mentioned here, foremost or photorec perform file recovery based on header search. However, I would prefer a tool that does search for orphan directory entries instead of files, so I can recover the files in a better way.
    – huff
    Mar 4, 2014 at 2:18

1 Answer 1

Reset to default
0

or a method to do it manually/programmatically, I don't mind getting my hands dirty

You can do that with bash (dd,xxd,etc) or any programming language, if you are willing to learn how.

But if fsck did not pick it up the data is not likely there. (super blocks are more space constrained than data, and the tree is rebalanced often) so likely it's photorec or nothing, but you can seach with

strings back.img | grep thing

(aka if it were doable there would be a tool by now)

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.