Real Steganography with TrueCrypt

(February 24, 2011)

Disclaimer: This article has been written at a time when TrueCrypt was still a viable encryption software. This is no longer the case. TrueCrypt has been discontinued and everybody who has been using it should use one of the maintained forks like VeraCrypt instead.
That being said, this article mostly deals with TrueCrypt as a file format, not the application itself. However, the newer forks (and VeraCrypt in particular) use the same file format, so everything in this article is applicable to VeraCrypt as well. So, when this article talks about TrueCrypt and .tc files, you can just mentally replace this with VeraCrypt and .vc files.

You probably know TrueCrypt, the perhaps most popular tool for encrypting filesystems. As an alternative to full filesystem or even full disk encryption, TrueCrypt can also work with filesystems inside encrypted container files. These are files that look like they’re full of purely random data, but when provided the correct decryption key, they reveal their true contents: A FAT or NTFS filesystem full of your secret data.

In addition to this basic functionality, TrueCrypt also offers a simple form of steganography. For the uninformed, steganography is the term for techniques that conceal the existence of secret data. This means that the secret information is hidden inside another unsuspicious piece of data. TrueCrypt does support this with its »hidden volume« feature. If this is used, a container can be opened with two different keys: The first not-so-secret key opens the »outer volume« with not-so-secret data and a second really secret key opens the hidden volume with the real secrets. There are two problems with this approach, though: First, it’s very simple to destroy the hidden volume since it’s embedded in the outer volume’s data area without proper marking in the outer volume filesystem’s meta-data (otherwise they would give away the presence of the hidden volume). This means that you can overwrite the hidden volume just by putting enough files inside the outer volume. TrueCrypt can protect the hidden volume when mounting the outer volume, but for this to work, you need to provide the hidden volume’s key.

The second issue with TrueCrypt’s approach to steganography is that TrueCrypt container files are just large files with random data and as such, they’re easily detectable. You can disguise them by giving them unsuspicious filenames – pagefile.sys or hiberfil.sys in a drive’s root directory are good candidates on Windows systems, for example. But then again, even these filenames are highly suspicious when found on removable media. So let’s use the next best thing: video files. These also tend to be very large and offer a good disguise for hidden data, but unfortunately, they are very easy to detect: Just try to play such a pseudo-video file and whatever player you use, it will tell you that something’s wrong.

So what we really want to call it proper steganography is a usable file that can be opened with standard software so it doesn’t raise any suspicion, but when opened in TrueCrypt with the right key, it should reveal the real payload – a filesystem full of secrets. Video files are the natural choice as for this kind of hack: Multi-gigabyte videos are completely common nowadays and encoders are so good that even large differences in bitrate don’t necessarily mean large differences in quality. In other words: A well-encoded fifteen-minute HD video clip of 1 gigabyte can look just as good as a not-quite-as-well encoded 4 gigabyte version. So let’s put the 3 gigs we can save to good use and store secret data there.

Unfortunately, this can’t be done using TrueCrypt directly. However, with a little bit of file format tweaking, it turns out to be possible anyway. In this blog post, I will describe a method of hiding TrueCrypt containers inside QuickTime / MP4 video files.
Read more …

Choosing the right video format

(January 31, 2011)

There’s a wide variety of devices out there which are capable of video playback – computers, music players, mobile phones, game consoles, you name it. However, all of them support a different set of formats and there’s no combination to catch them all. So if you want to generate a video, you will always have to pick a format based on a selection of devices that are important to you. To make this a little bit easier, I prepared a little tool for you:

Read more …

Video on the Canon EOS 550D

(June 2, 2010)

A few weeks ago, my father bought a shiny new Canon EOS 550D DSLR camera, not only for capturing photos, but for videos too. Why not – after all, the video functions are finally taken seriously by the camera manufacturers and video on a APS-C-sized sensor is a very cool thing – in theory. I had the chance to analyze a few 720p/50 sample videos made with the camera, and I have to say that I’m quite disappointed.
Read more …

Breakpoint 2010 Party Report

(April 11, 2010)

It was the end of an era: On April 2-5, 2010, the last Breakpoint demo party took place in Bingen. After 8 years of partying (6 of which I personally participated in), the main organizers decided that they need a break, so 2010 was the final event. Fitting to that situation, the party had the motto »like there’s no tomorrow« – and having a party like there’s no tomorrow is indeed what the visitors did :)
Read more …

Video encoder comparison

(February 25, 2010)

There has been some buzz about HTML5 web video lately. I won’t retell the story here, because it’s almost completely political and not technical, while I’m only interested in the technical side of things. One thing that struck me, though, is that many people believe that the two contenders, H.264 and Ogg Theora, are comparative in quality and performance. As someone who implements video codecs for a living, this struck me as quite odd: How can a refined version of an old and crippled MPEG-4 derivate come anywhere close to a format that incorporates (almost) all of the the latest and greatest of video compression research? I decided to give it a try and compare H.264, Theora and a few other codecs myself.
Read more …

My new (sort-of) home theater

(January 17, 2010)

Over the last few weeks, I upgraded my old TV set to a shiny new LCD TV, along with a 5.1-channel AVR and a Blu-ray player. This was done for two different reasons: First, I wanted a HDTV set for quite some time already, but I waited until it was safe that I could afford it. Second, the old TV set, which was the already repaired former set from my uncle, started to behave erratically again, so it was obvious that I needed a replacement anyway.
Read more …

Movies 2009

(January 2, 2010)

I love going to the cinema after work: The Tuesday afternoon showings at my local cinema are quite affordable, and for most movies except the biggest blockbusters, the auditorium is usually almost empty. This enables me to enjoy a movie without being disturbed by laughing kiddies and popcorn chewing noises :)
Here’s a list of all the movies I’ve seen this year, along with a short comment or rating: Read more …

pdfgen, an image-to-PDF converter tool

(December 14, 2009)

Converting images of scanned documents into proper PDF files is quite a hard task. What I usually want is

  • put the images on a page of a well-defined size (e.g. A4 or Letter)
  • don’t resample the image data
  • have precise control over compression – in particular, I want to use JPEG images as-is, without any recompression

This sounds simple and reasonable, but I’ve yet to find a tool that does exactly that. Adobe Acrobat handles the latter two constraints well, but I don’t know how to set the paper size when importing an image. This is no problem when using a normal vector graphics or page layout tool, but then you usually don’t have much influence on what nasty things the PDF output code does to your images. Furthermore, you mostly end up with useless cruft in the PDF files, like XML metadata or even fonts (even though there’s not a single letter of text anywhere in the document). So I decided to end this mess once and for all and write my own image-to-PDF converter. Here it is: pdfgen.
Read more …

Technical details about »Applied Mediocrity«

(September 4, 2009)

As you may or may not have noticed, my latest intro won the PC 64k competition at Evoke 2009. Unlike my previous demos and intros, it actually featured a few effects that go beyond fixed-function rendering or per-pixel lighting. For all who are interested in how it works, I’ve written this small article that explains how each of the eight effects in the intro is done, as well as some general insight into the creation process of the intro.
Read more …

Proposal: A file system for Live CDs

(August 20, 2009)

CDs or DVDs containing a full Linux system for installation, testing, repair or other special purposes are quite common these days. Chances are high that people make their first steps with the Linux, BSD or Solaris operating system using these so-called Live CDs: They are convenient (no need to install the OS), they are safe (doesn’t write anything to disk unless you really want it to) … but they are slow. Booting from a Live CD like Knoppix or the Ubuntu Desktop CD takes ages and makes you wonder if your CD/DVD drive will actually survive that whole operation, considering that it is permanently seeking. And even if you made it to the desktop, you’ll still have to be patient if you intend to open any application, because the drive has to spin up again and load libraries and data for whatever program you start. Or even worse: In the modern GUI-based environments you have to wait for icons to load even if you just click on a launcher menu. As useful as those Live CDs might be, this a major source of annoyance.

In this post, I will present a method to solve this problem. I do not claim to be the first one to invent it – in fact, I refuse to believe that no one had this idea before me.
Read more …