Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!usc!polyslo!vlsi3b15!vax1.cc.lehigh.edu!sei.cmu.edu!krvw
From: kelly@uts.amdahl.com (Kelly Goen)
Newsgroups: comp.virus
Subject: Re: DataCrime II - tiny clarification (PC)
Message-ID: <0002.8908111142.AA01970@ge.sei.cmu.edu>
Date: 10 Aug 89 20:52:18 GMT
Sender: Virus Discussion List 
Lines: 19
Approved: krvw@sei.cmu.edu

The comments about the cache usage on datacrime2 is somewhat
fallacious... while there is most certainly the 6 byte instruction on
board the chip and its status is relayed via signal pins to external
devices... that is not the reason why CV and debug lose control during
the jmp to loc 124(1 byte into a multibyte instruction...the actual
reason is that while tracing under cv a set of internal simulation
registers are continually utilized, the jump into the middle of an
instruction causes them to lose synchronization with the program
running...these simulation registers are what allow the debugger to
disassemble code correctly... TurboDebug's ability to merely handle
the the situation without error merely means that more robust code is
executing than codeview...(I have the latest for both and have tested
both) datacrime2 code was more unique than most viruses in this regard
but hardly very sophisticated...
                                  cheers
                                  kelly
p.s. before suspecting true skulduggery exmine the tool for fallacious
results!!  disclaimer I do not represent Amdahl Corp...or Onsite
consulting I represent me(myself only)