(help) multi boot disaster with true crypt thanks to pinguy

I ran a triple boot OS

1. Windows 7 system encrypted with pre boot auth

2. Windows 7 non encrypted

3. Pinguy linux os

All were working well....

Recently I updated the pinguy os, after the update, everytime I chose windows 7 on the boot menu, , windows always failed to start, with the msg "error 0xc000000f"

So I used the windows recovery console to fix the boot into the unencrypted partition of windows 7

It worked, then I tried to use easy bcd to fix all the boot entries of all my os

Since the other win 7 is system encrypted with pre boot auth, I tried to mount the partition using true crypt from the unencrypted win 7 partition, I chose the option to bypass the pre boot auth when mounting it

But it always fails, with the msg "incorrect password or not a true crypt volume", eventhough the password I put in is the correct one

No rescue cd, and yes, my keyboard is us eng


Is there still a hope left for me ?





Thanks

 

I don't know what boot manager you are using, if any. I would try booting up the computer using a CD-Rom with PLoP Boot Manager.

 

Can plop boot true crypt encrypted partition ?

 

Its a boot manager, if your original Windows/Grub boot loader has been damaged PLoP will replace it with its own (booting from the live CD), it doesn't matter that the partition is encrypted, after booting you will be asked to enter your Truecrypt password as usual.

If what has been damaged is Truecrypt partition or Truecrypt bootloader then it won't work. It is also a good idea to have a dedicated boot manager when you run multiple OS in your computer, I think that Plop can be permanently installed in your hard drive.

 

You should first Restore the volume header on the encrypted partition (from the TC Tools menu), then try to mount it. All this can be done from your unencrypted working Win 7. TC saves a backup volume header at the end of the partition, this backup header is often intact.

 

Tried to boot the encrypted partition using plop, it gaves a Black Screen Of Death

I tried to restore the volume header from the backup embedded in the volume, it asked for password, I entered the correct password, and it gave the msg "incorrect pass or no true crypt volume found" again

That means I'm doomed ?

 

Make sure you are doing Restore on the encrypted volume/partition (TC do not know the difference between an unencrypted and encrypted partition, so you will get the same error even if you tried on an unencrypted partition), but if you tried on the correct partition, with the correct password, and still get that error, you are doomed. Normally the backup header is intact if you only did a "boot recovery".

 

Yes it is the correct partition, the size of each partitions is different

Oh well, this will be the last time I do a system partition encryption, it's safer to use encryption on non bootable data only partition......sigh......

 

Sorry, this advice is incorrect. System-encrypted volumes don't have embedded backup headers. If damaged, the key data (the volume header) can be restored from the TC rescue disk, but you stated earlier that you don't have one.

 

Ok, that's why it did not work for UltraPaleskin. The Restore-volume-header has always worked for me, but I have only tried it on normal TC partitions.

 

@dantz, so there is no other way to mount the system encrypted partition and extract my data ?

If there is none, I'll format the partition.........

 

It depends on what's actually going on. The 512-byte header (which looks completely random from beginning to end) is normally located in the 63rd sector of Track 0, but I'm not sure if the location would be the same in a triple-boot system. If your header has been overwritten and you don't have the ability to restore it from the rescue disk or from a backup image then yes, you're completely screwed. On the other hand, since your system is set up in a non-standard manner, it's possible that TC merely isn't able to find the intact header in the expected location when you try to mount the system partition via the "mount without preboot authentication" command, in which case you would see the same error message as you would if the header had been damaged or overwritten.

I'll say this, you have certainly done a lot of mucking around. My off-the-cuff guess is that your header has probably been fried. Running the Windows Recovery console to fix the boot and using EasyBCD to modify the boot entries are both very inappropriate operations to perform on an encrypted system partition. Performing these actions without having either a backup image or a TC rescue disk is a recipe for disaster.

Unless you are both skilled and desperate and are willing to set up a duplicate of your triple-boot system for testing purposes on the off-chance that the header might still exist somewhere and is recoverable, I'd give up now. Sorry.