File Name: TrueCrypt Patched for supporting arbitrary offsets
File Submitter: joakim
File Submitted: 06 Apr 2014
File Updated: 27 Apr 2014
File Category: Security
This patched TrueCrypt version (experimental) can mount containers from arbitrary offsets in file or at disk. The container can consist of a range of bytes, instead of the whole file or the rest of the file. That means TrueCrypt volumes can now be stuffed inside other file formats Or it can be placed at arbitrary offsets on \\.\PhysicalDriveX, for instance in unallocated on disk. And thus reduce chances of detection. The patch is based on the latest version, 7.1a.
The orignal version is hardcoded to decrypt normal/outer header from offset 0 and hidden/inner header at offset 65536.
What we have achieved with this patch, is to add a layer of steganography to the TrueCrypt puzzle. For the extremely paranoid people, this may seem appealing, especially when combined with hidden volumes (outer/inner).
Since version 3 of patch, the broken partition patch of tateu has been merged. It was orginally made for version 4.2a: http://forums.truecr...opic.php?t=3820
How to use
First you must create a container and put it into another file (preferrably with a hex editor). See "Creating container".
The patched functionality can only be accessed by commandline mode, and is not available in the GUI.
The /i or /offset switch is for specifying the offset.
The /j or /sectors switch is only for broken partition usage.
The /n or /voltype switch is only for broken partition usage.
That means you can access directly a truecrypt disk hidden somewhere within another file. The original file format may be preserved as valid in certain scenarios, as the example below will show.
All other functionality is described in the official TrueCrypt documentation, and not here.
Example command line for container hidden in file:
truecrypt.exe /v "%CD%\sample-container\truecrypt-x64-original.sys" /lx /a /p joakim /i 231424Example command line for container hidden in unallocated on PhysicalDrive2:
truecrypt.exe /v "\Device\Harddisk2\DR2" /lx /a /p joakim /offset 10733990400http://i1100.photobu...zps140011bb.png
So how do you find the correct device for PhysicalDriveX?
Since \\.\PhysicalDrive2 not necessarily becomes \Device\Harddisk\DR2, it will help to download WinObj from Windows Sysinternals; http://technet.micro...s/bb896657.aspx and take a look in the GLOBAL?? page. Pay attention to casing as the TrueCrypts string parsing in that particular area is case sensitive.
The above command uses the original truecrypt driver for 64-bit as hostfile for container, and holds an encrypted volume within the Authenticode signature. The password is joakim, the mountpoint is X:, and the offset of container is 231424. By mounting it with the above command, you will get at the patched source files. After the source files are retrieved and volume dismounted, verify that the digital signature is still valid. It just uses a cool trick..
Another nice file format to play with is mp3. Here's an example I made based on one of the default sample music files installed by Windows;
http://www.mediafire.com/listen/ad0j2zurk00biyb/Kalimba.mp3The injected container has 2 volumes, one standard and one hidden. The standard volume has password "mikaoj" without quotes. Mount the hidden volume with this command:
truecrypt.exe /v "%CD%\Kalimba.mp3" /lx /a /p joakim /i 4307968Note
- On 64-bit systems you must enable testsigning mode to use it. On 32-bit it is fine though. This is because my recompiled drivers are signed with a selfsigned certificate.
- On first mount operation, the volume must be formatted. On subsequent mounts, the volume is mounted just fine.
- The container offset must be at a multiple of sector size.
- It has not been extensively tested, so there might be bugs. Encryption of system volumes has not at all been tested. Don't use it on that!
The procedure for creating containers suited for this patched version, goes something like this:
- Create a base container as you normally would, and specify size, encryption, password etc.
- Find a new host file, appropriate for hiding the base container.
- Modify the new host file and with a hex editor or other suitable tool, inject at appropriate offset the base container. This step would of course require a bit of knowledge about the file format specs of the new host file.
- Take a note of the offset where the base container is written.
- Take a note of the size of the base container.
- Now you are ready to mount the super hidden container.
- Since Windows will not detect the filesystem on the very first mount of this hidden container, you must let Windows format the volume. Now all hard work is done.
- Verify that it works by writing files to the volume. Dismount the volume, and remount it. Check that the file is still there.
- Check that the original file format of the new host file is still valid.
The steps for handling hidden volumes are similar, except for both the outer and inner volume, they both need to be re-formatted on the first mount. However, the concept with hidden volumes still work.
Other nice trick not described in official documentation
This trick works on the original unpatched version.
Idea taken from here: http://keyj.emphy.de...with-truecrypt/
Basically, since TrueCrypt will attempt loading the hidden volume inside container, and if decryption of the normal volume header (outer in this particular case), fails. It will move on and attempt decrypting the header of a possible hidden volume. The header of the outer volume is located in bytes 0 - 65535, and the header from bytes 65536.
Now to get this to work on unallocated on lets say \\.\PhysicalDrive2 we need to have some unallocated chunk with enough bytes to host our container, and it needs to be located on disk before the first partition. That means the first 512 bytes, which is the MBR, will be (from TrueCrypts perspective) a failed decryption of header for an outer volume, which means it move on to offset 0x10000 and try decrypting the inner volume. This way the disk will not appear like a standard Truecrypt disk/volume. It will look all fine from within Windows (actually this trick is independent of host OS). And it will work on the officially signed binaries. And don't forget to provide the password for the inner/hidden volume, and not the outer volume (they must be different!!). And just as important, remember to copy bytes from offset 0x10000 in container (and not from offset 0x0), and paste those bytes at offset 0x10000. Load it with a command like this one:
TrueCrypt.exe /v \Device\Harddisk2\DR2 /lx /a /p hiddenpasswordThe same concept, works on many different file formats too, as descrbed in the first link where an mp4 is modified. BMP is very easy.. EXE a bit tougher.
Tools to aid in tweaked container construction
Available in download section for several file formats:
The other tools only works with the patched version.
Regarding tateu's broken partition patch
Can be used to scan for a lost encrypted volume, due to overwritten partition table. It is slow, and performs about 3 sectors per second. It generates and output file to C:\TC_Offsets_Found.txt. Sample command to scan 10000 sectors for a hidden volume starting from offset 0x600000 (6291456 in decimal);
truecrypt.exe /v \Device\Harddisk4\Partition0 /lx /a /p password /i 6291456 /j 10000 /n 2Summary:
- The original TrueCrypt will by default attempt decryption of header (for normal/outer) volume at offset 0x0 of file or disk/volume. If that fails, it will move on to offset 0x10000 and attempt decryption of header for hidden/inner volume.
- The original TrueCrypt can in certain cases load hidden volumes if constructed as hybrid formats. It very much depends on the host format. Not all formats will allow this kind of tweaking. The hidden volume must always start at offset 0x10000 (both for file and physical disk). The first 65535 bytes can be something else, like MBR for physical disk or another file format header for file based containers.
- The patched version can load both normal and hidden volumes at arbitrary offsets for both file and physical disk. Remember to comply with the rules as described earlier in this post (alignment of offset, formatting of volume on first mount).
This package was built with VS2010. Building the solution required quite a bit of work. I believe I got the setup instructions from;
However, I ran into a number of issues.
- The driver build script, BuildDriver.cmd, needs modification to specify your own certificate to sign with.
- A .NET framework update messed things up, requiring a rename of all found cvtres.exe within the Visual Studio install path.
- Getting the 3rd party dependencies correct was not easy either.
- I think there was more, but because 1 year has gone since the actual patch was made, most is forgotten.
Click here to download this file