HackIM 2016 Forensics 200

This challenge was pretty fun, there were a couple of dead ends/tricks.
The first step was to take a look at the packets. You can quickly notice that a ton of files are being grabbed using Wget (seen in the user-agent below). These can be exported using Wireshark’s File -> Export Objects -> HTTP.

The request URI shows what to expect in the files you extract from the packets.

Exporting HTTP objects from the packet capture

When I listed out the files I noticed that there were a couple which were named with shorter, related strings. Running file on those particular files showed that they were all associated with either an archive or some data.
The 3 character file names really stand out

All of our short name files are associated with archives

After extracting and searching through a couple (initially focusing on caa, cae because they return “flag.txt” when running strings), I tried to extract the bab file using arj.

Arj extraction of bab.arj failed
The extraction failed when just trying to arj -e bab, so I figured that baa and bac may be extra pieces of the archive. I cat’d together bab,baa,bac (in that order), and again got a failure.

cat bab baa bac > bab.arj
Finally, after putting them together in the order bab,bac,baa the extraction worked properly. The file f2 was extracted which is a BTRFS volume which I mounted to the directory f2dir.
F2 extracted after “cat bab bac baa>bab.arj”
F2 was, like all other archives in this challenge, full of more randomly named files. I run the following command to look for interesting strings in the entire subdir:
find -type f -exec strings {} \;
Which found some interesting strings belonging to a PNG
As seen in the screenshot above, some interesting PNG tEXt comments were found in one of the files, so I narrowed my search, found an ARC archive, and extracted the files:

grep -R ‘f-l-a-g’
Binary file vaQ1Dg/7JLc3R/ktCBdI/az7zY6/OdzAzw/abcde matches
file abcde
abcde: ARC archive data, packed
unar abcde -o derp

Looking into the ./derp/abcde folder shows the expected PNGs, some of which can be seen below. Essentially it was a bunch of broken strings trying to spell “f-l-a-g{lossless_data_compression}”. Since no PNG was complete, I couldn’t be sure, so I ran strings again on all of the files.
Broken flags
strings * | grep ‘f-l-a-g’

All of the ‘f-l-a-g’ strings

Again, we see a bunch of broken flag strings, though one of them is complete. When submitting flag{lossless_data_compression} to the challenge, we get a wrong answer. Lame. So the only other interesting flag here is the “f-l-a-g{sha512}”, which I suspect means we will have to grab the sha512 sum of that particular PNG.

grep ‘sha512’ *Binary file 07bb9 matches
sha512sum 07bb9 
Input the flag with the sha512 sum above and scored the 200pts!