HDTenEightyP/NetNews huggingface dataset:
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Newsgroups: comp.virus
Subject: Re: Comment on the MtE wars (PC)
Date: 2 Nov 92 13:59:51 GMT

hobbit@ftp.com (*Hobbit*) writes:

> Obviously none of you are willing to publicly discuss the exact hows
> and whys of anyone's MtE-detection algorithm, for the usual reasons.

Yes, this is usually considered a trade secret.

> So the entire discussion is so far based on percentage hit rate, which

Correction: the discussion is not based on the percentage hit rate.
There is no such thing as percentage hit rate when you are speaking
about a known virus. Your scanner either is able to detect it
reliably, or it isn't. My tests are trying to show which scanners are
NOT able to detect the known MtE-based viruses reliably (because I
cannot prove that I scanner DOES reliable detection - I can only try
to find out an example that proves that a scanner is NOT able to do
reliable detection).

> for me has significantly less meaning in terms of explaining WHY
> product A sucks and product B is so much better.  Is this just me, or

Simple. :-) Reliable detection of the MtE-based viruses is -extremely-
difficult. Therefore, only anti-virus companies with very capable R&D
departments are able to solve the puzzle. (Note: this is not a flame
to anyone; for instance I don't know how reliable detection can be
achieved.) The current tests clearly show that very few AV companies
have indeed solved the puzzle.

BTW, it was demonstrated to me that no scanner can be made to detect
reliably unknown unencrypted MtE-based viruses. Sorry, but I cannot
discuss the details in public. The important thing is that the virus
could do some tricks to prevent this. None of the currently known
MtE-based viruses does this trick, so this fact should have any
impact on the current MtE detection by the scanners.

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: cjkuo@ccmail.norton.com (Jimmy Kuo)
Newsgroups: comp.virus
Subject: Re: Autoexec deletion virus?? (PC)
Date: 3 Nov 92 20:30:45 GMT

ed street writes:
>My mom recently purchased a IBM machine (PS/1) and is complaining
>about her virus checker deleting her autoexec.bat file,(she has the
>standard virus checking program that came with the computer) this only
>occurs when she gets an error message that says something similar to
>"can't read autoexec.bat and procedes to delete it.  This sounds to
>me not like a virus problem, but a file problem.

>So my question is does anyone know anything about this problem and if
>i told her right? (the program also deletes a text file from where the
>search program is located on her hard drive, so I am at a loss on
>this.  I know some programs delets file upon use (like workperfect and
>others) but never have I heard of this happening.)

We have encountered a direct action infector of C:\COMMAND.COM and
C:\DOS\COMMAND.COM which renames C:\AUTOEXEC.BAT to C:\AUTOEXEC.BAK on
Thursdays.  Presently, we have dubbed this "Thursday Autoexec".  We
had only one single sighting of this in the wild.

This is a COM appender virus which makes COMMAND.COM files grow by
452 bytes and spreads ONLY through COMMAND.COM!  It's a minor miracle
that this virus could spread (unless, "it gets lucky" [Dave Chess]).
Question: Has your mother recently purchased software or otherwise
obtained software that included its own copy of COMMAND.COM?

You can verify an infected command.com by debugging and noting that
it starts with: JMP [0104]

If all the above is true, NAV 2.1 can detect and repair this virus.

Jimmy Kuo                                       cjkuo@ccmail.norton.com
Norton AntiVirus Research
From: mathews@kong.gsfc.nasa.gov (Jason Mathews - GSFC/514)
Newsgroups: comp.virus
Subject: Re: Where to find VSUMX (PC)
Date: 10 Nov 92 16:42:00 GMT

millernw@craft.camp.clarkson.edu (Neal Miller) writes:
>	Until I received a disk error this morning, I had a copy of a
>VERY nice database of virus info in hypertext format.  It appeared
>very complete and was well written.  I've been tromping all over
>wuarchives trying to find it again without any luck.  If anyone could
>post/mail a sitename (number) and directory, I'd appreciate it.

Try Oak.oakland.edu (141.210.10.117)
directory = /pub/msdos/trojan-pro
file = vsumx209.zip

It is also available at wuarchive.wustl.edu in
"mirror/msdos/trojan-pro" and any other SIMTEL mirror site.

- -------------------------------------------------------------------------------
Jason Mathews			|  National Space Science Data Center (NSSDC)
NASA/Goddard Space Flight Center|  Internet: mathews@nssdcs.gsfc.nasa.gov
Greenbelt, MD 20771		|	     mathews@kong.gsfc.nasa.gov
- --------------------------------+ CPU time flies when you're having fun.
From: tck@bend.ucsd.edu (Kevin Marcus)
Newsgroups: comp.virus
Subject: Re: Is this a virus? (PC)
Date: 11 Nov 92 16:02:34 GMT

rknazik@x102a.harris-atd.com (knazik bob) writes:
>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.

Well, it depends.  See, not ALL computers get 655360 bytes free.  For
example, genuine IBM's are 1K under the 640K barrier.  It is possible
you have an unknown virus, though I can't think of one which is 1K
exactly; most MBR infectors take at least 2K.
 
To do a quick check, what you could do would be get a System disk from
a friend that is not infected, and boot with it.  RUn their copy of
chkdsk.  If it says 655360, then you have a problem.  Otherwise it's
prob. just your BIOS.  You could also try to run "fdisk/mbr" while at
the C: prompt, and then reboot your computer immediately after. This
will get rid of generic MBR infectors.  It does not matter if the
virus is in memory at this time.  (This is true for SToned,
Michelangelo, etc.).
 
Additionally, some BIOS's allow for 1K below 640K to be reserved as a
buffer.  Enter your CMOS and check through the options to see if you
have this flag set.  Sometimes they'll allow you to switch from
location 0:300 in memory to 1K below 640.
 
Newer AMI BIOS' definately have this function, I do not know about
others.
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Newsgroups: comp.virus
Subject: Re: Independent Virus Experts
Date: 4 Nov 92 11:07:21 GMT

amesml@monu1.cc.monash.edu.au (Mark L. Ames) writes:

> A Melbourne based organisation is looking for vendor-independant virus
> experts to advise on strategies to control and deal with the virus
> threat. If you are such a person, or know of one, please email me
> amesml@monu1.cc.monash.edu.au.

A group in Australia, called CVIG (Computer Virus Interest Group)
often publishes very competent tests of anti-virus products. Try to
contact Wayne Boxall.

Also, at the Queensland University of Technology, they have a very
strong virus research center. Prof. William Caelli is the head of the
center.

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: tck@bend.ucsd.edu (Kevin Marcus)
Newsgroups: comp.virus
Subject: Re: Info on Commander Bomber and Starship? (PC)
Date: 11 Nov 92 00:53:40 GMT

>Commander Bomber is a damn hard thing... Something like the MtE, but
>the MtE is about 2.5 Kb and this one is 4 Kb... :-( The virus itself
>is relatively easy (I'll post a short description, if you are
>interested) - just like the Dedicated virus is relatively trivial. The
>hard thing is the code generation engine generates the small pieces of
>code that transfer control to the main body... I have not "cracked" it
>completely yet... :-(

Yeah, please post up a description.
From: haymoree@byu.edu (Edward Haymore)
Newsgroups: comp.virus
Subject: Re: Infection density (PC)
Date: 4 Nov 92 22:49:00 GMT

: chess@watson.ibm.com (David M. Chess) writes:
: > I'd like to start a brief tangent on the question of how many files
: > are generally infected in a file-infector incident.  Does anyone have
: > any interesting experience of insights to share?

A friend of mine got the Sunday virus and didn't notice for a few
months -- he ended up with around 100 infected files.

- --
Ed Haymore
ed_haymore@byu.edu
From: BZ13INQ@bruerj.bitnet (Meyer, Leonardo Sant'Anna)
Newsgroups: comp.virus
Subject: Information (IBM VM)
Date: 11 Nov 92 22:40:57 GMT

Gentlemen:

        I would like some informations about the known VM viruses:

- -> if exists any anti-viruses programs
- -> if exists, how can I obtain them ?

                                        Thank you.

                                           Meyer, Leonardo Sant'Anna

                                                 BZ13INQ AT BRUERJ
From: webbew@aron01.gs.com (William Webber)
Newsgroups: comp.virus
Subject: Re: OS/2 Viruses (OS/2)
Date: 4 Nov 92 12:45:14 GMT

I hope this message is not a FAQ. I currently support approx 150 OS/2
high performance PC's & I am trying to establish the effective threat
from OS/2 viruses, if any. Does anybody have any information about
OS/2 viruses.

Many Thanks.
From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
Newsgroups: comp.virus
Subject: Is this a Virus (PC)
Date: 10 Nov 92 22:31:05 GMT

To: UVS1::"rknazik@x102a.harris-atd.com"
(personal mail to this address bounced)

(user reported 654360 bytes by DOS 5.0 MEM and CHKDSK)

a) See the FAQ 8*) it has an entry for this point.

b) The following process is what I use for "something" that cannot be
   identified:

Well, first I assume you meant 654336 not 654360 "total bytes memory"
or I'd be looking for a bad chip.

Next, I would cold boot from a clean write protected floppy with MEM
or CHKDSK on it and see if you get the same thing. If not I would be
concerned.

Then I would use DEBUG to look at the missing memory "D 9fc0:0 L 400"
should dump the whole k. (D 9fc0:0 with 7 sucessive "D"s will do the
same thing slower) If almost all zeros, it is probably a buffer. If
1/4 or more full of code, then I would be concerned, paticularly if
there were "interesting" ASCII strings. If all FFs then the chip is
not responding to that address range (really odd).

If really suspicious I would boot from floppy, capture the MBR, then
run FDISK /MBR and see if that took care of it. If not, try capturing
the DBR and run SYS. If this fixes the problem, send the captured file
to a researcher.

Write if this doesn't take care of it.

				warmly,
					Padgett
From: bartjan@blade.stack.urc.tue.nl (Bartjan Wattel)
Newsgroups: comp.virus
Subject: Re: Newest and best scanner? (PC)
Date: 4 Nov 92 10:12:39 GMT

One of *the* best scanners I know of, is:

TBScan, developped by: ESaSS B.V.
                       P.O. Box 1380
                       6501 BJ  Nijmegen
                       The Netherlands
                       Phone: +31 (0)80-787881
                       Fax:   +31 (0)80-789186
                       Data:  +31 (0)85-212395

TBScan is shareware, and can be uploaded from several BBS's. For the
most recent version, call the 'data'-phone number (all baudrates).

TBScan uses identity scanning, but als heuristic scanning. The
heuristic scanning algorithm is rather new and seems to be (one of)
the best there is.

If you have more questions, you can always contact me, as I work on
some (mostly hardware) projects of ESaSS. ESaSS also sells a hardware
PC immunizer (PC ISA/MCA only).

I hope this is enough information.

Bartjan Wattel at Eindhoven University of Technology, the Netherlands
(Email: bartjan@blade.stack.urc.tue.nl)
- ---------------------------------------------------------------------
                      All the good ones are already taken.
From: xrjdm@calvin.gsfc.nasa.gov (Joseph D. McMahon)
Newsgroups: comp.virus
Subject: re: Scores functions (CVP)
Date: 3 Nov 92 18:37:20 GMT

> It starts simply enough.  When an infected application is run on a
> new system, the system folder is infected.  Two invisible folders
> are created, one named Desktop and the other Scores (hence the
> name).  Thus the Scores infection gets to start early and go
> "resident".  (INITs of 6, 10 and 17 are created.  This led to later
> problems with other INITs numbered the same way that were mistakenly
> thought to be infected.)

The "Desktop" and "Scores" items are files, not folders. It has been
proposed that semi-sophisticated users with a means of looking at
invisible files would be tricked into thinking that the "Desktop" file
was the Finder's "Desktop" file (the Finder's Desktop file is at the
root level, not in the System folder), and that the "Scores" file
would be dismissed as belonging to some undefined game or another. All
of these files contained enough information to perpetuate the virus,
even if one or more of them was removed.

Scores took advantage of a hole which allowed INIT resources to reside
in invisible files. This hole was closed in System 6.0.3, I believe.
Invisible files are no longer eligible to be executed as control panel
(cdev) or system extension (INIT) files. It is definitely closed in
System 6.0.7 and up.

> The Note Pad and Scrapbook files, if not already present, are
> created.  The file types for these files are changed, as are the
> normal icons.

As well as their contents.

> The virus waits two days before it starts to infect applications. 
> Thus the Scores might almost seem to be an early form of the
> multipartite virus, since it "toggles" between system and
> application files.  However, it is only after the infection has
> entered the system folder that the other activities take place.

The actual infection mechanism of Scores is nearly identical to that
of the nVIR virus: A modified CODE resource installs an INIT; the INIT
modifies further CODE resources in a _Launch trap. One of the INITs is
the vector; the others are the payload. Blocking access to the System
file and disallowing creation of INIT/cdev files without user
permission disables this mechanism.

 --- Joe M.
From: frisk@complex.is (Fridrik Skulason)
Newsgroups: comp.virus
Subject: Re: Info on Commander Bomber and Starship? (PC)
Date: 4 Nov 92 09:27:52 GMT

pehmo@parker.ositech.fi (Petteri Jarvinen) writes:

>Has anybody dissected and analyzed these new advanced viruses like
>Commander Bomber and Starship? Virus Bulletin, perhaps?

Starship is not exactly a new virus - and there have been published
some reports on it (by Dmitry Gryaznov, for example).  There is also a
report in the last Virus Bulletin.

- -frisk
From: mcafee@netcom.com (McAfee Associates)
Newsgroups: comp.virus
Subject: Bad drive cable? (Was: Am I Infected?) (PC)
Date: 11 Nov 92 08:49:40 GMT

Hello Ferris,

ferris@turtle.fisher.com writes:
>I had the stoned virus and I was getting 1701 (or 1710, I forget)
>error on bootup. Supposed to indicate a hard disk error, I think.
>
>I replaced the hard disk and controller, virus scanned everything that
>went into the new disk. Ran the machine for a couple days with no
[...deleted...]

Did you try replacing the hard disk cabling?  It could be that you
have an intermittent break or short in the cables, causing the 1701
error to appear on the screen.

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: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
Newsgroups: comp.virus
Subject: PC-Week Article (PC)
Date: 11 Nov 92 21:27:17 GMT

Boy, this seems to be the week for it. Opened up the new (November 9)
PC-Week and on page 141 the lead to the Buyer's Guide is on "Network-
Operable Anti-Virus Software"

The section starts with a page of tips, comments, and quotes that would
have been very handy - in 1989 - but is sadly out of date today. Despite
the header, no information on network needs is made and the listings make
one wonder if the writers actually know what a network is !

I expect the readers to be confused about exactly what the different 
products do since I certainly was 8*(. For instance one "Novell Netware, 3.0
to 5.0" (confusing enough - the fine print indicates that "3.0-5.0" probably
refers to MS-DOS -I think) product provides "..logging of virus activity by 
user name or node address..." - sounds like a server module, right ? But two 
columns over "Memory Resident Features" lists "TSR can be loaded in high 
memory". TSR ? (not NLM) High memory ? (Netware uses a flat model).

Eventually some intelligence was gathered: if the product ran on everything
under the sun (the bright one), it was something that could be loaded on
an MS-DOS (or in at least one case on MACs) platform and could check/scan/
validate anything that MS-DOS could reach. In other words, my 1600 byte
CANARY written in 1989 to pick up the DATACRIME would qualify under all
of the networks listed (except Appleshare - well maybe if the MAC was running
SOFTPC 8*) and not require any memory, high or flat.

On the other hand, if a product only ran on Netware then *maybe* it was a 
NLM (McAfee's NETSHIELD is an NLM but didn't say so - never did figure out 
what Central Point's "master NLM and slave NLM support" means. 

At any rate, of the 25 products listed (no ranking was presented), I suspect
that only four acually provided separate server modules, the rest were
simply DOS based anti-virals that either were able to examine connected
server directories (as DOS directories), or were loadable by the client from
the server (and available as "server packs"). Since the only criteria is
for the program not to blow up on a drive that may not have a MBR, that
might not respond instantly, or that might have a locked file, qualification
is not difficult.

Maybe to expect something more than a three-year-out-of-date commentary or
less than the whole calabash claims from unrestrained vendors would be too 
much (well I know one journalist who could be accurate and demand accuracy 
but she is awfully quiet these days). Then again maybe a 1965 Pontiac 2+2 
could do 0-60 in 3.8 seconds.

					Warmly,
						Padgett

  (lets see, 421 Milt Shornack cubic inches, gear for 60 mph in first, 
   open exhausts, Firestone cantilever racing tires, and a Smokey Yunick 
   stopwatch...)
From: a_rubin@dsg4.dse.beckman.com
Newsgroups: comp.virus
Subject: Re: SCAN 95b doesn't find MtE in EXE files (PC)
Date: 5 Nov 92 00:00:28 GMT

Stefano_Turci@f0.n462.z9.virnet.bad.se (Stefano Turci) writes:

>The conversion is very simple, in fact COMTOEXE adds 32 bytes long
>header at the top of the file, and the CS:IP points to the first byte
>after the header.

Does this work?  I though you needed to reset segment registers for
the converted program to run.  If not, I can understand why the
scanners don't detect it (although they should detect as a "varient"
or "dropper".)

- --
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: duck@nuustak.csir.co.za (Paul Ducklin)
Newsgroups: comp.virus
Subject: Re: ExeBug - other names and removal? (PC)
Date: 5 Nov 92 09:59:21 GMT

Thus spake mybdav02@uctvax.uct.ac.za:
>There is an outbreak of EXEBUG virus on campus.
>It is easily removed by copying the original partition table from
>H0,T0,S17 to S17.

Yes-ish.

You must boot clean first, though. This is easier said than done with
EXEbug. The virus tells your PC (by altering the CMOS setup) that it
has no floppy drive A: installed. Some BIOSes, seeing this, figure
that trying to boot from an uninstalled drive is pointless, and thus
insist upon booting from hard disc. This gets the virus executed, and
installed in memory. The virus then attempts to boot from floppy -- if
there is a bootable floppy in the drive, you then seem to enjoy a
clean boot, though the virus is already active and working.

The virus' stealth mechanisms, once resident, deflect access from
0.0.1 to 0.0.17. So, when the virus is around, the partition record
looks normal -- and the partition table looks correct. DOS, when
working out which partitions belong to it, gets everything right.
When *not* resident, 0.0.1 is pure virus code, with complete nonsense
in the partition table zone. Boot without the virus, and DOS sees no
partitions belonging to it -- ergo, no C: drive!

So, if you try to boot clean to remove EXEbug, try logging to drive C:
after bootup. If you get "Invalid drive specification", then that's
*good* news. If you can reach drive C:, it means the virus is
resident.  Go into your CMOS setup, tell the system you *do* have a
floppy drive and then instantly reboot from floppy. Only when drive C:
is "absent" should you fire up NU, DE, DISCHAK or whatever to move
0.0.17 to 0.0.1.

>Another question: the virus formats an extra sector on floppies and
>     copies the original boot sector there - how does one read this
>     sector?  Does the virus have to be in memory? 

With the virus in memory, you'll see the "hidden" sector when you try
to read 0.0.1 from floppy, thanks to EXEbug's stealth. So you can use
the virus to access this extra sector...but then you can't write back
over the infected 0.0.1. Try Explorer or PEEKA.
- -- 
- --..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--
Paul Ducklin                                       duck@nuustak.csir.co.za

  CSIR Computer Virus Research Lab * Box 395 * Pretoria * 0001 S Africa
From: vpk2!john@attcan.uucp
Newsgroups: comp.virus
Subject: Virus-like behavior of DOS 5.0 chkdsk (PC)
Date: 11 Nov 92 14:09:43 GMT

This is an excerpt of a message I posted to comp.os.msdos.misc,
that I thought might be of interest.

(This is NOT an official report from Microsoft or AT&T. It's just
 my own friendly posting to try to help)


Program: chkdsk
O/S    : MS-DOS 5.0

Symptoms: Users running chkdsk with the /f option have 256 copies
          of the FAT written onto their hard disk starting at the
          first copy of the FAT. The result being that all directory
          information and a significant amount of the data in the data 
          area are irrecoverably destroyed.

Affected users: Any users using 256 sector FAT's. 

How to tell if you're at risk: 

          Run chkdsk WITHOUT the '/f' option and check the 
          "Total allocation units on disk". If this number is
          more than 65280, you're at risk. DO NOT USE CHKDSK TO
          CORRECT ANY DISK PROBLEMS if this is the case. You'll
          trash your disk.

Solution: Call Microsoft and request the 5.00A upgrade. They know
          about the problem and they've fixed it. They've also done
	  some diddling with the following programs: (though I don't
          know what they did to them.)

	deloldos.exe	diskcomp.com	diskcopy.com
	doshelp.exe	dosshell.exe	dosswap.exe
	emm386.exe	expand.exe	format.com
	himem.sys	mirror.com	qbasic.exe
	recover.exe	setver.exe	undelete.exe
	xcopy.exe

______Opinions stated are my own. Transcripts available by request______
      ===
    =--====  AT&T Canada Inc.          John Benfield
   =----==== 3650 Victoria Park Ave.   Network Support Analyst (MIS)
   =----==== Suite 700		  
   ==--===== Willowdale, Ontario       attmail   : ~jbenfield
    =======  M2H-3P7                   email     : uunet.ca!attcan!john
      ===    (416) 756-5221            Compu$erve: 72137,722

____Eagles may soar, but weasels don't get sucked into jet engines._____