First a disclaimer: What I'm writing here now is related to events that happened a long time ago, at a period of time when it was relatively safe to do it, the worse that could happen would have been the expulsion from the school. If you try to do this kind of thing now, you may very well do some jail time and have heavy fines to pay as well.

---

Up the ante

I wrote in the previous part there would be two parts, but considering that I miserably failed at writing, reviewing and publishing some of my longer essays, I decided that writing instead few short ones each dedicated to a particular issue would be more manageable. So here we are, expect at least a third one :)

The previous episode happened during the last year I spent in High School, this one happened three years later when I moved to Laval for my BTS Informatique de Gestion. The year is 1991¹, the place is the Lycée Douanier-Rousseau, a pretty Ok place to be considering how boring² Laval can be.

Know your enemy

In 1991, I had some serious business to finish: My demo group was working hard on finishing the Phaleon Gigademo, the biggest Atari ST demo project ever started at the time.

We were still thinking that PC sucked, so I did all my programming on the Atari ST, including the required Turbo Pascal assignments. Unfortunately Turbo Pascal was not yet available on the Atari ST at this time, so I had to hack around: A bit of GFA Basic to write a GfaToPascal converter, and PC Ditto³ to compile the generated code. Not particularly fast, but it worked: This took care of the need for a PC at home.

The real challenge was yet to come, I had to survive the school environment itself.

Unix for the poor

The description of the equipment owned by the Lycée made by the director was quite appealing: They had a IBM RS/6000 "mainframe" with twenty high resolution terminals and all the necessary IBM and Oracle software available for the students.

Technically, it was not really a lie. They really had a RS/6000 and twenty terminals, but as usual, the devil is in the details: The server machine had only four megabytes of memory⁴, barely enough to run at full speed when more than few of the terminals were being used to compile code. The terminals were IBM PS/2 workstations, with monochrome screens and Hercules graphics - there goes the high definition - using a IBM terminal emulator to log on the Unix machine.

The real problem came from the usage conditions imposed by the teacher: We were not authorized to install any software on the workstations, and all the source code had to be present on the Unix server on our server accounts, so we had to be logged in and use VI to edit the COBOL source code.

I don't know if you ever programmed in COBOL, but if you don't, all you need to know is that this language dates from the punch cards, and inherited from that some peculiarities concerning the formatting. Some instructions have to start at particular columns, if you don't respect them the program does not compile. VI is definitely not the kind of text editor you want to use for that. What you want is something like the editor of the Turbo Pascal!

Creative thinking

If I was able to use the GFA Basic to program in Turbo Pascal, it was probably possible to use the Turbo Pascal to write COBOL.

Of course there was a number of issues:

• since the teacher was going around the room to look at what we did, I had to find a way to make it look like I was indeed working on the Unix machine with VI.
  
• there was no way I could manage to run the Turbo Pascal from a floppy disk without being detected, so the software had to be installed somewhere on the PC. Actually on all of them, because we had floating seats, no guarantee I could use the same machine two days in a row.
  
• the installed software had to be hidden in some way, the teacher told us she was regularly scanning for pirated software on the machine.
  
• swapping between a DOS editor and a Unix machine involves some problems like incompatible carriage return conventions. Had to handle that.
  

One of the advantages of having the complete official documentation of the operating system and accompanying software freely available to students is that you could learn the whole system to the point where you could get very creative very fast ⁵.

By reading it, I learned that it was possible to quickly swap between DOS and AIX sessions by calling some simple batch commands. Some keyboard short-cut bindings later and I was able to instantaneously swap my screen between the two sessions: the teacher would not be able to surprise me. I also found all the necessary information to transfer files between the two systems, including the format conversion. That was all I needed to copy the source code from the Turbo Pascal to the Unix machine.

I did all that during a week-end, telling my teacher that since I had no PC at home I had to use a PS/2 machine to do my Turbo Pascal homework. Instead I prepared my development environment prototype: After few hours of tweaking I was able to edit a source code in the Turbo Pascal editor, and by pressing a single keystroke it would save the file, convert it to the Unix format, transfer it to my user account, call the COBOL compiler, and go back to the Turbo Pascal editor while the program compiled in the background. Another key-press and I was able to switch back to Unix to check the status of the build.

I still had to find a way to hide all my system and manage to access it from every machine.

Messed DOS

The solution I choose was to modify the operating system on the terminal machines in such a way that it would not be possible to use the standard commands of the operating system to locate what I wanted to hide.

During the previous holidays I tricked a friend of mine: I wrote a custom version of the DIR command which would most of the time behave normally but from time to time would just do weird things like swapping the case of characters or display the numerical values in binary instead of decimal. He really freaked out and thought his pc was infected by a virus, thankfully he told me about it before he actually proceed to reformatting and installing everything: no harm done!

How did I do that? Well, that was pretty low tech.

MS-DOS contains a program called COMMAND.COM responsible for handling the command prompt: When the user enters a command this program will decide what to do. Some of the commands are detected as internal commands (like DIR) because they are very frequently used. The less frequently used commands are called external, and map to a number of executable programs, one per command. If the user types something which is not recognized as either an internal or external command, an error message is displayed.

What I did was very simple: I wrote small programs - each of these was given the name of an existing command - and modified COMMAND.COM by renaming the original command name to some something else: From now on DIR, CHDIR, COPY, or DEL would call my own version of the command instead of the original one.

The first implementation was just calling the original command, but with the output redirected to a text file ⁶. My program would then load the text file, and return it to the caller. From the outside, no visible change.

The fun starts here. What is the easiest way to make sure nobody can find your software? Just make sure it never shows on the screen. With some tweaks I was able to filter out from the text file any reference to the location of my hidden stash (deeply buried in the Windows 3.0 system folder). I also made sure that trying to list or access this location would return the adequate "Not found" error message.

The final tweak was to keep a log of every single command, I would review that regularly to find out who was doing what, which was practical to see how the teachers were trying to find stuff⁷.

At this point hiding my COBOL development kit was really trivial, and it worked brilliantly. All the obstacles had been overcome.

Performance issues

Unfortunately, I quickly discovered that sharing the server with twenty other students was not really a viable option.

Due to the lack of memory, the machine started to swap out as soon as more than three or four persons were attempting to compile their programs. The irony of the thing is that if instead of being able to all run our commands simultaneously we had been placed in a queue, it would have been a lot faster: Compiling one program took at most one minute when the server was doing only that, but asking the same machine to compile four programs at the same time would take nearly 10 minutes, compiling ten programs would take more than half an hour. Horrible performance patterns.

I found a solution to this problem as well, I'm not particularly proud of it, but it did work very well.

The way the terminal system worked, each of the PS/2 machine had a custom AUTOEXEC.BAT containing the code to register the fixed IP address to use to connect to the server. If for some reason two machines happened to try to use the same IP, the last one would win, effectively killing the connection and the processes started by the previous user.

My solution to the performance issue was simple: I just wrote a batch file which would in turn try to connect to every single IP. This would result in a mass disconnection of every terminal - except mine -, giving 100% of the processing power to compile my own COBOL program in a fraction of the time it would have normally taken.

Of course I made sure I would disconnect myself at the end of the compilation process to not arouse suspicion.

This is all for this article, in the next one I will briefly discuss on the method used to collect the system passwords.

---