Jump to content

ISP intervention with tracker communication ?


rafi

Recommended Posts

Here are two capture files with the announce hand-shake to TBP tracker - tracker.thepiratebay.org . It seems that with one ISP there is a good scrape info of some seeds/peers and with the other one - 0 . Can anyone say if one of the ISPs manipulates any data in the tracker responses ?

Here are the capture files: http://www.mediafire.com/download.php?detzmwattxl

bezeqint ISP is the suspected one...

Thanks

edit: link to the local forum for one more example/link

http://www.tapuz.co.il/Forums2008/ViewMsg.aspx?ForumId=20&MessageId=130643210

Link to comment
Share on other sites

I sorta looked at that posted thread (web-translaters suck). Looks like the complaint is about receiving addresses fairly in the same range? Looking at the captures, I have the following to say:

1. The Bezeqint capture does indeed have IP addresses close together. The first ten addresses have at least the first 24-bits matching, so it seems they are changing the addresses to ones inside their network.

2. The 013 capture only returned a single address, and it belonged to 013.

3. Both are missing some statistics such as number of times downloaded, I get this info when I announce, maybe whatever is messing with things (if anything) doesn't pass this info along?

4. The 013 capture, perhaps most importantly, has a private flag. This is a private flag IN THE TRACKER RESPONSE, which has previously been called a dirty hack, sometimes used on private trackers instead of enforcing the torrent private flag. It is unsupported as such a flag should go in the torrent, lest it be injected maliciously, which may have been what happened here. The private flag is not in my capture or the Bezeqint capture, and I highly doubt TPB has ever used said flag.

I'm going with both sides are probably tampering with the tracker response :|

Link to comment
Share on other sites

thanks. This starts to make sense... did you also notice an RST packet FROM the tracker in the 013 data after each announce ? it is not in the bezeqint data . does it have any bad side-effect ?

1. Bezeqint: is this the list reported here: http://www.tapuz.co.il/Forums2008/ViewMsg.aspx?ForumId=20&MessageId=130643210 ? if so, they are probably bezeqint servers running centOS, that were used before to store some cache info (popular torrents). does it make any sense ? since nothing is really happening with this cache servers. seems like there are no downloads from them.

2. 013: They are operating cache for some time now. look at the second example below. When I look at the peers list after the FIRST announce, I can see only one 013 peer (212.235.15.36:16881 ) downloading at full speed with fake Azureus client ID. At this point, the scrape info (tracker tab) is 0/0. Only after the second announce I can see peers in the scrape info as well as the peers tab.

btw, DHT and PEX are off.

A second example, with a more "popular" torrent (like 1300 seeds on the scrape ) :

http://www.mediafire.com/?sharekey=980c4a740cf7106cd6baebe61b361f7ce04e75f6e8ebb871

Link to comment
Share on other sites

Tracker response says it's from Cent OS.. and also has bezeqint all over it in various headers(term?). Wish I noticed that earlier ><

It doesn't really matter that DHT/PEX are off, my point is that 013 is trying to force clients to treat the torrent as a private torrent. I hope that doesn't become more prevalent as a way of manipulating BitTorrent :|

Link to comment
Share on other sites

yep... they are still working on "fixing" it... we'll see next Monday if they will call me back as promised ... :)

edit:

@GTHK: new capture... the ISP claims they are trying to 'fix' the isseu... can you see any change ?

http://www.mediafire.com/?yztyr2rmjqk

edit2:

two new captures - done at the same time with and w/o use of a proxy defined uTorrent (proxy IP: 78.61..36.119)

http://www.mediafire.com/download.php?mmm0ygnymyq

http://www.mediafire.com/download.php?wjmu3mbmqym

HTTP packets 4 & 6 seem to be the relevant ones (?)

Link to comment
Share on other sites

  • 2 weeks later...

Don't really see a change in the third capture file, headers look the same, and the tracker response they force feed you is an exact match to the second capture.

The fouth cap looks about the same as well. The proxy cap appears unchanged by bezeqint, the statistics you're supposed to get are present (number of times downloaded and stuff), different min_interval/interval values etc... so yay proxy I guess :/

Link to comment
Share on other sites

  • 2 weeks later...

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...