Valhalla Legends Archive

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 from: Lenny on February 06, 2004, 03:12 PM
Why would releasing the source of a floodbot help bnet?  

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 from: Lenny on February 06, 2004, 07:27 PM
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.

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:


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)
}

}



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 from: Soul Taker on February 12, 2004, 01:49 AM
Looks to me like you are timing them.

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 from: Networks on February 12, 2004, 12:32 PM
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?

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 from: Soul Taker on February 12, 2004, 01:49 AM
Looks to me like you are timing them.

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.