Something's really NOT right in Truecypt's hidden OS feature

Truecrypt's website claims the following:

Which implies that a hidden OS partition should be indistinguishable from a standard encrypted OS partition; i.e. there should be no "flags" telling the bootloader that it is booting into a hidden OS rather than a normal encrypted OS. Futhermore, the hidden OS partition is supposedly a clone of the system partition, which, if that's indeed the case, further implies that the bootloader not only has no indication that it is booting a hidden system partition, but that it actually thinks it is booting the standard system partition.


Now, if this is truly the case, the following should work:
1. Encrypt the system partition using the standard method
2. Create a partition directly after the system partition, encrypt it with Truecrypt.
3. Create a hidden volume in the partition identical in size to the system partition.
4. Mount the new hidden volume and manually clone the system drive to it.
5. Reboot, and enter the hidden volume password.

This process should create a hidden operating system which should successfully boot when the hidden volume password is entered. The problem, as you've no doubt guessed, is that it doesn't, and instead gives a rather puzzling "incorrect password" error, even though the volume mounts correctly when the same password is entered from Windows.

This is major, because it means that the claims the development team made are false; there must be something telling the Truecrypt bootloader that a hidden OS is present or not, and if it doesn't "expect" one to be present, it doesn't even attempt to boot it.

If, as the developers claimed, it simply attempted to mount the hidden partition, and if successful attempted to boot from it, then there is no reason why the hidden system wouldn't boot after following the above instructions. Even if the cloning process somehow corrupted a system file or was not done correctly, it should attempt to boot and give a BSOD. Heck, even if the hidden partition was empty it should still mount successfully and subsequently hang on an "operating system not found" error when it tries to boot and finds no MBR.

Yet that is not what happens, instead I get an "incorrect password" error when I enter the correct password for the hidden partition. This means the bootloader isn't even trying to mount that partition and is simply rejecting the password after trying to mount the main system drive. Somehow, the bootloader knows that I haven't "officially" created a hidden OS, and so doesn't bother attempting to mount the hidden partition, even with the correct password.


I find this extremely worrying, and was wondering if anyone had any thoughts or could help shed some light on what's actually going on, as opposed to what the documentation claims is happening.

Feel free to replicate the results I got yourself using the instructions I've listed above.
I'm going to look into things some more, but I'm not liking this at all.

 

My guess is that the hidden header's system volume flag doesn't get set when you create the hidden volume manually.

 

For step 2, "encrypt it with Truecrypt," did you use the Windows GUI to encrypt the partition using "Encrypt a non-system partition/drive?"

System encryption and non-system encryption in TrueCrypt are different and one method cannot decrypt the other. Non-system encryption can use RipeMD160 with 2000 iterations, SHA512 with 1000 iterations or Whirlpool with 1000 iterations to generate the header key from your password. System encryption can only use RipeMD160 with 1000 (yes, only 1000) iterations.

Also, the 65536 bytes of the hidden system volume header needs to be in the MBR, track 62 or 63 I think, immediately after the standard system volume header. This is done automatically by TrueCrypt if you use the "Create Hidden Operation System" process. Because you manually created the hidden volume on partition 1, this did not happen.

 

I used Linux for that part, but yes, I encrypted it using the non-system method. I initially thought some difference between the two encryption methods might be the problem, so I tried creating a hidden OS using the official method, and after the process was complete, tried mounting the hidden partition from within the decoy system (without the "system" flag). It worked and the filesystem was decrypted correctly, which suggests that the hidden OS is, like they say, an OS booted from a normal hidden partition.

What you say about the MBR worries me greatly, but confuses me equally. A truecrypt header is certainly not 64KB long, it's 512 bytes. But if this part is written to the MBR, then surely it's trivial to reveal the presence of a hidden OS; one merely needs to dump the MBR and analyse the region where the hidden partition header would be located. If it contains data which would not be there with a regular system encryption, then you've shown with high probability that a second encrypted OS exists.

Likewise, the documentation claims that there are no "flags" indicating the presence of a hidden OS.

 

My apologies, you are correct. I just ran a test in VMWare by creating a hidden OS the official way and the hidden OS does, in fact, use the same number of hash iterations as the a regular hidden volume. It still appears to be limited to RipeMD only, but it uses the full 2000 iterations.

So, forget everything I said and I have nothing useful to add about your original issues.

Oh, and yes, a non-system TrueCrypt header techincally is 64KB, http://www.truecrypt.org/docs/volume-format-specification. Bytes 512 - 65536 are reserved. The system header is still only 512 bytes, though.

 

Here's how I believe it works: After the preboot authentication password has been entered, TrueCrypt uses it to attempt to decrypt either of two headers: the standard system encryption header located at the end of Track 0, or the hidden volume header (if one exists) located 65,536 bytes back from the end of the second partition. If the password is able to decrypt one of the headers then TC will mount that volume and will boot the OS that it contains. However, if the hidden header doesn't have the 'system' flag set then TrueCrypt will assume that it is a non-system volume and will not attempt to boot its contents.

Of course, the headers are encrypted and can't be analyzed unless the password is known.