Hacker Chronicles 2 (Alt)/The_Hacker_Chronicles_Volume_II-CD2.iso/virusl2/virusl2.249

Text File | 1995-01-03 | 29.3 KB | 696 lines

VIRUS-L Digest   Tuesday, 28 Nov 1989    Volume 2 : Issue 249

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

Today's Topics:

Re: Sophisticated Viruses (Mac)
seeking Gatekeeper (Mac)
'Tis the season
2600 VAX Virus (VMS) ?
Re: 80386 and viruses (PC & UNIX)
Re: Potential Virus? (Mac)
More on Signature Progs
More on the DIR.EXEC problem
EAGLE.EXE Trojan (PC)
Possible DIR EXEC Remedy (VM/CMS)
Questioning Netscan (PC - Novell)
Re: DIR EXEC (VM/CMS)
DIR EXEC revisited... (VM/CMS)
Linkable virus modules
stoned virus in partition table
Traceback (PC)
Re: Where did they come from ? (PC)
Re: Non-executable viruses
Eddie ? (PC)

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

Date:    Sun, 26 Nov 89 17:03:22 +0100
From:    [e-mail]
Subject: Re: Sophisticated Viruses (Mac)

[e-mail] (Chris Johnson) writes:

>There would be crashes because it's very common for software that
>patches traps to have interdependencies between its patches, i.e. one
>patch depends on data discovered and stored for later use by another
>patch.  Removing only a portion of such patches will be likely to kill
>the machine sooner or later.
> . . .
>Further, restoring traps to their original values is going to remove
>all of the patches put in place by the System itself - the patches
>that keep that machine running inspite of bugs in the ROMs, etc.
>Also, whole portions of the OS and Toolbox will be removed by
>restoring traps to their initial values (as taken from the ROM) - this
>will kill the machine for sure.
> . . .

So what if I remove system patches? You seem to think that I need to
call every little routine in ROM to do my dirty stuff. What I need is
say, ChangedResource, WriteResource and perhaps AddResource. What do
these traps have to do with OS traps? How many system patches are
there for these traps?  Do you *really* think that the ROM is truly
and utterly worthless without the system patches? Do you think they
wrote routines that didn't work at all and then patched them into
working? Why would I care if there is some small and obscure bug in
the ROM that could make my virus crash with prob. .000001%, after all
that is probably the whole idea with the virus after all!!

I don't claim that the ROM is bug free, but your indirect claim that
every trap is buggy is pretty heavy. (I got that from the "fact" that
everything will kill the machine "for sure", in case you wonder).

> . . .
>Writing well behaved patches is a black art on the best of days -
>writing the sort of un-patching patches discussed here would make that
>"black art" look like a carefree romp in the sunlit countryside.  I
>don't think such patches could be implemented safely, and I don't
>think anyone clever enough to do so would be wasting his time working
>on viruses in the first place.

This proves you've missed the point entirely. We're not talking about well
behaved viruses here. And just because you think no one would write one isn't
exactly proof that no one will...

>All in all, I don't think the techniques dealt with in this discussion
>are significant simply because there are too many reliability and
>compatibility problems intrinsically linked to them.

I do think they are significant though. The whole point with my post in the
first place was to make people realize that a virus could bypass the
protective fences of all anti-viral programs (including Gatekeeper) pretty
easily (theoretically anyway). What if a virus changed the resource map
directly without going through the ROM at all? We can't just rely on the
trivial and obvious protection that Gatekeeper et al. provies. What we need
is sophisticated protection schemes, and unless there's no discussion of
potential viruses we might never come up with these schemes in time.

>- ----Chris (Johnson)

/Christer

| Christer Ericson                            Internet: [e-mail] |
| Department of Computer Science, University of Umea, S-90187 UMEA, Sweden |
| "Track 0 sector 0 must *always* load into page 8!" -Krakowicz' first law |

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

Date:    Sun, 26 Nov 89 03:05:08 -0700
From:    Ben Goren <[e-mail]>
Subject: seeking Gatekeeper (Mac)

What's the easiest way to get a copy of Gatekeeper?  I haven't seen
any copies floating around campus here at Arizona State University.

Ben Goren
Bitnet:  AUBXG@ASUACAD

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

Date:    Mon, 27 Nov 89 08:36:29 -0500
From:    Kenneth R. van Wyk <[e-mail]>
Subject: 'Tis the season (yes 'tis)

This just heard on a local Pittsburgh radio station:

A company is selling a product called 'Safe Disks' (or some such)
which is a floppy disk condom.  The company is marketing it as a gag
gift for the holiday season.

Heavy sigh...

Ken

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

Date:    Mon, 27 Nov 89 14:56:52 +0000
From:    [e-mail]
Subject: 2600 VAX Virus (VMS) ?

I have just read "The complete Computer Virus Handbook" (issue 1)
written by David Frost.

In it, is described a virus called 2600 VAX virus. Basically a
programm which replicates itself and sends job requests to the batch
queue, which is a list of jobs awaiting execution. The so-called
"virus" caused the queue to overflow...

This was reported in a 1986 edition of the magazine 2600, a hacker
journal.

Well, to me it looks just like a recursive batch program. A two-liner.
We've often had students at our site writing this simple piece of
code, and submitting it to the queue. It surely wastes a lot of paper
(when printing the log files of the program), especially if run at
night, with no operator finding-out that the whole stack of paper
feeding the printer will be printed with garbage !

But does this simple piece of code really need to be mentioned in a
"Virus handbook" ? Did the next issues of this manual still mention
this ?

Olivier Crepin-Leblond, Computer Systems & Electronics,
Electrical & Electronic Eng., King's College London, UK.

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

Date:    27 Nov 89 19:55:29 +0000
From:    [e-mail] (Kelly Goen)
Subject: Re: 80386 and viruses (PC & UNIX)

Actually DOS/MERGE or VPIX is a somewhat cheap way to explore and test
viruses compared with the cost of some other environments that are
supposedly virus proof ... and you get unix to run along with
it!!!what a deal!! actually however you do have to make sure you leave
the permissions pretty much as distributed as peter has pointed out...
if dos programs are allowed to read and write normally(i.e. DOS) then
com and exe infectors can still infect...  int 13 and other
skul-duggery will be disallowed by the dos under *nix environment (you
wont get much in the way of system damage but you can look at the damn
things somewhat safely...I have done some experiments as to the
various possibilities for propagation and they do seem to be minimal
in this environment for general viruses(that does not preclude viruses
written to attack through 386 protected mode anomalys or COFF/*nix
based viruses....(and no I dont want to start a flame war about
whether those are possible or not...I am not speaking theoretically
here...))
    As to the environment its GREAT!!
     cheers
     kelly
                                    Kelly Goen
                                    CSS Inc.

DISCLAIMER: I Dont represent Amdahl Corp or Onsite consulting. Any
statements ,opinions or additional data are solely my opinion and mine
alone...

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

Date:    27 Nov 89 16:47:56 +0000
From:    oxtrap.oxtrap![e-mail] (Tim Endres)
Subject: Re: Potential Virus? (Mac)

[e-mail] writes:

   My question is: Should these programs modify themselves when I just
   run them.  All I do is run them and quit immediately and they are
   modified??? Do you think I have a virus problem???

   Joel Glickman
   Rensselaer Polytechnic Institute.

Many Macintosh programs modify their resource forks!
All of mine do. If the program saves any "state" for you it is most
likely storing the data in the RF. Rest easy. For now.

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

Date:    27 Nov 89 16:48:40 -0500
From:    Bob Bosen <[e-mail]>
Subject: More on Signature Progs

My epistle of several days ago regarding ANSI and ISO Message
Authentication Code (digital signature) standards generated quite a
few follow-up responses and other questions. Several people asked me
about my internet address. Most of you guessed correctly. I can get to
internet either via NCSC's "dockmaster" or through CompuServe.
Although CompuServe is more expensive, it is a lot more convenient for
me because I've got a "user-friendly" application for my PC that
automates most of my interaction with CompuServe.

What this means to internet users is that you can send electronic mail
to and receive mail from CompuServe subscribers IF both of the
following conditions are true:

1- You must know the CompuServe account (subscriber) number

2- The CompuServe subscriber must actively access CompuServe and
send/receive mail.

CompuServe subscriber numbers generally look a lot like mine
(71435,1777) and consist of two numeric fields separated by a comma.
In order to convert a CompuServe subscriber number into an internet
address, replace the comma with a period, and append the suffix
"@COMPUSERVE.COM". Thus, when addressing me through CompuServe, my
internet address is:

[e-mail]

A lot of other people sent me mail requesting ways to get hold of the
ANSI and ISO standards I referenced.

Copies of ANSI standard X9.9 can be obtained by sending $2.00 to:

ANSI X9 Secretariat

I am less familiar with ISO than with ANSI. I got my copy of ISO
8731-2 from ANSI because I am a member of the X9E9 working group. But
I believe you can get a copy of ISO standard 8731-2 by writing to:

Steve Wornick commented on the value of sophisticated,
cryptographically based signature programs as follows:

>  Bob Bosen brings up some interesting points, asking why programmers
>  writing authentification (sic) programs are utilizing CRC and
>  checksum algorithms rather than more sophisticated algorithms like
>  ANSI X9.9, ISO 8731-2, or DES. I think it depends on what you are
>  trying to do. If your plan is to encrypt your program and rely on
>  difficulties in decryption for protection against infection,
>  then it probably makes sense to use something very sophisticated,
>  because you want to make certain that no one but yourself can do
>  the decryption....  On the other hand, if you are not encrypting
>  your program but are simply trying to generate a number.... for
>  authentification (sic) purposes, I don't see that it is necessary
>  to use anything more sophisticated than a polynomial. If the virus
>  doesn't know your polynomial, then it's chances of guessing a
>  sequence of characters with which to "pad" your program file in
>  order to generate the same CRC value as the original unaltered
>  program is quite small. Of course, everyone ought to be using a
>  slightly different algorithm (i.e. different polynomials) and
>  ought to be hiding the authentication algorithm.

Industry-standard authentication algorithms such as X9.9 (DES based)
and ISO 8731-2 are NOT intended to encrypt files. They produce a short
"digest" or signature of information (in this case a program file).
Steve's suggestion that CRC algorithms can be sophisticated enough to
make guessing virtually impossible (if the algorithm itself is hidden)
MAY or MAY NOT be true. The risk that this assumption MAY NOT be true
is fairly high, especially if programmers rely on their own resources
on how to write a bunch of different yet "good" CRC algorithms. This
is even more true if the test is "on-line", because on-line
authentication implies on-line presence of the authentication
algorithm, where a sophisticated virus could determine the CRC
algorithm and/or associated initialization vectors (keys).

Today, in late 1989, Steve can make and defend the position that CRC
algorithms are good enough, especially if programmers are
knowledgeable about the security considerations, and if the signature
is calculated and verified "off-line" in environments where no virally
contaminated programs have a chance of grabbing executional control.
But in my opinion, this position is short-sighted. Who can say whether
the more sophisticated viruses of the future will attempt to analyze
CRC signatures or target specific products that rely on CRC methods?
Why not base today's protection on the best available and best
documented facts?  The newly emerging science of authentication
technology has clearly revealed that it is easier to compromise even
sophisticated authentication algorithms than previously thought.

David Paul Hoyt says:

>  Mr. Bosen points to very good documents that will point the serious
>  anti-viral minded software developers to an excellent method of
>  defending their software.... However, I would like to add a comment.
>  Any of these auth-check schemes rely on a small number (1 to n) of
>  of programmed checks to see if the software has been corrupted.
>  While this will defend against a general-purpose or unsophisticated
>  virus, it has little value against a malicious attack against
>  your product.

What kind of "malicious attack against your product" are you talking
about? Whatever it is, I'm sure the other members of the ANSI
standards (X9E9) working group and I would be very interested in
learning about it, because if this assertion is true, it could
possibly compromise the entire banking wire-funds transfer mechanism
that transfers billions of dollars every day. Are you saying you could
write or describe a virus that could infect a program but avoid
detection by an off-line ANSI X9.9-based message authentication code?
I'll acknowledge that this is possible with an on-line ANSI X9.9 MAC,
but it would take a lot of blind luck and something on the order of a
billion guesses. The consensus among standards organizations has been
that this is an acceptable risk in the case of the authentication
algorithms that have been studied and standardized.  As I said in my
earlier message, in my experience both on-line and off-line checks
have advantages and disadvantages, and a sophisticated defense must
allow users to pick and choose from all of these techniques according
to his needs. A heirarchy of interlocking defenses must be put
together, with on-line tests acting as the first line of defense, and
with periodic off-line checks. The on-line checks can detect the
viruses known today, and the off-line checks verify the integrity of
the on-line defenses and also protect against sophisticated future
viruses.

Bob Bosen
Vice President
Enigma Logic Inc.

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

Date:    Mon, 27 Nov 89 16:47:00 -0500
From:    <[e-mail]>
Subject: More on the DIR.EXEC problem

Apologies if this info on DIR.EXEC has already been posted (I hadn't seen
it before, though).

- --- Forwarded mail from Joachim Lohoff-Werner <C0030006@DBSTU1>

>From [e-mail] Mon Nov 27 16:08:24 1989
Sender: Computer Games List <GAMES-L@BROWNVM>
From: Joachim Lohoff-Werner <[e-mail]>

Hello *.*,

I have also received DIR EXEC and looked into it. After reading the
NAMES and NETLOG files and shipping multiple copies to the people listed
in these files it does something very bad:

The DIR EXEC asks for the system date (QUERY TIME) and erases all files
if the system date is greater then 89, i.e. next year.

Please discard all copies of DIR EXEC in your system RDR queue.

Kind regards, amicales salutations, cordiali saluti, shalom u'bracha,
freundliche Gruesse          Joachim Lohoff-Werner


- --- End of forwarded message from Joachim Lohoff-Werner <C0030006@DBSTU1>

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

Date:    Mon, 27 Nov 89 12:00:11 -0800
From:    <[e-mail]>
Subject: EAGLE.EXE Trojan (PC)

    The Jerusalem and AIDS viruses reported inside AXE'd files are
similar to dozens of other AXE'd viruses reported on Bulletin Boards
in the past 5 months.  Viruses discovered compressed in such files
have included 1701, 1704, AIDS, Jerusalem (over 20 samples), Vienna,
3066, Alabama, Dark Avenger, Yankee Doodle, Vacsina, Fu Manchu and
Datacrime I.  I'm not sure that developing identifiers for these AXE'd
files is the appropriate thing to do, since there are a virtually
unlimited number of hosts that may be included insidecompressed files.
Also, each version of AXE will produce different strings for the same
executable target.  So far, files like EAGLE.EXE have been treated as
trojans (even though they may contain replicating code) since the
compressed file itself cannot replicate.  Any string that identifies
the virus in the compressed form will not identify it in the free
form, and each virus has an uncountable number of potential compressed
identification strings, since each compressed infected host will be
different.  A thorny problem if we try to tackle it.  I don't believe
we should treat EAGLE any differently than GUNSHIP, BADGIRL or the
dozens of other compressed files that contain previously well known
viruses.
Tim Grant Curry
ICVI BBS Co-ordinator

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

Date:    Mon, 27 Nov 89 16:18:33 -0500
From:    "Gregory E. Gilbert" <[e-mail]>
Subject: Possible DIR EXEC Remedy (VM/CMS)

I adapted the following EXEC to help, possibly, in slowing the DIR
EXEC if it is still a problem.  Please note that I am unaware of any
problems with the EXEC, but it has not been what I would call
"extensively tested" (about 30 minutes in the making) so please do not
be upset at me if it does anything really nasty to some files.  It did
not do anything to my files.  (Above should be read "disclaimer".)

 ------------------------Chop Here if you wish--------------------------
/*  This EXEC was written by Karen Maloney and modified by Greg     */
/*  Gilbert to change any files with the filename of DIR and the    */
/*  filetype of EXEC to a new filename and filetype of TROJAN HORSE */
/*                                                                  */
/*  One can place "EXEC ANTIDIR" (quotes included) in one's         */
/*  PROFILE EXEC and have this EXEC executed upon loggin on.        */
/*                                                                  */
/* ------------------------------------------------------------------
  Note: Though we are unaware of any problems with this macro, we don't
  guarantee it in any way whatsoever and we assume
  no responsibility for any damage you may do with it.  ALWAYS HAVE
  BACKUP COPIES OF IMPORTANT FILES!!!!!
                                           - Greg Gilbert -
- -------------------------------------------------------------------- */
/*                                                                   */
"EXECIO * CP (STRING Q RDR ALL"
 if queued() = 1 then exit
 do i = 1 to queued()
 pull . spid . . . . . . . fname type .
 if fname = "DIR" & type  = "EXEC" then
 "CP CHANGE RDR" spid "NAME TROJAN  HORSE"
else nop
end
exit

 ------------------------------And Here---------------------------------

Gregory E. Gilbert
Computer Services Division
University of South Carolina
Columbia, South Carolina   USA   29208
[phone]
Acknowledge-To: <C0195@UNIVSCVM>

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

Date:    Mon, 27 Nov 89 15:40:00 -0600
From:    "David D. Grisham" <[e-mail]>
Subject: Questioning Netscan (PC - Novell)

        Has anyone bought and implemented the Novell scanning
program "netscan"?  We (UNM) are purchasing VIRUSCAN for a
few machines, at $15 per this is reasonable.  However, $1000
for a site license of NETSCAN is a bit steep.  We won't buy it
unless it is working at other institutions with great results.
Can you who do, please write me or post?
        I'd also like to hear if anyone can suggest a better
product.  Thanks in advance.
dave

  Dave Grisham, Security Administrator, CIRT      Phone [phone]
  University of New Mexico                        USENET [e-mail]
  Albuquerque, New Mexico  87131                  BITNET DAVE@UNMB

my comment for the day-
     It is to bad that the DOS world can't put out a product like
     Disinfectant (Damn good and free).  Do all the nice guys
     wear Macs?

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

Date:    Mon, 27 Nov 89 15:56:31 -0500
From:    Arthur Gutowski <[e-mail]>
Subject: Re: DIR EXEC (VM/CMS)

In Virus-L, v2i248, the following warning was posted:

>>Date:         Sat, 25 Nov 89 19:15:31 EDT
>>Sender:       Revised LISTSERV forum <LSTSRV-L@RUTVM1>
>>From:         "Juan M. Courcoul" <[e-mail]>
>>Subject:      IMPORTANT WARNING: CHRISTMA workalike on the loose on the links
...
>>A dangerous REXX exec named DIR EXEC has been detected on our node, thanks
>>to a watchful recipient. This exec purports to be able produce a directory
>>listing of the user's disks in a MS/DOS (PC) format.
>>
>>However, when the exec is run, it will produce the promised listing BUT it
>>will also send a copy of itself to all net addresses found in the user's
>>NAMES and NETLOG files.

From the cross-posting I got from IBM-MAIN@AKRONVM (IBM Mainframe
List), this EXEC also contains a timebomb: if the EXEC is run in 1990,
it will erase all A0 and A1 files from your account's A-disk.

I don't know if this thing has spread as fast as the warnings have,
but it may be worth the added info.

 Arthur J. Gutowski
 Antiviral Group / Tech Support / WSU University Computing Center
 5925 Woodward; Detroit MI  48202; PH#: [phone]
 Bitnet: AGUTOWS@WAYNEST1   Internet: [e-mail]
=====================================================================
 Disclaimer:  If VM is Virtual Machine, then I'm not really logged on,
              hence, I cannot have sent this message.

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

Date:    Mon, 27 Nov 89 18:04:00 -0800
From:    Pseudo Dragon <[e-mail]>
Subject: DIR EXEC revisited... (VM/CMS)

Apparently, the DIR EXEC everyone has been receiving is rather nasty.
Not only does it send itself to everyone in the files NAMES and NETLOG,
but also:
>The DIR EXEC asks for the system date (QUERY TIME) and erases all files
>if the system date is greater then 89, i.e. next year.

The advice given was:
>Please discard all copies of DIR EXEC in your system RDR queue.
(Quotes from: Joachim Lohoff-Werner)

I'd recommend editing this EXEC so that the spreading and damage part
is removed *completely*, make it read-only, and use it.  After all, it
*does* perform a useful function!  The only problem lies in getting a
bad copy again.  You'd be deleting your own files and starting another
outbreak!

So, once you've gotten it, *then* delete any more incoming (*bad*)
copies.  Just make @#$% sure your copy isn't going to erase your files
in 1990, or spread.

************ From the desktop computer of Charles Howes, [e-mail]
***** Mind you, I'm not using VMS myself.  These *are* only opinions.
***** Simon Fraser University, Vancouver, BC
***** "Unix is like sex; those who haven't tried it don't know what all the
*****  fuss is about; those who have, can't live without it."

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

Date:    Mon, 27 Nov 89 20:19:00 -0500
From:    IA96000 <[e-mail]>
Subject: Linkable virus modules

I have heard of, nor have I ever found any modules which were
specifically linked into a program, but I would like some of the
experts to comment on the following possibility:

1) A new or existing virus is developed and produced as a linkable
   object file.

2) Said object file is then either directly linked into an executable
   file at link time, or placed in a run-time library.

Is this even a remote possibility? If so, does anyone have any examples
or know of any examples where this has been done?

I would really like to gather opinions and comments on this possibility.

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

Date:    Tue, 28 Nov 89 06:25:28 +0000
From:    Tony Locke <munnari!extro.ucc.su.oz.au![e-mail]>
Subject: stoned virus in partition table

We have the stoned virus in the partition table of one of our hard disks
on an IBM-XT clone.

I don't know much about partition tables, but I've tried using
Nortons "WIPEDISK C:" and "SF C:" (low-level format program) both to no
effect. I've even deleted the DOS partition and re-created it.

Can I "wipe" this partition table and start again or do I need a program
to kill it ?

My floppy disk with dos 3.3 is uninfected and write-protected.

Sorry if this is yesterday's news but I'm not a regular reader of this
group.

Thanks in advance (email any help direct to me)

Tony Locke
Sydney University Computing Centre

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

Date:    Mon, 27 Nov 89 20:46:00 -0500
From:    IA96000 <[e-mail]>
Subject: Traceback (PC)

We recently ran into a problem. A user reported that a hard disk
drive in daily use, had only one file on it. The file was named
tracebck.com or another spelling of the virus name.

The disk label was @traceback and as mentioned all files were
deleted except the one file mentioned. SCAN.EXE identified the
Traceback virus as being present in the file.

Anyone recognize this? Unfortunately the user INSISTED that a
low level format be done on the disk, and could not wait for
someone with some knowledge to get there. The technician did a
screen dump of the SCAN.EXE report and then formatted the disk.

Does this sound familiar to anyone? If so, does the low level format
get rid of the virus? The files were restored from master disks and
as far as we know, the master are not infected.

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

Date:    27 Nov 89 21:19:53 +0000
From:    [e-mail]
Subject: Re: Where did they come from ? (PC)

In article <[e-mail]> [e-mail] (Fridrik Sk
ulason) writes:
>I am trying to compile a list showing where the various viruses seem
>to have originated. Here is what I have got so far, but I am sure the
>        Stoned                    New-Zealand/Australia

This virus was written two years ago in Wellington, New Zealand.
The author, who has been identified, was a high-school student,
who is now at university.  It seems that another individual
however was responsible for the spreading of the virus.

Geographical Note: New Zealand is *not* part of Australia.

Paul Gillingwater, Computer Sciences of New Zealand Limited
Domain: [e-mail]  Bang: uunet!vuwcomp!dsiramd!csnz!paul
Call Magic Tower BBS V21/23/22/22bis 24 hrs NZ+64 4 767 326
SpringBoard BBS for Greenies! V22/22bis/HST NZ+64 4 896 016

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

Date:    28 Nov 89 06:40:01 +0000
From:    carroll1![e-mail] (David C. Troup)
Subject: Re: Non-executable viruses


stanton![e-mail] (John Goodman) writes:
    [talk about a non-executable virus]
>Has anyone here seen such a virus?

Ive been working on several virus (or worms) for the Apple since I
read about them back in 86. Since all I had was an Apple IIe, I really
had to come up with some weird ideas for implementation for my
experiments.

What I came up with (in church one night!) was to use a text file that
could be EXEC'd from BASIC (or from the HELLO [startup] program on the
boot disk) that would execute the commands in that text file. This
text file would write a program to memory, that would go and patch
other startup programs with the text file, or a smaller version of it.
No assembly used (I was ignarant back then), and all of it was done in
BASIC with the EXEC'able text files. The programs were REALY difficult
to follow; commands that were writing commands to do DOS functions.
But it worked, and I infected an entire BASIC.101 class in 2 days. By
having the worms cross checking the copy counter (max==21), they
"knew" when they got everyone, and promtly killed themselves without
anyone knowing.

We got computers, we're tapping phone lines, I know that that ain't allowed_
    _______  _______________    |David C. Troup / Surf Rat_2600 hz__________
    _______)(______   |         |[e-mail] : mail______________
 _______________________________|414-524-6809(dorm)/7343(work)______________

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

Date:    Tue, 28 Nov 89 10:18:56 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Eddie ? (PC)

I was wondering about a text string that appears inside the Dark Avenger
virus:
                Eddie lives...somewhere in time

Wasn't there a character named Eddie in a horror movie ? If so, did this
sentence appear there ?

- -frisk


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

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