This time I'll focus on the legacy version though. We will investigate what the encrypted container bytes may;
- Look like in a bmp image.
- Sound like in wav track.
- Look like when turned into a raw video format like yuv.
The three examples we will go through are similar to the procedure described in example 4 of the previous blogpost referenced at the top. That is with a method like http://keyj.emphy.de/real-steganography-with-truecrypt/ where the container is a hybrid file that fulfill the structure of another file format and still works as a VeraCrypt container that can be mounted. The hybrid files can thus be managed in multiple ways.
For the examples I whipped together som code to prepare such containers. They can be found in the usual place at https://github.com/jschicht/MakeContainer Look out for those with names having -Legacy appended.
1. Encrypted bytes as a bmp image.
First create the container in VeraCrypt and use hidden volume feature, because we can't really use the standard/normal volume when used in a bmp. The reason for that is because the header is overwritten with the BMP header, and the last few bytes in the file may be bytes filled for alignment purpose. The way VeraCrypt works is that when the original header is invalidated for some reason, there is an option to load backup headers (both standard and hidden) from the last 0x20000 bytes of the file. Now in the case of the bmp trick, both places are tampered with, leaving us with the option to load hidden volume because its header (offset 0x10000 - 0x20000 from start) is still intact. Strictly speaking, it is possible to load the backup headers if you have a tool available that can load the encrypted bytes from a defined offset range and present it like a disk. This is what I explained in previous post when using the aim_ll tool from Arsenal Image Mounter. But forget about that for the moment, as we'll do this exploration from a different angle this time. Next download the tool at https://github.com/jschicht/MakeContainer/tree/master/MakeContainer-Bmp-Legacy and turn the container into a bmp. This is how such an image looks like;
It may come as no surprise that there is no obvious pattern to spot. That is of course an important point with encryption, to produce bytes that can't be distinguished from random bytes. I could mention that the tool will let you specify the pixel width, while the height is automatically created based on the chosen width. The reason for the appended bytes is because a pixel line (width) can't be broken or partial. That is, the smaller width, the less bytes you will possibly have to append. The header will look like a regular bmp header like this;
The encrypted bytes start at offset 0x36. It is worth noting that the way bmp works, is that the original (pixel) bytes are flipped 180 degrees on the X, and then turned upside down. When creating the special containers we obviously can't do that because it would break the VeraCrypt format. We thus need to make the bytes on disk as they are expected by VeraCrypt, but the bytes are distorted visually as interpreted and displayed through the bmp (inverted). But that does not really matter for the view right now as random data will still look like random data on the pixel side regardless of whether it is flipped 180 degress by X or turned upside down.
Mounting the encrypted container fairly easy. Just load the bmp into VeraCrypt and provide the password for the hidden volume.
2. Encrypted bytes as sound in a wav.
Create the container in VeraCrypt. You can use both standard and hidden volume with this file format. Similarly as with bmp, parts of the header is overwritten. Here's what the header may look like;
Fortunately with the wav format, there is no need to align data size. We can therefore use the backup headers for the standard volume. Usage of the hidden volume is just like normal. Go to https://github.com/jschicht/MakeContainer/tree/master/MakeContainer-Wav-Legacy and download the tool. There's an option to configure the number of channels. The tool will then output a ready made and valid wav to be played. At this point you might be wondering what it really sounds like. Here's a sample; https://drive.google.com/file/d/0B1M9FFDeCvMpUVVzOXdZRnRtUmc/view?usp=sharing The password of the standard volume is "joakim". It plays fine in Windows Media Player;
and also in VLC;
In order to mount the standard volume, we must use the backup headers. Configure the mount options like this;
The interesting thing with wav is that you can burn your "sound" compilation onto a CD, and still mount the encrypted container directly from the CD. For that we would need to also turn on the read-only mount option;
As already mentioned you can use both standard and hidden volumes, and since I used the backup headers in the above screenshot, it's because I was mounting the standard volume. As seen in the next screenshot, the sound file plays fine and VeraCrypt can mount the volume too;
3. Encrypted bytes as a raw video file.
First prepare a volume. With this method we also have some restrictions to handle. Due to the way raw video files and yuv in particular are built, is that there is no real header as with most other file formats. You simply need to know what frame size and type the file is expected to be in, and then just pass the parameter to the player. To strictly adhere to the specific encoder it is supposed to be in, the file may need some bytes appended. For this reason, you can use both standard and hidden volumes, in the normal way without using backup headers. In fact, the backup headers may not work at all because of the reason just explained. Get this tool https://github.com/jschicht/MakeContainer/tree/master/MakeContainer-RawVideo-Legacy for the preparation of the container. There you will have the option to specify the XY dimension of the video, and the tool will align file size according to the chosen XY and the rgba or yuva444p format. The output filename will contain the details to play it properly. In order to play the yuv file, there are a few options. For instance;
#1
vlc --demux rawvideo --rawvid-fps 25 --rawvid-width 320 --rawvid-height 240 --rawvid-chroma I420 file_320x240_rgba.yuv
#2
ffplay -f rawvideo -pixel_format rgba -video_size 320x240 -framerate 25 file_320x240_rgba.yuv
#3
Or this gui tool; https://sourceforge.net/projects/raw-yuvplayer/
When playing with raw video it quickly became evident that these players actually will attempt playing anything you feed it. The video will mostly look like with the bmp sample;
The concept of data hiding is far from new. A few related links worth mentioning;
- https://www.codeproject.com/Articles/6960/Steganography-VIII-Hiding-Data-in-Wave-Audio-Files
- https://www.codeproject.com/Articles/5294/Steganography-IV-Reading-and-Writing-AVI-files
Lastly I will stress the point that even though the encrypted container is masked within another file format, it is relatively easy to spot that there's something strange about it when you investigate the file.
No comments:
Post a Comment