This patched TrueCrypt version (experimental) can mount containers from arbitrary offsets in file or 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 placed at arbitrary offsets on \\.\PhysicalDriveX, for instance in unallocated on disk. And thus reduce chances of detection. That 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.truecrypt.org/viewtopic.php?t=3820

How to use
First you must create a container and put it into another file (preferrably with a hex editor).
The patched functionality can only be accessed by commandline mode, and is not available in 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 /v "%CD%\sample-container\truecrypt-x64-original.sys" /lx /a /p joakim /i 231424

Example command line for container hidden in unallocated on PhysicalDrive2
truecrypt /v "\Device\Harddisk2\DR2" /lx /a /p joakim /i 10733990400

The above file based command uses the original truecrypt driver for 64-bit as container, and holds an encrypted truecrypt volume within the Authenticode signature. The password is joakim, the mountpoint is X:, and the offset of container is 231936. By mounting it with the above command, you will get at the patched source files. After the source files are retrieved, 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 the default sample music installed by Windows; 
http://www.mediafire.com/listen/ad0j2zurk00biyb/Kalimba.mp3

The 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 /v "%CD%\kalimba.mp3" /lx /a /p joakim /i 4307968

Note
On 64-bit systems you must enable testsigning mode to use it. On 32-bit it is fine. This is because my recompiled binaries 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 file offset must be a multiple of sector size.
It has not been extensively tested, so there might be bugs.

Tested on Windows 7 SP1 32-bit and 64-bit.

Creating container
The procedure for creating containers suited for this patched version, goes something like this:
1.Create a base container as you normally would, and specify size, encryption, password etc.
2.Find a new host file, appropriate for hiding the base container.
3.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.
4.Take a note of the offset where the base container is written.
5.Take a note of the size of the base container.
6.Now you are ready to mount the super hidden container.
7.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.
8.Verify that it works by writing files to the volume. Dismount the volume, and remount it. Check that the file is still there.
9.Check that the original file format of the new host file is still valid.

Step 3 might be the most difficult part here. For the example I had to modify the output of my DigitalSignatureTweaker tool, since it does not write its payload at sector size alignment within the executable. An easy approach would in most cases be to just put the container at end of file, but that would easy to detect though.

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 hiddenpassword

The 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:

    MakeContainer-Authenticode
    MakeContainer-Bmp
    MakeContainer-Eof
    MakeContainer-PEResource
    MakeContainer-PESection
    MakeContainer-Zip

The MakeContainer-Bmp tool utilizes the same trick as reference earlier about mp4, where certain hybrid formats can be supported by the legacy TrueCrypt version. It is thus possible to choose what kind of supported bmp to generate. The restrictions put in the original version limits what kind of file formats can be used for this, while the patched version obviously extends the opportunities of file formats to use/abuse.

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 2

Summary:
 - 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).


Building
This package was built with VS2010. Building the solution required quite a bit of work. I believe I got the setup instructions from;
http://stackoverflow.com/questions/13379644/how-do-i-build-truecrypt-on-windows
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.
