Eggdev: The state of eggdrop1.9
list at semidefinite.de
Sun May 13 18:52:01 CST 2007
Derek Kuliñski wrote:
> I don't think this should be a reason to cripple the botnet protocol.
> This is unavoidable, there are a lot of scripts (usually involving
> timers) that can kill bot uppon receiving text with "[die]" string.
Ah, thanks for reminding me, why I hate Tcl. :)
> Let make botnet protocol pass values as they are, and add special
> functions (it would also be good to provide them from scripting
> languages) that would sanitize the string e.g. special function
> ircsanitize that would remove all dangerous characters that shouldn't
> be sent to an IRC server.
> BTW: I belive putserv/putquick/puthelp are already trimming \n.
> putdccraw doesn't but that's why it's called "raw" :)
I still think a text that has no other meaning than to be read by a
human shouldn't contain binary data. What would be the point?
Ignoring that, good argument, let's just do it that way. If someone
doesn't like it he's free to write his own botnet module. ;)
Ok, how about this:
Messages in the data stream are separated as defined in
This means the sockbuf used for the connection does not use the linebuf
filter but a to-be-written netstring filter.
After a connection has been fully established (including login and
password exchange), messages between bots have the following format:
message := [:<src>] <command> [<dst>] [:<parameters>]
src := [<id>@]<bot>
Looks kind of like the IRC protocol, but whoever designed that did a
good job with that, so we might as well borrow it.
src the entity the message came from, either a bot, identified by its
name, or a user, identified by his id and the bot he's on in the form
"id at bot". No need to bother with the nick, every bot on the net should
know that. id might be decimal or base64, not sure about that at this
point. This part may be omitted if the source is the bot on the other
side of the connection.
command is the actual botnet command, kinda like with the current
botnet, just a one or two letter string.
dst is the entity the message is for. Just like src, might be a
partymember or a bot but also a partyline channel. This part may be
omitted if it's a broadcast and therefor does not have a specific
parameters is just whatever comes after that, like a quit message or
whatever. May be omitted if there's nothing more to be said.
That's it. Should hopefully be compact enough to safe some bandwidth and
simple enough to allow efficient parsing.
The actual login might look something like it does in 1.6, can't see
anything wrong with that. But some kind of pre-auth handshake might be
bot1 is connecting to bot2:
bot1: OPT <option1> <option2>
bot2: OPT <option1> <option3> (enables option1 at this point)
bot1: (enables option1 at this point) <whatever comes next, like login>
This would allow the bots to use some sockbuf filters that might or
might not be available, like encryption, compression and so on.
bot1: OPT SSL BZIP2 GZIP
bot2: OPT SSL GZIP
Both bots will now use a SSL and a GZIP filter because that's what both
of them support.
Well, that's all for now. Any thoughts on that?
More information about the Eggdev