RatioMaster 1.8.7 updated by SB-Innovation

[anon]

SB-Innovation Presents

>>>>>> RatioMaster 1.8.7 updated by SB-Innovation <<<<<<

╔═══════════════════════════╗
Coded by:
╚═══════════════════════════╝

>>>>>> RatioMaster <<<<<<

╔═══════════════════════════╗
Source:
╚═══════════════════════════╝

>>>>>> moofdev <<<<<<

╔═══════════════════════════╗
Updated by:
╚═══════════════════════════╝

>>>>>> Rebound & anon <<<<<<

╔═══════════════════════════╗
Supplier:
╚═══════════════════════════╝

>>>>>> anon <<<<<<

╔═══════════════════════════╗
Changelog / Features:
╚═══════════════════════════╝

Changelog:

Version 1.8.7
--------------
- Update : moved client files to separate folder (/clients)
- Bug fix : fixed crash "invalid ip" on some computers
- Bug fix : fixed slow loading time on some computers
- Update : updated language template to ver. 1.8.7, new translation and client files

Version 1.8.6
--------------
- Feature : added 'Reset Counters' button, to reset upload/download amounts to previous values
- Update : support for type="alphabetic" and type="printable" attributes in client files
- Update : support for urlencoding "exceptions" node , see example in utorrent_1.8.3_build_15728.client
- Update : support for lowerCase="true" and "false"
- Update : updated language template to ver. 1.8.6, new translation and client files
- Bugfix : improved handling of bad ssl sertificates
- Small fixes and improvements

...

Version 1.8.2
--------------
- Feature : added ability to download new client files and translations directly from RM (tab Updates)
- Bug Fix : corrected "Host" header that RM sending to tracker in some cases - No more ort issue!
...
- Small fixes and improvements that i forgot about. - Scrape now works!

...

Version 1.7.5
--------------
- Bug Fix : Improved handling of connection and response timeouts.
- Bug Fix : Fixed problem with sockets not being closed
- Update : Updated build in uTorrent emulation to uTorrent 1.6.1 (build 490)
- Feature : added AI based on neural networks
- Feature : added voice recognition.
- build an installer (THX CoreCore!)

Client Files

Last Update: 11.07.2009

- ABC 3.1.0
- Azureus 2.5.0.0
- Azureus 2.5.0.2
- Azureus 2.5.0.4
- Azureus 3.0.0.6
- Azureus 3.0.0.8
- Azureus 3.0.3.0
- Azureus 3.0.3.4
- Azureus 3.0.4.2
- Azureus 3.0.5.0
- Vuze 3.1.1.0
- Vuze 4.0.0.0
- Vuze 4.0.0.2
- Vuze 4.0.0.4
- Vuze 4.1.0.2
- Vuze 4.1.0.4
- Vuze 4.2.0.0
- Vuze 4.2.0.2 Recommended, info_hash issue fixed
- BitComet 0.63
- BitComet 0.79
- BitComet 0.84
- BitComet 0.85
- BitComet 0.86
- BitComet 0.87
- BitComet 0.88
- BitComet 0.89
- BitComet 0.90
- BitComet 0.91
- BitComet 0.92
- BitComet 0.93
- BitComet 0.94
- BitComet 0.95
- BitComet 0.96
- BitComet 0.97
- BitComet 0.98
- BitComet 0.99
- BitComet 1.00
- BitComet 1.03
- BitComet 1.04
- BitComet 1.05
- BitComet 1.07
- BitLord 1.1
- BitTyrant 1.1
- BTuga 2.1.8
- Burst 3.1.0b
- Halite 0.3.1.1 Generated peer_id and key improved
- µTorrent 1.5
- µTorrent 1.6 (Build 474)
- µTorrent 1.6.1 (Build 483)
- µTorrent 1.6.1 (Build 489)
- µTorrent 1.6.1 (Build 490)
- µTorrent 1.7 (Build 1875)
- µTorrent 1.7.1 (Build 3360)
- µTorrent 1.7.2 (Build 3458)
- µTorrent 1.7.3 (Build 4470)
- µTorrent 1.7.4 (Build 4482)
- µTorrent 1.7.5 (Build 4602)
- µTorrent 1.7.6 (Build 7859)
- µTorrent 1.7.7 (Build 8179) (THX CoreCore!)
- µTorrent 1.8 (Build 11813)
- µTorrent 1.8.1 (Build 12616)
- µTorrent 1.8.1 (Build 12639)
- µTorrent 1.8.2 (Build 14153)
- µTorrent 1.8.2 (Build 14458)
- µTorrent 1.8.2 (Build 15167)
- µTorrent 1.8.2 (Build 15227)
- µTorrent 1.8.2 (Build 15296)
- µTorrent 1.8.2 (Build 15357)
- µTorrent 1.8.3 (Build 15728) Recommended, info_hash issue fixed
- µTorrent 1.8.3 (Build 15772) Recommended, info_hash issue fixed
- BitTorrent 6 (Build 4747)
- BitTorrent 6 (Build 5535)
- BitTorrent 6.0.3 (Build 8642)
- BitTorrent 6.1 (Build 11862)
- Deluge 1.1.7
- Transmission 1.06 (Build 5136) Generated peer_id and key improved

Weitere Wünsche für Client-Files sind immer Willkommen.
Of course you can post client file wishes for any client.

We have permission from the coder to post this tool!


╔═══════════════════════════╗
Password:
╚═══════════════════════════╝

joe6iut5n0i1lp90

[shoulder]

With Memory Reader and a correct client file there's no reason why it shouldn't work.

[anon]

Believe it or not! The times when the RM itself was detectable are over. No more ort issue, fixed scrape, use the memory reader and you get values from a real client, urlencoding exceptions...

Use the fixed 1.8.3 client file if you plan to emulate uTorrent at ScT!

[listener]

Lots of trouble with the randomizer lately...

The update interval varies from tracker to tracker - it can be as low as 20 minutes, or as high as 60. (I have seen 180m on a public tracker )

To make a graphic example:

• You set it between 100 and 150
• You set the initial speed to 100kB/s, and start the RM
• Say, 30 minutes pass, first tracker update, the tracker sees 100kB/s
• The RM picks another speed between your values, for example 128.07kB/s
• 30 minutes pass again, the tracker will see 128.07kB/s.

(Remember that in the peerlist, speeds are averaged. If you fake at 500kB/s, the first tracker update takes place, then you drop to 0kB/s, the tracker will show 250kB/s in the peerlist. If your speed is still 0kB/s after the third update, 125kB/s will be shown, and so on. So don't rush and check the "Connected" column to see for how much time that user's torrent has been running!)

In a nutshell: just enable the randomizer and don't worry about it

I know, I know, I really understand all that. But can you please read my previous comment again. My question was not about the average speed, but about the total "transferred" amount of bytes between 2 successive updates.
I said, because the speed seems to be specific up to 1/100 kB/s (the speeds are given up to 2 decimals after the comma). So if it uses a randomized speed in the first run, it will end at every update in a total transferred of x times 18 kB when you're on a tracker with a fixed update interval of 1800 seconds.

Please read this carefully, I know what I'm saying
but I think (hope) that the programma actually works with more decimals specified and just doesn't show those to the user.

[atlantis]

Believe it or not! The times when the RM itself was detectable are over. No more ort issue, fixed scrape, use the memory reader and you get values from a real client, urlencoding exceptions...

Use the fixed 1.8.3 client file if you plan to emulate uTorrent at ScT!

what do you mean with "fixed" ?

[anon]

"Fixed" means the characters the emulated client does NOT percent-encode when sending the info_hash aren't percent-encoded when the RM sends it, either. They make announces look 100% like a real client's when using the memory reader, so use them whenever available.

[alpacino]

RM was tested on ScT or What.cd?

Oh yes, they work. Like anon said, using memory read it will be pretty safe. On ScT you can jump on new torrents with high speeds and blend among the seedboxes (just don't go to the extent of pretending being one!). On what.cd works like a charm too. But there you have to use low speeds, or try the waffles method, read the guides by Mihai91 on tutorial section, there's been some reports of it working good, don't overdo.

My question was not about the average speed, but about the total "transferred" amount of bytes between 2 successive updates.

The total amount transfered will be the one precisely reported by RM on the gui, as long as the updates run smoothly. Hope it helped, and this 18kB multiple that you mentioned, I think it's nonsense, don't worry that much!

[Haggar]

Believe it or not! The times when the RM itself was detectable are over. No more ort issue, fixed scrape, use the memory reader and you get values from a real client, urlencoding exceptions...

Use the fixed 1.8.3 client file if you plan to emulate uTorrent at ScT!

Hi, is this fixed 1.8.3 client included with this rm or is only available for members? And wich build is emulating?

[anonftw]

Hi, is this fixed 1.8.3 client included with this rm or is only available for members? And wich build is emulating?

It's available to nonmembers too and contains both

- µTorrent 1.8.3 (Build 15728) Recommended, info_hash issue fixed
- µTorrent 1.8.3 (Build 15772) Recommended, info_hash issue fixed

[listener]

The total amount transfered will be the one precisely reported by RM on the gui, as long as the updates run smoothly. Hope it helped, and this 18kB multiple that you mentioned, I think it's nonsense, don't worry that much!

Probably it is nonsense indeed. I would just like to know why...

[anon]

Probably it is nonsense indeed. I would just like to know why...

Apart from trackers using different intervals, the RM notchs down exact 1024*1024 multiples, if I remember correctly...

[listener]

Apart from trackers using different intervals, the RM notchs down exact 1024*1024 multiples, if I remember correctly...

I'm sorry to keep going on about this subject, but I just want to help closing every single gap between GM behaviour and real torrenting (and have absolute certainty that it can't be detected of course).

Of course my x*18kB was just an example for trackers with update time of 1800 seconds. If the tracker has a fixed update time of 1 hour, this would be x*36kB and so on. The bottom line is that any tracker with a fixed update interval would be able to pick out the RM users because they would always have uploaded multiples of a tracker-specific amount, depending on the update interval. (If the RM makers wouldn't have anticipated on that of course.)

What you just said, does it mean that RM never results in a "total uploaded since last update" value of exactly x kB? (1024*1024 would be MB, right?)

[anon]

Of course my x*18kB was just an example for trackers with update time of 1800 seconds. If the tracker has a fixed update time of 1 hour, this would be x*36kB and so on. The bottom line is that any tracker with a fixed update interval would be able to pick out the RM users because they would always have uploaded multiples of a tracker-specific amount, depending on the update interval. (If the RM makers wouldn't have anticipated on that of course.)

You may be right. If you're worried about this, use mR, but:

What you just said, does it mean that RM never results in a "total uploaded since last update" value of exactly x kB? (1024*1024 would be MB, right?)

I think it works like this
1024*1024=1048576

The RM rounds it to 1048500 if I'm not mistaken. The amount is then no longer a multiple of the tracker interval, right?

[listener]

I think it works like this
1024*1024=1048576

The RM rounds it to 1048500 if I'm not mistaken. The amount is then no longer a multiple of the tracker interval, right?

I'm afraid I'm not really seeing what you mean.
This is how I'm reading your post, but maybe that's wrong...:
1024*1024= 1048576 => meaning 1048576 bytes in a MB? yes, that's true...

If RM rounds off the uploaded figure only when it's exactly that value, it's no use to deflect the potential problem about the multiple of tracker interval, because (again for the example of a fixed 1800s tracker interval) exactly 1048576 bytes can never be upped in 1 interval because it's no multiple of 18kB.

If RM rounds off every uploaded figure to a number of bytes ending with two zero's; RM could probably be detected very easily anyway, having ALWAYS an upload of multiple of 100B. However, this (and also the potential problem I suggested) is only a problem if the real torrent clients aren't doing the same thing...

But I guess nobody here knows this for sure?
Thanks for your answers and your time Anon, I already learned a lot in your posts here :)

[anon]

If RM rounds off every uploaded figure to a number of bytes ending with two zero's; RM could probably be detected very easily anyway, having ALWAYS an upload of multiple of 100B. However, this (and also the potential problem I suggested) is only a problem if the real torrent clients aren't doing the same thing...

It doesn't, but again, I'm not fully sure about how it works.

I'll PM Mr. RatioMaster to see what's his say on this.

[bakuno]

Are there any chances guys, to add for non members azu 4.2.0.5 client file?