*The hint is referring to this awesome web-comic. *

To begin the challenge, we are given a file named jareth1.gif

The thumbnail makes it look like a valid gif, but is it?

The file opens and animates fine.

Opening the gif with a hex editor, the header looks like a regular gif header.

Scroll to the bottom, and this file is missing the standard gif trailer of 0x3B. (Read more about what’s in a valid gif.)

The hex values at the end are not the standard gif trailer.

There is data appended to this gif.

So what do we do with this information? One trick I like to employ with tampered image files is to do a reverse image lookup via Google. I upload the jareth1.gif file to google image search and get this back:

Clicking through a few of the visually similar images we find this gif. It animates the same and has the same dimensions as our jareth1.gif but a different size.

When diffing the two gifs, we can see that the original gif ended at offset 0x3436D with a valid trailer of 0x3B. Some shellcode and malware authors like to hide data by XOR-ing it with single or multi-byte hex values. Since it appears that the 0xAA bytes are repeating at the end of the file, and some data typically contains nulls, lets XOR the entire file by 0xAA.

Now let’s look at the leftover data’s header:

Based off of the header, it appears that the hidden data is a 7zip archive. Let’s save off this XOR’d data to another file.

One trick I like to use is 7zip’s ability to unzip files when the header is in the incorrect place. Simply use the command line or right click and select 7zip -> Extract here.

Decompressing that file gives us another file simply named “file”.

Taking a quick look at the header we see that this is an html file.

Renaming it to file.html and opening it with a browser yields this glorious ASCII art of David Bowie:

So what now? There’s no obfuscated javascript, just a seemingly incomprehensible mess of html. It also looks as if there is a repeating pattern of A7 A0 bookending some other data.

Let’s drop a section of that hex looking data into a hex editor:

None of it renders into ASCII, let’s try XORing it with 2 byte 0xA7A0 to see if there’s data underneath:

Still nothing to work with, but it does look like it could possibly be ASCII text.

Let’s undo that and try again with the original single byte 0xAA:

Much better. The text renders as:

Write a YARA rule to find normal valid GIF files.

Using the template below:

1. replace each “**” pair in $header with the appropriate 6 bytes.

2. replace each “*” in $trailer with the appropriate regex.

3. replace the “*” in condition with the appropriate digit.

rule valid_gif : valid_gif
{
        strings:

			$header = { ** ** ** ** ** ** }
			$trailer = *******
				
        condition:
			$header at * and $trailer
}

Using the information about proper gif structure we write the following correct rule:

rule valid_gif : valid_gif
{
        strings:

			$header = { 47 49 46 38 39 61 }
			$trailer = /\x3B$/
				
        condition:
			$header at 0 and $trailer
}

After reading this article about what’s in a gif:

  1. The header is self-explanatory.

  2. The regex format is required here to make sure there is no following data after the 3B

  3. And of course the header has to be at the beginning of the file at position 0

Submitting the rule above will result in the key: PAN{848Y_wIsh3D_4w4y}