Recover truecrypt container after chkdsk

Sorry about that. I didn't realize that the evaluation version of WinHex would pop up notices during a long search. I've owned a licensed copy for a long time, and I have renewed it several times. You can try using a different hex editor if you don't want to purchase WinHex. I've played around HxD, which is a decent freeware hex editor, and I think it can do this, or at least, most of it. It's not nearly as full-featured as WinHex, and the menus are rather different, so you'll have to figure it out.

You don't need to worry about interrupting or restarting the search if you think you began it in the wrong place. I often stop a search and then restart it elsewhere. No point in wasting time searching the wrong area! You can also try manually scrolling through the "suspected" transition point to see if you can spot it visually, then use Search to fine-tune your position.

 

I stick for the searches to that program, cause i found "plenty of plain" text and I want to go onward now. The text consists of foldernames; it shows the path of the folders within the container. The search stopps every now and then and i do "define block" (20k), "into new file", close Tab and WinHex, TC open file, password, error msg, reopen Winhex, search starting point, start search several ... times. Search starts at ~97% but the small window fades too fast away while the next search results is found right after and sometimes the zeros are really only 00 00 00 00 00 long.

How many zeros/lanes with zeros will I look at when I see the right starting point?

Thanks for the new programs name. I will have a look at when I have the time and when it comes to the time I have to restore the container files cause WinHex "noticed" me that i only can "backup" up to 200KB files at once with the evaluation copy.


== update ==
I found as plain text the foldername where the TC Filecontainer should be inside. But the name of the Filecontainer isn't around.

 

I just stepped in to tell: nothing changed. I'm still searching.

 

Hang on, I have to go now, but I'll be back in a few hours with some more tips. It sounds to me like you're working too hard.

 

I'll be here listening. I should program my mouse and keyboard to hit the right keys and pixels for the search routines.

 

I'm too busy to respond right now, sorry. I'll try to catch up later.

 

All I can suggest at this point is to keep on looking. It shouldn't be that hard to find the approximate starting point of a huge block of random data, but it might be hard to "fine tune" your position to locate the exact starting point of your lost file, as the file might just happen to be adjacent to other random-looking data data, which would visually obscure the precise starting point.

Are you sure that your technique is correct? Have you practiced and successfully located a "lost" TrueCrypt file on another disk that you set up just for practice? Were you able to visually spot the transition points between the non-random "plaintext" data that (usually) precedes a file, and the large block of random data that the file consists of? And can you see another transition point directly after the file, where the data becomes non-random again? (For example, seeing some strings of zeros?) The transitions aren't always visible, but it's very helpful when they are. Anyway, at this point I would focus on doing more practice runs until you're sure that you're doing it right.

And for your information, all you need to see is a string of four or five bytes of zeros (hex) in a row to know that you're probably viewing plaintext (non-random) data. Strings of zeros, even relatively short ones, are very uncommon in random data, and they also happen to be very common in plaintext, so this makes them a very useful indicator for us.

For our purposes 4 bytes of zeros ("00 00 00 00") is usually enough, although 5 bytes ("00 00 00 00 00") is better. I prefer to use five bytes in my WinHex searches because a typical encrypted volume will usually contain one or more 4-byte strings of zeros. Of course, they will not have any "friends", and it should be quite obvious in that case that they're just a random occurrence and are not indicative of plaintext. Even 5-byte random strings of zeros will occasionally occur in a typical TC volume, but not very often.

Another approach you might consider is to look for the file's endpoint. It should be easy to find this near the end of the drive, and you can try to locate the embedded backup headers instead. The problem with this approach is that finding the endpoint won't be that useful in helping you find the beginning, since the file is almost certainly fragmented, since it is interrupted in several places by the MFT and other file system structures, so we can't just count backwards a specific distance from the end of the file in order to find the beginning.

There are also programs that can walk the drive and look for the lost header programatically, although I can't actually name any of them. You might need to resort to something like that.