Stuff like this is why I usually go for network namespaces + (wireguard / socks / iptables) when I need to isolate traffic.
> The tracker in question that I wanted to get this working for explicitly forbids running development builds of approved BitTorrent clients.
Also didn't realize trackers were that strict about clients. I've seen some ban buggy versions / sketchy clients (usually cloud-based or for mobile), but that's usually a for-your-own-good type thing. Major names like QBT are usually fine regardless of version.
The private torrent site crowd are very restrictive on which clients are allowed and even big names like qBit aren't safe enough to assume the version is allowed.
I've never looked at the source code of a PT, but my understanding is that they also implement heuristics to detect strange behaviors, i.e. clients trying to fake their ratio.
Not all of them do, but yes. Since it is the client who send all the info (bytes sent/received, version, etc), anything can be spoofed.
The tracker, having access to the stats of all the client on a specific torrent can find "unusual" client (for example, a client that report a lot of bytes sent while no other client report downloading/receiving anything, or the opposite). But due do quirks of the networks, delay and possible lost stats messages, they still have to be pretty permissive of small discrepancies. Also, all use an ID in the tracker url for each client to discriminate them and associate them with their account on the website. And some are not very careful about the ID generation algorithm, leading to being easily able to find other account peer ID, and so you can use them to download to preserve your ratio. I even found at least one private tracker that did not care if you passed a non-existent peer ID.
For example there's also something called "ghost leeching" (side channel entirely bypassing tracker reporting) which can lead to other peers reporting upload for which there's no opposite account of download on the tracker. Making it look like peers over-reported upload and cheated when they are in fact entirely innocent. There's no way for a private tracker to be really sure about stats. The most the moderators can do is to check for repeating suspicious usage patterns across many torrents of a particular peer under scrutiny.
I have used patched version of muTorrent. Binary exe contains string private, and I changed it to crivate with hex editor, so that torrent client stops reacting to private flag and starts whistleblowing peers to DHT. I don't think that my client looks unusual.
It does. If the tracker is monitoring DHT. Or, more likely, if your client finds a similar "no respect for private flags" DHT peer, sends data to it, and reports that to the tracker.
Does that weird DHT peer report to the tracker? It may not even have an account there. From the tracker's end, that peer is a ghost, and it looks like your client has reported sending data no one ever received.
I remember using a ratio-fake tool that would basically proxy your reporting to the tracker with the signature of the client you were actually using. It was awesome.
Sounds like a very restrictive tracker... but I guess the more restrictive, the more likely it has good stuff. Seems kind of strange though because most trackers I have seen just completely ban any sort of proxy or VPN.
They usually ban VPNs for website use but allow them for seedboxes (sometimes requiring approval). The rationale is to stop account sharing and ban evasion.
I don't know but it's pretty suspicious to ban VPNs to use something that is illegal in many countries. Hope they don't keep records that can be leaked.
It's really not. Even if they aren't recruiting new members you can buy an account or invites. You could also prepare alternate accounts ahead of time.
i was expecting a more hands on explanation of what the client sends and what the tracker responds but this post is quite abstract for a technical issue.
from what i read in the PR the qBT fix is to just ignore the proxy on the listening side of things but that doesnt explain the issue
i thought about including packet captures and some analysis on that, but ran out of steam. you're right that it would have made a more interesting post. maybe ill amend it at some point :)
there were other peculiarities i noticed in testing, like udp trackers not working through the socks proxy even after fixing the listening port problem. id like to revisit the topic at some point to see if that can be fixed as well.
Technically you could theoretically accept incoming connections if the SOCKS5 server supports the BIND command and the client knows how to use it. It's rare though.
Stuff like this is why I usually go for network namespaces + (wireguard / socks / iptables) when I need to isolate traffic.
> The tracker in question that I wanted to get this working for explicitly forbids running development builds of approved BitTorrent clients.
Also didn't realize trackers were that strict about clients. I've seen some ban buggy versions / sketchy clients (usually cloud-based or for mobile), but that's usually a for-your-own-good type thing. Major names like QBT are usually fine regardless of version.
The private torrent site crowd are very restrictive on which clients are allowed and even big names like qBit aren't safe enough to assume the version is allowed.
Although the identification is literally just a string you send when connecting, easy to spoof.
I've never looked at the source code of a PT, but my understanding is that they also implement heuristics to detect strange behaviors, i.e. clients trying to fake their ratio.
Not all of them do, but yes. Since it is the client who send all the info (bytes sent/received, version, etc), anything can be spoofed. The tracker, having access to the stats of all the client on a specific torrent can find "unusual" client (for example, a client that report a lot of bytes sent while no other client report downloading/receiving anything, or the opposite). But due do quirks of the networks, delay and possible lost stats messages, they still have to be pretty permissive of small discrepancies. Also, all use an ID in the tracker url for each client to discriminate them and associate them with their account on the website. And some are not very careful about the ID generation algorithm, leading to being easily able to find other account peer ID, and so you can use them to download to preserve your ratio. I even found at least one private tracker that did not care if you passed a non-existent peer ID.
For example there's also something called "ghost leeching" (side channel entirely bypassing tracker reporting) which can lead to other peers reporting upload for which there's no opposite account of download on the tracker. Making it look like peers over-reported upload and cheated when they are in fact entirely innocent. There's no way for a private tracker to be really sure about stats. The most the moderators can do is to check for repeating suspicious usage patterns across many torrents of a particular peer under scrutiny.
I have used patched version of muTorrent. Binary exe contains string private, and I changed it to crivate with hex editor, so that torrent client stops reacting to private flag and starts whistleblowing peers to DHT. I don't think that my client looks unusual.
It does. If the tracker is monitoring DHT. Or, more likely, if your client finds a similar "no respect for private flags" DHT peer, sends data to it, and reports that to the tracker.
Does that weird DHT peer report to the tracker? It may not even have an account there. From the tracker's end, that peer is a ghost, and it looks like your client has reported sending data no one ever received.
That part is just for your own protection - these are almost always private trackers with ratio requirements.
If you spoof the client name and your client ends up misbehaving/misreporting you'll just get banned for cheating.
I remember using a ratio-fake tool that would basically proxy your reporting to the tracker with the signature of the client you were actually using. It was awesome.
You can turn a socks5 into an interface and then move it to a different namespace: https://github.com/xjasonlyu/tun2socks
All that and he didn't even test it with the tracker in the end? What an anticlimax.
Sounds like a very restrictive tracker... but I guess the more restrictive, the more likely it has good stuff. Seems kind of strange though because most trackers I have seen just completely ban any sort of proxy or VPN.
Is it because of some game theoretic information exposure? Or is this more about that you can't trust any of the VPN providers.
why ban VPN? what about seedboxes?
They usually ban VPNs for website use but allow them for seedboxes (sometimes requiring approval). The rationale is to stop account sharing and ban evasion.
I don't know but it's pretty suspicious to ban VPNs to use something that is illegal in many countries. Hope they don't keep records that can be leaked.
>why ban VPN?
It's harder to ban people if you allow using VPNs.
Private trackers have no open registration. If they ban you at the account level then it's pretty hard to get back in.
>then it's pretty hard to get back in.
It's really not. Even if they aren't recruiting new members you can buy an account or invites. You could also prepare alternate accounts ahead of time.
Depends how private...
i was expecting a more hands on explanation of what the client sends and what the tracker responds but this post is quite abstract for a technical issue. from what i read in the PR the qBT fix is to just ignore the proxy on the listening side of things but that doesnt explain the issue
i thought about including packet captures and some analysis on that, but ran out of steam. you're right that it would have made a more interesting post. maybe ill amend it at some point :)
there were other peculiarities i noticed in testing, like udp trackers not working through the socks proxy even after fixing the listening port problem. id like to revisit the topic at some point to see if that can be fixed as well.
Technically you could theoretically accept incoming connections if the SOCKS5 server supports the BIND command and the client knows how to use it. It's rare though.
I've genuinely never seen a server that supports the BIND command.
Since you're already using a proxy, you can have the proxy change the parameters, and then you are not modifying the client.
id be interested to know how i might get started with implementing something like that
By writing your own proxy, and also making sure the URL doesn't say https (you can change it back to https in the proxy you write)
The headline, whilst true to the author, makes no sense. Announces is a verb, announcements is a noun.
A quick search shows me that "annouce" is sometimes used as a noun in the context of bittorrent for some reason.
Because it's a type of message, just like "GET" in the context of HTTP.