HOW THE HELL?!?!?!

[Gangz]

the new flood by fleet- that shitty titan hyper has the avdertisement for his site when it floods. It was one of those so i dont see why it would be different from any other one of his floods. I have the original source that he stole that version of shit bot from and i see know flaws in it and stealth bot 2.1 Efp is banning em all the time

[Stealth]

All EFP does is what a solid moderator bot might do in the first place:

1. Events are not presented to the user while it's activated, excepting chat events.
2. The queue is taken offline.
2. Events are checked to see if they're joins; if they are, the username is pulled directly out of the packetdata and compared against the dynamic safelist and user access arrays.
3. If there is no match within the safelist / userlist, the joinee is immediately banned.

Additionally, since TALK packets are parsed, the bot functions exactly the same internally -- so all commands used in the channel still perform their desired functions, albeit with no response to the user.

A cap variable makes sure that the bot will not drop if multiple people or bots join at the same time attempting to ban them.

There's obviously many ways this could be made more efficient, but it does a fair job if you're on a solid connection. For example, temporarily combining the safelist and the userlist into one master array of safe users; which would decrease the amount of time spent checking each user's statis before they are banned.

Since StealthBot is not designed to be purely a moderation bot, removing all GUI elements is not practical; however, with EFP on join and leave packets are dropped so no changes are made to the bulky listview, and the user has the option of locking the main rich textbox so that no text is displayed there as well. I have also introduced code to change the RAM priority of the program during EFP to High, which should help on slower or low-memory machines. Normal priority is restored once the feature is turned off.

Additionally, it's important to note that the "titanban" solution previously described will not work, because the newer floodbots randomize their names.

So, Gangz, there's your answer. In a nutshell, it ignores Battle.net except for join and talk packets, then bans the user who joins with only two dynamic-array passes to slow it down.

[Gangz]

its nice to have your input  . But as I have tested many times it only bans the newest flood made by him and it only works on 2.1....For somereason this is happening and its the ONLY bot i have ever seen ban it... im kinda stump on how it has happened...But as you said it is a little bit slower because of the safelist check so i think hes new flood is sped up and i think its is kind of in sinc and it's luck that the 2 work like that together...call me stupid but thats the only logical reasoning i can see behind this

[Skywing]

I still think that waiting until you've checked all messages received in the current data chunk is a good idea because you'll lose much more time due to flood protection on a missed ban than on any overhead involved (assuming you write sane code).

In any case, it's important to actually run some precision benchmarks to determine just what code actually needs optimizing and what doesn't.  Considering that at the minimum your response times to Battle.net will be in the tens of milliseconds, possibly over a hundred, trying to speed up a function that operates in .25 milliseconds isn't going to impact if you can ban somebody or not.

[iago]

I still think that waiting until you've checked all messages received in the current data chunk is a good idea because you'll lose much more time due to flood protection on a missed ban than on any overhead involved (assuming you write sane code).

In any case, it's important to actually run some precision benchmarks to determine just what code actually needs optimizing and what doesn't.  Considering that at the minimum your response times to Battle.net will be in the tens of milliseconds, possibly over a hundred, trying to speed up a function that operates in .25 milliseconds isn't going to impact if you can ban somebody or not.

I don't think VB's winsock control lets you do that, I think it automatically parses them out.  I could be wrong, though.

[Adron]

You are wrong iago, VB's winsock control lets you receive all the data currently available from the network just like recv in a C++ program.

[Grok]

Is the next ops bot evolution something in cooperative banning?  Since an Ops channel can have two ops, if they were able to negotiate which users they were banning it would double the bannable number and banning speed.

[turtles]

Is the next ops bot evolution something in cooperative banning?  Since an Ops channel can have two ops, if they were able to negotiate which users they were banning it would double the bannable number and banning speed.

There is already a bot that does. It is most effective against a Mass Load.

Funny how Fleet- came out with a new flooder immediately after i released my source.  

He was never a good programmer and understand nothing about packets. His coding was taken from a stealthbot and still retains its code-form. He turned into a jackass and after I cut ties with him he continues to harass me.  

Here's a link to his Flawed Bot v1.12

http://www24.brinkster.com/krazyturtles/flwdsrc.zip

Reason why I have his source at all was because he was too god damn dumb to implement socks support.
I gave him my source which has sock support so he can learn from it and he still can't figure out how it works.

[SiMi]

does that link not work or is it just me?

[Hitmen]

Is the next ops bot evolution something in cooperative banning?  Since an Ops channel can have two ops, if they were able to negotiate which users they were banning it would double the bannable number and banning speed.

I belive feanor tried that, or something similar, with firebot.

[Freeware]

Is the next ops bot evolution something in cooperative banning?  Since an Ops channel can have two ops, if they were able to negotiate which users they were banning it would double the bannable number and banning speed.

Dualops (or for a Warcraft III 4x Ops) is very effective, I have just incorporated it into my bot. Banning flood bots like the titan could also be banned this way (this is the way my bot does it, and it DOES work against titans very well)

 .titanphrase <string> - Sets a string to recognize the bot as a titanbot. For an example if the titan says:

<TitanBot>: Your Clan Sux!
<TitanBot>: HAHAHAHAHA
<TitanBot>: Your Clan Sux!

 the string could be set to: Sux!

Then every person that says that line is added to an array, until the same username is encountered. Once that username is encountered, the bot sends /ban <username> where <username> is the NEXT username to be used. It sends this after a few second delay, anticipating when the next username comes online. It also sends the /ban 3x times just incase it comes online a few seconds later than expected.

Of course the procedure ONLY works against bots that go through a userlist, if they chose random names it would be quite uneffective.

Too bad people on your friends list have to be mutual to recieve the 'your friend just came online' info, otherwise you could just add the titan to your friendslist, and when it came online ban it.  

[______]

Is the next ops bot evolution something in cooperative banning?  Since an Ops channel can have two ops, if they were able to negotiate which users they were banning it would double the bannable number and banning speed.

Dualops (or for a Warcraft III 4x Ops) is very effective, I have just incorporated it into my bot. Banning flood bots like the titan could also be banned this way (this is the way my bot does it, and it DOES work against titans very well)

 .titanphrase <string> - Sets a string to recognize the bot as a titanbot. For an example if the titan says:

<TitanBot>: Your Clan Sux!
<TitanBot>: HAHAHAHAHA
<TitanBot>: Your Clan Sux!

 the string could be set to: Sux!

well that would work but what if they change the way they flooded to :
rejoin (5 times)
say Your Clan Sux! (Twice)
disconnect
change name
repeat

You wouldnt be able to ban someone offline.

[Eric]

Besides, you receive a join event before a talk event.

[UserLoser]

Is the next ops bot evolution something in cooperative banning?  Since an Ops channel can have two ops, if they were able to negotiate which users they were banning it would double the bannable number and banning speed.

I made one that loads 4 Warcraft III clients, or 2 Broodwar clients.  They both interact and it works very well

[Stealth]

Skywing, you're absolutely correct -- however, due to the nature of floodbots, flood protection is not a concern because in order to not get IPbanned the bots must delay a significant amount of time between reconnects; this allows your op bot to recover without having to delay responses. Blizzard has become more stringent in this reconnect delay I'm assuming because of this very problem. Checking that you have recieved the packet's entirety is a good idea -- but you can ban users who have left the channel and are not yet offline, which is the case during the target's first few rejoins. Unless the Battle.net system were to notify you somehow that the target user had gone offline, drawing all the packet data wouldn't have a severe impact either way. (For consistency it's still a good idea, especially if it doesn't delay the client-side operation all that much.) As for these precision benchmarks, could you point me at some resources I could use to implement them?

What I also forgot to mention about EFP, though logical, is that it stores the name of the person who was banned by the system so that each of the rejoins is not counted as an individual ban. Since the bot will not flood banning the floodbots because it attempts only once, the only way to drop it during EFP was to load the channel with, say, 5+ bots or clients within the span of a second or two. The bot would drop trying to ban these usernames, so the cap variable is introduced to make sure that no more than three users are banned within a certain amount of time. The delay is more than adequate to handle floodbots without risk of disconnect.

Grok, I believe what you say is true -- applied to floodbots, it means that one of the bots can focus on attempting to ban the floodbots, and the other can focus on handling the other standard channel moderation functions. I don't think having two clients trying to suppress the floodbot will change the situation.. perhaps I'm wrong.