HDTenEightyP/NetNews huggingface dataset:
From: kratz%orville@uunet.UU.NET (Thomas Kratz)
Newsgroups: comp.virus
Subject: SVC 6.0 not rem. by F-PROT206a (PC)
Date: 18 Dec 92 17:01:35 GMT

Hi everybody,

I think I've found a bug in f-prot 206a.
A week ago I had two guys with their pc's in our office who had
cought the SVC virus in version 6.0.
SCAN V99 reported [SVC] and(!) [SVC 5.0] in the boot sector and on
various .com & .exe files, an information I decided not
to trust, because of the multiple report of infection.
F-PROT found (correctly) SVC 6.0 (4644 bytes), but only on the .com & .exe
files.
After removing the virus (which f-prot claims to do correctly)
all infected files were absolutely identical with the originals, that were
present on security-disks, but knowing that SVC 6.0 does infect the boot-
sector i ran scan again; with the result, that it reports [SVC] and [SVC5.0]
still present in the boot sector.
I removed the virus with CLEAN (V97) [SVC50] and everything was fine.

Now the Questions: Is the above a known bug with F-PROT? If yes, will Frisk
                   fix it in the next release, and when will McAfee get rid
                   of their double reports and get the right names, so one
                   can assume to clean the right virus with CLEAN?

By the way: the virus information of F-PROT says that SVC 6.0 is only a
            .exe & .com infector, which is simply not true!
- --
*****************************************************************************
"Even a stopped clock gives the right time twice a day"     from WITHNAIL & I
Thomas Kratz
Beratungsstelle ZDV-Uni-Mainz          INTERNET: kratz@goofy.zdv.uni-mainz.de
*****************************************************************************
From: cjkuo@ccmail.norton.com (Jimmy Kuo)
Newsgroups: comp.virus
Subject: Re: DAME update (PC)
Date: 21 Dec 92 23:23:54 GMT

Dave Mickle x5205 <MICKLE@csmcmvax.bitnet> reports:
>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.

Um... DAME could *NOT* have been reported by NAV V9.5.  NAV does not
have a version 9.5 and NAV uses the name "MtE", not "DAME".

Jimmy Kuo                                       cjkuo@ccmail.norton.com
Norton AntiVirus Research
From: frisk@complex.is (Fridrik Skulason)
Newsgroups: comp.virus
Subject: Re: Vshield vs Virstop (PC)
Date: 22 Dec 92 00:24:47 GMT

maven@kauri.vuw.ac.nz (Jim Baltaxe) writes:

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

Possible, but difficult.  The biggest problem is that VIRSTOP is written in
100% assembly, while the Secure scan is in a C/assembly mix.  If I created
a "Secure Scan" version of Virstop, I don't see how I could get the memory
requirements below 30K.  The 2K size (if using /DISK) is ok for most users,
but 30K is a different story...

- -frisk
From: bjl1@Ra.MsState.Edu (Brett J.L. Landry)
Newsgroups: comp.virus
Subject: Problems in MCAFEE OS/2 Clean (OS/2)
Date: 20 Dec 92 15:12:05 GMT

I downloaded the new OS/2 wares from Mcafee and had mixed results.
OScan discovered that there was stoned in two partitions on 120 meg
drive that was partitioned into a 40 and 80 meg C and D respective
drives.  The problem came into play when I cleaned using OSclean.
It removed stoned but also removed the second partition loosing the 80
meg section.    This was in a single boot HPFS scenario.  

Any thoughts on this would be appreciated.

Brett J.L. Landry
- --

- ---------------------------------------------------------------------
|------------------ Brett J.L. Landry,  bjl1@ra.msstate.edu, -------|
From: holerbch@phoenix.princeton.edu (Uwe Hollerbach)
Newsgroups: comp.virus
Subject: Re: DOS CHKDSK bug (PC)
Date: 18 Dec 92 19:30:55 GMT

holerbch@phoenix.princeton.edu (Uwe Hollerbach) writes:
[ about a version of DOS 5.0 which doesn't say "revision a" ]

I went back and checked into this some more, after everyone else
reported "Revision A" all over the place, and it turns out that I did
not see the "Revision A" message because I checked it under NDOS,
Norton's replacement for COMMAND.COM. When I check the version under
COMMAND.COM, I do indeed get "DOS 5.00, Revision A". Sorry if I caused
any confusion!

- -- 
Uwe Hollerbach          uh@acm.princeton.edu  or  uh@alumni.caltech.edu
"In His infinite mercy, Allah does not subtract from one's alloted span those
hours which are spent in contemplation of net.news. All praise be to Allah."
- -- an obscure commentator on the early work of Al-Khowariszmi
Xref: sparky comp.virus:4797 news.answers:4728
From: Nemrod_Kedem@f101.n9721.z9.virnet.bad.se (Nemrod Kedem)
Newsgroups: comp.virus
Subject: VSHIELD, VIRSTOP, ... comparison ? (PC)
Date: 19 Dec 92 06:03:00 GMT

(Sorry, Aryeh... I just have to...)

 > 1) VShield can check the authentication codes added to the files by
 > SCAN /AV (it is a BAD idea to modify other people's files!) and refuse
 > to run those that are not "checksummed". Unfortunately, this feature
 > can be trivially bypassed (i.e., it is trivial to write a virus that
 > adds a correct checksum to the file it infects).

This is true when using VSHIELD with the /CV option. A better option
to use is the /CF one, which compares the checksums from an external
file created by SCAN /AF command and does not alter any executable
file.

 > 3) VShield uses much more memory than VirStop.

But may be loaded to high memory, and then needs less then 1K of
conventional memory.

 > 6) VShield can be removed from memory (very BAD idea!).

That's why there is the /NOREMOVE option...

     Regards,
     Rudy.

- ----------------------------------------------------------
Nemrod.Kedem@f101.n9721.z9.virnet.ftn       (Nemrod Kedem)
FidoNet: 2:403/138   VirNet: 9:972/0, 9:9721/0, 9:9721/101
(972)3-966-7562 (14.4K)            (972)3-967-0348 (Voice)
P.O.Box 8394,     Rishon Le-Zion,   Zip 75253,     Israel.
- ----------------------------------------------------------

- --- FastEcho 1.21/Real!
 * Origin: <Rudy's Place - VirNet, Israel> Make Safe Hex! (9:9721/101)
From: RADAI@vms.huji.ac.il (Y. Radai)
Newsgroups: comp.virus
Subject: Re: Integrity Management (PC)
Date: 18 Dec 92 17:35:58 GMT


  Padgett Petersen wrote:
>> I agree but take it one step further, again the algorithm should be
>> tailored to the specific machine and use a different seed on each - this
>> in no way weakens the algorithm but gives each PC a different signature
>> for a particular file. Break one machine and "malware" must start all over
>> again on the next.

  Vesselin Bontchev replies:
> In fact, it depends on the algorithm used. If you are using a CRC,
> just using a different seed for the checksum does not make it secure -
> you must change the polynomial each time. If you are using something
> cryptographically strong as DES, MD4, MD5, MD2, or some such, then
> just changing the seed is enough.

I agree with part of this.  Yes, it depends on the algorithm, and
using a different seed does not necessarily make an algorithm secure.
To give an example, if you alter the seed of a simple checksum
algorithm (in the literal sense of "sum") from 0 to something unique
to each computer, it's just as easy to forge checksums as with a
fixed seed of 0.
  However, I have a couple of minor quibbles with the rest of the
paragraph (let's call it "hair splitting"; I'm tired of "nit pick-
ing").  First, you write as if all algorithms have a seed.  Well, in
the case of the MDx algorithms, I suppose you could say that the
initial contents of the buffers constitute a seed; also that DES has a
seed when used for authentication purposes (ANSI X9.9), namely the
initial block.  But what do you mean by "using a different seed for
the checksum" in the case of CRC?
  More important, in the case of MDx and X9.9, how do you know that
varying the seed is enough?  You *may* be right, but to the best of my
knowledge, neither the buffer contents of MDx nor the initial block of
X9.9 were designed for that purpose.  Notice in the case of X9.9 that
security against forging is obtained, not by varying the seed (initial
block), but by each user using a different (unknown) *key*.  So with
MDx, varying the seed is probably *not* the most secure approach.  One
obvious possibility would be to encrypt the message digest with a
user-dependent secret key, but that would add a lot of time.  Maybe
there's an equally secure method which does not take as much time.

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     RADAI@HUJIVMS.BITNET
                                     RADAI@VMS.HUJI.AC.IL
From: Sara_Gordon@f0.n10.z9.virnet.bad.se (Sara Gordon)
Newsgroups: comp.virus
Subject: Re: Integrity Master update (PC)
Date: 18 Dec 92 22:38:06 GMT

just a note..

some people reading the virus-l/comp.virus want to get the a-v files,
but aren' t able to use ftp, etc.  the list rob slade made of bbs that
have the files is really quite good, but i'm not sure if they would
all have the latest files such as integrity master, f-prot, tbscan,
scan.

for people who do not know how to ftp or do file requests, simple
downloading of files is available on 'traditional' type bbs (not the
internet sites), and rob's list is very good for helping find a bbs
near you that has these files.

anyone who wants to file request, or download these files can do so
from my ( private) system :), the number is 219-273-2431. the login,
if you wish to not identify yourself, is demo account.  the password
is system. of course, i dont really want my system tied up all day and
night doing this, so please look near you first, but if you cant find,
consider this an invitation to get them here.

If you want to read the virus-L faq and cant ftp it, you can d/l it
here, or read it online.

Intergrity Master is sent to this system directly from the author as
is VirX.  F-Prot, Scan, TBscan, and the other programs are obtained
from either the author's ftp sites, or a site utilized by the author.
With all of the hacked a- v programs floating around, it is of course
important to verify that the file you get is really -helping- you.


# talk to me about those computer viruses....
# sara@gator.use.com
# vfr@netcom.com
# SGordon@Dockmaster.ncsc.mil  
 
- --- GEcho 1.00
 * Origin: VFR SYSTEMS (219)273-2431 'ask us about VIRNET' (9:10/0)
From: perry@phil.utmb.edu (John A. Perry)
Newsgroups: comp.virus
Subject: Eugene.utmb.edu is retiring
Date: 18 Dec 92 20:54:07 GMT

Eugene.utmb.edu (129.109.9.21) is going to retire from anonymous ftp
service effective Jan. 2 1993. All files have been moved to
phil.utmb.edu (129.109.9.22) and is ready to service anonymous ftp
requests. That was all there was to it. Phil has newer hardware, a
better operting system, etc.
- -- 
John Perry - perry@phil.utmb.edu
Newsgroups: comp.programming
From: jhesse@netcom.com (John Hesse)
Subject: Need Bresenham's algorithm for an ELLIPSE
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Sun, 3 Jan 1993 19:29:56 GMT

We need a fast, pixel-based algorithm to generate an ELLIPSE. I have 
Bresenham's algorithm for a circle ("Fundamemtals of Interactive Computer
Graphics", Foley, p. 442). 

But I can't see a way to convert it to generate an ellipse. Is there
any code or sources available for this? Thanks.
-- 
----------------------------+---------------+-------------------------
J Hesse	                    |      END      |    California       
jhesse@netcom.com           |    50 MPH     |     traffic
Moss Beach, Calif           |  SPEED LIMIT  |       sign
----------------------------+---------------+-------------------------
Newsgroups: comp.programming
From: jim@nestmoi.rain.com (Jim Chorn)
Subject: Re: Semaphores, Swap, or Test_And_Set
Organization: none - Portland, OR
Date: Tue, 22 Dec 1992 05:57:27 GMT

In article <1h53bpINNabh@usenet.INS.CWRU.Edu> trier@slc6.ins.cwru.edu (Mr. Stephen C. Trier) writes:
	-> This approach uses the a lock prefix to make INC and DEC
	-> atomic, even on multiprocessors.  It depends on the
This will only work on multiprocessors if the lock prefix is supported by
the processor. For example, if the multiprocessor system is tightly
coupled and each processor supports a coherent cache but the cache
ignores the processor lock signal this may not work. If the system
is loosely coupled this may not work. It all depends on the hardware
design...

	-> some who might disagree with my referring to these as
	-> semaphores, since they are non-blocking and cannot be used
	-> as counting semaphores.  If it makes you feel better, think
	-> of them as semaphore building blocks, around which you can
	-> build whatever sort of fancy setup you want.
What you have described here in code is a 'lock' in the nature of P(), V()
style E. Dijkstra. I prefer to think of them as what they. Yes, semaphores
are built using locks and there are numerous types of semaphores (counting,
blocking, event,...).
From: spackman@disco-sol.dfki.uni-sb.de (Stephen Spackman)
Newsgroups: comp.programming
Subject: Re: Fast array rotation
Date: 1 Jan 1993 19:02:33 GMT
Organization: DFKI Saarbruecken GmbH, D-W 6600 Saarbruecken
Reply-To: stephen@acm.org
NNTP-Posting-Host: disco-sol.dfki.uni-sb.de
In-reply-to: Dave Dodson's message of Tue, 22 Dec 1992 15:43:38 GMT

In article <1992Dec22.154338.15357@news.eng.convex.com> Dave Dodson <dodson@convex.COM> writes:
|In article <u895027.724990251@tasman> u895027@tasman.cc.utas.edu.au (Mark Mackey) writes:
|>
|>	I am currently writing a terrain display routine which utilises
|>a fast surface display algorithm based on scan-line processing. As
|>part of the algorith I need to rotate the raw data array. I have an
|>algorithm to do this using two 1d transforms, but in between these
|>transforms the data array needs to be transposed.
|>	Does anyone out there have any code for fast array transposition
|>on disk, minimising disk access time? Alternatively, if anyone out there
|>has ideas on how to rotate a large array (512*512 reals) efficiently
|>I would be most grateful.
|
|I assume you have the array stored on disk in row- or column-major order.
|There is a way to transpose the array by reading and writing the matrix
|twice.  For simplicity, assume you have row-major order, 4 byte reals,
|and a scratch array of length 64K bytes.  Read 65536/4/512 = 16 rows into
|the scratch array.  Write 16 x 16 square blocks onto a scratch file.  There
|will be 512/16 = 32 of them for every 16 rows.  Repeat for all rows of the
|matrix.  Now randomly read blocks 1, 33, 65, ... .  Transpose each 16 x 16
|block in memory, and write out the first 16 rows of the transposed matrix.
|Repeat with blocks 2, 34, 66, ... , 3, 35, 67, ... .

Or, under certain circumstances, you might consider doing nothing at
all. After all, it's only the indexing calculation that distinguishes
layouts; could you parameterise on it and be done? (That might entail
either multiple versions of the various operations or runtime code
generation, to get really good performance; in the latter case, be sure
you know how to explain things to any caches that might be kicking
around :-). In a sense this is no more than a generalisation of dodson's
suggestion, of course....

But hey, if by a "real" you mean a float, you've only got a meg or two
of data there. Where do disks come into it? :-).
------------------------------------------------------------------------
stephen p spackman                                       stephen@acm.org
------------------------------------------------------------------------
From: dave@cs.arizona.edu (Dave Schaumann)
Newsgroups: comp.programming
Subject: Re: Locating duplicates
Date: 2 Jan 93 04:16:58 GMT
Reply-To: dave@cs.arizona.edu (Dave Schaumann)
Organization: University of Arizona

In article <C07FJo.4vq@ux1.cso.uiuc.edu>, ceblair@ux1 (Charles Blair) writes:
>   Given a large array of integers.  Is there a way to identify duplicates
>which is substantially less work than sorting the array?

Hmm... imagine we have an array with just two elements that are equal.
Now assume we have some duplicate finder which does not sort the array.
Assuming that the values and positions of the data are not related in
some way, it seems reasonable to assume that we can arrange the values
so that that the algorithm must try every possible combination before
it finds the duplicate pair.

Not an air-tight proof, but it seems reasonable to assert that no
algorithm that asserts anything about the order of the values in
the array can find a duplicate in less than O(n*(n-1)/2) time in the
worst case, and clearly using an O(nlogn) sort and a linear scan
is better than that.  To beat sort-and-scan, you would need some kind
of linear-or-better ordering algorithm that would allow you to scan
for duplicates with a linear-or-better scanning algorithm.

However, I think that generally you can do some things to speed up the
average case of sort-and-scan.  For instance, you could modify a heap
sort algorithm so that it stops as soon as it finds a duplicate.  Also,
you could employ a hashing scheme based on the lowest bytes of the values,
which would break up your data into 256 independant groups.

-- 
Dave Schaumann			dave@cs.arizona.edu
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.programming
Subject: Re: Programming by Description of Output...
Date: 31 Dec 92 00:19:40 GMT
	<C036t1.KCH@phage.cshl.org>
Organization: Department of Computer Science, University of Manchester
In-reply-to: boutell@isis.cshl.org's message of 30 Dec 92 19:15:01 GMT

In article <C036t1.KCH@phage.cshl.org> boutell@isis.cshl.org (Tom Boutell) writes:
   In article <1992Dec30.174004.4168@cs.cornell.edu> karr@cs.cornell.edu (David Karr) writes:
   >In article <C01yxr.BGF@phage.cshl.org> boutell@isis.cshl.org (Tom Boutell) writes:
   >>Initial state:
   >>Array A[] contains n whole numbers... 
   [deleted]
   >How much easier is it to specify a program by predicates on its input
   >and output rather than by an algorithm?  

I find that the spec. is usually shorter, but there are times when a
particular implementation (algorithm) is shorter than the spec.


   An excellent question. I gather Prolog programmers have discovered
   it is often as much or more work than writing the algorithm, as
   you point out.

Getting back to the sorting example: if the arrays are changed to
lists, then a spec is :-

  sort(List, Sorted_List) :-
    permutation(List, Sorted_List),
    ordered(Sorted_List).

Suitable definitions of `permutation' and `ordered' are left as an
excercise for the reader.

By using various transformations you can move from the spec. to a
particular algorithm, say a quicksort (sic) or mergesort or you alter
the spec. to ensure that the sort is stable.  Someone here did some
work on automatically transforming Prolog programs (the thesis
specifically covers generation of various sort routines from the above
spec).  If you are interested in program transformation in general, it
is worth looking at papers/books on Bird-Merteens Formalism, CIP, VDM
and Z or for a more gentle introduction try _Science of Programming_
by Gries.

bevan
Newsgroups: comp.programming
From: johnm@cory.Berkeley.EDU (John D. Mitchell)
Subject: Re: Semaphores, Swap, or Test_And_Set
Organization: University of California, at Berkeley
Date: Tue, 22 Dec 1992 19:22:29 GMT

In article <1h7htbINNdg6@usenet.INS.CWRU.Edu> trier@slc6.ins.cwru.edu (Stephen C. Trier) writes:
[...]
>I've been trying to figure out whether that LOCK prefix is necessary when
>sharing the code between several virtual 8086s running on one 386.   I have
>been unable to get a clear answer to this question -- is the LOCK prefix
>useful only for multiprocessors that take advantage of it, or does it also
>make the instruction noninterruptible?

The LOCK prefix code of the i80x86 CPUs locks down the system bus.  On a
uniprocessor system it's only relevant if there is bus activity going on by
the processor's back (e.g., DMA (which makes the system essentially a form
of asymetrical multiprocessor :-)).

>An answer to the effect of, "A 386 instruction is never interruptible" is
>OK, too -- I haven't been able to dig that sort of information out of the
>references I can find.  Everything provides application-level information,
>but none of the info I need about exactly when an interrupt or exception
>can take place.  It seems strange, since this information is readily avail-
>able for the 680[234]0.  Why isn't the 386/486 as well documented?  (Maybe
>I'm looking in the wrong place?)

Interrupts are documented in the Intel manuals and in the TASM manuals (at
least).  Note that some instructions can *NOT* be preceded by the LOCK
prefix.

Check out "The Processor and Coprocessor" by Robert L. Hummel.  It's all
about the nitty-gritty of the i80x86 family.

Hope this helps,
		John

P.S.	Standard disclaimers apply.

P.P.S.	This part of this thread no longer belongs in comp.programming and
	if continued, should be moved to one of the PC programming groups.
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.programming
Subject: Re: Programming by Description of Output...
Date: 1 Jan 93 13:44:44 GMT
	<BEVAN.92Dec31001940@panda.cs.man.ac.uk>
	<1992Dec31.155736.29068@cs.cornell.edu>
	<BEVAN.92Dec31202001@panda.cs.man.ac.uk>
	<1993Jan1.043329.27160@netcom.com>
Organization: Department of Computer Science, University of Manchester
In-reply-to: nagle@netcom.com's message of 1 Jan 93 04:33:29 GMT

In article <1993Jan1.043329.27160@netcom.com> nagle@netcom.com (John Nagle) writes:

   Formal specs that you can't run are tough to work with.

I heartily agree, though there are those who feel that if a spec. is
executable it probably isn't a good spec.

bevan