HDTenEightyP/NetNews huggingface dataset:
From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
Newsgroups: comp.virus
Subject: Clearing out old signatures (PC)
Date: 22 Dec 92 19:37:55 GMT

Enclosed is a DEBUG script that will create a 68 byte .COM file
(CLEAR.COM) that will zero out memory between the current load
position and the TOM. To use, extract the portion of this message
between the (cut here) lines and name it CLEAR.DEB (the portion
beginning with "a100" and ending with the blank line after the
"q" - NOTE: that last blank line must be there as must the blank
line following "JMP 102". 

Next run "DEBUG <CLEAR.DEB" When run there should be no errors.
This will create the program CLEAR.COM.

NOTE: It will not clear the disk buffers or any high/upper RAM
      nor will it remove any viruses that are properly resident
      in allocated space, it just clears free memory.

Weasel-words: this is FreeWare but carries no guarantee of fitness
              of any kind. Caveat etc. 

- ----beginning of CLEAR.DEB------------8<------cut here-------------
a100
JMP	010D                 ;skip around loop
MOV	ES,AX                
XOR	AX,AX                
MOV	DI,AX                
REPZ	                     ;clear out memory
STOSW	                     
MOV	AX,ES                ;replaced by CD 20 for last loop
RET	                     ;move stack to protected area
MOV	AX,0100              
MOV	SP,AX                
MOV	DX,CS                
MOV	SS,DX                ;make sure program does not get
ADD	DX,+20               ;overwritten until end
INT	12                   ;Find the TOM
MOV	CL,06                
ROL	AX,CL                
SUB	AX,1000              ;Can only clear 64k at a time
CMP	AX,DX                ;Make sure we are not back down
JBE	012E                 ;to where program is.
MOV	CX,8000              
CALL	0102                 ;if not, clear 64k
JMP	011F                 ;then try again
MOV	WORD PTR [010A],20CD ;last loop - put termination in 
SUB	DX,+0F               ;can overwrite most of program
MOV	AX,DX                
MOV	CL,03                ;DX contains amount of this segment
SHL	DX,CL                ;that is in use plus loop.
MOV	CX,8000              
SUB	CX,DX                ;Subtract from 64k gives amount to
JMP	0102                 ;clear. No return so JMP not CALL

rcx                                         
44
nclear.com
w
q

- ----------end of CLEAR.DEB---------8<--------cut here--------
             *
             |
            abc
           defgh               And a Merry Christmas to All,
          ijklmno
         pqrstuvwx                               Padgett
        yzabcdefghi
       jklmnopqrstuv
           wxyz
          __||__
From: sgr4211@ggr.co.uk
Newsgroups: comp.virus
Subject: Is this VIRSTOP version current? (PC)
Date: 5 Jan 93 16:15:39 GMT

Just noticed that the version of VIRSTOP that came with F-Prot 2.06a
announces itself as v2.05 on loading.  Only noticed this after 1st Jan
when it complained about being old.

Is there a newer version?

Steve Richards.
From: jeroenp@rulfc1.LeidenUniv.nl (Jeroen W. Pluimers)
Newsgroups: comp.virus
Subject: TBAV 5.02 and VSIG9214 upload (PC)
Date: 25 Dec 92 09:36:04 GMT

Hi all,

I just uploaded to oak.oakland.edu and garbo.uwasa.fi the following
files:

<MSDOS.TROJAN-PRO>
VSIG9214.ZIP VIRSCAN.DAT with fix for TBSCANX
TBAV502.ZIP  TBAV utils 5.02 (was tbscanXX.zip) 
TBAVU502.ZIP TBAV utils upgrade 5.01 to 5.02
TBAVX502.ZIP TBAV utils 5.02 processor optimized version

BTW: Merry X-mas and a healty 1993!

- -- 
jeroen                             voice: +31-2522-20908 (19:00-23:00 UTC)
                                   snail: P.O. Box 266
jeroenp@rulfc1.LeidenUniv.nl              2170 AG Sassenheim
jeroen_pluimers@f256.n281.z2.fidonet.org  The Netherlands
From: jwright@cfht.hawaii.edu (Jim Wright)
Newsgroups: comp.virus
Subject: Introduction to the Anti-viral archives listing of 02 January 1993
Date: 3 Jan 93 01:02:49 GMT

Introduction to the Anti-viral archives	listing of 02 January 1993

This posting is the introduction to the "official" anti-viral archives
of VIRUS-L/comp.virus.  With the generous cooperation of many sites
throughout the world, we are attempting to make available to all
the most recent news and programs for dealing with the virus problem.
Currently we have sites for Amiga, Apple II, Atari ST, IBMPC, Macintosh
and Unix computers, as well as sites carrying research papers and
reports of general interest.  Updates to these lists are made exclusively
by contributions provided by the readers of this group.  My thanks go
out to the many people who keep this information current.

If you have general questions regarding the archives, you can send
them to this list or to me.  I'll do my best to help.  If you have a
submission for the archives, you can send it to me or to one of the
persons in charge of the relevant sites.

If you have any corrections to the lists, please let me know.

The files contained on the participating archive sites are provided freely
on an as-is basis.

To the best of our knowledge, all files contained in the archives are either
Public Domain, Freely Redistributable, or Shareware.  If you know of one
that is not, please drop us a line and let us know.  Reports of corrupt
files are also welcome.

PLEASE NOTE
The Managers of these systems, and the Maintainers of the archives, CAN NOT
and DO NOT guarantee any of these applications for any purpose.  All possible
precautions have been taken to assure you of a safe repository of useful
tools.

Jim Wright
Canada-France-Hawaii Telescope Corporation
jwright@cfht.hawaii.edu
JWRIGHT@UHCFHT
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Newsgroups: comp.virus
Subject: Re: Viruses in OS/2 HPFS (OS/2)
Date: 5 Jan 93 22:50:52 GMT

buhr@umanitoba.ca (Kevin Andrew Buhr) writes:

> For one thing, if a boot sector virus infects your system on start up,
> it won't survive the OS/2 startup process.  You may get the "Your
> computer is stoned!" message, since this is displayed (randomly
> approximately one out of every eight times in many cases) before the
> operating system is loaded.  HOWEVER, OS/2's own floppy disk device

A minor nit picking - Stoned displays the message only when you are
booting from a floppy. It is unlikely that OS/2 will be often booted
from a floppy...

> In summary, the worst you can expect is your system simply not
> working.  An infected OS/2 system generally won't infect new floppy
> disks unless you use the special "DOS from Drive A" sessions with an
> infected boot floppy.

There is one more danger. If the virus is Michelangelo (which -is- a
Stoned-like virus; it is even a Stoned variant) and the current date
is March 6 - bye, bye hard disk, regardless of the operating system
installed on it... :-)

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@tmxmelb.mhs.oz.au (Roger Riordan)
Newsgroups: comp.virus
Subject: Invalid Boot Sectors (PC)
Date: 24 Dec 92 01:55:50 GMT

I recently wrote

>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.  ...

It appears the original message got lost, but the gist was that, 
IN THEORY, it is possible to write a BS virus which is invisible 
on an infected PC, but impossible to detect on an uninfected PC 
with any existing scanner because DOS will crash if any attempt is 
made to access an infected disk. 

More seriously, we have established that neither F-Prot V2.05, 
nor SCAN 8.9V97 will detect QUOX on 1.44M 3.5" disks.  

F-Prot reports

     Scanning boot sector B:
     Error: B: not found

SCAN less elegantly crashes with a critical error

     Scanning for known viruses.
     General failure reading drive B
     Abort, Retry, Fail?

Seasons Greetings to All,
(PS - I'll be away till early Jan)
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: CSCRDW%CURIE@vaxtm1.rtpnc.epa.gov (Ron Whittle)
Newsgroups: comp.virus
Subject: Re: How to measure polymorphism
Date: 7 Jan 93 19:26:09 GMT

On 06 Jan 93, bontchev said:

> There are already two polymorphic engines available (MtE and TPE) and
> we are going to see more and more polymorphic viruses in the future.
> An interesting question arises - how to determine how polymorphic a
> virus is? How to determine which of two viruses is "more polymorphic"?
> In other words - how to measure polymorphism in an objective way?

I think that the first thing that needs to be done is to separate the
'polymorphism' from the 'encryption'.  In your example code, that
would not be a polymorphic virus (rating 0), but an encrypting virus
(rating 1).

> Unfortunately, this is not good enough. First, what to do with viruses
> that use a limited set of decryptors, one of which is selected
> randomly (Whale). Such viruses are obviously more polymorphic than
> Cascade. But are they more or less polymorphic than Suomi? They can be
> detected by a set of non-wildcard strings...

By giving different ratings for encryption and polymorphism, this
problem would not be as big.  Also, a lesson could be taken from
fractal geometry.  Assign (whale) type viruses ratings between
numbers (1.3 for example).

> Second, what about Bad Boy? It consists of 9 segments of code, 8 of
> which can appear in any order. This gives 8! = 40,320 variants. But
> the virus is even not encrypted, so it can be detected with a simple
> (non-wildcard) scan string...

Bad Boy would have an encryption rating of 0, and a polymorphism
rating of 1 (or whatever.  I don't think the number of variants is
the only factor to be considered in the polymorphic rating.  As you
have shown, even a small number of segments can lead to a large
number of variants).

- ---
Ron Whittle
cscrdw%curie@epavax.rtpnc.epa.gov
From: frisk@complex.is (Fridrik Skulason)
Newsgroups: comp.virus
Subject: Re: Invalid Boot Sectors (PC)
Date: 6 Jan 93 09:06:21 GMT

riordan@tmxmelb.mhs.oz.au (Roger Riordan) writes:

>It appears the original message got lost, but the gist was that, 
>IN THEORY, it is possible to write a BS virus which is invisible 
>on an infected PC, but impossible to detect on an uninfected PC 
>with any existing scanner because DOS will crash if any attempt is 
>made to access an infected disk. 

well, only if the scanner uses int 21H/25H/26H to access the disk.  If it uses
int 13H to access the disk the disk can be read no matter what data is in the
boot sector.

- -frisk

- -- 
- --
Fridrik Skulason      Frisk Software International     phone: +354-1-694749
Author of F-PROT      E-mail: frisk@complex.is         fax:   +354-1-28801
From: tck@bend.ucsd.edu (Kevin Marcus)
Newsgroups: comp.virus
Subject: Re: Is this a new virus? (PC)
Date: 24 Dec 92 07:03:27 GMT

bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes:
>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.

Oh, come on, it is relevant.  The original problem: Disinfection of a
Stoned and MIchelangelo infection.  Where they move the orig. MBR is
quite important, because in one case, it is possible to remove the
viruses by pulling the original MBR up, and in the other, it is not.

- -- 
|| Kevin Marcus, Computer Virologist.  (619)/457-1836; RE-xxx, TSCAN       ||
|| INET: tck@bend.ucsd.edu       []-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]
||       tck@fold.ucsd.edu       || All I wanted was a Pepsi...            ||
||       datadec@watserv.ucr.edu ||       And she wouldn't give it to me...||
From: ygoland@edison.SEAS.UCLA.EDU (The Jester)
Newsgroups: comp.virus
Subject: Re: Viral Based Distribution System
Date: 24 Dec 92 22:10:21 GMT

bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes:
>ygoland@edison.SEAS.UCLA.EDU (The Jester) writes:
>
>> 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...

Yes.. I understand. And may I say I STRONGLY disagree with Dr.
Cohen's definition. A program in the login script that checks if you
have been updated and then updates you is NOT a virus. The program in
the loader does NOT reproduce itself it reproduces another program
which is itself NOT a virus. (Lets ignore the obvious case where the
loader installs an infected program =) For me the acid test of a virus
is:Can it reproduce itself? Is the login script programing trying to
run around and find other login scripts or executable files to infect?
No. It doesn't infect anyone! 'Damnit Jim, its not alive!'

>> 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?... :-)

After reading this line I laughed so hard I almost fell out of my
chair. AS a matter of fact I have. Thats why I now run on OS/2. What
do you say about a program whose most recent release has as it's main
selling point "we fixed all the bugs in our previous release".  Of
course microsoft doesn't have 'bugs', they have 'features'. =) But I
digress.

>> The Jester-PGP Ver2 upon Request
>Please consider this a request... :-)

Actually I bet you already have it, I have yours. You can finger me
but I'll send it to you anyway just to be annoying. =)

			Yaron (The Jester) Goland
p.s. see mister moderator, I remembered!!! =)
- -- 
			The Jester
"Whats a Knock Out like you doing in a computer generated Gin
joint like this one?"-William Riker
"I'm god, whats your excuse?"-The Jester
From: tck@bend.ucsd.edu (Kevin Marcus)
Newsgroups: comp.virus
Subject: Re: Clash between FDISK/MBR and scanners (PC)
Date: 6 Jan 93 09:05:10 GMT

riordan@tmxmelb.mhs.oz.au (Roger Riordan) writes:
>The command FDISK /MBR is often recommended for removing MBR 
>infectors (Stoned, etc) from hard disks.  However in some 
>circumstances this can cause problems with some scanners.  It 
>appears that some versions of FDISK/MBR rewrite the Master Boot 
>Record only as far as the end of the error messages, leaving the all 
>important partition information unchanged, but also leaving any 
>viral code between the messages and the partition information.

I recently installed Linux, a version of unix for the PC, in addition
to my regular dos partition.  This comes with a small program called
"wini" which is a program, which occupies the MBR to allow me to
choose which OS I would like to boot into.  It's my understanding
OS/half does somethign like this, also, or can do something like this.
If FDISK/MBR REWRITES the MBR with the basic, boring code that
normally is there with DOS, then if I use this method, I will destroy
the wini program, and restrict myself from booting into my Linux
partition.  This is another drawback to fdisk/mbr.
- -- 
|| Kevin Marcus, Computer Virologist.  (619)/457-1836; RE-xxx, TSCAN       ||
|| INET: tck@bend.ucsd.edu       []-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]
||       tck@fold.ucsd.edu       || All I wanted was a Pepsi...            ||
||       datadec@watserv.ucr.edu ||       And she wouldn't give it to me...||
From: o.crepin-leblond@ic.ac.uk (OlivierM.J. Crepin-Leblond)
Newsgroups: comp.virus
Subject: Re: The Internet Worm (CVP)
Date: 6 Jan 93 15:44:43 GMT

>From rslade@sfu.ca  Fri Dec 25 08:15:00 1992
>Date:    Fri, 25 Dec 92 00:15:35 -0800
>From:    rslade@sfu.ca
>Subject: The Internet Worm (CVP)
>
>HISVIRO.CVP   921215
> 
>                         The Internet Worm
> 
>By the fall of 1988, VIRUS-L had been established (let's hear it for
>Ken!) and was very active.  Issues were, in fact, coming out on a
>daily basis, so I was quite surprised when I didn't receive one on
>November 3rd.  I didn't get one on November 4th, either.  It wasn't
>until November 5th, actually, that I found out why.

This is incorrect. The first digest of VIRUS-L appeared on 9th Nov 88.
I suspect that this was triggered by the FLOOD of undigested messages
that had to be sent all around the place during the week 1 Nov to 8th
Nov 88. (am I right, Ken ?)

[Moderator's note: For the e-record, VIRUS-L Volume 1 Issue 1 was
posted Wednesday, 9 Nov 1988, just a few days after the Internet worm
incident.  The primary input behind going digest+moderation at that
time was a storm of ASCII "pictures" that were posted to the group.
That, plus the added discussions due to the worm prompted several
people (including myself) to want the list to go to digest format.  In
any event, VIRUS-L was distributed unmoderated and undigested from
Fri, 22 Apr 88 07:48:39 EDT (when I sent the first announcement to the
newly formed group) until 9 November.  The distribution was from
LEHIIBM1.BITNET aka IBM1.CC.Lehigh.Edu - the same IBM 4381 mainframe
that served the group until July 1992, when we switched over - not
without pain - to an RS6000 running AIX and IDA's sendmail.]

VIRUS-L was a BITNET listserv list (LEHIIBM1.BITNET) and was just an
email exploder, forwarding messages on BITNET and traffic went-on
throughout the internet worm. I recall receiving messages here in UK
via EARN-RELAY (known as UKACRL.BITNET). It was interesting to read
messages as they came in. I remember spending most of the 4th of
November 1988 on my terminal, reading message after message. (or was
it 5th ?)

Receiving so many messages per day was quite exciting, since I had
only started to subscribe to VIRUS-L a week earlier. An amazing
coincidence. Judging from the nonsense that was often written, the
amount of confusion amongst those affected by the worm was at a peak.
Rumours spread so quickly.

- -- 
Olivier M.J. Crepin-Leblond, Digital Comms. Section, Elec. Eng. Department
 Imperial College of Science, Technology and Medicine, London SW7 2BT, UK
       Internet/Bitnet: <foobar@ic.ac.uk> - Janet: <foobar@uk.ac.ic>
From: a_rubin@dsg4.dse.beckman.com
Newsgroups: comp.virus
Subject: Re: On the definition of viruses
Date: 7 Jan 93 23:00:08 GMT

fc@turing.duq.edu (Fred Cohen) writes:
>	Computer viruses do not have to be malicious, they do not have
>to be Trojan horses, and they do not have to enter without the
>knowledge or consent of the user.  Any definition that depends on
>these properties depends on peoples' opinions, skills, and knowledge,
>and are thus not "testable" in the scientific sense of the word.  (See
>Popper and others for more details).  For example:

..

>	The mathematical definition first published in 1985 is
>testable, and appears to properly differentiate viruses from
>non-viruses.  Perhaps someone else wishes to do a better job, but
>let's not make definitions that are senseless.

>	So what is a computer virus? In simple terms, it is a sequence
>of instructions that, when interpreted in an appropriate environment,
>"replicates" in that at least one relica also "replicates", etc., ad
>infinitum.

Actually, that definition isn't useful.  If the "environment" includes
a user typing "copy", then any file is a virus.  (Word Perfect, on the
other hand, qualifies as a Trojan Horse under almost any definitions,
because it busily modifies files without being asked.  MOST of those
files are in the WP directory, but....)
- --
Arthur L. Rubin: a_rubin@dsg4.dse.beckman.com (work) Beckman Instruments/Brea
216-5888@mcimail.com 70707.453@compuserve.com arthur@pnet01.cts.com (personal)
My opinions are my own, and do not represent those of my employer.
My interaction with our news system is unstable; please mail anything important
From: fc@turing.duq.edu (Fred Cohen)
Newsgroups: comp.virus
Subject: Changes at ASP
Date: 5 Jan 93 03:09:50 GMT


	As of Jan.  1, 1993, ASP has decided to transfer all
maintenance, marketing, and other responsibility for all information
protection products currently made and marketed by ASP to outside
companies in which we have no financial interest.  We are therefore no
longer involved in the commercial aspects of protection software,
except for the licensing of basic technology developed at ASP.

	This transfer is being done in order to eliminate any
appearance of conflicts of interest with a new venture just started as
a joint project between Information Integrity and ASP - called:

				  (tm)
		"Protection Experts   "

			 (tm)
	Protection Experts   provides immediate and unbiased answers to
your most pressing questions about computer security policies and
practices, electronic eavesdropping and countermeasures, malicious
software, network protection, and protection products and services. 

	We rapidly identify, retrieve, and distribute relevant
documents and information from our extensive collection of books,
conference proceedings, government publications, on-line information
services, journals, popular media, and product literature.

						(tm)
	For further details on Protection Experts,   please contact
us at:

	8:30AM-2PM Eastern		2PM-8PM Eastern
	TEL:US 412-422-4134		TEL:US 907-344-5164

	FAX:US 412-422-4135		FAX:US 907-344-3069

					Dr. Frederick B. Cohen
					President ASP
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Newsgroups: comp.virus
Subject: Re: Jerusalem (Israeli) Virus (PC)
Date: 7 Jan 93 13:22:52 GMT

bill.lambdin%acc1bbs@ssr.com (Bill Lambdin) writes:

> Jerusalem B is a file infector. It runs as a TSR, and will infect every 
> executable file you run except for .COM files larger than 62K. I believe 
> the virus is around 1800 bytes long.

First, there is not such thing as "Jerusalem B". Even SCAN does not
call any virus like that anymore... The Jerusalem family of viruses
contains many variants. You are probably speaking about the most
widespread one, which is 1808+5 bytes long and infects EXE files
multiple times (until they get too big to fit in memory).

> McAfee's Clean can remove this virus fairly easy to remove. It would be a 

Due to the infection method that this virus employs, it destroys EXE
files with internal overlay structure (e.g., WordPerfect). Such files
will crash when executed. They will still crash after disinfection,
although McAfee's Clean does not warn you about that. If you have an
outbreak of this virus, the best solution is to delete all infected
files and to replace them with clean copies.

> very good idea to re-boot the computer from a known clean bootable 
> diskette. If you don't have a clean bootable diskette, go ahead and type 
> the following on the command line.
>  
> CLEAN C: [JERU]
>  
> after Clean gets finished, turn your computer off for a few seconds, then 
> back on. The reason for this is that since Jerusalem-B runs as TSR. After 
> the computer is clean, make a bootable diskette, then place a write 
> protect tab on the notch. Then the next time you have another virus, you 
> will be ready.

If he follows your advise literally, the "next time" he will run a
CLEAN.EXE infected with the virus and will spread the infection again.
The correct advice is to emphasize that at least the program CLEAN
must be run from a write-protected diskette, if you are unable to boot
from a clean environment...

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