Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!ub!dsinc!netnews.upenn.edu!vax1.cc.lehigh.edu!cert.sei.cmu.edu!krvw
From: padgett%tccslr.dnet@uvs1.orl.mmc.com (Padgett Peterson)
Newsgroups: comp.virus
Subject: 4096 (PC)
Message-ID: <0016.9008131823.AA10141@ubu.cert.sei.cmu.edu>
Date: 12 Aug 90 04:00:00 GMT
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
Lines: 31
Approved: krvw@sei.cmu.edu


	It was promised that after a look had been taken at the 4096,
a locating method would be posted: as was first surmised, when
resident available memory is reduced by a touch over 5k.

	The 4096/JOSHI did require a revision in my statement that
common viruses can be detected by looking at three bytes. It now takes
five bytes.  This does bear out the earlier comment as to why there
are few mainframe viruses (worms are easier) - once signature
algorithms become sophisticated enough, the simpler way becomes to
mislead the checker, not try to guess the algorithm.

	However, so long as the authentification mechanism is invoked
by the CONFIG.SYS (only thing better would be a ROM extension and that
means hardware) the 4096 should trigger a flag at least twice even if
the checker does not examine the environment periodically:

1) Virus is introduced (new file)

2) Virus is invoked (changed signature of first infected file loaded)
   at next boot.

	Of course, if the system is booted only from a write-protected
floppy and critical files are checked during boot, it will trigger a
warning each time.

	Incidently, Mr. McAfee's v66 is out (65 was skipped) and it
will flag the 4096 in memory unless the /nomem switch is set (you
don't do you ?)

					Padgett