From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Newsgroups: comp.virus
Subject: Re: Defence from mutating viruses. (PC)
Date: 13 Apr 92 10:22:21 GMT

kiae!rtech!vl!ALS@vl.ts.kiev.ua writes:

>     Just now there is no any idea to increase scanners capability of checking
>     polymorphic viruses. It looks like virus scanners would be removed from
>     front line of battle against viruses. It seems to me that there is time

Unfortunately, it seems to be that the scanners will be with us at
least for the next two years... It's still easier to write and
maintain a good scanner (which simply does not try to detect anything
it can't with wildcard strings) than a good integrity checker... And
the polymorphic viruses are not that many right now. They are just a
trend - a dangerous trend - and I am trying to tell all those who
produce or rely on known-virus scanning that they should look a bit
more far than their noses...

>     First idea was to make ReadOnly attribute stronger. I wrote a little
>     program that makes changes in MSDOS.SYS (in memory, of course, not
>     in disk file). After that nobody can remove ReadOnly attribute (it
>     receives error code: Access denied), so it can't infect files with this
>     attribute set via file operations (open file, write to file, close file).
>     More than that, you can freely set or remove all other file attributes
>     except ReadOnly. For info purposes my program also writes red border
>     on EGA/VGA display if somebody tries to remove ReadOnly.
>     It is possible in my program (called RLock) to restore old MS-DOS
>    attributes manipulations if you really need to do something with protected
>     by this method files (for examle, to delete it or move).

If your program RLock can restore the attribute handling, then so can
a virus, since there is no memory protection in DOS. Your program is
successful not because it is secure, but because the viruses are not
aware of it (security through obscurity). As soon as it becomes as
widely used as SCAN, there will be viruses which get around it.

I have seen a better way to achieve the same in the ThundeByte
anti-virus card. When you try to turn the ReadOnly attribute off, the
card displays a pop-up window and asks you for permission. It reamins
silent if you are trying to set the attribute ON. Since it is
hardware-based and takes some anti-virus measures (constant
checksumming of its memory data areas; each card comes with different
version of the program in the EPROM; etc.), it's more tricky to bypass
it. But it's still possible - just not easy.

>     Results were surprising - nearly 95% of viruses were unable to infect

I'll be interested to know which viruses belonged to the 5 %
category... BTW, the fact that they exist means that as soon as your
methos gets widely used, the viruses will begin to use infection
methods that belong to the 5 % category...

> And what about 5%? These viruses used direct access to disk via Int 13h
> or DOS internal tables to infect files without removing ReadOnly attribute.

Let me guess: Dir II, Int13, maybe the Number of the Beast and the
Phoenix family, right? Any others?

>     I used the second idea to prevent their deeds: wrote another programm
>     modifying IO.SYS and MSDOS.SYS that can prevent direct access to disk
>     to all programs EXCEPT COMMAND.COM. As a result disk is opened for any
>     standart file IO (open, close, write, read) and any file editors and
>     compilers work correctly, but it is WRITE PROTECTED for direct writing

Why exactly is COMMAND.COM excluded? Does some program need to
manipulate its sectors directly?! And, yes, the above method won't
work if (1) the virus modifies the FST in memory, or (2) uses the
Norvegian infection method (Frisk, is there a virus which actually
uses it? Which one?), or (3) masquerades writes as reads like the
Phoenix family.

> to it. And also I filled this programm with trips that can make impossible
> for virus to access DOS internal tables. If anybody tries to do it,
> resident part of my second programm (called HDD - Hard Disks Defender)
> returnes COPY of the DOS table with incorrect values in critical fields.

OK, this whould take care of (1). But I bet that you have just written
an INT 2Fh handler for that. Have you thought about the possibility
for a virus to access the FST not by using the undocumented functions,
but directly?

>     As a result only very DOS-depended viruses can ignore this defence.
>     I don't know such viruses just now, but even if anybody can write them,
>     these viruses can die with the next MS-DOS version because of their
>     DOS-dependence.

How about Dir II? Oh, I guess it doesn't qualify as a file infector
(it's file system infector). But how about a virus which uses a
similar approach (i.e., using device driver requests instead of
interrupts)?

>     I think that idea of writing of virus defence as native part of DOS has

Sure, it is a good idea. However, in order to be successful, you need
memory protection, which you cannot have under DOS...

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev        Virus Test Center, University of Hamburg
Bontchev@Informatik.Uni-Hamburg.De  Fachbereich Informatik - AGN, rm. 107 C
Tel.:+49-40-54715-224, Fax: -226    Vogt-Koelln-Strasse 30, D-2000, Hamburg 54