💡 **BT下载数据统计的潜在漏洞**：PT下载主要依赖客户端汇报的`downloaded`和`uploaded`字段进行数据统计。然而，这些字段最初并非为严格限制分享率（ratio）而设计，因此存在被利用的可能性。作者通过对BT协议和Tracker协议的学习，发现了这一机制的“可操作点”。

🚀 **Tracker代理实现下载量规避**：作者开发了一个Tracker代理，用于拦截BT客户端向真实Tracker的汇报。当客户端连接时，代理会检查缓存中是否存在该种子的Peer列表。若列表存在且未过期，则直接返回，从而实现不计入下载量的效果。如果缓存中不存在，代理才会向真实Tracker发起“开始下载”请求，获取Peer列表并进行缓存。

🌐 **潜在的Peer列表整合优势**：除了规避下载量统计，该Tracker代理还可能带来一个额外的好处。当两个用户从不同的PT站点下载同一个种子时，如果他们都使用这个代理，代理可能会整合来自不同Tracker的Peer列表，从而使每个用户都能连接到更多的Peer，提高下载效率。

💻 **简易前端与使用方法**：由于作者不擅长前端开发，该工具的网页界面非常简洁，只有一个上传种子的按钮。用户上传种子文件后，工具会自动修改种子并提供修改后的文件供下载，然后用户将此修改后的种子添加到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