HDTenEightyP/NetNews huggingface dataset:
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Newsgroups: comp.virus
Subject: Re: Michelangelo (PC)
Date: 16 Nov 92 15:09:25 GMT

mcafee@netcom.com (McAfee Associates) writes:

> The Michelangelo virus is spread by booting from an infected floppy
> diskette.  When the infected floppy is booted from, the virus code is
> loaded and executed by the computer.  The virus is now installed in
> memory and will monitor the system for disk accesses.  When a disk
> access occurs, the virus checks the disk to see if its infected, and
> if not, infects the disk (network drives, Stacker compressed volumes,
> and other media which are accessed through a device driver are not

Not quite exact. The virus tries to infect the hard disk only at boot
time, i.e., when you are trying to boot from an infected diskette. If
the virus is being booted from the hard disk, or if it is already
resident, it doesn't try to infect the hard disk any more. Thus, it
can be disinfected from the hard disk even if it is active in memory,
although this is not generally recommended.

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.0 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: mcafee@netcom.com (McAfee Associates)
Newsgroups: comp.virus
Subject: Re: Dangerous bug in CLEAN 97 (PC)
Date: 17 Nov 92 07:38:39 GMT

Hello Vesselin,

you write:
[...message about CLEAN not removing the Michelangelo from 1.2Mb diskettes
deleted for brevity...]
>McAfee Associates has been notified of the bug and they are probably
>already working on the solution. Hopefully, the bug will be fixed in
>the next release of CLEAN.
[...deleted...]

Noted and in the queue of things to be looked into.  A new version of
CLEAN should be ready early next week fixing this, barring any
unforseen problems.

Regards,

Aryeh Goretsky
Technical Support

- -- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
McAfee Associates, Inc.  | Voice (408) 988-3832 | INTERNET:
3350 Scott Blvd, Bldg 14 | FAX   (408) 970-9727 | mcafee@netcom.COM
Santa Clara, California  | BBS   (408) 988-4004 | CompuServe ID: 76702,1714
95054-3107  USA          | USR HST Courier DS   | or GO MCAFEE
Support for SENTRY/SCAN/NETSCAN/VSHIELD/CLEAN/WSCAN/NETSHIELD/TARGET/CONFIG MGR
From: krvw@cert.org (Kenneth R. van Wyk)
Newsgroups: comp.virus
Subject: Administrivia - a new FAQ, and proposed new V-L message ordering
Date: 17 Nov 92 19:00:19 GMT

VIRUS-L/comp.virus readers:

A new V-L/c.v FAQ (Frequently Asked Questions (and answers)) document
will be posted to the group in the next day or so.  It is currently
available by anonymous FTP on cert.org (192.88.209.5) in
pub/virus-l/FAQ.virus-l, or by e-mail from listserv@lehigh.edu (just
send a note to that address saying, "info virus-l").  It will also be
posted to news.answers periodically.  My thanks to everyone that
helped out in this release!

On another note, a V-L subscriber recently requested that I change the
ordering of messages in each digest such that non-PC postings come
first, followed PC postings and the rest of the postings.  The
rationale for this request was that the PC postings make up the vast
majority of the messages on V-L/c.v, so non-PC people could locate the
messages of interest to them quicker.  Your comments and suggestions
are welcomed.

Cheers,

Ken

Kenneth R. van Wyk
Moderator VIRUS-L/comp.virus
Technical Coordinator, Computer Emergency Response Team
Software Engineering Institute
Carnegie Mellon University
krvw@CERT.ORG       (work)
ken@THANG.PGH.PA.US (home)
(412) 268-7090  (CERT 24 hour hotline)
From: frisk@complex.is (Fridrik Skulason)
Newsgroups: comp.virus
Subject: Re: F-Prot Bug (PC)
Date: 15 Nov 92 11:06:33 GMT


vxc15931@vax1.mankato.msus.edu writes:

>I just got version 2.06a of F-Prot but I think it is still buggy.
>When I check the Virus Information, the program quits whenever I
>selected information on the second virus I pick, exactly the second
>virus.

Sounds like a memory shortage problem to me - as if you are very close to th
limit of memory needed to run the program.

The problem is that the memory requirements of the program have been growing,
as the number of viruses has been increasing.  I have a plan, which should
take care of that, but those changes will not be implemented until in version
2.07.

- -frisk
From: WHMurray@DOCKMASTER.NCSC.MIL
Newsgroups: comp.virus
Subject: The Kid that Wrote that Worm
Date: 15 Nov 92 16:40:43 GMT

>There was a court of appeal, on march 7, 1991, but conviction 
>was upheld.

That decision was appealed to the Supreme Court of the US.  They
refused to here the appeal.

May he be condemned to the obscurity he so richly deserves.

WHM
From: martin@cs.ualberta.ca (Tim Martin; FSO; Soil Sciences)
Newsgroups: comp.virus
Subject: Apologies to Padgett, and clarification (PC)
Date: 17 Nov 92 19:20:55 GMT

Reading over two of my recent posts, about the Monkey virus, I realize
one could get the impression I am critical of Padgett Peterson's
"Fixutils" and "Disk Secure" packages.  Not at all!

I still find Disk Secure to be the best, simplest, and cheapest
software way I know of to protect against MBR infectors.  That's why
the University of Alberta uses it in all its "public access" DOS
computer labs.  And that, unfortunately, is why Monkey was written to
by-pass Disk Secure.  Far from a statement against Disk Secure, this
is a lesson on the limitations of any software-based protection
system: a directed attack, however unlikely, is always a possibility.

Similarly FixMBR demonstates an interesting and straightforward way to
recover from almost all MBR viruses.  But not from Monkey, and
presumably once again for the same reason.  :)

Tim.

 -------------------------------------------------------------
  Tim Martin                   *
  Spatial Information Systems  *  "I really don't see how returning
  University of Alberta        *       the product helps me."   
  martin@cs.ualberta.ca        *
 -------------------------------------------------------------
From: chess@watson.ibm.com (David M. Chess)
Newsgroups: comp.virus
Subject: re: CHRISTMA effects (CVP)
Date: 17 Nov 92 17:29:59 GMT

> From:    rslade@sfu.ca

>IBM's internal network,
>VNET, was more heavily hit than either EARN or Bitnet, and drastic
>action, in the form of a general system shutdown, was felt to be
>needed to clear up the mess.

This is an urban legend, I'm pretty sure (if you have a good primary
source for the statement, let me know).  I was on vacation when
CHRISTMA hit, but was involved to some extent in the followup
investigations.  As far as I know, VNET was never shut down as a
whole; it was even more a distributed system then than it is now, and
I don't think anyone knew then of a way to shut it all down if they'd
wanted to!  The various systems that were hit responded in various
ways.  Some wrote little demons that went through and purged any
CHRISTMA EXECs that showed up in the spool, some that were lightly hit
did this manually, and some that were very heavily hit no doubt
elected to shut down while dealing with it.  But the story that "IBM's
internal network was completely shutdown" is a myth, as far as I
know...  DC
From: medici@dorm.rutgers.edu (Mark Medici)
Newsgroups: comp.virus
Subject: Re: SCAN 95b doesn't find MtE in EXE files (PC)
Date: 17 Nov 92 01:47:17 GMT

frisk@complex.is (Fridrik Skulason) writes:

[in reference to various virus scanners missing MtE in .COM's converted
 to .EXE's via COM2EXE...]

| Not surprising - what you did was simply to add a new layer of
| encryption to the files.  Of course, the virus could be distributed in
| this form, and would probably replicate, but all the second (and
| later) generation copies would be detected normally.

[...]

| I don't consider it a serious problem - basically it is equivalent to
| distributing an old virus, with a new encryption wrapper...the
| original sample will not be found, but all the second generation
| copies will.

I'm not sure that I agree with that.  While it's good that the second
generation infections will be detected, (and, presumably, eradicated),
if the original vector for the virus remains undiscovered, further
infections will inevitably occur.  If nothing else, this would be a
continual time waster, as sysadmin's go around cleaning-up detected
instances of the virus and trying to find the source of the problem,
which could be right on their own PC.

Of course, if a person didn't take the time to check the .COM for
virus before converting to .EXE (or compressing with PKLITE/LZE/etc),
s/he is asking for trouble anyway.  But that doesn't exclude a baddy
from doing this on purpose to make the virus harder to detect.
- -- 
_________________________________________________________________________
RUCS     | Mark A. Medici, Systems Programmer III, User Services Division
User     | Rutgers University Computing Services, New Brunswick, NJ 08903
Services | [medici@gandalf.rutgers.edu]                    [908-932-2412]
From: duck@nuustak.csir.co.za (Paul Ducklin)
Newsgroups: comp.virus
Subject: Re: Is this a virus? (PC)
Date: 13 Nov 92 16:20:38 GMT

Thus spake rknazik@x102a.harris-atd.com (knazik bob):
>My 386 PC reports that I have 654360 conventional memory when I do a
>"chkdsk" or a "mem" (DOS 5.0).  This is 1024 short of the expected
>amount.  I seem to remember that there was a virus that caused this
>result, but VSCAN finds nothing wrong.  Does anyone know if this is a
>virus or just some weird hardware failure ?  Any help is appreciated.

Some BIOSes use the top 1KB of the DOS 640KB area as an extension to
the BIOS data area at 0040:0000, so 1KB missing at the top of DOS
memory might be quite normal.

Boot clean and then try MEM. The figure you see reported after a clean
boot is the "normal" figure for your PC. If you boot from hard disc and
see less than "normal", you may then get worried..

- -- 
- --..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--
Paul Ducklin                                       duck@nuustak.csir.co.za

  CSIR Computer Virus Research Lab * Box 395 * Pretoria * 0001 S Africa
From: mcafee@netcom.com (McAfee Associates)
Newsgroups: comp.virus
Subject: VIRUSCAN double hits (was: Re: KEY Press virus & McAfee v97_ (PC)
Date: 13 Nov 92 20:10:40 GMT

Hello Vesselin

you write:
[ ">>" stuff I write]
>>[long list of multiple viruses reported for a file infected by a
>>single virus deleted]
>
>I must have been asleep when I have written that! The list is far from
>complete; I really don't know why I have missed the rest of it... :-(
>Anyway, I apologize for the inconvenience and here is the rest of the
>list:
[long list of multiple viruses reported for a file infected by a 
single virus deleted.  Again. :)]

I'll let the programmers know.

Aryeh

- -- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
McAfee Associates, Inc.  | Voice (408) 988-3832 | INTERNET:
3350 Scott Blvd, Bldg 14 | FAX   (408) 970-9727 | mcafee@netcom.COM
Santa Clara, California  | BBS   (408) 988-4004 | CompuServe ID: 76702,1714
95054-3107  USA          | USR HST Courier DS   | or GO MCAFEE
Support for SENTRY/SCAN/NETSCAN/VSHIELD/CLEAN/WSCAN/NETSHIELD/TARGET/CONFIG MGR
From: PNYAPTN@pacevm.bitnet (tuan)
Newsgroups: comp.virus
Subject: F-PROT question (PC)
Date: 17 Nov 92 17:21:12 GMT

Virus-lers,

  Can any tell me why "Blem wit" is the program name when I load
virstop.exe?

  Background:
  PS2 node connected to novell netware LAN...Ipx and net5 are loaded
first and then virstop is loaded from the network drive.

  Is this a problem? if no, why does it occur? if yes, what are the
side affects?

  thank you for all your help.
  -tuan nguyen-
   programmer
   pace university
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Newsgroups: comp.virus
Subject: Re: Kuo's infection theory (PC)
Date: 16 Nov 92 15:02:19 GMT

tyetiser@umbc3.umbc.edu (Mr. Tarkan Yetiser) writes:

>    Dr. Cohen's coverage of the material is fairly broad yet concise.
> Curious individuals are recommended to take a look at it. You might
> learn something.  Here is one: "... for small files, deriving CRC
> coefficients is trivial; and for "empty" files, CRC codes may show the
> CRC coefficients directly."

This is one point where I (and Yisrael Radai, I believe, will support
me) disagree with Dr. Cohen. Deriving the CRC coefficients it
"trivial" only if you have enough file-checksum pairs. If you are
really smart and don't care about the file size, "enough" can be
reduced to "one". However, most self-respecting checksummers also
record the file size, so this is just a theoretical speculation.

Otherwise, i.e., if the checksum database is kept off-line and out of
the reach of the virus, there is no way to derive the CRC
coefficients, without knowing the polynomial used for the CRC. And, if
the virus -does- have access to the signature database, then all bets
are off, since it could go stealth instead, modify the database, and
lots of other nasty tricks.

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.0 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: sci240s@monu6.cc.monash.edu.au (Wey Jing HO)
Newsgroups: comp.virus
Subject: Re: SCANV97 don't work in OS/2 dosbox (OS/2) (PC)
Date: 17 Nov 92 05:27:09 GMT

co@bildsun1.mednet.gu.se (Christer Olsson) writes:

>I'm trying to use scan version 97 in a DOS-box but OS/2 trows out the
>scan with an error message saying that SCAN uses illegal 386
>instructions.

>Version 95 works fine, but not 97. 

>The machine is a AST 486/E Premium at 33 Mhz with 10 Mb of memory and
>OS/2 2.01 beta.

It works for me in OS/2 with the OCT'92 CSD applied. The only
complains I get are that certain files are currently being used.

- -- 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>Wey Jing Ho    Tel: 61-3-573-2567   E-mail : sci240s@monu6.cc.monash.edu.au<
>Physics Dept., Monash University ( Caulfield Campus ), Melbourne, AUSTRALIA<
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
From: dpn2@po.CWRU.Edu (Damien P. Neil)
Newsgroups: comp.programming
Subject: Re: Help!
Date: Thu, 19 Nov 1992 00:59:02 GMT
Organization: Case Western Reserve University
NNTP-Posting-Host: b63519.student.cwru.edu

In article <1992Nov19.000103.27156@mnemosyne.cs.du.edu> nogurtso@nyx.cs.du.edu (Nick Ogurtsov) writes:
>I have a problem. I'm new in C language, so can anyone help me?
>Could anyone write a piece of C code to show how to use findfirst()?
>
>Could anyone show me how to display found file name on the screen? (from
> ffblk.fname).

Are you using Borland/Turbo C, by any chance? If so, there is some good 
example code in the help system. Here it is: (Borland won't get mad at me 
for posting an insignificant fragment like this, will they?)

/* findfirst and findnext example */

#include <stdio.h>
#include <dir.h>

int main(void)
{
   struct ffblk ffblk;
   int done;
   printf("Directory listing of *.*\n");
   done = findfirst("*.*",&ffblk,0);
   while (!done)
   {
      printf("  %s\n", ffblk.ff_name);
      done = findnext(&ffblk);
   }

   return 0;
}
+-------------+------------------+---------------------------------+
| Damien Neil | dpn2@po.cwru.edu | Case Western Reserve University |
+-------------+------------------+---------------------------------+
Newsgroups: comp.programming
From: g.coulter@daresbury.ac.uk (G. Coulter)
Newsgroups: comp.programming
Subject: convert(script to script);
Date: 16 Nov 92 11:28:00 GMT
Reply-To: g.coulter@daresbury.ac.uk
Organization: Daresbury Laboratory, UK

Hi

I am writing a standard script language for defining scenes in raytracing
which I can then convert (parse) into the destination raytracer script. I
am looking for someone who can point me in the right direction on how to
do this.

(1) Is there any code out there that converts form onr script language to 
    another script language?

(2) Would writing a BNF spec and using recursive decent be a good idea?

(3) Any other ideas or thoughts

Thanks Gary.

PS If its OK I will include all people who help in the project references
   so please could you add your full name and the company you work for to
   the end of your reply. If you don't want to be added then don't give
   your company name.
Newsgroups: comp.programming
From: felciano@summit.stanford.edu (Ramon M. Felciano)
Subject: Need a text manipulation tool / programming language.
X-Posted-From: InterNews1.0a5@leland.stanford.edu
Organization: Stanford University Medical Media and Information 
 Technologies
Date: Sat, 21 Nov 92 23:56:06 GMT
Xdisclaimer: No attempt was made to authenticate the sender's name.


Hi --

I'm looking for a tool or programming language designed for the
manipulation of text files. I've got a number of similarly formatted
files that I want parsed into my program. Before I can do that,
however, I need to "massage" these files into the same format. I tried
writting a tool to do this, but the result starting looking more and
more like a language syntax parser (aagh!)

Are there any tools (Mac, Unix, or other) that do something like this?
I guess I'm sort of looking for a glorified grep with language
constructs (e.g. if-thens).

Thanks!

Ramon

+----------------------------------------------------------------+
| Ramon M. Felciano                felciano@summit.stanford.edu  |
| Associate Director, SUMMIT       (415) 723-9688                |
| Stanford University Medical Media and Information Technologies |
+----------------------------------------------------------------+
Newsgroups: comp.programming
From: dnebing@andy.bgsu.edu (dnebing)
Subject: Re: first-year programming languages
Followup-To: comp.programming
Organization: Bowling Green State University B.G., Oh.
Distribution: na
Date: Mon, 16 Nov 1992 18:44:21 GMT

In article <1992Nov16.171543.14359@leland.Stanford.EDU>,
dkeisen@leland.Stanford.EDU (Dave Eisen) wrote:
> 
> The main problem I have with inexperienced programmers is that
> they write *everything* from scratch. They are not good at
> reusing existing code, especially if the existing code is not
> as clean as it should be. And they are even worse at producing
> code that can be reused. Too many years of toy projects in school.
> 
> Is there really a problem with students not getting enough of
> a chance to write programs from scratch? Is the state of teaching
> so bad that students are only asked to make trivial changes to
> existing code?


  The problem is that the "toy projects" often deal with the algorithms 
the students have to learn, but they spend so much time creating the rest
of the "toy project" that the algorithm is practically missed.  More of the
focus has put on the algorithms.

  dnebing
Newsgroups: comp.programming
From: wiegand@rtsg.mot.com (Robert Wiegand)
Subject: Re: first-year programming languages
Reply-To: motcid!wiegand@uunet.uu.net
Organization: Motorola Inc., Cellular Infrastructure Group
Distribution: na
Date: Mon, 16 Nov 1992 21:16:28 GMT

aelman@Xenon.Stanford.EDU (Adam Elman) writes:

>bdewbank@cbnewsc.cb.att.com (bryan.d.ewbank) writes:

>>The first language in a computer science should be a machine language or
>>two.  Perhaps a single-address machine, a double address machine, and
>>something "unusual".

[Stuff deleted}

>I disagree strongly with this for two reasons:
>One:  Machine language is a _serious_ turn-off to people who aren't
>already committed to computing.  The assembly language class here is
>known as one of the hardest classes in the CS major -- if it was the
>first one, I think there would be very few people in Computer Science.

[Stuff deleted]

>I would agree that there is a good amount of debate on whether the
>emphasis of a first-year class should be on the ideas of programming
>structures, etc., (languages such as Pascal or C) or algorithms
>(something like Scheme, Lisp, or ML).  But I think that emphasizing
>the bare-bones machine aspects would be crazy.

>After all, we're not EE students. :-)

I would agree that an assembly course is probably a bit much for a first
course, but I do think it should be required at some point. I've had
to deal with programmers who had no idea how the machine "really" works
and found them to be at a disadvantage in a number of ways to other people
with a more rounded background.

How important this is would depend on exactly what type of applications
you are writing. But I think many programmers at some time have to get
down to the machine level so its good to know about.

-- 
------------------------------------------------------------------------------
Robert Wiegand - Motorola Inc.
motcid!wiegand@uunet.uu.net            uunet!motcid!wiegand
Disclamer: I didn't do it - I was somewhere else at the time.
Newsgroups: comp.programming
Subject: Re: first-year programming languages
From: huang1@husc11.harvard.edu (Howard Huang)
Date: 19 Nov 92 10:38:22
 U><dnebing-141192140340@m64-143.bgsu.edu><BxsFop.Jvw@watserv1.uwaterloo.ca> 
 <BxxKvy.4rI@news.cso.uiuc.edu><1eeg4nINNs38@matt.ksu.ksu.edu> <dpn2.111.722130918@po.CWRU.Edu>
Distribution: na
Organization: Harvard Arts and Sciences Computer Services, Cambridge, MA
In-reply-to: dpn2@po.CWRU.Edu's message of Wed, 18 Nov 1992 23:55:18 GMT


dpn2@po.CWRU.Edu (Damien P. Neil) writes:

   I took an Intro to CS course at Carnegie Mellon, and they have a rather 
   interesting approach: they start students out with a pseudolanguage called 
   Karel. 
   [...]
   The final project in the class is to write a Karel interpreter, which brings
   the whole course full circle. 

At Harvard, the second intro course starts off with LISP.  Assignments
involve generating random sentences based on a context-free grammar,
and puzzle-solving with backtracking.  It's a major change in thinking
from the first course, which is taught in Pascal.

The second half of the course teaches C, and the final few projects
involve writing a LISP interpreter in C.  It's challenging, but very
instructive.  Many people end up saying "Oh, so THAT's how it works!"
with a smile.

Howard
hhuang@mitre.org



Newsgroups: comp.programming