Jun 5, 2016 - backdoorctf16 : Imagelover

Author: dade

Publish Date: 2016-06-05

Category: Web Points: 70 Description:

Find imagelover here
Created by: Amanpreet Singh


We’re told that admin will visit our page with the flag, so we just need to submit something that we control so that we can watch the traffic come to our server.

Being the fond Hackers (1995) fan that I am, I’ll use my playground vps, gibson.zerocool.io to serve up a file that we can sniff traffic on. I’m using the gibson subdomain because I have ssl enforced on zerocool.io and wasn’t sure if tshark would be able to read the content as it came in, or if it would just show up as ssl packets.

Instead of sniffing all our traffic though, let’s get the IP address that imagelover will likely be coming from.

dig a hack.bckdr.in


From here we now have what we need to fire up tshark and listen to the traffic coming into the server.

[email protected]:/home/dade# tshark -i eth0 -x host

Now that the sniffer is running, we submit http://gibson.zerocool.io to the imagelover input.

Running as user "root" and group "root". This could be dangerous.
Capturing on 'eth0'

[Packet Capture omitted. Do it yourself :)]


This challenge is hosted permanently at Backdoor, so go find the flag yourself!

May 31, 2016 - TJCTF 2016: Torrent

Author: aagallag

Publish Date: 2016-05-31

Category: misc Points: 90 Description:

Help, someone’s sharing flags.


For those of you who may be living under a rock and have never heard of BitTorrent, I recommend skimming through the BitTorrent and Torrent file wiki pages. But to give a brief overview, torrent files don’t actually contain the desired file. But rather, they provide information to a Torrent client about how to download the desired file from peers on the internet. But how does your torrent client find suitable peers? Traditionally, the .torrent file contains the address to a torrent tracker that keeps track of who is downloading the file and who is currently sharing the file.

So I started by loading up the file into my torrent application to check and see if it will download anything.

Hmm… Doesn’t seem like the torrent is downloading anything, let’s poke around the torrent properties to see why.

Let’s start by checking out the trackers.

Oh great, there are no trackers. How can the file be downloaded without any trackers? It turns out there have been new protocols applied ontop of torrents to allow peer discovery without trackers, checkout the DHT and PEX wiki pages for more information on these protocols.

Perhaps, to solve this challenge, we have to find the tracker or peer hosting the file. SPOILER ALERT: this was not the correct approach.

By default, I like to keep the peer discovery protocols disabled due to privacy concerns (for those concerned with privacy, you probably shouldn’t be using BitTorrent in the first place). So for the duration of this challenge, I went ahead and enabled them.

Hmm… Still, my client doesn’t download the file. So I checked out the peerlist. After running nmap on some of the peers, I noticed one of them was hosting a torrent tracker. So I tried to set that peer as my tracker, but still, the file didn’t download. After noticing all these peers were hosting different services, and running different OS’s, I realized these peers were unlikely to be hosting the flag, but instead, I’m pretty sure they were other participants in the CTF.

Oops… before I get kicked out of the CTF for hacking other contestents, I decided to take a step back and stop attempting to download the file altogether.

Let’s see what information the *.torrent file reveals about the file.

Hmm, looks like *.torrent file contains the SHA1 hash of the file. This is required by the Torrent client so that once it has finished downloading the file, it can verify the integrity by generating a hash of the downloaded file and comparing it with the expected hash.

What if I try and work backwards from the hash? I could pass a bunch of random data into a hash function until it computes to the same hash. Nope, that would take too much time for any unique string larger than a few bytes.

Good thing I know a little bit about the BitTorrent protocol. My client doesn’t show it, but in addition to the entire file, the sha1-hash for each piece is also stored in the *.torrent file. That way, in the event that your client detects that the downloaded file is corrupt, it doesn’t have to throw out everything and start from scratch. Instead, your client checks the hash of each piece and re-downloads only the piece(s) that failed.

Using this knowledge, I realized that if the pieces are small enough, I could resolve the hash back to the piece a lot quicker than attempting to crack the hash for the entire file.

However, my Torrent client isn’t showing me enough information, I need to find a way to extract more details.

I found this cool Python project that parses torrent files and generates an HTML report, called bittorrent-parser.

To setup and run the tool…

$ git clone https://github.com/Resistor52/bittorrent-parser.git
$ python ./bittorrent-parser/parse-torrent.py flag_d542574c3e963792fe07321fd262fe28e6f5cf0ea126efe01148dd6890b63a4d.torrent 

After runnning the tool, I load up output.html into a web browser.

Wow, I wish this had been my first step, this parser is a lot more precise and verbose than your average torrent client.

I notice that the announce url (torrent tracker) was set to, that explains why the file could not be downloaded. Next I see that the exact size of the flag file is only 28 bytes with 14 pieces. Each piece is only 2bytes long! That’s great, cracking the hash for a string whose length we know to only be 2 is WAY quicker than attempting to crack the hash for the entire file.

So now I have to simply figure out which two bytes results in each SHA1-hash. Once I have each 2byte piece, I simply put them together to recreate the original file. Next section will show how I went about doing that.


Since I know the file is only 28 bytes long, I predict that this file doesn’t contain any binary data. So I make the assumption that this is a plaintext ASCII encoded file. So to speedup the cracking process, I only search for values in the ASCII range of 0->126. There are additional modifications that I could have made to ensure that the cracking process would be fast, but this implementation was sufficient for solving the challenge.

#!/usr/bin/env python
import sha

# hashes for each piece of the torrent file

def crack(shahash):
    for x in range(127):
        for y in range(127):
            attempt = chr(x) + chr(y)
            res = sha.new(attempt).hexdigest()
            if res == shahash:
                return attempt

    raise Exception('Failed to crack the hash: ' + shahash)

def main():
    flag = ''
    for i in PIECE_HASHES:
        flag += crack(i)

if __name__ == "__main__":


Run the script to get the flag.

$ ./torrent_hash_cracker.py 

May 20, 2016 - TU CTF 2016: The Nack

Author: aagallag

Publish Date: 2016-05-20

Category: Forensic Points: 100 Description:

Attached file


I load up the capture file into Wireshark and start by checking for HTTP objects with…

File -> Export Objects -> HTTP...

Unfortunately, there aren’t any HTTP objects found.

After checking for HTTP objects, my next step when working with packet captures is usually to inspect the individual TCP streams.

Right Click Packet -> Follow -> TCP Stream

TCP Stream 0

Looks like the traffic may contain a GIF file, but why does it start with ‘GOAT’?

TCP Stream 1

Wireshark lets you quickly switch between the different streams by increasing the Stream counter at the bottom right of the pop-up window. Scrolling through the first couple TCP streams reveals a pattern.

TCP Stream 15

It looks like all of the streams start with the same 4 bytes, ‘GOAT’ followed by the byte 0x01.


Now that I know the pattern, I threw together a simple Python script that looks for all occurances of ‘GOAT’ followed by 0x01 and then writes the proceeding 4 bytes to a file.

#!/usr/bin/env python

# read file contents into memory
f = open('ce6e1a612a1da91648306ace0cf7151e6531abc9.pcapng', 'rb')
content = f.read()

#split on 'GOAT' + x01 byte (skipping the front part of file before GOAT starts)
goats = content.split('GOAT\x01')[1:]

#write the TCP data to a new file
f = open('goats.data', 'wb')
for i in goats:
	#data is in first 4 bytes, 5th byte should be null
	assert(i[4] == '\x00')
	data = i[:4]


print('Goat data extracted...')

Next I wanted to confirm that my initial suspicion was correct about this being a .gif file.

$ file goats.data
goats.data: GIF image data, version 89a, 590 x 225

Great, let’s see what the image looks like…

$ mv goats.data goats.gif


I don’t see a flag there… Maybe it’s hiding in a single frame of the .gif and the flag is flashing too quickly for me to see it. So let’s extract each frame of the gif into seperate, non-moving images.

$ convert goats.gif out%05d.gif
$ ls out000*.gif
out00000.gif  out00005.gif  out00010.gif  out00015.gif  out00020.gif  out00025.gif
out00001.gif  out00006.gif  out00011.gif  out00016.gif  out00021.gif  out00026.gif
out00002.gif  out00007.gif  out00012.gif  out00017.gif  out00022.gif  out00027.gif
out00003.gif  out00008.gif  out00013.gif  out00018.gif  out00023.gif  out00028.gif
out00004.gif  out00009.gif  out00014.gif  out00019.gif  out00024.gif

I check each frame of the gif, the 17th frame(out00016.gif) reveals something interesting…