[ANN] TrueCrypt Steganography made simple

[phelix]

This software lets you hide TrueCrypt volumes within fully working .mp4 (and other) video files.
edit: Unfortunately detecting the hidden volume is not very hard.

Actually it is 99% a simple wrapper redistributing KeyJ's tcsteg script. Details on his page:
http://keyj.emphy.de/real-steganography-with-truecrypt/

http://bitcoinX.com/tcsteg

[phelix]

reserved

[Foxpup]

Detecting the hidden volume is not trivial.

Actually, it is.

There are only four ways to detect the presence of the hidden volume, all of which are unlikely to be checked even by a knowledgeable person. The easiest way to tell about the manipulation would be bitrate monitoring: If a player tells you that the stream has a bitrate of 1 Mbps, but by analyzing the file size, you can compute that it must have at least 5 Mbps, you can tell something is amiss. But who looks at bitrates this detailed? The only other ways would be (1) a sophisticated packet-by-packet analysis of the mdat data that would find out that from offset 65,536 on, there’s not only random-looking compressed data, but random-looking garbage; (2) checking for a repetition of the first 64k of mdat somewhere later in the file and (3) seeing that there’s much unused space in the mdat that isn’t referenced by any chunk offset table. I can imagine, in theory, that there might be tools to do the latter, but until someone shows me such a tool, I boldly declare my method as safe

First of all: the tool works very well.
Second: it is one of the best solutions i’ve seen.
Third: unfortunately, as many others steganographic solutions it is simple to detect .
The bitrate isn’t a problem (not so serious, at least). The stream size is the very problem. Look at this test for the difference. First one is a real MP4 video. The Second is the same video with a Truecrypt volume (6 mb) inside.

Infos from mp4 file:
File size : 68.1 MiB
Video Stream size : 58.7 MiB (86%)
Audio Stream size : 9.23 MiB (14%)
Total Stream : 67.93 MiB (100% – more or less, the rest is header)

Infos from TC hybrid file:
File size : 74.6 MiB
Video Stream size : 58.7 MiB (79%)
Audio Stream size : 9.23 MiB (12%)
Total Stream: 67.93 MiB (91% – the rest, of course, is TC volume)

Every file with a stream size lower than 100% is a suspicious file.
Many tools are capable to calculate stream size, MediaInfo (http://mediainfo.sourceforge.net) can do it, for example.

I used MediaInfo.dll and AutoIt (http://www.autoitscript.com/) for doing a (very rough) CLI utility for quickly hybrid files detection. It is here: https://rapidshare.com/files/63434631/TCHFind.zip (MD5: zip file: 774DA43D5706B1B8E5ABA9847420EE87 exe file: A1D68BDAD3FE1CCA8D5717BB0443B330 – tested on Win 7) Read the “ReadMe” file for usage.

However, you did a good job.

This is really no better than cat SomeVideo.mp4 SecretData.tc.zip > InnocentLookingVideo.mp4 (Zipping the TC file allows it to be easily extracted by just opening the resulting MP4 file as a ZIP file). The resulting file requires no special tools either to create or open, and it's no more likely to be detected than more complicated methods (the MP4 file still works, and is still identified as an MP4 file by all standard file type signature tools, so nobody's going to check it too closely and if they do, they would have found the secret data anyway).

[phelix]

Detecting the hidden volume is not trivial.

Actually, it is.

There are only four ways to detect the presence of the hidden volume, all of which are unlikely to be checked even by a knowledgeable person. The easiest way to tell about the manipulation would be bitrate monitoring: If a player tells you that the stream has a bitrate of 1 Mbps, but by analyzing the file size, you can compute that it must have at least 5 Mbps, you can tell something is amiss. But who looks at bitrates this detailed? The only other ways would be (1) a sophisticated packet-by-packet analysis of the mdat data that would find out that from offset 65,536 on, there’s not only random-looking compressed data, but random-looking garbage; (2) checking for a repetition of the first 64k of mdat somewhere later in the file and (3) seeing that there’s much unused space in the mdat that isn’t referenced by any chunk offset table. I can imagine, in theory, that there might be tools to do the latter, but until someone shows me such a tool, I boldly declare my method as safe

First of all: the tool works very well.
Second: it is one of the best solutions i’ve seen.
Third: unfortunately, as many others steganographic solutions it is simple to detect .
The bitrate isn’t a problem (not so serious, at least). The stream size is the very problem. Look at this test for the difference. First one is a real MP4 video. The Second is the same video with a Truecrypt volume (6 mb) inside.

Infos from mp4 file:
File size : 68.1 MiB
Video Stream size : 58.7 MiB (86%)
Audio Stream size : 9.23 MiB (14%)
Total Stream : 67.93 MiB (100% – more or less, the rest is header)

Infos from TC hybrid file:
File size : 74.6 MiB
Video Stream size : 58.7 MiB (79%)
Audio Stream size : 9.23 MiB (12%)
Total Stream: 67.93 MiB (91% – the rest, of course, is TC volume)

Every file with a stream size lower than 100% is a suspicious file.
Many tools are capable to calculate stream size, MediaInfo (http://mediainfo.sourceforge.net) can do it, for example.

I used MediaInfo.dll and AutoIt (http://www.autoitscript.com/) for doing a (very rough) CLI utility for quickly hybrid files detection. It is here: https://rapidshare.com/files/63434631/TCHFind.zip (MD5: zip file: 774DA43D5706B1B8E5ABA9847420EE87 exe file: A1D68BDAD3FE1CCA8D5717BB0443B330 – tested on Win 7) Read the “ReadMe” file for usage.

However, you did a good job.

This is really no better than cat SomeVideo.mp4 SecretData.tc.zip > InnocentLookingVideo.mp4 (Zipping the TC file allows it to be easily extracted by just opening the resulting MP4 file as a ZIP file). The resulting file requires no special tools either to create or open, and it's no more likely to be detected than more complicated methods (the MP4 file still works, and is still identified as an MP4 file by all standard file type signature tools, so nobody's going to check it too closely and if they do, they would have found the secret data anyway).

had not thought it would be so easy. thanks for sharing the cat zip method.

[phelix]

sweet, Foxpup's trick works with windows, too:

copy /b video.mp4 +zipfile.zip test.mp4

test.mp4 can be opened with 7zip for example and video does still work...

[Foxpup]

This isn't "my" trick, it's a pretty well-known method of abusing file format quirks. It works quite simply: Most file formats (MP4 included) start with a header which describes the data contained in the file, as well as (in most cases) providing byte offsets to the data chunk(s). Any data beyond these offsets is ignored, and you can append whatever you want to such a file without breaking anything.

But ZIP files are different. The header of a ZIP files is at the end of the file, not the start, and the offsets to the compressed file entries within the ZIP file are relative to the start of this header, not the start of the file. This is completely the opposite of most file types, and allows ZIP files to be prefixed with arbitrary data without breaking them.

These two facts allow you to stick a ZIP file onto the end of another file, and the resulting file will function normally as both the original file and the attached ZIP file without having to use special tools to separate the two.

But that's not all. File type signature tools typically work by reading a few bytes from the start of a file and comparing it against a database of known file headers. This works for most file types, including undoctored ZIP files, because ZIP files normally start with a compressed file entry, which is not the header, but is treated as such by signature tools because it is uniquely identifiable as being part of a ZIP file. But this assumption fails completely for ZIP files which do not start with ZIP compressed data, and the tool will instead identify the file as being whatever type of data the ZIP file was prefixed with.

This is, of course, trivial to detect if you know what you're looking for (namely, the file size being significantly larger than the apparent data contained in the file), but most other steganography techniques have the exact same problem.