58 lines
3.4 KiB
Plaintext
58 lines
3.4 KiB
Plaintext
FUNBOT3.CVP 910918
|
|
|
|
Boot sequence - part 2
|
|
|
|
Obtaining the state of the environment immediately after the boot sector
|
|
has been run is not as easy as it might sound at first. The computer,
|
|
while functional, does not have all parts of the operating system
|
|
installed at this point, and it is the "higher" levels of the operating
|
|
system that users generally interact with.
|
|
|
|
The last section of the boot sector program points to the files or areas
|
|
on the disk in which to find the next step of the operating system. At
|
|
this point the specific files and subsequent steps start to change from
|
|
one operating system to another. However, it is fairly common for all
|
|
operating systems to have "hidden" files along this route which may be
|
|
subject to viral attack. Given that the files are not evident to the
|
|
user, they are more subject, not to attack, but to an undetected change.
|
|
|
|
When setting up antiviral defences, it is important to know the sequence
|
|
of events in the boot process in order to know which programs will
|
|
protect to which level. The MS-DOS sequence provides the clearest
|
|
example, and those knowledgeable in other systems can use the examples it
|
|
provides in order to analyze the specific details of their own systems.
|
|
|
|
After the master boot record and boot sector proper have been run, MS-DOS
|
|
normally runs two additional programs which set up input/output routines
|
|
and the most basic operating system. (As these programs are called by
|
|
the boot sector, it is possible to re-route this process to call
|
|
specialized driver programs first, or with them. Some esoteric disk
|
|
drives use such a process.) Traditionally, these files have "hidden"
|
|
attributes and are not visible to the user on the disk. After they have
|
|
run, the system has sufficient programming to interpret a text file which
|
|
contains listings of various additional programming which the user wishes
|
|
to have in order to run specialized hardware. This file, CONFIG.SYS, is
|
|
the first point at which the intermediate user may normally affect the
|
|
boot process, and is the first point at which antiviral software may be
|
|
easily installed. As can be seen, however, there are a number of prior
|
|
points at which viral programs may gain control of the computer.
|
|
|
|
After the programs listed in CONFIG.SYS are run, the command interpreter
|
|
is invoked. The standard MS-DOS interpreter is COMMAND.COM, but this may
|
|
be changed by an entry in the CONFIG.SYS file. After COMMAND.COM is run,
|
|
the AUTOEXEC.BAT batch file is run, if it exists. AUTOEXEC.BAT is the
|
|
most commonly created and modified "boot file", and many users, and
|
|
antiviral program authors, see this as the point at which to intervene.
|
|
It should be clear by now, however, that many possible points of
|
|
intervention are open before the AUTOEXEC.BAT is run.
|
|
|
|
In spite of the greater number of entry points, viral programs which
|
|
attack the programs of the boot sequence are rare, and not greatly
|
|
successful. For one thing, while very disk has a boot sector, not every
|
|
disk has a full boot sequence. For another, different versions of a
|
|
given operating system may have different files in this sequence. (For
|
|
example, the "hidden" files have different names in MS-DOS, PC-DOS and
|
|
DR-DOS.) Finally, viral programs which can infect ordinary programs
|
|
files may not work on boot sequence files, and vice versa.
|
|
|
|
copyright Robert M. Slade, 1991 FUNBOT3.CVP 910918 |