While in grad school, I was an “assistant” in a lab which contained two pdp-11/23’s running UNIX System 2. 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.
 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.
 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!