textfiles/virus/virus101003.vir

From: woodside@ttidca.TTI.COM (George Woodside)
Newsgroups: comp.sys.atari.st,comp.sys.apple,comp.sys.mac,comp.sys.ibm.pc
Subject: Virus 101: Chapter 3
Date: 13 Mar 89 14:24:23 GMT

First, the mail: 

Addressing a controversial topic is sure to generate some strong responses,
and this one is no exception. Mail of the "Thank You" flavor outweighs the
"You Idiot" flavor by about 4-1, so I'll be pressing on. The majority of
the "You Idiot" mail is from senders who either admit, or display, limited
programming ability. For the benefit of those individuals: I appreciate
your concern. I am not attempting to aid in the spread of viruses, but in
your own understanding of them, and ability to defend yourself. People with
the ability to create a working virus will have found little or nothing
they didn't already know in the preceeding postings. There is certainly
nothing in them that isn't already available in the most fundamental books
about personal computers. The preceeding postings are also written at a
superficial level, and are missing quite a few specific things necessary to
make a real working virus. Those missing items would add nothing to the
layman's understanding of how a virus spreads or works, so are not
included. You need not take my word for this; contact anyone you know who
is knowledgeable in the system software field, and they will confirm it. 

Sin of omission: 

Part of a message received from Forrest Gehrke (feg@clyde.att.com): 

...One method for a virus finding enough space to hide itself, that I have
seen, you have not mentioned. I have noticed that the so-called Pakastani
virus uses non-standard sectoring at tracks 37 and 38 for IBM PC
diskettes... 

Mr. Gehrke is quite right. I did forget to mention this technique. While I
had heard rumors of it being in use, I hadn't seen it in any of the virus
code I've captured (again, I'm in the Atari ST world). 

I have responded to all mail I have recieved (if it requested a response)
including mailing out copies of missed chapters. Several responses have
been returned by various mailers. If you requested something, and haven't
heard from me, either your request or my response failed.

Now, Chapter 3: 

Once a virus has installed itself, and replicated as frequently as it has
found the opportunity, it will eventually launch whatever form of attack it
was originally designed to do. That attack is the real purpose of the
existance of the virus. Everything up to this point has been for the sake
of getting to this stage. 

What will it do? Almost anything. The limits are imagination and code
space. The most benign virus I've seen claims to be an anti-virus. It
blinks the screen on boot-up. The idea is that if you see the screen blink,
you know that the benign virus is on the disk, rather than a more malicious
one. It does, however, spread itself just like any other virus. From there, 
things proceed through the prank levels, time-triggered, messages, ones 
which try to simulate hardware failures, to ones which destroy files and 
disks. The actions vary from virus to virus. And, of course, there is a 
whole different library of viruses for each machine type. Attempting to detect
a virus by describing or recognizing the symptoms is not only a task of 
limitless proportions, it is too little too late. When the symptoms appear, 
the damage has already been done. 

Several viruses attempt to simulate hardware problems. (Conversly, I've had
several pleas for help with a virus that proved to be other types of
failures.) Frequently these viruses use timers to delay their actions until
the system has been running for some time, and to spread out their
activities to make the problem appear intermittent. Such virus induced
glitches include occasionally faking succesful disk I/O, while actually not
performing the read or write, altering the data being read or written, and
(more commonly) screen display glitches. It is very difficult for anyone to
determine whether such incidents are the results of a virus, or a real
hardware problem. When such incidents start to occur on your system, start
executing whatever virus detection software you have available, before
lugging your system off to a service firm. 

Previously, I mentioned the use of write protected disks as a step in the
right direction to protect yourself. A large percentage of personal
computer systems now use hard disk systems. Floppy disks are more often a
backup media, or offline storage of files not needed on the hard disk for
day to day use. Backing up requires the disks to be writeable, as does
archiving off the infrequently used files. It is good practice to write
protect the archived disks as soon as the files are copied to them. Run
whatever virus checking software you have on the archive disks, write
protect them, and then file them away. 

(When reading the following suggestions about protecting your system from
attacks, keep in mind that not all techniques can be applied to all systems
or all software. Read the documentation accompanying the software before
your first attempt to use it. Be familiar with what it is expected to do 
before you run it, and you'll be more able to recognize unexpected activity.)

The next step is to apply write protection to whatever disks you recieve
software distributed on, before ever inserting them into a computer. Be
they Public Domain, User Group Libraries, Commercial Software, or whatever,
write protect them before you first read them. Then, make a backup copy if
possible. Finally, when first executing the new software, have only write
protected disks in your system. You should be well aware of any legitimate
attempt to write to a disk by the software before it happens, and have
adequate opportunity to insert a writeable disk when the proper time comes. 
This will not only give you a clue to the presence of a virus in the new
software, but also protect the new software from a virus already resident
in your system.

If your system supports the use of a RAM disk, copy new software into the
RAMdisk before executing it the first time. Put write protected disks in
the drives, then execute the software from the RAMdisk. If the software has
no reason to access other disks, especially when starting itself up, be
very suspicious of any disk activity. The most common time for a virus or
trojan horse program to do it's dirty work is at startup, when it is
impossible to tell whether disk access is part of program loading, or some
clandestine operation. By having the software loaded into and executing
from memory, you will be able to detect any disk I/O which occurs. 

Finally, backup everything. Hard disks, floppy disks, tapes, whatever. Make
backup copies, write protect them, and store them in a safe place off-line.
If you are attacked by a dstructive virus, your first problem is to rid
your system of the virus. Do not go to your off-line backups until you have
determined if your problem came from a virus, and if so, that you have
removed it from the system. A backup is useless if you give a virus a
chance to attack it as well as your working copy. 

A significant portion of these three chapters have been related to boot
sector viruses. While the most common type in the Atari and MS-DOS world,
they are certainly not the only type. 

What follows is next is mostly a re-phrasing of an article from "Los
Angeles Computer Currents", June, 1988. There are a few direct quotes from
the copyrighted article. While I do not agree with all that this article
states, I can not disprove the items from a position of experience. Since
my efforts here are to inform, you may judge for yourself. A significant
portion of my remarks are oriented to the Atari ST, but the concept is true
to most all personal computers. 

An article in that issue, by Lewis Perdue, outlined the problems he faced
when the IBM PC running Ventura Publisher he was using to create the first
issue of PC Management Letter became infected. I won't begin to copy all
that, but the most interesting part of the recovery task was when they used
a normal (high-level) format program to clear the hard drive. It didn't
kill the virus. They had to resort to a low level format, and rebuild from
all original distribution disks. Their backups had been infected as well as
their working copies of the software. They relied on a PC specific tool
called Data Physician, by Digital Dispatch, to aid in the detection of the
virus. It implements techniques to diagnose infections, but it has to be
installed before the virus strikes. 

Another, more interesting aspect of the article, was categorizing viruses
into four groups: Shell, Intrusive, Operating System, and Source. 

Shell - these "wrap themselves around a host program and do not modify the
original program." In laymen's terms, such a virus would tack itself onto a
program file, so it would get loaded with the program. It would have to do
this in a manner that would cause itself to be executed before the host,
since the host certainly would not pass control to the virus. 

This would be quite a complex task on an Atari ST (and on systems with a 
similar structure for executable program files). The virus program would
have to be quite large in order to deal with the structure of an executable
file on the ST. In simple terms, an executable file (a program) is a series
of unique sections: a header, the code, data, a relocation map, and
possibly a symbol table. The header specifies the size of each of the
following segments. The code is the program, but in a form which will not
run until it has been relocated. The data is constants, literals, messages,
graphic data, etc. The relocation map tells the ST what changes to make to
the code before it can be run. The symbol table is not usually present,
except during program development. The reason behind this structure is that
when a program is created, it does not know where in memory it will reside
when it is executed. Things like RAMdisks, device drivers, accessories,
printer buffers, spelling checkers, and so on, may or may not be present in
the computer when the program is run. Since each of those things require
memory, the place where the program will wind up being loaded is unknown.
So, when it does get loaded, it has to be told where it is. And, since the
program will almost always contain references to itself (subroutines,
variables, etc.) it has to be modified so that those references point to
the right place. That's what the relocation map is for. It details how the
program has to be modified. Once the program is loaded into memory, and
fixed up, the relocation map and symbol table are discarded. So, to hook
into a program file, a virus would have to split the program file, attach
itself to the beginning of the code segment, (that's where execution
begins), re-attach the data, relocation, and (possibly) symbol table
segments, update the relocation map (all the original references would now
have moved), update the header, then re-write itself to the original disk,
assuming there was room on the disk for the (now bigger) file and that the
disk was not write-protected. That's a large amount of work to develop, and 
a large amount of code to sneak into a system for the original infection. 

I should mention here that it is not difficult to write "position
independant" code on most micro-processors. You have to set out to do that,
though, and take the necessary steps along the way to keep everything
position independant.  Boot sector code is a well known example. The
address where the boot sector will be loaded into memory is unknown, and
there is no relocation done on the code. It has to be position independant.
It also has to fit in the boot sector. If it needs more than the amount of
space in the boot sector, it has to determine its own location, and load
the additional code itself. Of course, that means that it had to have a
place to store the additional code, and it had to know where to find it. 
Those items were covered previously.

Detecting a "Shell" type virus is not difficult. When it attaches itself to
the target program, it must increase the size of the file. While it would
be a real nusiance to check file sizes on a regular basis, there are
programs available to do this for you. An "alteration detection" program
will typically accept a list of programs to recognize. It will write a data
file of its own, noting characteristics of each file in the list, such as
length and date, and then run a numeric algorithm across the file. The
numeric algorithm (typically a Cyclic Redundancy Check, or CRC) will yield
a value which is stored in the alteration detection program's own data
file. Then, on each subsequent execution of the alteration detection
program, it checks the recorded characteristics of each file in its list,
and re-executes the algorithm on the files. It reports back any file which
has been changed since it last executed. Needless to mention, such a
program must be run on the files to be monitored before any virus has an
opportunity to attach itself to those files. Then, it must be run frequently
to have a chance to detect altered files.

(Back to the types of viruses defined in the article)... 

Intrusive - Intrusive viruses work by patching themselves into an existing
program. This type of virus has two possibilities - either it is willing to
render the host program useless, or it will attempt to co-exist with the
host. If it is willing to corrupt the host, this is not too difficult a
task. It would replace a part of the host program, modify the relocation
map, and wait to get run. When it did, it would abandon the original task
of the host program, and launch its attack. An example of this would be the
virus bearing version of a word processor which struck the IBM compatible
market some years ago. It signed on, looking just like a popular shareware
program, but it was busy re-formatting the hard disk while the user waited
for it to load and get ready to accept input. 

The other flavor of intrusive virus, which attempts to co-exist with the
host program, is terribly difficult to create. It has to modify the host in
a manner that either accomplishes the host's task while also doing it's
own, or find a part of the host that is infrequently or no longer used, and
hide there. It would then have to modify some other part of the host in
order to get itself executed. In either case, a virus of this type has to
be aimed at one specific host program. There's no way it could perform the
analysis necessary to locate such portions of a randomly selected program.
For that reason, an intrusive virus has to target some program that resides
on a large portion of the target computer's installations, and that it is
certain will be available to tamper with when the virus introduction
occurs. That normally means either the Operating System, or some utility
program so common that it is found virtually every where. 

Operating System viruses work by replacing a portion of the Operating
System with their own code. This is similar to the intrusive type, except
that it can use a new trick (and there are ones that do this on the
IBM/MS-DOS computers). As a part of the operating system, it can sneak out
to a hard disk, find an unused part, mark it as defective, and hide there.
That would mean only a very small part of the code would have to be hooked
into the operating system (possibly as an entry in a list of device
initializing routines). That small segment could then allocate adequate
memory for the real routine, and load it from wherever. 

Source Code viruses - I found this type of virus to be a bit unbelievable.
The article reads (I quote): 

Source code viruses are intrusive programs that are inserted into a source
program such as those written in Pascal prior to the program being
compiled. These are the least-common viruses because they are not only hard
to write, but also have a limited number of hosts compared to other types.
(end quote) 

Sounds to me like this would be nearly impossible to accomplish in
after-market software. If, on the other hand, they mean a part of the
program added by a devious member of a development team, then, it is
credible. It brings to mind the story (which I can't verify, but I've heard
it from enough different sources to believe it is true) about what may well
have been the first virus. In case you're not familiar with "C" compilers,
they are usually several different programs, which must be run in proper
sequence, passing files and options from one to the next. Usually, this is
all done by a another program, a "compiler driver", which is almost always
called "cc". You execute "cc", passing it the necessary flags, and the
name(s) of the program(s) you want compiled, and it drives all the
necessary tasks to do it. 

This was reported to have been done by one of the originators of the UNIX
operating system, (name deleted), back in the development days at Bell
Labs. Well, the story goes, he wrote the first versions of UNIX, "C", and
"cc". He had a "back door" to get into a system running UNIX. He built the
back door code into "cc". The code in "cc" checked to see what it was
compiling. If it was the module "login", it incorporated the back door into
the module, so that he could get into the system. If, on the other hand, it
was compiling "cc", it included the code both to re-create itself, and the
code to build the back door into "login". So, every "cc" had the code, and
consequently every UNIX system included the back door. Eventually, it was
discovered, and removed. There followed a frantic rebuilding of every UNIX
system in existance, so the story goes. 

This is the final chapter which will be distributed via cross-posting.
Chapter 4 will relate specifically to viruses captured in the Atari ST
environment, and will be posted only to comp.sys.atari.st. It will come out
about 1 week after this one. This article was posted on March 13, 1989, so you
can determine the approximate delay to your receipt, in case you don't read
that newsgroup, but wish to locate the fourth chapter in comp.sys.atari.st. 

End of Chapter 3. 
-- 
*George R. Woodside - Citicorp/TTI - Santa Monica, CA 
*Path:       ..!{philabs|csun|psivax}!ttidca!woodside

Downloaded From P-80 International Information Systems 304-744-2253