- irc flooding solution
git clone git://
Log | Files | Refs | Archive | README

commit 5d6877afe803f53294f492a80903b6cfbeca9983
Author: acidvegas <>
Date: Sun, 4 Apr 2021 12:50:39 -0400

Initial commit

Diffstat: | 43+++++++++++++++++++++++++++++++++++++++++++
Amuhstik/CIDR.txt | 316+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/MONITOR.txt | 117+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/MOTD | 10++++++++++
Amuhstik/Makefile | 21+++++++++++++++++++++
Amuhstik/NAMES | 40++++++++++++++++++++++++++++++++++++++++
Amuhstik/SASL.txt | 119+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/TODO.odt | 0
Amuhstik/TODO.pdf | 0
Amuhstik/TODO.tex | 219+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/cisco.txt | 2641+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/ident.word | 13581+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/include/clone.h | 101+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/include/control.h | 31+++++++++++++++++++++++++++++++
Amuhstik/include/globals.h | 74++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/include/init.h | 92+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/include/lists.h | 55+++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/include/load.h | 29+++++++++++++++++++++++++++++
Amuhstik/include/mass.h | 31+++++++++++++++++++++++++++++++
Amuhstik/include/muhstik.h | 25+++++++++++++++++++++++++
Amuhstik/include/net.h | 43+++++++++++++++++++++++++++++++++++++++++++
Amuhstik/include/print.h | 32++++++++++++++++++++++++++++++++
Amuhstik/include/proxy.h | 50++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/include/string.h | 46++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/ipv6/ | 28++++++++++++++++++++++++++++
Amuhstik/ipv6/ | 178+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/ipv6/ | 10++++++++++
Amuhstik/ipv6/ | 13+++++++++++++
Amuhstik/jupes.txt | 47+++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/muhstik | 0
Amuhstik/muhstik.conf | 154+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/muhstik.wordlist | 7209+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/prox/ | 34++++++++++++++++++++++++++++++++++
Amuhstik/prox/prox.tcl | 167+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/prox/ | 21+++++++++++++++++++++
Amuhstik/proxies.txt | 1938+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/servers | 225+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/servers6 | 225+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/ | 4++++
Amuhstik/socks4.txt | 2114+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/socks5.txt | 2113+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/src/clone.c | 1418+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/src/control.c | 1022+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/src/init.c | 362+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/src/lists.c | 363+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/src/load.c | 316+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/src/mass.c | 277+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/src/muhstik.c | 469+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/src/net.c | 205+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/src/print.c | 500+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/src/proxy.c | 449+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/src/string.c | 216+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Amuhstik/vhosts | 100+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

53 files changed, 37893 insertions(+), 0 deletions(-)

diff --git a/ b/
@@ -0,0 +1,42 @@
+# muhstik
+> irc flooding solution
+## Information
+muhstik, an enterprise-class fully functional IRC flooding solution for your mission-critical trolling needs, was retroactively created around December 1993 to help perpetuate the incessant wars on #gayteen.
+It uses a state-of-the-art event-based system to concurrently connect to proxies and servers.
+In fact, testing of an early version of one of muhstik's parent scripts is the reason that freenode now checks for open SOCKS proxies.
+## Authors
+* Louis Bavoil
+* roadr
+* Leon Kaiser
+## Credits
+* abez              for ghost-writing ASIAN.
+* Blackman Heartiez for his collection of nicks.
+* freenode          for providing the perfect environment for testing muhstik.
+* h                 for his contributions to my understanding of Internet Protocol version 6, Domain Name Systems, and tunneling.
+* incog             for blogging with Rufas about AYSYN, ASIAN, and STUPID.
+* JacksonBrown      for writing '', which I used to gather thousands of IRC nicks for muhstik.wordlist.
+* Jmax              for his many, many ideas from ASIAN and for his multiple blog sessions with vxp and madvirii. Also for coding
+* l0de              for blogging with Rufas about AYSYN, ASIAN, and STUPID.
+* madvirii          for his multiple blog sessions with Jmax and vxp.
+* mef               for writing AYSYN.
+* Osama Bin Laden   for his contributions to my chronic insomnia/PTSD and for being THE GREATEST MAN ALIVE. You were a shining beacon of hope for freedom worldwide, rest in peace.
+* rshxd             for blogging with Rufas about AYSYN, ASIAN, and STUPID.
+* Rufas             for writing ASIAN and STUPID, as well as blogging to l0de about the aforementioned scripts.
+* sam               because he no doubt helped with this somewhere, he's everywhere FFS.
+* sloth             for blogging to l0de about IPv6 botnets, and his collection of nicks.
+* sparc             for blogging with Rufas about AYSYN, ASIAN, and STUPID.
+* thyme             for blogging with Rufas about AYSYN, ASIAN, and STUPID.
+* vxp               for his multiple blog sessions with Jmax and madvirii.
+* w00t (aka X)      for his collection of nicks.
+* chrono            for leaking this private muhstik loldongs.
+* acidvegas         for keeping the dream alive.
+## Mirrors
+- []( *(main)*
+- [GitHub](
+- [GitLab](
+\ No newline at end of file
diff --git a/muhstik/CIDR.txt b/muhstik/CIDR.txt
@@ -0,0 +1,316 @@
+$Id: /rb/doc/CIDR.txt 2 2008-12-17T03:10:09.215481Z androsyn  $
+CIDR Information
+  Presently, we all use IPv4.  The format of IPv4 is the following:
+  Where letters 'A' through 'D' are 8-bit values.  In English, this
+  means each digit can have a value of 0 to 255.  Example:
+  Digits are called octets.  Oct meaning 8, hence 8-bit values.  An
+  octet cannot be greater than 255, and cannot be less than 0 (eg. a
+  negative number).
+  CIDR stands for "classless inter domain routing", details covered
+  in RFC's 1518 and 1519. It was introduced mainly due to waste within
+  A and B classes space. The goal was to make it possible to use
+  smaller nets than it would seem from (above) IP classes, for instance
+  by dividing one B class into 256 "C like" classes. The other goal was
+  to allow aggregation of routing information, so that routers could use
+  one aggregated route (like instead of
+  advertising 16 C classes.
+  Class A are all these addresses which first bit is "0",
+  bitmap: 0nnnnnnn.hhhhhhhh.hhhhhhhh.hhhhhhhh (n=net, h=host)
+  IP range is -
+  Class B are all these addresses which first two bits are "10",
+  bitmap: 10nnnnnn.nnnnnnnn.hhhhhhhh.hhhhhhhh (n=net, h=host)
+  IP range is -
+  Class C are all these addresses which first three bits are "110",
+  bitmap: 110nnnnn.nnnnnnnn.nnnnnnnn.hhhhhhhh (n=net, h=host)
+  IP range is -
+  Class D are all these addresses which first four bits are "1110",
+  this is multicast class and net/host bitmap doesn't apply here
+  IP range is -
+  I bet they will never IRC, unless someone creates multicast IRC :)
+  Class E are all these addresses which first five bits are "11110",
+  this class is reserved for future use
+  IP range is -
+  So, here is how CIDR notation comes into play.
+  For those of you who have real basic exposure to how networks are
+  set up, you should be aware of the term "netmask."  Basically, this
+  is a IPv4 value which specifies the "size" of a network.  You can
+  assume the word "size" means "range" if you want.
+  A chart describing the different classes in CIDR format and their
+  wildcard equivalents would probably help at this point:
+CIDR version	dot notation (netmask)	Wildcard equivalent
+A.0.0.0/8	A.0.0.0/	A.*.*.*  or  A.*
+A.B.0.0/16	A.B.0.0/	A.B.*.*  or  A.B.*
+A.B.C.0/24	A.B.C.0/	A.B.C.*  or  A.B.C.*
+A.B.C.D/32	A.B.C.D/	A.B.C.D
+  The question on any newbies mind at this point is "So what do all
+  of those values & numbers actually mean?"
+  Everything relating to computers is based on binary values (1s and
+  zeros).  Binary plays a *tremendous* role in CIDR notation.  Let's
+  break it down to the following table:
+          A            B            C            D
+       --------     --------     --------     --------
+/8  == 11111111  .  00000000  .  00000000  .  00000000  ==
+/16 == 11111111  .  11111111  .  00000000  .  00000000  ==
+/24 == 11111111  .  11111111  .  11111111  .  00000000  ==
+/32 == 11111111  .  11111111  .  11111111  .  11111111  ==
+  The above is basically a binary table for the most common netblock
+  sizes.  The "1"s you see above are the 8-bit values for each octet.
+  If you split an 8-bit value into each of it's bits, you find the
+  following:
+^^^^^^^^_ 1sts place  (1)
+|||||||__ 2nds place  (2)
+||||||___ 3rds place  (4)
+|||||____ 4ths place  (8)
+||||_____ 5ths place  (16)
+|||______ 6ths place  (32)
+||_______ 7ths place  (64)
+|________ 8ths place  (128)
+  Now, since computers consider zero a number, you pretty much have
+  to subtract one (so-to-speak; this is not really how its done, but
+  just assume it's -1 :-) ) from all the values possible.  Some
+  examples of decimal values in binary:
+15  == 00001111  (from left to right: 8+4+2+1)
+16  == 00010000  (from left to right: 16)
+53  == 00110101  (from left to right: 32+16+4+1)
+79  == 01001111  (from left to right: 64+8+4+1)
+254 == 11111110  (from left to right: 128+64+32+16+8+4+2)
+  So, with 8 bits, the range (as I said before) is zero to 255.
+  If none of this is making sense to you at this point, you should
+  back up and re-read all of the above.  I realize it's a lot, but
+  it'll do you some good to re-read it until you understand :-).
+  So, let's modify the original table a bit by providing CIDR info
+  for /1 through /8:
+          A            B            C            D
+       --------     --------     --------     --------
+/1  == 10000000  .  00000000  .  00000000  .  00000000  ==
+/2  == 11000000  .  00000000  .  00000000  .  00000000  ==
+/3  == 11100000  .  00000000  .  00000000  .  00000000  ==
+/4  == 11110000  .  00000000  .  00000000  .  00000000  ==
+/5  == 11111000  .  00000000  .  00000000  .  00000000  ==
+/6  == 11111100  .  00000000  .  00000000  .  00000000  ==
+/7  == 11111110  .  00000000  .  00000000  .  00000000  ==
+/8  == 11111111  .  00000000  .  00000000  .  00000000  ==
+  At this point, all of this should making a lot of sense, and you
+  should be able to see the precision that you can get by using CIDR
+  at this point.  If not, well, I guess the best way to put it would
+  be that wildcards always assume /8, /16, or /24 (yes hello Piotr,
+  we can argue this later: I am referring to IPs *ONLY*, not domains
+  or FQDNs :-) ).
+  This table will provide a reference to all of the IPv4 CIDR values
+cidr|netmask (dot notation)
+/1  |
+/2  |
+/3  |
+/4  |
+/5  |
+/6  |
+/7  |
+/8  |
+/9  |
+/10 |
+/11 |
+/12 |
+/13 |
+/14 |
+/15 |
+/16 |
+/17 |
+/18 |
+/19 |
+/20 |
+/21 |
+/22 |
+/23 |
+/24 |
+/25 |
+/26 |
+/27 |
+/28 |
+/29 |
+/30 |
+/31 |
+/32 |
+  So, let's take all of the information above, and apply it to a
+  present-day situation on IRC.
+  Let's say you have a set of flooding clients who all show up from
+  the following hosts.  For lack-of a better example, I'll use a
+  subnet here at Best:
+nick1  (  []
+nick2  (  []
+nick3  ( []
+  Most people will assume the  they were all in the same class C
+  (  or  206.184.139.*).
+  This, as a matter of fact, is not true.  Now, the reason *I* know
+  this is solely because I work on the network here; those IPs are
+  not delegated to a class C, but two portions of a class C (128 IPs
+  each).  That means the class C is actually split into these two
+  portions:
+Netblock               IP range
+--------               --------
+   to
+ to
+  For the record, and are both known as
+  "network addresses" (not to be confused with "netblocks" or "Ethernet
+  hardware addresses" or "MAC addresses").  Network addresses are
+ and are what are known as broadcast
+  addresses.  Broadcast addresses are *ALWAYS ODD*.
+  Now, the aforementioned list of clients are in the 2nd subnet shown
+  above, not the first.  The reason for this should be obvious.
+  The remaining question is, "Well that's nice, you know what the netblock
+  is for Best.  What about us?  We don't know that!"
+  Believe it or not, you can find out the network block size by using
+  whois -h WHOIS.ARIN.NET on the IP in question.  ARIN keeps a list of
+  all network blocks and who owns them -- quite useful, trust me.  I
+  think I use ARIN 5 or 6 times a day, especially when dealing with
+  D-lines.  Example:
+$ whois -h
+Best Internet Communications, Inc. (NETBLK-NBN-206-184-BEST)
+345 East Middlefield Road
+Mountain View, CA 94043
+Netname: NBN-206-184-BEST
+Netblock: -
+Maintainer: BEST
+  Does this mean you should D-line  Probably not.
+  That's an entire class B-sized block, while you're only trying
+  to deny access to a subnetted class C.
+  So then how do you get the *real* info?  Well, truth is, you don't.
+  You have to pretty much take a guess at what it is, if ARIN reports
+  something that's overly vague.  Best, for example, was assigned the
+  above class B-sized block.  We can subnet it however we want without
+  reporting back to ARIN how we have it subnetted.  We own the block,
+  and that's all that matters (to ARIN).
+  Not all subnets are like this, however.  Smaller subnets you may
+  find partitioned and listed on ARIN; I've seen /29 blocks for DSL
+  customers show up in ARIN before.
+  So, use ARIN any chance you get.  The more precision the better!
+  Now, there is a small issue I want to address regarding use of CIDR
+  notation.  Let's say you D-line the following in CIDR format (hi
+  sion ;-) ):
+  Entries like this really makes my blood boil, solely because it adds
+  excessive confusion and is just basically pointless.  If you
+  examine the above, you'll see the /24 is specifying an entire
+  class C -- so then what's the purpose of using .18 versus .0?
+  There IS no purpose.  The netmask itself will mask out the .18 and
+  continue to successfully use
+  Doing things this way just adds confusion, especially on non-octet-
+  aligned subnets (such as /8, /16, /24, or /32).  Seeing that on a
+  /27 or a /19 might make people go "wtf?"
+  I know for a fact this doc lacks a lot of necessary information,
+  like how the actual netmask/CIDR value play a role in "masking out"
+  the correct size, and what to do is WHOIS.ARIN.NET returns no
+  netblock information but instead a few different company names with
+  NIC handles.  I'm sure you can figure this stuff out on your own,
+  or just ask an administrator friend of yours who DOES know.  A lot
+  of us admins are BOFH types, but if you ask us the right questions,
+  you'll benefit from the answer quite thoroughly.
+  Oh, I almost forgot.  Most Linux systems use a different version of
+  "whois" than FreeBSD does.  The syntax for whois on Linux is
+  "whois <INFO>", while under FreeBSD it is
+  "whois -h <INFO>"  Debian uses yet another version
+  of whois that is incompatible with the above syntax options.
+  Note that the FreeBSD whois client has shortcuts for the most commonly
+  used whois servers.  "whois -a <INFO>" is the shortcut for ARIN.
+  Also note that ARIN is not authoritative for all IP blocks on the 
+  Internet.  Take for example  A whois query to ARIN
+  will return the following information:
+$ whois -h
+European Regional Internet Registry/RIPE NCC (NET-RIPE-NCC-)
+   These addresses have been further assigned to European users.
+   Contact information can be found in the RIPE database, via the
+   WHOIS and TELNET servers at, and at
+   Netname: RIPE-NCC-212
+   Netblock: -
+   Maintainer: RIPE
+  This query tells us that it is a European IP block, and is further
+  handled by RIPE's whois server.  We must then query
+  to get more information.
+$ whois -h
+% Rights restricted by copyright. See
+inetnum: -
+netname:     INSNET-P2P
+descr:       Point to Point Links for for London Nodes
+country:     GB
+  This tells us the actual IP block that the query was a part of.
+  Other whois servers that you may see blocks referred to are: 
+ for Russia, for Asia, Australia, and
+  the Pacific, and for IPv6 blocks.
+Contributed by Jeremy Chadwick <>
+Piotr Kucharski <> 
+W. Campbell <> and
+Ariel Biener <>
diff --git a/muhstik/MONITOR.txt b/muhstik/MONITOR.txt
@@ -0,0 +1,117 @@
+MONITOR - Protocol for notification of when clients become online/offline
+             Lee Hardy <lee -at->
+$Id: monitor.txt 23973 2007-06-30 22:28:55Z jilles $
+Currently, ISON requests by clients use a large amount of bandwidth.  It is
+expected that it is more efficient for this to be done by the server at the 
+expense of cpu cycles.  The WATCH implementation that was designed to counter 
+this is (in my opinion) severely flawed.  This protocol was designed to 
+provide a cleaner implementation.
+The command used throughout this specification is "MONITOR".
+Each use of the MONITOR command takes a special modifier, indicating
+the operation being performed.  The client MUST NOT attempt to specify
+more than one modifier.  Only one special modifier may be used per MONITOR
+Thus it is impossible to combine additions to the list with removals from
+the list -- these MUST be done with two seperate commands.
+A client MUST NOT issue the MONITOR command more than once per second.
+Any attempts to do so will generate an error.
+In commands and numerics where multiple nicknames may occur, the length of
+the nickname list is limited only by the buffer size of 512 chars, as
+defined in RFC1459.
+Support of this specification is indicated by the MONITOR token in
+RPL_ISUPPORT (005).  This token takes an optional parameter, of the maximum
+amount of nicknames a client may have in their monitor list.  If no
+parameter is specified, there is no limit.  A typical token would be:
+MONITOR + nick[,nick2]*
+Adds the given list of nicknames to the list of nicknames being monitored.
+If any of the nicknames being added are online, the server will generate
+RPL_MONONLINE numerics listing those nicknames that are online.
+If any of the nicknames being added are offline, the server will generate
+RPL_MONOFFLINE numerics listing those nicknames that are offline.
+MONITOR - nick[,nick2]*
+Removes the given list of nicknames from the list of nicknames being
+monitored.  No output will be returned for use of this command.
+Clears the list of nicknames being monitored.  No output will be returned
+for use of this command.
+Outputs the current list of nicknames being monitored.  All output will use
+RPL_MONLIST, and the output will be terminated with RPL_ENDOFMONLIST
+Outputs for each nickname in the list being monitored, whether the client is
+online or offline.  All nicks that are online will be sent using 
+RPL_MONONLINE, all nicks that are offline will be sent using RPL_MONOFFLINE.
+The list will be terminated with RPL_ENDOFMONLIST.
+Numeric replies
+:<server> 730 <nick> :nick!user@host[,nick!user@host]*
+This numeric is used to indicate to a client that either a nickname has just
+become online, or that a nickname they have added to their monitor list is
+The server may send "*" instead of the target nick (<nick>). (This makes it
+possible to send the exact same message to all clients monitoring a certain
+:<server> 731 <nick> :nick[,nick1]*
+This numeric is used to indicate to a client that either a nickname has just
+left the irc network, or that a nickname they have added to their monitor
+list is offline.
+The argument is a chained list of nicknames that are offline.
+As with 730 the server may send "*" instead of the target nick.
+:<server> 732 <nick> :nick[,nick1]*
+This numeric is used to indicate to a client the list of nicknames they have
+in their monitor list.
+:<server> 733 <nick> :End of MONITOR list
+This numeric is used to indicate to a client the end of a monitor list.
+:<server> 734 <nick> <limit> <nicks> :Monitor list is full.
+This numeric is used to indicate to a client that their monitor list is
+full, so the command failed.  The <limit> parameter is the maximum number of 
+nicknames a client may have in their list, the <nicks> parameter is the list
+of nicknames, as the client sent them, that cannot be added.
diff --git a/muhstik/MOTD b/muhstik/MOTD
@@ -0,0 +1,10 @@
+                                      _         _   _ _
+                      _ __ ___  _   _| |__  ___| |_(_) | __
+                     | '_ ` _ \| | | | '_ \/ __| __| | |/ /
+                     | | | | | | |_| | | | \__ \ |_| |   < 4.2.3
+                     |_| |_| |_|\__,_|_| |_|___/\__|_|_|\_\
+                            Maintainer: Leon Kaiser
+                          E-mail: <>
+                           Web: <>
+              $ last rev: 59d302dcdfc42fada321c66a3afb66bf6d3cfe64 $
diff --git a/muhstik/Makefile b/muhstik/Makefile
@@ -0,0 +1,21 @@
+CFLAGS=-Wsign-compare -Wall -I/usr/local/include
+LDFLAGS=-L/usr/local/lib -lpthread
+OBJS=clone.o control.o init.o lists.o load.o mass.o muhstik.o net.o print.o proxy.o string.o
+all:		muhstik dork
+muhstik:	$(OBJS)
+		cd build; $(CC) $(LDFLAGS) -o ../muhstik $(OBJS)
+		$(CC) $(CFLAGS) -c -o build/$@ $<
+		rm -f *~
+		rm -f */*~
+clean:		notmp
+		rm -f build/*.o
+		latex doc/TODO.tex
+		dvipdf TODO.dvi doc/TODO.pdf
+		rm -f TODO.dvi TODO.aux TODO.log texput.log
diff --git a/muhstik/NAMES b/muhstik/NAMES
@@ -0,0 +1,40 @@
+* Cisco
+* Demolish
+* IRC
+* Router
+* Ruin
+* Syncronized
+* gaping
+* galling
+* glorious
+* galvanizing
+* gratuitous
+* genital
+* genocidal
+* generous
+ALLAH:      A... L... L... A... H...
+BINLADEN:   B... IRC N... L... A... D... E... N...
+CHIMPIN:    C... Hyper-Intensive Multi Protocol IRC Nuker
+CHINKS:     Cisco HTTP IRC Nuker K... SOCKS
+CHUFTER:    Cisco HTTP U... F... T... E... Ruin
+FAGGOT:     F... A... G... G... O... T...
+FATWAH:     F... A... T... W... A... H...
+GAYPORNO:   G... A... Y... P... O... R... N... O...
+JIHAD:      J... IRC HTTP A... D...
+MIRC:       Masive IRC Ruining Clones
+MUHSTIK:    Massive Unwanted Homosexual Shitstorm Targeting IRC K...
+NIGGERCUNT: Networked IRC Generating Glorious Enterprise Ruin Causing Unprecedented Night Terrors
+OSAMA:      O... Synchronized A... M... A...
+RAPIST:     Ruinous Assault Program IRC SOCKS Targeter
+SANDNIGGER: Syncronized Assault Network Demolishing IRC Generating Gratuitous Eternal Ruin
+SHITSKIN:   SOCKS HTTP I... T... S... K... IRC Nuker
diff --git a/muhstik/SASL.txt b/muhstik/SASL.txt
@@ -0,0 +1,119 @@
+SASL authentication
+This document describes the client protocol for SASL authentication, as
+implemented in charybdis and atheme.
+SASL authentication relies on the CAP client capability framework [1].
+Support for SASL authentication is indicated with the "sasl" capability.
+The client MUST enable the sasl capability before using the AUTHENTICATE
+command defined by this specification.
+The AUTHENTICATE command MUST be used before registration is complete and
+with the sasl capability enabled. To enforce the former, it is RECOMMENDED
+to only send CAP END when the SASL exchange is completed or needs to be
+aborted. Clients SHOULD be prepared for timeouts at all times during the SASL
+There are two forms of the AUTHENTICATE command: initial client message and
+later messages.
+The initial client message specifies the SASL mechanism to be used. (When this
+is received, the IRCD will attempt to establish an association with a SASL
+agent.) If this fails, a 904 numeric will be sent and the session state remains
+unchanged; the client MAY try another mechanism. Otherwise, the server sends
+a set of regular AUTHENTICATE messages with the initial server response.
+initial-authenticate = "AUTHENTICATE" SP mechanism CRLF
+A set of regular AUTHENTICATE messages transmits a response from client to
+server or vice versa. The server MAY intersperse other IRC protocol messages
+between the AUTHENTICATE messages of a set. The "+" form is used for an empty
+response. The server MAY place a limit on the total length of a response.
+regular-authenticate-set = *("AUTHENTICATE" SP 400BASE64 CRLF)
+	"AUTHENTICATE" SP (1*399BASE64 / "+") CRLF
+The client can abort an authentication by sending an asterisk as the data.
+The server will send a 904 numeric.
+authenticate-abort = "AUTHENTICATE" SP "*" CRLF
+If authentication fails, a 904 or 905 numeric will be sent and the
+client MAY retry from the AUTHENTICATE <mechanism> command.
+If authentication is successful, a 900 and 903 numeric will be sent.
+If the client attempts to issue the AUTHENTICATE command after already
+authenticating successfully, the server MUST reject it with a 907 numeric.
+If the client completes registration (with CAP END, NICK, USER and any other
+necessary messages) while the SASL authentication is still in progress, the
+server SHOULD abort it and send a 906 numeric, then register the client
+without authentication.
+This document does not specify use of the AUTHENTICATE command in
+registered (person) state.
+Example protocol exchange
+C: indicates lines sent by the client, S: indicates lines sent by the server.
+The client is using the PLAIN SASL mechanism with authentication identity
+jilles, authorization identity jilles and password sesame.
+C: CAP REQ :sasl
+C: NICK jilles
+C: USER jilles 1 :Jilles Tjoelker
+S: NOTICE AUTH :*** Processing connection to jaguar.test
+S: NOTICE AUTH :*** Looking up your hostname...
+S: NOTICE AUTH :*** Checking Ident
+S: NOTICE AUTH :*** No Ident response
+S: NOTICE AUTH :*** Found your hostname
+S: :jaguar.test CAP jilles ACK :sasl 
+S: :jaguar.test 900 jilles jilles! jilles :You are now logged in as jilles.
+S: :jaguar.test 903 jilles :SASL authentication successful
+S: :jaguar.test 001 jilles :Welcome to the jillestest Internet Relay Chat Network jilles
+<usual welcome messages>
+Note that the CAP command sent by a server includes the user's nick or *,
+differently from what [1] specifies.
+Alternatively the client could request the list of capabilities and enable
+an additional capability.
+C: NICK jilles
+C: USER jilles 1 :Jilles Tjoelker
+S: NOTICE AUTH :*** Processing connection to jaguar.test
+S: NOTICE AUTH :*** Looking up your hostname...
+S: NOTICE AUTH :*** Checking Ident
+S: NOTICE AUTH :*** No Ident response
+S: NOTICE AUTH :*** Found your hostname
+S: :jaguar.test CAP * LS :multi-prefix sasl
+C: CAP REQ :multi-prefix sasl
+S: :jaguar.test CAP jilles ACK :multi-prefix sasl 
+S: :jaguar.test 900 jilles jilles! jilles :You are now logged in as jilles.
+S: :jaguar.test 903 jilles :SASL authentication successful
+S: :jaguar.test 001 jilles :Welcome to the jillestest Internet Relay Chat Network jilles
+<usual welcome messages>
+[1] K. Mitchell, P. Lorier (Undernet IRC Network), L. Hardy (ircd-ratbox), P.
+Kucharski (IRCnet), IRC Client Capabilities Extension. March 2005.
+This internet-draft has expired; it can still be found on
+See also and
+ (these links are
+currently dead but may be resurrected in the future).
+$Id: sasl.txt 3169 2007-01-28 22:13:18Z jilles $
diff --git a/muhstik/TODO.odt b/muhstik/TODO.odt
Binary files differ.
diff --git a/muhstik/TODO.pdf b/muhstik/TODO.pdf
Binary files differ.
diff --git a/muhstik/TODO.tex b/muhstik/TODO.tex
@@ -0,0 +1,219 @@
+\author{Leon Kaiser}
+\contentsline {section}{\numberline {1}Tasks Organized by Priority}{2}
+\contentsline {subsection}{\numberline {1.1}High Priority}{2}
+\contentsline {subsection}{\numberline {1.2}Medium Priority}{2}
+\contentsline {subsection}{\numberline {1.3}Low Priority}{3}
+\contentsline {subsection}{\numberline {1.4}Unknown Priority}{3}
+\contentsline {section}{\numberline {2}Relevant IRC/IRL logs:}{4}
+\contentsline {subsection}{\numberline {2.1}Jmax}{4}
+\contentsline {subsubsection}{\numberline {2.1.1}Jmax and madvirii}{4}
+\contentsline {subsubsection}{\numberline {2.1.2}Jmax, vx`, and madvirii.}{4}
+\contentsline {subsection}{\numberline {2.2}LiteralKa blogging to no-one in particular.}{5}
+\contentsline {subsection}{\numberline {2.3}Rufas}{5}
+\contentsline {subsubsection}{\numberline {2.3.1}Rufas, sparc, and thyme}{5}
+\contentsline {subsubsection}{\numberline {2.3.2}Rufas, incog, and rshxd.}{6}
+\contentsline {subsection}{\numberline {2.4}The l0de Radio Hour}{6}
+\contentsline {subsubsection}{\numberline {2.4.1}Rufas at [S1E12] 16:26}{6}
+\contentsline {subsubsection}{\numberline {2.4.2}Rufas at [20100409] 30:00}{6}
+\contentsline {subsubsection}{\numberline {2.4.3}sloth at [20100409] 3:07:21}{7}
+% {{{ Tasks organized by priority
+\section{Tasks Organized by Priority}\label{Tasks Organized by Priority}\index{Tasks Organized by Priority}
+% {{{ High Priority
+\subsection{High Priority}\label{High Priority}\index{High Priority}
+\item Support clone connections via {\tt TOR}.
+\item {\tt TOR} might actually already be supported by {\tt PROXY}.
+\item File flooding with \emph{optional} adjustments for nick-length and latency.
+\item The reason for the `optional' bit is because one won't necessarily need a nick-length adjustment if the file being flooded is not an {\tt ASCII} file (in fact, it will just look weird.)
+\item Permit (bot)net to target multiple networks (be able to send separate commands to an individual network's bots.
+\item Implement {\tt STUPID}-like {\tt SSH} tunneling. ({\tt SSH Tunnel Utilizing Python IRC Destroyer}.)
+\item {\tt}-style nick spamming (using {\tt /NAMES} output.)
+% }}}
+% {{{ Medium Priority
+\subsection{Medium Priority}\label{Medium Priority}\index{Medium Priority}
+\item Add `nickshuffle' with `nickbase' option.
+\item {\tt do\_jupe()}:
+\item Call on \{de,re,\}connection.
+\item muhstik's mechanism to do {\tt MODE}s and {\tt KICK}s sucks. It doesn't track any list of nicks to op, or nicks to {\tt KICK}, but it tries to change with simple {\tt MODE +o} and {\tt KICK}. This needs to be recoded with penalty handling.
+\item Mass\{{\tt KNOCK},{\tt INVITE},{\tt TOPIC}\}.
+\item For mass{\tt INVITE}s, allow a mask (*!*@*.* style) `blacklist' of sorts, so that the clones don't {\tt INVITE} honeypot bots, lorf.
+\item Add a `stop connect' command (`pause' or w/e.)
+\item It should toggle, obviously.
+\item Max bots for connect -- maximum successful bots, not maximum connections.
+\item Allow increase/decrease.
+\item Support {\tt SSL}/{\tt TLS} and {\tt SASL} {\tt IRC} connections%
+\footnote[1]{Leach, P., Newman, C. \emph{Using Digest Authentication as a SASL Mechanism}, {\tt RFC 2831}, May 2000, (}%
+\footnote[2]{Myers, J. \emph{Simple Authentication and Security Layer (SASL)}, {\tt RFC 2222}, October 1997. (}%
+\footnote[3]{Newman, C. \emph{Anonymous SASL Mechanism}, {\tt RFC 2245}, November 1997. (}
+\item Fix the buffer overflow or what the fuck ever when scan mode is enabled.
+% }}}
+% {{{ Low Priority
+\subsection{Low Priority}\label{Low Priority}\index{Low Priority}
+\item Inline documentation.
+\item {\tt TOPIC} lock mode.
+\item {\tt TOPIC} fight mode.
+\item {\tt CTCP} responses.
+\item Random colored messages.
+\item Spam every person, (non-)\{op,ircop,voice\}, etc. in the channel.
+\item \{Mass,Single\} reconnect (for evading {\tt ident} bans.)
+\item Detect {\tt MODE +g} notifications on {\tt PRIVMSG}.
+\item Probably should just issue a warning or something.
+\item Add \emph{optional} spectator -- bot that watches, and doesn't respond to `all'.
+\item Modify bot behavior so that if a clone is the only `user' in a channel, the clone will cycle \emph{only} once. If deopped by ChanServ, etc. then give up.
+\item Possibly include a configuration setting that determines if channel registration is possible on the network ({\tt boolean}, on the off-chance that a network with NickServ doesn't have ChanServ, as it would otherwise be covered by {\tt conf.dalnet}.)
+\item Does {\tt echo} mimic {\tt CTCP ACTION}s as well?
+\item Allow \emph{optional} Cisco passwords (in format IP\{:PW,\}.)
+\item {\tt do\_jupe()}:
+\item If ghosted, does the affected clone reconnect?
+% }}}
+% {{{ Unknown Priority
+\subsection{Unknown Priority}\label{Unknown Priority}\index{Unknown Priority}
+\item {\tt do\_jupe()}:
+\item \_2\_ @ {\tt MONITOR}
+\item Handle overflow.
+\item {\tt .select *\&,}
+\item {\tt .deaf}
+\item Write or find some sort of tool that can differentiate between {\tt SOCKS4} and {\tt SOCKS5} proxies.
+\item Should {\tt static} be used more?
+% }}}
+% }}}
+% {{{ Relevant IRC/IRL logs:
+\section{Relevant IRC/IRL logs:}\label{Relevant IRC/IRL logs:}\index{Relevant IRC/IRL logs:}
+% {{{ Jmax
+% {{{ Jmax and madvirii.
+\subsubsection{Jmax and madvirii}\label{Jmax and madvirii}\index{Jmax and madvirii}
+02:32:57 $<$@Jmax$>$ maybe... add line numbers?\\
+02:33:12 $<$+madvirii$>$ yah, like but it would have to be a system\\
+02:33:19 $<$@Jmax$>$ or after the line is sent to chan, send a message to the next\\\indent bot\\
+02:33:20 $<$+madvirii$>$ cuz it would get old editing your fav asciis\\
+02:33:36 $<$@Jmax$>$ system?\\
+02:33:44 $<$+madvirii$>$ yah like, read the txt file in line by line in an array, and\\\indent then assign a line number to each bot accordingly, if they got banned, it\\\indent might affect it, unless u design a failsafe, but it seems to be the right direction\\\indent to head in\\
+02:34:50 $<$@Jmax$>$ if a bot can't send the message, it's delegated
+% }}}
+% {{{ Jmax, vx`, and madvirii.
+\subsubsection{Jmax, vx`, and madvirii.}\label{Jmax, vx`, and madvirii.}\index{Jmax, vx`, and madvirii.}
+02:44:38 $<$@Jmax$>$ if you mean \emph{cat}|(1)ting, then here's what I have in mind:\\
+02:44:41 $<$@Jmax$>$ 1) determine latency\\
+02:44:47 $<$ vx`$>$ if it's gonna have the ability to scroll an ascii with the whole\\\indent set of bots or some that ie. aren't banned on the channel\\
+02:44:50 $<$@Jmax$>$ 2) ignore any bots with high latency, if there's enough bots\\
+02:44:56 $<$ vx`$>$ then you wouldn't want some bots ruining the ascii because of\\\indent slow links\\
+02:45:38 $<$+madvirii$>$ well, if we determine latency, and then just have the ten\\\indent fastest bots\\
+02:45:52 $<$@Jmax$>$ no, we can't just ignore the bots\\
+02:45:59 $<$ vx`$>$ hardly efficient\\
+02:46:03 $<$@Jmax$>$ if we only have 10, then it'll still be limited. esp. if we have\\\indent 100 more\\
+02:46:34 $<$ vx`$>$ apart from that, low latency links might get a) hit by the other\\\indent bots scrolling b) throttled c) \{banned,muted,shunned,glined\}\\
+02:47:29 $<$@Jmax$>$ 3) determine which bots are capable of speaking in the\\\indent channel. (not\{muted,banned,shunned\}, etc.)\\
+02:47:56 $<$ vx`$>$ freenode's ircd might have some gay features to suppress\\\indent ruining, and you don't necessarily get numerics from the ircd informing you\\
+02:48:11 $<$+madvirii$>$ that is a good 3-step process to execute \emph{prior} to even\\\indent attempting to load a file\\
+02:48:31 $<$@Jmax$>$ 4) pull the file into an array, and assign each line to one of\\\indent those bots\\
+02:48:51 $<$@Jmax$>$ 5) measure nick length, pad accordingly\\
+02:50:18 $<$ vx`$>$ but there are some time constraints on that code,\\\indent proportionally to the amount of bots you're scrolling with\\
+02:50:28 $<$@Jmax$>$ actually, in step 4, do not assign each line to a bot, maintain\\\indent each list separately, a queue for \{bot,line\}s\\
+02:55:02 $<$@Jmax$>$ 6) issue the first line to the first bot in queue, and make\\\indent the second bot wait for a successful message. If, during that time, it is\\\indent determined by the first bot that it \emph{cannot} send the message (and it's not a\\\indent latency issue), the line is re-assigned to the next bot in the queue and\\\indent removed from the queue.\\
+02:55:34 $<$@Jmax$>$ 7) repeat until the file is complete.\\
+02:55:52 $<$@Jmax$>$ that will ensure that, if a bot is kicked, the rest of the bots\\\indent take account for it\\
+02:56:04 $<$+madvirii$>$ so the number of lines in the file queue will determine\\\indent the number of bot instances in the bot queue\\
+02:56:05 $<$@Jmax$>$ and any lines assigned to that bot are not ignored\\
+02:56:10 $<$@Jmax$>$ no, completely independent\\
+02:56:27 $<$ vx`$>$ what do you in case of a line not arriving due to ie. unexpected\\\indent network problems, the link going down completely, etc.\\
+02:56:39 $<$+madvirii$>$ ok so its just for lines in queue\\
+02:57:24 $<$@Jmax$>$ well, that's what the second part of step 6 is for, but that\\\indent doesn't account for netsplits\\
+02:57:48 $<$ vx`$>$ or any other network issues for that matter, like the proxy\\\indent going down or lagging, ...\\
+03:00:02 $<$@Jmax$>$ sure it does, there will be a timeout, there will be the chance\\\indent that the bot is just very very lagged, and wasn't removed from the queue\\\indent earlier, and sends the message, reaches the timeout, and the other bot\\\indent replaces it, however, the message was still sent, so it will show up later\\
+03:02:08 $<$ vx`$>$ sure, but out of order and if that'd happen too often it'd ruin\\\indent the whole thing\\
+03:02:16 $<$@Jmax$>$ right: i think that will be a rarity
+% }}}
+% }}}
+% {{{ LiteralKa blogging to no-one in particular.
+\subsection{LiteralKa blogging to no-one in particular.}\label{LiteralKa blogging to no-one in particular.}\index{LiteralKa blogging to no-one in particular.}
+13:51:56 $<$\&LiteralKa$>$ Maybe a command to spam a specific type of person in\\\indent a given channel: (non-)\{ops,ircops,voiced\}, all, etc.\\
+13:53:34 $<$\&LiteralKa$>$ Synchronized ASCII flooding would be p. cool (read:\\\indent \emph{cat}(1)-style file flooding.)\\
+13:53:48 $<$\&LiteralKa$>$ Like, delegate {\tt x} amount of lines to each bot based on\\\indent connection speed or some other algorithm or something.
+% }}}
+% {{{ Rufas
+% {{{ Rufas, sparc, and thyme
+\subsubsection{Rufas, sparc, and thyme}\label{Rufas, sparc, and thyme}\index{Rufas, sparc, and thyme}
+21:38:16 $<$+Rucas$>$ i highly suggest you check out {\tt STUPID}, run it from a very\\\indent fast box and it can DDOS an ircd just by flooding text in chat, {\tt SSH Tunnel\\\indent Utilizing Python IRC Destroyer}\\
+21:38:54 $<$ sparc$>$ \emph{Rucas}: how fast of a box are we talking\\
+21:39:00 $<$+Rucas$>$ 100mbit is perfect, basically you need enough bandwidth\\\indent to push all the OTHER boxes at a decent rate, it still does pretty well from\\\indent a standard cable line though\\
+21:39:42 $<$ thyme$>$ cant do something like: start remote processes on machines\\\indent to avoid having to have one big monsterbox and just send signalling from\\\indent home box\\
+21:40:09 $<$+Rucas$>$ well the original intent was cooperative flooding so like,\\\indent you'd have 5 hosts and they'd all paste lines of one ascii, so you could spam\\\indent asciis but bots wouldn't molish you but i never got around to that, because\\\indent of \emph{jenk}'s {\tt irc-rc}
+% }}}
+% {{{ Rufas, incog, and rshxd.
+\subsubsection{Rufas, incog, and rshxd.}\label{Rufas, incog, and rshxd.}\index{Rufas, incog, and rshxd.}
+21:42:43 $<$ rshxd$>$ \emph{Rucas}: since when did you write {\tt ASIAN}\\
+21:42:50 $<$\&Rucas$>$ fucing years ago\\
+21:42:59 $<$ rshxd$>$ I thought \emph{abez} wrote that for you\\
+21:43:02 $<$\&Rucas$>$ no, i wrote it, and \emph{abez} rewrote part of it\\
+21:43:04 $<$ incog$>$ before that was {\tt AYSYN}\\
+21:43:13 $<$\&Rucas$>$ and then \emph{Jmax} rewrote that, and it is on {\tt ASIANv6} or some\\\indent shit, but i wrote {\tt ASIANv1}\\
+21:43:36 $<$ incog$>$ was it based off \emph{mef}'s shit or all new?\\
+21:43:42 $<$\&Rucas$>$ all new, i wish i had \emph{mef}'s code, but now i wrote {\tt STUPID}\\\indent which is much nicer than {\tt ASIAN}
+% }}}
+% }}}
+% {{{ The l0de Radio Hour
+\subsection{The l0de Radio Hour}\label{The l0de Radio Hour}\index{The l0de Radio Hour}
+% {{{ Rufas at [S1E12] 16:26
+\subsubsection{Rufas at [S1E12] 16:26}\label{Rufas at [S1E12] 16:26}\index{Rufas at [S1E12] 16:26}
+\emph{l0de}: [If you steal that idea] my lawyers will fuck you so severely that it's not\\\indent even funny...\\
+\emph{Rufas}: I'm sure they will, just like that guy's 800 bot botnet running wild on\\\indent EFNet right now.\\
+\emph{l0de}: Holy shit, that's hillarious--he's got 800 bots now?\\
+\emph{Rufas}: Yeah, he's up to 900 now.\\
+\emph{l0de}: 900 fuckin' bots, through a JPEG redirect exploit-type of thing? [...] And\\\indent for our listeners, basically this guy coded an Internet Explorer link that runs\\\indent an mIRC exploit and basically \bf{turns your computar into botnet}\rm\\
+\emph{Rufas}: And he authorized us to reverse engineer it [...] We can use it to assrape\\\indent \emph{\#politics}.
+% }}}
+% {{{ Rufas at [20100409] 30:00
+\subsubsection{Rufas at [20100409] 30:00}\label{Rufas at [20100409] 30:00}\index{Rufas at [20100409] 30:00}
+\emph{l0de}: Alright, so what people really want to hear about from you is the ruin:\\\indent the mega ruin that is going on. And you have this \bf{massive}\rm\symbol{32} fucking botnet\\\indent and you're annihilating everything that comes into contact with you. I know\\\indent Hardchats was DDoSed massively last night, primarily because of your\\\indent exploits. Why don't you tell us what happened?\\
+\emph{Rufas}: Well, not a heck of a lot has really changed with what I've been doing.\\\indent I've used the new tool I wrote a few months ago called {\tt STUPID} but-\\
+\emph{l0de}: Is this a reference to \emph{Max Goldberg}'s {\tt AYSYN}--no it was \emph{mef} that wrote\\\indent {\tt AYSYN} right?\\
+\emph{Rufas}: \emph{mef} wrote {\tt AYSYN} and I wrote {\tt ASIAN} based on that which was {\tt Automated\\\indent Synchronous IRC Attack Network}. And then based on that I made {\tt STUPID},\\\indent which is {\tt SSH Tunnel Utilizing Python IRC Destroyer}--because they all\\\indent have to have some sort of stupid {\tt GNU} acronym to go with them.
+% }}}
+% {{{ sloth at [20100409] 3:07:21
+\subsubsection{sloth at [20100409] 3:07:21}\label{sloth at [20100409] 3:07:21}\index{sloth at [20100409] 3:07:21}
+\emph{sloth}: I've gotten a lot of comments about "Oh my God! This is the first IPv6\\\indent botnet I've ever seen."\\
+\emph{sloth}: We are on the cutting edge of IRC flooding: we are pushing it into IPv6\\\indent and people just \bf{don't even know}\rm.
+% }}}
+% }}}
+% }}}
+% }}}
diff --git a/muhstik/cisco.txt b/muhstik/cisco.txt
@@ -0,0 +1,2641 @@
diff --git a/muhstik/ident.word b/muhstik/ident.word
@@ -0,0 +1,13581 @@
+EDY_19 Ne|nteresant 
+Eyy Geo_1
+v|rus mariol
+VYKOR_19 `
+Lyjea _
+Z|na rtxtos
+ _daissy_
+Elyy Geo_1
+kllklk r6