BitTorrentDHT
Simon Waite
Post date: Apr 16, 2012 12:00:00 PM
The specification for identifying mainline clients is the “v” key in the root dictionary of every message.
These are in the wild. I noticed a South Korean client that claimed that it was a uTorrent client (UTz\xAD) that:
114.200.XX.XX:345YY v:UTz\xAD is trying to convince me I’m: 114.200.XX.XX:440ZZ
The port was correct, but the ip was the buggy/malicious clients own.
A Vietnamese ‘uTorrent’ client (UTy\xA3) claimed that I was 192.168.1.1:440ZZ, which while it had the port correct, thought I was on an internal network.
113.182.XX.XX:44XXX v:UTy\xA3 is trying to convince me I’m: 192.168.1.1:440ZZ
Other UTy\xA3 clients claimed similar nonsense
A US client thinks I’m in Belgium and one from Pakistan thinks I’m on its LAN.
50.33.XX.XX:10XXX v:UTy\xA3 is trying to convince me I’m: 94.224.YY.YY:440ZZ
182.186.XX.XX:47XXX v:UTy\xA3 is trying to convince me I’m: 192.168.1.1:440ZZ
The UT client seems to use 4 bytes of random looking data
The LT, and Zo clients seems to use 2 bytes
Timestamp ie. a number rendered in ascii 10047026 which appears to increase by one with each request.
Some use a random-looking string of 8 bytes
One particularly broken client had the token of ASCII ‘1’, and kept requesting data from differing port numbers
Another uses the format ‘abcde12733’ with the number part increasing due to different queries.
Yet another uses the format ‘get_peers608’, with the number part increasing.
0000xxxx0000xxxx0000xxxx0000xxxx0000xxxx
It’s statistically improbable that you’d want to look for an node like this.
Client Identification
| Name | Prefix | Examples/Notes |
|---|---|---|
| uTorrent | UT | UTz\xAD |
| libTorrent, Rasterbar | LT | LT\x01\x09 |
| libTorrent (other?) | lt | lt\x0D\x00 |
| MooPolice | MP | |
| GetRight | GR | |
| MonoTorrent | MO | MO06 |
| Transmission | TR | TR\x02\x0B |
| Vuze (maybe) | AZ | Az\x00\xC3\xB1Az\x00\xC3\xB2Az\x00\xCB\x9CAz\x00\xE2\x80\x93Az\x00\xEF\xBF\xBD (common)Az\x05H |
| Alpha Two | A2 | A2\x00\x03 |
| Bravo Foxtrot | BF | BF-1.41BF-1.50Maybe a Battlefield 3 patcher? |
| Bravo Tango | BT | BT\x00\x01 |
| DhtPlay | DP | |
| India Lima | IL | IL\x00\x10 |
| November Sierra | NS | NS\x01\x18 |
| Sierra Zulu | SZ | SZ\x02\x06SZ\x02\x07 |
| Tango Xray | TX | TX1a |
| UltraTorrent1 | UltraTorrent1 | UltraTorrent1 |
| Uniform Tango | UT | uT01First client appears to be sharing a co-located server in the USA running a chinese language website that appears to promote an windows app called “octopus search artifact” which appears to be a bittorrent search engine of some description. |
| Zulu Oscar | Zo | Zo\x00\x06Zo\x00\x07Zo\x00\x09Zo\x00\x0AMost of these clients appear to be in ex Warsaw Pact countries, sometimes a google search of the info_hashes appear on various bittorrent scrapers though they do not seem to allow peer exchange. Which makes me wonder if these are malware clients, private torrents that are hosted only by broken clients, or some kind of software that is using bittorrent as a peer2peer discovery system (think bonjour over DHT) |
| Null 4 | \0\0 | \0\0\0\0 |
IP Address Key
Various clients send you an “ip” key, to helpfully convince you what your external ip and port are.
Obviously evil (or just plain buggy) clients will try to convince you otherwise.
These are in the wild. I noticed a South Korean client that claimed that it was a uTorrent client (UTz\xAD) that:
114.200.XX.XX:345YY v:UTz\xAD is trying to convince me I’m: 114.200.XX.XX:440ZZ
The port was correct, but the ip was the buggy/malicious clients own.
A Vietnamese ‘uTorrent’ client (UTy\xA3) claimed that I was 192.168.1.1:440ZZ, which while it had the port correct, thought I was on an internal network.
113.182.XX.XX:44XXX v:UTy\xA3 is trying to convince me I’m: 192.168.1.1:440ZZ
Other UTy\xA3 clients claimed similar nonsense
A US client thinks I’m in Belgium and one from Pakistan thinks I’m on its LAN.
50.33.XX.XX:10XXX v:UTy\xA3 is trying to convince me I’m: 94.224.YY.YY:440ZZ
182.186.XX.XX:47XXX v:UTy\xA3 is trying to convince me I’m: 192.168.1.1:440ZZ
Tokens
Tokens are passed with each message, to supposedly help identify each message. Many clients just don’t bother making this meaningful.
Some variations that I’ve noticed:
-
The UT client seems to use 4 bytes of random looking data
-
The LT, and Zo clients seems to use 2 bytes
-
Timestamp ie. a number rendered in ascii 10047026 which appears to increase by one with each request.
-
Some use a random-looking string of 8 bytes
-
One particularly broken client had the token of ASCII ‘1’, and kept requesting data from differing port numbers
-
Another uses the format ‘abcde12733’ with the number part increasing due to different queries.
-
Yet another uses the format ‘get_peers608’, with the number part increasing.
Odd Hashes
There appears to be an oddity with some clients identifying as UT (Mostly UTy\xA3) requesting find_node with the following pattern:
0000xxxx0000xxxx0000xxxx0000xxxx0000xxxx
It’s statistically improbable that you’d want to look for an node like this.