home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / org / eff / talk / 8591 < prev    next >
Encoding:
Text File  |  1993-01-11  |  3.2 KB  |  75 lines

  1. Newsgroups: comp.org.eff.talk
  2. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!howland.reston.ans.net!usc!sol.ctr.columbia.edu!emory!nastar!phardie
  3. From: phardie@nastar.uucp (Pete Hardie)
  4. Subject: Re: Beneficial Virus
  5. Message-ID: <1993Jan11.174828.7461@nastar.uucp>
  6. Organization: Digital Transmission Systems, Duluth, GA.
  7. References: <m503wB4w165w@ruth.UUCP>
  8. Date: Mon, 11 Jan 1993 17:48:28 GMT
  9. Lines: 64
  10.  
  11. In article <m503wB4w165w@ruth.UUCP> rat@ruth.UUCP (David Douthitt) writes:
  12. >I thought I would give some thought about how a beneficial virus would
  13. >be implemented, so that we're all arguing about the same points.
  14. >
  15. >One assumption I will be making is that the system(s) are single-user
  16. >MSDOS sites - multiuser viruses present a whole new can of worms.
  17.  
  18. Not the best of assumptions about the state of the future, but an acceptable
  19. basis for discussion.
  20.  
  21. >First, the user installs the software on their system (System A).  They
  22. >run a program called INSTALL.EXE on the provided distribution diskette.
  23. >With appropriate warnings and notifications, the install program places
  24. >the marker on the system.  It is possible that it would (with notice)
  25. >load the compression virus into memory at that time, so that it would
  26. >start to spread - or a choice could be given to place the virus on
  27. >a file or files, to be activated later (during decompression).
  28.  
  29. Why should a virus require installation?  If it requires me to run an
  30. install program, why not make it a time-run batch job that will compress
  31. the files daily?
  32.  
  33. >If the virus was contained in the MARKER, then when a compressed file
  34. >leaves the system (such as taking a compressed executable from System A
  35. >to System B) there is no virus at ALL present in the file, and the virus
  36. >does not spread.
  37.  
  38. This begins to invalidate the name 'virus' - the program then becomes a
  39. compression TSR, producing self-extracting executables
  40.  
  41. >One possible problem would be a malicious virus masquerading as a
  42. >valid marker file.  Then any file compressed with the beneficial
  43. >virus would activate the malicious virus - some sort of check would
  44. >have to be made that the virus was the *RIGHT* virus.
  45.  
  46. With all the attendant troubles of verification and the slowdown it will
  47. present.
  48.  
  49. >Having considered the infected file, let's consider the virus in operation.
  50. >It is assumed that the virus has only been placed in memory after it has
  51. >been verified that the marker was present, and it is okay for it to run.
  52.  
  53. Does the virus get removed from memory after the executable stops?  If not,
  54. then what happens when another executable is run?
  55.  
  56. >   3. If the file is not compressed, it would write out to the file on
  57. >      disk, in order:
  58. >         - the marker check routine
  59. >         - the decompression routine
  60. >         - the compressed executable
  61. >
  62. >   4. It would then delete the original and rename the temporary file to
  63. >      be the original.
  64.  
  65. Note that this would change the creation date of every executable every time
  66. the program was run.  Even on a single-user MS-DOS system, this can have
  67. some undesirable results.
  68.  
  69.  
  70. -- 
  71. Pete Hardie:  phardie@nastar  (voice) (404) 497-0101
  72. Digital Transmission Systems, Inc., Duluth GA
  73. Member, DTS Dart Team           |  cat * | egrep -v "signature virus|infection" 
  74. Position:  Goalie               |
  75.