From: kiae!rtech!vl!ALS@vl.ts.kiev.ua
Newsgroups: comp.virus
Subject: Defence from mutating viruses. (PC)
Date: 6 Apr 92 10:28:36 GMT

>   mike.opzoomer@canrem.com (Mike Opzoomer) writes:
>   > The polymorphic engine is just that, and once infected it mutates on
>   > an ongoing basis, rendering any scan utility useless (unless you have
>   > a copy of the size of the original file)
>
>   I tend to agree that there cannot be a virus for which there is no
>   protection, but it looks like we are starting to see viruses for which
>   the vast majority of conventional methods fail.
>
>   Rememberring that there are more ways of stopping a virus than simply
>   scanning for it, what other anti-viral methods (e.g. change detectors,
>   software write-protection, anything) actually succeed? Has anyone
>   carried out the tests?  If not, could someone with the engine do so -
>   quick, please!
>
    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
    for non-traditional methods for preventing virus infection. I made some
    testing of what would be if I can change some codes of MS-DOS resident
    part to make it more virus-safe.

    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).

    Results were surprising - nearly 95% of viruses were unable to infect
    files after setting RLock defence. Some of them even didn't try to remove
    Readonly and failured, other failured with removing and very intellectual
    viruses that used tracing Int 21 chain to jump directly into MS-DOS
    Int 21h routine failured too because RLock protection of ReadOnly attribute
    became a part of MS-DOS itself.

    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.
    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
    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.

    RLock and HDD are DOS-depended and were written for MS-DOS 4.0, 4.01
    and 5.0.
    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.

    I think that idea of writing of virus defence as native part of DOS has
    future. Anti-viral packets can be simply modified and quickly sent to
    PC users when new DOS version was upgraded, while viruses have long way
    to their "users".

    And what are you thiking about it?

- --
Alexander Shehovtsov,     (8-044)266-70-28 (9:00 - 18:00 Kiev, Ukraine) voice
           als@vl.ts.kiev.ua    Relcom | 2:463/30.5  or  2:463/34.4   FidoNet