# ASIS CTF Finals 2023 Write up - White & Blank

## Step 0: Reconnaissance

We have a file called "White & Blank". We don't know what type of file it is, and nothing seems interesting in the file's metadata, so let's take a look with a hex editor. For me, I used HexEd.it:


We see that some of the bytes translate to some text, Googling the text will show that the file is in a format called OpenEXR[^1] (Might have to scroll down a bit or add more keywords):


So, now we know it is an .EXR file, how to do we open it?


For this challenge, I will be using GIMP[^2], a free and open source image editor. But when we try to open the file, we get this:


:::warning
Seems like the file is corrupted. What now?
:::

## Step 1: File Signatures

Usually when a file is corrupted, especially an image file, that means some of the bytes in the file are modified and are incorrect.

Remember the official documentation we looked up? That might come in handy. Usually when dealing with these types of forsenics challenges, we first check the **file signature**, otherwise known as header/magic bytes.

:::info
### What is a file signature?
A file signature is used identify or verify the content of a file. It is usually located at the beginning of files.
:::

Taking a look at the official OpenEXR documentation, we can find this in the page where it mentions about the file layout:


Now, when we take a look at our file's bytes again:


:::info
76 2D 3F 01 02 00 00 00
:::
We can clearly that the header bytes has been modified, which should be the cause for the file corruption. In theory, if we repair the header bytes, we should be able to view the file in GIMP.
:::success
76 2D 3F 01 02 00 00 00 ---> 76 2F 31 01 02 00 00 00
:::

If we try opening it, we get:
:::warning
We fixed the header bytes, but the file is still corrupted. Now what?
:::

## Step 2: Searching for More Bytes
The EXR file is still corrupted, so this could mean:

1. There are more things to be repaired.
2. The file is unrepairable, and we have to use other methods to extract the flag.

For now, let's assume it is case 1. But how should we find out what we should fix? One method I like to use is to compare the corrupted file bytes with bytes from a non-corrupted file.
:::info
In other words, it might useful to compare the corrupted EXR file with a normal EXR file.
:::

Luckily, the official OpenEXR documentation also contains some "Test Images" that we can use to compare with the corrupted file. I chose the "Rec709.exr"[^3]. image for comparasion.

If we take a look at their bytes:


You may see a subtle difference between the 2 images. I will leave the solution in the spoiler tag so you may try and spot the difference.

:::spoiler
If you look closely, you can see that the bytes for "Rec709.exr" and "White & Blank" at the location where it says "compression compression" are different.

One is "compression compression" and the other is "compression&compression".

The correct one is "**compression compression**".

Now, we just have to change the "&" to " ":
:::info
26 ---> 00
:::

After finding the error and correcting it, we can try opening the EXR file again:


:::success
We finally have some progress and got a 1335x37 image, but where do we go from here?
:::

## Step 3: Looking Lower
It seems like there is nothing hidden in the image, even after some image processing. So we might have left something out in the bytes of the files.

Scrolling down, we see something weird:


Once again by comparing the EXR file to other images, it seems like this "GFIP" is not present in any other of the EXR images, also the bytes near the "GFIP" look very similar to another file signature:


Could it be that another image is hidden inside the EXR file? Let's try to extract it by deleting the bytes before "00" and repairing the header bytes, then try exporting it as a JPEG:

 (<--- That is the image)

We get a 257x1 JPEG image, which seems weird as the file size suggests that the image should be a lot larger.

:::info
Could it be that the image's dimensions has been modified?
:::

## Step 4: Fixing Dimensions

After even more Googling related to JPEGs, you might find some information to how to modify the height and width in a JPEG file[^4].

In short, we should be able to find the following set of bytes, which dictates which bytes we should modify to edit the image height and width.

*Credit: Jason Scott, Hiding Information by Manipulating an Image's Height*[^5]

Looking back at our JPEG:


We can now try to modify the image's width and height. But what should their values be? Let's try 1335x37, the dimensions of the EXR image.

After modifying, we get the following:


It seems like this is the flag, however the image width still seems wrong. At this point, we can try to brute force the image width until we get the flag. The correct image dimensions is in the spoiler tag.

:::spoiler
:::info
The correct width and height should be 1523x37.
:::

::: success
Once you repair the image, you should get the flag!
:::

[^1]: Official OpenEXR Documentation:
https://openexr.com/en/latest/

[^2]: GIMP Website:
https://www.gimp.org/

[^3]: Rec709.exr Image:
https://openexr.com/en/latest/_test_images/Chromaticities/Rec709.html

[^4]: JPEG File Layout and Format
https://mykb.cipindanci.com/archive/SuperKB/1294/JPEG%20File%20Layout%20and%20Format.htm

[^5]: Hiding Information by Manipulating an Image's Height
https://cyberhacktics.com/hiding-information-by-changing-an-images-height/