Possible solutions.

Having decided that a RAM drive was the best way of solving the problem, I was left with two possible ways of installing it, both of which involved quite a large amount of low-level work. These were:

• Load RAM drive at boot time.
  I asked a network manager about this, and he said it was not possible to do so. To achieve control of the machine at boot time, I needed to hack into the network, take copies of all the network drivers and put them all onto my own boot floppy. The difficult part was, of course, the first part.
  
  
• Load RAM drive after boot time.
  This solution would involve a lot of in-depth knowledge of the internal working of DOS and the structure of DOS tables. In the absence of any suitable technical reference manual, I would have to do all my own research, by taking apart DOS code. This involved even more work than the other possibility.
  
  
• Solution number 1 - Load at boot time.
  The network running on the workstations I was using was RM-NET 3.1. This is MS-NET compatible, which meant that my technical reference contained details of the DOS function calls necessary to connect and disconnect network drives.
  The first step I took was to write, in C, a program to list the network devices connected to the system. I soon expanded it to include connection and disconnection of network devices, but it kept it's original name, NETLIST.EXE.
  Now I had this method of listing connected devices and connecting more, I was more aware of what was happening within the system. I decided that it was time I found out the passwords for some of the network drives.
  Working on the basis that they had to connected at some point in time by calling the DOS function to connect network devices, I set up a simple Trojan Horse to take over the DOS function interrupt (INT 21h). Whenever an INT 21h call was made with the AX register set to 5F02h (the function code forconnecting a network device), the program recorded the drive connected, the shortname and the password in an internal buffer. The program was written in assembly language, and was called REDIR.EXE
  I originally started by using SYMDEB to examine the program in memory and read the contents of the buffer, but I soon tired of that and wrote a program to display the copied information automatically. This was REDIRSHW.EXE, and I wrote it in C. For this I had to amend REDIR.EXE to include a signature, so that REDIRSHW could be sure the Trojan Horse was installed, and a pointer to the buffer, so that I wouldn't have to change REDIRSHW.EXE every time I changed the size of the Trojan Horse program.
  The Trojan Horse worked perfectly, and soon I had found the shortnames and passwords of drives I hadn't previously known existed. Every server on the network had a drive named PUBLIC, and they all had the same password. This applied even to a server they hadn't told us about, meant for Computer Services use only. The PUBLIC drive on this contained copies of software not generally available on the network, for example Excel 4 and Superbase 2. I was encouraged by this discovery, and continued.
  When logging off, the logon program usually just disconnects all network drives and asks for another user name and password for logon. If a TSR was installed, however, the machine was automatically rebooted, which meant that my Trojan Horse was lost every time I logged off from the system, making it difficult to gain access to many drives which I didn't usually have access to.
  This problem was soon fixed, however. I used SYMDEB to examine the image of the logon program, XNETLIST, in memory, found all the checks performed and by-passed them. The program then didn't reboot when I logged off, but left my Trojan Horse running while the next user logged on. This was the point at which I began to enjoy myself.
  When I examined the record of device connections after logging off and then back on again, I found that a connection had been made to a drive X:, and subsequently disconnected. I immediately reconnected to this drive and examined it. I found it to contain the version of DOS from which the machines booted, all the network device drivers, the logon program and also the user database containing all the passwords on the system. This was exactly what I had been looking for.
  I examined the startup procedure carefully, to avoid making any mistakes and causing problems when I made my boot floppy.
  The stations boot from the closest server on the network. and immediately connect drive X: to the network boot drive. A copy of CONFIG.SYS is then executed, depending on the type of the workstation. This loads all the device drivers necessary for normal operation of DOS and the network. NET.EXE is then called as the DOS shell. This connects a network session and then passes control to XNETLIST.COM, which is basically a loop which does the following:
  
  
  • 1. Connect drive X:
  • 2. Run XNETLIST.EXE (see below.)
  • 3. Disconnect all drives, rebooting if can't
  • 4. Reboot if INT 21h vector changed.
  • 5. Reboot if amount of free memory has changed.
  • 6. Various other checks, rebooting if changes.
  • 7. Loop to part 1.
  
  
  XNETLIST.EXE is the program which handles to logon procedure, by asking for a user name and password and looking them up in the user database. If they are correct, the necessary network drives are connected and a copy of COMMAND.COM is invoked.
  
  Once I was sure of the boot procedure and was confident that I could make a network boot floppy without making any mistakes that might disrupt the network, I copied all the network drivers to a DOS 5 boot disc along with the CONFIG.SYS file for the workstations I was using, and attempted to boot from my own floppy, This worked fine with an exact copy of the CONFIG.SYS, so I added a RAM drive, and was delighted to find that I had solved the problem.
  I soon cut out the network security programs from the boot procedure, after first examining them to ensure there would be no adverse effects caused by their removal.
  My next step was to by-pass the normal logon procedure. I got bored of typing my name and password, so I wrote MYSHELL.EXE in C to log on automatically. This connected me to both my own user space and the Student Union user space, in which I occasionally had to work The only problem with this was that many of the shortnames and passwords were eight-digit random numbers which were changed every week. About once a week, I had to log on normally and catch all the shortnames and passwords again. This only took a couple of minutes, though, and so I didn't go back to the normal logon program.
  A more important problem with my solution was that all the workstations were set up to remote boot from the network, and only attempt to boot from a floppy disc if the network was not available. This meant that I had to unplug my machine from the network every time I booted it. I had, however, seen that the network managers possessed boot discs which the machines booted from in preference to the network. The discs obviously contained a signature, probably in the boot sector, marking them as having priority over a network boot. The machines always checked the floppy drive for this signature before booting from the network. In order to find out exactly what this signature was, I took home a complete copy of the machine's ROM BIOS and started to go through the INT 19h procedure, which is the ROM bootstrap.
  Before I completed this, however, I encountered another obstacle. I was asked by the network managers to refrain from using my own boot floppy. I explained exactly what I was using it for, and asked the Development Team Manager about the possibility of loading device drivers from the command line. He replied that he'd tried it once, but had given up on it.
  Naturally, I took this as a challenge, and threw myself into solving the my second possible solution; loading device drivers from the command line.
  
  
• Solution number 2 - Load from command line.
  This involved writing a program to install a RAM drive into the DOS internal tables after boot time. I decided to take it a step further and make it install all device drivers.