LinkBack URL
About LinkBacks
Reply With QuoteWe don't like to delete threads
This is a discussion on BitComet AND Azureus can break private trackers within the P2P Help and Security Forum forums, part of the P2P Forums category; I noticed all the fuss about BitComet being banned from private trackers so I did a little test of my ...
I noticed all the fuss about BitComet being banned from private trackers so I did a little test of my own - here are my results (apologies for the long post - but at least some of you are gonna be interested in this)
DreadWingKnight mentioned a scenario where a BitComet client could bridge between trackers listed in a .torrent
I tested a variation of this scenario and here's what happened.
First I dled a torrent lets call it private.torrent.
Then I made a copy of the private.torrent and called it free4all.torrent
Then I modified the announce url of free4all.torrent to point only to my own test tracker(removed the original announce to the private tracker).
I switched on my test tracker - and uploaded the free4all.torrent to it.
Then on one machine I fired up BitComet with the private.torrent that points to the private tracker.
while starting the private.torrent in BitComet I added my own test tracker's URL to the tracker announce list. The BitComet client (I'll call this the bridging client from now on) connected to the private tracker and to my test tracker . It recieved the peer list from the private tracker - as it should - and started conecting to peers and downloading. It also connected to my test tracker, but there were no peers on my test tracker so no action there.
Then on another seperate machine (I'll call this the superleech) I started the modified free4all.torrent that only points to my test tracker and it connected.
And then - SHOCK of SHOCKS - that superleech (connected only to my test tracker) started recieving the peer list from the from the original tracker (which is was not directly connected to) via my bridging client.
i.e. without being connected to the private tracker - I was still able to receive and connect to peers from that private tracker !!!!
To my surprise the superleecher is able to connect to many clients , not just other BitComets. They can leech from Azureus and G3 - the only one's I saw kick it was BitTornado although I may need someone to help me test this for certain.
I even noticed the superleech machine connect and give pieces to the official BT client-
A quick test with BitTornado.0.3.10 on the superleech machine :- it connected to my test tracker and only found one peer - i.e. the bridging client. No other peers were passed to it from the original tracker via the bridging client.
Next I tested the same scenario with Azureus and BitTornado as bridging clients.
Azureus worked as a bridging client BitTornado didn't.
turning Azureus into a bridge was as trivial as BitComet - just right clicked on the private.torrent and added the URL of my test tracker.
I am surprised by this because I thought part of the security of BT was that peers only accepted connections from the peerlist provided by the tracker/s in the .torrent file - yet the clients I am superleeching from are letting me connect to them even though the tracker they are connected to has no knowledge of my existance.
here is a screen cap of the superleech in action
For public trackers this functionality is great - it means if I find a torrent like the one I happen to be superleeching where there are a bunch of people stuck at 99.6 % with no seeder in sight - I could try and find the same torrent somewhere else, connect with BitComet and all the other leechers will be able finish via my bridge - without having to go and find the other torrent that points to a tracker with the seed.
For private trackers I'm still not sure what the full implications are except that basically they can't stop non member leechers while there is any BitComet or Azureus client attached to the tracker. And if client spoofing is used -
ED
IT: old link was dead. here's new one
http://www.p2pforums.com/viewtopic.php?t=11225
is it checkmate for private trackers ??
In theory users that are unknowingly being leeched by non members will still report their UL stats correctly - ? anyone care to help me get my head round this one fully.
NOTE:
These are my findings - they need to be verified by someone else - there could be factors that affected my tests that I'm unaware of.
If anyone would care to simulate this scenario and verify my findings that would be lovely - I used easyBNBT as my 'middleman' tracker.
P.S I posted this info on a private tracker and the thread was deleted !!!
hope it fairs better here.
P.P.S this post is a cleaned up version of my post on the thread here:
http://www.p2pforums.com/viewtopic.php? ... c&start=30
I just thought it deserved a little tidy.
We don't like to delete threads
Welcome to P2PForums, Aldoogy
Excellent first post. Hope you stay around for awhile.
I think that the future of BT lies in 3rd-party modifications to the basic protocol configuration to improve anonymity.
I'd like to see a system where IPs are only given out on a need-to-know basis, so that the tracker would retain all the IPs and only give them out in paired sets consisting of an uploader and a downloader - and peers would only know about - could only connect to - other peers when given express permission by the tracker.
Also, an encryption key-verified tunnel between peer and tracker - as well as between all peers - would also be a nice addition.
These proposed changes, or something similar, would be needed to convert BT from an open system where everyone know's everyone else's IP address - to a closed private P2P where most of the peers in the 'swarm' remain hidden from each other (except transfer pairs) and will not respond to upload requests unless previously given permission by the tracker.
thanks - just glad that there is some freedom of ideas over here. very healthy.Originally Posted by tm
if the tracker has to verify every client transaction - in large swarms won't it just fall over.
The choking and optimistic unchoking nature of BT (which make it find the best peers to exchange with - and therefore best speeds) would mean a lot of transactions for the tracker. Or are you thinking of making transactions between peers last longer to compensate - not sure how this would effect overall speed - badly I suspect.
Also as I understand it the deal with tcp is that to get best speeds - requests for pieces must be queued - thats why it sends peers a peerlist of a whole bunch of peers rather than just the four that most clients would upload to by default. In the pairs of peers scenario I suspect the download speeds would be up n down like a yoyo rather than the steady build up that users currently enjoy.
Also if the tracker is gonna set up pairs of peers - what happens if peers don't have the correct pieces that each other needs - that means going back to the tracker for another peer - slow . Or will the tracker check for which pieces peers have first (this tracker's gonna be a very tired tracker).
this will help with anonimity issues and ISP throttling issues. sounds a bit like what 'waste' are doing . I wonder what the overhead is like.
Can't see how you can do this and still get the phenomenal dl speeds that most users enjoy with existing BT without the tracker taking on a much heavier load - I'm happy to be proved wrong tho.
Also since ultimatley the peers themselves make the transactions - if even one client puts in a feature that caches peers (even if it's only given 2 or 3 at a time by the tracker) and allows peer list sharing how is the tracker gonna stop that ? Everyone using the 'open' client will still be able to do their own thing - and connect to each other regardless of what the tracker says they can or cannot do - no?
As it currently stands - and I'm racking my brain - this situation of clients that are incredibly 'open' like Azureus2.2.0.2 and BitComet basically mean there is nothing a private tracker can do to stop these clients sharing peers with non members.
For instance in my supeleech test - If I was using BitTornado in the swarm - the supeleech couldn't connect to me - but if people choose to use the 'open' clients what can a private tracker do about it ? Banning clients is NOT a solution because clients can be spoofed.....
While this info was banned from one private tracker I frequent - (deleted 3 times now) - I gotta wonder if this is actually such a bad thing. There seems to me 2 reasons why trackers go private - 1. to regulate the load on the tracker - 2. le
gal reasons.
In the first instance the superleech scenario doesn't affect their tracker because the load is balanced across the 'middleman' tracker, and secondly if the legal issues are their concern then the publicly available .torrent has no trace of their tracker in it.
Their only other concern is they can't monitor user ratios accurately. A big concern in one sense , but I wonder . . . .
this will help with anonimity issues and ISP throttling issues. sounds a bit like what 'waste' are doing . I wonder what the overhead is like.tm wrote:
[quote:75b48]Also, an encryption key-verified tunnel between peer and tracker - as well as between all peers - would also be a nice addition.
[/quote:75b48]
In Rodi i decided to sign only control packets, not the data transfer. it means that less than 2% of overall traffic is signed and verified by the peers.
military grade encryption comes at performance cost, no doubt about it. While without encryption 9 (nine) simultaneously running on single CPU system Rodi clients consume under 1% of CPU (total traffic is 700KBytes full duplex) with encryption of data this number jumps to 60%.
When only control packets are signed the cost is marginal. Two reasons - control packets are rare and they are typically short. In most cases size of the control packet is undert 128 bytes including UDP header.
larytet:
would the encryption of just control packets be enough to evade detection of traffic type, such as used by ellacoya/sandvine/packeteer switches , or would the payload of 'clear' data packets be easy enough to detect?
rgds
What I was talking about in having a more closed BT swarm was just a simplified example - in reality there would need to be more peer IPs thrown around to create a small queue and prevent lags.
Bittorrent was designed for maximum file transfer & propagation, with absolutely zero effort at protecting users' identity. A modified BT system that would hide most IPs from other users would be naturally less efficient, but it's slower speed might be acceptable if it would not automatically give everyone's IP to everyone else, including the MPAA.
Another possibility is for a tracker to act as a middleman in an IP spoofing arrangement (for those people on an ISP capable of it) so that the uploader's actual IP is known only to the tracker, which acts as a proxy for acknowledgement packets only.
There is a balance that can be worked out between network efficiency and relative anonymity - it does not need to be either all one or the other.
yeh - your right - just had some good results with 'waste' - transfer speeds were more than adequate (av.18kB/s UL on 256kbps adsl on which I will get 25kB/s max usually) - and that is secure enough not to be deep scanned - checking out larrytet's Rudi next, which looks more BT'esque.
Encryption is an area I have only very basic knowledge of so thanks for all the pointers.
Also had a look at the 'tor' solution for the proxy style arrangement you mentioned - .
I was wondering about a stop gap solution for private trackers in their current battle to try and keep control of their content against 'open' clients that share peers.
Bear with me I may be way off the mark -
it could be described as an 'unauthorised leech sabateur'.
it would act as an agent for the tracker and join all swarms being tracked by said tracker as if it were just another client.
It would obtain an official peerlist directly from the tracker - it would keep a record of which peers in the swarm are authorised member peers.
It would also mimic BitComet and Azureus behaviour and allow peer sharing. This way it would have two lists to compare - a list of authorised member peers direct from the tracker and a list of any uninvited peers collected from the swarm.
Then it would attempt to poison the member peers against the uninvited by spoofing the uninvited peers IP and sending bad data to the member peers - the member peers' clients would then kick and ban the unauthorised peers - thinking that they were sending bad data.
could something like that work ? (again I know next to nothing about IP spoofing).
Or is that just silly.
Interesting concept, Aldoogy, but I have to wonder if intentionally sending bad data would not be too extreme?
I wonder about a small-cell arrangement in BT where users are grouped together in a mini-swarm of maybe a dozen or two users. So a tracker is handling several mini-swarms instead of one big swarm. This arrangement would be more work for both the tracker and original seeder, but the advantage would be that only the IPs of members of the mini-swarm would be known, and the users in all the other mini-swarms would be unknown to anyone except members of that particular mini-swarm. So basically your IP address is known by only a dozen other active members, instead of being openly published and available to all downloaders as well as non-participants and prying eyes.
For IP spoofing, read about Rodi:
http://www.p2pforums.com/viewtopic.php?p=85814
http://larytet.sourceforge.net/rodiAnonymity.shtml
wow - brilliant links both of them - in the last two days I have learnt more about internet security issues than in the last 2 years !
well, from trying to trace through the python source of BT1 - I'm hoping peers ban clients after a certain amount of bad connection attempts - so in theory this could be as simple as sending the wrong info hash or a non matching peer_id and IP -Interesting concept, Aldoogy, but I have to wonder if intentionally sending bad data would not be too extreme?
So no bad piece data would actually have to be sent - which would obviously kill a downloaded piece when hash checked. (which I agree is self defeating). Although there's a certain homeopathic quality to the concept.
(although so far it looks like it only bans peers that send bad data chunks)
From what I'm understanding on both of those links I think the spoofing part could be difficult to make work in practice and I hear IP6 will shut this avenue completely ?
I'll have a go anyway and see - it's all good for broadening my understanding of these issues.
The UDP usage in Rodi is a very clever way to go - and small is good when talking about piece sizes - I do see what Larytet is saying about trusting the publisher, but isn't there some saying about "what can go wrong, will".
I'll have to think more about that one.
Anyway,I've downloaded Rodi and shall be trying it out in the next week . I'll post some feedback.
Plus I shall be following your discussion with Larytet.
I recommend it to anyone reading this thread, who like me wants to further understand p2p security issues from a strategic perspective :
here it is again.
http://www.p2pforums.com/viewtopic.php?p=85814
Posting Permissions 
Bookmarks