Noob question here. I'm trying to recover a truecrypt container inside a truecrypt encrypted HDD. The OS, Win7, is on another drive.

I've mirrored the truecrypt drive and I'm working on it. Getting ready to use hexeditor on it. I assume I should make it read-only, but should I bother disabling windows search index if the Win7 is on another drive? Is there anything else I should do before I start figuring out how to try to find the header that contains the password?

I don't understand most of this. Are you saying you have a truecrypt encrypted HDD that you have decrypted and mounted and you are now trying to locate a truecrypt container file somewhere in the filesystem?

What has windows indexing got to do with anything?

What do you think you are going to achieve by using a hex editor? You are aware that the header of truecrypt containers are encrypted too....

I don't understand most of this. Are you saying you have a truecrypt encrypted HDD that you have decrypted and mounted and you are now trying to locate a truecrypt container file somewhere in the filesystem?

What has windows indexing got to do with anything?

What do you think you are going to achieve by using a hex editor? You are aware that the header of truecrypt containers are encrypted too....

I haven't decrypted the HDD, but I can access it with my password. I used winhex a few months ago to read it, and it saw two huge chunks of unused space that I assume are my two truecrypt containers. They were 75gb or so, and I had a bit of activity for a small amount of time after the accidental deletion, so this increases the chances that my endeavour will fail.

I'm trying to recover any one of those two truecrypt containers.

I hope to carve the file out with winhex, am I being too hopeful? I also don't know if it's right to assume that the headers will be sitting at the beginning of this 'empty' space that I saw in winhex a few months ago. It's NTFS. The space isn't empty of course though, it just showed on winhex as not having any current files on it but not being totally empty, so I assume this could be my hope.

I'm also not sure if these two containers are exact copies or if they were different containers to begin with, but I do know that they contained the same data. So trying to find the header by looking for exact copies of the headers in these two spaces may or may not work.

Disabling Windows indexing, like enabling read-only, is what I assume are the steps I should take before I do this properly. But of course this being a secondary drive in which the OS is not stored, maybe disabling indexing doesn't help at all? What do you think of all this?

Btw, this is a mirror image of the drive where the deletion happened, just in case I commit an error in the recovery.

What do you mean by accessing it with your password? Doesn't that decrypt the HDD?

What exactly is it that is encrypted and that you are trying to recover?

Truecrypt can encrypt:
1. The whole HDD
2. A single partition on the HDD
3. A container file that resides on a filesystem

Your original posting implied that you were looking for an encrypted container (type 3 above) within an encrypted HDD (Type 1 or 2 above). It also implied that you could decrypt the HDD and were searching the decrypted HDD looking for the (deleted?) truecrypt container.

The problem you will have trying to recover a deleted truecrypt container within a encrypted HDD is that the previously unused areas will be random data. The truecrypt container is designed to look like random data. Therefore it will be difficult to find the start and the end of the container.

If you were trying to recover an encrypted container from an unencrypted HDD it would be easier as previously unused areas would simply be 0x00s (zeros). The truecrypt container would therefore stand out as random data sat in amongst zeros.

Truecrypt headers are not like regular headers, they are encrypted and can only be read by truecrypt when decrypted with the correct password.

I can access the truecrypt encrypted HDD with my password, so I think we can assume its decrypted in a sense. The problem are these two big containers I deleted accidentally, they're inside this drive. There really isn't much free space on the HDD, so on Winhex in the 'allocation of visible drive space' there are two big clusters that seem to stand out a lot, as they are the only ones that are described as free space. Would it be correct to assume that the beginning of these two big ''free spaces'' might be the ones that contain my header, that is if I didn't overwrite them before I mirrored the drive? Indeed they don't show up as zeros on winhex but as random data, and yet winhex describes it as free space.

1) You had full-disk encryption enabled with TrueCrypt.
2) You can access the drive with your password so you are able to decrypt it.
3) On that same drive, you also had two TrueCrypt containers that were separately encrypted.
4) The containers were deleted by accident.

There is a possibility that you can recover the containers but I'm skeptical. Since the containers were large, it's very likely that they were fragmented. If you're not successful in recovering even a part of the container, that could prevent you from recovering the rest. If you miss part of it, carve certain blocks out of the order they were originally in, or include blocks that were not part of the original file, the attempt will probably fail. I've used TrueCrypt but I have never attempted to recover a delete container so I don't know if there is any unencrypted information that will help you (e.g. a standard header/footer for all .tc files).

I don't know if the indexing matters. I'd be more concerned about accidentally writing anything else on the drive you're trying to recover from.

There is a possibility that you can recover the containers but I'm skeptical. Since the containers were large, it's very likely that they were fragmented. If you're not successful in recovering even a part of the container, that could prevent you from recovering the rest. If you miss part of it, carve certain blocks out of the order they were originally in, or include blocks that were not part of the original file, the attempt will probably fail. I've used TrueCrypt but I have never attempted to recover a delete container so I don't know if there is any unencrypted information that will help you (e.g. a standard header/footer for all .tc files).

Is there any reason to assume that on winhex when you have a suspiciously big chunk of ''free space'' as it says, that the truecrypt headers won't be stored at the beginning of that free space and that carving isn't as easy as selecting that free space on winhex from beginning to end? Are you saying that 'free space' can have the headers anywhere and that the blocks it shows aren't in order somehow? I've never carved out anything before and haven't a clue how it's done.

- tracedf

I don't know if the indexing matters. I'd be more concerned about accidentally writing anything else on the drive you're trying to recover from.