Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!sdd.hp.com!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!ub!dsinc!netnews.upenn.edu!vax1.cc.lehigh.edu!cert.sei.cmu.edu!krvw
From: CHESS@YKTVMV.BITNET (David.M.Chess)
Newsgroups: comp.virus
Subject: Re: 4096 Virus and Checksums (PC)
Message-ID: <0019.9008131823.AA10141@ubu.cert.sei.cmu.edu>
Date: 13 Aug 90 13:11:44 GMT
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
Lines: 34
Approved: krvw@sei.cmu.edu

To reply to some of Johnathan Vail's points:

  - As you probably know (I couldn't quite tell from your posting!)
    the checksum field in the header of EXE files is completely ignored
    by the operating system, so a virus infecting an EXE file
    doesn't have to worry about fixing it, or about leaving the
    file's checksum unchanged (some viruses use the field as the
    place to put their own self-id marker).
  - Since the checksum field in the EXE header is ignored, the kinds of
    checks that are useful in protecting against viruses are CRCs
    performed by an anti-virus utility that looks for file
    modifications.   Since there are lots and lots of possible
    CRCs, and a virus writer has no way of knowing in advance
    which ones his virus will encounter, it's not really possible
    to write a virus that makes modifications to a file in such a
    way as to fool any significant number of different CRC checks.
    (I agree that it's easy for a virus to fool a simple add-up-
    the-words checksum in the way you describe, but those are
    so insecure that no one uses them, as far as I know.)
  - Programs that check themselves for virus infection generally
    do it by examining themselves *on disk*, not by examining
    the in-RAM copy, for just the reasons that you give; the virus
    will generally fix the in-RAM copy to look normal before
    passing control to the "host".

As Ken points out, the 4096 (and other "stealth" viruses) defeats CRC
checks (and other modification-detectors) that are run while the virus
is in memory, by "lying" to programs about the contents of files.  As
Mr. Radai says, the best way to protect against this is to get the
machine into a trusted state before running the modification detector.
On the PC, this involves a cold boot from a trusted floppy; not
exactly convenient, but worth the trouble for critical systems...

DC