本文作者分享了入坑PT一年来的探索，从bencode到tracker协议，深入理解了PT机制。文章重点介绍了如何利用BT客户端汇报数据（downloaded和uploaded）的机制漏洞，实现不计入下载量的PT下载。作者开发了一个tracker代理，能够缓存peer列表，在客户端汇报时返回缓存数据，从而达到不计下载量的效果。此外，该方法还能整合不同PT站点的peer列表，增加连接的peer数量，提升下载效率。文章还提到，作者开发了一个简单的网页工具，用户上传种子后即可下载修改后的种子，方便添加到BT客户端使用。文末提供了网站和GitHub仓库链接。

💡 PT下载机制的原理与漏洞：PT站通过客户端汇报的downloaded和uploaded数据来统计用户流量，但这些字段并非最初为限制流量比率而设计，因此存在可利用的漏洞。作者通过深入学习bencode和tracker协议，发现了这一机制的实现细节。

🚀 Tracker代理实现不计下载量：作者开发了一个tracker代理，当BT客户端向其汇报时，代理会检查并返回已缓存的、未过期的种子peer列表。如果缓存中不存在，则向真实tracker请求，并将获取到的peer列表进行缓存，从而实现客户端汇报下载量时，实际下载量不被计入PT站点的统计。

🌐 整合Peer列表与提升下载效率：该tracker代理的另一个潜在好处是，当不同PT站点的用户下载同一个种子时，他们的peer列表可以被整合。这意味着用户可能连接到更多来自不同站点的peers，从而有机会提升下载速度和稳定性。

🛠️ 简易种子修改工具：作者开发了一个简单的网页工具，用户只需上传种子文件，工具会自动修改并提供修改后的种子文件供下载。用户将修改后的种子添加到BT客户端即可开始下载，实现不计下载量的目标。网站和GitHub仓库链接也已提供。

我入坑 PT 也快一年了，之前偶然读到了一篇博客，讲的是 PT 机制的几个有意思的漏洞。正好我对 BT 也不是很了解，就一路从 bencode 学到 tracker 协议，现在也算是对这块比较熟悉了。

PT 只靠客户端汇报的 downloaded 和 uploaded 来统计数据，而这些字段原本不是设计来限制 ratio 的，所以自然就留下了很多可以做文章的点。我就跟着博客作者的思路，实现了一个 tracker “代理”，当 BT 客户端向代理汇报的时候代理就会检查缓存里是否有这个种子的 peer 列表，如果有并且没过期就直接返回，否则向真实 tracker 发起一个“开始下载”的请求，得到 peer 列表并存储。这样就可以实现不计入下载量的效果。

而且可能还有一个额外的好处，就是如果两个人下载同一个种子，但是通过不同的 PT 站，那么 peer 列表会被整合，让每个人都能连接到更多的 peer 。

因为我不太会前端，所以网页做得比较简单，就一个按钮，把种子上传之后会自动修改并下载修改后的种子，然后添加到 BT 客户端就可以下载了。如果感兴趣可以试一试。

网站： https://tracker.submy.org

仓库： https://github.com/arielherself/btc