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
- 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
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
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
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
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
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.
Devload Project Writeup - David Woodhouse (Dave@infradead.org)