peer exchange/peer caching.

[thebrass]

@DWKnight your views on private (ratio) trackers is well known-so could your findings be a little tainted ?

Perhaps, but the security hole I found (regarding a client ending up with remote connections even though it got rejected by the tracker) was discovered purely by accident (due to a client crash that I had no control over). It is also quite reproducable in any client that has a single listen port. Just generate a condition where the client fails to send a "stopped" event to the tracker, then restart it and it'll continue to get incoming connections because the tracker thinks it's still there.

let me know what you used to dissect the torrent that you downloaded from my site so I can see what you posted for myself-

http://torrentspy.sf.net - TorrentSpy Metainfo viewer.

Look for Azureus and BitComet created torrents specifically for the "azureus_properties" and "nodes" keys in the root of the torrent file.

humm.....isn't that cached peers that your connecting to...regardless of what the tracker thinks ?

and didn't I post something about this in responce to SqrtBoy's topic-Fight against ratio hacking ?

that is a fundamental flaw in the system due to the peers being cached-

and I will look in to the above

[DreadWingKnight]

humm.....isn't that cached peers that your connecting to...regardless of what the tracker thinks ?

No, ABC doesn't cache peers at all and it was the client I used to connect when I stumbled on this issue. All the connections were remote.

and didn't I post something about this in responce to SqrtBoy's topic-Fight against ratio hacking ?

Yes you did post something about this sort of system in response to that thread (sorry to others, filesoup leader's lounge, restricted access), but since a lot of the clients that generate this sort of behavior don't have peer caching, it can't be blamed for the problem.

[moussie]

If B is private and has the same files but a torrent with the private flag set, as has been mentioned before, the hash information would be changed. Even if you 'seek out' my cached IP, you would not be able to connect on that torrent, so that makes your point moot.

info hash is only relevant if you go through the tracker, which in this case you don't .. and the files are still the same

Just because the IP is cached doesn't mean that you're pulling down any information from it.

if I re-establish the connection I can .. obviously

IP caching is like giving someone an address. If the private flag is not enabled then it's also like giving someone a key. However, with it enabled, the IP itself will do you no good.

the private flag cq DHT has nothing to do with PEX aka NAT traversal .. if I'm able to cache your IP I can reconnect to you and through you to the swarm

[DreadWingKnight]

info hash is only relevant if you go through the tracker, which in this case you don't .. and the files are still the same

If a peer connects to another, it decides what files to get by info hash, not by filename. Please read http://wiki.theory.org/BitTorrentSpecification

PEX aka NAT traversal

PEX - PEER EXCHANGE

NAT Transversal is NOT Peer Exchange.

[Firon]

For a successful connection between two peers, they must be using the same infohash. If someone edited a torrent to remove the private flag, the infohash would change, and you would NOT be able to connect to any peer on the swarm with the original infohash.

[moussie]

if the 2 above statements .. about infohash having to be the same to be able to connect, seed and leech .. were correct we wouldn't have this problem .. right .. ?

but obviously there's peers from another tracker, with different info hash, leeching and seeding the same file .. so the facts proove your words to be wrong

and indeed .. you're right DWK .. it's not quite the same .. NAT traversal is only used to re-establish the connection after the peers are cached with PEX

[DreadWingKnight]

but obviously there's peers from another tracker, with different info hash, leeching and seeding the same file .. so the facts proove your words to be wrong

Not really. It just means that the two swarms can't bridge.

Considering that things like the announce url do not affect the infohash of a torrent, it's possible for peers to obtain connections from each other in different ways and bridge, even if the torrent is still flagged as private.

NAT Transversal is a way for two peers on a torrent to workaround firewall issues using UDP to communicate.

Peer exchange is a way for two peers to exchange peerlists for given torrents.

Peer caching is a client storing peer information for later use.

[Smoovious]

if the 2 above statements .. about infohash having to be the same to be able to connect, seed and leech .. were correct we wouldn't have this problem .. right .. ?

but obviously there's peers from another tracker, with different info hash, leeching and seeding the same file .. so the facts proove your words to be wrong

HAHAHAHAHA!!!

Ok, lets deal with some facts here...

Fact#1: a public torrent will not have private=1 in the file, and so will have one infohash

Fact#2: a private torrent, properly configured, will have private=1 in the file, and so will have a different infohash for the same exact files found in the public torrent mentioned.

Fact#3: torrent clients do NOT decide what files are to be uploaded and downloaded based on the peer connections.

Fact#4: torrent traffic is decided by the info-hash. When a peer connects to another peer, the initiator sends the info-hash of the torrent it is trying to open a connection for, to the recipient, and if the recipient isn't working on that info-hash, the connection will be rejected.

Whether or not other peers are caching your client's IP, HAS NOTHING WHATSOEVER TO DO WITH IT!

Other peers can cache your IP all day, and if you aren't working on the same hash as they are, they will NEVER trade data.

Consider:

Person A, retrieving a torrent containing the video "moussie_can't_stop_humiliating_himself_in_the_forums.avi", from a public tracker, using a publicly flagged torrent.

Person B, retrieving a torrent from another site, also containing the video "moussie_can't_stop_humiliating_himself_in_the_forums.avi", from another public tracker, using a publicly flagged torrent.

both persons, assuming the video, "moussie_can't_stop_humiliating_himself_in_the_forums.avi", is binary-identical, and that the torrents were both created in the same way, will have a good chance of having the same info-hash, and will be able to trade data with each other since their info-hash's match.

Say Person B, finds the video, "moussie_can't_stop_humiliating_himself_in_the_forums.avi", on a private tracker somewhere else... it is better distributed there, and he'd like to finish getting it from there instead.

Person B, downloads the torrent from the private tracker, for the video, "moussie_can't_stop_humiliating_himself_in_the_forums.avi", and adds it to his µTorrent client.

At this pont, one of two things will happen, if the torrent file isn't corrupt... 1> the info-hash is different, as it should be, and it will be added to the queue as a seperate, unique, torrent like it is supposed to be. 2> the info-hash is identical to the public one, as it should NOT be, and the currently queued torrent will be updated with the new torrent's information.

Condition 2, above, can happen, if the private site releases .torrent files without including the private=1 flag in the info-dict section of the .torrent file. If it is missing, and the info-hash is the same as a public torrent, then it is a trivial matter of including open trackers in the tracker list to bridge public and private swarms.

With the private=1 flag in the info-dict section, the info-hash changes, and as far as trackers and clients are concerned, they are totally seperate files, even if the resulting file is binary-identical.

This has nothing to do with DHT, or peer exchange... (and NAT? please...)

If the private site is distributing .torrent files with hashs that match public torrents, they have only themselves to blame.

A possible solution to this issue, will require changes on the parts of both the clients, and the trackers.

A change of format to the private=1 flag... as you may or may not know, some other networks use unique identifiers to identify themselves. Take IRC networks. UnderNet has dozens of different servers, but they are all identified as the same network because they all use the same identifier in the "NETWORK=undernet" flag. FreeNode does the same thing with their network.

Changing the private flag to something like "private=demonoid" would help insure that the .torrent is only valid for a particular tracker. If demonoid ran 4 different trackers, all 4 could be added in the tracker list, and if all 4 trackers identified itself in the announce as "demonoid" they would all be accepted and valid. Similarly, when the client makes an announce to the tracker, it could include the "demonoid" value somewhere in the announce string, which the tracker would look for, and if it is not supplied, the announce can be rejected. In this way, each private tracker would have a unique info-hash from each other. As it stands now, several private trackers, can each have their own private .torrent files being distributed, but have common info-hash's because "private=1" isn't unique between them. By uncluding the tracker's identifier in the private= flag, this insures each private tracker is using info-hash's unique to only them.

Peers can also do the same when negotiating. Peer1 connects to Peer2, negotiates which torrent is to be worked on. Since the info-hash would be unique specifically for "demonoid", that should be enough, but "demonoid" could also be passed during the negotiation, and if both sides agree that they are both "demonoid" peers, they will communicate.

This would avoid the need to send peer lists amongst each other to compare against the tracker, which appears to be part of the problem in the first place, even tho uT doesn't share peer lists, someone else in the swarm, is.

Another change would be to honor the private= flag when it comes to editing the tracker lists as well, but if the network-identifier suggestion I am talking about here is used, it wouldn't be necessary. If a non-zero private= flag exists in the .torrent, then the tracker list box should be greyed out, forbidding changing the trackers, but even if you did change the trackers, if the new trackers only accepted announce requests with their own network identifier, changing the tracker lists wouldn't accomplish anything. This could even be a bad idea, if the private tracker changes it's address, you couldn't be able to just change to the new address, you'd have to download a new .torrent file. Again, using a network-identifier, it wouldn't even be necessary. This isn't just a µTorrent-specific issue. Other clients let you external-announce and change trackers as well.

This entire thread began because someone thought µTorrent was sharing peer lists. µTorrent is not programmed to do it. Old peer cache data wouldn't have mattered if there were unique info-hash's being used in the first place. All µTorrent did was made the issue visible. Banning µTorrent doesn't make the problem go away, it just hides it from the tracker. It doesn't stop it.

Other clients are distributing the peer data. µTorrent isn't written to do that, and this isn't something 'a bug' would account for. 'A bug' just doesn't add a completely independent feature that hasn't even been started to be implemented yet.

Anyways... For those of you who have a lot to say, but little technical knowledge of the subject you are ranting about (yes, I'm talking about you, moussie), you should shut up while you're already behind before you lose even more respect from people who do know what they're talking about, than you already have.

Set something in µTorrent to prevent other clients from caching and sharing your IP? Are you kidding me? That would be like me trying to set an option in mIRC to prevent DWKnight from DCC'ing a file to chaosblade. Rediculous.

Anyways, my rant and idea is done... I'll clean this up a bit, and post it to the people who deal with protocol issues in a few days... reasonable and intelligent comment/discussion would be welcome... (no, moussie, I'm not talking about you).

-- Smoovious

[1c3d0g]

[laffin]

Not really' date=' since torrents come into the hands of users. Users with editors, can make the torrent a DHT enabled torrent.

The BitComet Announce Private flag defeats this. So the tracker decides if it's private or open, not the user who creates a torrent.[/quote']

It was put into the info dict section of the torrent for a reason: remove the private flag, the infohash changes. Then it's not the same torrent, and it won't work. BitComet's private announce method is uselesss, it's easily defeated by just about ANY torrent client, even legitimate, because no tracker response = no private set.

And on that note, µTorrent does support getting a private flag from the tracker. Ludde himself said it.

If it did, than dht wudda been disabled.

So the code for dht disabling is too relaxed, and leaves it on.

the same code with bitcomet works great. Cuz they have a pretty strict ruleset for dht enabled torrents.

My suggestion is that utorrent follow suit.

But all I see from this forum is same thing. It's quite disappointing to see, that instead of trying to fix a problem, ya all seem intent on ignoring it.

Once other private trackers realize that utorrent is causing this type of peer leaking thru it's dht implementation, the more ya will see utorrent banned from those trackers. As it happened BitComet.

But BitComet decided to fix the issue rather than ignore it. And now bitcomet releases ove .58 are now allowed.

So do the math, google the info if u must. but learn sumfin, instead of ignoring what's going on.

[maestro_black]

Nothing personal to anybody, but f**k private trackers. If you want to ban utorrent then ban it, but why waste 5 pages of this forum debating the fact?

Just do it and move on.

[laffin]

See prime example of what I mean

[silverfire]

but learn sumfin

Very convincing.

At any rate, I'm almost tired of this thread. If I don't see anything productive in the next five posts, it's getting locked.

[Firon]

laffin, please stop making retarded posts. Learn the protocol and the functionality of this program before you continue making yourself look retarded.

DHT WAS DISABLED BY THE PRIVATE FLAG AND UTORRENT SUPPORTS BOTH TYPES, YOU'D GET THAT IF YOU READ THE GOD DAMN THREAD. Thanks.

Also, provide proof µTorrent is causing the leak. Here's some tools: WinPcap and Ethereal. Have fun.

[maestro_black]

Ok, one final post.

Maybe a workaround for this problem. Why not have utorrent identify itself as other bittorrent clients, maybe as an optional flag in the program. This tracker guy cant block all clients or he wont have anyone left to use his tracker. Maybe do the identity thing using 10-20 of the most well known client id's chosen randomnly on startup.

Its an easy solution to the problem.

[Firon]

Client ID spoofing? Like BitComet and BitSpirit can do? (az has a plugin for it)

[ScubaSteve]

/me types something non productive.

la la la la la la la

Edit: also i dont agree with client id spoofing as its just another way for ppl to try and f**k trackers over

[ignorantcow]

Ok, one final post.

Maybe a workaround for this problem. Why not have utorrent identify itself as other bittorrent clients, maybe as an optional flag in the program. This tracker guy cant block all clients or he wont have anyone left to use his tracker. Maybe do the identity thing using 10-20 of the most well known client id's chosen randomnly on startup.

Its an easy solution to the problem.

Which would lead to even more hate. G3Torrent did this, whoa. The hate.

[maestro_black]

Whats the worst that can happen, he complains?

[Firon]

BitComet and BitSpirit support it natively iirc, and Az has a plugin. But then again, BC and BitSpirit are kinda hated. XD

[silverfire]

Now it's definitely off-topic. Discuss client ID spoofing in another thread.