Skip to main content

Torrent Analyze picoCTF 2022 Solution

Analyze a network packet capture to identify a file downloaded via a peer-to-peer protocol.

Published: July 20, 2023Updated: August 25, 2026

Description

A network capture shows BitTorrent traffic. Identify which file was downloaded by extracting the most frequent info_hash; the file name becomes the flag.

Open the PCAP in Wireshark and filter for BitTorrent DHT traffic (e.g., bt-dht).

Wireshark has no dedicated bt-dht.info_hash field: the DHT dissector renders the value as a bencoded string and (on Wireshark 4.2 and newer) appends Info_hash=<hex> to the Info column, so read the hashes from there (or from the bencoded dictionary in the packet detail pane). The bittorrent.info_hash field exists only for the TCP handshake, and this capture carries no BitTorrent TCP sessions at all, so sorting on that field shows nothing.

If you prefer the command line, tshark -r torrent.pcap -Y bt-dht -T fields -e _ws.col.info | grep -oE 'Info_hash=[0-9a-f]+' | sort | uniq -c | sort -rn | head ranks the DHT hashes by count instantly.

Feed the top hash to a public tracker search (Linuxtracker, etc.) to learn the file name.

Solution

Want to try it yourself first?

The guided walkthrough reveals hints one step at a time.

Walk me through it
For more PCAP triage workflow (display filters, follow-stream, exporting objects, working with tshark on the command line), see the Wireshark PCAP for CTF guide.
  1. Step 1Locate the info_hash
    Observation
    The capture carries BitTorrent DHT traffic with many info_hash values at differing frequencies. Count the occurrences and take the most frequent, which separates the real download target from routine routing maintenance.
    The capture carries 36 DHT queries that include an info_hash, but only eight distinct hashes: one appears 29 times and each of the other seven appears exactly once. That single repeated hash is the download target, because the client keeps issuing get_peers for it, which dwarfs the one-off chatter for unrelated hashes.
    What didn't work first

    Tried: Picking the first info_hash that appears in the capture and looking it up.

    The first hash you see is usually a routing-table ping rather than the download target; those appear constantly as nodes maintain their buckets. Count how often each hash appears and take the highest, which is the only one representing a real transfer.

    Tried: Filtering by HTTP or TCP instead of bt-dht to find the download.

    DHT traffic travels over UDP rather than HTTP or TCP, so those filters return nothing useful. Use Wireshark's bt-dht filter, which targets the UDP protocol where the info_hash appears. Peer data exchange normally runs over TCP, but this capture contains no BitTorrent peer sessions at all, so the DHT packets are the only place the hash shows up.

    Learn more

    Why the most-frequent hash is the right one. A leeching client repeatedly issues get_peers queries against the target infohash to discover new peers, and it keeps doing so for as long as it wants more peers. The handful of other hashes in the capture are DHT routing-table maintenance: nodes look up unrelated IDs to keep their k-buckets fresh, and each such lookup shows up once. That maintenance traffic is incidental and produces a tail of single-hit hashes. Sort by count and the actual download falls out at the top.

    BitTorrent is a peer-to-peer file sharing protocol. Every torrent is identified by an info_hash: a 20-byte SHA-1 hash of the torrent's metadata (file names, sizes, piece hashes). This hash is the globally unique identifier used to find peers, announce to trackers, and look up files on DHT networks.

    The DHT (Distributed Hash Table) is BitTorrent's decentralized peer discovery system. Instead of relying on a central tracker, peers ask nearby DHT nodes "who has info_hash X?" - these queries are visible as UDP packets in the PCAP. Wireshark dissects them with the bt-dht display filter, exposing the info_hash values being searched.

    Wireshark is the industry-standard network protocol analyzer. Key workflow for PCAP analysis: apply display filters to focus on a protocol (bt-dht, http, dns), add relevant fields as columns for quick comparison, use "Follow Stream" to read full conversations, and export specific packets for offline analysis. It's essential for network forensics and CTF challenges.

  2. Step 2Map the hash to a file
    Observation
    The winning info_hash is a fixed 20-byte SHA-1 with nothing human-readable in it. Look it up in a public torrent indexer, which already maps hashes to file names, rather than trying to decode it.
    Paste the hash into a torrent search engine; it points to a specific .iso file. The flag format is picoCTF{...}.
    What didn't work first

    Tried: Searching for the hex hash in a regular web search engine like Google.

    A generic web search rarely returns structured torrent metadata for a raw hash. Use a torrent-specific indexer, one that stores the mapping from info_hash to file name, and paste the full hex hash into its search field.

    Tried: Trying to decode the hash itself as Base64 or hex-encoded text to extract the file name.

    The info_hash is a SHA-1 digest of the torrent metadata, a fixed-length hash rather than an encoding of the name, so there is no mathematical way back. Recovering the file name means looking it up in an external index that already holds the association.

    Learn more

    Because the info_hash is derived from the torrent metadata (including file names), it can be used to look up what file a torrent represents - even without having the .torrent file itself. Public torrent search engines index info_hashes and their associated file names, making this lookup straightforward.

    This is a real network forensics technique: if a captured PCAP shows BitTorrent traffic, an analyst can determine exactly what files were being downloaded (or uploaded) by extracting info_hashes and looking them up. This has legal implications in copyright enforcement and incident response cases where data exfiltration via P2P is suspected.

    The lesson about network traffic leakage extends beyond BitTorrent: DNS queries reveal what domains a user visits, HTTP headers leak browser/OS details, TLS SNI extensions expose the target hostname even over encrypted connections, and metadata in protocols often reveals more than the payload. Traffic analysis without decryption is a powerful forensic and intelligence technique.

Interactive tools
  • Hex ViewerView text or raw hex bytes as a xxd-style hex dump with byte offset, hex columns, and ASCII sidebar. Highlights printable characters and null bytes.
  • Strings ExtractorPull printable text from any binary, library, or image. ASCII and UTF-16 detection, configurable minimum length, flag-like highlight, no command line needed.

Flag

Reveal flag

picoCTF{.....amd64.iso}

Leakage of torrent metadata is often enough to identify what was downloaded.

Key takeaway

BitTorrent DHT queries expose the info_hash of every torrent actively downloading, and a public indexer turns that hash back into a filename. Counting occurrences in a capture and taking the most frequent picks the real target out of the routine maintenance traffic. Traffic analysis without decrypting anything is powerful on its own: DNS queries, HTTP headers, and TLS SNI fields all leak what a user is doing even when the payload is encrypted.

Related reading

Useful tools for Forensics

Where to go next