Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!ncar!noao!asuvax!fbog!dbk
From: dbk@fbog.UUCP (Dave B. Kinzer @ Price Rd. GEG)
Newsgroups: comp.sys.amiga
Subject: IRQ virus
Summary: Helpful hints
Keywords: IRQ ideas
Message-ID: <1738@fbog.UUCP>
Date: 5 Jan 89 00:54:08 GMT
Reply-To: dbk@fbog.UUCP (Dave B. Kinzer @ Price Rd. GEG)
Followup-To: comp.sys.amiga
Distribution: na
Organization: Motorola Microcomputer Division, Tempe, Az.
Lines: 95

[Do line eaters eat viruses?  Line eater vanquished, Big Net Virus shows up.]


   I would like to contribute some ideas on how to reduce the spread of
the new strain of virus.  Not being intimate enough with the system internals
to implement all these ideas, I feel that this information in the hands
of a net.guru will perhaps result in a new weapon in the war on viruses.

First some background info.

   Virus writers take advantage of anything known about a system.  For
example, the first Amiga virus hid in some unused memory and was held
in a boot block of known format.  The point I'm making is, the weapon
that we fashion here should not be something that a virus writer can
count on.

   Viruses spread through their latency.  The latency is the time between
infection and detection.  Reduction of this time will reduce the spread. 

   The scheme I present here will not prevent a virus from attacking a
system, rather it is a way of detecting the damage done by a virus.  This
will at least alert a user that something is wrong.  This should slow down
the rate of spread, even if it does not stop it.  Of course this could
be combined with programs that search out specific virusus for more
complete protection.

   The idea is to keep more complete information around about all the
files on a disk.  OK, nothing earth shattering here, but the specific
suggestions that follow will make it very hard for a virus writer to
circumvent.

1)   Since we are going to keep a file on disk, the name should be user
     configurable.

2)   The data file should be encrypted (NES one-key preferred).  It almost
     goes without saying that the key should be user configurable.

3)   Data should contain file length.

4)   Data should keep track of the hunks, overlays or whatever in each file.

5)   Data should contain two different CRC checks of the file using user
     configured polynomials.

6)   The virus detection program should have a user configurable name.

7)   Any ports used should have a user configurable name.

8)   The program distribution should be in object module format with a
     mini-linker which randomizes the (hopefully small) modules making
     detection of the virus detector program difficult.  Random length
     modules (with random or better yet duplicate fill) could be created
     so the length ends up random.  The linker could also prompt for
     all the user configuration data.

9)   Manual invocation and possibly automatic call on disk insertion.

10)  Program to output (possibly to window with drag bar [random window
     structure names :-)]) the New Files, Deleted Files and Changed Files.
     Included in the output should be some user configured text so a
     virus has a hard time faking this.  Program would then calculate
     new checksums for new and changed files (except checksum file ;-))
     upon reciept of user OK.


   Note that there is very little for a virus writer to count on in the
above.  As long as the password data is kept out of his hands (might have
to be kept encrypted in a program that looks for diskchange, [and thus
is resident in memory] since the virus could get it from there [hint hint,
also flush variables]), the above procedures make a 'standard solution'
which would be hard to beat.

   Running the program (via amicron or dcron) nightly on a hard disk would
reduce the virus latency to 24 hours, significantly reducing the spread.
This might be an application for a two-key encryption system so that
a password on the command line (in the cron file) would not unlock
the data file directly.

   A note to anyone who might like to take it upon themself to write a
utility like this.  Assume the virus writer has your commented source
code, knows how to manipulate the system hardware directly, and knows
where you have your program stored. 

Known hole in above scheme: Programs that have just been written to disk
are available for attack since no CRC's have been computed for them yet.


   Anyway, just some ideas that can be taken and run with.  Anyone else
out there with some suggestions?



|    // GOATS - Gladly Offering All Their Support  Dave Kinzer (602)897-3085|
|   //  >> In Hell you need 4Mb to Multitask!  <<  uunet!nud!fbog!dbk       |
| \X/   #define policy_maker(name) (name->salary > 3 * dave.salary)         |