Denial of Passover
April 28, 2000
Hi all,
As some of you know and most of you don't, I have been in the Netherlands for a few days. Thank god most of you didn't know, because this Amsterdam-Bilthoven Thomer-Tour was almost more than I could handle. Don't be insulted if you were not one of the lucky few because my main purpose was to go home for Passover. (You know, Passover is that wild party where we celebrate the fact that we got kicked out of Egypt after 400 years of slavery and had to eat unleavened bread for a week and walk around the desert for another 40 years). Anyway, Passover passed over and I was lucky enough to see 14 family members (5 of which are younger than 13) plus one grandmother from Switzerland (one of which is younger than 77). In total I saw 31 people in 5 days. Man, was I glad to come back here. It was a trip with extreme highs and lows.
It was weird walking around in Amsterdam. I have no house, let alone a key to it. I somewhat felt like a tourist. At home, but estranged. I must have looked like a tourist too: I was watching and absorbing everything like I had never seen it before. You live in a funny country! Everything is so small and people are so blond! Our streets and our buildings are muuuuuch bigger!!!
I realized that I had totally idealized Amsterdam. It was not as pretty as I imagined it would be. Absence makes the heart grow fonder, you know. The same happened with some people who turned out to be really ugly in real life.
My flights were adventurous. Two out of four flights got canceled. My journey back was great, though. During my first flight to Newark and then to Boston I sat next to a nice young lady (a different one on each flight) who made time fly like an arrow and fruit flies like a banana.
Boston is different now. When I came back I couldn't decide whether or not I came FROM or TO home. I no longer feel like a stranger here, although the Star Market tried its share. Monday I was walking around looking for matzah, took a pack and carried it to the checkout. At the checkout I looked on the box. It said "not kosher for Passover". Writing that on a box of matzah seemed like an oxymoron to me, but oxymorons are not kosher either so I walked back and went looking for other matzas. None. I was stunned and so were the other insulted Jews looking at the empty shelves. We were all moaning and complaining when one of the ladies in the crowd of hungry desert people suddenly accuses me of being Dutch. Needless to say that I was deeply insulted. I vigorously tried to deny it, but it was a lost case; she was on to me. She then invited me for a Shabbat dinner at her place. Almost too cliché to be true, but I got picked up by a lady in the grocery store. Her fiancé sounded nice too. I just felt you were thinking about that.
It's Friday now, so I can report about the dinner. First I went to a Shabbat service with Beth (the lady who invited me) that has been quite different from what I am used to. It started when I came in: no chairs. People sat on cushions on the floor. Very sixties. The service started by lighting candles: not 2, but 7. During the blessing over the candles I thought I heard something strange, but I wasn't sure. As the service proceeded I got more and more confused, because the prayers just made no sense. When reading the Hebrew carefully I discovered that all mention of God was feminine! You have to know that Hebrew conjures verbs, nouns, adjectives and possessives differently based on gender. God, it was confusing. I know many prayers by heart, but I quickly lost ground. Then there was this problem that all mention of Abraham, Isaac, Jacob and Moses was followed by Sarah, Rebecca, Rachel and Miriam respectively. Also, every mention of God blessing the Jewish people was followed by "... and all other people on Earth". In short: very progressive, very reform but far away from what I am used to. On a rational level I agreed with everything, but it is just so different from what I am used to so I'm not sure if I'll go back there again. Oh, yes... This was the best: there is this song where the congregation welcomes Shabbat. It is a custom to open the door for 'the Shabbat bride' to (metaphorically) come in (or at least face the closed door when singing the prayer). They did it the hardcore way: they opened the door and went out on the street! No kidding. They left the room and proceeded singing the prayer outside! Anyway, after the service we all introduced ourselves which I really hate b-b-b-because I d-d-don't like to speak in groups. We stayed another 30 minutes for chit-chat. Then a few people (and I) went to Beth's house were she and her fiancé had prepared a great meal. I had fun. I felt really at home. Everybody was so nice. Jewish life in the US is happier than in Europe (not surprisingly) and less about having to prove ones own identity amongst "strangers" since so many people are Jewish here. It's just easier, more relaxed and no more or less than a simple part of American society.
And now for something completely different.
Computer programs are written by humans in a programming language. A programming language is a language just like English, but unambiguous (time flies like an arrow and fruit flies like a banana) and with less words. Unfortunately, the computer doesn't understand programming languages at all. You first have to 'compile' a program written in a programming language to turn it into something a computer understands. (Compilation is done by a so-called compiler which is just another computer program; who sees the paradox here?). In other words, there are always two copies of a program: one that a human can read but the computer can't and one that the computer can read (and run) and the human can't. Example: if I discover a 'bug' (error) in a program I make changes to the human-readable version (also called 'source code') and compile it again. The result of that compilation is the corrected version of the program that a computer can read. The computer-readable version of a program is called the 'executable'. I sometimes compare it to beefsteak and minced beef. Compiling a steak (i.e. pushing it through a mincer) turns it into minced beef. In this example the steak is the source code and the minced beef is the computer-readable program (executable). The reason why this meat comparison works so great is that, in both cases, the reverse is impossible: you can't turn minced beef into a steak by pulling it back through the meat grinder in reverse. The point is that you can never turn an executable into source code. This fact made matters worse for the Year-2000 problem. People made a mistake in software, which is bad enough on itself, but in many cases the programs were written so long ago that the source code got lost so that the error couldn't be corrected. The only thing they had was the executable (minced meat) which couldn't be turned into source code (beefsteak). Gee, I'm getting hungry.
I needed this whole story to tell you that I was looking through some source code that was written by someone else in my group and found some comments that I thought were funny. Comments are part of the source code that are only for human consumption. Computers ignore it when they compile the source code (the '//' characters at the start of each line tell the computer that it is a comment and not a part of the program itself).
Here goes:
// fuck, i don't know what the right thing is. ideally would
kill
// the signal handler and timer and cause run() to finish. will
// subclass destructors call this? fuck i am ignorant. if not,
// need a function like stop(), which subclass destructors must
// promis to call. but wait, we are singleton anyway. probably
// that is also a bad idea.
I rest my case.
As for Denial-of-Service: I am NOT working on it. I am NOT at MIT. I am NOT writing programs that try to stop DoS attacks. It's just NOT true.
Regards,
Thomer
P.S. I include a conversation that appeared on USENET recently, concerning breaking into computers and getting servers down. If you don't get it after reading part 3, then forget it. You have no humor. René will love this.
Subject: Re: Taking Down a server
From: "deltoid" <deltoid@dev.nul>
Newsgroups: alt.2600
"Derek" <d.rupe@gte.net> wrote in message news:38FA2E13.4C579626@gte.net...
>
> I have this desire to not just hack into a certain website, but to
> seriously take em down for as long as possible.
> What would be the best way to do this.
>
Derek, we all have that desire from time to time, and I completely understand your frustration. I made you a tutorial that explains how to do it.
----------8<--------------------8<----------
HOW TO GET SERVERS TO GO DOWN TUTORIAL
by P. R. Deltoid
Getting a server to go down is a very magical experience. There is much confusion about this topic on all of the Internet. Newcomers are commonly unaware that it is possible to get a server to go down. This tutorial aims to reduce some of the confusion, and offer a handful of techniques that are sure to get a server to go down.
PART 1: FIND OUT EVERYTHING YOU CAN ABOUT THE SERVER
That's right, you will need all sorts of information about the server. You can send queries to the server's peers to get a lot of useful data. The server will often be very good at hiding information that would make your job a lot easier, but the server's peers and "trusted connections" will often reveal this information to anyone. There is no set amount or type of information you will need to get, but every little bit will help you out later.
PART 2: MAKING THE CONNECTION
It is important when making your initial connection to the server that you don't let it know too much about yourself. Some people go to great lengths to conceal all true information regarding their identity. Try to make the connection when the server is otherwise not doing anything. This will enable you to have the full processing power at your disposal. It is essential that you make no mistakes during this phase, as a rejected connection spells disaster for the whole undertaking. If you get the server to accept the connection and acknowledge your queries, you are ready for the next stage of the undertaking: inspecting the system.
PART 3: INSPECTING THE SYSTEM
This is one of the most cherished parts of the process of getting a server to go down, and quite possibly the most enjoyed aspect of all server interactions. Your goal in this part is to look deeply at the server. Look into its ports. Look at the overall shape of the server. Study how it responds to your queries. You will gain an understanding of the server's internal structure, how it processes - or rejects - requests from you. The more you observe, you will probably begin to realize some of the server's weaknesses. Make note of them. The weaknesses you discover in this part will be used extensively in the next sections to essentially fool the server into granting your requests simply because of how you make them.
PART 4: ENTERING A TRUSTED CONNECTION
The benefits of forming a trusted connection with the server are many. First, the server will typically perform less validation and parameter checking on requests that originate from a trusted connection. This is often very useful in your attempts to compromise the server's security. Another benefit of forming a trusted connection is that if you do perform some type of action that the server considers to be unacceptable, you will be given more leniency. If an offensive action is attempted via a non-trusted connection, the server is likely to simply refuse connections from you in the future.
PART 5: VIOLATING THE SERVER
This is the last stage of progress leading to actually getting the server
to go down. This stage will serve to weaken the server's defenses, allowing
you to completely exploit it in the next part. Your goal here is to gain
complete control over the server. By the time this stage is done, you should
be able to at least do the following:
1. Cause an excitation state in the server's data socket
2. Insert arbitrary digits into the server's data socket buffer
3. Introduce your data packet into the socket
NOTE: Most servers have what is known as a 'back door.' Most of the time,
the server's creator reserves these back doors for specific purposes.
Although it is not essential to the task at hand, inserting your data packet
into the server's back door can prove to be an interesting process.
PART 6: GETTING THE SERVER TO GO DOWN
Finally, the objective is within your reach. If you have reached this stage, you will usually have no problem getting the server to go down. There are several distinct views on what is considered proper procedure and form for this stage. In any case, the goal is the same. We will cover only the two most popular approaches to the situation. The first approach is to wait for the server to initiate a connection from its audio (wav/out) port. This approach is generally the most safe, but the server will not always initiate such a connection. The other approach is to unexpectedly (not forcibly) insert your data packet into the server's audio (wav/out) port, thus forcing a connection. The server will sometimes issue a resync and terminate the port. If the server issues a resync, there is significant threat that you will not be able to retrieve your data member. If you use this approach, it is your responsibility to detect an imminent resync and automatically end the connection.
PART 7: CONCLUSION
Getting servers to go down is a very maturing process. Once you have a server go down on you, you will be forever changed. Some hackers like to have a server around their home, for no purpose other than 'experimenting' with them, and experiencing the true bliss of server fellatio on demand. Mature hackers, in their later years, will typically have several servers under their direct control. It is one of the most beautiful and mysterious activities you may ever know.