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
$ python ./bittorrent-parser/ 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 =
            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.

$ ./