Truecrypt hidden volume partitions lost with diskpart

Dear all,
I am now struggeling since last November with a lost Truecrypt volume and did not proceed working on a rescue since there just was not enough time up to now.

I recognized the (impressive) help given by dantz in another thread in this forum (https://www.wilderssecurity.com/showthread.php?t=327959) when I was searching for an ad-hoc solution for my problem. As it turns out, my problem is still not solved and the data is waiting to be recovered...

I'll try to give as much information right now..
- The accident happend while I accidentally "cleaned" the disk with diskpart while trying to format a bootable USB device. Initially selected the wrong device and here we go.
- I made a whole backup image with testdisk after I figured out that I could not restore the data (back in November).
- The hard drive has a "public" partition (FAT32 - 10GB) which was intended to serve as a temporary storage without any special things. After running testdisk, I could recover the public fat32 partition.
- There was a hidden volume/partition lying at the rest of the space (~920 GB, the fill harddrive has 930GB). After recovering the FAT32 partition, I can even mount the Truecrypt volume (Devices -> Auto-mount all device-hosted volumes) when selecting "Use backup header embedded" in the mount options. Without the option it does not work. (see attached image).
- I tried once to restore the backup header of the volume - this resulted in a un-mountable volume without further outcome and I had to restore the whole tables with testdisk.
- As the volume is mountable, I am right now trying to run PhotoRec on the mounted TC volume (no outcome up to now).
- I tested to copy the header block with WinHex as suggested in the other thread (link above) without success. The password always seems to be incorect no matter which offset I try. I have a licensed version of WinHex in place, so copying more than 200kB would be possible.

Initially I thought the lost data was not as important (mostly family pictures and media). However, after some months it turned out to be not as uncritical as I thought initially. Consequently I really want to try to recover the data (if possible)....

Help appreciated! Thanks and cheers,
Christoph

 

In DiskPart, which command did you use? "Clean" (zero fill of certain sectors only), or "Clean All" (total zero fill of the entire selected disk or partition)? I assume you either ran Clean, or stopped Clean All before it got to the end, otherwise your embedded backup headers probably wouldn't be working.

I see that you are able to mount your outer volume. Can you also mount your inner (hidden) volume? That's where all of your data is, right? If you are able to mount the hidden volume but you can't find any data in it then the first question is whether or not the hidden volume's contents are actually decrypting. (Sometimes they won't, usually due to using an incorrect header or having the header incorrectly located).

Mount the hidden volume using the embedded backup header, then use WinHex to examine the contents of the mounted volume. Look at the first few sectors. In the text column, are there any obvious words (such as "disk", "the", "read", "missing") or abbreviations (such as NTFS, FAT, NTLDR) or any other non-random patterns such as long strings of "dots" (which are displayed as 00 00 00 00 00 etc. in the hex column)? If you can see any non-random data at all then the decryption appears to be successful and you can move on to data-recovery.

If you don't see any of the above then perhaps that portion of the volume was overwritten, in which case you need to look further down the drive to see if you can find any decrypted data. Use WinHex to search the drive for long strings of zeros (in hex view). I find that ten zeros in a row is a good search string. A fully encrypted volume that isn't decrypting properly (due to incorrect header, wrong header location, etc.) will be totally filled with random data and will contain very few if any strings of zeros of that length, wheras a properly decrypting drive will typically have huge amounts of them. Do as follows:

In WinHex, click on "Search: Find Hex Values". Type ten zeros "0000000000" (with no spaces or quotation marks) into the search box. 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 you're probably looking at a large block of encrypted data. In this case, your headers are either the wrong ones, or they are wrongly located in relation to the data.

On the other hand, if WinHex quickly finds blocks of zeros, especially large blocks, then you have almost certainly found decrypted data, which shows that your header is fine and is working correctly.

You can press F3 to repeat the search farther down the volume if desired.

 

Hi dantz, thanks for the reply and your help! To answer your questions:

I used "Clean" for removal of the partition tables only (so no "Clean All").

Regarding the mount of outer/inner volumes I am really confused which one I was using all the time. I created the encrypted storages a few years back and used it mainly to store my media (family pictures) but I always used only one key which should be the one to mount the inner volume. As far as I know I never used the outer volume at all.
Consequently, the outer volume should not contain any data while all of it should be in the inner one (so "yes" to your question if all my data is stored in the inner one).

I checked the beginning of the mounted volume with respect to your keywords and also searched for big blocks of zero-data. For both I have to say that I could not find and positives there. So there are no human-readable blocks of text and also no long blocks of zeros (in fact I found one block which contained 10 zeros in a row, but I think that was a random case).

I would assume the data is not decrypted correctly, since the whole volume content looks perfectly random (in WinHex). I noticed just before that the partition recovered with Testdisk (the 10GB fat32 in the beginning of the harddisk) now spans the whole 930GB of the hard disk. I am not sure on this, however I think that it used to be a 10GB partition before my stupid diskpart "Clean" mistake...

 

According to the image you posted, you are mounting the outer (aka "normal") volume. (Look in the "Type" column). And you selected Partition 1 to do it. Did you always select Partition 1 in order to mount your volume, or did you previously (before the accident) use Partition 2?

When you have an inner ("hidden") volume stored inside an outer volume, there are usually two passwords involved, one for each. Are you sure you're providing the password for the inner volume? Because if that's where your data is stored, mounting the outer volume won't do you much good. And until you mount the correct volume, your data will merely look like a huge block of random data.

 

yeah, I am aware of the issues with the outer/inner volumes which is why I got really confused in the first place.

For mounting my target volume, I always used the "Auto-mount" functionality in Truecrypt without selecting any device or file.

The behaviour was the following: After I plugged the harddisk to the PC, LANALTOOLS (10GB Fat32) showed up right away. Then TC was opened, and the device mounted with the auto-mount functionality and the password I used all the time. In Win, there were then 2 additional disks visible in the explorer, but only one of them was usable with NTFS format (they both pointed to the same space afaik).

I am rather sure about the size of the old LANALTOOLS partition (FAT32, 10GB). I am really willing to try out different things, however for now I am still stuck without any usefull ideas to try out with the device..

I'll continue trying other passwords and so on...is there also a way to check where the backup header which was used for mounting is located? From your statements in other threads, it should be right at the end of the partitions?

Thx in advance, Chris

 

Ok, if you always used that password then you were apparently using the outer "normal" volume all the time. And yes, the embedded backup headers are located a specific distance back from the end of the partition.

The fact that your embedded backup header accepts your password and allows you to mount your volume proves that both the embedded backup header and the partition's endpoint are located correctly, so you don't have to mess with that at all. However, the fact that your data is apparently not decrypting implies that the beginning of your partition is located incorrectly. Apparently you lost the partition table in the accident, and when you got things working again the beginning of the partition ended up in the wrong spot.

According to the images you posted, the original size of your mounted outer ("normal") volume was 989,712,875,520 bytes (which is approximately 921 GB). If we add 262,144 bytes to account for the 4 headers that surround every TrueCrypt outer volume then we can deduce that the original size of your encrypted partition was exactly 989,713,137,664 bytes.

To locate the original starting offset of your partition, try this:
1. Dismount the TrueCrypt volume if it is currently mounted
2. Open WinHex
3. Tools: Open Disk:
4. Under "Logical drive letters", select and open the encrypted partition
5. Click once in the hex display column (may not be necessary, but can't hurt)
6. Press Ctrl+End to move your pointer to the very end of the partition
(You are probably now in hexadecimal mode, as WinHex switches to this mode automatically when the decimal numbers get too large. If you're not in hexadecimal mode then click once in the offset column to toggle into it. We will convert the numbers as needed.)
7. Tools: Hex Converter: paste or type 989,713,137,664 into the decimal (right-hand) box and press Enter
The Hexadecimal (left-hand) box should now display E66F800000
8. Copy that number (select it, then press Ctrl+C)
9. Position: Go to Offset: New Position: paste in or type E66F800000. Make sure the button says "Bytes (hexadec)"
10. Change the "Relative to" setting to "end (back from)"
11. Click OK
12. You should now be located one byte prior to the original beginning of the partition. Move your pointer forward one byte. It should now be in the "0" column, just below the sector boundary. If all went properly, this should be the original starting offset of the encrypted partition, plus the first byte of the original volume header. Write this location down. (Note the "Offset" indicator at the bottom of the display)

13. Try creating a TrueCrypt test file (as described in the other thread) that begins at this location and then see if you can mount it in TrueCrypt, just to see if your original volume header is located here and is still intact.

It would be great if the test file was mountable, but if the header was overwritten during the accident then it might not work. It's also possible that we are in the wrong location due to some sort of a minor error. We'll see.

 

I tried to do your approach, however when I open the partition in WinHex, it only appears as a 10GB partition (see screenshot). As I obviously could not navigate back 921GB from a 10GB partition I instead did the following
1) Opened the whole disk in WinHex
2) Searched the beginning of the first partition (the string "MSDOS5.0" at the beginning of the partition did the job for the disk search) (screenshot attached)
3) Added the offset 10485760000 (size of whole partition) from the beginning of the FAT32 partition (screenshot)
4) Consequently I found the offset to the beginning of the TC partition to be 10486808576 bytes (screenshot)
5) I copied 400kB of test data starting there and was able to successfully mount the test.tc file with truecrypt - I think that is good news so far.

I then thought a possible way to go would be to just recreate a partition with testdisk and/or shrink the FAT32 partition (in the table) to the correct size (2048 to 20479999 sectors in EFI GPT table). However, as I was struggeling if I should create a new partition after the FAT32 one, I decided not to touch the partition tables as long as there is no confirmation from your side.

I went back and noticed that you mentioned in the other thread that saving the whole truecrypt space as a winHex block to a new file would be a possible recovery strategy as well. As I anyhow want to replace the TC volume (because of the obvious risks and the non-confidentiality of my data) I am for now copying the TC block of data to a backup disk. I used as borders the start-offset 10486808576 and for the end startoffset + 989713137664-1(size given by you - TC and headers). This is still ongoing for pretty much the whole day...

 

I read your latest post and I thought it over for awhile, but I can see that it's going to require some serious study before I can make a positive contribution.

However, I'm right in the middle of preparing to leave on a short trip, so unfortunately I can't spend that kind of time on your problem right now. Good luck with your plan to save the entire block as a file! It stands a good chance of success.

However, before saving the entire huge partition as a file I would try saving a reasonably-sized sample (maybe 50 to 100 MB or so), then I would use TrueCrypt to mount the sample file and examine the mounted volume with WinHex in order to look for decrypted data. (Search for recognizable text, blocks of zeros, etc.) If it's fully random clear to the end then it might be time to rethink things.

I'll be back in about 2 weeks and will rejoin the thread then. In the meantime, good luck!

 

Dantz, thank you very much! Long story short - the backup strategy with copying all content to a backup-container did the job. I got full access to all data without any data loss, basically everything I wanted to have.

Without your input I certainly would have given up on the data! This is perfect for now...I wish all the best and a good trip

 

Fabulous news! Congratulations.