CHESS@YKTVMV.BITNET (David M. Chess) (08/09/89)
Alan Roberts is basically right about the oddness of the "DataCrime II"s self-degarbling code. One small point (just so we don't get too impressed with these virus-writers): while the trick that Alan refers to does prevent the virus from degarbling itself if you single-step through it, it's still trivial to disassemble; just set a breakpoint right after the degarbling loop (there's even one clear byte there to make it easy!), and let it run until then. The virus writer was probably trying to show off, and no doubt thinks him/her/itself very clever, but in fact the trick added about 90 seconds to the time required to analyze the virus, and was hardly worth the effort... DC
kelly@uts.amdahl.com (Kelly Goen) (08/11/89)
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)CHESS@YKTVMV.BITNET (David M. Chess) (08/11/89)
Not to prolong the technical discussion too long, but... Kelly Goen and Alan Roberts are both completely correct (or, actually, I'll assume they are, not knowing myself!); CodeView probably does get confused by the odd things the virus does. I always use good old DEBUG for initial examination of viruses, because I know exactly what it's doing! (CodeView is much more powerful, but for that reason also more complex.) I didn't get thrown out to DOS at any point, but I *did* notice that the virus was doing some bizarre self-alteration, decided that it was trying to avoid being single-stepped, and then confirmed that by experiment. (If you single-step through it, it degarbles to garbage, rather then to the actual virus code.) So I never got to observe the effect that Kelly and Alan saw! (So I don't think anything I said was "fallacious"; we were just talking about different effects.) Alan asks a good question about disassemblies. I think it's probably a Good Thing if at least two or three people do independant disassemblies of each virus, just to make it less likely that something subtle will be missed. I know my disassemblies (except the ones I've spent lots of time on) always contain sections marked with vaguenesses like "Does something subtle with the EXE file header here". At some point, I guess, some time does start to be wasted by duplication of effort; hard to say where, though. I probably tend to lean towards "the more the merrier"! DC