Home » CTF

Ghost in the Shellcode 2015 CTF – cloudfs writeup

19 January 2015 No Comment

Hello, Internet!

In this challenge, You are given a cloudfs file it was an xz archive
Extract it and you get cloudfs-31c938df3531611b82fddf0685784a2b67373305ec689015f193a555b756beb21 a network capture dump
I opened it with wireshark and search for the word “key”
I get an ICMP packet with the content: key.tbz
That’s a hint telling us to search for bzip2 = content in the dump
I searched in the packets for hex value “42 5a” which is ascii “BZ” and it’s the start of the bzip2 file header.
I found that repeated too much times towards the end of the capture packets.
So i tried to weed out the duplicates and got 4 unique packets, with the same payload repeating over and over, 3 unique packets with frame length 1066, and 1 unique packet with frame length 134.

But there is two things to note:

1-They are not always in the same order.

2-The packet with “BZ” in it, doesn’t start with “BZ”

So i split the packet content into two parts, the start of the file until before “BZ” and “BZ” and whatever data that follows.

Now i have 5 parts which the solution must contain some of them, and in an order i don’t know.
So i wrote a little script using python to generate all the possible combinations of the data and put them into a file.

After running the file i got hundreds of files… how would i know the right file?

Uzing bzip i tested all files: bzip2 -vt *
Sample of the errors:
” 25143.bzt: bad magic number (file not created by bzip2)”
” 31245.bzt: data integrity (CRC) error in data”
” 314.bzt: file ends unexpectedly”
” 34152.bzt: trailing garbage after EOF ignored”

The last error looks more interesting than the other errors, so i tried to open the file but i get an error.

So i tried to repair the file: bzip2recover 34152.bzt
bzip2recover 1.0.6: extracts blocks from damaged .bz2 files.
bzip2recover: searching for block boundaries …
block 1 runs from 80 to 25066
block 2 runs from 25115 to 32768 (incomplete)
bzip2recover: splitting into blocks
writing block 1 to `rec0000134152.bzt.bz2′ …
bzip2recover: finished

And the output is a file with the type:
rec0000134152.bzt: application/x-tar; charset=binary

I untar’ed it and found a file named “key” containing the flag: “key{WhyWouldYouEverUseThis}”


In retrospect i could’ve made the script to always start with p3 (the one with the right header)

Original challenge file CLOUDFS

The script i used to generate the files: uncloud.py

Your opinion matters!

Add your comment below, or trackback from your own site. You can also subscribe to these comments via RSS.