• Welcome to Valhalla Legends Archive.
 

HOW THE HELL?!?!?!

Started by Gangz, October 24, 2003, 05:28 PM

Previous topic - Next topic

Gangz

Well as most of you have know Fleet- came out with another pussy flood that tops his last one....I have never been able to make a bot connect on BNLS or CSB that is fast enough to catch it...last night we got flooded by a whole clan and my friend put his stealth on ops and efp banned every single on of em...anyone can explain this 1?

Tuberload

#1
I don't understand how it would be BNLS fault that a bot wouldn't be fast enough. You only have to use BNLS to get past the logon stages don't you? CSB could be to blame because it might not receive, and process the data fast enough, but a daemon used to log a bot onto battle.net easier doesn't seem like it should cause problems later on. Maybe it is something in your bot causing problems? That might be something worth investigating.
Quote"Pray not for lighter burdens, but for stronger backs." -- Teddy Roosevelt
"Your forefathers have given you freedom, so good luck, see you around, hope you make it" -- Unknown

Freeware

Quote from: Gangz on October 24, 2003, 05:28 PM
Well as most of you have know Fleet- came out with another pussy flood that tops his last one....I have never been able to make a bot connect on BNLS or CSB that is fast enough to catch it...last night we got flooded by a whole clan and my friend put his stealth on ops and efp banned every single on of em...anyone can explain this 1?

stealth bot just isnt fast enough to catch a titan, but for your own custom bot i have some suggestions:

 1. Having to read an access list takes time, I recommend perhaps the bot ONLY responding to a single person that it loads at startup.
 2. Dont add an extensive GUI, just make it show if the bot is offline, online, logged in etc... In other words, dont show an userlist or chat.
 3. Dont make exentsive commands that take forever to search through, in this case a simple ban / unban / ipban might do.
 4. If you want the FASTEST connection, use winsock.dll instead of a winsock control/csb. It is proven to be much faster.
 5. Make sure you have cable/dsl/or faster (obvious but true)
 6. Make your clan channel in warcraft III, so you can use the /clan private command to stop others from entering.
 7. Just dont get into fights if you can fight them off
 8. Stop whining about Fleet-, the more you yell and cry the happier everyone else will be
 9. Switch to C++, its faster than Visual Basic

im not sure if this will help you or not, but good luck.

Skywing

I think that in general you will find that network transit times are orders of magnitude longer than processing an access list, even in Visual Basic, as long as you're not talking about an unreasonably large database.

Note that of course it's possible to make database lookups very slow by using a poor design, such as doing disk I/O every time you want to look up somebody's privileges.

In many cases you simply won't be able to ban these kinds of bots  in between their joining and leaving the channel.  For instance, if such a bot were to send a join message and a disconnect message in the same TCP packet (e.g. PSH|FIN), it's not reasonable to expect that you'll ever be able to ban it in the interval between joining and leaving.

However, I can recommend two algorithms that you can use to mitigate the disruption causes by these types of attacks, one for an operator bot and one for a chat bot.

In many cases, the server will send both join and leave notifications for these very-fast-rejoin bots in the same TCP packet.  You can roughly equate the chunk of data that you receive in a data arrival notification to a TCP packet arriving.  You can take advantage of this by deferring all potential automatic bans until after you have finished parsing Battle.net packets out of the data you have just received.  After you've finished parsing the received data, you can go and check to see if you were notified that a user both joined and left the channel in the same data chunk.  If this is the case, it's probably not worth trying to ban them, so you can safely suppress a potential automatic ban response and save your moderator bot some queue quota.

The second algorithm is for clients intended to be used by a human to chat through.  Essentially, you may find it useful to delay most processing of chat events for several seconds.  This allows you to detect a "flood bot" joining and leaving the channel very quickly.  Typically you would react to this by silently dropping notifications to the end user about the "flood bot" in question, greatly reducing the amount of spam the end-user must deal with.

Both of these topics have been extensively discussed in the past, and I believe some sample implementations were given.  I recommend that you use the search feature to find these past threads.

Freeware

BTW it is possible to ban a titan, but with multiple cdkeys / usernames it makes it more difficult. A poor system that works well against only a few usernames/cdkeys would be to implement a command that sends /ban a few times.

.titanban <username>
On recieving that, your bot should send  /ban <username> about 10-15 times (of course make sure you have anti-flood queue). Then by pure luck you should be able to ban them as they connect. It *DOES* work, but it will be less effective with users that have many keys / usernames.

Again, using a Clan channel instead of an Op will be MUCH easier, since you can use /clan private.

iago

Also, making the chatbot you use ignore flooders so you don't ever see them is the easiest way.
This'll make an interesting test for broken AV:
QuoteX5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*


Lenny

Quote from: Freeware on October 24, 2003, 06:44 PM
BTW it is possible to ban a titan, but with multiple cdkeys / usernames it makes it more difficult. A poor system that works well against only a few usernames/cdkeys would be to implement a command that sends /ban a few times.

.titanban <username>
On recieving that, your bot should send  /ban <username> about 10-15 times (of course make sure you have anti-flood queue). Then by pure luck you should be able to ban them as they connect. It *DOES* work, but it will be less effective with users that have many keys / usernames.

Again, using a Clan channel instead of an Op will be MUCH easier, since you can use /clan private.

The probability of banning a floodbot depends on connection speed and what the actual bot does...

Titan has an obvious flaw, it idles in a random channel before flooding, if you could predict the username its logged on to (just see 1 cycle through the name list) you  could ban it before it even has a chance to join the channel....This is why sending /ban constantly has a chance to catch it...
The Bovine Revolution
Something unimportant

Live Battle.net:

WARNING: The preceding message may have contained content unsuitable for young children.

Spht

Quote from: Gangz on October 24, 2003, 05:28 PM
Well as most of you have know Fleet- came out with another pussy flood that tops his last one

No, I didn't know. Who's Fleet-?

Quote from: Freeware on October 24, 2003, 05:48 PM
stealth bot just isnt fast enough to catch a titan

In most cases, the bot isn't to blame, unless it's overly bloated with bad coding. See Skywing's post.

Quote from: Freeware on October 24, 2003, 05:48 PM
1. Having to read an access list takes time, I recommend perhaps the bot ONLY responding to a single person that it loads at startup.

Um, no. I clocked my client taking zero-time to run through [vL]'s access database (which contains over 1900 users).

Quote from: Freeware on October 24, 2003, 05:48 PM
2. Dont add an extensive GUI, just make it show if the bot is offline, online, logged in etc... In other words, dont show an userlist or chat.

Probably not the best suggestion for chat bots. For a chat bot I'd implement something like what Skywing mentioned (which is called SVProtect - Short Visit Protection). And of course a client designed purely for channel moderation shouldn't need a GUI anyway, right?

Quote from: Freeware on October 24, 2003, 05:48 PM
3. Dont make exentsive commands that take forever to search through, in this case a simple ban / unban / ipban might do.

What, you mean like a bot which has 10,000 commands? Only then can I picture there being a slight decrease in performance. Otherwise, I don't think the amount of commands a bot has should be a worry.

Quote from: Freeware on October 24, 2003, 05:48 PM
4. If you want the FASTEST connection, use winsock.dll instead of a winsock control/csb. It is proven to be much faster.

Makes sense.

Quote from: Freeware on October 24, 2003, 05:48 PM
5. Make sure you have cable/dsl/or faster (obvious but true)

That may help in some cases.

Quote from: Freeware on October 24, 2003, 05:48 PM
9. Switch to C++, its faster than Visual Basic

Quite blunt, but compared to your other suggestions, it's probably your best one.

Freeware

+1 to Spht for being so critical  ;D

Grok

Quote from: Skywing on October 24, 2003, 06:14 PM
I think that in general you will find that network transit times are orders of magnitude longer than processing an access list, even in Visual Basic, as long as you're not talking about an unreasonably large database.

Note that of course it's possible to make database lookups very slow by using a poor design, such as doing disk I/O every time you want to look up somebody's privileges.

Regarding database speed; so long as you're not talking about a flat file, but have some kind of indexing in place, you could have a million entries in the database and the search time could still be 0.0005 seconds.  I saw this result today while running a query on a db server on the network.  It wasn't even local to the caller.

You're right in cases where people are implementing their own databases using unindexed data.

Kp

As Spht hinted at, a true moderator bot shouldn't waste any time on an interface.  It's not that the interface will slow it down much (usually), but that there's no value in encouraging a user to try to chat through it, which IMO is exactly what providing a nice interface accomplishes.

Regarding attempts to ban a floodbot, there's obviously another major flaw in the bot which I'm surprised to see.  Months ago, vL was attacked by bots written by someone with enough sense not to do this, yet here we see a new floodbot dumb enough to reuse usernames?  Pssh.  Anticipation of a floodbot's username can be easily countered by rolling a long random string of letters/numbers for a username and using it to logon -- and change it every time.
[19:20:23] (BotNet) <[vL]Kp> Any idiot can make a bot with CSB, and many do!

SiMi

About titan... I've heard of it many times, what is the secret to this floodbot and who created it?

hismajesty

Quote from: Simi on October 24, 2003, 10:17 PM
About titan... I've heard of it many times, what is the secret to this floodbot and who created it?

I don't remember what the secret is...but Fleet- made it.

Gangz

i have still not figured this out but you all talk as if it is not possible..it was nuts we turned on EFP and it banned every singe 1...I done know if the que allowed to ban right when the next 1 came on but it worked i ment to screen shot it but i spaced out and forgot...but if it did time and ban right when it logged on again that may work for banning many of the titan floods

Skywing

Quote from: Gangz on October 25, 2003, 12:15 AM
i have still not figured this out but you all talk as if it is not possible..it was nuts we turned on EFP and it banned every singe 1...I done know if the que allowed to ban right when the next 1 came on but it worked i ment to screen shot it but i spaced out and forgot...but if it did time and ban right when it logged on again that may work for banning many of the titan floods
It's possible if the floodbots that attacked you were flawed.

You'd probably need at least millisecond-resolution in your timestamps to see how fast they really stay in the channel.