The magazine of the Melbourne PC User Group
Sticky Beak’s Wonderment
Hartmut Rabich

Forty years ago when I wrote my first programs for a very early computer everything was very casual: there were only typewritten instructions, the computer jobs were stored on paper tape, the operators fed the tapes manually into the machine, the very slow computer took minutes or even hours to complete a job and the output-data were again on paper tape, which had to be printed in a separate job by a teleprinter. We had to develop our own programs, chase errors and finally run the jobs with the appropriate data to evaluate our experiments. No one thought about privacy. Later the input tapes were replaced by cards, the outputs were changed to line printer listings: privacy was still no problem. But further improvements brought us the interactive terminals for input-output and the excellent possibility to keep the files stored on big disks.

Before, we sent the whole input file to the computer every time, but now we specified only corrections to the already stored file. Every programmer had to name his files with his initials. Most of the stored files were long columns of temperature, pressure, wind speed and similar data and hardly of interest to a private person, but some files contained sensitive data like half finished papers. Suddenly privacy was an issue: rumour had it that our computer operator who had installed and looked after the operating system had read other peoples' files so programmers like myself decided to play games, fooling him with bogus files. I wrote my first SCRAMBLER program and called my scrambled files xxxx.BIN (binary). Some time later everyone had to choose a password and use it during the LOGIN process.

The introduction of passwords had its peculiarities. The computer operator asked me what password I would wish him to put into the system for me. He added: "But - if you insist - you can press the keys yourself." I answered "I am quite happy if you do it for me", thinking that he as a privileged operator is able to read my files anyway - no matter if I allow it or not.

Immediately I planned to invent - if possible - a second (hidden) password the existence of which I would not reveal to anyone. This job turned out to be quite simple: (Our operating system was not written in DOS - but I will write my explanations in DOS language). It used the system prompt > in a canny way: The prompt tells the user that the operating system is ready to receive the next user instruction. As early as possible the file AUTOEXEC.BAT waited without any indication for the secret characters. If they were not given the batch file would branch into a dead-end looping.

AUTOEXEC (not the system) would offer a bogus system prompt > and repeat the given letters on the next line and offer the system-prompt on the following line again. The conversation could look like this:
>DIR
DIR
>TIME
TIME
>date
date
> ...

assuming that the intruder had typed: DIR TIME date etc. This worrying and frustrating cat and mouse game would be repeated about ten times after which the LOGIN was broken off regardlessly. This behaviour was really scary, as typing EXIT would not LOG OFF. I had added some actions behind the scene which made the operations even more worthwhile: all commands of the intruder (who had already passed the barrier of the first password) were copied into a prepared file TESTLOG together with all information that was available eg. the date and time and terminal number. If on the other hand I answered with the correct second password AUTOEXEC would take the following actions:

  • test the existence of the file TESTLOG
  • if positive: it would print it out
  • continue with the rest of AUTOEXEC
When I designed this "second password trap" I thought it would never happen: but I was wrong. On one afternoon around three o'clock TESTLOG was created, the untrustworthy privileged operator had passed on my first password without my knowledge or permission to someone else who tried to copy one of my files - although both people did know that a copy of this wanted file was already in a non-password-protected area. Some people have difficulty respecting other people's privacy. By the way: nobody ever talked to me about the strange behaviour of this particular LOGIN. Up till now I have kept quiet about this incidence.

This second password protected my files from access via LOGIN but not from the curiosity of the computer operator, who, with special privileges could read, write and delete any file on the disks. So I added another way of protection. Each file-listing of DOS contains only the date and time of the file creation or its updating. The file-listing of the computer of this story contained also the date and time of the last access, i.e. the last reading of the file. (The WINDOWS file systems with the long file names stores also the last access date but not its time.) The computer operator was the only member of our community who had a phone-line with modem connected to our computer and we did know that he used this means during the night to snoop around. So I prepared two programs which run as last program before LOGOFF and as the first program just after LOGIN: the first one wrote only a listing of all my present files, the other program
  1. wrote another similar listing
  2. run a special program that compared the two listings, took special note of the last access time and
  3. sounded alarm if a discrepancy was noted.
Does the reader think the alarm had a chance to ring? The reader may ask "Does an operation system need privileged operators?" Yes it does: it happens occasionally that one, two or more jobs interfere with each other in such a way that no or few useful calculations are done. Only someone with the detailed knowledge of the operation system can untangle the situation and he or she must be free of all restrictions. But this person must practice a moral standard.

About the Author
Hartmut Rabich, hartmut@melbpc.org.au likes the systematic structure of computer hardware and software and dislikes Microsoft.

Reprinted from the December 2002 issue of PC Update, the magazine of Melbourne PC User Group, Australia

[ About Melbourne PC User Group ]