While in grad school, I was an "assistant" in a lab which contained two
pdp-11/23's running UNIX System 3. Much of my education came from
jokes played on me by my more knowledgeable friends. I'm sure I
deserved them; I was into writing multi-player games, and I got a
kick out of writing special caveats that only I knew about; these
caveats could give other players invisible handicaps. (Don't ask me
for the games; they're very terminal dependent and I don't even
know where they are anymore.) We once wrote a multi-player version
of Walter Bright's empire from scratch. I added H-bombs (like fighters,
but when they hit a city it goes neutral, and when they hit a neutral
city it goes away, etc) Only, the program was rigged so that when
a certain friend completed an H-bomb, he got this dialogue that ended
with the H-bomb developers testing the bomb in his own city! It was
VERY funny.
[1]
The lab contained two kinds of terminals; Zenith-something-or-other for
one pdp and TVI-something-or-other for the other. The console for each
pdp was some other type (e.g., vt100 or somesuch). I normally logged
in on a Zenith in a particular spot. One day my first attempt to login
failed and my second succeeded. I thought nothing of it, and continued.
Later, I happened to be on the console when I did a ps and noticed a
program running in the background belonging to one of my friends, B.
Although it was not uncommon for real work to be done this way (and the
program had an innocent sounding name), I poked around in B's directory
to see if I could figure out what it was doing (I was root; what a feeling
of power!). An ls revealed a very strange directory name; under that
directory lived some interesting looking programs and files.
It turned out that B had written one of those password-catching programs,
and had run it on my favorite terminal, apparently hoping that I'd login
as root there. The directory name was an escape sequence that caused
an "up-cursor, carriage-return", so an ls on a Zenith would overwrite
the funny directory name with the next file/directory. I had done the
ls on the console (different escape sequences) by pure luck.
I figured out the file in which B was writing the login name and password,
and replaced my login and password (yes, his program worked!) with:
"B is a bad boy". Eventually he came in. I casually asked him about
the background process, and he had a simple explanation ready. I then
left him to the "Zenith" room, and went to the adjoining "console" room
and waited. His reaction was quite rewarding.
[2]
B waited almost a year to try again, and this time he was nasty. I was
working on a huge program, a dbms, for my Master's thesis. I was having
some trouble debugging, and looking at the prospect of spending yet
another semester finishing it. During a particularly frustrating session,
another friend stopped in to mention that B had done something to my
..profile; I thanked him and checked it out.
It was a very subtle change; I don't remember how I happened to notice it.
My PATH was set with /usr/bin in front of /bin (default on our system was
/bin in front of /usr/bin). I looked at /usr/bin, and found an executable
cc, owned by B. Further exploration revealed that B had written new
read() and write() primitives; his cc arranged that the resulting a.out
would get the bogus primitives. These primitives read or wrote garbage
about 1/6 of the time. Can you imagine debugging a dbms with this handicap?
So, how to get back at him? I figured the first step was to pretend I
hadn't discovered his little trick, so I modified my makefile to run
/bin/cc directly. After a day or so, B stopped in to ask how I was doing,
and I told him everything was going well. He happened to notice my /bin/cc
lines, and asked why I did that. I told him I had some simple shell
scripts named "cc" scattered about, and didn't want to accidentally pick
one up (this was before aliases). He swallowed it.
The next day, /usr/bin had an executable make to go with the cc. B's make
made a backup copy of the makefile, changed all the /bin/cc's to /usr/bin/cc's,
and ran the real make; when the make finished, it moved the original makefile
back. I was amazed at the trouble he had gone to -- and got a good lesson
in shell programming as well!
