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?

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 author=Gangz link=board=17;threadid=3231;start=0#msg25469 date=1067034529]
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?
[/quote]

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.

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.

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.

Also, making the chatbot you use ignore flooders so you don't ever see them is the easiest way.

[quote author=Freeware link=board=17;threadid=3231;start=0#msg25483 date=1067039084]
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.
[/quote]

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...

[quote author=Gangz link=board=17;threadid=3231;start=0#msg25469 date=1067034529]
Well as most of you have know Fleet- came out with another pussy flood that tops his last one[/quote]

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

[quote author=Freeware link=board=17;threadid=3231;start=0#msg25472 date=1067035699]
stealth bot just isnt fast enough to catch a titan[/quote]

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

[quote author=Freeware link=board=17;threadid=3231;start=0#msg25472 date=1067035699]
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.[/quote]

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

[quote author=Freeware link=board=17;threadid=3231;start=0#msg25472 date=1067035699]
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.[/quote]

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 author=Freeware link=board=17;threadid=3231;start=0#msg25472 date=1067035699]
3. Dont make exentsive commands that take forever to search through, in this case a simple ban / unban / ipban might do.[/quote]

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 author=Freeware link=board=17;threadid=3231;start=0#msg25472 date=1067035699]
4. If you want the FASTEST connection, use winsock.dll instead of a winsock control/csb. It is proven to be much faster.[/quote]

Makes sense.

[quote author=Freeware link=board=17;threadid=3231;start=0#msg25472 date=1067035699]
5. Make sure you have cable/dsl/or faster (obvious but true)[/quote]

That may help in some cases.

[quote author=Freeware link=board=17;threadid=3231;start=0#msg25472 date=1067035699]
9. Switch to C++, its faster than Visual Basic[/quote]

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

+1 to Spht for being so critical ;D

[quote author=Skywing link=board=17;threadid=3231;start=0#msg25479 date=1067037269]
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.
[/quote]

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.

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.

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

[quote author=Simi link=board=17;threadid=3231;start=0#msg25532 date=1067051863]
About titan... I've heard of it many times, what is the secret to this floodbot and who created it?
[/quote]

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

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

[quote author=Gangz link=board=17;threadid=3231;start=0#msg25541 date=1067058910]
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
[/quote]
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.

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

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.

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

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.

[quote author=Skywing link=board=17;threadid=3231;start=15#msg25555 date=1067063636]
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.
[/quote]

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

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.

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.

[quote author=Grok link=board=17;threadid=3231;start=15#msg25565 date=1067085068]
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.
[/quote]

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. :P

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.

does that link not work or is it just me?

[quote author=Grok link=board=17;threadid=3231;start=15#msg25565 date=1067085068]
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.
[/quote]

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

[quote author=Grok link=board=17;threadid=3231;start=15#msg25565 date=1067085068]
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.
[/quote]

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. ;D

[quote author=Freeware link=board=17;threadid=3231;start=15#msg25618 date=1067098550]
[quote author=Grok link=board=17;threadid=3231;start=15#msg25565 date=1067085068]
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.
[/quote]

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!
[/quote]

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.

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

[quote author=Grok link=board=17;threadid=3231;start=15#msg25565 date=1067085068]
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.
[/quote]

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

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.

[quote author=___/\___ link=board=17;threadid=3231;start=15#msg25623 date=1067099183]
[quote author=Freeware link=board=17;threadid=3231;start=15#msg25618 date=1067098550]
[quote author=Grok link=board=17;threadid=3231;start=15#msg25565 date=1067085068]
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.
[/quote]

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!
[/quote]

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.
[/quote]

Thats why it waits a little and sends /ban to the NEXT username that they would load.

[quote author=Freeware link=board=17;threadid=3231;start=30#msg25658 date=1067105077]
[quote author=___/\___ link=board=17;threadid=3231;start=15#msg25623 date=1067099183]
[quote author=Freeware link=board=17;threadid=3231;start=15#msg25618 date=1067098550]
[quote author=Grok link=board=17;threadid=3231;start=15#msg25565 date=1067085068]
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.
[/quote]

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!
[/quote]

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.
[/quote]

Thats why it waits a little and sends /ban to the NEXT username that they would load.
[/quote]
Not everyone uses titans, so it would change its name to something random.

But I was talking about Titans...

Flood protection is indeed an issue. Speaking from experience in Op [vL]/Clan [vL], which have been some of the most floodbotted channels on Battle.net, many attacks have been fast enough that without flood protection the operator bot would have flooded out and all bans would have been lost.

This is probably accomplished by using large quantities of SOCKS proxies or something similar, but it is most definitely something you need to worry about.

Skywing is right withought any anti-flood of some sort any floodbot is useless. But i suppose if it isnt effencient then no use trieng to ban the impossible.

[quote author=Grok link=board=17;threadid=3231;start=15#msg25565 date=1067085068]
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.
[/quote]
I pondered this for my bot (zeroone) but i came to the conclusion that it would really only help against mass load attacks. and while thats handy, denial showed me that a massload attack can't really be banned due to max banlist size.

But it would help against slow massload attacks that do not exceed the max ban limit.

[quote author=Grok link=board=17;threadid=3231;start=30#msg25862 date=1067176830]
But it would help against slow massload attacks that do not exceed the max ban limit.
[/quote]

Yes it would. And, considering how most people are fools and don't know ANYTHING, this is the type of massload that you would have to deal with most often.

Maxban is 500 bans per key if i recall right it may be 250 per key.

It's an approx. amount of about 80 - 100 per op.

thats incorrect i have banned Vietphos 200 bots with single op.

The ban (and squelch) limits have been 80 for years and years.

[quote author=Skywing link=board=17;threadid=3231;start=30#msg25998 date=1067216290]
The ban (and squelch) limits have been 80 for years and years.
[/quote]

Incidentally, although it seems you can exceed the limit, what actually happens is that when you ban the 81st person, the 1st person you banned is no longer banned. Or at least that's how I recall it working.

[quote author=Zakath link=board=17;threadid=3231;start=30#msg26090 date=1067269118]
[quote author=Skywing link=board=17;threadid=3231;start=30#msg25998 date=1067216290]
The ban (and squelch) limits have been 80 for years and years.
[/quote]

Incidentally, although it seems you can exceed the limit, what actually happens is that when you ban the 81st person, the 1st person you banned is no longer banned. Or at least that's how I recall it working.
[/quote]

It is FIFO.

FIFO?

[quote author=UserLoser link=board=17;threadid=3231;start=30#msg26147 date=1067298040]
FIFO?
[/quote]

First in, first out.

hrmm new one on me never heard that it begins to unban the ones you first banned

What you could do is dualop and have the secondary op not use flood protection.

[quote author=St0rm.iD link=board=17;threadid=3231;start=45#msg26164 date=1067302283]
What you could do is dualop and have the secondary op not use flood protection.
[/quote]
Perhaps you should verify whether bans are per-operator or per-channel first.

Hmm, after reading this I couldn't resist but signing up.

First off I would like to say I never stole any sources from any one. I however did take a few snippets on the earlier versions of Titan. I got my snippets from lord zeros original floodbot. I took the login sequence, the pbuffer class(I understand some one else in vL wrote this), and the create game sub, every thing else was work of my own.

Sitting in channels is not a "flaw" of the bot, it is suppose to do that.

As far as what turtle said, is pretty much completely false. 1) thats not my source, it is but it isn't, it has been modified so much you might as well not even consider it mine. 2) I had no problem with proxy support, I never chose to look into it, I spent about 10 minutes of research and I got proxy support working.

Also I'll take this quote from turtle.. "There is already a bot that does. It is most effective against a Mass Load." Its funny that he says this because..that bot is my bot, Flawed.
As far as the backdoor rumors they are completely false. Where those started from is that a private copy was leaked so I scrapped up a new private copy with a few new features, and I did indeed backdoor this private copy. I also embedded names in it so I could find out who leaked it. Well I found out who leaked it alright, and I found a bunch of people using it. I warned every single person to close the bot and that it was a private bot befor I stole their keys and often wounded their clan the best I could. I'm not an ass, but I don't appreciate people stealing stuff from me.

Also, I did not steal his source in any manner, he did give it to me to look at but his coding was so sloppy I couldn't make heads or tails of it so I deleted it, and he very well knows this.

Continueing on, he did not "cut ties" with me, he was exiled from our channel for being an ass, and acting like he knew every thing. I really dont like people like that, he never was ahead of me, I just straight up didn't give a fuck. Okay..I dont know where to go from here on this..?


Well as a final note I would like to say I do not make flood bots to terrorize people, and be evil ect ect. But more or less to kick the shit out of stupid clans which talk shit and act badass when they are nothing. That is why I offerred channel protection on certain clans, if I knew they were not those types of clans. As far as stealth / stealthbot, I have NEVER taken a single piece of code from his bot, I respect Stealth for his work, he has helped me understand how some things go tick and tock and what not, and I would not be an ass and "steal" from him. You will even notice his name will be in the main credits of the new flawed bot, which is quite an improvment from 1.17b.

If you guys want to look down on some one, and blame some one for floods, if anything you should blame turtle, he was the moron which was stupid enough to release a strong floodbot source to the pub, and let newbs make numerous versions of it, and claim it as their own. Despite that, Titan 1.06 is a nice new version, tops his flood bot in options, just as fast if not faster. I have seen his bot get banned by a 60ms ping, and that same bot couldnt ban mine (im a 56k).

If your wondering why I make a floodbot, than a counter floodbot..I really don't know how to answer this..for the challenge I suppose?

They stole your bot, you warned them to stop using it, they ignored you, you stole their keys as payment. Sounds like a fair and reasonable penalty.

Hrmm.. i would like to say that titan may not be stolen but the idea for it was first designed by lord]ZeR0[, from what i know so you may have not stolen the coding but the idea yes. Then again we all have stolen ideas from other bots and people [some people call it borrowing] the only reason we are here making bots is because we learned from each other as i am sure when the first bnet bot came out it did not need hashes and sent and recived alot less packets but over the years bnet evolved into more advanced coding in which "WE" as the people who use it worked together to make battle.net better but as in are history we also destoryed battle.net in terms of flood bots mass loading etc. i do not condone the use of them. I myself have used a flood bot and i have seen what the flood bot has done to battle.net.

On the stealing of code i dont condone stealing the hole bot but learning from source codes is a good idea. I myself am not that good of a programmer and i learned everything i know from friends and source codes.

I do not belive that any bot is stolen because most bots do the same thing at the same speed and rate. The only reason there are so many bots out there is because people want fame also some like to back door which i do not condone either.

On the banning of the new titan only by stealth bot 2.1 it may because fleet- has learned off of stealth and his coding therefore his bot connects and does send packets ect. the same way stealth bot does which in turns allows it to ban it. I also belive as long as you edit someones source and dont release it for public use its not really stealing a bot its editing to your personalty and making sure your version is not back doored.

I have heard rumors that BLNS logs username, passwords, and cdkeys. but i myself do not care but for those that do you should release the warcraft 3 hash scripts for the public because not everyone is good at programming [Note i cant even get a packet logger to work].

[quote]On the stealing of code i dont condone stealing the hole bot but learning from source codes is a good idea. I myself am not that good of a programmer and i learned everything i know from friends and source codes.
[/quote]

There is a significant difference between "learning" and "copy-pasting".

[quote]
I have heard rumors that BLNS logs username, passwords, and cdkeys. but i myself do not care but for those that do you should release the warcraft 3 hash scripts for the public because not everyone is good at programming [Note i cant even get a packet logger to work].
[/quote]

#1. Get over it, and get over it now. BNLS does not steal information. Skywing and Yoni don't have any reason to steal your accounts, cdkeys, and the like. Furthermore, if you don't like it, DON'T USE IT.

#2. Your arguments aren't coherent. First you say BNLS steals information, then you say that as a result of that and because "not everyone is good at programming" Skywing should release his W3 hashing code publicly. I don't understand: Just what entitles everybody to have the fruits of Skywing's labor, especially people who aren't good at programming? There are thousands of career possibilities and things to do with one's time -- and people who aren't willing to work towards their end goal of being able to program well shouldn't really be programming. Skywing and Yoni were able to reverse-engineer the Warcraft III login system, they have given it to the public through the BNLS service. If you want to log in on W3 without BNLS, find yourself a disassembler and figure it out. BNLS performs VERY well; it's efficient, free, and rarely unavailable -- what more can you ask for?

But that's just my two cents.

On a side note, this thread is way off-topic.

-Michael-: work on your grammar. Your post is a serious nuisance to read due to run-on sentences.

[quote author=-MichaeL- link=board=17;threadid=3231;start=45#msg33649 date=1070569386]I have heard rumors that BLNS logs username, passwords, and cdkeys. but i myself do not care but for those that do you should release the warcraft 3 hash scripts for the public because not everyone is good at programming [Note i cant even get a packet logger to work].[/quote]

I'm assuming you mean BNLS here. To my knowledge, only Skywing and Yoni have actually developed the capability to do warcraft III logon procedures. Therefore, it is not the case that there exists someone who is able to release the warcraft III logon data and that the same someone is interested in doing so.

Lord zero is a flamer anyways. He wrote a new flood bot which can drop every type of bot there is, except a flawed, a zds may live through it too. He got bent when I told him he wouldn't suceed in dropping a flawed bot, then when he attempted to, and failed he got even more pissed and ran his mouth ect ect. Anyways I'm just telling every one this because you should set up your bots to some how evade this from dropping them. His method his quite barbaric, all he does is a bunch of mass rejoins real fast. The reason it wont drop a flawed is because it has virtually no gui! So I would set up your bots that if it recieves so much info in so much time it should at least ignore some client / lag icon reading.

[quote author=Fleet- link=board=17;threadid=3231;start=45#msg33699 date=1070580936]
Lord zero is a flamer anyways. He wrote a new flood bot which can drop every type of bot there is, except a flawed, a zds may live through it too. [/quote]
Yet for some reason even "Topaz Chat" survives with only minor lag.

"Lord zero is a flamer anyways. He wrote a new flood bot"

YOU are a flamer anyways. You wrote that piece of garbage named titan so that everybody can be a lamer and flood people without being banned.

I like people who make fun of other people that make better products then them.

BTW, your flawed bot sucks, couldn't ban a titan on my connection average 15/16 ms. Even on T3 it couldn't ban (Wireless T3 .. might have been a bit slow ><). How you can say it can pwn mass loads is funny .. because stealthbot can pwn massloads too .. and even better! :)

Conclusion:

[quote author=Skywing link=board=17;threadid=3231;start=0#msg25479 date=1067037269]
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.
[/quote]