Tools for Television PRO
By taklamakan | July 19, 2007
The guys from Pixel Post Studios contacted us to inform us that their software Tools for Television PRO is tracked by our tracker and that they pretty much would like that we stop distributing their software. As we are only an open bittorrent tracker and are not in the possession (illegal or not) of the software in question, therefore are unable to distribute or stop distributing it, we are not really in the position to help them.
But we took the liberty to take a look on their website to see what this software is all about and really wonder why people distribute this software via bittorrent without buying it.
People, if you really work in this niche television field and if you use this software to earn your money, why not pay $179 or even only $99 (its on sale right now!)? For the package of features and tools you get, thats a fair price we guess! If you are a student, get the $30 discount or better ask your university to buy this software, we are sure the sales people at Pixel Post Studios would be happy to sell a campus licence (Arizona
State University is already a customer of them). If you are uncertain if this software really is for you, get the time limited trial version!
So the price is fair (with on-sale going on even more), student discount is available, you can get a time and not feature limited trial version, the company is small (so we are sure you will get eventual bugs fixed in time) and they even put up Tutorial Videos for the software! Why not buy it?
Really, the only drawback we see is the platform-specific registration keys, the people at Pixel Post Studios should think about that again (if you need to buy it again if you change to a different platform).
PS: No, we don’t get money or anything else from them 
Update: They informed us that they provide
free key changes to people who switch platforms.
Nice.
Topics: abuse, free speech | 2 Comments »
Problems with Peerguardian
By taklamakan | July 19, 2007
An anonymous tip directed our attention to this posting in the Phoenix Labs forum, the guys responsible for providing filesharers with the Peerguardian tool. It appears that the peerguardian block-list includes our tracker IP-address because they think we are part of the Chaos Computer Club (CCC) and therefore hackers (Yeah, thanks for the flowers!) or malware and virus distributors (WTF?).
We don’t understand how the connection between us and the Chaos Computer Club appeared but we don’t deny that some of us have connections to the CCC but the tracker is run by us, not the CCC. It is hosted on a server of a friend of us who is not even a member of the CCC as far as we know and just happens to have enough resources for our little project.
We thought about funding the hosting with the help of the CCC but that didn’t work out for other reasons.
Even if the tracker would be run by the CCC, people should be happy about that! If you would name organizations in Europe in favour of filesharing, freedom of information and bittorrent beside Piratbyrån in sweden (the guys who started thepiratebay.org), the CCC would be one of them!
We have no idea how the people responsible for Peerguardian get the idea that we work together with MediaDefender or any other anti-piracy company, we certainly do not!
Why should we, we don’t like people earning money with law-suits against filesharer. But then this information is a year old if we understand this posting correct. We changed our tracker-software in the meantime and even try to take countermeasures against faker, so maybe they should re-check about fakes and stuff.
But this is an open tracker, so everybody can use it. The sites who are serving the fake torrents should delete them, we are only providing the trackerservice (for free) without any interaction with the enduser or knowledge of the content of the torrent!
We serve about 170.000 torrents, have 1,5 million users and about 180 million completed downloads in the last 1000 hours, all of them fake? We don’t think so. Some of them fake? Probably. Such is life!
But if the people of peerguardian have a problem with our tracker, they should feel free to contact us, we don’t bite (most of the time)!
Topics: free speech | 3 Comments »
Perfect Deniability
By erdgeist | February 12, 2007
I stumbled across this post the other day. Copy right enforcers nowadays seem to have trouble catching people ignoring their copy rights red handed. Black lists seem to spread fast enough to lock spies out. So all they’ve got is IP lists bittorrent trackers supply them for a given torrent.
As it seems, this really is enough for them to send out threatening letters to ISPs. While we certainly do not encourage anyone to share files they’re not supposed to, we do not feel well being missused as evidence distributors. Spoofing an IP address is not that hard and knowing that some trackers even parse IP addresses from query strings presented to them is not helpful either.
Whats worse: since bittorrents tracker protocol is based upon http, a webdot like
<img src="http://denis.stalker.h3q.com/announce?info_hash=01234567890123456789"/> on a frequently visited web site can bring an unanware internet user to announcing themself to our tracker.
So we decided to insert truely random IP addresses from known-to-be-used sub nets into all our answers. We do know that this will degrade overall performance and will cost extra traffic and connections. But we are sure that this kind of deniability, when adopted by other trackers as well, will force copy right spies to acquire hard evidence against file sharers. Spread the word.
Topics: abuse, free speech | 26 Comments »
This can only mean one Thing! Injection!
By supergrobi | January 30, 2007
Today, supergrobi explains how a connection to a tracker should NOT look like!
You ever wondered why it seems that our tracker answers your announce requests with an RST packet thus destroying your connection? Think again! It is your ISP who tries to kill your connection without admitting it to save bandwidth for which you probably paid money.
Lets look how an ordinary TCP connection is set up.
First you send a SYN packet to the tracker:
03:38:07.763665 IP (tos 0x0, ttl 104, id 28391, offset 0, flags [DF], proto: TCP (6), length: 48) 1.2.3.4.1737 > 217.13.206.147.6969: S, cksum 0x764c (correct), 3957760381:3957760381(0) win 16384
Our tracker answers this with a SYN and ACK:
03:38:07.763687 IP (tos 0x0, ttl 64, id 51007, offset 0, flags [DF], proto: TCP (6), length: 48) 217.13.206.147.6969 > 1.2.3.4.1737: S, cksum 0x0bcb (correct), 2652573014:2652573014(0) ack 3957760382 win 65535
Your clients also acknowledges this with an ACK:
03:38:08.163338 IP (tos 0x0, ttl 104, id 28398, offset 0, flags [DF], proto: TCP (6), length: 40) 1.2.3.4.1737 > 217.13.206.147.6969: ., cksum 0xf31d (correct), ack 1 win 17520
Now both ends of the connection have exchanged the sequence numbers (3957760381 and 2652573014) – the client could send the actual request to the client. But look closer and see what happens next:
03:38:08.165227 IP (tos 0x0, ttl 13, id 0, offset 0, flags [DF], proto: TCP (6), length: 62) 1.2.3.4.1737 > 217.13.206.147.6969: R, cksum 0xf303 (correct), 1:23(22) ack 1 win 17520 [RST 00000000000000000000000000000000000000000000]
This is an RST packet which destroys the connection no matter what. The tracker will not accept any more packets from this connection after it received this RST packet. So this client will never get any peers from our tracker.
But why did I choose the peculiar title of this blog entry? This RST is NOT sent by the client – it is injected. It even has a different TTL and a payload of 22 bytes filled with zeros which is unusual AND useless for an RST packet. Let’s look at the next packet:
03:38:17.151116 IP (tos 0x0, ttl 104, id 29025, offset 0, flags [DF], proto: TCP (6), length: 471) 1.2.3.4.1737 > 217.13.206.147.6969: P, cksum 0xddd8 (correct), 1:432(431) ack 1 win 17520
This is the actual announce request from client to tracker. But it comes ca. nine seconds later and has the same sequence number as the RST packet. So one of both packets is injected. You can guess which! Since our tracker has no state for this connection anymore it will answer this request with another RST, which is normal behavior.
So what happened here? After some head scratching and googling we think we can explain it. Somewhere between client and tracker sits a filter. THEY use it to sniff the first data packet of a connection. There is not so much else THEY can do to detect bittorrent traffic. Bittorrents tracker protocol can use any port and uses HTTP GET request for its tracker⇔client communication. So THEY need to look inside packets and scan for strings like ‘info_hash’ (‘info_hash’ is unavoidable because it is part of the bittorrent spec).
Once THEY identifiy that it is a bittorrent announce request, THEY drop it and send an RST packet instead. Some ISPs do not send such an RST packet back to the client. Your client still waits for an ACK for this request packet. But our tracker got THEIR RST packet and will not send this ACK, so your client is sending the announce request again. Since THEIR filter only sniffs the first data packet of a connection (it would be too much work to inspect every packet from every connection) this packet does not get filtered and arrives nine seconds later at the tracker.
Actually once we tried to filter incoming RST packets for our tracker, enabling us to successfully answer the arriving (second) announce request packet. The problem is, that we can not filter the RST packets from the whole internet because it costs us too much open sockets while it generates alot of connections in a wait state (they invented this RST flag with a reason after all!).
So if anyone has some suggestions how this ISP p2p blocking can be avoided, leave a comment.
Topics: tech | 9 Comments »
torrenty.org update
By taklamakan | January 27, 2007
We don’t know if the torrenty.org people read this blog or got word through other channels, because our mail to them bounced, but they stopped using our tracker!
Anyway, we appreciate this decision! We wish them the best with their own tracker and thanks for all the phish!
Topics: abuse, history | 1 Comment »
torrenty.org
By taklamakan | January 26, 2007
Today we noticed a huge grow of numbers in our monitoring graphs. Until today we had about 200 actual announces per second and served about 220.000 peers. Those numbers jumped to 570 announces/sec and we started serving 480.000 peers.
What happened? After some debugging and an anonymous tip we found out that the guys at torrenty.org, a large pay-torrent-site in poland, started to use our open bittorrent tracker for their torrents.
Beside the facts that we are flattered by the trust the people at torrenty.org put in our service and that we are somewhat proud how well our software works and scales for that number of requests, we can’t believe how incredibly stupid this is by the torrenty.org people.
First of all, they just changed the IP-address of their tracker “tracker.torrenty.org” to our tracker IP-address:
;; ANSWER SECTION:
tracker.torrenty.org. 1800 IN A 217.13.206.147
This means in all their torrents they still use the hostname “tracker.torrenty.org” in the HTTP header. This is easy for us to filter, just deny all request for “Host: tracker.torrenty.org” and we are all set.
The fun part is, a quick look at the torrenty.org website shows us that they in fact serve warez-torrents and take money for that. Now they provided us with a complete list of IP-addresses of their customers and an easy way to distinguish their customers from all other requests by checking the HTTP-header. If we were some kind of copyright-prosecutor, which we are totally not, now would be the time to send some letters to customers of torrenty.org. That would put them out of business relatively quick I guess, or would you like to be a customer of a warez site which provides your IP-address to copyright-prosecutor for free?
So this post goes to the people at torrenty.org and maybe all other warez-torrent people out there who think about abusing an open tracker, please stop using our tracker for your warez-business and stop putting the risk at us. We will filter requests with anything other than denis.stalker.h3q.com as a hostname anyway.
We will now implement this filtering technique in our tracker, which will take a while. And we will stop serving torrents with “Host: tracker.torrenty.org” in the HTTP header. Of course clients will continue to connect to our tracker because the DNS-record of tracker.torrenty.org will still resolve to our IP address. So hey torrenty.org, please change that DNS-record you’re wasting our bandwidth!
Topics: abuse, history | 4 Comments »
« Previous Entries Next Entries »