Torrent Analyze picoCTF 2022 Solution

Description

1. Step 1

   Locate the info_hash

   Observation

   I noticed the PCAP contained BitTorrent DHT traffic with many different info_hash values appearing at different frequencies, which suggested that counting occurrences of each hash and picking the most frequent one would isolate the actual download target from routine DHT routing maintenance.

   DHT queries reveal multiple hashes, but the one repeated most often corresponds to the actual download. Once peers find each other, they exchange a flood of find_node and get_peers for that single infohash, which dwarfs unrelated DHT churn.

   What didn't work first

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

   The first hash seen is usually a random DHT routing-table ping, not the actual download target. These appear constantly as nodes maintain their k-buckets. You need to count how many times each hash appears and take the one with the highest frequency - only that hash represents the real transfer.

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

   BitTorrent DHT traffic travels over UDP, not HTTP or TCP, so those filters return nothing useful. The correct Wireshark display filter is bt-dht, which targets the UDP-based DHT protocol where the info_hash fields are exposed. Some peer data exchange happens over TCP, but the info_hash identification must come from the DHT packets.

   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, while bootstrap nodes and connected peers gossip find_node for the same value. Other hashes you see in the capture are DHT routing-table maintenance: every node periodically pings random IDs to keep its k-buckets fresh. That maintenance traffic is incidental and produces a long tail of one-or-two-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 2

   Map the hash to a file

   Observation

   I noticed the most-frequent info_hash was a fixed 20-byte SHA-1 value with no human-readable content, which suggested looking it up in a public torrent indexer that already maps info_hashes to file names rather than trying to decode it directly.

   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 string. You need a torrent-specific indexer (such as Linuxtracker or a DHT-based search engine) that stores the mapping from info_hash to file name. Paste the full hex hash into the search field on one of those sites to get the file name.

   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 - it is a fixed-length hash output, not an encoding of the file name. You cannot reverse a hash to get the file name mathematically. The only way to recover the file name is to look it up in an external index that already stores that 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.

Flag

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