Perhaps you could implement a function that alerts Blizzard when people violate their agreements. You could log the incident, and send an e-mail letting them know what happened. It would not instantly stop a flood/spam attack but it could lead to cd-key bans and possibly help filter out the bad seeds over time.

Does this sound like a practical idea? I am not too familiar with Blizzards policy on the subject, but I would assume they are just as eager as us to get rid of the flood bots.

[quote author=Tuberload link=board=17;threadid=5108;start=0#msg42752 date=1076049866]
Perhaps you could implement a function that alerts Blizzard when people violate their agreements. You could log the incident, and send an e-mail letting them know what happened. It would not instantly stop a flood/spam attack but it could lead to cd-key bans and possibly help filter out the bad seeds over time.

Does this sound like a practical idea? I am not too familiar with Blizzards policy on the subject, but I would assume they are just as eager as us to get rid of the flood bots.

[/quote]

Nice idea, turn any flood bot into an e-mail spammer... :P

You'll find out whether they choose to ban the flood bot or the e-mail spammer first I suppose ;)

[quote author=Adron link=board=17;threadid=5108;start=0#msg42757 date=1076063240]
[quote author=Tuberload link=board=17;threadid=5108;start=0#msg42752 date=1076049866]
Perhaps you could implement a function that alerts Blizzard when people violate their agreements. You could log the incident, and send an e-mail letting them know what happened. It would not instantly stop a flood/spam attack but it could lead to cd-key bans and possibly help filter out the bad seeds over time.

Does this sound like a practical idea? I am not too familiar with Blizzards policy on the subject, but I would assume they are just as eager as us to get rid of the flood bots.

[/quote]

Nice idea, turn any flood bot into an e-mail spammer... :P

You'll find out whether they choose to ban the flood bot or the e-mail spammer first I suppose ;)
[/quote]

I would assume it only sends a single email for a floodbot :/

I don't think Blizzard particularely cares, though.

if they really cared in the slightest they would just completly change the game prot.ocol or make a minute (probally very hard to find) change

IIRC, the actual bot that sends the email is also in violation of the EULA of B.net.

[quote author=NuLL link=board=17;threadid=5108;start=0#msg42773 date=1076074801]
if they really cared in the slightest they would just completly change the game prot.ocol or make a minute (probally very hard to find) change
[/quote]

They could limit bots in other ways, too, without having to update their game clients. But most of all, they could automaticly detect them and ban their cdkeys (I don't see any other reason that FloodBot#23 would be online unless it was either a winbot or a floodbot, neither of which they should allow). But they don't, so obviously they don't care. Moo.

I've often thought that too. Why would they not void cdkeys logging any account with a multiple number '#'? Like you say, they can't be that bothered about it.

Well, just because you have a # in your name, you dont have to be a bot. People do share accounts...But anything higher than #5 its reasonable to assume its a bot.

I also assume bnet allows 8 connections from 1 ip for people who have LANs.

[quote author=Eternal link=board=17;threadid=5108;start=0#msg42776 date=1076076113]
I've often thought that too. Why would they not void cdkeys logging any account with a multiple number '#'? Like you say, they can't be that bothered about it.
[/quote]

What if you leave your war3 on and go to the LAN cafe or your friends house.

You have to log in on a #2. :(

They could easily gather up thousands of CD-keys which break the ToU and disable them. The problem is, most of the mass CD-keys people own are what they've stolen from someone else. So such a mass ban would result in massive complaints from the original owners of the CD-key.

Future restrictions to Battle.net will make attacks more weaker. Until then, your best option is to let Blizzard do their job while you not worry about it and think of other methods to block them out (e.g., an auto-ignore if short visit).

Spht are there any functions on these forums that show how to auto filter a floodbot or anything? like a 1 second join and leave. How could u implement that?

[quote author=Networks link=board=17;threadid=5108;start=0#msg42809 date=1076091991]
Spht are there any functions on these forums that show how to auto filter a floodbot or anything? like a 1 second join and leave. How could u implement that?
[/quote]

By checking the amount of time since he joined when he leaves, and if it's small enough ignore him completely? It isn't that difficult to do if you know anything about programming.

If Blizzard cared, they could do more to temporarily change the situation. Flooders would adjust their methods. The best Blizzard can hope to do is block methods which are beneficial to bots, but serve no useful function for regular gamers.

That said, it is not practical to write their servers to prevent floodbots, because the design specifications would change the moment they implemented the previous model.

For example, I could create 200 email accounts, 200 random-letter names, use 200 CD-keys, on 500 different internet addresses. Generally, this is how average gamers appear to battle.net -- unique names from all over the world.

How do you combat it? More importantly, is it worth it to spend shareholder dollars on combatting it? Probably not. Floodbotters are only annoying a few people out of millions, and not doing damage to battle.net.

[quote author=Grok link=board=17;threadid=5108;start=0#msg42814 date=1076093991]
How do you combat it? More importantly, is it worth it to spend shareholder dollars on combatting it? Probably not. Floodbotters are only annoying a few people out of millions, and not doing damage to battle.net.
[/quote]

So, the solution to our problem is to ensure that floodbotters annoy a larger share out of the millions, and so become a problem worth spending shareholder dollars combatting? :P

[quote author=Adron link=board=17;threadid=5108;start=0#msg42819 date=1076096240]
[quote author=Grok link=board=17;threadid=5108;start=0#msg42814 date=1076093991]
How do you combat it? More importantly, is it worth it to spend shareholder dollars on combatting it? Probably not. Floodbotters are only annoying a few people out of millions, and not doing damage to battle.net.
[/quote]

So, the solution to our problem is to ensure that floodbotters annoy a larger share out of the millions, and so become a problem worth spending shareholder dollars combatting? :P
[/quote]

If that is what it may take.. perhaps turtle released his floodbot source thinking the exact same thing in hopes blizzard/bnet will do something about it.

Why would releasing the source of a floodbot help bnet?
Im sure they already know how they work, perhaps better than turtle himself...

His intentions for releasing the source of a floodbot was more likely to allow other silly programmers to spawn new versions from his own......

[quote author=Lenny link=board=17;threadid=5108;start=15#msg42826 date=1076101963]
Why would releasing the source of a floodbot help bnet?
[/quote]

Read my previous post on how it might help some people.

Considering battle.net itself is a free service and also that floodbots are no longer common problems to most gamers, floodbots and bots in general are very low on battle.net's priority list. Even when it was an epidemic battle.net made few changes to resolve the issue.

Battle.net will most likely stay the way it is for a very long time. Inevitably, floodbots will die out....I dont believe bringing back floods is the solution.

[quote author=Lenny link=board=17;threadid=5108;start=15#msg42863 date=1076117240]
Considering battle.net itself is a free service and also that floodbots are no longer common problems to most gamers, floodbots and bots in general are very low on battle.net's priority list. Even when it was an epidemic battle.net made few changes to resolve the issue.

Battle.net will most likely stay the way it is for a very long time. Inevitably, floodbots will die out....I dont believe bringing back floods is the solution.
[/quote]

Well.. floodbots were already popular especially with Fleet-'s Titan Flooder out on the loose and was/is still a common problem for many even if its not the majority.

Fleet- is also known for putting backdoors on his bots. Just a warning to people who use Flawed bot.

The best way is to just filter out the floods, as previously discussed. There is no magical way to prevent floodbots from existing totally, unless blizzard took some sort of drastic action (don't count on it). The overall affect if everyone in the channel simply had decent floodbot auto-detect-and-filter capabilities would be that floodbots would seemingly disappear.

As far as how to code such a filtering system, you would do something along the lines of (building on what iago was talking about of course):

Psuedo Code:

[code]
OnJoinHandler()
{

; * * * CHECK FOR REJOIN SPEED * * *
IF (CurrentTime - User.LastTimeJoined) > threshold ; Compare the current time with the user's last join time
{

User.JoinViolationCount = User.JoinViolationCount + 1 ; If the join is too fast, add a violation to the counter

; * * * CHECK FOR PAST VIOLATIONS OF REJOIN SPEED THRESHOLD * * *

IF (User.JoinViolationCount > violationthreshold)       
{
AddFilterByUser(User)

; If they have rejoined too fast the set amount of times (threshold), filter them...
; You'll need some sort of linked-list or data-structure to hold all the
; filtered users/msgs. Filtering in general is a good feature to have in your bot, so you
; might as well kill two birds with one stone and create a robust filtering system.
}

}

ELSE
{

; * * * COOLDOWN * * *
[insert cooldown code here]

; This will ensure that if they have 1 violation.. it won't carry over even if they rejoin
; quickly like 2 hours later. You can simply set JoinViolationCount back to 0,
; But it's recommended that you have some sort of more intelligent way to slowly de-increment
; the violation counter (To prevent situations such as the floodbot taking a 4 second break or something)
}

}
[/code]


Note that you may want to also check for cummulative rejoin spam: such as the situation when the floodbot waits to rejoin every 5 seconds instead of rapidly. So for instance you could do a check for say 5 rejoins max every minute or something. Anyways, that's (believe it or not) the most simple & affective way to counter floodbots (Atleast AFAIK).

Hope this helps some people out. (I apologize for how crappily the psuedo-code's spacing turned out)

Or you could do what Skywing has suggested in the past, and filter out a packet with both the join and leave events clumped in it.

That's exactly what I'm doing? Notice "OnJoinHandler()" indicating it runs the function when somebody joins the channel (receives a join packet).

Looks to me like you are timing them.

[quote author=Soul Taker link=board=17;threadid=5108;start=15#msg43821 date=1076572148]
Looks to me like you are timing them.[/quote]

Timing them is a better approach. Many floodbots that I've filtered were not instantaneous rejoins, but rather the events arrived between 5 and 500 milliseconds apart. A properly tuned filter neutralizes these floodbots, despite their sluggish motion. While they may be bannable when moving that slow, it's really not worth the effort.

Is there anything constant when u logon b.net that could show that it is the same person everytime? Accounts and Cdkeys are constant since you change them but any sort of constant signatrue that one may have. If so maybe you can ban anyone with that constant.

Also how could you ban a user who has a Join and leave packet clumped together in VB6?

[quote author=Networks link=board=17;threadid=5108;start=15#msg43855 date=1076610762]
Is there anything constant when u logon b.net that could show that it is the same person everytime? Accounts and Cdkeys are constant since you change them but any sort of constant signatrue that one may have. If so maybe you can ban anyone with that constant.

Also how could you ban a user who has a Join and leave packet clumped together in VB6?[/quote]

As far as I know, the server will not show you any of the truly identifying marks (such as CD key magic number or client IP address). The closest you can get is taking advantage of squelches being by IP. As we have explained many times before, you cannot ban someone if they get logged off the server before you send out your command. There was a huge thread about this months ago.

If someone joins the channel, says something, then leaves the channel, I would prefer to never have seen any of the three events.

By delaying the display of any user events until the user has met the threshold minimum time in channel, this can be effective filtering of both floodbots and spambots.

I'd also qualify this by saying take an integral of the count of filtering actions over time, and if it value is low, you could lower the minimum time. As the integral value goes up, you can raise the minimum delay. This would give you dynamic filtering that would adjust for actual flooding situations, as compared to spamming situations. The latter of which you'd want to know about so you could manually ban someone who spamming but not flooding.

what was battle.net's reasoning for getting rid of acct #'s?

[quote author=Soul Taker link=board=17;threadid=5108;start=15#msg43821 date=1076572148]
Looks to me like you are timing them.
[/quote]

Oh sorry, I mis-read your post. Anyways, what you suggested is totally unreliable if the floodbot has any delaying mechanism at all. I actually like Grok's suggestion, that's a rather good idea if you want the best results...

wait u said squelching is by there IP so if we are able to squelch the flood bot in time will it all together filter it or is a user who logs on to b.net with the ip squelched from before not squelched by the user who squelched them...lol

And can anyone please respond to my post about clumped join/leave packets above.

[quote author=Networks link=board=17;threadid=5108;start=15#msg43904 date=1076628389]
wait u said squelching is by there IP so if we are able to squelch the flood bot in time will it all together filter it or is a user who logs on to b.net with the ip squelched from before not squelched by the user who squelched them...lol

And can anyone please respond to my post about clumped join/leave packets above.
[/quote]

Is it just me or does everything you say not make sense ?

ill TRY and answer your question anyways , once you squelch a user he is then squelched on every account he logs on to coming from that IP , however masking yourself with a proxy will avoid this.

Also asking for people to respond to your question will undoubtable make people inturn avoid it and make you look extremly annoying.

even if he logs back on will he still be squelched?

and if masked by a proxy couldn't that IP just squelched if the bot is able thus filitring floods w/ ease.

[quote author=Networks link=board=17;threadid=5108;start=30#msg43912 date=1076629708]
even if he logs back on will he still be squelched?

and if masked by a proxy couldn't that IP just squelched if the bot is able thus filitring floods w/ ease.
[/quote]
Yes, but you can't squelch an account when it's offline.

Yes if you have squelched him and he logs off then on again he will still be squelched (even with a new name) , up until YOU log off.

think of it as , not squelching a SINGLE user but more as squelching ALL users with that certain IP.


<edit>Sorry posted same time</edit>

[quote author=Networks link=board=17;threadid=5108;start=15#msg43904 date=1076628389]
wait u said squelching is by there IP so if we are able to squelch the flood bot in time will it all together filter it or is a user who logs on to b.net with the ip squelched from before not squelched by the user who squelched them...lol

And can anyone please respond to my post about clumped join/leave packets above.
[/quote]

Most bots have their data arrival function able to separate clumpted packets....
It's not very difficult, considering bnet gives you the length of the packet.

Two steps on preventing any kind of bots:

1) Get a clan channel
2) Type '/clan private'

[quote author=Soul Taker link=board=17;threadid=5108;start=30#msg43914 date=1076629884]
[quote author=Networks link=board=17;threadid=5108;start=30#msg43912 date=1076629708]
even if he logs back on will he still be squelched?

and if masked by a proxy couldn't that IP just squelched if the bot is able thus filitring floods w/ ease.
[/quote]
Yes, but you can't squelch an account when it's offline.
[/quote]

Can always code a local squelch.

[quote author=UserLoser. link=board=17;threadid=5108;start=30#msg44034 date=1076691726]
Two steps on preventing any kind of bots:

1) Get a clan channel
2) Type '/clan private'
[/quote]

Worthless post of the day.

[quote author=Grok link=board=17;threadid=5108;start=30#msg44046 date=1076693979]
[quote author=UserLoser. link=board=17;threadid=5108;start=30#msg44034 date=1076691726]
Two steps on preventing any kind of bots:

1) Get a clan channel
2) Type '/clan private'
[/quote]

Worthless post of the day.
[/quote]

Your momma

It's true though...even though my client has delayed ~425ms for each user on joins for a couple months now

Well then squelching is the best way to go I suppose rather than having to ban 90+ to finally kill all the guys keys and accounts...

[quote author=Networks link=board=17;threadid=5108;start=30#msg44061 date=1076698024]Well then squelching is the best way to go I suppose rather than having to ban 90+ to finally kill all the guys keys and accounts...[/quote]

No, filtering them automatically by analysis of their behavior is much better than squelching. It avoids bloating your list if they morph names rapidly, and it's much more reliable than server-side squelches.

wouldnt there be ways to make floodbots leave before u got a chance to ban them? no matter the way you came about catching them.. (squelch, behavior, etc..)

Hamtaro,
If the bot filters it then there is nothing the floodbot can do. The filter wouldnt stop it from flooding the channel but all chat events would be sent to the bot/client and it is up to it to do something with it.

Edited: Typos

I think that we've all gotten a little dumber by reading these posts.

Conclusion:
- Filter the floodbots by delaying chat input, ignoring multiple EID_TALK's, EID_EMOTE's, EID_JOIN's and EID_LEAVE's that occur in a single datastream or filter any EID_TALK's, EID_EMOTE's, EID_JOIN's and EID_LEAVE's that take place in under a second of the user joining.
- Squelch the user flooding (providing he isn't using proxies)
- A clan channel and /clan private

The following require two things (considering the floodbot is working at proper speed): A super-computer and an unshared OC-13 line.

- Squelch the floodbots
- Ban the floodbots

[quote author=LoRd[nK] link=board=17;threadid=5108;start=30#msg44180 date=1076731773]
I think that we've all gotten a little dumber by reading these posts.

Conclusion:
- Filter the floodbots by delaying chat input, ignoring multiple EID_TALK's, EID_EMOTE's, EID_JOIN's and EID_LEAVE's that occur in a single datastream or filter any EID_TALK's, EID_EMOTE's, EID_JOIN's and EID_LEAVE's that take place in under a second of the user joining.
- Squelch the user flooding (providing he isn't using proxies)
- A clan channel and /clan private

The following require two things (considering the floodbot is working at proper speed): A super-computer and an unshared OC-13 line.

- Squelch the floodbots
- Ban the floodbots
[/quote]

Personally, to me the most practical solution would be to ignore clumpted EID_TALK's, EID_EMOTE's, EID_JOIN's and EID_LEAVE rather than delaying the chat input to the user.

You wouldn't have to delay the chat input that much... I think most programming languages out their could execute a simple filter relatively fast.

Wouldn't the speed depend on how fast the floodbot actually is?

Would you want to only filter fast floods or both slow and fast?

A packet clump from a flood consists of about um. about 9 packets. or so and the amount of buffer that comes in is always limited to about 1024 bytes. My thought on this is.. Extract the username from each packet (do not process packet yet) and store it temporarily in a variable somewhere .. as you extract a username from each packet from the clump you check against the list of already present usernames in the list. If any matches are found. Flag the packets/name (or remove the packets from buffer) .. So when you actually do process the packets it won't process any packets that has a username that is flagged as showing up more then once in the clump. It takes more work and processing but if this is for a chat bot.. it doubt it would matter.

And..

To help reduce Error in channel listing.. you shoud setup the bot to refresh the channel list by idling "/unignore (theNameYouAreUsing)" .. that should give you a list of inchannel users to compare it against the current list..

[quote author=o.OV link=board=17;threadid=5108;start=45#msg44232 date=1076758181]
A packet clump from a flood consists of about um. about 9 packets. or so and the amount of buffer that comes in is always limited to about 1024 bytes. My thought on this is.. Extract the username from each packet (do not process packet yet) and store it temporarily in a variable somewhere .. as you extract a username from each packet from the clump you check against the list of already present usernames in the list. If any matches are found. Flag the packet/name (or remove the packet from buffer) .. So when you actually do process the packets it won't process any packets that has a username that is flagged as showing up more then once in the clump. It takes more work and processing but if this is for a chat bot.. it doubt it would matter.
[/quote]
I'd make it depend on the event, since I'd think in certain situations people could certainly send multiple events in one packet, such as someone joining a channel and having their flags changed, and a statstring update perhaps if it's laggy.

[quote author=Soul Taker link=board=17;threadid=5108;start=45#msg44233 date=1076758419]
[quote author=o.OV link=board=17;threadid=5108;start=45#msg44232 date=1076758181]
A packet clump from a flood consists of about um. about 9 packets. or so and the amount of buffer that comes in is always limited to about 1024 bytes. My thought on this is.. Extract the username from each packet (do not process packet yet) and store it temporarily in a variable somewhere .. as you extract a username from each packet from the clump you check against the list of already present usernames in the list. If any matches are found. Flag the packet/name (or remove the packet from buffer) .. So when you actually do process the packets it won't process any packets that has a username that is flagged as showing up more then once in the clump. It takes more work and processing but if this is for a chat bot.. it doubt it would matter.
[/quote]
I'd make it depend on the event, since I'd think in certain situations people could certainly send multiple events in one packet, such as someone joining a channel and having their flags changed, and a statstring update perhaps if it's laggy.
[/quote]

You are right. It should only check Join Leave Talk and Emote.
Grabbing the channel event is certainly not hard. its just a checking a single byte.
Of course.. People can be laggy and it would filter them out if they sent messages too fast.. but.. sacrifices have to be made.
But then again, they might be a bot sitting in channel spamming or something.. So it could be a good thing.
Slap this idea together with the one I provided above and you have got yourself a so called filter.

You could just support the SVP (short visit protect) method which Skywing's BinaryChat and some other clients use.

The logic behind this is for join/leave/talk/flagschange/emote, check if the user is in channel, if so then process event normally. If they're not in channel and it's a leave event, delete the user's chat event queue. If it's not a leave event, push the chat event into the user's chat event queue. If the user's queue is "old enough," (we use a little over 1 second) then process all events in the queue and delete the queue.

This method has proved to work very well.

[quote author=o.OV link=board=17;threadid=5108;start=45#msg44232 date=1076758181]
A packet clump from a flood consists of about um. about 9 packets. or so and the amount of buffer that comes in is always limited to about 1024 bytes.[/quote]

Without regard to the other problems in your idea, this sounds much more like a client limitation than something inherent in the server. The server can potentially send you far more data very rapidly. It's your TCP receipt implementation that's capping it at one kilobyte.

[quote author=o.OV link=board=17;threadid=5108;start=45#msg44232 date=1076758181]To help reduce Error in channel listing.. you shoud setup the bot to refresh the channel list by idling "/unignore (theNameYouAreUsing)" .. that should give you a list of inchannel users to compare it against the current list..[/quote]

Unless the filter is extremely braindamaged and inconsistent about when and how it filters, there will be no desynchonization of the channel list.

I would use the in-same-message idea to filter out users that could not possibly be banned from an operator bot, and the delay-events idea for a chat bot to block out as much spam as possible, even if users may be banned as a result.

Something Grok said made me think: ANYBODY who joins the channel, talks, and leaves within about 10 seconds isn't worth my time, regardless if he's a floodbot or legit :)

Sorry Kp it was an assumption.
When I use to packet log data coming from winsock controls
during a flood.
It was always seperated into limited chunks
of data consisted of a number of packets.
And that was the first time I have encountered Packets
coming in incomplete pieces.

[quote]
Without regard to the other problems in your idea, this sounds much more like a client limitation than something inherent in the server. The server can potentially send you far more data very rapidly. It's your TCP receipt implementation that's capping it at one kilobyte.
[/quote]

A single flood is about 500 to 600 in length.
A person who is flooding usually isn't running that many floodbots
and I say again its about 1024 because I never noticed
any particularly large chunks of data that might be over 1024 bytes.
That is why I made this assumption for winsock controls.

This deduction was made back when floodbots were still
able to pull off over 50 rejoins before getting ipbanned.

[quote]
Unless the filter is extremely braindamaged and inconsistent about when and how it filters, there will be no desynchonization of the channel list.
[/quote]

The idea was to begin evaluation of the packets as soon as the clump arrives.
So that you wouldn't have any noticeable delay of incoming data
when waiting it out even if for just 500 milliseconds.
What I was worried about is a bot that joins channel and idles for a while
and decides to flood off or a bot that comes in flooding but sits.
It would drop the packet that says user has left/joined the channel.
But ok.. Fine.
It should drop all BUT the last (join/leave) packet of the flagged username.