uTorrent 3.5.5 Build 45798

**Cr@zYiNsEiN** · 21.10.20, 08:39

Download here:- 3.5.5 (45798).rar

The zip contains one file.
1) 3.5.5 (45798).client

Information regarding the client:
1) Peer ID: - The Peer ID is global.
2) Key: - The key is global.
3) IPv6:- The client does not reports your IPv6 address. (If you want one made, please provide announces with the ipv6 enabled).
4) Encryption: - uTorrent doesn't send the encryption parameters for some reason. You can check out the announces I captured to make sure of it.
5) Memory Reader: - If you want to run uTorrent and Vuze/BiglyBT mod together read post http://www.sb-innovation.de/showthread.php?p=349640. Thanks to @anon for figuring this out.
7) Operating System: - Windows 10.

How to use the client files?

Simply copy and paste the client file inside the uTorrent folder you need to make here or wherever you have installed Vuze/BiglyBT. -> C:\Program Files\BiglyBT\clientfiles\uTorrent

How to use the correct client files?

There is only 1 client file. So a tutorial is not needed.

Spoiler Announces Captured Here:

What should I do if an error is found?
Report it back here the (defect) client(s) will be changed as soon as possible.

Happy Spoofing and don't get banned!

**anon** · 21.10.20, 20:54

Tagging this to check it later.

Originally Posted by cloud99

4) Encryption: - uTorrent doesn't send the encryption parameters for some reason. You can check out the announces I captured to make sure of it.

I surfed through your list of announces and noticed the peer_id prefix changed to -UT355W- when you enabled encryption, is this behavior reproducible? I'd never seen it before.

**Cr@zYiNsEiN** · 22.10.20, 04:50

Originally Posted by anon

is this behavior reproducible?

~~I am currently busy with work right now. But will provide a much more detailed post regarding this behavior by the end of the day.~~

Update: - I captured more announces and this seems to be a thing (not a mistake).

Click image for larger version.

Name: Screenshot_2.png
Views: 685
Size: 87.4 KB
ID: 20769

Can you please confirm whether or not Peer ID prefix changes after enabling "Encryption". Please download uTorrent from link I've provided below and not other mirrors so that we are on the same page.

Code:

https://www.utorrent.com/downloads/complete/track/stable/os/win

Spoiler Announces here:

Side note: - I may need to also recheck the handshake reserved bytes uTorrent sends out when encryption is enabled.
~cloud99

**anon** · 22.10.20, 21:30

Originally Posted by cloud99

Can you please confirm whether or not Peer ID prefix changes after enabling "Encryption". Please download uTorrent from link I've provided below and not other mirrors so that we are on the same page.

That's the download I always use... well, almost.

Code:

wget "https://download-hr.utorrent.com/track/stable/endpoint/utorrent/os/windows" -O "uTorrent.exe"

You can swap "stable" for "beta" to download the latest beta build, which is not necessarily newer than the stable one. In any case, I will verify this myself as soon as I can, but your packet capture data seems solid, which makes this idiosyncrasy really interesting. Since there is some semi-formal collaboration between uTorrent developers and private tracker staff, I guess the former decided to report encryption preferences to trackers at some point (for whatever reason) but without changing the announce structure by adding one or more parameters to the query string. That's just pure speculation, though. I was unable to find any more information about this "UT355W" prefix or the significance of the W, vs. S which presumably refers to "Stable".

Looks like we're going to have to test and create two client files per uTorrent build from now on

I will check the reserved bytes too, but there's the question of how to tell if they differ if encryption is enabled since they'll be, well, encrypted. Verbose logging may help here.

**Cr@zYiNsEiN** · 24.10.20, 05:56

Originally Posted by anon

but your packet capture data seems solid

Don't waste your time then. You can spend it on making newer client files. However, please go through the announces and compare it with the client file (I post) to see whether it is accurate.

Originally Posted by anon

That's just pure speculation, though. Looks like we're going to have to test and create two client files per uTorrent build from now on

That's fine. I could care less about the extra work, but as long as it is accurate enough to pass in private trackers. That's all.

Originally Posted by anon

I could not find any more information about this "UT355W" prefix or the significance of the W vs. S, which presumably refers to "Stable."

@all reading this: - Could someone possibly bring this question up in Github? The developers could confirm whether this, in fact, is actually a thing that we are going to see from now on. Or just a glitch which or error which will be present only in this version.

Originally Posted by anon

I will check the reserved bytes too, but there's the question of how to tell if they differ if encryption is enabled since they'll be, well, encrypted. Verbose logging may help here.

Can you help me out here with Verbose logging with WireShark or other tools? I only ask you to direct me to a tutorial so that I can learn and then apply to capture the encrypted reserved bytes.

The search query "Verbose Logging" + "Wireshark" brings up no tutorials.

Code:

https://www.google.com/search?q=%22verbose+logging%22+%2B+%22wireshark%22&oq=%22verbose+logging%22+%2B+%22wireshark%22

~cloud99

**anon** · 24.10.20, 19:17

Originally Posted by cloud99

Don't waste your time then. You can spend it on making newer client files. However, please go through the announces and compare it with the client file (I post) to see whether it is accurate.

Unfortunately I'm used to uTorrent exhibiting "mystery" behavior on its requests (including Accept-Language, Accept-Encoding, ipv6 and a completely different announce structure formerly present on some beta builds), so I'm not going to let go of this easily. Just need to find some time to check it

That's fine. I could care less about the extra work, but as long as it is accurate enough to pass in private trackers. That's all.

Not a big deal for me either, but obviously I'd prefer if it was a single file like it's always been.

@all reading this: - Could someone possibly bring this question up in Github? The developers could confirm whether this, in fact, is actually a thing that we are going to see from now on. Or just a glitch which or error which will be present only in this version.

Is uTorrent on GitHub? I thought the only channel of communication with the developers is the (fairly inactive) official forum. I did a search for "UT355W" there but found no results.

Can you help me out here with Verbose logging with WireShark or other tools? I only ask you to direct me to a tutorial so that I can learn and then apply to capture the encrypted reserved bytes.

The search query "Verbose Logging" + "Wireshark" brings up no tutorials.

Verbose logging is a feature in clients, not Wireshark. In uTorrent you can configure it by right-clicking anywhere in the log. BiglyBT has the most complete logging feature of any client, which can be found at Tools -> Console (but must be enabled first on Tools -> Options -> Logging).

Wireshark can capture and dissect the BitTorrent handshake message including its reserved bytes, but only if encryption is disabled on both ends of the connection. Obviously that won't help us find differences vs. when it's enabled, if any.

**Cr@zYiNsEiN** · 01.11.20, 05:37

Originally Posted by anon

Is uTorrent on GitHub? I thought the only channel of communication with the developers is the (fairly inactive) official forum.

Sorry about the GitHub thing. I did a search on Google search and saw uTorrent on Github and assumed that the developing team was present.

Click image for larger version.

Name: Screenshot_2.png
Views: 649
Size: 35.5 KB
ID: 20784

Originally Posted by anon

single file like it's always been

Things change a lot of these days with the passage of time.

Originally Posted by anon

In uTorrent you can configure it by right-clicking anywhere in the log.

Can you help me please? I can't see to get how to turn on logging option. I want to test this logging feature out in the "Clean uTorrent 2.2.1 Build 25302" you shared with me. Before I move on to using it latest ad-filled/resource-hogging/lagging and crashing latest version(s).

Also Yes, I did search for logging options for uTorrent on Google and came across this.

For Windows OSs, a quick and dirty trick to log torrent activity and append to a file, would be to use "Run this program when a torrent finishes" or "Run this program when a torrent changes state" functionality (Options -> Preferences -> Advanced -> Run Program), with the following command (modify parameters for echo to suit your needs):

cmd.exe /c /u "echo name(%F)__title(%N)__hash(%I)__state(%S)__status(% M) >> c:\utorrent_activity.log"

Unfortunately, Windows' environment variables (such as: %APPDATA%) won't work here. Also, this will keep showing a command interpreter window for a split second, every time torrents in uTorrent will be changing states, which might be annoying.

Also, one can modify shortcut that starts uTorrent - open shortcut properties, in the "Target" field, add a /logfile switch along with the filename of the file to which application will be logging (see below). Unfortunately, I'm not aware of the option to append to the existing log - it will be overwritten with every application start.

"C:\Program Files\uTorrent\uTorrent.exe" /logfile "%APPDATA%\utorrent\utorrent.log"

Source: -

Code:

https://forum.utorrent.com/topic/70268-utorrent-activity-log-file/?tab=comments#comment-416366

Heads up! You may need to solve key captcha when visiting the link.

If you look at the quoted text from the external source, you will notice this command to run.

cmd.exe /c /u "echo name(%F)__title(%N)__hash(%I)__state(%S)__status(% M) >> c:\utorrent_activity.log"

So my question is can you tell me what I need to modify or change in the command so that I can capture logs to see and I quote you. "Reserved bytes to tell if they differ if encryption is enabled since they'll be, well, encrypted."

Originally Posted by anon

BiglyBT has the most complete logging feature of any client,

Too bad we don't have the need to make emulations for BiglyBT for Vuze and BiglyBT.

Originally Posted by anon

Wireshark can capture and dissect the BitTorrent handshake message including its reserved bytes, but only if encryption is disabled on both ends of the connection. Obviously that won't help us find differences vs. when it's enabled, if any.

Does this mean I am doing it the wrong for the following thing?

I have been checking the reserved bytes with WireShark, by enabling forced encryption on the torrent client, and then connecting to encrypted only peers to see whether the reserved bytes remain the same when enabling and disabling encryption.
~cloud99

**anon** · 02.12.20, 16:19

During my tests, no amount of changes to the encryption parameters made a difference in the peer_id prefix. However, turning on "protocol enhancements" always switched it to -UT355W-%e6%b2 (and back to -UT355S-%e6%b2 after turning it off). Any chances is was both settings that you enabled?

**mmmmm** · 25.03.21, 20:22

Originally Posted by anon

-UT355W
-UT355S

searched and found :

"Enable protocol enhancements" setting causes settings variable "wallet_integration_enabled" to be set to true, which allows Tron and BitTorrent Token (BTT) to use BitTorrent Speed, a monetized exchange mechanism (you get "paid" for participating). The "W" is for Wallet.