Didier Stevens

Thursday 9 February 2012

Quickpost: Disassociating the Key From a TrueCrypt System Disk

Filed under: Encryption,Quickpost — Didier Stevens @ 21:05

TrueCrypt allows for full disk encryption of a system disk. I use it on my Windows machines.

You probably know that the TrueCrypt password you type is not the key. But it is, simply put, used to decrypt the master key that is in the volume header.

On a system drive, the volume header is stored in the last sector of the first track of the encrypted system drive (TrueCrypt 7.0 or later). Usually, a track is 63 sectors long and a sector is 512 bytes long. So the volume header is in sector 62.

When this header is corrupted or modified, you can no longer decrypt the disk, even with the correct password. You need to use the TrueCrypt Rescue Disk to restore the volume header. This rescue disk was created when you encrypted the disk.

I’m using Tiny Hexer on the Universal Boot CD For Windows to erase the volume header (you can’t modify the volume header easily when you booted from the TrueCrypt system disk; using a live CD like UBCD4WIN is one possible workaround).

First I’m checking the geometry of the system drive with MBRWizard:

Take a look at the CHS (Cylinders Heads Sectors) value: S = 63 confirms that a track is 63 sectors long.

Then I open the system drive with Tiny Hexer (notice that the sector size is 512 bytes or 0x200 bytes):

I go to sector 62, the last sector of the first track:

It contains the volume header (an encrypted volume header has no recognizable patterns, it looks like random bytes):

Then I erase the volume header by filling the sector with zeroes and writing it back to disk:

And if you absolutely want to prevent recovery of this erased sector, write several times to it with random data.

Booting is no longer possible, even with the correct password. The TrueCrypt bootloader will tell you the password is incorrect:

One can say that I’ve created a TrueCrypt disk that requires 2-factor authentication. To decrypt this disk, you need 2 factors: the password and the corresponding TrueCrypt Rescue Disk.

First you need to boot from the TrueCrypt Rescue Disk, and select Repair Options (F8):

And then you write the volume header back to the system disk. Remark that the TrueCrypt Rescue Disk requires you to enter the password before it writes the volume header to the disk:

And now you can boot from the system disk with your password.

Use this method if you need to travel with or mail an encrypted system disk and want to be 100% sure there is no way to decrypt the drive while in transit. But don’t travel with the 2 factors on you, send the TrueCrypt Rescue Disk via another channel.

Remark: MBRWizard allows you to wipe sectors, but for whatever reason, it couldn’t successfully wipe sector 62 on my test machine.

Oh yeah, don’t forget to make a full backup before you attempt this technique 😉

Quickpost info


  1. Can you think of any way this process could be automated? I think it would be very interesting to have a permanent two factor authentication for truecrypt with full disk encryption.

    Comment by R — Thursday 9 February 2012 @ 22:07

  2. @R Yes, one could develop a device driver that erases the header again after Windows booted.

    Comment by Didier Stevens — Thursday 9 February 2012 @ 22:11

  3. It would be very nice to have true two factor authentication for truecrypt in fulldisk mode. I think this is one of the few things missing on this otherwise great software. It would put it on par with other paid solutions, like for example Safeboot or Bitlocker (not sure if bitlocker supports two factor with an external key on pendrive).

    One idea would be perhaps to change the password for the encrypted volume after you created the rescue disk. If you change it to something incredibly long and random (which not even you would know), it would be, for most effects, as good as not having it at all. You could for example type randomly on the keyboard or generate a large random string to use as the password. One scenario where I think this would not suffice would be if you’re in a position such as being compelled to give the password for the encrypted volume. A forensic analysis on the harddrive would show that the header is still there, so you “should” have the password. But if the header is not there to start off, I can see a more plausible reasoning in claiming that it’s impossible to decrypt.

    What do you think?

    Comment by R — Friday 10 February 2012 @ 0:02

  4. Simply, clean, and effective… just perfect!
    It can be automatized in a bootable pendrive with truecrypt and a bit of time, to automatize this, asking for passwords and then restoring sector?


    Comment by Anonymous — Friday 10 February 2012 @ 10:27

  5. […] The following article is not directly related to your discussion but maybe someone find it useful: https://blog.didierstevens.com/2012/0…t-system-disk/ Reply With Quote     + Reply to […]

    Pingback by TinKode Busted - Page 5 — Friday 10 February 2012 @ 15:40

  6. @R Actually, a forensic analysis can’t show that the header is there if there is no password to decrypt the header. The encrypted header has no structure, it looks like random bytes. What a forensic analysis can show is the absence of a header. For example all bytes are null.

    Comment by Didier Stevens — Friday 10 February 2012 @ 16:53

  7. You’re saying “If you absolutely want to prevent recovery of this erased sector, write several times to it with random data.”. This is an urban legend.. http://www.nber.org/sys-admin/overwritten-data-guttman.html

    Comment by jelbo — Wednesday 15 February 2012 @ 9:02

  8. @Jelbo I believe what you want to say is that recovering data from a overwritten drive is an urban legend.

    I agree, but there are a couple of differences here. I don’t know if these differences are significant, as I’ve not researched this (this is a QuickPost).

    The differences are:
    1) we are not talking about recovering a complete disk, but at most 256 bytes
    2) even recovering parts of the encrypted key could reduce the key space to search
    3) the key is written in sector 62, which is not normally written to. On unencrypted disks, this sector remains pristine. And on TrueCrypt system disks, this sector is only written to once at disk encryption time as long as you don’t change the password

    Again, I’ve not researched if this actually makes a difference. But I’m being cautious.

    Comment by Didier Stevens — Wednesday 15 February 2012 @ 11:53

  9. […] Detalii cu privire la procesul prin care puteți face asta găsești aici. […]

    Pingback by Cum să folosești TrueCrypt pentru a cripta hard disk-ul în varianta "paranoică"? | WorldIT — Thursday 23 February 2012 @ 11:27

  10. Hi Didier,

    Very useful article; and perhaps a useful feature for Truecrypt to include in a future update!

    The issues with deleting data are well known and I will not belabour them here. However a single overwrite with 0’s or 1’s would be good enough, Writing a 1 and then a 0 to each bit would probably be overkill but not time-consuming an would ensure that each bit has been set and reset once.

    Overwriting with a known pattern would be better so you would be able to identify the reason for the data being erased. e.g overwrite the data with repeats of 0xDEADBEEF would reveal the reason why the data was overwritten. Random data or misleading data might be better though. Writing back a standard volume header might be better.

    There are urban legends about recovering overwritten data but they are seemingly just that. No one claims to be able to do this in the visible world and the shadow world would find it a very difficult task. When it has been attempted it seems to give worse results that randomly guessing if a bit was 1 or 0.

    A more plausible issue would be either overwriting the wrong sector by accident (or even worse perhaps) by design. Malware which tampers with the overwriting process would lead to a situation where you thought you had deleted the data but hadn’t.

    You might then send the encrypted volume off to a third party (and the recovery disk via another route) only to find the data had been decrypted enroute (unknown to you).



    Comment by Simon Zerafa (@SimonZerafa) — Saturday 25 February 2012 @ 10:08

  11. If there is a second hidden Operating System installed, which is a option in TrueCrypt, does it affect to it too?

    Comment by Alex — Monday 7 May 2012 @ 20:44

  12. @Alex You should be able to boot the hidden OS when the key of the primary OS is deleted. But I’ve not tried.

    Comment by Didier Stevens — Monday 7 May 2012 @ 22:09

RSS feed for comments on this post. TrackBack URI

Leave a Reply (comments are moderated)

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Blog at WordPress.com.