Thursday, July 3, 2014

Random Offset Hiding of TrueCrypt Containers

   Have you ever had to need to completely hide encrypted data and know that if you had to, you could successfully deny its existence?  Have you ever dreamed of hiding an encrypted container in unpartitioned free space?  No...  Neither have I, but we stumbled across a neat little trick and wanted to share with you.

   While playing around with with the command line, we wanted to see if one could use dd to consecutively write two individually created filesystems to a thumb drive (without partitioning the drive).  And if so, subsequently mount and use either one of the filesystems to store and save files.  We learned that the answer is yes, so we decided to make one of the filesystems an encrypted one.

   The process is a bit time consuming, but the end result is that you will end up with a device that will contain a fully functioning, usable, unencrypted filesystem followed by a completely hidden encrypted one.  The second encrypted filesystem will reside in the free space of the drive.  Since the device will not be partitioned, only the first filesystem will be seen by the operating system.  Without the existence of a partition table, not even forensic software will be able to spot the existence of the second encrypted filesystem, so don't forget its starting sector offset!

   At the time that we tested this theory, the credibility of the TrueCrypt software was still strong.  For that reason, we used TrueCrypt to encrypt the encrypted filesystem.  If your are of the belief that TrueCrypt is no no longer secure, then you are welcomed to use other tools.  The process should be repeatable and you can adjust it to your needs.  For the purposes of this article I used a VmWare Player Virtual Machine with Ubuntu 14.04 installed on it.  Let's get started. 

Installing the tools:

   With the exception of TrueCrypt, all of the tools that we will use are either included in Ubuntu by default, or can be downloaded from the Ubuntu Software Center.  TrueCrypt is still available for download.  Steve Gibson @SGgrc, the creator of SpinRite, stores the latest version of TrueCrypt on his website.  Find it here.  After download, if you want a bit of peace of mind, check the hashes against known file hashes independently stored on other sites, like this one

   The other tools that we will need to accomplish this scenario are dd, and sleuthkit.  Dd comes pre-installed in Ubuntu, so lets install sleuthkit. 

   We will install the tools form the command line.  Open a Terminal window, In Ubuntu you can accomplish this by pressing Ctrl-Alt-T at the same time or by going to the Dash Home and typing in “terminal”.  Type the following into the terminal to install sleuthkit from the apt-get repositories. 

$ sudo apt-get install hexedit sleuthkit

   You will be prompted for your root password.  Enter your root password and wait for the program(s) to install.  This procedure will install sleuthkit version 3.2.3, which will work fine for what we need.  As of this writing the latest version is 4.3.1.  If you want to use the latest, you have to compile it from source.  We can go over that a different day. 

   Now that you have the tools that we need, the next step is to prepare a working folder for us to store our working copies of our data.  Go to your desktop, right click on your desktop and select “create new folder”, name it “Test”.

   Navigate to the previously created Test folder on the desktop.  We will use the CD command to change directory into the desktop.  Type the following into the terminal.

$ cd /home/carlos/Desktop/Test/

   Replace “carlos” with the name of the user account you are currently logged on as.  After doing so, press enter.  You should receive these results. 

   This will be the directory were we will create our filesystems and/or whatever data we plan on using as a working copy of a file. 

The test:

   The first step in our process is to create the first filesystem that will later be written to our drive.  It will be an unencrypted filesystem that you can use to store any non-sensitive data, or any data for that matter. 

   Since two independent filesystems will be residing on our drive, you will have to decide how large each of your filesystems will be.  For the purposes of this article, I will be using a 64MB thumb drive to store our filesystems. I chose a very tiny thumb drive so that I could make the image available to you, if you wish to download it.  Find it here.  Each of my filesystems will be 25MB in size.   The password is "mtk".  Continuing...

   From the terminal, type the below command

$ dd if=/dev/urandom of=1st25mb_unencrypted.dd bs=512 count=50000

   Dd is a common Linux program whose primary purpose is the low level copying and conversion of raw data.  The if= tells dd to read from file.  In this instance the file is /dev/urandom, which is an interface to the kernel's random number generator.  The of= tells dd to write to a file, which will be a file called 1st25mb_unencrypted.dd.  Bs is the block size of data to be used, and count tells dd to write fifty thousand blocks of 512 bytes.  The result is that we will end up with a data chunk that contains exactly 50,000 blocks of 512 bytes.  Multiply 50,000 by 512 and then divide it by 1024 and you will get 25MB. 

   This should be the resulting data chunk.  The ls -l command is the command to list files with the -l argument that uses the long listing format.

   Once the data chunk has been created use the below command to format the data chunk into a functioning Fat-16 filesystem with volume label “MTK.”  Fat-16 worked best for the data chunk that we created.  You can use a different filesystem if you choose. 

$ mkfs.vfat -F 16 -n MTK -v 1st25mb_unencrypted.dd

   Mkfs.vfat is the command to create an MS-DOS filesystem under Linux, -F Specifies the type of file allocation tables used, -n sets the volume name (label) of the filesystem and -v will give us verbose output. 

   Success we have formated the data chunk.  If you want to look at the filesystems statistics of the data chunk, you can use the sleuthkit command fsstat, which will provide just that.  Type the below command and press enter

$ fsstat 1st25mb_unencrypted.dd

   The next step is to create our encrypted filesystem using TrueCrypt.  There are many tutorials online on how to do this.  I don't want to go over the steps of creating one here due to the many options available and how much longer it would make the write up.  A good article on how to create a container can be found on the Howtogeek site.  I went ahead and created a 25mb container using all the defaults and the password mtk (lowercase).  I named the container 2nd25mb_encrypted.dd. 

   I also mounted the encrypted container and added a file titled SecretFile.txt.  You can use the same article from Howtogeek for instructions on this.  Once you have added a file to the container use TrueCrypt to unmount it. 

   Now comes the fun part.  Find a thumb drive that we can write these filesystems to.  I inserted my 64mb thumb drive to my VM and ran the below command to identify it.

$ sudo fdisk -l

   Fdisk is a partition table manipulator for Linux.  The flag -l tells fdisk to list the partition table.  Sudo gives fdisk superuser privileges for the operations.  Press enter and type your root password (if needed).

   Ubuntu assigned my 64mb media as SDB.  SDA is the internal virtual HDD that Ubuntu is installed on. 

   We finally get to write these filesystems to the media.

   The below command will write each filesystem consecutively to my 64MB thumb drive.

$  cat 1st25mb_unencrypted.dd 2nd25mb_encrypted.dd | sudo dd of=/dev/sdb

   Cat is the command to concatenate (combine) the two chunks one after the other.  The “|” is known as a pipe.  A pipe is a technique in Linux for passing information from one program process to another.  Dd saw the two chunks that were passed to it and wrote them contiguously to the 64MB thumb drive assigned as physical device /dev/sdb.  

   Our thumb drive is now ready for deployment and use.  Both of the filesystems are now residing on the drive.  If you insert this drive into a Windows machine this is what you would see.  Windows only recognized the unencrypted filesystem and assigned it logical letter (F).  

   At this point the drive is fully functioning with a 25MB filesystem that is capable of storing data.  Even the “MTK” volume label that we assigned is being recognized.  To the untrained eye the drive looks perfectly normal and if forced to show your files, only the non-sensitive data would be seen.  The trained eye or anyone with a little knowhow will be able to see that a 64MB drive only contains a 25MB filesystem.  Inspection of the free space of the drive would only show noise and nothing else.  Similar to the noise in the unallocated space of the unencrypted filesystem, hence the reason why we chose /dev/urandom for that data chunk.  You can picture them scratching their heads, but that may be the extent of it.  Have you ever heard of an examiner segregating the free space of a drive into its own file to look for encrypted containers and run brute force attacks?  If you have, please tell us about it in the comments.

Accessing the encrypted container:

   To access the encrypted container we are going to have to create a loop device and then mount that loop with TrueCrypt.  Because the free space of the drive contains an entire filesystem, that specific offset of the drive can then be mounted as if it were a disk device.

   Accomplish it with the below command.

$ sudo losetup -o 25600000 /dev/loop0 /dev/sdb

   Losetup is the command to set up and control loop devices, -o is the argument to specify the offset to the encrypted container.  This location has to be specified in bytes.  The container starts 25,600,000 bytes into the drive, which was the 50000 sectors of the unencrypted filesystem times 512 bytes.  /Dev/loop0 is the first available loop mount and /dev/sdb is the 64MB thumb drive. 

   Lastly we need to decrypt the loop mount and mount it to a previously created directory using TrueCrypt.  This step can be accomplished with the below command.

$ sudo truecrypt -t /dev/loop0 /mnt/tc/

   Truecrypt -t is to use the TrueCrypt program in text mode, /dev/loop0 is the location of the loop and /mnt/tc is a previously created mount point that I created using mkdir (no screenshot). 

   By running ls -l on /mnt/tc we can see that our previously created file titled SecretFile.txt is now decrypted and available to us.  The loop device was mounted in readwrite mode, which means that any data that you add to this filesystem will be stored and encrypted upon dismount. 


   This was a time consuming process of creating a hidden encrypted container to store sensitive data.  It probably doesn't offer any more security than the already available methods through TrueCrypt.  It simply was an exercise on how to manipulate data chunks and filesystems using the shell. 

   If this procedure helped your investigation, we would like to hear from you.  You can leave a comment or reach me on twitter: @carlos_cajigas


Update 07/10/14:  Bored?  Notice that the last screenshot above tells us that "SecretFile.txt" contains 11 bytes of data.  Download the image, mount the encrypted container, and be the first one to tell us what data is stored in the "SecretFile.txt".  Leave it in the comments section.  Remember to share a tip.


Update 07/18/14:  Gerry Stephen found the data inside of the txt file.  He went about finding the data using his preferred method and he even described his way.  Go to the comments section to see his tip.


  1. Very nice Carlos! Didn't go the Linux route. Loaded the E01 file using EnCase and Noted the Volume Slack started at Physical Sector 49,997. Since your writeup stated the Encrypted Volume was 50,000 sectors, I went in 1,536 bytes [ 3 x 512] and carved out the rest. Mounted it using TrueCrypt and the password "mtk". Found the file "SecretFile.txt" with a Modified Date of 3 Jul 14 @ 3:52 PM. Inside was the text "SecretData".

    1. Gerry, Way to go. That’s it. You found the “SecretData” Thanks for taking on the project. I like the way you went about it and thanks for letting us know of another way to accomplish the task. Thanks for the comment.