On 26 November 1997, freezing cold and his monochrome 486/66 plugged in, |ncubuX decided his mates on the BBS needed a networking guide. Not a dry, clinical one — one full of X-DDDDDDDDDDDDD, swearing, and the bar-toilet analogy to explain the TCP protocol. Three chapters were promised. This is the first. It's translated here as faithfully as possible from the Word 7.0 original — typos, run-on sentences and all — without polishing a single joke.
01 — Introduction
Setabia's Hell presents...
-| The Kus |-
Attack & Defense by the balls
by |ncubux
Started on 26 November 1.997
Freezing cold, on a monochrome 486/66
with Win95 and Word 7.0 (Now THAT takes balls X-DDDDDDD)
By the way... hoping some background comes out in colour X-DDDDDDDDDD
[ Photos of Sifer buck naked, with Glor ]
· This text is meant to be one of those FAQs you find floating around out there, but I'm hoping it turns out fairly long and actually useful for something. Everything I talk about here comes from experience, tried and tested (most of the time), loads of times. I'm not claiming it's a one-of-a-kind document (mostly because the way I write wouldn't let me pull that off X-DDDDDDDDDDDDDD), so as further reading I'd recommend you don't bother reading much more of this unless you're going to get into programming. If all you want is to know the defences you can use to browse/chat safely... you barely need to read anything... if you want to attack without knowing how what you're doing actually works... you don't need to read much either... if you want to program, read the whole document front to back and while you're at it, grab the RFCs for IP, ICMP, UDP etc.... and if you want to attack and defend like an absolute champion, you don't even need to touch any code, but you do need to know what each thing does, what the flaws are, and above all, how each protocol works... the more you know about all this... the fewer enemies you'll have left >;)
· It's well known by people who know their stuff (God, what a mouthful) that there's plenty of "lamers" wandering around who haven't got a clue about anything and go around shooting their mouths off, scaring the crap out of everyone and getting in far too many people's faces. I remember about a year and a half ago when I got into networking... everything looked far too murky for a self-taught guy... you don't know where to start... what software do I need?... what protocol does this use?... how the hell does this work under DOS?... are these drivers I've got here even standard?... Anyway... the truth is I was all over the place, bouncing from one thing to another... net.exe, lsl, packet drivers and a million other bits and pieces, and if it hadn't been for an old BBS acquaintance (JRL) who told me what I needed, and someone I don't even know who uploaded a "kit" for playing Doom over a network (and that's where lsl and ipxodi came from), I'd still be flailing around like a clueless muppet... so what the hell is all this leading up to?... well, because I want this little text to debunk a load of nonsense that gets said about the internet, and to confirm other stuff that, however unbelievable it sounds, is actually true (I confess that before I got into writing internet programs, I didn't believe half of it myself). I also want it to help you defend yourselves, and to attack too... obviously C:)
· I don't know whether to assume you all already know what a packet is, or even a plain byte... anyway... you can keep reading straight through to the attack and defence sections and skip the bits about how those attacks/defences actually work. You'll get a lot more out of it if you already know a bit about the subject (mostly because I'm a worse teacher than Kyrenee is at knitting).
· Right then... here we go...
02 — What is this Internet thing I've got at home?
· Right... when people get asked this, they answer that the Internet is basically a shedload of computers plugged together... and that's that. And yeah, the internet is exactly that... a bunch of boxes that talk to each other using a protocol (IP – Internet Protocol).
IPs
Every box (every node, or client/server, whichever) has a "name"... (because that's what the IP protocol demands) a unique address on a network... this is what's usually called an IP address, which you've all seen at some point: 192.1.1.7, 194.100.1.25 etc. etc. Every IP has a matching ASCII name... for example... at my place, the PC with IP 190.1.1.1 is called "Office", the 486/66 I'm typing this on right now is 190.1.1.2 and is called "Office2"... This name is called a "host"... and the name for your own box is what's called "localhost". On the internet they tend to be a bit longer, something like "ppp852.redestb.21" or similar... though honestly it doesn't matter much, since you can refer to a computer either by its IP or by its host name.
DNSs
· If you remember when you first got the internet set up at home, you had to enter the DNS settings... what the hell is that, you ask?... it's pretty simple, really... when you want to go to a page, say www.microsoft.com/dsks/win32s, your machine doesn't know Microsoft's server's IP... so the system takes care of sending www.microsoft.com to your DNS server (because that's the host) and the DNS server hands you back, at that exact moment, Microsoft's server IP, let's say 232.130.22.12... Then your browser connects to 232.130.22.12 over a TCP port (25 for HTTP)... and following whatever protocol HTTP uses (I'll admit I don't know that bit too well :))))... your browser asks 232.130.22.12 for the document /dsks/win32s.
· Why do you need a DNS server at all?... very simple, because the internet is always changing, servers' IPs aren't always the same, so you need them kept up to date somewhere.
· Another practical example... you connect with mIRC to the server eu.undernet.org on port 6667... since you can't put names (hosts) inside an IP packet... you need to work out the IP for eu.undernet.org... You call your DNS server and ask about that host... and the server hands you back, say, 212.124.234.142... your IRC client (mIRC in this case) grabs that IP, converts it into an IP-long... sticks it into the IP packet (the one that's about to be sent), sets up the packet and requests a connection to 6667 (for example).
03 — IP-long, your ISP, and how computers actually connect
So what's an IP-long then? (skip this bit entirely if you don't code)
· You'll have noticed that IPs written in ASCII are pretty long, and the numbers in them are always 4 groups, each below 256... the IP-long is simply the conversion from ASCII into a 4-byte long integer (a "long"). Also, the least significant number goes first. That way, instead of taking up 15 or 16 bytes per IP inside a packet, you only need 4 :)))
Okay, okay, okay... but doesn't my internet provider (ISP) do anything else?
· Your internet provider handles giving you a bunch of things (normally, of course):
- The most important thing: they give you an IP (a different one every time you connect, obviously) and they give you access to the network, meaning you become just another node on the big network... like you were one of the big servers, only tiny.
- A mail service... this keeps a client/server permanently switched on and connected, where the messages people send you land. Naturally it also has its own host/IP... for example on Redestb there's pop3.redestb.es: when people send you mail, it comes in through here, and smtp.redestb.es (when you send mail, it goes out through here... it also has its own IP, obviously).
- A news service... I don't actually know exactly how this one works, but they also offer you a news server... which you connect to on port 119 (that's how it is on news.redestb.es), but I genuinely have no idea how it picks up the messages, where it gets them from, or how it sends them out... so don't ask me.
- Loads of providers advertise IRC as one of their services... which is a bit daft, really, since if you've got an IP, you can connect to any server you fancy (that'll let you in, obviously).
Okay... lots of talk about "connecting", but I still don't know how the boxes actually connect...
· For a connection between two computers to happen, you need two things: some physical medium to fling the data down and have it actually arrive at the other end... and the second thing is a protocol... a protocol is nothing more and nothing less than the set of rules both sides have to follow to pull off a connection... for example, say you're in a bar, busting for a shit, but it turns out the toilet has a sign on it saying "Ask the barman for the key"... well then... if you want to go (connect)... you have to send the barman a message (a packet) in a very particular way. The main protocol here is going to be speech (which, in the internet's case, is IP):
a) Which sub-protocol are we using? – Good manners –> "Hi, good morning" (TCP)
b) Message type: Urgent, I'm about to shit myself -> "I'm in a bit of a hurry" (OOB)
c) Message length: short, I need to go NOW -> "I'll keep it brief" (56 bytes)
d) Message: "Right then, I want the key, for god's sake" (blalbllblallbllalblallblallbalblla)
· Getting a bit more practical now... here's the header of an IP packet (the header is, let's say, everything we write on an envelope so a letter reaches who we want it to, and gets there under the conditions we want). We've already said the main internet protocol is IP... ALL the other protocols (TCP, ICMP and UDP above all) ride on top of IP... and the vast majority of protocols also ride on top of TCP in turn (think the IRC protocol, FTP, HTTP etc. etc. etc). If anyone's already lost, drop a mail to setahell@redestb.es
04 — The IP header
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL | Type of servi | Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Header
· It's 'copied' from the IP RFC... RFCs are a ton (AN ABSOLUTE SHITLOAD!) of documents used to nail down standards on the internet... they're completely essential if you want to understand how everything works, and even more so if you're a programmer ;))). (each + is one bit)
· This header is what reaches the gateways (basically... the little "traffic lights" that route every packet all over the network) and the final destination.
· Let me run through the fields, briefly:
- Version: this is the version of the internet header you're using... in case the IP spec changes in the future... so programs only need a small tweak. (We've been stuck on version 4 since 1981)
- IHL: an important one, the number of Dwords in the header, i.e. how many "32-bit" blocks the header has... most commonly it's 5 (20 bytes)
- Type of service: a bunch of flags (options, basically) for the gateways to use... among them: High speed (queue priority) or High reliability (a security matter).
- Total length: the total length of the packet... an IP packet can be up to 64Kb. There's one thing you need to bear in mind... the IP protocol allows messages to be split into little chunks... meaning that if you send a 64Kb block, there's a 100% chance it'll get broken into pieces... and each little piece makes its own way to the final destination... All IP clients should be able to reassemble the pieces, but if one of them can't... a special flag has to be used, "DF -> don't fragment"... although in my experience... every gateway just tells that flag to get stuffed, splits the packet anyway and sends you back an ICMP saying "the packet that couldn't be fragmented (with DF set to 1) wasn't sent because it needed fragmenting". It's important to understand why fragmentation exists... given that there's a shedload of us on the network... if everyone sent 65Kb packets, it would crawl along at a snail's pace because we'd choke the lines completely... normally, gateways tend to fragment starting from 576 bytes, or from 4096 bytes (sounds tiny, but it's pretty quick) and on local networks with W95, it's almost always a first fragment of 576 and the rest at 4096 (I've measured this myself, but I don't know if it's always the case). Whether a gateway fragments or not depends on what's called the MTU (how many bytes the next network hop can handle, per packet)... if it does fragment, it always sends the biggest packets first... and leaves the smallest one for last. When reassembling... the packet pieces need to match on identification, protocol, source IP and destination IP... otherwise... the packet just gets dropped. The fact that only those 4 things get checked when reassembling has allowed for some rather handy little flaws... we'll get to that, oh yes ;)))
- Identification: here you put whatever number you fancy, it's only there so that when reassembling the pieces, you know which packet each one belongs to.
- Flags: there are 3 flags here: Don't fragment / fragment, one reserved bit, and one for First fragment / Last fragment.
- Time: the famous TTL... the TTL (Time To Live) is how long this packet is allowed to keep bouncing around the internet... anywhere from 1 to 255 seconds... at 255 seconds, whether or not it's reached its destination... a gateway will destroy it. It's also mandatory for every gateway to decrement the TTL by 1.
- Protocol: one of the strong points of IP... here you specify what type of header is going to follow the IP header... for example 1 for ICMP, 6 for TCP, 0 to do whatever the hell you feel like, etc. :))))
- Checksum: the sum of every word in the header (16-bit words). Since the checksum itself is also part of the header, for the purposes of summing its own 16 bits... those are treated as if they were all set to 0.
- Source and destination address: sounds a bit obvious, but the destination address is where the gateways will carry this message to... and the source is only really there so the other end knows who's "talking" to them, and so the gateways can send you error messages back if something's gone wrong. (We'll talk more about these error messages shortly).
- Options: options have a variable size depending on the type of option you stick in... there's loads of them so I'm not going to go through them all, but for example you can flag the security level of the message, or how you want it routed... anyway... another field I always end up just setting to 0 X-DDDD.
- Padding: since the IHL can only hold whole numbers, the header value has to land on a multiple of 32 bits... so you have to pad it out if it doesn't reach the next multiple (20 bytes -> 24 bytes etc.)
- And naturally: THE DATA! :)))))) Since we're sending this whole chunk of a header for a reason, something's got to go after it, right??... Well... if you're not using any other protocol on top, your data goes right here... and it'll arrive at whatever IP you put in "destination address", assuming everything's fine and you put a 0 in "protocol"... If you're using another protocol (which is almost always the case, if not always) like TCP or ICMP, that protocol's header comes next... meaning the TCP/ICMP/UDP header starts exactly where we are right now... at DATA. Later on we'll talk (or rather, I will) about each protocol (useful and famous X-D) in more depth.
Bloody hell mate... you owe me a chamomile tea... my head's killing me X-DDDDDDDD
· Maybe it's best if we leave it there for now, eh? >;)
05 — TCP and its business
Okay, fine... I get how to send a message... but... hang on, then what the hell are ports like 25, 113, 6667 and all the others I keep seeing actually for?
· Right, well... it turns out all we've managed so far is getting a packet to arrive at some bloke's box (God, and here's a bloke who didn't get a single packet when he was born, eh???... X-DDDDDD... (sorry mum)). Now... so the internet wouldn't be a total jungle, several "standard" protocols were created... those were ICMP and TCP. Let's start with TCP. TCP, broadly speaking, is a fully reliable connection... meaning... if the packet doesn't arrive for whatever quirk of fate, or some data got changed, or anything at all goes wrong... the gateways and clients have to sort it out entirely on their own, without dragging the program that's using TCP into it at all. In TCP, to make a connection... you have to send an IP packet with a TCP header stuck behind it... and in that header you need to state the port where the other end is going to be waiting for our call... (don't you go getting scaaaaared). If I send a message to a server, and that server does both FTP and Web... how the hell is it supposed to know whether what I'm asking for is FTP or HTTP???... well, it's dead simple... some standard numbers get set up... 21 for FTP, 25 for HTTP, and loads of others we'll get to. So the server sits there listening for messages that come in with the remote port set to 21 or 25 (and everything else... it doesn't give a damn about, though it does still receive it). This is what's called "listening", or "listen" in Yankee-speak. Meaning... if I want to make a connection to the FTP server at 192.1.1.7... I need to put into the IP header... destination IP 192.1.1.7... source IP: whatever mine happens to be at that moment... protocol: 6 (TCP). In the data, I'll place the TCP header (which we'll look at shortly) and in the IP header we tell it we want to connect to its port 21 (remote port=21). TCP is a two-way communication, meaning... when I connect to its port 21, the other computer might refuse to let me connect, or it might let me in. If it does let me connect... the other computer needs to know which port I'll be listening on for its messages... which is why in our header we'll add a "Local port"... whatever port we fancy (that way any messages that arrive on this port, we'll know are replies coming from the FTP server)... heh... and also because whoever wrote the protocol (TCP) said it had to be that way, and that's just how it is :))))))))
· Goes without saying that if you're going to code anything for the internet... go dig up the RFCs yourselves... or ask me for them, and I'll send them over.
Ahhhh... hang on... so what does the TCP header look like? Tell me more little TCP things...
· As I said before, the TCP header comes right after the IP header (where the data would be if you were sending a packet with protocol=0). The program receiving the packet will know where the TCP header sits, because it knows the length of the IP header (the header length does NOT include the data) and it'll know it's TCP because IPHeader.protocol will hold a 6.
· Why use TCP at all?... very simple... TCP allows for very secure connections, since the data that arrives is exactly what the other side sent... duplicate packets aren't allowed through, nor are packets with errors... packets can be fragmented without "anything" important happening, connections can pause and pick back up... anyway... a whole load of reasons.
· When someone sends a message over TCP, they sit there waiting for an ACK (acknowledge, or something like that... basically, "all good"). If that ACK doesn't arrive within a set time... the message gets resent. Every fragment has a sequence number... and thanks to that number, the pieces get reassembled while damaged duplicates get thrown out (if there are any... they get spotted quickly, since they're assumed to be damaged, and TCP tacks a checksum onto every fragment).
· Besides the reliability... TCP is brilliant for another reason too... you can control how many bytes you want to receive in the next packet. When you send an ACK saying you've correctly received the last one... you can also send the byte size you want to receive next time round.
· What's called multiplexing in TCP... is nothing more than being able to use 0FFFFh (65536) ports per IP (which I reckon is more than eeeeenough, don't youuuu think??? >;)))). This is the local port and remote port thing I told you about earlier.
· Another lovely thing about TCP is that a handshake happens both at the start and the end of the connection... so if the connection gets closed... whoever's closing it gives notice... and without having to sit around waiting for a timeout (with the other side doing nothing for X amount of time)... you free up the memory and resources you were using for that connection. When it comes to doing the handshake (and yes, you do have to do it by hand, sod it)... it happens in 3 steps:
- At the start, the sending socket (a socket is, let's say, a little gadget that uses a TCP port for something... sending, receiving... or for nothing at all! :))) needs to be closed... while the one about to receive the connection is listening.
- The sending socket sends a SYN (a bit inside the TCP header), and the other end receives it. That other end then sends back to the first one an ACK (another bit: all went fine), a SYN-RCV (another bit, saying it received the SYN... SYN is used to kick off the conversation), and an ACK number (whatever it fancies)
- The first one, to signal it's received the SYN-RCV, sends as its SEQ (message number) the number the other side had previously sent in its ACK, and sends across another ACK number.
- The second one receives this... and at that point the conversation is considered started. Data can now be sent.
· Knowing how this works might seem like overkill, but it's essential if you want to make TCP connections at a low level (without using library functions and the like)... and to understand how certain weapons work ;))))))).
· We'll talk about actual programming another time... though I don't think that's really what this FAQ is about... although, truth be told, I've been writing this for a couple of hours now and it feels like all I've talked about is programming... I'm hoping you're all still with me up to this point, because if not, none of you are going to stick around any longer.
06 — ICMP and UDP
Hang on... didn't you say something about ICMP earlier?
· Yep, you heard right... ICMP is a protocol developed alongside IP... but it works like TCP... meaning... it has its own header... and that sits inside the IP packet's data portion. ICMP is protocol number 1 (not because it's the best X-DDD... but because you have to put a 1 in the "protocol" field of the IP header). It's the error-control and routing protocol... yeah, I know that sounds like gibberish, in fact I won't even bother giving you the English name for it. ICMP is used between host and host, and between gateways and hosts. Most commonly it's only used between hosts... but it's also handy for gateways. One important thing needs saying: ICMP messages have absolutely no reliability guarantees whatsoever... meaning... if they get lost on the network, no big deal, if the information gets corrupted, tough luck, etc. etc...
· When's ICMP used?... it tends to get used by the lower-level implementations on hosts (for example on Win95... everything that wsock32.dll sits on top of)... or when a gateway detects an error, or has a suggestion about routing. A gateway can send an ICMP message to a host if it sees that the route the packet is about to take through itself is longer than going via another gateway. It can also send an ICMP if the network happens to have dropped at that moment, etc. etc. The most common case for ICMP messages tends to be pings (both the replies and the original message are ICMP messages)... not the mIRC ones, the ones where you ping an IP... if you don't know what a ping is, I'll explain it later. Another common case is a host sending another host an ICMP because the second one asked the first for a connection to a UDP port that doesn't exist, or because it tried to connect using a protocol it doesn't support. A few interesting attacks are based on ICMP (nuke, echo-flood, reply attacks against multiple servers, etc... we'll cover all of this later on).
· Right... on to the ICMP header... this one's small but effective:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Previous internet header + 64 BITS of original data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
· This is the standard header layout... for each type of ICMP message, the header can change a little bit (we're not going to go through every single case, that's what the RFC is for). For example... type 3 means that for one reason or another, the packet failed to reach its destination. The reasons are dictated (God, what a fancy word X-DDDDDDDDDD) by the "code" byte... if the type is 3, the reasons can be (depending on "code")
0 = Network not found 1 = Host not found 2 = Protocol not found 3 = Port not found 4 = I need to fragment the packet, and "don't frag" is set to 1 5 = Route not found
· There's another very common "type", the ping one (echo request and echo reply)... the request is the ping request and the reply is the host's answer to that ping. Type is 8 for the request and 0 for the reply. Code is always 0. The header's different here... a sequence number and an ID get added (like in TCP) so you can tell which request each reply you receive actually belongs to. Ah!... you can also send data along with the request. This matters a lot, because Echo flood is based on firing off huge echo-requests by the truckload... and, for example, ssping / jolt / Ping of Death (they're all the same thing really) are based on sending an oversized ping (over 64kb... how? we'll get into that later. Hehehehhehehhehe).
· There's not much more to say about ICMP... the only other thing worth mentioning is that the checksum is calculated the same way as IP's, treating the checksum field itself as if it were set to 0. And that the previous IP header plus the 8 bytes that follow (64 bits) can be quite important if used cleverly... see Nuke (not the OOB one) >;)))) Oh... and that when a packet travelling across the network runs out of TTL (hits 0), you get an ICMP sent back telling you it timed out. That's all on ICMP for now.
Earlier you said another important protocol was UDP, right?
· Yep-ers... UDP is a tiiiiiiny little protocol, but people use it anyway... it has no error control... actually, truth is it has pretty much nothing at all, the only thing it has is ports, yeah, just like TCP's, except there's no handshake, nothing of the sort, you simply listen on a port and if a UDP packet turns up, congratulations... and if it doesn't turn up... well, nothing... nothing happens :)))))
· "Bloody hell, so what's the big deal then?" – you'll be asking. Well, it's got several important things going for it... first off, it's very widely used, and when it comes to coding, you've got loads of libraries and stuff for working with UDP. The advantage is it's fast. The downside is you can only send 8Kb at a time (these are called datagrams... I believe UDP is something like User Datagram Protocol). And the biggest advantage is there's no way to see which UDP packets are coming in on port 7 (the UDP one) under Win95, so it's dead easy to write a program that floods someone right off the network, simply by firing off hundreds of little 8Kb packets at port 7. If you use a different port, you'll just get an ICMP back telling you the port doesn't exist... so at that point you'll both end up flooded :))))))) There's also one more important thing (although I have NO experience with it myself)... which is that I know there's a very fast file-transfer protocol that runs over UDP... but that's all I know :))
07 — End of Chapter I and thanks
End of Chapter I...
I hope you're all still standing by this point, because in the next chapter we'll be moving on to the akction... meaning I'll walk you through every security flaw (how they work, how they're coded, etc.), how they can be exploited, how to wreck someone who's getting on your nerves, how to patch yourself up, how to defend against someone, and a thousand other things. Unavoidably, the next chapter is going to be mostly about IRC... the third chapter will be purely for programmers, pointing out references, links, documentation, libraries etc, for coding under Windowzzz... I don't think it's shown much so far, but whatever anyone says, I hate Linux, I'd rather my box crash 20 times a day and run 20 times slower than on Linuz, but at least I can get something useful done with it... shame DOS is going down the drain :((((
Thanks (oh go on then >;)
To my mum for making me a hot chocolate that'll blow your mind while I was writing this X-DDDDDDDDD (better than the one from Impor X-DDDDDDD), to Kyrenee for a suggestion called Kutuskus (and for a thousand other things too, obviously), to ^|mportao for getting all of us hooked on IRC (and for another thousand things besides), to Glor because I wouldn't have learned even half of what I know about the internet without him (it's either laugh about it or let the bad mood get to me X-DDDDDDDDDDDDDDDDDD), to Michel Izquierdo for giving a 2400 modem a chance, to Paco Belle for the same but with a 33600 :))))))))) (maaaate, we really need to meet up at one of the get-togethers, eh!!! >;))). To JR Laguardia because, believe it or not, if it hadn't been for him, I'd never have gotten into networking at all, to everyone from #deusto and #fontecada (there's so many of you lot that I've just about filled the whole page X-DDDDDDDDDDDD), to Jon Postel for making genuinely manageable RFCs possible, to the people who made Winsock possible, and lastly to Walt Howard for building a genuinely brilliant DLL and releasing it as freeware with source, and of course to everyone else, not that I'm forgetting anyone, it's just that I've been at this document for 4 hours now and I'm knackered describing things, blimey!!! X-DDDDDDDD)... oh!!!... and MS for making such a slow OS... cheers!... without Win95, writing a document in Word 7 wouldn't be a challenge for my monochrome 486/66, cheers!!! X-DDDDDDDDDDDDDDDDDD... hell, and I'm writing Kutuskus 2.0 on that very same box... daaaaad, let me use the Pentiuuuum X-DDDDDDDDDDDD
Liability and other bullshit
Meeeee?? Noooooone whatsoever!!!!!!!! :)))))))))))))....... every trademark belongs to its respective owner and whatever evil, wicked thing I show you here, well, that's between each of you and your own conscience (I'm losing my patieeeeeence X-DDDDDDDDDDDDDDDDDD)
— |ncubuX / Setabia's Hell, 1.997. No copyright whatsoever, naturally.