GCHQ Challenge - Stage 4

Stage 4 looks very interesting. http://www.theregister.co.uk/enigma2013 has a picture of (I think) a Colussus machine from Bletchley during the war (need to check that… I have a book about Colossus downstairs; I think I recognise the “Heath Robinson” tape mechanisms in the back of the picture). There’s nothing else on the stage page, so I guess the solution is hidden in the picture somewhere/how. Perhaps a form of steganography.

No time to do more now, but roughly I plan to:

1. look at the image format and metadata to see if there’s anything obvious (whether plaintext or obviously ciphertext)
2. read up on the image format to see if there are elements of it that don’t match the format that might suggest where data is hidden
3. find a tool that can check for “image alterations”
4. Open it in Gimp and zoom in and LOOK for the answer just printed there very small!)

Afternoon update…

So I decided to work backwards through the list above, since that seemed easiest. Firstly the image itself - even under a magnifying glass (i.e. Gimp Zoom) there’s no explicit message visible in the image). While in Gimp I checked the file metadata - there is none, so no message there, at least until I look using a binary/hex file inspection tool.

There’s one interesting aspect of the file: in the bottom right corner of the image are some vertical and horizontal “artifcacts” - e.g. slight discolourations/lines. These are only obvious when the image is properly zoomed in. What’s interesting is that they are vertical and horizontal on the image - i.e. they are surely not lines on the actual floor when the photo was taken. I think this suggests that the image itself has indeed been tampered with and there is a message hidden inside.

Some googling about “steganography” (hiding messages) suggests that there are some tools out there that should be able to help me at least identify if this is the case, and perhaps even to extract the message. If not - JPEG specs here I come! :(

Shortly afterwards…

Well I found a handful of steganography tools, some online that seemed to handle PNG/GIF’s only, and something called stegdetect that seems widely referenced. I couldn’t download it for Ubuntu from a package server, and when I tried to compile the source code that didn’t work either, but I did manage to get an older version (0.4) for windows in binary form. Sadly when used it to try and scan the image file (comp3.jpg) it told me it was “skipping the file likely due to false positive”.

So, I’ve now started to look at the data in the file itself, guided by http://en.wikipedia.org/wiki/JPEG#Syntax_and_structure and the handy xdd command in linux that does hex dumps of files.

So the spec says that metadata and comments are encoded in sections beginning with 0xFFEn and 0xFFFE respectively.

Grepping for these sequences shows nothing at all in the latter category (even allowing for grep “FF FE” in case the bytes lie across the column boundary of xdd output), and although there are some sequences of “FFE” there’s no obvious message hidden in the subsequent bytes.

Also the “lines” in the image described above have convinced me that the message is encoded/encrypted into the image data itself (rather than metadata) hence the distortion to the actual picture.

I might be onto something already…

So I figured I would simply grep for all of the “section marker” bytes described in the Wikipedia article, e.g. start of file/image, start of frame, etc. and simply work my way through each of the sections - if only to get a handle on the file structure.

What is interesting is that the very first of these I search for (FFD8 - Start of Image) appears twice - i.e. there are two FFD8 sequences, and the second follows immediately an FFD9 which is also a control sequence (End of Image).

 $ xxd comp3.jpg | grep "ffd8" | more
0000000: ffd8 ffe0 0010 4a46 4946 0001 0101 00c8  ......JFIF......
000cbd0: 401f ffd9 ffd8 ffe0 0010 4a46 4946 0001  @.........JFIF..

Now - I don’t see why these sequences cannot appear in the “body” of data (say the image encoding itself), unless that’s explicitly prohibited, but it does seem more than a little odd that you get an FFD8 immediately after an FFD9 if that were the case.

If I search for FFD9 I get this same occurance (preceding the second FFD8) and a second one right at the end of the file:

000cbd0: 401f ffd9 ffd8 ffe0 0010 4a46 4946 0001  @.........JFIF..
000f400: 6319 ffd9                                c...

So this now has me wondering about the following - perhaps the image is not distorted with artefacts after all, perhaps that’s just me seeing what I wanted to see! Perhaps this is as simple as there being two jpeg images - one appended to the other in the same file, but when a jpeg is rendered (e.g. in a browser), when it reaches the end of the image (FFD9) it assumes it has also reached the end of the file and thus doesn’t render a “second image”.

If so I simply need to “split” the file into two parts between the FFD9 and the subsequent FFD8, i.e. (from above) the new file should start from position 000cbd2.

Finally…

First - a confession: I can’t count! The new file needs to start from position 000cbd4 - I was counting each double-byte unit/half-column as one byte when looking at the output from xxd. Oh the shame… :(

After much further messing around with xxd using the -r and -s options to try and split the file at the right place, and then reading in the hex dump again into xxd to create the new binary file I gave up and discovered the dd tool can do what I want directly, so:

cat comp3.jpg | dd bs=1 skip=52180 > secondfile.jpg

this says “use a blocksize of 1 byte and skip 52180 blocks” (52180 being the decimal representation of 000cbd4 - the point at which we want to split the file.

This yields a new file, the “second” hidden file from comp3.jpg which itself IS a jpeg and provides the answer to stage 4:

Link: www.eveningstandard.co.uk/colossus

I think in retrospect I could have guessed the answer to this stage! ;-)

Now to stage 5