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 ListLines: 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)