# Softpanorama 91a (vol.9, No.2),
March-April, 1997

# Computer Humor

The Cuckoo's Egg by Cliff Stoll

Review picked up on the Internet
and adapted for alt.security
by Nikolai Bezroukov

The Cuckoo's Egg by Cliff Stoll is a book about a German student, a hacker actually. This hacker had a strange hobby breaking into military sites. Bad guys from KGB forced him to bring some US military documents. The hacker did not know that KGB guys already obtained everything they wanted using girls and vodka instead of Internet. These backward Russians usually rely on good old tricks. Anyway, even if they obtained something useful it was almost always lost in the huge bureaucratic machine KGB was, or left by drunken agents somewhere in the subway.

Cliff Stoll, an astronomer turned UNIX system administrator, (this kind of disaster happen with astronomers quite often nowadays) works at Lawrence Berkeley Lab. He was going over some problems when he found a 75-cent accounting error (girls should beware dating with former astronomers).

Cliff found a hacker on the system and alerted the CIA/FBI. Since no one would listen to him because the hacker hadn't stolen more than a million dollars or "How to make an A-bomb" FAQ, he started his investigation alone. Cliff hooked up his computer, so that every time the hacker logged on, his beeper would ring. He tried to imitate Sherlock Holms and even get a logbook which he put all his information in. Now when his PC was hooked he could not play Red Alert in his working hours anymore. That made him uncomfortable and he tried to pursue the hacker with double energy.

At last the hacker broke in again and tried to log on by using stolen passwords. This was the day Cliff was waiting for. The FBI/CIA was finally interested, but they only took information from Cliff, never giving any back. They never treated him well and Cliff was always left out in the cold in his own investigation. They traced the hacker throughout the globe and eventually discovered that he was somewhere in Germany.

Since the hacker always tried to get documents from army bases, Cliff made up hundreds of fake military documents and planted them in the computer. Imitating military documents was a very difficult job, (most of them are usually so stupid). But Cliff was diligent and worked around the clock. Some of these documents were actually much better than the real.

The hacker was delighted to get Cliff's documents and sent Cliff a letter asking for more information. Unfortunately, it was intercepted first by FBI and then had found its way to CIA. Bad guys from FBI/CIA didn't let poor Cliff to know who the hacker was and why he was doing this. Cliff had no choice but to follow their instructions. He felt like a pawn.

All in all, he had spent the whole year chasing the hacker. With a miserable result of some fuzzy links to the hacker instead of his own planet. Tragically he was unable to go back to astronomy and even to UNIX system administration. All he wanted was to be interviewed or to chase other hackers. Basically he sacrificed his love life and his job at the Lawrence Berkeley Lab. Now he was good only for interviews. He will never discover a new planet. His beeper always rang when he was with his girlfriend, and eventually she got really mad at him. His life and his career were ruined and out of desperation he became a security consultant.

The main idea of the book is that every time the hacker went onto the Internet and wrote a program, it was like a cuckoo laying an egg. Each time the hacker would lay his egg and leave it to Cliff to hatch. And after hatching several eggs it's too easy to became a kind of cuckoo and start to give interview after interview. It's a darker side of the story. On a positive side the book could serve as a warning for young people. It teaches us that could happen when some people have too much zeal in catching a hacker and especially in giving interviews. Like in stock trading, too much zeal in interviews make them no good.

Anyway, you never know who is who on the Internet.

6/2/97 3:42 PM

Newsgroups: rec.humor.funny
From: ms0p+@andrew.cmu.edu (Michael Gordon Shapiro)
Date: 2 Apr 91 11:30:03 GMT
Keywords: computer, smirk
From www.castle.net/~tina/computer.html -- Computer Jokes

## How to program in "C"

(Left on the blackboard by students in a Real-Time Systems course)

1. Use lots of global variables.
2. Give them cryptic names such as: X27, a_gcl, or Horace.
3. Put everything in one large .h file.
4. Implement the entire project at once.
5. Use macros and #defines to emulate Pascal.
6. Assume the compiler takes care of all the little details you didn't quite understand.

"It's 5:50 a.m., Do you know where your stack pointer is?"

[ No, and my program doesn't, either! ]

### How to debug a "C" program.

1. If at all possible, don't. Let someone else do it.
2. Change majors.
3. Insert/remove blank lines at random spots, re-compile, and excecute.
4. Throw holy water on the terminal.
5. Dial 911 and scream.
6. There is rumour that "printf" is useful, but this is probably unfounded.
7. Port everything to CP/M.
8. If it still doesn't work, re-write it in assembler. If this won't fix the bug, then it will make sure no one else finds it and makes you look bad.

The recent submission of "How to program in C" left out some very important rules.

I have come up with the following list of additional rules in order to give the serious student some aid and the professional a refresher.

### How to program in 'C' - addendum

1. Rewrite standard functions and give them your own obscure names.
2. Use obscure, proprietary, non-portable, compiled library packages so that you never have to move from the platform you love so well.
3. Use very descriptive comments like /* printf("Hello world\n"); */ before each function call.
4. REMEMBER - Carriage returns are for weenies. Tabs are for those who have not reached weenie-dom yet.
5. Include LOTS of inline assembly code.
6. "User Interfaces" are for morons. "Users" have no business interfacing with a professional product like yours.
7. If you are forced to comment your code (in English), then borrow comments from somebody else's code and sprinkle them throughout yours. It's quick, easy, and fun to watch people's expressions as they try to figure it out.
8. Remember to define as many pre-processor symbols as possible in terms of already defined symbols. This is considered 'efficient use of code'.

### How to debug a 'C' program - addendum

1. Since you got it to compile, the problem must be in the Other Guys Code.
2. If it's all your code then the problem MUST be in those unreliable Standard Libraries. See '1.' in the previous section.
3. Claim the bug reports are viscious lies meant to tarnish your sterling reputation as a 'C' programmer (well aren't they?). After all, those who wrote the reports couldn't even read your code. How could they possibly know if there was a bug or not?
4. If they could read your code, review "How to program in 'C'", above.
5. Claim that there wouldn't be a problem if this stingy Company/School/Wife/etc would spring for a copy of C++.

Note: If you still have a Job/Degree objective/Wife/Mind/etc after utilizing the above rules then you simply aren't trying hard enough.

See also Tina's Humor Archives main page