HDTenEightyP/NetNews huggingface dataset:
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Newsgroups: comp.virus
Subject: Re: Virus Simulator MtE Available (PC)
Date: 21 Dec 92 12:45:03 GMT

as194@cleveland.Freenet.Edu (Doren Rosenthal) writes:

>               Virus Simulator MtE Supplement Available

[stuff deleted]

>      Virus  Simulator  (introduced earlier) and this  new  Virus 
>      Simulator  MtE Supplement are not intended to  replace  the 
>      comprehensive   collection   of  real  virus   samples   as 
>      maintained  by Rosenthal Engineering and  other  anti-virus 
>      product   developers  for  testing.  Virus  Simulator   MtE 
>      Supplement  produces safe and controlled dummy  test  files 
>      that  enable users to verify that they have  installed  and 
>      are  using  their MtE virus detecting  programs  correctly, 
>      additionally  affording  an  opportunity  for  a   practice 
>      training drill under safe and controlled conditions. 

I've had some very strong objections against your virus simulator in
the past. I have not seen yet your MtE simulator, but I have the
following questions about it:

1) Does is simulate perfectly the behavior of the MtE? I.e., are the
dummy files generated by it the same as if generated by the MtE? If
not, then it is not good as a simulator, because the simulation is not
perfect enough.

2) If the answer of the above question is "yes", then it means that it
uses the MtE itself to encrypt the dummy files - because using
anything else would mean imperfect simulation. If it uses the MtE, do
you include the MtE itself in the generated dummies?

3) If the answer of the above question is "no", then the simulation is
again not good enough, since the only way a scanner could detect the
unencrypted replicants of an MtE-based virus is to scan for a scan
signature of the unencrypted body of MtE. If the answer of the above
question is "yes", then it is pretty easy to extract the MtE from the
unencrypted dummies... Therefore, you are distributing malicious
software...

Conclusion: regardless how you answer to the above questions, either
the simulator is useless, or you are distributing malicious
software... Hmm, I was able to draw this conclusion even without
having to look at the simulator... Pretty good, isn't it?... :-)

Leaving the ethical problems aside, do you try all kinds of flags
(i.e., the contents of the AX register before calling the MtE)?
Because, if you don't, you'll be able to generate only a small subset
of the code that can be generated with the MtE...

Regards,
Vesselin
- -- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
From: riordan.cybec@tmx.mhs.oz.au (Roger Riordan)
Newsgroups: comp.virus
Subject: Invalid Disk Boot Sectors. (PC)
Date: 17 Dec 92 22:29:49 GMT

In a recent comment on a query by MOPURC01@ULKYVM.LOUISVILLE.EDU 
(Michael Purcell) about a virus which allegedly made disks 
unreadable I wrote.

> If you put the wrong byte in the wrong place you can get the 
> symptoms described.  ...

We have since established that if you set the sectors per cluster 
field (offset 0dh) in the BIOS Parameter Block to zero in the boot 
sector of an otherwise normal disk all versions of DOS will crash 
immediately you try to access the disk.  All utilities we have 
tested also crash.  You can format the disk with DOS 3 & 4 but 
Format will crash under DOS 5 unless you use the /u option.

F-Prot, Dr. Solomon's Toolkit, & McAfee Scan all crash.  VET crashes 
too, but we are working on it!

Roger Riordan                     riordan.cybec@tmxmelb.mhs.oz.au

CYBEC Pty Ltd.                                 Tel: +613 521 0655
PO Box 205, Hampton Vic 3188   AUSTRALIA       Fax: +613 521 0727
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Newsgroups: comp.virus
Subject: Re: Viral Based Distribution System
Date: 21 Dec 92 12:35:04 GMT

ygoland@edison.SEAS.UCLA.EDU (The Jester) writes:

> If the purpose of the program is to automatically cause some
> 'change' in various computers, then the program must execute from a
> loader or an infected file. If its being launched from a loader then
> the need for the distribution system is nullified. Assuming the goal
> is to still keep absolute system security, then the loader will be
> 'allowed' in by the administrator but the virus it is loading won't
> be allowed to attach itself to another program, just make the change
> for the single user that activated the loader.

Yes, this is exactly how the current products with virus-like
distribution work. The "loader" is the system login script of Novell
NetWare. When the user logs in, the script checks whether his/her
workstation has an up-to-date version of the software, and if not
copies the newest version of the software from a secure directory on
the server to the workstation and requests a reboot.

> If this is an
> effective means of distribution then why use a virus at all? 

The question is incorrect. According to Dr. Cohen's definition, "this"
- -is- a virus. And, since you are using it to do something you would
like to be done, it is obviously a benevolent virus. Do you see the
misunderstanding now? It's all matter of definitions...

> In conclusion, a system that changes in an unpredictable manner,
> that uses hard to track mechanisms of change, is a security
> nightmare.

Yup... Ever tried MS Windows?... :-)

> Just as self modifying programs have been given a very
> bad reputation for very good reasons, a viral based distribution
> system deserves a similarly bad reputation.

Does it? Why? Because of the word "virus"? But they just don't use
that word when selling you the package! They call it "Installs and
Updates Hundreds of PCs on a Network in One Easy Step" (Symantec),
"Completely Centralized Anti-Virus Strategy" (Central Point Software)
or others some such...

> 			The Jester-PGP Ver2 upon Request

Please consider this a request... :-)

Regards,
Vesselin
- -- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
From: Malte_Eppert@f6002.n491.z9.virnet.bad.se (Malte Eppert)
Newsgroups: comp.virus
Subject: Pink dos color -Virus? (PC)
Date: 19 Dec 92 20:58:00 GMT

Hello!

 > My default dos foreground color is Pink not low intensity
 > white. Is this possibly a virus? I booted from a protected floppy
 > master disk - - no change!

Does your monitor display the default gray at all after the failure?
If not, try to fix your video cable. It just may be a loose contact.
Had that before, and all the gray on the screen turned pink, until I
fixed the cable.

cu!
eppi

- --- Via SCANTOSS V 1.37
 * Origin: No Point for viruses - The EpiCentre! (9:491/6002)
From: aryeh@mcafee.com (McAfee Associates)
Newsgroups: comp.virus
Subject: Questions about OS2SCAN and OS/2-based AV software in general (OS/2)
Date: 21 Dec 92 22:07:12 GMT

Hello Vesselin,

You write:
>>I write:

>This is not actually a problem. Since the scanner runs in its own area
>of memory, protected from the other processes, it cannot be fooled by
>a stealth virus and cannot be made to spread a fast infector on all
>files it scans... In fact, I am wondering why a memory check is
>performed at all by an OS/2-based scanner...

Are you aware OS/2 scanners that do?  I know that IBM's Antivirus/2
has a DOS-based TSR component which scans memory when a DOS session is
started up.  But that's really an anti-viral for DOS, not OS/2.


>> - -      OS2SCAN checks "extended filenames" and HPFS-partitioned
>>        drives as well as DOS (FAT) drives.

>Do you know any way in which a known DOS virus can infect an extended
>filename on an HPFS partition?

Nope.  But I myself create directories under OS/2 HPFS with names like 
"MS-DOS 3.3 Files" and "Today's Downloads" in which I keep normal DOS
files.  I'm sure other people do as well :-)

Regards,

Aryeh Goretsky
Technical Support

- -- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
McAfee Associates, Inc.  | Voice (408) 988-3832 | INTERNET: aryeh@mcafee.COM
3350 Scott Blvd, Bldg 14 | FAX   (408) 970-9727 | IP# 192.187.128.1
Santa Clara, California  | BBS   (408) 988-4004 | CompuServe ID: 76702,1714
From: MC1980@mclink.it (Luca Parisi)
Newsgroups: comp.virus
Subject: CPAV leftovers: summary (PC)
Date: 19 Dec 92 22:15:09 GMT

Here is what I've found out about the "leftovers" I mentioned.

The "CARMEL Software" string is indeed added to files by the
"Immunize" option of Central Point Anti Virus 1.0 and 1.2 (At least; I
could only find those versions, and the new Windows one that has no
such option).

It is not part of the integrity checking program, however. It seems to
be used to pad the executable file to a multiple of 16 before adding
the self-checker, but only under certain conditions (I was unable to
replicate it except on NU.EXE, and I found another padding string
elsewhere).  It is not deleted by the "Remove Immunization" option,
although the file is restored to its original size. The padding string
and a copy of the first bytes of the original immunized program can be
read in the slack space and will disappear as expected when the
deimmunized file is copied.

The user who originally faced the program had indeed used CPAV, not 
the original CARMEL product.

Thanks to those who supported me with suggestions.

Luca Parisi 
<MC1980@mclink.it>
From: frisk@complex.is (Fridrik Skulason)
Newsgroups: comp.virus
Subject: Re: Virus Simulator MtE Available (PC)
Date: 18 Dec 92 10:15:10 GMT

as194@cleveland.Freenet.Edu (Doren Rosenthal) writes:

>     are  using  their MtE virus detecting  programs  correctly, 
>     additionally  affording  an  opportunity  for  a   practice 
>     training drill under safe and controlled conditions. 

I just hope that everybody realizes that the ability of a program to
detect the files generated by the "Virus Simulator" does not at all
indicate if it will detect the actual viruses or vice versa, which
makes this effort quite pointless, IMHO.

- -frisk
From: yoshida@microsupport.sas.upenn.edu (Dan P. Yoshida)
Newsgroups: comp.virus
Subject: RE: VI-SPY 10.0 spitting out strange numbers... (PC)
Date: 21 Dec 92 17:08:51 GMT

12/21 I talked to RG Software:

According to them the numbers are debugging codes that only beta
versions of 10.0 should display.  The numbers only showed up when
vi-spy was being run by the AUTOVS program, so this could have been
the problem somehow.

Their recommendation: erase the current version of vi-spy and
reinstall from an original disk know to be a release version.

- --dan

[Moderator's note: Thanks for the follow-up, Dan.  This is exactly the
sort of thing that I had in mind with regards to posting product
support questions and summaries here.  I hope that others follow this
example.]

Original post:
> VI-SPY 10.0
> RG Software Systems, Inc.
>
> Has anyone encountered this problem with VI-SPY 10.0?
>
> I have vi-spy running from the autoexec.bat on a Northgate
> 386 that has a Stacker "stacked" drive.
>
> On boot up, vi-spy starts to check for viruses, then it spits
> out four numbers, <<3031>>,<<3120>>,<<E8F4>>,<<4549>>,
> then the system freezes (need to hit the reset button).
From: aryeh@mcafee.com (McAfee Associates)
Newsgroups: comp.virus
Subject: Re: INFO SOUGHT: FILLED virus (PC)
Date: 21 Dec 92 21:49:06 GMT

Hello Ken McVa,

You write:
[...deleted...]
>When SCANV was run, it warned of FILLED three times, after the format
                                  ^^^^^^
Filler virus, perhaps?

>- - local rumour has it FILLED resides on an area of the disk DOS
>doesn't read - at any rate, after three warnings, the system was shut
>down.
[...deleted...]

When SCAN is run in the presence of certain other anti-viral programs,
such as Central Point Anti Virus, it can erroneously report the presence
of viruses because if the other program uses the same piece of code SCAN
does to detect the virus but does not hide that code in memory.

Regards,

Aryeh Goretsky
Technical Support
- -- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
McAfee Associates, Inc.  | Voice (408) 988-3832 | INTERNET: aryeh@mcafee.COM
3350 Scott Blvd, Bldg 14 | FAX   (408) 970-9727 | IP# 192.187.128.1
Santa Clara, California  | BBS   (408) 988-4004 | CompuServe ID: 76702,1714
From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
Newsgroups: comp.virus
Subject: CHKDSK & PC-DOS 5.00 (IBM) (PC)
Date: 21 Dec 92 15:01:08 GMT

My last last word on DOS 5.00 CHKDSK problem with big disks (promise)

It seems that the same problem *may* exist in PC-DOS 5.00 from IBM
however I do not have PC-DOS 5.00 so cannot say for sure. However if
it does exist, here is how to tell.

First PC-DOS VER/R is said to give a slightly different output than 
MS-DOS 5.00 VER/R e.g.

   IBM DOS Version 5.00
   Revision 1  CSD URxxxxx 02/92

(note: this version apparently has the "fix")

According the report, PC-DOS uses CHKDSK.COM instead of CHKDSK.EXE
(though still in .EXE format) and further, it is 16 bytes shorter than
the MS-DOS 5.00 CHKDSK.EXE (16,184 bytes vs 16,200).

Accordingly, the fragment in question appears to be at DEBUG offset
DS:2633h instead of DS:263Eh (offset used in my .BAT file was
different since file was "converted" to permit update).

The same check should be valid (8B 4F 0F 8B F9 indicates the "early"
version while 8B 7F 0F 32 ED is an indicator of the "fixed" CHKDSK)
just at the different offset, but as said, I do not have a copy of
either version of PC-DOS 5.00 so your guess is probably better than
mine.

             *
             |
            abc
           defgh               And a Merry Christmas to All,
          ijklmno
         pqrstuvwx                               Padgett
        yzabcdefghi
       jklmnopqrstuv
           wxyz
          __||__
From: riordan.cybec@tmx.mhs.oz.au (Roger Riordan)
Newsgroups: comp.virus
Subject: Another new version of Zerotime. (PC)
Date: 17 Dec 92 22:24:11 GMT

We have just received another version of Zerotime (or Slow) virus, 
which would appear to have been patched locally.  Two instructions  
have been swapped, as shown below.  The only existing program we 
have tried which will find it is F-Prot, which identifies it as "a 
new strain of Slow".

This would have been fairly trivial if the finder had not had many 
files in which the virus was protected by a CPAV product, supposed 
to provide integrity checking.  This is reported in another note.

The effects of this virus do not seem to be well known.  It is 
Jerusalem derived, is not obvious, and does not make the PC run 
slow.  However for every 2nd file closed during business hours on 
any Friday it sets the file date & time to zero (ie midnight on Jan 
1st, 1980).  This would appear to be intended to trick accounting 
and backup software into thinking that the the latest weeks results 
are incredibly boring old rubbish, and throwing them away.  

It also mutates, and occasionally generates a version with a new 
randomly derived signature (used by the virus when checking if a 
file is already infected).  The new version recognises, and will not 
re-infect, files infected by its parent.  As no reputable scanner 
uses this signature this has no practical significance.  Zerotime is 
quite common in Australia.

Oddly DIR does not show a date or time for files dated Jan 1, 1980.

          Normal                             Zerotime 3

   0107 90        NOP                 0107 90        NOP
   0108 81C61B00  ADD  SI,001B        010C B9900C    MOV  CX,0690
   010C B9900C    MOV  CX,0690        0108 81C61B00  ADD  SI,001B
   010F 2E        CS:                 010F 2E        CS:
   0110 803471    XOR BYTE PTR..      0110 803471    XOR BYTE PTR..


Roger Riordan                     riordan.cybec@tmxmelb.mhs.oz.au

CYBEC Pty Ltd.                                 Tel: +613 521 0655
PO Box 205, Hampton Vic 3188   AUSTRALIA       Fax: +613 521 0727
From: MICKLE@csmcmvax.bitnet (Dave Mickle x5205)
Newsgroups: comp.virus
Subject: DAME update (PC)
Date: 17 Dec 92 23:25:35 GMT

Further investigation reveals DAME was reported by NAV V9.5, *NOT*
some infected program running on the machine. SCAN V99 did not find
it.  The owner has good habits, controls access to the PC and is
careful about installing new software.  I'm concluding it's a false
positive.  I'd like to thank the folks at MacAfee and HI Industries
who were kind enough to call and offer the benefit of their
experience.

- ----David K. Mickle                             Ignorance
- ----if   !(BITNET) MICKLE@CSMCMVAX                       is
- ----then  (VOICE)  310 855-6642                             its
- ----else  (FAX)    310 967-0112                                 own
- ----while (Cedars-Sinai Medical Center, Los Angeles, CA  USA)      reward.
- -------------------------------------------------------------------------
From: krvw@cert.org (Kenneth R. van Wyk)
Newsgroups: comp.virus
Subject: Re: Questions about OS2SCAN and OS/2-based AV software in general (OS/
Date: 22 Dec 92 13:51:58 GMT

Aryeh Goretsky writes (in response to Vesselin):

> >Do you know any way in which a known DOS virus can infect an extended
> >filename on an HPFS partition?
> 
> Nope.  But I myself create directories under OS/2 HPFS with names like 
> "MS-DOS 3.3 Files" and "Today's Downloads" in which I keep normal DOS
> files.  I'm sure other people do as well :-)

I, for one, use long file/dir names (such as these) extensively on my
home OS/2 system.  A short filename scanner (e.g., a DOS-based product
running in a DOS session) would see only a very small portion of my
primary HPFS partition, which has DOS files strewn all over it.  That
is why I use an OS/2-specific product.  Opinion: long filenames is one
of the things that makes HPFS so nice to work with, especially when
combined with a command interpreter that can do name completion.

Cheers,

Ken van Wyk
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Newsgroups: comp.virus
Subject: Re: Is this a new virus? (PC)
Date: 21 Dec 92 11:50:23 GMT

tck@fold.ucsd.edu (Kevin Marcus) writes:

> I have varients of stoned which copy to 0,0,15, and 0,0,7, as well as a
> few other locations.  They do not necessarily copy to the same spot.

And we have here variants that put the original MBR at 0,0,2 and
0,0,8. This is irrelevant. What is rellevant is that the problem with
Michelangelo occurs exactly because the "standard" Stoned variant put
the original MBR at 0,0,7 - at the same place as Michelangelo, and
because the two viruses do not recognize each other.

Regards,
Vesselin
- -- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
From: maven@kauri.vuw.ac.nz (Jim Baltaxe)
Newsgroups: comp.virus
Subject: Re: Vshield vs Virstop (PC)
Date: 19 Dec 92 21:13:52 GMT

frisk@complex.is (Fridrik Skulason) writes:

>Well, VIRSTOP (or Quick scan) will not detect as many viruses as
>F-PROT Secure scan.  It will miss all MtE viruses for example, and
>most of the viruses which cannot be found using a signature-based
>approach. While Secure scan will detect around 99% of all viruses,
>Quick scan may detect only around 90% (however, it will detect a much
>higher percentage of "in-the-wild" viruses).

Maybe this is being greedy, but would it be possible for you to put a
switch into VIRSTOP that would force it to use the Secure scan
mechanism? I realise that this would result in a performance penalty,
but since it is only checking one file at a time this shouldn't be too
intrusive. The benefit would be enhanced security, particularly for
those who would not run F-Prot explicitly to scan their systems
periodically.

Thanks again for everything

- -- 
Jim Baltaxe - jim.baltaxe@vuw.ac.nz
Computing Services Centre - Victoria University of Wellington - New Zealand
- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Time is such a valuable commodity because they're not making it any more.
From: mrosen@nyx.cs.du.edu (Michael Rosen)
Newsgroups: comp.virus
Subject: Re: Stoned Virus (PC)
Date: 18 Dec 92 06:42:12 GMT

I've encountered what seems to be a new variant of stoned (according
to a guy who works in the computer center here) on my diskettes when I
use them in our computer labs occassionally.  Norton Anti-Virus sees
as it as my boot sector being infected by Bloomington, while f-prot
says I have stoned.  According to f-prot's files in viruses,
Bloomington is a cousin to stoned.

The guy I spoke to is sending my diskette to the author of f-prot.
It's quite annoying; it creates invisible junk files on my diskettes.
I'll get a file name on there with portions of garbage characters and
some partial words like "DOS 5.0" or other words.  Just recently it
destroyed a bunch of files that thankfully I couldn't find again,
though it was a major pain.

Mike
- --
Michael Rosen						"Time and space
Tau Epsilon Phi - George Washington University		 can be a bitch."
mrosen@nyx.cs.du.edu					  -Quantum Leap
Michael.Rosen@bbs.oit.unc.edu or @lambada.oit.unc.edu
From: cjkuo@ccmail.norton.com (Jimmy Kuo)
Newsgroups: comp.virus
Subject: Re[2]: Stoned Virus (PC)
Date: 21 Dec 92 23:27:59 GMT

mrosen@nyx.cs.du.edu (Michael Rosen) writes:
>I've encountered what seems to be a new variant of stoned (according
>to a guy who works in the computer center here) on my diskettes when I
>use them in our computer labs occassionally.  Norton Anti-Virus sees
>as it as my boot sector being infected by Bloomington, while f-prot
>says I have stoned.  According to f-prot's files in viruses,
>Bloomington is a cousin to stoned.

What NAV reports as Bloomington is more commonly known as NoInt and has
since had its name changed in NAV to NoInt.  NoInt is a stoned variant.

>The guy I spoke to is sending my diskette to the author of f-prot.
>It's quite annoying; it creates invisible junk files on my diskettes.
>I'll get a file name on there with portions of garbage characters and
>some partial words like "DOS 5.0" or other words.  Just recently it
>destroyed a bunch of files that thankfully I couldn't find again,
>though it was a major pain.

Your data corruption is likely the result of the virus overwriting one of
the sectors with its saved copy of the original boot sector.  The original
boot sector looks to have been written over a sector that serves as your
directory sector thus creating a number of strange looking files.  It is
not that you have invisible junk files on your diskettes but rather the
directory table is bad.  (Garbage in certain fields that get translated as
file names, garbage in other fields that translated into where the supposed
file begins...)  You can edit the directory to eradicate the bad filenames
or better yet, copy off the files you know and reformat the diskettes.

Jimmy Kuo                                       cjkuo@ccmail.norton.com
Norton AntiVirus Research