To:	   VIRUS-L@LEHIGH.EDU
Subject:   VIRUS-L Digest V6 #73
--------
VIRUS-L Digest   Tuesday,  4 May 1993    Volume 6 : Issue 73

Today's Topics:

Detecting Mutations
Re: Human factor in infections
Re: Scanners getting bigger and slower
Re: Scanners getting bigger and slower
Re: Sending viruses over Internet/Fidonet
carobase & requests for info
Re: Can a virus infect NOVELL? (PC)
Re: On the merits of VSUM (PC)
Re: BeBe Virus (PC)
Re: COMMAND.COM Vaccination (PC)
Re: COMMAND.COM Vaccination (PC)
Re: F-Prot 2.07 (PC)
Re: On the merits of VSUM (PC)
Accidental Infections by ZIPs. (PC)
Re: Viruses which cost $$$ (PC)
VSUM reaches a new height of accuracy... (PC)
Hiroshima info wanted ! (PC)
Ongoing false alarms caused by DOS buffers (PC)
can't get unStoned (PC)
Stoned-B New Zealand VIRUS! (PC)
Re: ??Hidden file: 386spart.par?? What is this? (PC)
Re: ??Hidden file: 386spart.par?? What is this? (PC)
Re: ??Hidden file: 386spart.par?? What is this? (PC)
Evaluation standards - numbers again (CVP)
New Files on Risc (PC)
TBAV v6.01 anti-virus and new signatures uploaded (PC)

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.  (The complete set of posting guidelines is available by
FTP on cert.org or upon request.) Please sign submissions with your
real name.  Send contributions to VIRUS-L@LEHIGH.EDU.  Information on
accessing anti-virus, documentation, and back-issue archives is
distributed periodically on the list.  A FAQ (Frequently Asked
Questions) document and all of the back-issues are available by
anonymous FTP on cert.org (192.88.209.5).  Administrative mail
(comments, suggestions, and so forth) should be sent to me at:
<krvw@FIRST.ORG>.

   Ken van Wyk, krvw@first.org

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

Date:    Wed, 28 Apr 93 11:30:12 -0400
From:    Donald G Peters <Peters@DOCKMASTER.NCSC.MIL>
Subject: Detecting Mutations

We all know that Antivirus programs distribute "updates" which consist
of strings (probably encoded?) which allow your antivirus software to
detect the latest viruses.

But with the self-modifying viruses, this doesn't make sense to me. What
would have to be distributed would probably be *code* not *data*. Code
updates seem to be the only way to approach viruses which are now taking
anti-virus products into consideration! Have any antivirus programmers
considered this possibility/probability/inevitibability?

Wow. Imagine the medical community if they had to deal with viruses
which mutated every duplication and knew what the doctors were doing
and took efforts to defeat (indeed, EXPLOIT!) medical defenses. You
antivirus people have a tough job, especially on a single state computer
like the PC.

Of course, even in a machine with multiple states (eg, protected mode),
any program which has access to the boot device has a way to defeat
the system. I recently bought some old programs which require a diskette
to be inserted in the boot device in order to work. Even in a multi-state
computer, access to the boot device like this could give a program access
to the privileged state. What I'm getting at is that copy protection
and security seem to have a conflict of interests. I wonder if there
are any companies which still use copy protection but are also in the
anti-virus business.

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

Date:    Thu, 29 Apr 93 04:55:14 -0400
From:    frisk@complex.is (Fridrik Skulason)
Subject: Re: Human factor in infections

Inbar_Raz@f210.n9721.z9.virnet.bad.se (Inbar Raz) writes:

>I said I considered chances of infection of big companies were small.

Depends on what you mean - most big companies get isolated cases
every now and then...for example if an employee brings an infected disk
from home, but cases of massive, company-wide infection are rare....still,
they happen occasionally - the worst I have seen was somewhere around 20.000
machines infected in a single company.

- -frisk

- -- 
Fridrik Skulason      Frisk Software International     phone: +354-1-694749
Author of F-PROT      E-mail: frisk@complex.is         fax:   +354-1-28801


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

Date:    Thu, 29 Apr 93 05:02:51 -0400
From:    frisk@complex.is (Fridrik Skulason)
Subject: Re: Scanners getting bigger and slower

Inbar.Raz@p42.f100.n403.z2.fidonet.org (Inbar Raz) writes:

> > Generic disinfectors exist...

>How effective are they?

Well, they fall into two categories:

    1) CRC+database-based disinfectors, such as those in Untouchable and
       F-PROT Professional.  Basically they only work if you ran the integrity
       program before the files got infectred, and stored the right
       that is needed to disinfect.  Those disinfectors never make mistakes,
       but may not be able to disinfect all viruses.

    2) Emulation/single-stepping disinfectors.  Basically, the idea here is 
       to trace through the virus code until it has restored the original
       program and transfers control back to it.  Those disinfectors are
       interesting, but are still in the experimental stage.

- -frisk

- -- 
Fridrik Skulason      Frisk Software International     phone: +354-1-694749
Author of F-PROT      E-mail: frisk@complex.is         fax:   +354-1-28801


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

Date:    29 Apr 93 17:18:28 +0000
From:    pjj@cs.man.ac.uk (Pete Jinks)
Subject: Re: Scanners getting bigger and slower


frisk@complex.is (Fridrik Skulason) writes:
>the more viruses there are, the more time you'll have to spend
>searching, or, to put it in other words, there are more things to search for
>in every scanned file, that is, exclusive of various 'Turbo Scanning'
>techniques...)

	[I missed the start of this discussion, so I may be misunderstanding
	 what you mean, or you may already have discussed this, but...]

If you have a regular expression describing each viral signature (which is
what the signatures I have seen here seem to be) then it need take no more
time to scan for 1 virus or for 1000 viruses - you just have to preprocess
the signatures, using compiler-generator techniques. Is this what you mean
by "Turbo Scanning"?

Why would any virus scanner NOT do this? Is it to make it easy to check the
signatures for attack before running? I would have thought that
preprocessing them would make them easier to defend.

The scanner will get bigger as more signatures are processed, but the only
reason I can see why scanners should get significantly slower is if you have
to check more parts of the file/disc/ram etc. for new viruses.

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

Date:    Thu, 29 Apr 93 21:09:43 -0400
From:    tox@remarque.berkeley.edu ()
Subject: Re: Sending viruses over Internet/Fidonet

tck@fold.ucsd.edu (Kevin Marcus) writes:
>Peters@DOCKMASTER.NCSC.MIL (Donald G Peters) writes:
>>Of course, I have not yet seen 40-Hex. If it also contains material
>>on how to commit crimes (eg, I have seen an email mag which tells
>>people how to commit murders) then I may change my mind. Somehow
>>I don't think writing a virus is as bad as committing a murder.
>>Right now I would equate virus magazines with gun magazines. In
>>theory, no harm done. 
>
>Do you get guns with your gun magazines?  No.
>Do you get viruses with your virus magazines?  Yes.
>
I beg to differ-
In gun magazines, you don't get guns, at worst you get diagrams or descriptions
that you could use to fabricate a gun.
  
In virus magazines, you don't "get virii", you get the instruction/source
so that you can assemble/compile it. 

My point being, virus magazines listing source code are no more responsible
for the spread of virii than cooking magazines are for the spread of
salmonella.
 
Be seeing you,
	Tox



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

Date:    Tue, 04 May 93 05:46:14 -0400
From:    Big Foot <mdbois@hvlpa.ns-nl.att.com>
Subject: carobase & requests for info

        In Virus-L volume 6 issue v68 Vesselin Bontchev mentioned
        the CaroBase package.  It contains extensive information
        on [some] virusses, and a request was put out for people
        to send in carobase forms about virusses not yet entered
        and about new virusses [an empty form is supplied].

        Would it be possible to send a copy of such a form to this
        list as it's entered into the carobase. [e.g. by the
	maintainer[s] of the package].  This way people could check
	the information about the virus [opinions seem to differ]
	and the net load would be less because people don't have
	to FTP the package each time it's updated. [and how about
	when you don't have FTP at all ... :-( ]

- -- 
       Marc du Bois                                   .--------_____  _/
       Systems & Network operator EDP-CC              |__o       __ ==
       AT&T Network System Netherlands bv.             `---\\----



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

Date:    Wed, 28 Apr 93 23:44:25 +0000
From:    maniac@howlin.cs.unlv.edu (Eric J. Schwertfeger)
Subject: Re: Can a virus infect NOVELL? (PC)

bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes:
) From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
) Subject: Re: Can a virus infect NOVELL? (PC)
) Date: Thu, 22 Apr 93 09:38:34 PDT
) 
) kam.bansal@symantec.com (Kam Bansal) writes:
) 
) > famousee last words!). Novell is really good at stopping anything from 
) > changing a file that is read-only or the user only has read only rights. I'
) 
) No, if the file has the ReadOnly attribute set (and if the Modify
) right is granted to the file), a virus (and anybody else) can remove
) the attribute and infect the file. 

I think Kam was referring to trustee rights, not to file attributes.  In
that respect, he's right, but there are other ways around it.

) NLM infectors are possible in theory. It's a bit tricky to implement
) them - the SYS:SYSTEM volume is normally protected, and the format of
) the NLM is not that well known, and it operates in '386 protected
) mode, but nevertheless, writing an NLM infector is by no means
) impossible. Note however, that in order to spread, such virus must
) also infect something else - an NLM-only infector won't spread far...

Not knowing the NLM format, I can't comment on this, but I see no reason
for it not to work.  Interesting idea.  Especially with NetWare's special
load-executable calls, so the NLM could attach the virus code to the 
DOS executable only when a program is executed, and the viral code would
never appear in the executable itself, only in memory, until it gets the 
chance to infect something not on the Novell file server.  That would stop
all the current scanners, unless they looked for the infected NLM. The 
only problem I see is making the thing dual-modal, and still be small 
enough not to have problems propogating.  Jeeze, I've got a scary
imagination at times.

- -- 
Eric J. Schwertfeger, maniac@cs.unlv.edu


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

Date:    Thu, 29 Apr 93 02:54:21 -0400
From:    vfr@netcom.com (sOciaLly AdePt)
Subject: Re: On the merits of VSUM (PC)

i would like to gently point out that there is still that one
irritating documention existing, in the CVB program, re: the
text in the virus 'dedicated'. 

i was assured this would be corrected, but noticed it is still there:)

for those not knowing, suggest taking a look at the CVB, which although
incomplete is most excellent program..except for that one little 'bug' :)

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

Date:    Thu, 29 Apr 93 04:43:08 -0400
From:    frisk@complex.is (Fridrik Skulason)
Subject: Re: BeBe Virus (PC)

Inbar_Raz@f210.n9721.z9.virnet.bad.se (Inbar Raz) writes:

>2. The BeBe virus, for some reason, did not execute well. It hung the
>   computer. What's more weird is that if I load it to a debugger and STEP it,
>   it works. Even more weird is that if I load and GO, it hangs as well.

Hm...which Bebe ?  The 1004.A variant ?  (We also have Bebe.1004.B and
Bebe.486) Anyhow, I checked my notes...it replicated without problems
on my old XT test machine - I never tested them on the AT machine I
run viruses on as well.  Anyhow, the reason seems to be that the FAR
JMP instruction is located too close to the instruction that modifies
it, so if you single-step all is ok, but if you run it normally on a
'386 the (unmodified) instruction is already in the queue when it is
modified.

>3. I have a virus, aliased 'Brothers in Arm'. I was very suprised to find that
>   only SCAN has managed to find this virus

Eh, "only SCAN" ? Which scanners did you try, if I may ask ?  I expect
this is the Murphy.Brothers virus, which contains the text "Brothers
in Arm", 2045 bytes long.  As far as I know F-PROT has detected it
(and identified correctly) since version 2.01...more than one year
ago.

- -frisk
- -- 
Fridrik Skulason      Frisk Software International     phone: +354-1-694749
Author of F-PROT      E-mail: frisk@complex.is         fax:   +354-1-28801


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

Date:    Thu, 29 Apr 93 04:44:01 -0400
From:    duck@nuustak.csir.co.za (Paul Ducklin)
Subject: Re: COMMAND.COM Vaccination (PC)

Thus spake Jani_Patanen@f273.n220.z2.fidonet.org (Jani Patanen):

>Executables that have been compressed with PKLITE are basically immune
>to infection by viruses that infect executables, including COMMAND.COM
>in this case.  The PKLITE file can still be infected externally (as
>reported by McAfee's SCAN), but the actual executable cannot be infected
>in this form.

This is a silly, and misleading, statement. "Compressed" executables are
just executables -- and are *not* immune to infection. 

The statements "the PKLITE file can be infected externally" and "the
actual executable cannot be infected" are mutually contradictory. Once a 
program is "compressed" [with PKLITE, LZEXE, etc], the "actual executable",
from the user's point of view, is the compressed one. It has a different
form, to be sure, but identical functionality.

What is "external infection" if not simply "infection". Run an "externally
infected" file, and you've actuated the virus.

Paul

    /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \  Paul Ducklin                         duck@nuustak.csir.co.za  /
    /  CSIR Computer Virus Lab + Box 395 + Pretoria + 0001 S Africa  \
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/


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

Date:    Thu, 29 Apr 93 04:44:15 -0400
From:    duck@nuustak.csir.co.za (Paul Ducklin)
Subject: Re: COMMAND.COM Vaccination (PC)

Thus spake Jani_Patanen@f273.n220.z2.fidonet.org (Jani Patanen):

>Executables that have been compressed with PKLITE are basically immune
>to infection by viruses that infect executables, including COMMAND.COM
>in this case.  The PKLITE file can still be infected externally (as
>reported by McAfee's SCAN), but the actual executable cannot be infected
>in this form.

This is a silly, and misleading, statement. "Compressed" executables are
just executables -- and are *not* immune to infection. 

The statements "the PKLITE file can be infected externally" and "the
actual executable cannot be infected" are mutually contradictory. Once a 
program is "compressed" [with PKLITE, LZEXE, etc], the "actual executable",
from the user's point of view, is the compressed one. It has a different
form, to be sure, but identical functionality.

What is "external infection" if not simply "infection". Run an "externally
infected" file, and you've actuated the virus.

Paul

    /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \  Paul Ducklin                         duck@nuustak.csir.co.za  /
    /  CSIR Computer Virus Lab + Box 395 + Pretoria + 0001 S Africa  \
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/


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

Date:    Thu, 29 Apr 93 05:11:30 -0400
From:    frisk@complex.is (Fridrik Skulason)
Subject: Re: F-Prot 2.07 (PC)

Inbar_Raz@f210.n9721.z9.virnet.bad.se (Inbar Raz) writes:

>Hello Frisk.

>I did not like the fact that F-Prot 2.07 did not allow its extraction. I got 
>the archive from an FTP site, as a ZOO file. I extracted the archive, and 
>found out that F-PROT.EXE was compressed.

True.  There are two main reasons:

   1) by compressing F-PROT, I could fit the executables on a single 360K disk.

   2) I am trying to make life just a little bit more difficult for anybody
      who might want to try to disassemble my program or subvert it somehow.
      I am not saying it cannot be done...given enough effort, it would be
      possible, but if I stop 95% of the potential attackers, I am happy.

I put several layers of self-testing in the program, just in order to make sure
that the copy executed is identical to the copy that I release - which is why
I don't allow execution of the decompressed version. 

In other words - I don't want to have to "skip" version numbers, because
somebody released a trojanized version of my program, and I just try to make
doing that as difficult as possible.

- -frisk

- -- 
Fridrik Skulason      Frisk Software International     phone: +354-1-694749
Author of F-PROT      E-mail: frisk@complex.is         fax:   +354-1-28801


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

Date:    Thu, 29 Apr 93 05:25:13 -0400
From:    frisk@complex.is (Fridrik Skulason)
Subject: Re: On the merits of VSUM (PC)

bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes:

>Too many mistakes/incorrectnesses/incompletenesses for two "good"
>entries for two so common and well-known viruses, don't you think?

One comment - considering how incorrect/incomplete the information on those
common viruses is, it is perhaps not surprising that the information can be
outrageously silly in other cases....I haven't looked at VSUM for a long time..
does it still include the RAM "virus", for example ?

- -frisk

- -- 
Fridrik Skulason      Frisk Software International     phone: +354-1-694749
Author of F-PROT      E-mail: frisk@complex.is         fax:   +354-1-28801


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

Date:    Thu, 29 Apr 93 06:22:15 -0400
From:    S.M.Baines@sheffield.ac.uk
Subject: Accidental Infections by ZIPs. (PC)

Can I warn Virus-L readers of a possible method of infection that may
not have occured to most new users to PC's. I know this one as it
happened to me yesterday. I was wanting to print out my third year
project, it is rather large, and to fit it onto a floppy I had to use
PKZIP. I unzipped it at the university computer services, had to make
a few changes, printed it, and re-zipped it up. Whilst rezipping, I
zipped in another file as well by accident by not being to careful
with my switches. I unzipped it on my computer, and my memory
resident anti-virus software said it was Maltese Amoeba. No damage
was done, and I was lucky. *ALWAYS* be careful when zipping that your
zip file doesn't accidentaly zip another file with it. It may be
carying a dangerous payload.

Stephen Baines

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

Date:    Fri, 30 Apr 93 09:16:40 -0400
From:    "William Walker C60223 x4570" <WALKER@aedc-vax.af.mil>
Subject: Re: Viruses which cost $$$ (PC)

From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev):

> Peters@DOCKMASTER.NCSC.MIL (Donald G Peters) writes:

> > I think I recall seeing the following warning in one of my books:
> > "Improper use of this register may cause physical damage to your monitor."

> That information is a bit out-of-date. It was real, it was a hardware
> bug (in the controller for monochrome monitors, not in the monitors
> themselves), but those (buggy) controllers and not produced any more
> since a long time.

> > Am I correct, is there physical damage that can be done through
> > software?

> Not to the contemporary hardware.
 
I don't know which register Mr. Peters and Mr. Bontchev are referring to, 
but there were several registers in the monochrome controller (a 6845 
chip) which allowed harmful values to be entered (or should I say harmful 
combinations of values).  This was not a bug, but a feature of the chip.  
The IBM-style monochrome controller was not configured to use these 
combinations.  The Hercules monochrome graphics card (and the AST 
MonoGraph cards we had) WERE capable of using these configurations, 
generating 720x348 monochrome graphics.  However, not all monitors could 
take the resulting output.  The Amdek 310A amber monitors had to have a 
resistor snipped in order to be compatible with these cards without 
frying.  Many companies still sell 720x348 monochrome graphics cards, and 
I would bet that Amdek 310A monitors (and similar ones) would STILL have 
to have that resistor snipped to work with them.  I don't know for sure. 
Is there someone out there who DOES know?  

And BTW:
From:    Jeroen.Donkers@mi.rulimburg.nl (Jeroen Donkers):

> I remember to have destroyed a EGA Color monitor by installing MS-DOS
> version 4.0 on a Sperry HT (a XT from 1986).

I used those crummy machines back in 1984.  They were what we plugged the 
first AST MonoGraph cards into.  The green Sperry monitors worked 
unmodified, though, unlike the Amdeks.  

Bill Walker ( WALKER@AEDC-VAX.AF.MIL ) |
OAO Corporation                        | "Some days you just can't get
Arnold Engineering Development Center  |    rid of a bomb!"
1103 Avenue B                          |  -- Adam West, "Batman"
Arnold Air Force Base, TN  37389-1200  |



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

Date:    Fri, 30 Apr 93 11:12:54 -0400
From:    virus-l@lehigh.edu
Subject: VSUM reaches a new height of accuracy... (PC)

I just perused the "word from Patricia..." screen of the new [?]
VSUM. In it, I spotted the following words of wisdom:

    "The information in VSUM is accurate on the day of release;
     however, its accuracy degrades rapidly by an amount proportional
     to the elapsed time since release"

Not only is this false, since much of the information in VSUM is wildly 
inaccurate, but it is absurd. I'm intrigued to discover how the analysis
of a specific virus can "lose" accuracy over time. 

What's even more surprising is that, despite the claim of total accuracy
above, the "word" goes on to observe that:

     "a VSUM release might have some short-lived flaws"

Funny. First, VSUM is claimed to be accurate. Then, you're told that its
accuracy is rapidly and linearly decreasing. Subsequently, you learn that
it *isn't* totally accurate, but that its accuracy should be expected to
*improve* over time.

Cor.

Paul

    /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \  Paul Ducklin                         duck@nuustak.csir.co.za  /
    /  CSIR Computer Virus Lab + Box 395 + Pretoria + 0001 S Africa  \
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/


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

Subject: Hiroshima info wanted ! (PC)

hey there,

I had a friend who wanted information regarding the Hiroshima (sp?)
virus.  Where, when, what, how, and why, etc.

please send replies through e-mail:

	arunasal@egr.msu.edu


thanks kindly,
austin.


- -- 
- ---------------------------------------------------------------------------
Austin D. Arunasalam        |
arunasal@frith.egr.msu.edu  |     Signature file being remodeled.  
Michigan State University   |  	 	 


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

Date:    Mon, 03 May 93 12:56:52 -0400
From:    Martin Zejma <8326442%AWIWUW11@helios.edvz.univie.ac.at>
Subject: Ongoing false alarms caused by DOS buffers (PC)

Hello Community|

As always, a certain amount of the contributed mail consists of false
alarms, caused by various dumb scanners using simple pattern matching.
So I decided to try to find a solution to that still existing problem.
I dived deep into the miracles of Ralph Brown's interrupt description
(INTER33A-D.ZIP), but at a certain point there was somehow a dead end.
I've learned that, with dos loaded high , there is a one segment
workspace buffer in low memory. DOS also tells you the segment address
of that buffer, but no further description of the structure of it is
given. So I tried the same without dos loaded high, found the ring
buffer chain , and manually browsed through it. But the scanned boot
sector wasn't there, it was far below that buffer. Almost immediately
after the BIOS Segment. Why there and not where it should be??  I also
failed when searching for an implemented function to mark all buffers
as empty, to force DOS into rereading the wanted sectors.

Has anybody else encountered the same problems ?
Is there any other solution leading to the same goal ?

                                 Regards, Martin


+-----------------------------------------------------------------------+
| Martin Zejma                                  8326442@AWIWUW11.BITNET |
|                                            Martin.Zejma@wu-wien.ac.at |
|                                                                       |
| Wirtschaftsuniversitaet Wien  ---   Univ. of Economics Vienna/Austria |
+-----------------------------------------------------------------------+


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

Date:    Mon, 03 May 93 14:15:33 -0400
From:    esova@magnus.acs.ohio-state.edu (Edward R Sova)
Subject: can't get unStoned (PC)

I think I've got trouble trying to shake this stoned virus.  McAfee's
scan detected it, Clean supposedly did a job on it.  I've tried
FDISK /MSB.  I don't think things are back to where they should be....
How infectious is a boot sector virus like this?  Thanx..
Incidently a NAV norton Antivirus told me the virus was "Bloomington"

  ___
  \  \      Mr. Ed on rollerblades?  Nah, that's:
  _\  \      esova@magnus.acs.ohio-state.edu       Prodigy:CBGX09A
 \_____\       but his friends call him Ed,
 o o o o                    yeah that Ed Sova Kid, he answers to anything.


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

Date:    Mon, 03 May 93 16:24:26 -0400
From:    mcox@access.digex.net (Michael Cox)
Subject: Stoned-B New Zealand VIRUS! (PC)

Anyway, we got this virus on 3 systems and eradicated it with VPCSCAN from
DATAWATCH.

I was told that this virus can not attach itself to a 3.5" HD disk.  Is this
true?  If so, why can't it?

Mike
- -- 
Michael Cox                             Work:   mcox@access.digex.com
Amiga Conquers, AMOS Rules!             Play:   aj639@cleveland.freenet.edu
This space intentionally left blank     Fido:   1:109/456.0
        The text above is my own and all that other disclaimer junk


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

Date:    Mon, 03 May 93 18:36:31 -0400
From:    amn@ubik.demon.co.uk
Subject: Re: ??Hidden file: 386spart.par?? What is this? (PC)

Forked Tongue Redlich, <skank@leland.Stanford.EDU>, writes:
> I noticed this while playing solitaire on my PC (a 386).
> Nothing else was running, and I noticed that my hard disk had
> started doing something - I heard the noise it makes and saw
> the light buzzing.

This could be 'smartdrv' which can store up disk writes and do them
a minute or two later, (depending on the options selected).  Many hard
drives also move the heads occasionally to prevent 'hot spots', which can
heat and damage the disk surface.


> Since I found this unusual, I ran a virus check.  Found nothing.
> Except there was a new hidden file - in the root directory - 386spart.par
> ...

(Ken, I don't remember this being in the FAQ.  Would you add it please?)

Q   I have a hidden file, "386spart.par", in my root directory, which
    occupies several megabytes of space.  Does this indicate a virus?

A   No, it does not indicate a virus, it is used by Microsoft's Windows 3.x.
    In "enhanced mode" it can use this as a 'swap file'.  If you select a
    program that requires more RAM than is available, it attempts to make
    space by moving other programs into the swap file.  You have the option
    of a permanent or temporary swap file, (configured in 'virtual memory',
    from the '386' icon in the 'Control Panel').  A temporary swap file is
    preferred if you have little disk space, it is created and extended when
    needed, and deleted when you exit from Windows.  A permanent swap file
    (always called '386spart.par') is a little faster, and the sum of your
    RAM and file sizes is usually 16Mb.  (Check your Windows manuals for
    more detailed information).


I know this is a long answer with barely a mention of viruses, but when
I reassure people that '386spart.par' is not a virus they always demand to
know what it is!


Regards,
Anthony Naggs                 Email:                  Paper mail:
 Software/Electronics Engineer amn@ubik.demon.co.uk    P O Box 1080, Peacehaven
 & Computer Virus Researcher   [or xa329@city.ac.uk]   East Sussex  BN10 8PZ
 Phone: +44 273 589701                                 Great Britain


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

Date:    Tue, 04 May 93 00:33:00 +0000
From:    oep@colargol.edb.tih.no (oep)
Subject: Re: ??Hidden file: 386spart.par?? What is this? (PC)

Forked Tongue Redlich (skank@leland.Stanford.EDU) wrote:

: Since I found this unusual, I ran a virus check.  Found nothing.
: Except there was a new hidden file - in the root directory - 386spart.par
: I did a binary file edit but found mostly text and junk.  I couldn't

This is a file made by MS-Windows, and is a swap file. You can change the
size of this file in "Control Panel/386-Enhanced/Virtual memory"

(Ofcourse MS-Windows didn't tell you about this file, as Microsoft never 
dreamed about that anyone ever would like to deinstall their buggy DOS-
extender :-)

- - oep



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

Date:    Tue, 04 May 93 06:18:20 -0400
From:    v922340@herzberg.si.hhs.nl (Ivar Snaaijer)
Subject: Re: ??Hidden file: 386spart.par?? What is this? (PC)

skank@leland.Stanford.EDU (Forked Tongue Redlich) writes:
|> I noticed this while playing solitaire on my PC (a 386).
|> Nothing else was running, and I noticed that my hard disk had
|> started doing something - I heard the noise it makes and saw
|> the light buzzing.
|> 
|> Since I found this unusual, I ran a virus check.  Found nothing.
|> Except there was a new hidden file - in the root directory - 386spart.par
|> I did a binary file edit but found mostly text and junk.  I couldn't
|> find anything that hinted at a virus hidden in this 10 megabyte
|> file.  I wonder if it may just be a dump from shutting off the
|> computer in haste and having some program backup what's on - but
|> why a hidden file in the root directory.
|> 
|> Any help would be appreciated.

This file is created by the windows virus, espesialy the 386 enhanced mode
version. :-).

Don't worry, this is a "temporary" swap file created by windows as
virtual memory. You can change the size of this file by executing the
setup program (that little computer with the caracters on it, you can
change collors, desktop, sound and all other kind of stuff with it.
Just search in the main window) the icon you must have has the number
386, But !!! be careful when you change it because windows sometimes
gets a bad attatude when you do someting wrong.
 
|> Thanks,  Warren Redlich
|> skank@leland.stanford.edu

Ivar.

- -----------------------------------------------------------------------------
Rule one in program optimization : Don't do it.
Rule two in program optimization (for experts only) : Don't do it yet.
Rule three in program optimization (for athlets only) : Just do it.
- -- 
E-mail : v922340@si.hhs.nl    ... i can't help it, i'm born this way ...
- -----------------------------------------------------------------------------


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

Date:    28 Apr 93 14:53:00 -0600
From:    "Rob Slade" <roberts@decus.arc.ab.ca>
Subject: Evaluation standards - numbers again (CVP)

PRTAVS5.CVP   930425
 
               Evaluation Standards - Numbers again
 
We have tried to show some of the difficulties in choosing antiviral
software.  There are, of course, matters of the type, the test suite
against which the computer is effective, the user interface and the
"style" of the program or system.  Still, surely there must be
*some* standard by which to measure antiviral software?
 
In the computer world, the nice thing about standards is that there
are so many to choose from.
 
However you divide the different types of software, it is extremely
difficult to apply the same standards to various categories. 
Besides the problems of the "numbers game", in testing a given
program against a given suite of viral programs, the importance of
the test results are of different importance to a scanner, a change
detector, and an operation restrictor.  For operation restricting
software, it may be of no importance whatsoever that the program
does not "catch" infections; so long as the restricting software is
100% effective in preventing the spread of infection, it does not
matter whether it ever "identifies" any viri.  Change detection
software may "catch" all infections, and yet be less effective than
a scanner which catches only 90%, but effectively identifies them as
well.  (Unfortunately, one must also factor in the fact that change
detectors will generate a *lot* of "false positives", particularly
as software vendors continue to insist on writing programs which
modify themselves.)  Therefore, a single "numeric" standard, based
upon the use of a test suite, would be of little utility in
assessing the overall effectiveness of antiviral software.
 
In addition, the environment is constantly changing.  Not simply the
corporate or user environment, but the number, specific strains and
types of viral programs are increasing all the time.  One of the
newer types of viral programs, as of this writing, is the companion,
spawning or "precedence" virus, which, in order to prevent the
detection of a changed program, does not change the files on disk at
all, but rather takes advantage of the order in which programs are
"called for".  Thus those operation restricting programs which
prevent changes to program files become useless, as do change
detectors which peruse only those files in the database at the
previous "run".  Standards, therefore, which are based upon the
currently existing viral environment, will be very quickly outdated,
and mostly useless.
 
A single, or even multiple, numeric measure simply does not have
sufficient flexibility to gauge antiviral software.  It may be
possible to construct one, after considerable work.  However, even
if a criterion reference could be made broad enough to cover the
various types of antiviral software, the gauge would have to be a
moving one.  Thus, antiviral software tested at one point, would
have to be retested each time the standard was renewed: at a
minimum, that would likely be on a yearly basis.
 
copyright Robert M. Slade, 1993   PRTAVS5.CVP   930425

==============
Vancouver      p1@arkham.wimsey.bc.ca   | You realize, of
Institute for  Robert_Slade@sfu.ca      | course, that these
Research into  rslade@cue.bc.ca         | new facts do not 
User           p1@CyberStore.ca         | coincide with my
Security       Canada V7K 2G6           | preconceived ideas

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

Date:    Thu, 29 Apr 93 13:22:44 -0400
From:    James Ford <JFORD@UA1VM.UA.EDU>
Subject: New Files on Risc (PC)

The following files have been placed on risc.ua.edu (130.160.4.7) in the
directory /pub/ibm-antivirus for anonymous FTP.  Thanks to Jan van 't Ent
for the files.

- --------------------------- forwarded message ----------------------
Yet again, a new version of the ThunderByte antivirus utilities
has appeared, apparrantly immediately followed by a small change
in the signature file; see the whatsnew.601 for the details.
There's also a new version of Harry Thijssen's virus scanner.
The usual validate info to check whether the new .zips were
transferred correctly follows:

_filename_    _size_  _date_     _v1_  _v2_
tbav601.zip  267,835  4-25-1993  8EBA  056E
tbavx601.zip  75,870  4-25-1993  D42E  0BA8
tbsg601a.zip  22,466  4-27-1993  384C  1AA7
htscan20.zip  95,797  4-21-1993  D94F  0553

Oh, by the way, I checked the ESaSS BBS too, but there is no small
TBAV6xxU.ZIP with a diff/update from previous versions.


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

Date:    Sun, 02 May 93 01:34:03 -0400
From:    bondt@dutiws.TWI.TUDelft.NL (Piet de Bondt)
Subject: TBAV v6.01 anti-virus and new signatures uploaded to SIMTEL20 (PC)

I have uploaded to WSMR-SIMTEL20.Army.Mil and OAK.Oakland.Edu:

pd1:<msdos.virus>
TBAV601.ZIP     TBAV anti-virus software (complete pkg v6.01)
TBAVX601.ZIP    TBAV anti-virus - processor optimized versions
TBSG601A.ZIP    TBAV anti-virus new signatures. Adds to v6.01

Replaces:
pd1:<msdos.virus>
TBAV600.ZIP
TBAVX600.ZIP

Greetings,

Piet de Bondt                   E-mail: bondt@dutiws.twi.tudelft.nl
===================================================================
FTP-Admin for the MSDOS Anti-virus software, @dutiws.twi.tudelft.nl


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

End of VIRUS-L Digest [Volume 6 Issue 73]
*****************************************
