Incorrect password or not a TrueCrypt volume after installing Linux as dual boot

Okay so, I will start from the beginning. My hard drive has been split into 2 partitions since I got it, C: (system) and D: (about 150 GB each). I used TrueCrypt to encrypt the secondary partition (D: ). Unfortunately I didn't create a Rescue Disk. After formatting C: and reinstalling Windows, my encrypted D: drive became inaccessible via TrueCrypt. I found a solution to tick "Use backup header embedded in volume if available" and "Mount partition using system encryption without pre-boot authentication" before mounting and it worked fine.

I always wanted to install Linux as a secondary OS, so I finally decided to do it. In order to secure a partition for my Linux Xubuntu, I decided to take a chunk of my C: partition. So I've shrank my C: partition to 100 GB and created another one for Linux, about 50 GB (not sure which application I used, but I certainly did it inside Windows environment).

I then proceeded to install Linux Xubuntu on my new 50 GB partition, being careful not to accidentally format the encrypted secondary partition or the Windows system partition. After installing TrueCrypt on my new Xubuntu, it wouldn't mount the encrypted volume: "Incorrect password or not a TrueCrypt volume". I thought it might be because I'm trying from Linux but it would pop-up the same error from Windows too now.

I tried researching the internet (this forum too), tried a few things, but I'm too scared to make it worse by experimenting further. I would appreciate it if you can tell me where did I mess up and if there's any way to recover my encrypted volume.

My suspicions are:
- I messed it up somehow when I created the third partition (splitting the original C: into 100 GB and 50 GB partitions),
- Linux installation messed it up somehow (formatting in the installation process, or GRUB maybe?),
- Trying to mount it from Linux messed it up somehow.

Thank you very much!

tl;dr My TrueCrypt encrypted drive became inaccessible after splitting a non-encrypted partition into two and installing Linux as dual-boot on a new partition.

 

Did you use TrueCrypt to encrypt the operating system on drive C? From your description it doesn't sound like it, and thus a TC Rescue Disk would not be called for.

If you merely encrypted partition D, and then you reinstalled Windows in Partition C, then Windows would naturally overwrite the volume header of your TrueCrypt volume in Partition D. This happens all the time. You're not supposed to do that sort of thing without taking extra precautions. But luckily for you, your embedded backup header was still ok.

Installing Windows while an encrypted partition was present was your first mistake, but then you committed an even worse mistake: You repartitioned your disk in the presence of a TrueCrypt-encrypted partition. This is an extremely dangerous thing to do, as none of the partitioning software, or even Windows itself, is able to recognize a TrueCrypt partition for what it is. The software merely sees an unused (and apparently damaged, from its point of view) partition and it assumes that the space is up for grabs. And unfortunately, TrueCrypt partitions are extremely brittle and cannot tolerate any changes to their partition boundaries. As soon as you change the boundaries or move the data, they break.

Since you are apparently no longer able to mount the volume using the embedded backup header, we can assume that either:
1. the embedded backup header near the end of the partition was overwritten or damaged, or
2. the partition's endpoint was changed (which is more likely).

You might be able to recover your volume if you can find the original starting and ending offsets of the lost encrypted partition. You will probably have to go in with a hex editor to look for the endpoints manually.

There are also certain specialized programs that can sometimes help you find lost TrueCrypt headers (when you get the search area narrowed down enough), but they require a fair bit of technical expertise to set up.

I'll briefly outline the strategy that I would begin with, but I'm not going to put down step-by-step instructions, as it would take many pages and we don't even know your full situation yet:

I would start by making a full, sector-by-sector backup copy of the disk, for backup purposes.

Then I would examine the disk (either the original or the backup, but not both) with a hex editor such as WinHex (in read-only mode).

I would start by looking at (or near) the third partition to see if I could clearly identify the endpoints of the very large block of random data that used to be your TrueCrypt volume. The ending offset of the lost partition would probably be the best bet, as this is probably the least messed-up area of the disk. It would probably not be located at the exact end of the current partition, otherwise your embedded backup header would already be functional.

Then I would try to find and recover the embedded backup header.

If I found the embedded backup header and was able to test-mount it then I would use it to calculate the starting offset of the lost partition by mounting the volume and viewing the volume size in bytes (under TC volume properties).

Then I would use a hex editor to select and save the entire lost partition as a file, according to its calculated offsets, and then I would mount the file in TrueCrypt to try to recover whatever data I could. The volume's file system might be broken, so at this point data-recovery software might be needed.

And I hate to say it, but the bottom line is that none of these efforts are guaranteed to succeed. It seems that you have already lost your volume header, and if the embedded backup header was also overwritten then there will be no hope at all (unless you have a header backup somewhere). The only way to find out will be to dive in and try some of this stuff.

So as you can see, the recovery effort will be a highly technical undertaking.

edit: fixed typo

 

Thank you very much for your reply.

I was busy these days, but I finally started experimenting with WinHex. Currently I'm trying to find my header, as you advised. I looked up some of your other posts on this forum to try to find a guide.

Does this screenshot (link: http://i.imgur.com/6PydR6H.png) tell you anything? Are the zeroes before the encrypted partition start a good sign? Also, could these "Unpartitioned space", two "Partition gap" and "Unpartitionable space" be the reason why my encrypted partition got messed up? Sorry, I wasn't very familiar with data storage technicalities before this, I'm trying to learn as much as possible now.

What I've tried:

I created a .tc file from the F: (truecrypt partition) start and added 20000 as the end point. I tried to mount the file but the same "Incorrect password or not a Truecrypt volume" error popped up.

I tried to mount the ~20 kB .tc file again with ticked "Use backup header embedded in volume if available" and "Mount partition using system encryption without pre-boot authentication", no error showed, but literally nothing mounted, as if nothing even happened.

Did my new information give you any more new insight? I'm planning to experiment more as soon as I have more free time.

Regards,

EDIT: Disk Management screenshot (hopefully it gives you more insight): http://i.imgur.com/a63MQuJ.png *the smallest partition is now NTFS since I got rid of Linux ext4

I couldn't leave it for today, so I made my 2nd attempt based on one of your posts on the forum:

I double clicked my encrypted partition (Partition 4 F:, from the first screenshot of this post) and did the quoted steps.

When I got to the the position (131071 Bytes relative to end) I selected the next 512 bytes (block) and saved it into a new test .tc file. (just a side note, random hex data goes until the very end)

I tried to mount it with TrueCrypt and got the following error:
"Incorrect volume size." Screenshot: http://i.imgur.com/70m1mKa.png

I thought this was a good sign. I tried typing a wrong password on purpose and it showed the same error.

 

I will try to respond soon, but I'm trying to catch up on other projects right now.

 

Of course, no problem, just take your time.

 

The test file needs to be large enough to exceed the minimum allowable size, otherwise TrueCrypt will display that error. I haven't measured the exact minimum, but it's somewhere around 16KB. I usually make my test files 20KB or larger. 200KB is even better, as this will be large enough to include both 64KB headers plus some user data from the beginning of the lost volume (if it mounts, that is).

 

Well time to be honest. I just messed up my TrueCrypt headers/bootloader stuff while screwing around with Linux and Grub on my machine. It sounds very much like what you are going through, so let me tell you what happened and how I fixed my screw up. It doesn't sound like you have a rescue disk so this may just be a learning post.

I have TC both decoy and hidden + I have lvm encrypted linux all on the same machine. I was updating my linux version and thought I handled the grub correctly, but apparently I didn't because it wrecked my TC OS's (they wouldn't mount at all). What gives?

I mounted my machine in RAM using a partition tool to see what was going on. Nothing showed up in that tool as obvious with partition structure. Hmmmm.

I grabbed my rescue disk thinking that the bootloader was damaged and surely restoring the bootloader would make all well. Nope. The bootloader now came up normally and asked for a password but entering it meant nothing. Next I put in my rescue disk (bootable flash) and attempted to open the hidden OS reasoning that grub at the front of the drive wouldn't go back to the second partition. Nope.

Then I remembered that the rescue disk also contains the entire header data. Just maybe? I restored the key header data hoping that would do the trick. Yep, both OS's come up with their respective passwords. Nice. Linux is coming up fine too.

Lesson learned for me is the rescue disk header data is worth gold.

Your issues are scary close to what I had happen on this end. It happens. I have been using this product as a semi-Pro for years now and you just never know when you will make a mistake.