Description: An infiltrated russian spy has sent us a file that indicates the name of a Doctor of great relevance in the advanced projects on Artificial Intelligence (IA). According to an intelligence report, we should omit the place where the information leak occurred: the Massachusetts Institute of Technology.
Hint (-75 points)
The magic numbers are very helpful as is the ASCII code of the PNG images.
There is a clue in the course of the resolution of the challenge, observing in the ASCII code. This steganography must be applied.
(1) ANALYSIS OF THE FILES WITH AN HEXADECIMAL EDITOR
Once decompressed, the provided attachment contains the following 25 PNG files:
But unfortunately we are not able to display any of them. As we can see using an hex editor, the headers seem to be corrupted because there is no trace of the PNG magic numbers before the iHDR chunk on each file. The magic numbers have been overwritten with other strings. Checking all the files in alphabetical order reveals the following:
If we merge all the ASCII strings at the beginning of each file, we get the following fake flag:
And now the last files, which do not reveal anything interesting:
We decode the base64 string found in the 'snworks-logo-facebook.png' file:
After some investigations, we conclude that the second part of the decoded string 'rfghqvnqb ra pnyvsbeavn' is cyphered using a simple ROT13 cypher. Decyphering it is easy:
So it seems that we found a hint:
Me encanta la IA, estudiado en california
(2) REBUILDING THE PNG FILES
The next step was rebuilding the PNG files in order to be able to display them and look for more information. The magic number of a PNG file is '89 50 4e 47 0d 0a 1a 0a' and we can easily see that its length is just the amount of bytes overwritten on each file. In order to restore the magic numbers in all the PNG files we use the following script:
However, after the restoration process and using the 'pngcheck' tool we see that there are still 3 files with errors:
Examining in more detail 'Cookies.png' and comparing it with other successfully restored files, we see that it has a slightly different structure:
Using the HxD hexadecimal editor in Windows, we insert the hex values '00 00 00' before '49 48 44 52'. The image is repaired but once displayed it does not reveal anything interesting.
Examining the file '4DO1rnQ83ny.png', we see that there is no iEND chunk at the end of the file. This chunk is compulsory for PNG files. The file contains the following strings at the end:
Using our hex editor, we overwrite 'BAT#' with 'IEND' and the image is repaired, but again we don't see anything of interest.
And finally, as we saw with 'pngcheck' the file 'snworks-logo-facebook.png' contains a CRC error in an iDAT chunk:
We overwrite the wrong CRC 'f1779cd6' with the expected one '23e5ddc7' and we are able to display the file. Nothing interesting.
(3) HOMING THE MISSILE
At this point, lots of stego tools were used against all the PNG files, to no avail. But then if we read again the hint we got from the decoded base64 string:
'Me encanta la IA, estudiado en california'
We see that there is precisely a file 'ucal-fb-image.png' that once displayed shows an University of California logo. If we zoom in the file, on the bottom left part we can see what it seems to be a part of an string. Using a contrast filter with the image reveals the following hidden hex string:
If we try to decode the hex string to ASCII, we just get rubbish and lots of non-printable characters.
In order to decode the string, we tried other techniques as well, to no avail:
Converting the file to binary and trying to carve possible hidden files within it.
Using the 'xortool' tool to try to determine possible simple stream cyphers and key lengths.
Decomposing the string in adequate length substrings and performing mask attacks against each one of them, considering them as hashes.
In the end, we decided just to reverse the string:
And tried to decode it from hex to ASCII using Python, this time successfully:
It looks clearly as a base64 string, so we try to decode it:
We get what it seems to be a new base64 string. Due to the fact that recursive encoding seems to be in place, we used the following script in order to recursively decode in base64 looking for a 'fwh' string on each iteration, which is our flag format:
Once executed, the script reveals that base64 encoding was used 3 times: