Discovering the Presence of Hidden Volumes in TrueCrypt

By Chad Kluck on

I completed my Master of Science in Software Engineering in May of 2011. My final paper was for a computer forensics class in which I examined TrueCrypt, which recently received the results of its second round audit examining its crypto. No back doors or serious vulnerabilities were discovered.

TrueCrypt was long regarded (and to many including me still is) as an awesome and robust encryption program, allowing encrypted containers, file systems, and bootable drives across many platforms. Though support for it abruptly ended last year as it was going through a crowd funded audit, many still see it as the standard when compared to proprietary or other programs that have not been as pounded upon as TrueCrypt.

Though TrueCrypt is bulletproof (provided a strong password is used) for my final project I set out to see if I could gather any information about how the volume was used by a suspect and what a volume may contain.

I just want to stress, possession of a TrueCrypt volume on its own is not a reason to suspect anyone of ill doing. We use passwords and encryption every day to secure our bank accounts, phones, computers and devices. Security, encryption, and privacy are essential to protect us from those who wish to cause us harm. Just as locking your home or car does not make you a criminal, neither does encrypting your personal data. As with many things, it can be used for us, as well as against us.

Discovering the Presence of Hidden Volumes in TrueCrypt

A graduate student's final project

May 16, 2011

Chad Leigh Kluck

When computers are about ready to be seized, and it is noted that encrypted volumes exist, a judgment call must be made if the files or volume is open and in an unencrypted state. Unencrypted files may be saved off of the computer, a memory dump may be performed, and the suspect may be asked to give passwords.

Additional steps may be taken to recover potential passwords such as searching for passwords in memory, on written notes, or documents on the suspect’s machine. TrueCrypt is a popular free, open source encryption software readily available and will pose problems for forensic examiners if the passwords are unknown.

Also, just because you can decrypt a TrueCrypt volume, doesn’t mean you have access to all the data. TrueCrypt has the ability to create a hidden volume which they tout has all the means to achieve “plausible deniability.” It is believed that no examination can tell a TrueCrypt volume with hidden data apart from one that does not have hidden data.

Much like the way a magician would show the audience that indeed his magic box was empty before the “pull-a-rabbit-out-of-the-box” trick, an individual could, without caution, reveal the contents of an encrypted volume to an observer requesting access.

Both the magician and the suspect use misdirection to try to put at ease any question of not revealing the contents of the box or volume. However, just as the magician uses mirrors and hidden compartments to stow the rabbit, the suspect can use a second password to get to the hidden, secret volume.

Open it one way to reveal there is nothing to hide, open it a secret way when no one is looking.

The audience, if they were allowed on stage and knew what to look for (if they were practicing magicians themselves), would quickly examine the box and find the magician’s secret to keeping the rabbit out of view until the trick was accomplished. My question is: “Can a forensic examiner familiar with encrypted volumes, having complete access to the encrypted blob, and the password, detect the presence of a hidden volume?”

Using some forensics tools against several TrueCrypt volumes I created, some with hidden volumes, some without, I quickly learned more about the claim of “plausible deniability.” I also gained a better and more thorough understanding of how TrueCrypt works and how to examine drive images.

First, to avoid confusion, I will refer to both TrueCrypt encrypted containers and volumes as “encrypted containers” or just “containers” since they “contain” encrypted data as a single blob. The difference is mainly that one is a file, the other a whole encrypted volume, but beyond that they have much the same construction. For my purposes there is no need to distinguish between the two. I will reserve the name “volume” when referring to the area of a container that can be decrypted and mounted as a volume that allows the contents to be accessed. I will use the term “outer volume” when referring to the volume disclosed to an investigator, and “hidden volume” or “hidden area” when referring to the secret volume hidden from the investigator’s view.

To start, I created two encrypted containers, one with a hidden volume and one without, both 2MB in size since I wanted something manageable. The directions TrueCrypt gives when creating a volume with a hidden area is to choose a password (PASSWORD1) to be handed over to anyone compelling the user to divulge it. This is for the outer volume meant to demonstrate to investigators that there is no incriminating evidence. The user is also instructed by TrueCrypt to copy over non-incriminating files to the outer volume. Next, the user is prompted for a strong password to use to protect the hidden volume (PASSWORD2).

A TrueCrypt container without a hidden volume is created merely by creating a password and having TrueCrypt format a container.

After the volumes were created I mounted each one by one and gave a quick examination. The mounted volume size for both the containers showed as 2MB, even though one had a hidden volume. Free space was also equal in size since both had the exact same files copied in. From this quick examination there wasn’t a way to determine if either had a hidden volume.

Wondering if I would be prevented from using all 2MB on the volume (since I allocated half the space to be hidden) I quickly copied an image over with no problem. I then dismounted the outer volume and tried to mount the hidden volume receiving an error. I quickly surmised that there isn’t anything protecting the hidden volume from being overwritten and it is truly regarded by the OS as free space. (However, upon closer reading of TrueCrypt documentation, there is a way to prevent this, I’ll get to that later.)

I then recreated the 2MB container with a hidden volume to replace the one I destroyed, as well as a few other test containers larger in size (20MB) so that I could play around with something more than just small text files. I added files, deleted them, modified some, and choose thumbnail view on a machine running Windows XP. After some play time I acquired “drive” images of the mounted volumes for low level examination.

Examining the acquired images with AccessData’s Forensics Toolkit, I quickly found out that mounted volumes behave exactly like real volumes with a real File Allocation Table (in this case a FAT12), recycle bin, slack space, and free space. The free space is unique in that instead of being formatted with all 0’s, it is filled with random data. (I’ll get to that later too.)

I had an 8KB text file that was filled with the repeated phrase, “All work and no play makes Jack a dull boy.” I modified that removing all lines and saving only the two words, “Feelin’ fine.” When examining the image I was able to recover the slack space revealing the repetition of the original phrase as shown in the following (simplified) example.

|Feelin’ Fi|ne........| makes Jac|k a dull b|oy. All wo|rk and no play mak|
|0000000000|1111111111|2222222222|3333333333|4444444444|5555555555|...9999|
|0123456789|0123456789|0123456789|0123456789|0123456789|0123456789|...6789|

Documents were able to be recovered from the recycle bin and images could be seen in the thumb.db files created after I viewed the directory in Thumbnail View.

I would often go back to the mounted volumes adding more documents and then creating a forensic image. Each time I examined it I noted that the new files ate away at the free space filled with random data. Again and again there were no markers telling the system to stop and not overwrite any protected area.

At this point I decided to read up on TrueCrypt and its use of hidden volumes.

Luckily TrueCrypt is open source and much is said about the algorithm online. The developers of TrueCrypt also provide a lot of documentation online to educate users on how their data is encrypted.

Here is a simplified view of a TrueCrypt container, which is laid out much like a fixed length record in a data file. There are two sections, the headers take up the first section (we’ll say locations 0-19) and the rest is data (20-99 in this example). (The pipe characters (“|”) are just for visualization.)

|HEADER1---|HEADER2---|DATA------|----------|----------|----------|...----|
|0000000000|1111111111|2222222222|3333333333|4444444444|5555555555|...9999|
|0123456789|0123456789|0123456789|0123456789|0123456789|0123456789|...6789|

When you look at a raw, encrypted container all you would see is a random blob of information demonstrated here by random, printable ASCII characters:

|#Tl]+kO=lm|`Ql+M?GiuF|/UcJ,@uWOb|w^pS)\8L@j|z!cU'yl;zJ|Q:l*QcD6)l|...>Zbl|

When a user points TrueCrypt to a file to mount as a volume TrueCrypt takes the supplied password and attempts to decrypt the first header (locations 0-9). Once decrypted using the password, TrueCrypt can read the header data including the cryptographic key and algorithm used to encrypt the data section. It takes that information to decrypt and mount the volume. It is important to note that the password itself does not encrypt the data. Like with most, if not all, strong encryption schemes, the password only protects a strong key that is used to then perform data encryption.

Separating the password from the data section also means you can’t just take a password and try it against the encrypted data. Your best attempt at recovering the data is to brute force against the header until you get a key or by doing a memory dump.

Why the two headers? The first header is for a standard TrueCrypt volume without a hidden volume. The second is for a hidden volume which may or may not exist. Even though a container is created without a hidden volume, space is allocated to a second header to prove a first point of plausible deniability. The theory is if all TrueCrypt containers reserve space for two headers there is no way from the header area to tell if we are looking at a container with a hidden volume or not.

If the user has a hidden volume and supplies PASSWORD1, the first header is decrypted and the outer volume is mounted. However, if the user supplies the super-secret password, PASSWORD2, the attempt by TrueCrypt to decrypt the first header will fail (as it isn’t the right password for the first header) and will try it against the second header. Since this super-secret password is only for the hidden volume, which the second header contains information for, it decrypts the second header successfully thus gaining the encryption key and algorithm to decrypt the hidden volume within the data section. The second header also tells TrueCrypt where the hidden volume starts.

It is important to note that if an incorrect password is supplied TrueCrypt first attempts Header 1, fails, and then attempts Header 2, which it will also fail at. TrueCrypt itself cannot determine what headers are used or what the password is for. TrueCrypt even goes further by brute forcing encryption algorithms when it attempts to decrypt the headers. There are absolutely no signatures when looking at an encrypted container. If you know you are looking at a TrueCrypt container, all you know is where the header is and where the data is.

In this example, with PASSWORD1, we have access to the first header that lets TrueCrypt know the data portion is encrypted with the key “abcde” using AES encryption. The volume is mounted showing the text file containing non-incriminating text and free space filled with random characters. (For simplicity I have excluded slack space.)

|HEADER1---|HEADER2---|DATA------|--------FR|EE-SPACE--|----------|...----|
|AESabcde..|`Ql+M?GiuF|[FAT]Feeli|n’ Fine.@j|z!cU'yl;zJ|Q:l*QcD6)l|...>Zbl|
|0000000000|1111111111|2222222222|3333333333|4444444444|5555555555|...9999|
|0123456789|0123456789|0123456789|0123456789|0123456789|0123456789|...6789|

This container may or may not contain a hidden volume. This leads to the second point of plausible deniability. Remember, free space in TrueCrypt formatted volumes are filled with seemingly random data. Since all volumes contain this random data in the free space, you can’t distinguish truly free random data from seemingly random data that is actually an encrypted volume underneath. There could actually be several hundred megabytes of random data in the free space before the hidden volume starts. At this point, the only way to know if there is a hidden volume and where it starts is to unlock the second header with PASSWORD2 and find the location.

In the example below “vwxyz” is the key using AES and the hidden volume starts at location 42 revealing “Get ax, Terrorize family, Destroy Overlook Hotel.” Note that the first header as well as data before location 42 is untouched.

|HEADER1---|HEADER2---|DATA------|----------|--HIDDEN-V|OLUME-----|...----|
|#Tl]+kO=lm|AESvwxyz42|/UcJ,@uWOb|w^pS)\8L@j|z![FAT]Get| ax, Terro|...tel.|
|0000000000|1111111111|2222222222|3333333333|4444444444|5555555555|...9999|
|0123456789|0123456789|0123456789|0123456789|0123456789|0123456789|...6789|

I was able to verify random characters in the free space by looking at the entire image through FTK and the program DiskExplorer for FAT.

Again, remember, when the outer volume is mounted using the first header the hidden volume is stored within the free space. It isn’t floating around in the free space, but rather is “right aligned” with the end of the container. For example, if the data section is 20-99, and the hidden volume is 57 units long, it will be stored in locations 42-99. If it is only 30 long it will be stored in locations 69-99.

This means that anything between 20 and 42, or 20 and 69 in these examples is true free space where files can be written without overwriting the hidden partition. Since the FAT on the outer volume does not know what the true free space is, it will continue to allocate space for files until it fills up, reaching the 99th location thus overwriting the hidden partition. That is the issue I ran into early on in my experiments, and as I mentioned, there is a solution to that problem.

The outer volume may safely be used without fear of overwriting the hidden volume if the user supplies both passwords when attempting to mount the volume. This tells TrueCrypt to open the outer volume and mount it, but access the second header in order to know what the true available free space is thus preventing overwriting the hidden volume. Of course, the user would never supply or use both passwords when demonstrating to investigators that there is nothing to be seen.

So, based upon TrueCrypt’s documentation, and my own experiments, it is impossible to tell either on the surface or at the byte level whether or not a hidden volume exists within a single container. Not all is lost, however as examination of what you have access to can point you in the right direction.

First, before the hidden volume is created, the user is prompted to put files into the outer volume. These files, when copied over, most likely will retain their original creation, access, and modification dates. On my Windows XP machine I found this to be the case. If the user copies these files over, intending to only use them as a decoy and not modify, the dates will not move forward and the files will look stale. This technique is also used by network intruders. If the files all have the same creation date, or have not been modified in a long time, they can have the suspicion that they are looking at a honey pot or decoy machine.

If the user actively uses the outer volume in a protected mode (in order to keep from overwriting the hidden volume) the files will appear fresh, and this also means there could be information in the recycle bin, thumb.dbs, and slack space. Hidden volumes can be created well after the initial outer volume is created. A user may move files from the outer to the hidden volume leaving traces of the incriminating files behind. Or, they could have been really careless and created an incriminating document in the wrong place later moving or deleting it.

Perhaps the most conclusive method I discovered for knowing that a hidden volume exists is by comparing free space characters in the outer volume with any backups or copies available from the user’s computers or storage media.

If there are any copies or back-ups of the container and the investigator has the password, decrypting the original and any copies should result in the same sequence of random free space characters. Since free space wouldn’t be overwritten until new files are added to the outer volume, the remaining free space should never change. If there is a change in the pattern at any point in the free space it means that something was modified in a hidden volume.

Myfiles.tc
|HEADER1---|HEADER2---|DATA------|--------FR|EE-SPACE--|----------|...----|
|AESabcde..|`Ql+M?GiuF|[FAT]Feeli|n’ Fine.@j|z!cU'yl;zJ|Q:l*QcD6)l|...>Zbl|

Myfiles backup.tc
|HEADER1---|HEADER2---|DATA------|--------FR|EE-SPACE--|----------|...----|
|AESabcde..|`Ql+M?GiuF|[FAT]Feeli|n’ Fine.@j|z!cU'ylfC/|I3&\xmD6)l|...>Zbl|

I was able to discover this in my own experiments under the premise that all changes, whether in the outer or hidden volume will change something. Since the hidden volume is stored within the free space some changes will be reflected. I was able to confirm this by creating two additional copies of my test container. I then mounted a hidden volume from one of the copies and added a small file.

After dismounting the hidden volume I mounted the original outer volume and its copy to compare side by side in DiskExplorer. I noted that two separate sectors within the free space changed. I still wasn’t able to identify the start of the hidden volume, but I can only assume that the change in two separate places were due to the new file now being listed in the File Allocation Table as well as in the data area. Since the other sectors did not change, and TrueCrypt encrypts sector by sector, the remaining free space would naturally be untouched.

This can be significant because it is very easy to change data on a volume, as demonstrated earlier. Any modification or access may change data in the FAT. Deleting or modifying files or viewing images as thumbnails will also create changes to the volume. Any of these small changes will be reflected by a change in the random data contained in the outer volume’s free space.

When working with a TrueCrypt volume, it is a good idea to carve out and obtain a hash of the free space for comparison if other copies are available. The free space, of course, needs to be of equal size and must start closest to, but not including, the most recently allocated space, even if it is now slack space. If the hashes don’t match, something in the free space changed giving a strong indication that a hidden volume was modified since the last back-up.

Though knowing something exists is not always evidence, it can lead to new possibilities and opportunities for discovery. If there is suspicion that a hidden volume is being used a dictionary or most likely password attack against the container may be in order. If recovering the password is at all possible, dictionary and partial password attacks would be the most successful. A true brute force attack (aaaa, aaab, aaac...) would be infeasible and take several decades to complete (unless they were using “12345” as their password).

Identifying a list of other passwords the individual has used as well as possible important dates, names, and places, will help aide in the dictionary attack. However, if there are keyfiles used, unless you know what they are, forget it. You are not getting at the hidden volume without the keyfiles and some idea about what the password could be.

I attempted a memory dump after opening a TrueCrypt volume and instead of any passwords in memory, I only found text from the file I created to remind me of the passwords which I had opened earlier but did not have open at the time of the memory dump. Even though the password itself was not in memory, a suspect may have recently opened a text file to help remember their super secret password. Any small pieces of text found in main memory should be included in the list to try during the dictionary attack.

If there are any keys resident in the memory they could be used to decrypt the data. However, this might not be helpful unless you know where the hidden volume started inside the container. Only the second header has the start location and you need the password to obtain header information.

As I work in making sure data is secure on our department’s devices, it was very helpful to use computer forensic techniques to break down and examine what is happening in a program such as TrueCrypt. Though I had played with, and used, the software for a while, I never had a complete understanding of how it worked. The ability to experiment, research, and actually see the low level inner workings improved my understanding of how forensic and security software works.

Though many suspects may not have older versions of their TrueCrypt containers, I was still thrilled to discover and prove that comparing free space in a mounted outer volume could expose the presence of a hidden volume if it had been modified since the last back up or copy. I believe thinking outside of the box and attacking the problem from different angles helped me on that one.

Additional resources

(The first three were used in writing this report, the one for Steve Gibson was added specifically for this blog post):

Tags