Received: from barnabas.cert.org by abacus.hgs.se (5.65c/1.5)
	id AA16900; Wed, 3 Feb 1993 21:01:52 +0100
Received: from localhost.cert.org by barnabas.cert.org (4.1/2.3)
        id AA25747; Wed, 3 Feb 93 15:04:17 EST
Message-Id: <9302032004.AA25747@barnabas.cert.org>
To: mikael@abacus.hgs.se, mil@solace.hsh.se
Subject: Re: issue 15 
In-Reply-To: Your message of "Wed, 03 Feb 93 20:31:24 +0100."
             <199302031931.AA14805@abacus.hgs.se> 
Date: Wed, 03 Feb 93 15:04:16 EST
From: Kenneth R. van Wyk <krvw@cert.org>
Status: RO

VIRUS-L Digest   Tuesday,  2 Feb 1993    Volume 6 : Issue 15

Today's Topics:

Virus Calendar
Measuring polymorphism
re: On the definition of viruses
Re: On the definition of viruses
Re: What is a virus ?
Re: Heuristic Scanners
Re:Mainframe viruses? [Sam Wilson:06/13]
+ - viuses
re: Os2scan checked (OS/2)
CANSU V-SIGN at GA Tech (PC)
DOS CHKDSK bug: How to show it with a small hard disk (PC)
(Re) Cansu virus plague revisited (PC)
Re: windows virus (PC)
DON'T DO THIS! (was: False positives, disk buffers, and IO.SYS) (PC)
Virus???? (PC)
VSHIELD, VIRSTOP, ... comparison ? (PC)
Re: NOINT Virus (PC)
PKZIP204e (PC)
Re: 696 Virus? (PC)
Re: False positives, disk buffers, and IO.SYS (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.sei.cmu.edu 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@CERT.ORG>.

   Ken van Wyk

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

Date:    Tue, 26 Jan 93 03:17:00 +0100
From:    Fil_Grushevsky@f0.n744.z9.virnet.bad.se (Fil Grushevsky)
Subject: Virus Calendar

Hello!

 > From: mdbois@hvlpx.ns-nl.att.com (Big Foot)

 >        I'm  trying to  compile a  calendar,  specificing just those
 > virusses
 >     that hit on [a]  certain day[s], like Payday on every friday except
 > 13th.
 >     I already have the list from VSUM.
A lot of "Soviet" viruses "love" xUSSR holiday (like 23 February, 1 May, 7 
November, etc.). If you like more information, ask please...
 >
 >     Third, a Dutch  magazine  mentioned the Hymn virus, which seems to
 > hit on
 >     the day with the same number as the month, so Jan. 1th, Feb. 2nd,
 > etc ...
 >     VSUM and F-prot did not know about it ?!?
Family of this virus contains 3 viruses (1865, 1962, 2144 bytes lenght) Virus 
infected Com & EXE files when file run, open, rename, create, change attr. 
Virus correct run only in DOS v3.30. Very dangerous viruses.When day = number 
of month, virus demage boot sector of "C" drive, display picture (some version)
and false play HYMN xUSSR.
 When boot sector demage by this virus:
- - boot up PC/XT stay impossible (!) from HD and from normal boot floppy. You 
need to create special boot disk with special boot sector.
- - on PC/AT and other PC with CMOS, boot up from HD stay impossible too, but 
you may boot up your PC from floppy disk with MS-DOS version => 4.0



Sincerely,
Fil Grushevsky

- --- RA-Echo/beta
 * Origin: MiKrOB Point (9:744/0)

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

Date:    Sun, 24 Jan 93 16:41:00 +0100
From:    Malte_Eppert@f6050.n491.z9.virnet.bad.se (Malte Eppert)
Subject: Measuring polymorphism

Hi Frisk!

 >    MtE: 174 lines

Wow! You managed to correctly scan any MtE mutation by using 174 wildcarded 
scan strings? I thought this was impossible, because the MtE makes viruses _
very_ polymorphic, and you must use an algorithmic approach?
Are you going to detect the TPE in the same way, with even more scan strings?

cu!
eppi

- --- Via SCANTOSS V 1.37
 * Origin: Another Virus Help Node - The EpiCentre! (9:491/6050)

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

Date:    Thu, 28 Jan 93 07:52:01 -0500
From:    fc@turing.duq.edu (Fred Cohen)
Subject: re: On the definition of viruses

Y. Radai <RADAI@vms.huji.ac.il> writes

>  Suppose a program contains code for replication, but only within a
>statement of the form "If <condition> then <replicate>", where
><condition> is something which depends on the run-time environment,
>e.g. on the input which a user supplies.  Can a detection program
>discover whether the program actually does replicate?

Only at runtime!

>
>  To illustrate the generality of the situation, I'll even offer a
>choice between three reasonable informal definitions of "virus":
>
>(a) a virus is a sequence of instructions which replicates on *every*
>    execution;

Replicates is probably not general enough - perhaps procreates would
be a better term - intending to include evolution.  Also, instructions
is a relative term.  I prefer to discuss sequences of symbols.  These
symbols can be interpreted by any number of mechanisms.

	This may seem subtle and unimportant, but it is vital to have a
`ground state' - something that corresponds to a physical reality, not
something relative to something else.  Instructions are different things
in different environments (e.g.  11101011 is a `jmp' on an 8080 and an
`addm' on a 6800), but symbols from the symbol set of the machine are
not (a 11101011 on either machine is still a 11101011). 

>
>(b) a virus is a sequence of instructions which replicates on *at
>    least one* execution;

Same as above, but add - if *at least once* does it mean that if a copy
program copied it, it would be a virus? Example: run your program which
halts, then later, someone copies it once, and bingo, it's a virus.  The
reason for *every* is that we can associate the replication property
with the virus and not the rest of the machine.

>
>(c) A sequence of instructions is a virus in a given run-time environ-
>    meant if and only if it replicates in that environment.
>

Looks better - same as (a) above.

>  If the decision is to be made by appearance of the program alone,
>then the simplest case is (c), for suppose that the program asks the
>user to supply two numbers, x and y, and <condition> is "x < y".  Then
>it is completely obvious that fulfillment of this condition cannot be
>determined without actually running the program, hence whether the
>program is a virus is undecidable by appearance of the program alone.

The problem is that in the Turing Machine model, there is no `input'!
All the information needed for the computation is on the tape and in the
FSM, and is thus provided a-priori.  Input is modeled as a preexisting
tape state.  The undecidability proofs I generated relate to ANY inputs
(i.e. any tape state can exist outside the virus).  They are thus `input'
independent.

>Note that this argument does not require the assumption that the
>computer has an infinite amount of storage, as Fred's proof does.

Sure it does - we can identify that under one set of inputs it's a
virus, and under the other it is not.  As we watch the inputs, there
comes a point in time when we say `VIRUS!!!'.

>  If the definition is (a) or (b), then we can do even better: we can
>show that in some cases the question cannot be decided even by running
>the program any finite number of times.  For example, suppose the
>program asks the user to input four positive integers i, j, k, n
>(where n must be > 2).  If you choose definition (b), I shall take
><condition> to be "i^n + j^n = k^n".
>
>  Now for all anyone knows, it may be that this condition is *never*
>actually satisfied.  (The statement that there are no such integers is
>Fermat's "Last Theorem", for which he *claimed* he had found a proof,
>but he didn't produce it and no mathematician since him has found
>either a proof or a counter example.)  Not only can we not decide this
>by appearance of the program, but even if we run this program a zil-
>lion times and the program doesn't replicate, that doesn't prove that
>it can *never* replicate; all one can say is that the program hasn't
>replicated *so far*.

Not right.  For finite sized systems, these problems are not unsolvable. 
They merely take a lot of time to solve.  We could literally try all
possible integers that could fit in the finite sized computer.

>  If you choose definition (a) instead, I take <condition> to be the
>negation of the above statement, and the same argument works.

Again not right for the same reason.

>  In any case, there are some situations in which you can't decide
>whether a given program is a virus.

All unsolvable problems of this sort depend on the size of the integers
being infinite. - As above.  There is no undecidability for finite sized
computers, and there can never be.

>  We can substitute for Fermat's
>Theorem any other unsolved problem.  If you could write a program
>which could decide whether the resulting programs are viruses, then
>you would become famous for having solved all the world's heretofore
>unsolved problems!!  (Well, at least those which can be expressed by a
>computer program.)  Thus it is intuitively clear that the property of
>virality is undecidable, at least for all practical purposes.

As above. Also, solving Fermat's last Theorum will neither make you
famous, nor solve all of the world's unsolved problems.  They used to
say the same thing about the 4-color graph problem, but some people
proved it with a computer theorum prover.  What was their name?

>  Of course, one can take the position that it's just an historical
>accident that these problems have not yet been solved, and that in
>principle they may all be solved some day.  However, it can be shown
>that there are infinitely many problems which can *never* be solved
>(although that apparently requires use of one of those "paradoxical"-
>type proofs which I've been trying to avoid here).

As I mentioned above, there is no problem that can *NEVER* be solved for
a finite machine.  Unsolvable problems only occur in infinite state
machines.

>  Comments are welcome (especially Fred's).

You should know better!

	A general comment may be in order here.  The problem with your
way of looking at this issue is that in order to make claims about
mathematical problems, you need a mathematical model.  Your model
isn't mathematical enough to do proofs.

	The reason undecidable problems are undecidable is that they CAN
NEVER be solved by ANY Turing Machine.  It does not depend on the state
of mathematics of the day or a proof not yet found or the number of
computations we can perform per unit time.  In that sense, it is an
absolute limit of the nature of the machine.  All of the realized
digital computers to date and all of the theorized finite discrete
valued computers fall into a subset of Turing Machines, and thus no
undecidable problem can be solved by any of them either.  That's why
the concept is so powerful.

	Instead of running to `unsolved' problems, it seems a much better
choice to run to `unsolvable' problems in your proofs.  That's why I
used the halting problem to show that virus detection is undecidable
rather than Fermat's last theorum.  I didn't want to show computational
complexity, but unsolvability.  If we use:

	If <some other Turing Machine halts> then <procreate>

we force the detection program to solve a potentially unsolvable problem.
In the proofs I wrote, I demonstrated a virus that could evolve ANY result
that ANY Turing Machine could compute - hence showing the generality of
viral evolution.  The dual purpose of this was to show that in order to
determine whether a program is a virus, we must be able to determine
whether ANY Turing Machine will halt.  Hence the undecidability of viral
detection.

	Perhaps a more interesting measure would be how much computing
power is required to solve the virus detection problem for a machine of
any given size.  This then is covered by the complexity theory in
widespread use.  Given some seemingly reasonable assumptions, we can
show that many types of evolution yield NP-complete detection.  I wrote
a paper on this (soon to be released?) in Computers and Security.  Most
of the problems you have described fall into that category, and are for
practical purposes unsolvable for most computers today.

	I am not saying that your presentation isn't interesting or
useful, only that when you try to get down to the mathematical level, it
runs into a brick wall.  The wall is made up of undefined terms and
loose assumptions.  It may appear to be easily bypassed, and many may
wish to walk through it as if it weren't there, but they may, in doing
so, make mistakes that result in real world decisions that are later
judged inappropriate.  Perhaps we will soon have zero-knowledge viruses!

FC
__________________________________________________________________________
8:30AM-2PM Eastern		Protection		2PM-8:30PM Eastern
US+412-422-4134			 Experts		   US+907-344-5164
	FAX US+412-422-4135 -OR- 907-344-3069 24 hours - 7 days
__________________________________________________________________________

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

Date:    Wed, 27 Jan 93 16:50:16 -0500
From:    Jerry Leichter <leichter@lrw.com>
Subject: Re: On the definition of viruses

In VIRUS-L Digest V6 #11, Y. Radai presents an argument that general virus
detection is impossible, for any reasonable definition of "virus", based on
code of the following form:

	if <condition> then <infect>

By making <condition> non-computable, Radai makes it impossible to determine
whether the code (ever | always | in some known set of circumstances) actually
<infect>'s, hence rendering any definition of "virus" that relies on being
able to prove that the program infects non-computable.

There are at least two problems with this approach:

	- It has nothing to do with viruses!  Suppose I attempt to recognize
		"programs that print the number 4".  What does "print the
		number 4" mean?  Well, it might mean "ALWAYS prints 4" or
		"SOMETIMES prints 4" or "in some well-defined circumstances
		prints 4".  But the program

			if <condition> then print 4

		cannot be computably tested under ANY of these definitions.
		The non-computability is in the <condition>; the fact that
		you can attach it to just about any predicate says nothing
		about the predicate.

	- None of the definitions that Radai gives really tell us what we
		really want to know about a program.  If the <condition> in

			if <condition> then <infect>

		can be satisfied, then certainly we don't want the program
		around (assuming <infect> is an operation we don't ever want
		carried out).  If we can prove that <condition> CAN'T be
		satisfied, then perhaps the thing isn't "really" a virus, but
		it's still dead code, and we'd prefer that it not be there.
		However, we can live with it.  (Such code can actually arise
		as the result of a successful disinfection.)  If we can't
		prove either that <condition> IS satisfiable, or that it is
		not, then I can't imagine any circumstances in which we would
		treat this as anything BUT a virus.

A reasonable PRACTICAL definition of a virus is that it is code such that
SOME path through it (which we cannot PROVE is impossible) infects.  Such a
definition is, unfortunately, dependent upon our current ability to prove
things.  The easiest solution is to remove that part of the definition:  A
virus is code such that some path through it (i.e., some set of choices of
choices at all conditions, even those choices that are "obviously" impossible)
infects.  You could formalize this by replacing your machine model with a
non-deterministic machine which, in effect, tries every possible choice at
every possible conditional.  Nondeterminism is intended exactly to model such
"there exists some path such that ..." kinds of conditions.

Note that I haven't attempted to define "infect".  That's where the real heart
of the problem lies, and that's where Fred Cohen's definitions and proofs
really come into play.
							-- Jerry


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

Date:    Thu, 28 Jan 93 13:00:08 -0500
From:    "William Walker C60223 x4570" <WALKER@aedc-vax.af.mil>
Subject: Re: What is a virus ?

There seems to be much confusion over what constitutes an accurate 
natural-language definition of a computer virus (confusion in general--
no one has any confusion over his own posting ;-) ).  Several writers 
agree that the mathematical definition is clear enough.  Maybe so, but 
many people don't (or won't) understand mathematical definitions.  I 
would like to define what I understand to be a computer virus (I'll put 
"virus" and "worm" in quotes to refer to the "popular" definitions, and 
virus without quotes to refer to Dr. Cohen's definition).  

As Padgett pointed out, Dr. Cohen's definition of a virus includes not 
only what is popularly known as a "virus," but also what is popularly 
known as a "worm."  The popular definitions separate the two by whether 
or not a specific "host" program is needed:  a "virus" needs a host 
program, a "worm" does not.  A host program could be an MBR/PBR or a 
stand-alone program.  A "virus" could gain control by overwriting the 
host, attaching to the host, relocating the host and taking its place, 
or by intercepting a call to a program without directly affecting the 
host.  A "worm" is a stand-alone program that is executed at some 
point, whether by the parent program, the user, or some other 
circumstance.  However, even by this definition there is still some 
confusion.  Some Macinstosh "viri" propagate by creating new INITs or 
other resources where none existed before, so even by the popular 
definition they should be "worms" instead.  At this point, the 
distinction between a "virus" and a "worm" blurs, and there should be 
one encompassing definition for both.

Well, here goes:

     A computer virus is a sequence of instructions which, when 
     executed under certain conditions, will make a functional 
     duplicate of itself and will place this duplicate where it will 
     intercept program execution at a later time under certain 
     conditions, and may or may not return control to the original 
     program execution at the point it was intercepted.  A virus may 
     also have additional functions, but only the above functions are 
     necessary for something to be called a virus.  

I believe that this definition will apply to all known "viri", and 
"worms" as well.  By "functional duplicate," I mean a duplicate which 
may not be an exact copy, but operates the same as the original.  This 
would allow for polymorphic and multipartite viri.  The key to this 
definition is "intercept program execution."  Most other natural-
language definitions say "attach themselves to other programs," then 
have to make exceptions for BSIs, companion viri, and others.  However, 
all viri must intercept program execution at some point and replicate; 
how they do it is irrelevent as far as the definition is concerned.  
Also, a virus does not have to return control at the point it 
intercepted it.  Overwriting viri are perfect examples of this.  They 
intercept a call to a particular program, but never return control to 
that program -- because it doesn't exist anymore.  

This definition seems to be free from subjectivity, so even Dr. Cohen 
might agree with it.  I don't expect it to remain unmodified, or even 
to survive at all, but I would like to see how it holds up under the 
intense scrutiny it's about to receive.

                "Incoming!"
                                "Fire in the hole!"

Bill Walker ( WALKER@AEDC-VAX.AF.MIL ) |
OAO Corporation                        |  This .signature does NOT contain
Arnold Engineering Development Center  |  a stealth .signature virus!
1103 Avenue B                          |
Arnold Air Force Base, TN  37389-1200  |

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

Date:    29 Jan 93 08:50:37 +0000
From:    frisk@complex.is (Fridrik Skulason)
Subject: Re: Heuristic Scanners

antkow@sis.uucp (Chris Antkow) writes:

> ...or anyone who wants to develop a better heuristic scanner! Gee
>you're paranoid...

Paranoid ?  Well, considering the discussion on some virus-exchange BBSes on
how to defeat my heuristic scanner, and considering that some of the latest
viruses contain code which only serves the purpose of confusing heuristic
scanners, I would rather say I was just being realistic.

After all, the original posting did not ask for information on how heuristic
scanners worked, what their limitations were or how they could be improved,
but how they could be defeated - which I am most certainly not interested
in helping anyone with.  

My heuristic scanner may not be foolproof, but it is is able to identify
the vast majority of new viruses (which regular scanners cannot do) before
they are run (which integrity-checking programs cannot do). Of course it is
not able to detect all viruses, without ever giving false alarms...(which is
theoretically impossible anyhow), but naturally, the virus authors see this
as a threat, and I am not going to do anything to make the life easier for
them - directly or indirectly...I hope you understand my position.

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

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

Date:    Fri, 29 Jan 93 05:21:28 -0500
From:    brunnstein@rz.informatik.uni-hamburg.dbp.de
Subject: Re:Mainframe viruses? [Sam Wilson:06/13]

Sam Wilson mentioned a "survey of 816 European and North America mainframe
sites (with) ...35.5% .. disasters .. 60% of which had been due to viruses".

Since about 10 years, I happen to supervise several large IBM mainframes for 
security and backup procedures, but I have NEVER seen, in several disasters
due to bugs, inadequately installed or used programs, hacker attacks and few
chain letter happenings, ***ANY real mainframe virus*** (I know of some tests
performed by some system engineers to see whether viral methods may work and be
detected but such "test virii" were carefully guarded). Did I really miss
real life experience? Did I miss reports in other European countries? Where to 
get the material which UK press reports? (Or may this be the same style as 
UK mass media report on their politicians -:?

Klaus Brunnstein, University of Hamburg (January 29,1993)



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

Date:    Fri, 29 Jan 93 06:32:16 -0500
From:    KARGRA@GBA930.ZAMG.AC.AT
Subject: + - viuses

Hi all,
2 things I'm missing in the discussion over viruses, benevolent or not:
a) is it necessary to perform a task
b) does it try to hide by all means

ad a) If a program needs a viruslike program ( can be a worm too) to do what it
      is supposed to do, and the manuals state clearly, that there is a part of
      this software acting on its own, then I would not call this a virus in a
      common sense.
ad b) If a program tries to hide by all means, then it is shurely a virus. This
      is somehow similar to some TSR's, but you can still use even the shurely
      not very sophisticated "MEM" to see it.
 JMHO, Alfred

###############################################################################
Alfred Jilka             #
Geologic Survey, Austria # Shall I raise the white towel or throw the flag ???
KARGRA@GBA930.ZAMG.AC.AT #
###############################################################################

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

Date:    Thu, 28 Jan 93 10:20:30 -0500
From:    KARGRA@GBA930.ZAMG.AC.AT
Subject: re: Os2scan checked (OS/2)

Hi all,
sorry, I was not clear enough on Cleaning Jerusalem. There WAS no, there IS no
and hopefully there WILL NEVER BE a jerusalem in my system. I tried to clean
a NONEXISTENT virus, just to see what will happen. OS2CLEAN reported correctly,
that no Jerusalem was found. So: no files were damaged...
BTW: I checked OS2SCAN once again with gammatech SENTRY on. It locks the boot-
sectors and some important files against writing to them. Everything was fine,
NO false errors or complaints about a locked file.
Alfred
###############################################################################
Alfred Jilka             #
Geologic Survey, Austria # Shall I raise the white towel or throw the flag ???
KARGRA@GBA930.ZAMG.AC.AT #
###############################################################################

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

Date:    Tue, 26 Jan 93 13:30:41 -0500
From:    keith.watson@stucen.gatech.edu
Subject: CANSU V-SIGN at GA Tech (PC)

I have had three confirmed reports of the CANSU or V-SIGN virus on the
Georgia Tech campus. At least one workstation in the computer science
department was infected. There is no formal reporting system on campus so I
suspect that this is just the tip of the iceberg.


Keith R. Watson
Georgia Institute of Technology, Atlanta Georgia, 30332-0453
uucp:  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!kw3
Internet: keith.watson@stucen.gatech.edu

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

Date:    Wed, 27 Jan 93 09:28:37 -0500
From:    fwf@gisa.uucp (Frank W. Felzmann)
Subject: DOS CHKDSK bug: How to show it with a small hard disk (PC)

>From:    padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
>         (VIRUS-L  Volume 5 : Issue 203)
>Assuming that this is causing the problem, DEBUG will find the
string:
>
> 8b 4f 0f 8b f9 (MOV CX,[BX+0F] MOV DI,CX)  .... in the "old" and
> 8b 7f 0f 32 ed (MOV DI,[BX+0F] XOR CH,CH)  .... in the "new"
>
>CHKDSK.EXE. Both are 16,200 bytes long.

This is also correct for the German version of CHKDSK.EXE,
(16,984 bytes long) at offset ds:2A4D.

You can force this bug also on a small hard disk (smaller than the
documented 128 Mb or multiples) by doing the following steps:

1.  Corrupt with a disk editor the FAT by changing the information
    of the first entries (e.g. write  "test" in hex dump sector 1 of FAT).
2.  Change the entry "number of sectors per FAT" in the boot sector to 256.
    (Hex address 16 17  to x'00 01')
3.  Boot the PC from a floppy disk
4.  Start the unfixed CHKDSK.EXE with parameter /F  - and
5.  You can see intensive writing on the hard disk:
    256 copies of 256 sectors (1. FAT copy), i.e. 32 Mb of unwanted 
    FAT copies are written out from the start of the first FAT.  

Frank W. Felzmann
- ----------------------------------------------------------------
G   German
I   Information         <>  Voice    +49-228-9582-248
S   Security            <>  FAX      +49-228-9582-400
A   Agency
- ----------------------------------------------------------------
   "It's a Snark!" ... Then the ominous words, "It's a Boo---"
- ----------------------------------------------------------------

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

Date:    Thu, 28 Jan 93 03:28:46 -0500
From:    schmitz@gisa.uucp (Hubert Schmitz - Bundesamt fuer Sicherheit in der I
	  nformationstechnik)
Subject: (Re) Cansu virus plague revisited (PC)

Here are some remarks about V-Sign-Virus (alias Cansu, alias Sigalit)

Description of the virus
V-Sign (alias Cansu, alias Sigalit) has two parts, the boot sector
and the  virus body. The boot sector contains only a short routine
(about 38  Byte), which  loads the  virus  body  into  memory  and
transfers control to it. The virus body is located in:

    Zylinder 0, Head 0, Sector 4 + 5        Harddisk

    Track 0, Head 1, Sector 2 + 3           5.25" DD
    Track 0, Head 1, Sector 13 + 14         5.25" HD
    Track 0, Head 1, Sector 4 + 5           3.5"  DD
    Track 0, Head 1, Sector 14 + 15         3.5"  HD

On floppy  disks these  sectors represents the last two sectors of
the root directory.

If control  is transferred,  the virus  goes memory  resident  and
hooks interrupt  vector 13  (for controlling  diskettes  and  hard
disks). After  this the virus restore the original boot sector and
transfers control to it. The PC normally boots.

Because there is a bug in V-Sign, floppy disks, which are infected
in drive  B: don't  work correctly.  If  you  boot  with  such  an
infected disk,  the virus  try's to  load the  virus body not from
drive A:  but also  from drive  B:. If  there is  not an identical
infected disk, you will get a System Hangup.

V-Sign has  two variants  which differs  in the  payload  trigger.
After 64  (variant 1)  or 32  (variant  2)  infections  in  a  non
interrupted system  (you don't  have to power down the PC) it will
display a "V" (Victory) sign on screen and the computer hangs.

To remove  the virus whitout any tool, cold boot the computer from
a noninfected, write-protected boot diskette first!
Format floppy  disks with  the option  /U. On  hard disks  use the
undocumented option /MBR with FDISK-command (FDISK /MBR, only with
MS-DOS 5.0).  This option  writes a  new partition  record without
changing the partition table.


About your problem
The virus is not transferred into memory only by executing the DIR
command on  floppy disks.  That means,  that  the  PC  is  already
infected (and  the virus  is active)  by executing DIR and running
McAfee's SCAN.
V-Sign goes  memory resident  only by  booting  from  an  infected
floppy disk or hard disk.

About SCAN - CLEAN
There are two possibilities

1. You run SCAN in a clean system (V-Sign is NOT in memory):
    SCAN reports  a virus  on a  floppy disk.  If CLEAN  warns you
    about "Virus  active in  memory", this is a false alarm. There
    is a virus image in memory (from SCAN), but not active.

2. You run SCAN in an infected system (Virus is active in memory):
    Then SCAN  reports the  virus in memory. If you run CLEAN now,
    it will also warns about "Virus active in memory".


Hubert Schmitz, GISA (German Information Security Agency)
Postfach 20 03 63
W-5300 Bonn 2
Germany                                       Internet: hsm@bsi.de


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

Date:    28 Jan 93 09:35:07 +0000
From:    frisk@complex.is (Fridrik Skulason)
Subject: Re: windows virus (PC)

S.M.Baines@sheffield.ac.uk writes:

>I am sorry to be a nuisance, but several users of Windows at Sheffield
>appear to have been hit by a virus that isn't detected directly. 

Which scanners have you tried ?

>Using
>memory resident virus checkers only detect a write to a protected file
>or disc, but not the name. Scanning the disc and memory also fails to
>show up the 'virus'. It appears only to infect the Windows files, and
>these fail to run. 

Now, this would rather seem to indicate that it was *not* a Windows virus,
but just a regular DOS virus, which was unable to handle Windows executables
properly, because it is not aware of the "new executable" format. 

- -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, 28 Jan 93 19:54:53 -0500
From:    Anthony Naggs <AMN@vms.brighton.ac.uk>
Subject: DON'T DO THIS! (was: False positives, disk buffers, and IO.SYS) (PC)

A. Padgett Peterson, <padgett@tccslr.dnet.mmc.com>, writes:
> [...]
>
> I have run some tests using SCAN (v95 and v100) and F-Prot  (2.05
> and  2.06a)  and in each case if a DIR was done  of  an  infected
> (STONED)  floppy prior to scanning, a positive indication of  the
> "virus in memory" was generated. If a DIR was done on a clean DOS
> partition thereafter (without reboot) memory came up clean.
>
> Next  I  tried  the following: did a DIR on an  infected  disk  -
> infection  warning was generated. Used debug to clear the  IO.SYS
> buffer  in  memory (again without reboot) -  scans  now  reported
> system OK. This was proof to me as to what was being detected.

And entirely to be expected if you read Microsoft's documentation,
(yes they have got somethings correctly documented, :-).
Try the "MS-DOS Encyclopedia" [Section I; Section II Articles 2, 3, 15],
or "Microsoft MS-DOS Programmer's Reference" [Chp 9], both from Microsoft
Press (distributed by Penguin outside North America).  Other sources
give similar or supplementary information.

> In no case was there any indication that the signature was  found
> in  low  memory  (segment 0000, first 64k)  rather  each  scanner
> finished its examination of memory and then reported the virus.

> For  some  time  we  have been  thinking  that  somehow  a  virus
> signature was being introduced into the disk buffers but the lack
> of repeatability caused much confusion. ...

Padgett, I am really most disappointed, you usually take the trouble
to research topics properly before posting.  I keep my PC clean, although
I have viruses stored on it, I only run a very small, fixed set of software.
So I don't often use the a-v utilities that I occasionally fetch from ftp
sites to distribute, otherwise I may have spotted some time ago this
misunderstanding about 'DOS buffers'.

> ...In no case in my  testing
> did  I  ever  find  a DBR in the  buffers,  only  root  directory
> entries.  However in every case following floppy disk  access  as
> described above, the DBR was found in the IO buffer in segment 0.

This is how DOS is designed, only the Block Device Drivers (ie those that
interface DOS to disks, tapes, CD-ROMS, etc...) actually check the DBR.
They may use the common temporary buffer provided by IO.SYS, or their own
private buffers.

> Just as a suggestion to a-v developers: since I have not observed
> any ill effects from clearing this buffer other that a reload  on
> the next floppy access and it is a source of false positives, why
> not just clear the buffer before starting a memory scan ?

Please, please, please DON'T DO THIS.

Firstly, it is very bad practice to mess with the private data of any other
program.

Secondly, Block Device Drivers use the data in this buffer to detect disk
changes - altering it may damage open files or make DOS unstable.

Thirdly, products that produce such a false alert demonstrate an inherent
weakness in their design.  It is surely better that developers understand
DOS properly when producing their products, than that they frig around with
other program's data to get around poor design and testing.

Hope this clarifies things a little,
Anthony Naggs
Software/Electronics Engineer                   P O Box 1080, Peacehaven
(and virus researcher)                          East Sussex  BN10 8PZ
Phone: +44 273 589701                           Great Britain
Email: (c/o Univ of Brighton) amn@vms.brighton.ac.uk  or  xa329@city.ac.uk

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

Date:    Fri, 29 Jan 93 05:23:18 +0000
From:    toejam@Panix.Com (Toejam)
Subject: Virus???? (PC)

	I was wondering if anyone has seen this before:
I turned on my PC a little while ago and.....what everyone fears happened,
it didn't boot all the way, it sorta hung in the middle of the BIOS.
Now this happen to me before about a year ago and it turned out to be a
virus I picked up from the wonderful user room at my school.  I eventually
got to the hard drive and tried to salvage what I could but most of the
files were corrupted, so I scrapped everything and started fresh.  
	Now the same exact thing happened this time but with one exception
2 of my drive partitions (which I salvaged with Norton) had address listings
where my files used to be.  The addresses listed were all in the local 
New York City area but I didn't know any of the people listed.  I don't
log into local BBS's at all and I'm positive I didn't have a record of
these address on my hard drive...so I'm assuming this was a side effect
of the virus.  BUT WAIT ...it gets even stranger... Since I didn't feel like
reinstalling all my files I decided to put it off for a day.....and today
everything is back to normal......no strange addresses all over the place
the files are all ok...everything booted up ok....this is driving me up the
wall..
Has anyone seen this before?  I think the first virus that
infected my machine was called Witch or the Bloomington virus or something
to that effect.  Norton AV didn't find anything when I scanned the drives.
Has anyone had these addresses appear on their screen.  Thanks for any help.

===============================================================================
||   L I V E   F R O M   N E W   Y O R K   I T 'S . . . - Alex Diamantis     ||
||------------------------------------------------\  Email: ToEjAM@pAnIX.cOM ||
||"I don't know if there are men on the moon, but   \________________________||
|| if there are, they must be using Earth as their lunatic asylum." - Shaw   ||
===============================================================================

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

Date:    Thu, 28 Jan 93 04:17:00 +0100
From:    Nemrod_Kedem@f101.n9721.z9.virnet.bad.se (Nemrod Kedem)
Subject: VSHIELD, VIRSTOP, ... comparison ? (PC)

Sorry for the delay in reply...

  > 3) VShield uses much more memory than VirStop.
 >>
 >>But may be loaded to high memory, and then needs less then 1K of
 >>conventional memory.

 > Implying that Virstop cannot?!  Virstop can be loaded high, and then
 > requires no conventional memory.

No, I'm not... I just wanted V.B. to know (or if he doesn't - then check) the 
many options VShield have. I, presonally, do not use any TSR against viruses. 
Instead I scan every diskette of program before running it.

 > And still, VSHIELD will use more high memory that Virstop, reducing the
 > number of other things you can have loaded high simultaneously.
 > Even with loadhigh in DOS 5.0, smaller is still better when it
 > comes to memory-resident programs.

Not always... Sometimes smaller meens less options (not implying anything..).

I prefer to keep the extra memory I have for more important things. I consider 
any TSR for a PITA. I run a very complex system and ALL TSR's made lots of 
problems conflicting with other programs.

I simply adopted the habit to check every program with at leats two virus 
scanners and with a CHK4BOMB program. I wasn't hit by a virus since there were 
two or three of them ...;-)


     Regards,
     Rudy.

- ----------------------------------------------------------
Nemrod.Kedem@f138.n403.z2.fidonet.org       (Nemrod Kedem)
FidoNet: 2:403/138    VirNet: 9:972/0    CI$ ID: 100274,73
(972)3-966-7562 (14.4K)            (972)3-967-0348 (Voice)
P.O.Boc 8394,     Rishon Le-Zion,   Zip 75253,     Israel.
- ----------------------------------------------------------

- --- FastEcho 1.21a/Real!
 * Origin: <Rudy's Place - VirNet, Israel> Make Safe Hex! (9:9721/101)

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

Date:    29 Jan 93 08:29:16 +0000
From:    frisk@complex.is (Fridrik Skulason)
Subject: Re: NOINT Virus (PC)

MCKNIGHM%UNION.decnet@gar.union.edu (UNION::MCKNIGHM) writes:

>Several of our lab machines have become infected with a virus that has
>been identified as:
>	NOINT (STONED)			F-PROT 2.05
>	A new variant of STONED		F-PROT 2.06
>	NOINT				CPAV (version that came with
>					      PCTOOLS 8.0)

>Why is F-PROT able to detect but not disinfect NOINT and are there plans
>for F-PROT to eventually handle the virus?

The reason that Version 2.05 identified the virus but 2.06 did not is
as follows: One of the changes between 2.05 and 2.05 was the addition
of a checksum-identification of boot sector viruses.  This was done to
provide accurate identification, which is necessary to properly
disinfect any virus.  Unfortunately, in one case Stoned.NoInt the area
the checksum was calculated for was wrong (it included a variable
byte), so in some cases the program would identify a Stoned.NoInt
infection as a "new variant of Stoned", and therefore refuse to
disinfect it.  This problem has been fixed, and 2.07, which is due any
day now does not have this problem.

- -frisk

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

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

Date:    Fri, 29 Jan 93 03:28:31 -0500
From:    Pim Clotscher <clotscher@coh.fgg.eur.nl>
Subject: PKZIP204e (PC)

L.S.,
Got PKZIP204e.EXE today, and remembering the discussions on this list
about  204c, I would like to know if this updated version (yes, it
claims the problems with 204c being solved...) is official and
reliable. No validate info was included. -AV verification upon self-
extraction lokked O.K.
Any info available?

Thanks a lot,

Pim Clotscher
Erasmus University Rotterdam - NL
E.R.C. - Computer Support Hoboken
E-mail (Internet): clotscher@coh.fgg.eur.nl



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

Date:    29 Jan 93 09:01:09 +0000
From:    frisk@complex.is (Fridrik Skulason)
Subject: Re: 696 Virus? (PC)

mark@walt.CS.MsState.Edu (Mark Rauschkolb) writes:

>A co-worker just told me that his home machine is heavily infected by
>the 696 virus (according to McAfee SCAN).  I looked for 696 in the
>VSUM "program" but could not find it.

To start with, there is no "696" virus - or rather, there are three viruses
which happen to be 696 bytes long.

The name "696" was originally used to refer to an East-European virus, which
is now properly known as "On 64".  This virus is now (V99) "identified" as
the FamR virus by SCAN.

The second "696" virus is one of the new PS-MPC-generated viruses - the "Page"
virus to be exact. I haven't checked what SCAN calls it.

What Scan calls "696" is a variant of the "Screaming Fist" family, the
Screaming_Fist.II.B variant to be exact.

- -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 Jan 93 09:09:56 +0000
From:    frisk@complex.is (Fridrik Skulason)
Subject: Re: False positives, disk buffers, and IO.SYS (PC)

padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) writes:

>the next floppy access and it is a source of false positives, why 
>not just clear the buffer before starting a memory scan ?

I have (mostly) fixed this problem in version 2.07 of F-PROT.  It will
now ignore boot sector virus signatures found in the lowest part of memory,
so just doing a DIR of an infected diskette and then running the scanner
should not produce this problem any more.

- -frisk

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

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

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

