Some time ago, I wrote an external
DHT Tracker for Lua (
GitHub ) for
Shareaza . For Shareaza, this is a common local tracker, and in fact it is a BitTorrent DHT client that allows it to download torrents via magnet links without a tracker.
So, while the client is working, he catches packets with unknown fields and saves for further analysis (if this option is enabled).
So, what's new we caught in BitTorrent DHT.
(Standard fields are cleared, but left for clarity of structure):
{
v = "utct",
q = "vote",
a = {
target = "",
vote = 0,
token = "",
id = ""
},
y = "q",
t = ""
}
')
See what's new:
- v = "UTct" - These are two letters of the client ID (in this case, uTorrent) and the version is 2 bytes (63 74).
- q = “vote” - Judging by the name, this is “Voting”.
- vote = 0 - Well, this is probably an estimate.
Everything else is the same as in the announce_peer package, though there is no port, but it is obviously not needed here.
Crawling through a bunch of votes, we stumble upon another interesting package:
{
v = "UTdS",
q = "announce_peer",
a = {
name = "File Name.avi",
info_hash = "",
port = 1,
id = "",
token = ""
},
y = "q",
t = ""
}
Normal announce_peer with a plus in the form of the name of the torrent (see a.name). Apparently for a search engine or to display the name before receiving info.
Looking further and find:
{
v = "Az \ 5H",
q = "announce_peer",
a = {
seed = 0
info_hash = "",
port = 1,
token = "",
id = ""
},
y = "q",
t = ""
}
By client ID, we understand that we are already dealing with Azureus (judging by the Wiki, this is already Vuze). Also, announce_peer came to us with a plus in the form of a seed field, which is set to 0. Apparently, this feast is not a seed, says KO.
And again Azureus:
{
v = "AZ00",
q = "get_peers",
a = {
scrape = 1,
want = {
"n4"
},
info_hash = "",
id = ""
},
y = "q",
t = ""
}
See scrape and want. Apparently this is an analogue Scrape request to the tracker. Want is a list and contains the value "n4". It has long been flashed this field, and I learned a little about him. N4 are IPv4 addresses and N6, respectively, IPv6 addresses can be simultaneously.
This is our catch today. It remains to add about what has already been added to the packet filter:
{
r = {
ip = "\ 0 \ 0 \ 0 \ 0",
nodes2 = {}
}
y = "r"
}
The replies may additionally contain the ip field. The investigation revealed that this is your own ip.
nodes2 - list ipv6 node as far as I remember. Since my provider is still on ipv4, I didn’t go deep into this question.
A lot of new things appeared, of course, and in this regard, I had an idea to give the opportunity to ask for help from the client who sent the unknown package.
It looks like this:
Request
{
t = "",
y = "q",
q = "help",
a = {
path = {"q", "help"} - I think the list is better than the line. There used to be a line in which field names were separated by a dot.
}
}
In this case, this is a help query for the value q = help.
And the answer should come to him:
{
t = "",
y = "r",
r = {
help =
[= [
q = [help, ping, find_node, get_peers, announce_peer]
help - Micro help about new parameter dht packet.
a.path (query packet) - path to new parameter
r.help (responce packet) - help about new parameter
more: http://forum.bittorrent.org/viewtopic.php?pid=2134
other see on http://bittorrent.org/beps/bep_0005.html
] =]
}
}
Perhaps additional links are better to highlight a separate list.
Well. For those interested in this topic, google details, write comments.
By the way
forum.bittorrent.org does not work for me. And there were discussed exactly the innovations of BitTorrent clients.
PS For Peer-to-Peer karma is not enough.
PPS Thanks for the karma. Transferred