Hacker 2/HACKER2.mdf/virus/virusl3/virusl3.24

Text File | 1995-01-03 | 37KB | 809 lines

VIRUS-L Digest   Monday, 29 Jan 1990    Volume 3 : Issue 24

Today's Topics:

Re: Shrink-Wrapped Software
Re: "Desktop Fractal Design System Not Infected"
Re: Internet worm writer stands trial (Internet)
Re: Signature Programs
More re: Desktop Fractal Design System
Re: Signature Programs
Re: Signature Programs
STONED Virus data (PC)
WDEF Virus in California (Mac)
More about UVDs
Three new viruses (PC)
The V651 virus (PC)
Re: Virus vs. worm

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    26 Jan 90 21:00:24 +0000
From:    [e-mail] (Mark Draughn)
Subject: Re: Shrink-Wrapped Software

[e-mail] (Bernie Cosell) writes:
>ensys.ensys.com!silvlis.com![e-mail] (Michael S. Maiten) writes:
>
>}[e-mail] writes:
>
>}>   Users can protect themselves
>}>   and discourage this risky practice by refusing to deal with retailers
>}>   that offer them the right to return.
>
>}Stores that offer return policies are exactly the ones with whom I do
>}deal, since it is almost impossible to see if the software will meet
>}my needs by reading the box or trying out the store demonstration
>}copy.  What they should do is to be more careful when accepting the
>}returned items (check for missing materials, and check for infection
>}of the disks) before returning the person's money.
>
>Actually, isn't this almost totally trivial for the store --- all they need
>to is, before they re-shrink-wrap, do a sector-by-sector, byte-by-byte
>comparsion of the *entire* disk(s) that were returned against a master set
>the store keeps.  It doesn't seem hard, and surely cannot take long, and far
>as I can tell totally elminates the problems.

This requires the stores to keep safe copies set aside for every piece
of software they sell.  It's a lot of work and it costs a lot in terms
of time and equipment.

How about this instead:  Software vendors could ship the media separate
from everything else in the piece of software, including the license
to the software.

When someone buys a piece of software from the store, they get the entire
package and the disks.  (Having separate media also makes it easy to choose
5.25" v.s. 3.5" etc.)  If the customer returns the software, the store keeps
everything except the actual disks.  The disks are returned to the vendor.
The vendor then sends the store a new set of disks.  The store still has
the same number of legal, licensed copies, so nothing much has changed.

This seems like a good idea because the vendor already has the equipment,
expertise, legal permissions, and master copies needed to produce virus-free
copies of the software.

The cost of doing this is small--just the cost of making and shipping a few
disks.  Whether the cost should be carried by the vendor, the store, or the
customer is a detail that market forces will probably control.  My guess is
that the retail stores will end up eating the cost as part of the cost
of good customer service.

There are problems with cheating--the retailer could re-wrap, or the vendor
could simply re-ship returned software--but I don't think this will make
things worse.  The retailer has relatively little to gain by cheating when
he can get good copies so cheaply.  The PR damage from even a single incident
of shipping infected software should keep the vendor from cheating.

How does that sound?

- --
EMAIL: [e-mail]+--------------+ Academic Computing Center
BITNET: SYSMARK@IITVAX       | Mark Draughn | 10 W. 31st St.
VOICE: [phone]       +--------------+ Illinois Institute of Technology
ALSO: ...{nucsrl|att}!iitmax!draughn          Chicago, Illinois  60616

------------------------------

Date:    Fri, 26 Jan 90 14:50:52 -0500
From:    Eric Roskos <[e-mail]>
Subject: Re: "Desktop Fractal Design System Not Infected"

Since writing the posting in today's VIRUS-L with the above Subject line,
I have received some seemingly rather hostile mail criticizing the above
statement.

I would urge people who object to the above statement to (a) reread the
original posting, (b) note the quotation marks around the statement, and
(c) reread past issues of VIRUS-L regarding this problem more closely.

My point in writing that particular Subject line was, and is, that to
date there is no evidence *which has been presented on VIRUS-L* that the
Desktop Fractal Design System, as shipped from the publisher, is
infected.  There is only the claim that it is, and the statement
(secondhand) that the publisher is "aware" of the problem.  Whether they
are aware that some people say the program is infected, or whether they
have copies of it from their stock that are infected, is not known from
this statement.

On the other hand, we do have evidence -- I have it right here -- that
at least one copy is *not* infected, as purchased from a local bookstore
(Reiter's Scientific Bookstore in Washington, DC).  This also is not
evidence that the copy was not infected when shipped -- someone might
have bought the copy, disinfected it, and returned it to the store, for
example -- but the converse possibility is true for the allegedly
infected copies.  Since I write-protected the disk before I used it the
first time, I know it has not been written upon since I unwrapped it.

It would be helpful to those of us who have to deal with these issues to
know more about details of alleged virus infections, things such as:

        - Did you personally open and install the infected disk?

        - Did you write-protect the disk before doing so?

        - How many copies do you have that you know to be infected?

        - What is the version number of the software?  Is there any other
          date or serial number information involved?

More facts and less rumors would be helpful, both in understanding the
problem, and ensuring that it is properly identified, particularly when
a virus report contains some highly specific information (such as stating
that a particular item of software is infected).

(Incidentally, I would add here that it would also be beneficial to
software publishers if they would publish their software on floppy disks
without write enable notches in them.  IBM used to do this with their
early PC software disks; I don't recall seeing any like this in a long
time.  It would protect the publishers from being falsely accused of
spreading a virus when in fact the disk was infected by the user during
installation; although it would also eliminate their ability to claim
the latter if they were, indeed, responsible for the infection.  All
around, the practice would seem to be an improvement.)

Disclaimer:  I have no connection with the author or publisher of the
Desktop Fractal Design System; I simply own an uninfected copy of it.

------------------------------

Date:    26 Jan 90 13:38:02 +0000
From:    [e-mail] (Woodrow Baker)
Subject: Re: Internet worm writer to go to trial Jan 16th. (Internet)

> >Gene, in your report (_The Internet Worm Program:  An Analysis_), you

Where or how can I get a copy of this report?

Cheers
Woody

[Ed. It is available via anonymous FTP from cs.purdue.edu in
/pub/reports.  I also keep a copy of it on the CERT anonymous FTP,
cert.sei.cmu.edu, in /pub/virus-l/docs.]

------------------------------

Date:    26 Jan 90 13:53:51 +0000
From:    [e-mail] (Woodrow Baker)
Subject: Re: Signature Programs

Where can a description of ISO 8731-2 be obtained at little or no cost?

Cheers
Woody

------------------------------

Date:    Fri, 26 Jan 90 18:51:35 -0500
From:    Eric Roskos <[e-mail]>
Subject: More re: Desktop Fractal Design System

In keeping with my own suggestion, I checked the version number on the
copy of this software that is not infected; it is version 1.0, as
labeled on the disk (near the bottom of the green label on the disk),
and when started up it also displays 1.0 as the version number.  Can
someone who has an infected copy post the version number involved? If
it is a different version, that will give some insight.  Thanks...
- --E.R.

PS - This copy I have was purchased about the 2nd week in December.
There is not any other date or serial number marking present, other than
a serial number for the floppy disk itself, "46892C", stamped on the
back in ink.

------------------------------

Date:    Fri, 27 Jan 90 00:28:39 +0000
From:    utoday![e-mail] (Ross M. Greenberg)
Subject: Re: Signature Programs

 [e-mail] (Bob Bosen) writes:
>
>
>1- The PERCENTAGE of the file that is subjected to the sophisticated
>algorithm. This can sometimes be quite a small fraction of the whole
>file.  (The remainder of the file can be processed by an industry-
>standard CRC algorithm. There are various techniques deriving from
>cryptology that can be used to cause the effects of the sophisticated
>algorithms to "ripple through" all the way to the final signature.)
>Properly implemented, these techniques can result in a reliable,
>virtually unforgeable signature that is calculated almost as quickly as a
>conventional CRC.

True, only if you're looking for a known pattern.  Otherwise, you're
guessing that your algorithm is smarter than the bad guys.  Not on my
machine you don't!  You're gonna have to scan the whole file, every
byte to tell me if there has been a change. It's incredible what a
simple one byte change may produce:  changing an INT25 to an INT26 (or
vice versa) makes for a difference that can destroy your hard disk. A
one byte difference.

>
>2- WHEN the signature is calculated. Obviously you can infuriate your
>users if you make them stand around twiddling their thumbs while all your
>files are authenticated in batch mode during the bootstrap process. On
>the other hand, if most authentication is done "on the fly" as programs
>are loaded, users hardly notice the delays.

Assume that your user has a mongo file, maybe .5Meg of code s/he wants
to load up.  For the reasons cited above, you have to do *something* with
each byte of the code.  Take an XT, clocking at 4.77MHz.  Add algorithm
for *each* byte.  Stir slowly.  In the case of the XT, very slowly.  Now,
start adding to the complexity of the algorithm.  Notice the chair in
front of the terminal suddenly gone empty?  That's because the user got
frustrated at the time cost of a very sophisticated algorithm.

>
>3- How OFTEN the signatures are calculated. It really isn't necessary to
>recalculate each and every signature every day, or even every time a
>program is executed. Sensible authentication frequencies will depend on
>the work environment, presence of known threats, and the value of assets
>controlled, but may average once or twice a month in typical business
>environments.

Every time the file is loaded.  Unless you'll guarantee the user, in writing,
that there is no chance the next time I run a program on a supposedly clean
system that I'm not running a damaging program.  Of course, if you'll
guarantee me that the system the user is on is clean and you'll also
guarantee me that the user has introduced *no* new program whatsoever
onto their system, well, maybe I can see your point.  Would you be willing
to guarantee this type of thing?

>
>4- The ALGORITHM chosen. Although its strength is not as well researched
>as DES, ISO 8731-2 has withstood at least some respectable public
>scrutiny, and runs at least ten times as fast as DES. Early indications
>are that SNEFRU is a very strong algorithm that is much faster than DES.
>RSA is much slower than DES. (And as I've consistently said since my
>earliest posting, CRCs of varying strengths are available and can be used
>in appropriate combinations with some of the more sophisticated algorithms
>to speed things up still further.)

Any two simple routines will outfunction a singular more complex routine.
A well known routine, no matter the nomenclature, is easily breakable by
anyone who a) understand the algorithm and b) has a dis-asm program handy.
Two differing methods, say a simply  checksum and a simple bit-add-rotate
will do the trick faster and be just as effective.
>
>By judiciously balancing these variables, it is possible to create a
>fast, reliable, sophisticated system that performs so quickly that users
>hardly notice it.

Interesting claim, but I've not seen usable proof yet -- usable to the real
world, that is.  I agree that complex algorithms will produce complex
results that are difficult to get around -- but so what?

> I have to agree with Ross Greenberg that a
>sophisticated algorithm that performs poorly won't get used at all, and
>is therefore worse than an unsophisticated algorithm. But I also know,
>from direct, first-hand experience, that we need not limit ourselves to
>thinking of sophisticated algorithms as being slow performers. All things
>considered, there is really no reason NOT to abandon the simplistic
>algorithms in favor of those that are likely to be beyond compromise by
>virus writers for several years to come.

I'd be interested in two things, both of which are (I think) easily available.
One:  timing results on real live files with anyone of the more sophisticated
routines you propose versus sime CRC and checksum, and Two: any proof at all
that one is going to prove more difficult than the other for a determined
bad guy with a debugger and the ability to do "MOV DS:[BX], OPCODE_FOR_NOP"
when they feel like it.

Ross M. Greenberg, Technology Editor, UNIX Today!   [e-mail]
             594 Third Avenue, New York, New York, 10016
 Voice:(212)-889-6431 BIX: greenber  MCI: greenber   CIS: 72461,3212
  To subscribe, send mail to [e-mail] with "Subject: Request"

------------------------------

Date:    Fri, 27 Jan 90 00:36:46 +0000
From:    utoday![e-mail] (Ross M. Greenberg)
Subject: Re: Signature Programs

[e-mail] (Bob Bosen) writes:
>When I began this in-depth series of discussions on authentication
>algorithms and signature programs late last year, I was alarmed and
>frustrated by the lack of attention being paid to the subject of well-
>researched "standard" authentication algorithms.

Bob continues, indicating that a bunch of people seem to agree with his
premise that sophisticated algorithms are inherently superior than the
less sophisticated ones.  As one of the named parties, allow me to
disagree, in part:  for authentication that need be done only once, let
the routine be as sophisticated as the data being authenticated need be.
For data that must be scanned and authenticated regularly, I think that
the expression "good enough" must come into play, alas.  Otherwise, the
100% authoentication method will turn to 0% as the user simply stops
using it.

Ross M. Greenberg, Technology Editor, UNIX Today!   [e-mail]
             594 Third Avenue, New York, New York, 10016
 Voice:(212)-889-6431 BIX: greenber  MCI: greenber   CIS: 72461,3212
  To subscribe, send mail to [e-mail] with "Subject: Request"

------------------------------

Date:    Sat, 27 Jan 90 10:47:00 -0500
From:    [e-mail]
Subject: STONED Virus data (PC)

Response to Dave Lovless at UWO and Peter Jaspers-Fayer at Guelph:

Explanation of what STONED virus does and step-by-step instructions to
remove that virus from a hard disk can be found in:

[1] COMPUTERS & SECURITY - Volume 8, Number 1 on page 11 [2] CAS -
Volume 8, Number 2 on page 97 [3] CAS - Colume 8, Number 5 on page 369

All are part of my "Bits & Bytes" column in the journal of IFIP TC 11.
Received the first copy of that virus directly from John Beatson of Data
Systems in Wellington, New Zealand in October 1988.  Data Systems is
similar to our Federal Reserve System, only run by the banks.  John is a
close friend and is Manager of Risk and Security.

Bill Kinny of Digital Dispatch, Inc., producers of Data Physician [I ran
a review of product in February 1988 issue] and Virhunt and VirRes [scan
programs] wrote piece on how to remove STONED virus from hard disk.  His
code was checked in real-time by me; I infected one of our machines and
used his "cure" program.

Complete information about STONED, aka Marijuana, New Zealand, is
contained on pages 61 through 70 of COMPUTER VIRUS HANDBOOK just
published by Oxford Advanced Technology Press [publishers of COMPUTERS &
SECURITY] located in Oxford, England.

David Loveless at University of Western Ontario has copies of CAS as
does Professor John Carroll at UWO.  John should have a copy of COMPUTER
VIRUS HANDBOOK within two to three weeks.

If anyone cannot get their hands on CAS issues, contact David, John or
me.  Both CAS issues and COMPUTER VIRUS HANDBOOK contain step-by-step
explanation of how virus code works.  The HANDBOOK also has this data
for some 20 additional common viruses plus other information about this
subject.

- ----------------------------------------------------------------------------
Dr.  Harold Joseph Highland, FICS [FICS = Fellow of Irish Computer
Society] Distinguished Professor Emeritus of SUNY Editor-in-Chief
Emeritus of COMPUTERS & SECURITY Managing Director of International
Institute for Information
     Security Education and Training Highland -at DOCKMASTER.NCSC.MIL
MCI Mail 406-5012 Voice contact for emergency:  516-488-6868 EST
- ----------------------------------------------------------------------------

------------------------------

Date:    Sat, 27 Jan 90 12:52:02 -0800
From:    [e-mail]
Subject: WDEF Virus in California (Mac)

One of our Macintosh microcomputer labs was target of the new WDEF
virus despite intense daily anti-viral measures.  This warning is
posted especially for the other universities in Northern California.
Our staff are developing measures against this new virus.

Gerry Gray
Academic Computing Department
Humboldt State University
Arcata, California  95521
[phone], 4207, 4208

------------------------------

Date:    Sun, 28 Jan 90 15:18:47 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: More about UVDs

                Can an Universal Virus Detector (UVD) be written ?

In order to answer this question, we need to define just what is meant by
the term "virus".

We can start with the definition by Fred Cohen, from his "Computer Viruses:
Theory and Experiments":

        "We define a computer virus as a program that can infect
         other programs by modifying them to include a slightly altered
         copy of itself"

This definition is not perfect.

        "program" should also include boot sectors, INITs and all
        other forms of executable code.

        "include" must also cover cases like the 405 virus, that
        overwrite the victim, and may destroy it completely.

        "slightly altered" is much too inaccurate. It is easy to imagine
        a virus that would only include a small part of itself in the
        programs it infects. See note #1 at the end for details.

But is this modified definition just what we want ?  Consider the following
program.

                Program P1
                Display "This is a copy utility"
                Display "Name of input file ?"
                Input In-File
                Display "Name of output file ?"
                Input Out-File
                Copy In-File to Out-File
                End

Is P1 a virus ?

Well, according to our definition, it is. If we give it the name of itself
as In-File and the name of some other existing program as Out-File, it will
behave just like any other destructive overwriting virus. Since P1 is able
to place a copy of itself within another program, it is (according to this
definition) a virus.

So, any UVD would classify the above program as a virus.  In fact, it would
classify most operating systems as viruses, since they can easily "infect"
other programs in the same way - you just have to give them the right sequence
of commands.  Any compiler used to compile a copy of itself would also
qualify.

        "COMMAND.COM is a virus"
        "csh is a virus"
        "C is a virus"
        "OS/2 is a virus"     I like that one.....   :-) :-)

But is this what we want ?  Well - hardly.

The major reasons for not wanting to call P1 a virus are:

        1) It asks the user for the name of source and target files.
        2) It destroys the "victim", instead of executing it more
           or less normally, after executing the virus.

Objection 2 is not valid - as mentioned before we already have some programs
like 405 and the AIDS virus (not to be confused with the AIDS trojan), that
work like that. They are labeled as "viruses" without hesitation.

Let's change the program a bit:

                Program P2
                Display "Name of output file ?"
                Input Out-File
                Copy P2 to Out-File
                End

                Program P3
                Display "Name of input file ?"
                Input In-File
                Select Out-File at random
                Copy In-File to Out-File
                End

                Program P4
                Select Out-File at random
                Copy P4 to Out-File
                End

We probably want our UVD to tell us that P4 is a virus, but also that
P2 and P3 might behave like viruses in some circumstances.

But, and this is the all-important question, is it theoretically possible to
write a UVD that will tell us if a program may behave as a virus under
some circumstances ?

The UVD must always return with a "Yes" or "No".

The answer is Yes, if we make some assumptions:

        The program which is to be examined will be called P.

        The computer P runs on will be called C.

        The environment of P will be called E.

        E is assumed to contain the values of registers, memory and data
        in external storage.

        P is assumed to be of finite size.  Writing a UVD for programs
        of infinite length is impossible.  It is left as an exercise to
        he reader to determine the result if we have a multi-processing
        system, with an infinite number of processors, each running an UVD
        and throw an infinitely long program at it. :-)

        E is also assumed to be of finite size, with a specified maximum.
        This excludes Turing machines.  Writing an UVD for a Turing Machine
        is impossible, just as solving the halting problem for it.  We can,
        however, in theory determine if a program will halt on some input on
        some specific real-world computer.

        All I/O operations consist of the transfer of finite amount of data.

        The UVD program runs on a different machine, C*.  This machine must
        be many orders of magnitude more powerful than C. In fact, if C is
        a simple machine like Sinclair ZX80, with 1K of memory, C* would
        need to be more powerful than all current supercomputers combined.
        However, we must not be distracted by small problems like that. :-)

The proof itself is not included, since it is too lengthy, but if there is
interest I'll make it available.


                        Note #1 - Multi-Part viruses

Let us imagine we have the following three program parts

        Part A contains the main program

        Part B contains procedures for locating programs and making a
               program memory resident.

        Part C contains a file I/O routines.

Let us then create two programs, one containing A+B and one containing A+C.
If we only look at one of them, it is unable to replicate and (by definition)
not a virus.

Now the fun begins.

If we run a program containing A+B, it will not infect other programs.
It will however, hide a part of itself, namely B, somewhere in memory. and
then execute the original program.

If we run a program containing A+C, it is also unable to infect other programs,
but it can check if B is present in memory. If so, then we can combine A, B and
C in memory and run the combined program. It will use B to find all programs
not yet infected. They will the either be infected (using C) with parts A+B
or parts A+C. Repeat this for all programs that can be found by B. Then

The "virus" here is the program containing A, B and C, but as I said I would
demonstrate, it does not just include a "slightly altered" copy of itself in
other programs, but rather just an "inert" part. The virus will only activate
when its parts are combined.

- -frisk

------------------------------

Date:    Sun, 28 Jan 90 15:23:56 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Three new viruses (PC)

New virus:  Devil's Dance.

    Even though the name sounds as if this is a complex and interesting
    virus, it is not so. This virus is a very simple direct-action .COM
    infector reported to be from Spain.  It will add 941 bytes to the end
    of any file it infects and overwrite the first three bytes with a JMP
    to the viral code.  The virus may infect the same file over and over,
    just as the original Jerusalem virus did.

    Those of you having a copy of F-PROT can add the following line to
    SIGN.TXT, in order to enable detection of this virus:

Dance       BEbjA5tjKtmmT5mX4Kurg8uIgum4J628UGYOVjk5LOeDVjimIp


New virus:  Virus101

    This virus is written by the author of Virus90.  According to the
    documentation file, some changes have been made. The virus is now
    supposed to infect .EXE files and the boot sector, as well as .COM
    files.  From the documentation file:

                     VIRUS101 is the "big brother" of VIRUS-90.

           VIRUS-90 was a true non-overwriting virus designed to operate
           under the PC-DOS/MS-DOS operating systems.  VIRUS-90 was
           specifically designed to give both experienced programmers and
           novice computer enthusiasts experience in dealing with computer
           viruses.  VIRUS101, like VIRUS-90, is designed to educate the
           public on computer viruses, but is aimed more towards the
           programming populace.

    The author also states that the virus is tamper-proof and disassembly
    resistant.  This is of course absolute bullsh*t - it would probably
    take an experienced assembly language programmer less than an hour to
    create a harmful variant of it.  At least it took me only a few minutes
    to examine Virus90 enough to be able to write a program to detect it and
    remove it from infected files.

    The copy I have is labeled as pre-distribution and does not work. Since
    I no not include non-working viruses (like Pentagon) in my anti-virus
    program, I will not include this one yet.

    The author states that Virus90 and Virus101 are harmless, and he even
    has the nerve to ask authors of virus detection programs to

        "mention that both VIRUS-90 and VIRUS101 are educational utilities
         and that I have designed them for the benefit of programmers"

    and

        "include a short description of the programs for the good of the
         programming public.  Thanks for your help on this."

    But, the fact remains that this is a virus, and could very easily
    be turned into a very dangerous one. So, as soon as I get a working copy
    of it, I will update my programs to detect and remove it.

    Still, at least the author has agreed to stop selling the sources.


New virus:  1260

    There is no doubt about it - this is the most interesting virus
    to appear recently. It uses an encryption method similar to that
    used by Cascade (1701/1704), but there is one VERY important
    difference: It is not possible to use ordinary identification strings
    to find infected programs, since the longest sequence of bytes
    identical in all infected programs has a length of three!

    To demonstrate the problem, here are the first five instructions from
    three infected files:

       INC  SI             CLC                   MOV  AX,86FA
       MOV  AX,F69F        MOV  DI,0147          MOV  DI,0147
       NOP                 INC  SI               INC  SI
       MOV  CX,0550        CLD                   CLD
       CLC                 DEC  BX               DEC  BX

   The first 39 bytes of the virus are not encrypted, but they only
   contain 8 instructions, with a length of 17 bytes, for doing the
   actual decoding.  The rest is just garbage, mostly one-byte
   instructions like NOP, CLC, STC, CLD, INC SI, DEC BX etc, that have
   no effect on the program, but are only meant to confuse.

   The last "feature", which nobody had expected is that the eight
   encoding instructions are not always in the same order, but may be
   permuted in 24 different ways.  My virus detection program was not able
   to handle that, so I will have to create a new version - expect it in a
   day or two.

   "1260" is a resident .COM infecting virus. Infective length is 1260 bytes.

- -frisk

------------------------------

Date:    28 Jan 90 20:00:00 +0700
From:    [e-mail]
Subject: The V651 virus (PC)

                            The V651 Virus
                            --------------

        This virus can be considered as a teaching example (a state of
the art) of how to construct viruses.  It is only 651 bytes long (I
have named it V651 or Eddie-2, you will see later why) but contains
solutions of almost all problems which a virus designer may encounter.

        The virus attacks both .COM- and .EXE-files.  They are
infected when you start them and the .EXE-files are distinguished from
the .COM- ones by the `MZ' marker in the first two bytes.  So you
cannot fool the virus by renaming your *.COM files to, say, *.CMD and
*.EXE to *.EXX and fixing the default extensions in COMMAND.COM.

        To be infected, the files must have a length larger than 651
and smaller than 64372 bytes.  The virus installs itself in the memory
by manipulating the memory control blocks, so it cannot be seen with
such utilities as the public-domain MAPMEM.  However, by using PC
Tools (F3, system Info), you can see that the amounts of available
memory found by PC Tools and by PC-DOS differ by 1 K byte (e.g., 640
and 639). (WARNING! I know at least 3 computers which show the above
difference but have no viruses --- maybe sometimes this difference may
be caused by the strange firm/hardware.)

        The virus' marker is like the one of the VHP-648 (Vienna A,
Austrian) --- 62 seconds in time-of-last-update field of the directory
entry for the infected files.  This makes possible to design a vaccine
(just like for the VHP-648 virus).  One has simply not to forget to
vaccinate both the .COM- and the .EXE-files.  I'm wondering why the
virus author did not made his virus three bytes shorter (which is
possible) --- just to make it look like the VHP-648 one.

        When in memory, this virus intercepts two PC-DOS functions ---
find-first (FCB) and find-next (FCB).  They return various information
about the respective directory entry --- its name, size, date and time
of last update and so on.  When an entry for an infected file is
encountered (which is recognized by the time-of-last-update field),
the virus changes the information in the `size' field, by subtracting
651 (its own size) from it.  So if you type DIR with the virus
resident in memory, you will obtain a directory listing with the
original (non-infected) file lengths.  This reduces the chances to
discover the virus.

        The virus has his own critical error handler, so you won't get
the "Abort, Retry, Ignore? " message when it tries to infect a write-
protected diskette.

        However, the virus' author has made two mistakes.  First, the
virus does not intercept the find-first/find-next functions which are
using the file handle (instead of FCBs used by DIR) method.  So, if
you look at a directory with a file-manager utility, you will almost
certainly notice the increased file lengths.  Second, if you already
have a small (under 651 bytes) .COM-file, which is vaccinated against
the VHP-648 virus and the V651 virus is resident in memory, you will
obtain a huge number for the file length when listing the directory
with the DIR command.

        The virus has no destructive functions.  In fact it does not
have any effects at all.  The string "Eddie lives" is contained in its
body but is never displayed.  (The string contained in the original
Eddie or Dark Avenger virus is "Eddie lives...somewhere in time!".)
Obviously, the author of the V651 virus was envious for the faith of
the Dark Avenger.  Of course, this reveals also the fact that this
virus was created in Bulgaria (I do not know its author).

        Just like the Eddie (Dark Avenger) virus, this one saves the
critical information from the infected files in the last 11 bytes of
its code.  They have the following layout:

                IP (2 bytes) - The contents of the IP field of the
                               EXE-header
                CS (2 bytes) - The contents of the CS field of the
                               EXE-header
                SP (2 bytes) - The contents of the SP field of the
                               EXE-header
                SS (2 bytes) - The contents of the SS field of the
                               EXE-header
                (3 bytes)    - The first 3 bytes of the file

        The (IP, CS, SP, SS) fields are used when an infected .EXE-
file is run and the last 3 bytes are for the .COM-files. So, if you
want to disinfect (cure? I'm not sure for the right word) an infected
file, you have to restore the original contents of the .EXE-header
(resp. - the first 3 bytes of the .COM-file) from the last 11 bytes
described above and then to shorten the file by 651 bytes.

                        Sincerely,
                                        Vesselin Bontchev

------------------------------

Date:    29 Jan 90 05:40:13 +0000
From:    [e-mail] (Gene Spafford)
Subject: Re: Virus vs. worm

hp-sdd!hplred.HP.COM![e-mail] (Jeff Perry) writes:
>   This is probably a simple question, but I haven't heard it asked (or
>answered). What is the difference between a virus and a worm?

Well, there are many differing definitions, with one extreme being
that all worms are viruses.

The definitions I think most people use are:

  A virus is code that cannot run on its own.  It is inserted into
another ("host") program, and cause that program to run the virus
code when the host is run.  The virus code, when run, will insert a
copy of itself in another "host," then possibly do some other task
(often known as the "manipulation" task), then possibly execute the
original host code.  Viruses are not self-contained programs.

  A worm is a program that can run by itself.  It is self-contained in
that it can run as an independent program.  It may use system programs
to propagate itself.  Worms travel (and possibly multiply) over
communications links.  They do not necessarily do anything other than
travel from machine to machine (or propagate around a network), but
they may also perform manipulation tasks, carry viruses, etc.

Gene Spafford
NSF/Purdue/U of Florida  Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet:  [e-mail]   uucp:   ...!{decwrl,gatech,ucbvax}!purdue!spaf

------------------------------

End of VIRUS-L Digest
*********************
Downloaded From P-80 International Information Systems 304-744-2253