The World of Computer Software/World_Of_Computer_Software-02-387-Vol-3of3.iso/v/vl6-031.zip/VL6-031.TXT

Internet Message Format | 1993-02-24 | 36KB

Received: from fidoii.CC.Lehigh.EDU by abacus.hgs.se (5.65c/1.5)
    id AA25814; Wed, 24 Feb 1993 18:50:22 +0100
Received: from  (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA04204
  (5.67a/IDA-1.5); Wed, 24 Feb 1993 09:13:42 -0500
Date: Wed, 24 Feb 1993 09:13:42 -0500
Message-Id: <[e-mail]>
Comment: Virus Discussion List
Originator: [e-mail]
Errors-To: [e-mail]
Reply-To: <[e-mail]>
Sender: [e-mail]
Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas
From: "Kenneth R. van Wyk" <[e-mail]>
To: Multiple recipients of list <[e-mail]>
Subject: VIRUS-L Digest V6 #31
Status: R

VIRUS-L Digest   Monday, 22 Feb 1993    Volume 6 : Issue 31

Today's Topics:

re: virus-definitions
Re: my idea for detecting file infectors
Re: Virus education
Re: Scanners getting bigger and slower
Re: Scanners getting bigger and slower
Censorship
OS2SCAN V100 checked (OS/2)
Re: Help! Help, with FORM virus (PC)
Re: Jeruslem variant (PC)
Re: standardization (PC)
Re: Tokyo Virus in NETCB or a false positive? (PC)
Re: MtE Infected... (PC)
Re: Tremor (PC)
Re: F-prot/FSP/bootsum problem. Help! (PC)
Re: NAV questions (PC)
Re: standardization (PC)
Re: Help with FORM (PC)
Re: New Virus (PC)
Re: windows virus (PC) - is WALDO one?
Warning, logic bomb in PKZIP 2.04g, put there by PKWare

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 [e-mail].  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:
<[e-mail]>.

   Ken van Wyk, [e-mail]

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

Date:    Fri, 19 Feb 93 06:48:31 -0500
From:    [e-mail]
Subject: re: virus-definitions

Hi,
if we can't get Xcopy and Diskcopy out of this definition, then someone will
have to admit, that there are at least two benevolent viruses ....
Alfred

###############################################################################
Alfred Jilka            #This place intentionally left blank. This place intent
Geologic Survey, Austria#onally left blank. This place intentionally left blank
[e-mail]#. This place intentionally left blank. This place inte
###############################################################################

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

Date:    18 Feb 93 21:16:51 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: my idea for detecting file infectors

[e-mail] (Bill Lambdin) writes:

>This should detect any file infector except for stealth infectors.

Almost, but not quite - it will miss any "companion"-type viruses.

>This is my idea, and I want to think the following people to trying to
>shoot holes in my theory.
>
>Glenn Jordan
>Mike Lambert
>Wolfgang Stiller

Hey, why not me...*grin*...

I see a few problems....by including only a few files, there is a chance of
missing certain viruses...for example those which only infect files in
the current directory.  If none of your "victim" files happens to be located
in that directory.....well...then you would not find it.  You could of course
include *all* your executables, but that would mean a long delay, and a
significant waste of space.

Still, overall it is an easy-to-implement "early-warning" system.
- --
Fridrik Skulason      Frisk Software International     phone: [phone]
Author of F-PROT      E-mail: [e-mail]         fax:   [phone]

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

Date:    18 Feb 93 21:33:27 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: Virus education

[e-mail] (John Mechalas) writes:

>   I could write a program, for example, that interrupts all I/O
>access to the hard drive.

Technically no - you could not....well, maybe on a +386+, using protected
mode, debug registers and such...in general you would need hardware to
intercept all I/O.  Software can be bypassed.

- -frisk

- --
Fridrik Skulason      Frisk Software International     phone: [phone]
Author of F-PROT      E-mail: [e-mail]         fax:   [phone]

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

Date:    18 Feb 93 22:45:10 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: Scanners getting bigger and slower

[e-mail] (Gal Hammer) writes:

>Hi All,

>I was thinking (Not happen a lot, but...) if every virus have his own sig.

depends - some anti-virus programs use "generic" signatures - trying to catch
as many viruses as possible with any single one....other products rely on
highly specific signatures.

>and every week few or some viruses appers,

make that "every day" :-(

>So don't all the AnitViruses program will start to get bigger and slower ?!

Bigger, YES...slower, NO.  Why on earth should we use a time-linear (o(n))
search algorithm, when better approaches (like hashing) are available ?
Double the number of signatures, and the speed of any decent scanner will
hardly be affected at all.  There may still be some o(N) scanners around,
but that primitive technology is doomed...personally I dropped it in 1991.

- -frisk
- --
Fridrik Skulason      Frisk Software International     phone: [phone]
Author of F-PROT      E-mail: [e-mail]         fax:   [phone]

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

Date:    19 Feb 93 05:49:48 +0000
From:    [e-mail]
Subject: Re: Scanners getting bigger and slower

[e-mail] (Gal Hammer) writes:
>... if every virus have his own sig. and
> every week few or some viruses appers, So don't all the AnitViruses program
> will start to get bigger and slower ?!

The programs certainly will have more and more work to do, although
the increase in time need not be proportional to the number and size
of strings to look for.  Another problem is that the people who have
to create the scan strings get over-worked, have more "false
positives", less time to check them thoroughly, and the updates could
come further and further behind the discovery of the viruses.  I
wonder how Frisk, McAfee, and the rest survive the work load. I guess
they employ Santa's elves in the off-season.

Mark Aitchison.

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

Date:    Fri, 19 Feb 93 15:59:43 -0500
From:    Donald G Peters <[e-mail]>
Subject: Censorship

Someone said: (I'm not jumping on the author, I'm just trying to
restate my opinion that we must consider what should be discussed
on this forum and what should not...)

  > The most I can say, without
  > giving ideas to virus writers, would be...

The text which followed that quote was a nice LITTLE summary of
what viruses do. If the author was correct, and that was "the most"
that we are allowed to discuss here, then I would be gone.

However I think most people speak more freely than the above
author did, but perhaps not with enough liberty even then.

First, does anyone have any idea if there is any law that would
prevent anyone from posting virus source code on this forum?
Since this is an international forum, do we have to worry about
breaking other the laws of other countries? I thought it was
illegal in Canada to post virus code anywhere where it is
accessible by the public. If that were the case, would we
become "wanted" people in these countries??

Second, if there is no legal issue of any sort, at what point
does the moderator need to censor information? Someone told me
through email that they would not make any public references
to certain books because they don't want the bad guys to find
these books and learn from them. Is that really our right to
judge? If the information is ALREADY public do we have any
business censoring it? That tactic may work against the dumb
bad guy, but not the smart bad guy. Does educating the dumb
bad guy outweigh the benefits of educating the general public?

All I really want to know is whether there should be
guidelines for this matter. It seems to me that if we could
develop guidelines (and who would be all that much better
than us?) we could provide something of use to the computer
community as a whole.

I have NO objection to people keeping information private on
the basis of 'trade secrets'. That is, privacy because they
want to make money from their ideas. THat's fine. But very
often I see people saying (or implying) "I can't talk about
that here because that might give ideas to the bad guys."

With everyone making these decisions on their own, we will
probably all be shortchanged. We should either have a
guideline to decide by, or have one person make the decision
for us (eg the moderator). I prefer the former idea because
there is always the chance that the moderator could be a
bad guy himself (no offense, moderator.)

Since the techniques used by viruses are already widely
available, and are useful for people to know about in order
to set up defenses, we should never prohibit this information.
Even hypothetical virus behaviour can be useful for setting
up a defense. But "behaviour" can be considered to be a
"specification" for code, and in a few cases there are ways
to compile specifications into code, but not in this case.

Please feel free to propose things that we should NOT post
on this forum. I would agree to censor raw virus code but
would like to consider the value of censoring ANYTHING else.


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

Date:    Fri, 19 Feb 93 06:48:14 -0500
From:    [e-mail]
Subject: OS2SCAN V100 checked (OS/2)

Hi all,
again I was checking OS2-antivirussoftware from McAfee. First thing I found,
was that OS2VAL does not seem to be aware of its own name. The help-info
gives as example:
VALIDATE 0.5 for OS/2 Copyright 1988-92 by McAfee Associates.  [phone]

This program prints the validation information for a file.
Examples:
          VALIDATE SCAN.EXE
          VALIDATE SCANRES.EXE
And BTW: Why should I validate SCAN ? I think this should be OS2SCAN...
The doc's really give a false sense of security. But Vesselin already took
the word from my mouth.
OS2SCAN:
Documentation:
          ~     The /SAVE switch does not modify the OS2SCAN.EXE file.
                Instead, it creates a SCAN.INI file.
                                      ^^^^^^^^
This should read: os2scan.INI (a copy of what a DIR showed me in a window)
Program:
Though gammatech "sentry" is always active to lock bootsector and various
files against tampering, OS2SCAN behaves well. (at least on HPFS-drives.)
The program however still does not check DLLs by default. Thus it is still
necessary to save additional extentions (ADD(AdapterDeviceDriver=Basedevice),
DMD(DiskManagerDriver=Basedevice),DLL(DynamicLinkLibrary)) which contain
executable code, where ADD and DMD probably will be locked by the system, but
you never know if it was not already infected when you got it. Even if there
is currently no specific OS2-virus, DLLs might have been damaged by a silly
DOS-based virus.
Another thing is, that still the option exists to modify all executables by
adding checksums. The documentation points out, that there are several
programs, where you must not do this, as they are already selfchecking:
         NOTE:  Files which are self-checking (e.g., Lotus 1-2-3) should
                 not be validated with the /AV (Add Validation) or /AG
                 (Add Generic) switches which modify files.  Instead, use
                 the /AF (Add File) switch.
So please tell us all: why do you still maintain these modifying options ??
To me it is a strange philosophy. Your customers don't want, that something
tampers with their programs and data, you give them the means to reach the
goal, but tamper with their programs yourself!
You seem to be aware of the problems ! And I still can't understand the use
of
          /RF {filename} - This option removes recovery and validation
          data from log file {filename} created by the /AF option.
Is it not sufficient simply to delete this file ?? Or does /AF modify some-
thing in a way, the user should not know ?
HPFS seems to be supported very good, as this is one of the first shareware-
products I have seen, which support long names(i.e. are not restricted to
8.3 filenames.) '/AF rec.data' works perfect!
For some mysterious reason, option /DATE still refuses to create a
SCANVAL.VAL file on the directory, where OS2SCAN resides. It is not in a
rootdirectory too. Neither hidden nor something else. :( Thus option
/SHOWDATE still fails. :( Again: In my review of version 99 I suggested to
put it in your INI-file, where the date is relatively save from being
changed unintended by the user.
          Do not use the /SUB switch if you are scanning a drive
          from the root level.
Could you tell me why ??? I tried OS2SCAN C: /SUB and OS2SCAN C:\ /SUB,
apparently there is no difference.(Maybe an unconfirmed slight speedimpact)
The description seems to be better in OS2NSCAN.DOC.
I know, that computerists usually tend to shortcut whatever they can, but
here is a way to tell people about OS2 and long filenames, instead of 8.3:
OS2SCAN C: /NOPAUSE /REPORT A:INFECTN.RPT
                              ^^^^^^^^^^^ How about A:INFECTION-REPORT
This should be improved, as you have a (useless) /RF option too:
          In addition, the
          SCANVAL.VAL hidden file containing validation codes for the
          partition table, boot sector, COMMAND.COM, and system files may
          have to be replaced (unhide the file with the ATTRIB command
          and then delete it).
Why must a user unhide and delete this file. Either there should be a new
option to delete it or it is updated like the INI-file or the /AF file.
Your important note on false positives has a better place at the beginning
of the docs. People hardly read them anyway, and will shurely miss such a
note if it is at the very end.
OS2NSCAN:
Program: This program already misses switches /AG and /AV and the related
ones. (according to the docs) I suppose, this is due to the networking
environment, that you do not change other peoples data. Anyway: it would be
a step in the correct direction. However: the helpscreen shows this:
     \                  - Scan root directory and boot area only
     /A                 - Scan all files, including data, for viruses
     /AD                - Scan all local hard drives
     /AF filename       - Store recovery data/validation codes to file
     /AG filename       - Add recovery data/validation codes to specified
                          files EXCEPT those listed in filename
     /AV filename       - Add validation codes to specified files EXCEPT
                          those listed in filename
As I don't want to alter my files, I won't test it. But maybe Mr.Goretsky
can clarify.
Regarding default-extentions the same applies as in OS2SCAN.
As I go through the docs, I start wondering, why there is no OS2NCLEAN ?
The docs suggest to use OS2CLEAN, if an infection is found with OS2NSCAN.
In order to read files on a network, you need a special version of OS2SCAN.
In order to write to files on a network you do not ??! I'm not a specialist,
but this is a thing I can't understand ... >:] (Hard thinking smiley)
Somehow this program was 'improved';) Now you can't run it anymore if there
is no network present, which was perfectly possible in version 99. At least
the computer is not dead-locked anymore, like it happened with NSCAN for DOS.
Docs: There is something mysterious:
          Options are:

          \                - Scan root directory and boot area only
          /? /H or /HELP   - Displays help screen
          /A               - Scan all files, including data, for viruses
          /AF {filename}   - Store recovery & validation data to {filename}
          /BELL            - Beep whenever a virus is found

               Following is a detailed description of OS2NSCAN's options.
          Please note the /AF and /AG switches modify executable files.
          This may cause other anti-viral programs to generate a warning.

/AF does NOT modify files, does it ? /AG does not exist according to the
available options. So how do I understand this difference ?
/SAVE     The options are stored by creating a
          file named NETSCAN.INI in the same directory as OS2NSCAN.EXE.
                     ^^^^^^^^^^^
I found the INI to be named:
18.02.93  22.25         33           0  os2nscan.INI
Once again: The important note should be placed at the beginning, not at the
end, where hardly any user reads it.
OS2CLEAN
Program:
Docs:
VIRLIST.TXT:
>For replacing the MBR code  on MS-DOS 5.00 partitioned hard disks, use the
>FDISK.EXE program with the undocumented /MBR switch.
This is somehow not precise: you can use MSDOS 5.0 FDISK /MBR for any DOS-
formatted HD if it does not use special diskdrivers to circumvent DOS-
limitations.

This is all for today, Alfred

###############################################################################
#
Alfred Jilka             #This place intentionally left blank. This place inten
t
Geologic Survey, Austria #onally left blank. This place intentionally left blan
k
[e-mail] #. This place intentionally left blank. This place int
e
###############################################################################
#


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

Date:    18 Feb 93 21:28:45 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: Help! Help, with FORM virus (PC)

[e-mail] writes:

    [F-PROT pricing info deleted]

>(There, now I've said it.  You don't have to violate network
>advertising guidlines, Frisk.)

Thanks for the free advertising.... :-)

Anyhow, if you are dealing with FORM, be sure to use version 2.06 or later
(2.07 is the latest)....There was a FORM-related bug in earlier versions - it
would sometimes refuse to remove FORM from hard disks, claiming it could not
locate the original boot sector.

- -frisk

- --
Fridrik Skulason      Frisk Software International     phone: [phone]
Author of F-PROT      E-mail: [e-mail]         fax:   [phone]

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

Date:    18 Feb 93 21:36:52 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: Jeruslem variant (PC)

[e-mail] (Le L. Chen) writes:

>can not understand how come the first time checked it was ok, later,
>after the computer was infected, it can detect them.

one possibility is that you might have some virus "dropper" program - a
scanner might not find a virus hidden inside it...then you run it, and the
virus goes resident, infects other programs, and the next time you run the
scanner it would find the other infected files.

Another possibility is that the virus might be hiding in some overlay file,
that is not scanned by default.  Try scanning *ALL* files.

- -frisk

- --
Fridrik Skulason      Frisk Software International     phone: [phone]
Author of F-PROT      E-mail: [e-mail]         fax:   [phone]

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

Date:    18 Feb 93 22:13:06 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: standardization (PC)

[e-mail] (Bill Lambdin) writes:

>I feel that the authors of scanners need to get together, and agree on a
>naming system.

We did....more than a year ago...:-)

Actually, there is a *semi-official* naming standard...the CARO naming scheme,
which unfortunately is not used by all the programs on the market.  Even
the programs that try to stick pretty close to it, like Dr. Solomon's
Toolkit, and my own F-PROT do not always agree 100%, but we are at least
trying.

There are some programs that don't use this naming standard.  In some cases
they have just not gotten around to it...in other cases you may have a package
which is very good at detecting viruses, but not-so-terribly great at
distinguishing one virus from another - if the scanner does not even know
what virus it is deling with, how can it be supposed to name it correctly ?
Finally, the author(s) of the package may just not like the CARO name
structure, which sometimes can produce quite long names.

- -frisk
- --
Fridrik Skulason      Frisk Software International     phone: [phone]
Author of F-PROT      E-mail: [e-mail]         fax:   [phone]

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

Date:    18 Feb 93 22:33:57 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: Tokyo Virus in NETCB or a false positive? (PC)

[e-mail] (Ian Leitch) writes:

>These and other indications lead me to think that I may have hit
>a false positive.

Yup, you did...sorry....I have now fixed it, and created a new version of
the VIRSTOP program, which fixes this - you can FTP it from complex.is

Everybody else, don't worry about getting this (new) version, unless you
encounter the same problem (Tokyo false positive), which should be quite
unlikely if you are not using this NETCB program.

- -frisk

- --
Fridrik Skulason      Frisk Software International     phone: [phone]
Author of F-PROT      E-mail: [e-mail]         fax:   [phone]

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

Date:    Thu, 18 Feb 93 23:00:22 +0000
From:    [e-mail] (Charles Dobbins)
Subject: Re: MtE Infected... (PC)

[e-mail] (martin dewaele) writes:
>From: [e-mail] (martin dewaele)
>Subject: MtE Infected... (PC)
>Date: 12 Feb 93 06:52:20 GMT

>I have Norton Anti-Virus 2.1 and it has detected what is called the
>MtE Infected virus.  Yet the Repair function states that it is unable
>to repair the infected file.

>Does anyone happen to know what the virus is or the problem which is
>creating this warning in Norton Anti-Virus.

Norton Anti Virus has some problems with finding false positives for MtE
virus's. If you call the Symantec BBS at 408-973-9834 they have updates that
fix some of the false MtE problems. We use NAV on a LAN and have had a few
MtE problems with it and the patch seemed to help. One odd problem is that
it seems to find MtE in 0 byte files mostly. Good Luck
- ------------------------------------------------------------------------------
Charles Dobbins                                 Ericsson Network Systems, Inc
Systems Programmer                                            P.O. Box 833875
                                                    Richardson, TX 75083-3875
                                                               [phone]
- ------------------------------------------------------------------------------

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

Date:    18 Feb 93 22:53:13 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: Tremor (PC)

[e-mail] (Paul Ferguson) writes:

> not had an opportunity to effectively measure), but since there were
> no references to it within the F-Prot documentation ("New viruses --
> detection added..") or from within the program itself ("Not yet
> analysed"), I suspect that detection of TREMOR was a last minute
> addition.

It most certainly was....in fact the current detection routine is only
a temporary solution - not perfect (similar to my first MtE detector),
but it should be working 100% in version 2.08.

The integrity checker in F-PROT Professional handles it without problems,
just like any other similar package.

- -frisk
- --
Fridrik Skulason      Frisk Software International     phone: [phone]
Author of F-PROT      E-mail: [e-mail]         fax:   [phone]

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

Date:    Thu, 18 Feb 93 23:03:46 +0000
From:    [e-mail] (John Mechalas)
Subject: Re: F-prot/FSP/bootsum problem. Help! (PC)

[e-mail] (jornj) writes:
>: FSP+).  I have FSP configured so that it checks my bootsum when I boot
>: up.  The value of the bootsum is not supposed to change, and never
>: does until I scan my drive with F-prot.  After I finish scanning my
>: drive I get an alert from FSP saying my bootsum records do not match,
>: and then it shows the newly assigned value.  I am confused about why
>: F-prot changes my bootsum when it scans my drive and if there is
>: anything I can do about it.
>
>: By the way, my system is a IBM AT (100% compatible) running Stacker on
>: a 32m hard drive, and DOS 5.0.
>
>I've experienced the same problem, using Integrity Master and Stacker
>2.0. When I check the 'bootsector' of my stacked volume IM always
>claims it has changed...
>
>Is this normal for Stacker? Or do I have a 'problem'?
>(I've scanned with scan v99, fprot 2.06 and IM doesn't report any
>other problems).

As near as I can tell, this is normal for Stacker.  My copy of Intergrity
Master always claims a change in the boot sector as well.  I am not sure
why this is, though, not being very technically literate as far as
Stacker is concerned.

- --
John Mechalas                    \ If you think my opinions are Purdue's, then
[e-mail]     \     you vastly overestimate my importance.
Purdue University Computing Center \         Stamp out and abolish redundancy.
General Consulting                  \                    #include disclaimer.h

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

Date:    Thu, 18 Feb 93 23:23:28 +0000
From:    007 <[e-mail]>
Subject: Re: NAV questions (PC)

[e-mail] (McAfee Associates) writes:
>>As far as I know, there is a close link between the authors of SCAN and
>>VSUM, and i wouldn't trust the test as a purely independent test.
>
>There is no close link between McAfee Associates and Ms. Hoffman, at
>least, none different from that between her and any other anti-viral
>vendor.

Really?  I wonder why Ms. Hoffman states in her "A word from Patricia..."
section:

    A special thanks goes to John McAfee for the countless hours he
    has spent reviewing VSUM prior to its release.

Seems she has a bit more of a connection with SCAN than "any other
anti-viral vendor."

  -- 007

- --
 000   000  7777 | [e-mail]
0   0 0   0   7  |-----------------------------------------------------------
0   0 0   0  7   |        Childhood is short...
 000   000   7   |                    ...but immaturity is forever.

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

Date:    Thu, 18 Feb 93 23:56:28 +0000
From:    007 <[e-mail]>
Subject: Re: standardization (PC)

[e-mail] (Bill Lambdin) writes:

>I feel that the authors of scanners need to get together, and agree on a
>naming system.

A (very) few already have.  The naming system is called the CARO
standard, and the scanner that adheres most closely with it (that is
widely available) is F-prot.  Vesselin periodically publishes a
cross-reference between SCAN output, F-prot's output, Dr. Solomon's
output, and the "official" CARO name for every virus in Vesselin's
collection.  This can be VERY useful for keeping my virus collection
straightened out, but it would be even better to have F-prot spit out
the exact CARO name.  Some of my variants of jerusalem are impossible
to distinguish by F-prot's output alone.

(Hey frisk, how about "f-prot /CARO"  as a command line switch?? ;-)

  -- 007
- --
 000   000  7777 | [e-mail]
0   0 0   0   7  |-----------------------------------------------------------
0   0 0   0  7   |        Childhood is short...
 000   000   7   |                    ...but immaturity is forever.

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

Date:    Fri, 19 Feb 93 10:03:44 -0500
From:    Bill Hayes <[e-mail]>
Subject: Re: Help with FORM (PC)

Thanks very much for the speedy response to my FORM infestation. Nearly
everyone recommended F-PROT, and I have the bureaucracy churning out a
purchase order for this very good piece of software. I received nearly
50 noted from Virus-L readers, and I think I've been able to send a nice
and short (!) reply to everyone.

One correspondent stated that F-PROT would be available in the U.S. from
a U.S. vendor at about $2.00 per machine.  I contacted the vendor and
discovered that the "professional" version costs about $50.00 for a single
copy.  Site licenses go for about $35 per machine.  This is supposed to
pay for toll-free telephone support, a new check-sum feature, and a printed
manual.

Bill Hayes
Computer Labs Supervisor
IANR Communications and Computing Services
Institute of Agriculture and Natural Resources
University of Nebraska-Lincoln
[e-mail]


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

Date:    19 Feb 93 15:50:31 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: New Virus (PC)

[e-mail] (Tan Bui) writes:

> Well, from my point of view, the Whale virus is one of the better viruses
> written by the virus authors. It uses stealth techniques and has procedures

I disagree. Define "better". Even if we forget about the usual remark
that no program that messes with your files without your permission
can be a good program, then a "good" (sic!) virus should be a virus
that is well written, uses clever tricks, has no bugs, and spreads
well. Let's look at Whale: horribly written (spagetti code), full of
bugs, unable to survive in the wild. As to the tricks - well there are
indeed some armouring ones, but first they are too many and hamper the
ability of the program to work and second everything else (tunnelling,
stealth) is implemented in a rather clumsy way. No, Whale is
definitively not "one of the better viruses"... The most that could be
said is that it is the most puzzling one to disassemble.

> to keep away the unsuspecting and the less qualified 'debuggers'. It is
> a virus from which you can learn a lot, and I am sure that some people

Really? And -what- have you learned from it?

> will take its source codes for modifications.

Fortunately, its source code has never been made available.

> Take the Jerusalem virus for example. It is a rather old virus, and yet,
> modifications have been made to it, and have been released.

The main difference is that Jerusalem is easy to disassembly,
understand, and patch.

> Although the Whale virus has flaws, we can learn a lot from it.

Yes, for instance:

1) Don't play games with the prefetch queue, or your program won't
work on many machines.

2) If you don't know how to implement polymorphism, don't try to be
smart by using N different decryptors, 'coz they can be detected by
just using N different scan strings.

3) If you are going to obscure your code, don't overdo it, or your
program will become so slow, that nobody will use it.

Well, were the above point really worth writing a clumsy virus to
prove them?

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

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

Date:    19 Feb 93 16:08:14 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: windows virus (PC) - is WALDO one?

[e-mail] (Andrew Wang) writes:

> I haven't been able to find any documentation of a virus called Waldo,
> but since our data is valuable to us, I am taking the possibility
> seriously. Here's some info: We run Word for Windows, Corel Draw, and Excel
> almost exclusively. I've just downloaded virscan90 but it turns up nothing.

Corel Draw is causing the problem. It contains the message about Waldo
and displays it when an old version of Corel Draw is run on the new
version of Windows, or something like that.

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

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

Date:    19 Feb 93 20:03:46 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Warning, logic bomb in PKZIP 2.04g, put there by PKWare

- -----BEGIN PGP SIGNED MESSAGE-----

Date: 19 Feb 93 20:03:46 GMT
If you read the documentation of the latest PKLite, you'll see that it
provides an option that makes "disliting" a PKLited program more
difficult. More exactly:

> The extra compression option now writes the characters 'PK'
> (50, 4B hex) into the psp at offset 5C hex.  The user program
> can check for this signature and abort if it isn't found.  This
> way the user program will not run if the PKLITE compression is
> removed. This check may look something like the following in
> Microsoft or Borland C:
>
> if (*(unsigned int far *)MK_FP(_psp, 0x5C) != 0x4B50)
>    exit(1);

Well, the new PKZIP 2.04g (and possibly the older 2.04 versions too)
make use of this possibility. On execution, they check for the
identifier mentioned above, and, if it is not found, they destroy
themselves by overwriting argv[0] with 64 Kb of junk.

Therefore, if you are using one of the many "disliting" programs
available - beware. The only program that allows you to handle the
problem is Ben Castricum's UNP. It allows you to attach a small module
to the dislited programs, which supplies the 'PK' identifier at
runtime. So, if you are disliting the new PKZIP.EXE and PKUNZIP.EXE,
make sure that you tell the program to attach this module. If you
don't, the programs will destroy themselves at runtime.

The logic bomb is obviously put there by PKWare, and does NOT have any
other destructive effects. I couldn't figure out any way in which it
could destroy anything that it shouldn't.

Note: PLEASE, don't start a flame war on whether PKWare's act is
ethical or legal; or whether disliting their program is ethical or
legal; or whatever. The purpose of this message is just to warn you
about a possible problem.

Regards,
Vesselin

- -----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBK4U/iTZWl8Yy3ZjZAQHiiAP/aL3BfWCB03DnAZo488UwwXNQpkxkic8E
EFYavJzZPkfSy6Xc95XVki9EvO3lG7a+jPZ2QOXMdmj2pmMtbYoIcJH0VAt9kXgX
wnJg5fCTERt4bjIZRa67jII+dOdTgBR6yjPLCUU8lAPlbYbYCpRZs6j/nV18XQBc
E+scisO55a8=
=bQMA
- -----END PGP SIGNATURE-----
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

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

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