Really? If that's so, then I stand corrected.
My reasoning was that most clients don't really let you mess with the timeout (to my knowledge) between updates, and if they see that you update after 5 minutes, then after 2, then after 10 seconds, then 5 minutes again, then you're obviously doing something by hand...
Though, looking now, there's an "update tracker" option in utorrent 1.6.1 -- I'm guessing this sends an update? Never had to use it
The automatic update intervall is just the prefered one sent by the tracker.
The manual update is just blocked for a few minutes after the last update, and restarting the torrent ("updating") isn't blocked at all.
------------------------------>>>>>>>>>> <<<<<<<<<<------------------------------
Yes, it does, and that version doesn't have anti-hammering like newer ones do. However, in general it's not a good idea to update manually unless something's going wrong.Originally Posted by TheUnknown
Though, looking now, there's an "update tracker" option in utorrent 1.6.1 -- I'm guessing this sends an update? Never had to use it
"I just remembered something that happened a long time ago."
Yeah... I still use it because it's the last version I know of that can do ghost-leeching without any mods...
Well, it appears you can ghostleech with the newer official uTorrent versions too if you use the Trackers tab to remove the tracker URL instead of the Properties window - unless they patched this in 2.0.
"I just remembered something that happened a long time ago."
Really? Is that a bug or something? Are we talking all the way up to ver 2.0?
I guess so
I haven't checked the official 2.0, only tested that up to v1.8.5.Are we talking all the way up to ver 2.0?
"I just remembered something that happened a long time ago."
How much would you consider to be safe? I'm planning to do something <10kb/s.
<20kB/s
"I just remembered something that happened a long time ago."
lol I got banned.
I mistyped my password, as I entered the password I always use for everywhere which I used on my first account on What.CD. Immediately after I entered it correctly. In 2 hours I got banned.
They must have a script that searches incorrect passwords with existing passwords on disabled user accounts, and if they match --> boom headshot.
That's really sneaky. By the way there's a special emoticon for "boom headshot" and it's called SniperHeadShot2.
Last edited by ooblar; 14.03.10 at 02:23.
You sure that is all you've done? I mean, this is a forum about cheating trackers... you probably did a bunch of other stuff and this is a coincidence. That script wouldn't be very reliable.
Not to mention, it is not common for websites to store your password in plaintext.
Usually the password hash is stored along with a random-per-user salt.
So...
Make account(username, password) ===> server generates SALT.. stores (Hash(password+SALT), SALT)
login(username, password) ====> server compare(Hash(entered_password + SALT), stored_hash)
Yeah the account was 100% fresh (500mb up 0mb down, 1 day) and I didn't anything illegal yet (on this acc, yes on my previous one).
The DB of gazelle stores everyone's pass in 128-bit MD5 (I have checked it locally), so if my password was, say, "password", it stores to the correspondant table as "5f4dcc3b5aa765d61d8327deb882cf99". That grants no one with access to the DB can see it as plain text (although this is not 100% true, you could insert a proxy machine previous to the DB or break the MD5 hash if the password is not too complex), but they have access to the tables (and therefore all the passwords in MD5), so it's as simple as making the script so as to compare the MD5 string sent to the authentication module with the MD5 hashes of the disabled users, if they match, return something and you are done.
Same for dupe accounts.
What I don't know is why are they so paranoid, as the script would take a lot of resources (maybe it's run on a separate machine but it has still to access the DB).
The passwords are salted. it would be ineffective for them to brute force everyone's passwords.
They cannot even use rainbow tables because of the salt, so they'd have to manually try all those hashes with secure salts.. It's not feasible.
Reply With Quote
Bookmarks