Truecrypt container recovered, no longer mounts. Have older working backup

I've accidentally deleted a truecrypt container but was able to recover using Recuva. However the container no longer mounts. From researching past posts on this forum I'm thinking the volume header got corrupted?? In any case, I have a 3 month old backup up the same container. The files in my backup copy are different, not having the most latest/recent. Is it possible to somehow restore the volume header of my recovered truecrypt container using my working backup? I looked into creating a backup of the volume header from the working copy but the process seems to involve re-encryption....therefore I am not certain if it will work with my recovered container. Please help.

 

More likely the volume header got truncated or deleted due to an incomplete recovery of the deleted file. Have you tried mounting the volume using the embedded backup header? That might still work. However, if the recovered file is not exactly the same size as the original then you could get an unexpected outcome: The password will be accepted and the volume will mount to a drive letter and will appear to be ok, but the contents will not decrypt (as seen if Windows offers to format the volume. If you're asked, don't format!)

Note: Don't restore the volume header from the embedded backup header, merely try using it to mount the volume. ("Mount Options: Use backup header embedded in volume if available"). And make sure you have a backup copy of the recovered container file before you try anything! It's possible to make the situation worse by writing the wrong thing to the file.

Yes, it's very easy to do and it's worth a try, if your backup file is actually a true copy of the original container file. (It can be an older copy, no problem). In that case the volume headers will be identical, and you can copy the header from your backup and use it to restore the (allegedly) damaged one on your recovered file. This might work, depending on the circumstances, but to play it safe I would try this only on a copy of the container.

In TC, choose "Select File" and select your backup copy. Then use "Volume Tools: Backup Volume Header" to make a backup copy of the header. The result is a small file.

Then, use "Select File" again to select a test copy (hopefully not your only copy) of your recovered file. Use "Restore Volume header from an external backup file" and follow the prompts to restore that header onto your recovered file.

It will probably mount to a drive letter, but the real test will be to see if it decrypts. If Windows complains and offers to format the volume when you try to view it in Explorer then you've got additional problems that will require further work.

 

Thanks for the response dantz.

I was able to backup the vol header from my working backup copy and restore it to the recovered copy. It work and TC mounted the container but, as u suspected would happen, windows is prompting to format the mounted drive. =/

Any further help would be great.

 

It sounds as though your recovered file may be the wrong size. Try this:

Open TC and mount the volume, then click on Volume Properties (in the TC interface) and note the volume's Size in bytes. This data, which is stored in the TC header, represents the exact size of your original, functioning TC volume (the backup copy, that is). Add 262,144 to that number to account for the four 64KB headers that wrap the volume, and then compare your result to the size (in bytes) of your recovered file (as shown in Windows when you right-click on the filename and choose Properties).

 

The file size of the working backup copy via TC Volume Properties is 1079479680 bytes. Add 262,144 => 1073741824 which is the exact same size in bytes as my recovered file via windows rt-click->properties.

 

Hopefully you did this on a separate copy of the recovered file, not your only copy.

Just for the record, did you try using the embedded backup header first?

I'm surprised that your recovered volume is the correct size and yet Windows thinks it's unformatted. Are you sure that your backup volume was a direct copy of the original? Not a container that you created separately?

PS: The file size you posted contains a typo, should be 1079741824, right?

The next step will be to examine the mounted volume using WinHex to see if your data is decrypting or not. I don't have time right now, so I'll post the technique tomorrow.

 

Yes, I have 4 copies of the recovered file. =)

I did try to use the embedded backup header first without any luck. TC continues to prompt with message: "Incorrect password or not a TrueCrypt volume."

I am absolutely positive that the backup volume was a direct copy of the original. It was a copy stored on my backup hdd in which I usually re-copy over (backup if you will) at frequent times. It just so happens that this last back up was 3 months old.

Typo indeed. Good catch. It should have read: 1073479680 bytes + 262,144 => 1073741824

Thanks again for your responses. I hope to be able to recover this file.

 

It's time to inspect your mounted volume more closely to see if we can figure out what's going on. A hex editor such as WinHex will be a good tool for this job. You can download a free evaluation copy from the site. (I have a paid version, of course, as I find it to be extremely useful.)

The first goal is to see if you can locate any unencrypted data, as this will indicate that your volume is most likely decrypting properly. (Decryption in this type of situation is generally all or none.) Instructions follow:

1. Use TrueCrypt to mount your recovered volume to a drive letter

2. Open WinHex

3. In WinHex, select "Tools: Open Disk", select the Logical drive letter that you mounted your volume to, and click "OK"

WinHex displays the contents of your volume using a combined hex/text view. The larger main column shows the row-by-row contents of your file as hex. The right-hand column interprets each row of hex and displays it as text, which is generally easier to recognize.

4. Look in the right-hand (text) column and see if you can find any recognizable words such as "NTFS" or "NTLDR" or "disk read error" or any obvious patterns such as "..........". Scroll down a bit (or press PgDn repeatedly) and keep looking. It will mostly be unreadable, but there should be some occasional words or patterns in there. (To get a larger view of the text column, click on View: Text Display Only" or press "F7").

If all you can find is large amounts of unintelligible, random looking data then continue on to the next step:

5. Make sure the hex column is visible. If you previously pressed F7 to view text only, then press it again to resume viewing both columns. Also, scroll back up to the top, or press Ctrl+Home.

6. Click on "Search: Find Hex Values"

7. Type ten zeros "0000000000" (with no spaces or quotation marks) into the search box. (If WinHex locates that pattern then it will display as "00 00 00 00 00", although it usually be much longer than that). This pattern is extremely common in ordinary plaintext but is rarely found in encrypted data, so I find it to be a convenient, "quick and dirty" way to search for plaintext. There are more accurate ways, of course, but this method usually works.

8. Set Search: Down, then click on "OK" and let it run.

If it runs for a long time and doesn't seem to find anything, then WinHex is probably searching through a very large block of encrypted data, which is a bad sign. You can let it run for awhile if you like, but in my experience the plaintext either shows up right away (and often in the first few sectors), or not at all. If you can't find any plaintext in the volume then your headers are either the wrong ones, or they are wrongly located in relation to the data that they are designed to decrypt.

On the other hand, if WinHex quickly finds one or more blocks of zeros, especially very large blocks, then you have almost certainly found decrypted data, which shows that your header is fine and is working correctly. At this point the job becomes one of data recovery, and there are several progams you can try. I've had good luck with GetDataBack (if the file system is still partially intact) and PhotoRec (if it isn't). You could even try Recuva to see what it might find. Of course, these programs must be used to explore the mounted volume, not the unmounted container file.

(I can't guarantee that the above steps are 100% accurate, but I think they're pretty close and should suffice. Let me know if anything doesn't seem to be working as expected. Good luck!)

 

I followed your instructions exactly. Mounted the recovered TC container to a drive letter (T: ) in this case. Used WinHex and opened disk of the mounted drive letter. The first thing Winhex prompted was: "The volume does not contain a recognized file system. Please make sure that all required file system drivers are loaded and the the volume is not corrupted."

I proceed and in looking on the right-hand column, did not recognize anything that are actual words or any obvious patterns. I then searched the hex values for ten zeros and with the search set to Down. Winhex took a few seconds indicating progress as it chugged along. The results came up negative. "0000000000" was not found.

So..I take it that this means I'm out of luck with this recovery effort. Funny thing is, in looking at the time stamp and size of the recovered file, it is all identical to my working backup copy. I would think that this is
a fully recovered file. But then again, my knowledge when it comes to this topic is limited. Welp, it was worth a try though. Thank you dantz for all your help. Really appreciate it.

If you think of any other suggestions or methods I could try please let me know.

 

It's very strange that your recovered file was exactly the same size as your original, and yet neither the volume header nor the embedded backup header were functional when you recovered the file. This would imply that either the file's contents or its location changed during the act of deleting the file, and yet you were able to recover the whole thing intact.

I think there's more to the story than what you have posted thus far. I could make educated guesses, but I'd rather let you post the additional details if you wish.

RE our results after restoring the backup headers from your backup file: Be aware that you can restore a set of TrueCrypt headers onto any file whatsover, including an unencrypted file of any type, and end up with an identical outcome. The volume will appear to mount, but its contents will be completely random. This is because TC volume headers are able to decrypt only the file that they were created on (or a copy of that file).