From: rat@ruth.UUCP (David Douthitt)
Newsgroups: comp.org.eff.talk
Subject: Beneficial Virus
Date: 9 Jan 93 02:58:45 GMT
Organization: Network XXIII - +1 608 222 9253


I thought I would give some thought about how a beneficial virus would
be implemented, so that we're all arguing about the same points.

One assumption I will be making is that the system(s) are single-user
MSDOS sites - multiuser viruses present a whole new can of worms.

First, the user installs the software on their system (System A).  They
run a program called INSTALL.EXE on the provided distribution diskette.
With appropriate warnings and notifications, the install program places
the marker on the system.  It is possible that it would (with notice)
load the compression virus into memory at that time, so that it would
start to spread - or a choice could be given to place the virus on
a file or files, to be activated later (during decompression).

One note to be made - the virus being discussed has one purpose: to
spread the decompression routine to as many executables as it sees fit
to.  The decompression routine and the viral infection must be kept
SEPARATE when considering the ramifications of this system.  The decompression
routine could in fact be LZExe or some other, or could even be released
separately from the virus.

A file with the virus (and compression code) would operate in this manner:

    1. The executable is loaded into memory and run.

    2. The first code operates this way:

          a. Does viral marker exist?
                - NO: take your pick of ONE (and ONLY one) of these
                      possibile actions to be taken:

                      1. remove virus from file (leaving compression routines
                         in place to decompress file later).
                      2. skip to step 3 - virus remains to activate on other
                         system containing marker.
                      3. remove virus AND COMPRESSION from file.
                      4. ask the user what to do (and choose one of the
                         above or possibly a new install).

                - YES: load the virus (either from file or marker) into
                       memory as a TSR program - with hooks into disk
                       or file read/write/execute.

    3. Having executed past the viral code, the decompression routines would
       take hold and decompress the program - virus or no virus.

    4. The actual code would then begin to execute.

My favorite option under 2. (NO) is to remove the virus entirely.  A virus
would cause too much unnecessary panic otherwise from a misguided and
paranoid public who have heard too many stories which brand hackers as
vicious evil malcontents intent on destroying the world by computer.

If the virus was contained in the MARKER, then when a compressed file
leaves the system (such as taking a compressed executable from System A
to System B) there is no virus at ALL present in the file, and the virus
does not spread.

Since the virus is not resident in the file, there is not even a chance
of this virus "escaping" a system because the only way the actual code
gets there is by user installation.  If there is an option to install
the virus under 2. (NO) 4., then the viral code must be present in the
compressed file and somebody would probably scream.

One possible problem would be a malicious virus masquerading as a
valid marker file.  Then any file compressed with the beneficial
virus would activate the malicious virus - some sort of check would
have to be made that the virus was the *RIGHT* virus.

Having considered the infected file, let's consider the virus in operation.
It is assumed that the virus has only been placed in memory after it has
been verified that the marker was present, and it is okay for it to run.

The virus might operate this way:

   1. The virus recognizes the fact that an executable file is being loaded
      for execution.  How this is done is not particularly relevant, and
      could most likely be done a number of ways.

   2. The virus checks for several signatures in the executable (after it has
      been loaded, of course).  This would check whether the file already
      had been compressed (with who knows what), or whether the file had
      the required marker check routine.

   3. If the file is not compressed, it would write out to the file on
      disk, in order:
         - the marker check routine
         - the decompression routine
         - the compressed executable

   4. It would then delete the original and rename the temporary file to
      be the original.

Hope this clears up the viral debate - but I still hope it rages on! :-)


--
UUCP: ....!fullfeed.com!ruth!rat        |  Network XXIII - +1 608 222 9253
InterNet: rat@ruth.UUCP                 |  80Megs+ of Usenet/Fido programs!
Fidonet: David Douthitt 1:121/23        |  ... Files via Fidonet FREQ,
"...because appealing to the masses has |  anon uucp, first time login,
 never appealed to us."                 |  mail to fileserver@ruth.uucp
Newsgroups: comp.org.eff.talk,soc.culture.usa,alt.activism