they dont ban you for an incorrect header most of the time, just send you some bencoded error.Quote:
Originally Posted by anon
Printable View
they dont ban you for an incorrect header most of the time, just send you some bencoded error.Quote:
Originally Posted by anon
A cheating program shouldn't have detection vectors as a matter of principle, even if it offers no warranties or is not intended to be used on high-level trackers, and especially if they're easily fixable anyway.
Hi everyone, which torrent client should be emulated next? i'm thinking about adding another parameter that we can pass the emulated torrent client codename. (for example -c qbit4.0.3)
Well, the most requested emulations here are qBittorrent and uTorrent, so I guess you could do the latter next. The query string's structure is identical, even...
http://www.sb-innovation.de/showthread.php?t=33450
If possible, please consider prioritize support for a qbittorrent version with individual peer_id and key. qBittorrent/4.2.5 and qBittorrent/4.3.1 are the two that use individual peer_id and key and also the most widely used version currently (according to peerlists on multiple trackers)
Also about that info_hash bug, I've just selected 20 random torrents to test again (v1.6 + windows), involving 11 trackers I often use. Result: 16 torrents of them showed info_hash bug, 1 showed unregistered torrent error message (the following test with real client proved it was registered) , only 3 (out of 20) torrents working normally. This info_hash bug is not rare to me, it's a bug that makes this tool still unusable.
Ok, thanks to @anon i might have found the problem,i will release a version later today if everything checks, @JohnareyouOK could you send more error samples on pm?
@Edit
Version 1.7 is out with the info_hash fix
BIG thank you for the quick fix! besides, is it the tracker side's reason that announce interval for torrent 4~7 are all constant 30s? (also 4 trackers)
It's the tracker that recommends the interval rateQuote:
Originally Posted by JohnareyouOK
Note that all versions from 4.0.4 onwards exhibit this behavior. Before then, the peer_id was global.Quote:
Originally Posted by JohnareyouOK
Quote:
Originally Posted by JohnareyouOK
No tracker will ever suggest such an extremely low value, so I'm thinking there's a bug here. Note that returning an interval is optional, and if none is given, you should assume 1800 seconds (which is 30m rather than 30s, perhaps this is just a simple typo in the source?).Quote:
Originally Posted by pauloafonso
Announce interval in real qB is not 30s for these same torrents. Packet shows min intervals trackers return are 30s, none of intervals are 30 seconds, is it possible code using min interval rather than interval parameter?Quote:
Originally Posted by pauloafonso
---------- Post Merged at 16:03 ---------- Previous Post was at 16:00 ----------
Attachment 20883
Had a look at the source and it looks like you're right.Quote:
Originally Posted by JohnareyouOK
Code:func (R *ratioSpoofState) updateInterval(resp trackerResponse) {
if resp.minInterval > 0 {
R.announceInterval = resp.minInterval
} else {
R.announceInterval = resp.interval
}
Yes, currently i'm using the minInterval if its higher than 0, i will change to interval later, what do you guys think about this? and which value should i hard-code if interval is not present?1800 seconds ?
Quote:
Originally Posted by pauloafonso
Yes and yes :happy:Quote:
which value should i hard-code if interval is not present?1800 seconds ?
v1.8 is out
Now we always use "interval" and if not present 1800s
i'm working on a new ratio-spoof version with multiple-client emulation support(for now qbit-4.0.3 and qbit-4.3.3), would anyone be interested in testing it?