Better Data Hiding

The addition of offsetting the data is proving to be a more difficult problem than expected due to the way addressing bits was optimized for speed. Turns out I need to rewrite a large number of the functions used to encode and decode data. This change is still a work in progress and wont be committed until it doesn't prevent compilation.

Changes in the works

Recent changes to the repository have included mostly small bug-fixes, corrections in debugging messages, and the prevention of possible double-frees. Also, the start of a GUI has been added to the repository.

I've been working on figuring out the structural changes I need to make to have the option to better hide a data stream, it is proving interesting.

Which is Which? - Answers

Here are the answers to the question from the last post:

• Clip 1 is the original sound file
• Clip 2 is encoded with AES-ECB and scrambled lower 1 bits
• Clip 3 is has nothing encoded, but scrambled lower 1 bits

If you look at the clips visually with a sound editing program they all appear the same even at extreme zooms:


The audio clips sound the same as well, so how can you tell them apart? As it turns out the original WAV file compresses better than the files with the scrambled lower bits (43% vs. 38%). After you narrow down the data to clips 2 and 3 you could then extract the lower 1 bits from each and perform an analysis on them. The AES encyption method that we used (and are replacing) is block based and leaves a detectable pattern. Once you figure out how big the block of data is you could then turn to traditional means of breaking AES.

From here on we are working on replacing AES ECB with a better AES algorithm in an effort to reduce detectability. We are also investigating ways to reduce the randomness of our random data padding so that the compression ratio is the same as or similar to the original file's ratio.

Which is which?

Last night I took an audio clip and I ran it through Awesome-WAV two times. Once was with a 80 byte data file, and once was without any data (to scramble the lower bits).

The clips

Is it possible to determine which clip is which? If you can figure it out, then send an email to awesomewav@gmail.com with your answer. In your email note which clip is the original, which contains data, and which contains no data. Also let us know how you figured it out.

*It is pretty easy to determine which file is the original

awesome-wav 1.1.0

I am pleased to announce the release of awesome-wav 1.1.0. This is an intermediary release that mostly adds new features and fixes a few small bugs in behavior.

There are two major changes in this release. The first is supporting compression with quicklz as well as zlib, with options to not include zlib compression. This decreases compression time, though increases file-size by a bit. The other significant change is allowing wav files with unknown wav chunks. The current implementation just discards the unknown chunks, something that will be changed by the next major release.

This release also fixes various behavior bugs and will allow the chunks of the riff file to be read in any order instead of a fixed order.

awesome-wav 1.0.1

I am pleased to announce the release of awesome-wav 1.0.1. This is primarily a bug-fix release, fixing issues with wav file validation and a few other random minor bugs. This release also includes the somehow forgotten --version argument.

the argument processor was also back-ported from the under-development 1.1/1.2/1.5 code as it is a little more flexible and includes some other various code modifications that have no effect on the actual operation of the program.

cmake

I've been working on adding cmake as an option to assist with building awesome-wav. Currently the only target that works right (only been tested by me on Debian Squeeze) seems to work right at the moment.

If anyone would like to test it on mac os or windows, that would be greatly appreciated, and input on improving the CMakeLists.txt file would be appreciated as well.

How AES Encyption Works

I was doing some research a couple of days ago and I found a very nice visualization of the Rijndael Cipher. It was chosen as the Advanced Encryption Standard (AES) by the National Institute of Standards and Technology (NIST) in 2001.

awesome-wav 1.0.0

awesome-wav 1.0.0 has been released. It supports encoding into 8, 16, 24, and 32 bit PCM WAV files, 32 and 64 bit IEEE float WAV files, compressing the input data using zlib and data encryption with ECB AES.

Release includes 32 & 64-bit *nix binaries and 32-bit Windows binary.

awesome-wav download

Release 1.0 Prep

We've been fighting with a couple barriers to the planned 1.0 release of awesome-wav. Currently the biggest project is setting up cmake as suggested by David Doria among other things. Hopefully the release will be ready in the next week or so.