system

Is there any information at all about this crash bug that affects all extended messaging versions? After last time, I'm reluctant to take anybodies word for it existing and affecting 1.4-1.7.x We all know how much you'd love to see 1.6.1 die out.

The change log keeps changing to remove 1.6.x and then reverting.

Page 1 of this thread. http://download.utorrent.com/1.7.6/utorrent-1.7.6.txt Edit: just to eliminate all possibilty of a cache problem, I'm reading the same thing through a remote shell.

There is no opinion there. Fact is 1.7.x can be crashed, 1.6.x can't and you can verify that yourself. The initial reports on What and other sites were based on someone using a known exploit on 1.6.0, which has been fixed in 1.6.1. From there, the 2 exploits got confused by a lot of admins leading to bans which is when I started trying to clear the FUD. What is pure opinion is listing 1.6.x as exploitable with the new exploit on the first page of the thread and in the changelog, or speculating as to how 1.6.1 may be insecure because you cannot verify it does not have a bug, ie "As far as we know, 1.6.1 cannot through the same method, but it doesn't rule out the possibility" As far as I know, 1.7.6 cannot blow up my monitor but I cannot rule out the possibility. Or, the opinion that I don't do testing and like to ban clients

jewelisheaven: For starters, I do my own testing. This is how I know that 1.6.x are not susceptible to the new exploit. When all the other sheeple were off banning, I was testing all versions from 1.6.0 to 1.7.5. Laugh all you want, but I do not do knee jerk. I do not have control of client bans at bm, but I do at other sites where I have not banned anything in a long time. If you want to run the same tests I have, the link to the c based exploit has been posted repeatedly, or I can supply a small php script I coded up for the occasion. Those links you posted do not show any proof at all the 1.6.1 is exploitable. They just link back to firon posting about something with no evidence. Here's the thing. Now, why on earth would I take the word of someone who wants everyone to believe there is a problem with 1.6.x when he says that, big suprise, there's a problem with 1.6.x The only exploit findable with a google search for 1.6.x is the malformed torrent one for 1.6.0. This was fixed in 1.6.1 which is the version allowed on bm and other sites. Holding out against new bugs by the bucketload is not unwise when the old version has not been proven to be exploitable. If anything, 1.6.1 has one less remote exploit than any of the 1.7.0-1.7.5 versions.

Assuming you mean staff from a certain tv site. What he did was run the code from milw0rm against 1.6 There is only one piece of code for uT on milw0rm, and that's the malformed torrent code. Here's what he said later: 1.6.1 fixes that problem, and neither 1.6.0 or 1.6.1 will crash with the new exploit.

@jewelisheaven, 1.6.x does support extensions. Here's what happens if you send the extnsion bit in a handshake to 1.6.1. \0x13BitTorrent protocol\0x00\0x00\0x00\0x00\0x00\0x10\0x00\0x00 Which means extensions are supported. Next we get this: \0x14\0x00d1:ei0e1:mde1:pi32489e1:v14:µTorrent 1.6.1e That's the extended messaging client name, the same one that's causing trouble in the 1.7.x versions. What 1.6.x does not do is display the information it gets from that client name in the peers or logger pane, which probably explains why this bug does not affect 1.6.x Apparently it suits certain people to have everyone believe that 1.6 is affected though.

Although the spec lists event as optional, the definition for what a non-present event means is pretty clear. The key may or may not be present, but it should only be non-present for a regular announce. The spec says if event is not present, then it is a regular announce. The spec is vague on whether completed should be sent at 100% of all files or only those you are downloading, but the same vagueness also applies to the left variable. When we consider that bittorrent clients originally were not able to choose which files they wanted though, we can assume both represent the total of all data in the torrent. I know the old saying about assumptions, but lacking any official word on the subject any attempt to clarify will always be an assumption either way. Another consideration though is that the tracker has no use for the information that you have 0 bytes left to download when you picked 3 files out of 5. To other clients, you will be shown as a peer unless you have all parts, why should the tracker show you as something different? It also has no need of the completed event if you have actually only half completed and may decide to select more files in the same session (which would trigger 2 or more completed events as well as a sudden jump in left). Taking either completed or left to be anything less than 100% of all files also makes a mockery of scrape, which was designed with Bram Cohen at least playing a part in its developement (if not designing the whole thing). If the tracker has a different view of peers/seeds than the client, the scrape information essentially becomes useless for anything and may as well contain random numbers.

It also happens when someone is no longer running their client but uT tries to connect to them. Either thay are peers in uTs cache, or they are listed by the tracker because they never sent a "stopped" event message (crash/badly coded client/congested tracker).

It's the version that comes round, slaps your wife, steals your beer, sleeps with your daughter then beats you to a pulp. You must have seen it

Tested for LPD with public and private torrents running, it skips LPD on private torrents