/[cvs]/eggdrop1.9/modules/oldbotnet/PROTOCOL
ViewVC logotype

Contents of /eggdrop1.9/modules/oldbotnet/PROTOCOL

Parent Directory Parent Directory | Revision Log Revision Log | View Revision Graph Revision Graph


Revision 1.2 - (show annotations) (download)
Sun Jun 20 21:33:28 2004 UTC (15 years, 4 months ago) by wingman
Branch: MAIN
CVS Tags: HEAD
Changes since 1.1: +3 -3 lines
* 1.7 => 1.9 change (though not all occurrances replaced. Old modules,
  ChangeLogs, etc were kept.)

1 1.6 BOTNET PROTOCOL
2 (the parts we care about)
3
4 Table of Contents
5
6 1. Vital notes
7 2. Connecting to an obot
8 3. Maintaining a connection
9 4. Channel commands
10
11 1. Vital notes
12
13 I use the term 'obot' to refer to a 1.6 bot that we are linking with.
14
15 Whenever I use the term 'base64' I am referring to eggdrop's own, nonstandard
16 base64. Take a look at botmsg.c for the original code.
17
18 Honestly, the only confusing part of the botnet protocol is the connection
19 process. The codepath in dcc.c is just terrible. The rest of the stuff you
20 can easily figure out for yourself by looking at botmsg.c and botcmd.c.
21
22 The other important note is obots are compiled with NO_OLD_BOTNET undefined,
23 in other words, they *do* recognize the old botnet protocol. This means that
24 the long forms of commands (e.g. ping instead of pi) will work when you send
25 them. However, if you connect to the obot and send a version command indicating
26 that your bot's version is > NEAT_BOTNET (currently 1029900), the obot will
27 only SEND you the short version. You will never get a "join" command from a 1.6
28 bot, only a "j" command. Since 1.9's version is 1090000 or higher, this
29 document only examines the new botnet protocol. The syntax has changed! So in
30 the "j/join command" section, the "join" part is only there for human reference
31 not as part of the protocol. The actual syntax of the "join" is different from
32 the "j" command in this document.
33
34
35
36
37
38
39
40 2. Connecting to an obot.
41
42 2.1 Username/password
43
44 Upon connection, the obot will print out its banner and prompt us for a
45 username. We send it our bot's name. Now the obot realizes we are a bot, not
46 a user, and if we have a password set it prompts us with the passreq command
47 (an md5 hash of our password and some other stuff). We ignore it and send our
48 password in plain text.
49
50 If a password is not set, the obot doesn't prompt us for one, it lets us log
51 in immediately.
52
53 2.2 h/handshake command
54
55 If a password is not set, the obot will send us this handshake command. The
56 only argument is a randomly generated string that will serve as our password
57 in the future. So we save it in the obot's user record for next time we
58 connect.
59
60 2.3 *hello! command
61
62 Once we log in, the obot will send us "*hello!" to which we are supposed to
63 reply "version numericver handlen stringver <network>". However, since 1.9
64 does not have a fixed handlen, we do not send our version reply until we
65 receive the obot's version.
66
67 2.4 version command
68
69 So, right after the obot sends "*hello!", it sends the version command talked
70 about above. An example is:
71
72 version 1061603 32 eggdrop v1.6.16+somepatch <my.network>
73
74 We parse it a little bit to extract the handlen, and then we reply
75 with our own version information:
76
77 version 1090000 32 eggdrop v1.9 <alrighty.then>
78
79 2.5 tb/thisbot command
80
81 After we send our version reply, the obot should send us the thisbot command.
82 The only parameter is the obot's name. It is a security measure to ensure that
83 the bot we just connected to is the bot we really did want to connect to.
84 Example:
85
86 tb obot
87
88 2.6 j/join command
89
90 The next thing the obot does is give us a list of all the users logged onto it.
91 It does this via the join command. Basically it sends us a join command for
92 each user, specifying the originating bot of the user and the channel he's on.
93 The only difference between this and a normal join is that the obot's name is
94 prefixed with "!". The format for such a message is:
95
96 j !botname user chan# (icon)sock user@host
97
98 An example would be:
99
100 j !obot stdarg A *I dragon@localhost
101
102 As you can see, (icon) doesn't really have parentheses around it. They are only
103 there to separate it from sock, since there isn't any whitespace in the actual
104 message. The icon given is the same as what appears on .who output, e.g.
105 * = owner, + \ master, etc.
106
107 Now is where we start to get into some really annoying stuff! In the 1.6 botnet
108 protocol, integers are encoded in a nonstandard base64 format. That is why the
109 "sock" parameter, which is an integer uniquely identifying the partyline
110 connection on the obot, is sent as "I" instead of "8" in the example. The sock
111 parameter is important since several other commands use it instead of the
112 username. The chan#, normally 0 for the global partyline, is sent as A.
113
114 2.7 i/idle command
115
116 One such command is the idle command. The format is:
117
118 i botname sock idletime awaymsg
119
120 An example would be:
121
122 i obot I BN
123
124 Once again, the sock and idletime parameters, normally integers, are encoded.
125 As you can see, the sock I in this command is the same as the sock I in the
126 last join command example. This is no coincidence. Since a user may be logged
127 on more than once, it is necessary to use a unique identifier (the sock) rather
128 than a username (you wouldn't know which one to update if he were logged on
129 twice). Note in the example, there is no away message.
130
131 2.8 el command
132
133 Once the data for all of the users has been transferred, we receive the el
134 command, which signifies the end of linking. Now we can pass around other
135 events, like channel chatter, joins, parts, etc, as they happen.
136
137
138
139
140
141
142
143 3. Maintaining a connection
144
145 This section is very simple. The only command you *need* to implement to
146 maintain a connection is...
147
148 3.1 pi/ping command
149
150 When you get "pi", you should quickly respond "po". That is all.
151
152
153
154
155
156
157
158
159 4. Channel commands
160
161 This section deals with the commands related to partyline channels.
162
163 4.1 j/join command
164
165 This command is largely the same as the join command received while you are
166 connecting. Format:
167
168 j botname user chan# (icon)sock user@host
169
170 When you receive the join command, botname will be the obot's name. When you
171 send the join command, botname will be your bot's name. Chan# and sock are
172 in base64.
173
174 4.2 pt/part command
175
176 When a user leaves a channel, a part command is generated. Format:
177
178 pt botname user sock reason
179
180 Botname is of course the originating bot. Sock will be encoded in base64. Reason
181 is optional.
182
183 4.3 c/chat command
184
185 When somebody talks on a partyline channel, eggdrop uses this command. Format:
186
187 c user@botname chan# text
188
189 Pretty self explanatory. Chan# is base64. Example:
190
191 c stdarg@dragonbot A asdf asdf asdf
192
193 The other use of the chat command is for a bot message. When the bot wants
194 to say something to the channel, it leaves off the user@ and does:
195
196 c botname chan# text
197
198
199
200
201
202 That's all for now!

webmaster@eggheads.org
ViewVC Help
Powered by ViewVC 1.1.23