Heuristics for antivirus / archiving detection
by Rajaat / 29A

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