PDA

View Full Version : uTorrent



anthony-joal
10.08.17, 19:04
Please before reading this thread, read Client file format (https://www.sb-innovation.de/f275/announce-parameters-url-headers-33455/).

Since BitTorrent clients are updated regularly, i'll post the default file template for Deluge. And will list any changes for a particular version against this default template.

Default template


{
"keyGenerator": {
"length": 8,
"type": "hash",
"refreshOn": "TIMED_OR_AFTER_STARTED_ANNOUNCE",
"refreshEvery": 10,
"case": "upper"
},
"peerIdGenerator": {
"pattern": "xxxxxxxxxxxxxxxx",
"refreshOn": "NEVER",
"shouldUrlEncode": true
},
"urlEncoder": {
"encodingExclusionPattern": "[A-Za-z0-9-]",
"encodedHexCase": "lower"
},
"query": "info_hash={infohash}&peer_id={peerid}&port={port}&uploaded={uploaded}&downloaded={downloaded}&left={left}&corrupt=0&key={key}&event={event}&numwant={numwant}&compact=1&no_peer_id=1",
"numwant": 200,
"numwantOnStop": 0,
"requestHeaders": [
{ "name": "host", "value": "xxxxx"},
{ "name": "User-Agent", "value": "xxxxxxxxxxxxxxxx" },
{ "name": "Accept-Encoding", "value": "gzip" },
{ "name": "Connection", "value": "Close" }
]
}



3.5.3_44428
peerIdGenerator.pattern: -UT353S-(\u008c)(\u00ad)[\u0001-\u00ff]{10}
requestHeaders.User-Agent: uTorrent/353(111652236)(44428)"

3.5.3_44358
peerIdGenerator.pattern: -UT353S-F(\u00ad)[\u0001-\u00ff]{10}
requestHeaders.User-Agent: uTorrent/353(111652166)(44358)

3.5.1_44332
peerIdGenerator.pattern: -UT3515-(\u002c\u00ad)[\u0001-\u00ff]{10}
requestHeaders.User-Agent: uTorrent/351(111389996)(44332)

3.5.0_44294
peerIdGenerator.pattern: -UT3500-(\u0006\u00ad)[\u0001-\u00ff]{10}
requestHeaders.User-Agent: uTorrent/350(111258886)(44294)

3.5.0_44090
peerIdGenerator.pattern: -UT3500-(\u003a\u00ac)[\u0001-\u00ff]{10}
requestHeaders.User-Agent: uTorrent/350(111258682)(44090)


3.5.0_43916
peerIdGenerator.pattern: -UT3500-(\u008c\u00ab)[\u0001-\u00ff]{10}
requestHeaders.User-Agent: uTorrent/350(111258508)(43916)


3.2.2_28500
peerIdGenerator.pattern: -UT3220-To[\u0001-\u00ff]{10}
query: info_hash={infohash}&peer_id={peerid}&port={port}&uploaded={uploaded}&downloaded={downloaded}&left={left}&corrupt=0&key={key}&event={event}&numwant={numwant}&compact=1&no_peer_id=1
numwantOnStop: 200
requestHeaders.User-Agent: uTorrent/3220(28500)
requestheaders new header: { "name": "Accept-Language", "value": "{locale}" } The header takes place between "Accept-Encoding" and "Connection".

anon
11.08.17, 17:26
"Accept-Language": "en-US"

The value for this is read from "LocaleName" on registry key HKCU\Control Panel\International, so it can vary between computers.

Also, how do you handle URL encoding exceptions? uTorrent only encodes a-z, A-Z and - . _ ~ in the info_hash and peer_id as per the protocol specification, but other clients are different.

I'll have a look at the client file terminology and then your other threads when I have more time, good work so far.

anthony-joal
11.08.17, 17:42
The value for this is read from "LocaleName" on registry key HKCU\Control Panel\International, so it can vary between computers.
You'r right ;) i updated the definition. For those interested in java you can use "Locale.getDefault().toLanguageTag()".



Also, how do you handle URL encoding exceptions? uTorrent only encodes a-z, A-Z and - . _ ~ in the info_hash and peer_id as per the protocol specification, but other clients are different.
What do you mean by encoding exception? Since it's an HTTP call, all characters except a-z, A-Z and - . _ ~ have to encoded (with url encoding algorithm) this is part of HTTP protocol specification. Some clients does not seems to URLEncode characters, but these clients are using a standard charset (like qBitTorrent or transmission). Am i right or did i missed something?

If you meant "what chars should compose the peerId", this is covered by client file terminology, for utorrent i'm 99.9% sure it uses random (from 0x00 up to 0x7E), i'll take another look tonight.

Here is two peerId that i just got from uTorrent 3.5.0_43916 (in bold chars not being encoded):
-UT3500-%8c%ab%a9%87%ce%2b%a8o%22%01sj
-UT3500-%8c%ab%a1%d4%2c%93%24v3%91%60%ee

As you can see, all characters from 0x00 up to 0xFF are encoded, except those you mentionned, but this is part of the HTTP protocol specification, i haven't seen yet a client that does not URLEncode another way. If there is one i'd like to know so i could investigate :)

anthony-joal
12.08.17, 15:11
Ok.... i understand what you mean, some stupid clients does not follows the Http specification.... i'll change the client definition soon

anthony-joal
13.08.17, 16:07
Updated file format to a more readable one and fixed missing encoding exclusion.

anthony-joal
18.03.18, 01:32
Added v3.5.3 build 44358

anthony-joal
23.05.18, 23:36
Added 3.5.3 build 44428