home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / virus / 3753 < prev    next >
Encoding:
Internet Message Format  |  1992-09-09  |  3.4 KB

  1. Path: sparky!uunet!decwrl!spool.mu.edu!yale.edu!jvnc.net!netnews.upenn.edu!netnews.cc.lehigh.edu!news
  2. From: RZOTTO@NYX.UNI-KONSTANZ.DE (Otto Stolz)
  3. Newsgroups: comp.virus
  4. Subject: Re: Auto-detecting virus (PC)
  5. Message-ID: <0013.9209092012.AA23912@barnabas.cert.org>
  6. Date: 8 Sep 92 18:12:44 GMT
  7. Sender: virus-l@lehigh.edu
  8. Lines: 71
  9. Approved: news@netnews.cc.lehigh.edu
  10.  
  11. On Wed, 02 Sep 92 17:52:27 +0000 Denis Beauregard
  12.  <beaurega@ireq.hydro.qc.ca> said:
  13. > I would like to write a program that will check if it is per se
  14. > holder of a virus.
  15.  
  16. Fine! Everybody should do so.
  17.  
  18. > The method I have in view :
  19. > [1] Compile the program.
  20. > [2] Compute the checksum of the program.
  21. > [3] Put the checksum in the program.
  22. > [4] When starting the program : Stop the program if the checksum has
  23. >     been altered.
  24.  
  25. Problem:  Step 3, above, will change the program, hence invalidate the
  26.           checksum.
  27. Solution: You will have to anticipate this in step 2, above.
  28.  
  29. Pitfall:  Almost any virus will have restored the core image of the
  30.           program before the latter gains control.
  31. Solution: As you have implicitely assumed (quote suppressed for
  32.           conciseness), the program will have to check its disk file
  33.           rather than its core image.
  34.  
  35. Problem:  When a stealth virus is active in memory, it will hide its
  36.           presence from any other program (including your self-checking
  37.           routine): the program file will appear unaltered, hence the
  38.           checksum will compute correct.
  39. Solution: You could try to tunnel under the virus (i.e. find the ROM
  40.           address where your system invocation eventually is executed),
  41.           then jump directly there to get hold of an unaltered disk
  42.           file. However, this is not feasable in all circumstances.
  43.  
  44. > Also, I never saw a self-protected program.
  45.  
  46. So you never saw Word Perfect Vers 4.2, nor Dr. Solomon's Anti-Virus
  47. Toolkit, F-Prot, or any other professionally designed anti-virus
  48. program? :-)
  49.  
  50. > Even an anti-virus program
  51. > has as instructions : use the included diskette if infection is known.
  52.  
  53. . write-protected, of course! This will preclude infection of the
  54. anti-virus program (which would refuse to work after an infection, on
  55. account of the very scheme you proposed).
  56.  
  57. An anti-virus program should be used only after a clean boot, to avoid
  58. the following problems with particular types of (possibly unknown)
  59. viruses:
  60. - - when a Fast File Infector is active in memory, it will infect every
  61.   program scanned for viruses (raising the cost for the eventual
  62.   cleaning);
  63. - - when a Stealth Virus is active in memory, its infections are
  64.   effectively invisible (hence scanning the disk is futile).
  65.  
  66. > Would it be safer to use a 32 bit checksum? [...]
  67.  
  68. >From the technical details I suppressed in the quote I infer that you are
  69. planning to use a simple XOR type checksum. Imho, this would be too
  70. obvious, too easy to guess and forge for a virus. You should invent a
  71. more sophisticated scheme, involving a particular key for each program
  72. (e.g. a XOR-ROL loop with the amount of rotating varying in the loop).
  73.  
  74. Even a self-checking program is not immune from specific attacks. Yet,
  75. carefully designed self-checking will help to catch most viruses; and
  76. those evading your self-checking routine will eventually be catched by
  77. some other self-checking program.
  78.  
  79. Best wishes,
  80.                     Otto Stolz <RZOTTO@DKNKURZ1.Bitnet>
  81.                                <RZOTTO@nyx.uni-konstanz.de>
  82.