Copy Link
Add to Bookmark
Report
29A Issue 03 02 09
Heuristics for antivirus / archiving detection
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Well, the generic idea is, that all antivirus toolkits work in
some generic way, as do viruses. This thought also can be
applied to archivers. So if we make some kind of heuristics to
detect wether the running program is an archiver or an
antivirus toolkit, we wouldn't need a list of filenames to
avoid. For viruses that are fast infecting/full stealth this may
have an enormous advantage. The first advantage is that you
don't need to be aware of new scanners and archivers (and their
respective filenames), your virus would not let go of an
opportunity to go into fast infecting mode when somebody starts
using some new kind of archiver. The old fashioned programmed
viruses would not go to fast infecting mode and skip these
files. Another major advantage is that you virus can't be fooled
by some user that renames his antivirus product to an archiver
name, where a conventional virus would turn to fast infecting
mode, thus causing the scanner to go yell and tell the user they
have a virus infection.
Tools needed for rules
~~~~~~~~~~~~~~~~~~~~~~
Like an antivirus scanner that uses heuristics, your must also
have a set of rules defined, that identify the behaviour of
antivirus scanners and archivers. This is not a very hard task,
if you have the right equipment for it. This means some
interrupt monitor in which you can view (or perhaps save) the
calls a program makes to certain important interrupts. A most
excellent tool that certainly does the job are the companion
programs called INTRSPY & CMDSPY. You can monitor interrupts and
output the results to a file. These programs rely on a script,
so it's highly extendable (you can include win95 LFN calls in
it) and you can tailor the scripts to what you need. I will
include these tools together with the outputs and intel I
gathered on some antivirus scanners to help you understand what
it is all about.
Logic comes first
~~~~~~~~~~~~~~~~~
The most important thing we must do before even starting these
great utilities is first analysing the behaviour of certain
types of programs. All programs of some category will show all a
similar kind of behaviour. For example, you can detect every
kind of modem program by setting a watch on all the output ports
for serial communication. If your program detects that "AT" (the
general hayes command starting sequence) is being sent to the
port, it can trap it, see from where in the pc's memory it is
done, and identify the mcb to which program it belongs... If
it's a nice program, it will till have some PSP in starting
right after it's MCB marker, which in turn has a field that
points to the environment segment of that program, where it's
full pathname is stored after all environment settings. Et
voila, you have a very generic modem detection program. Just
like this example here, we are also going to analyse the
behaviour of antivirus programs and archivers.
Common antivirus scanning flow
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The typical virus scanner all show a similar kind of behaviour
in their search for viruses. When you execute a scanner, the
first thing it will do is (1) perform a self integrity check.
When the scanner passes that test (make the virus its stealth
routine that good the scanner gets fooled by it, or just don't
infect the scanner itself). Then a virus scanner will most
certainly (2) scan the internal memory for active viruses. Some
antivirus toolkit will do this simply by tracing interrupt 21h,
or they would trace it anyway in order to fool the simpler kind
of stealth viruses. After it successfully passed this test (that
means until your virus has been added correctly to the antivirus
product its antivirus database) the virus scanner will (3) check
master boot record & boot sector for infection. And then it will
begin (4) scanning all kind of file objects that can be
infected.
Common archiver flow
~~~~~~~~~~~~~~~~~~~~
An archiver works pretty different from an antivirus engine. An
archiver too will (1) open a lot of files sequentially. But
there are a few subtle differences. First, an archiver does (2)
not read the master boot record. And second, the archiver will
most probably have (3) one file constantly opened with (4) write
access (5) during opening all those other files for reading.
Identifying antivirus behaviour
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Now that I've explained a bit about the basics of rules and the
typical behaviour of these two kind of programs, it is time we
are going to make an iventory of what kind information we would
need in order to make a set of rules for each program. We have
already read the general workings of an antivirus program. Now
lets convert these thoughs to actual interrupts and their
functions and hardware ports (if you want to use 386
breakpoints) we need to monitor.
First we must know all ways how you can open a file in dos. The
most 2 common methods is by 21h/3Dxxh and 21h/6Cxxh. So the
first step identifying wether the current running program is an
antivirus utility we need to see wether the program opens itself
on disk again. To determine the program name we use a large part
of the code we already thought up in the example of the
communication program identifier, by searching the caller of int
21h gettings it's mcb owner, and from there the environment
block that hold it's filename. This is not typical antivirus
behaviour, also programs that contain overlay files or
internally stored variables shows the same kind of behaviour.
But congratulations, you just have created Antivirus.Rule.A.
What we also need to do is hook the single step interrupt (int
1) and check if it gets used, or use a stack check in your int
21h and int 13h chain, or tunnel your own way to the int 21h
entry, and modify some code there so that it check if the call
is done directly or through the int 21h chain including resident
virus. This can be defined as Antivirus.Rule.B. But take care,
also debuggers do show this kind of behaviour.
To see if files are scanned, you can monitor if there is some
certain amount of executable opened sequentially after
eachother. This rule alone is also archiver-like behaviour, but
this Antivirus.Rule.C is combined with the other two a very
strong detection method to identify antivirus programs.
Identifying archiver behaviour
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Identifying archivers can be done in a very similar way, we must
monitor wether some file is opened with write access and if
there are done many file openings/closings during writing to
that other file. So again we need to monitor int 21h for some
file actions, like opening, but to be a bit more on the sure
side we also need to monitor the does read (3fh) and write (40h)
of the dos int 21h handler.
Collecting function calls
~~~~~~~~~~~~~~~~~~~~~~~~~
To find all functions that have a similar behaviour (like
21h/6Cxxh and 21h/3Dxxh) you'll definately want to get your
hands on the Ralph Brown interrupt list to find all possible
calls to monitor. These huge text archive is also very well
suited for finding weak spots in the operating system
architecture, like the dreaded int 2fh/ah=13h function to
determine the bios entry point of the hard disk bios services.
Lights... Camera... Action!
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Once we have successfully identified an antivirus scanner or
archiver, we must plan what to do with it. You could think of
setting your virus to fast infector mode when it recognizes that
an archiver has been started, so every executable that gets
archived get before it goes into the compression chamber a nice
portion of replicating code attached to its body. Or you might
want to put your virus into disinfection stealth mode when some
kind of antivirus scanner is started, so it has a bigger chance
to escape detection. Anyway, you can do with it what you want,
and the possibilities are only limited to your imagination.
Artificial Intelligence???
~~~~~~~~~~~~~~~~~~~~~~~~~~
Now that you have gathered your information, you ought to do
something with it. A thing that would truly give your virus the
technical level of advancement that you wish for is by using a
simplified kind of artificial intelligence in your program. If
you can recognize the behaviour of scanner and archivers, why
not letting your virus learn of their filenames and add them
into an internal table? That easier than recognizing them over
and over again. So if your program is sure it detects the
behaviour of an archiver, virus scanner or any program you wish
to be heuristically analyzed, it should add the filename of the
current executing application to its internal list of filenames.
On execution the virus has to check if the program to be
executed is in the list of filenames and if it is it should do
whatever that is desirable in your virus.
Too much work? Too complex?
===========================
Perhaps. Perhaps not, I leave that up to you, I hereby merely
told you one of my ideas that you might want to try out in your
viruses. In my opinion we should not only share sources,
magazines and articles, but ideas as well. I hope you think of
this virus-heuristics as a cool idea that you want to try out. I
appreciate it.
Rajaat 29A, November '98
