home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / org / eff / talk / 8357 < prev    next >
Encoding:
Text File  |  1993-01-06  |  2.7 KB  |  61 lines
  1. Newsgroups: comp.org.eff.talk
  2. Path: sparky!uunet!van-bc!rsoft!mindlink!a3916
  3. From: Clayten_Hamacher@mindlink.bc.ca (Clayten Hamacher)
  4. Subject: Re: Beneficial Virus?
  5. Organization: MIND LINK! - British Columbia, Canada
  6. Date: Wed, 6 Jan 1993 10:34:30 GMT
  7. Message-ID: <19284@mindlink.bc.ca>
  8. Sender: news@deep.rsoft.bc.ca (Usenet)
  9. Lines: 50
  10.  
  11. >>Still, the question arises - suppose I decide I don't want those files
  12. stored
  13. >>compressed any more.  How would I get rid of the virus?
  14.  
  15. You either wouldn't let it 'infect' certain files or if you did you'd have a
  16. program to remove it.
  17.  
  18. >The files are not changed by being without the marker!!  The only
  19. >thing which is changed is that the virus will no longer spread itself.
  20. >The compressed file _still_ has the virus prepended.  Thus it will
  21. >_still_ be able to decompress the file upon execution.
  22.  
  23. Considering that only files that can actually be executed have control passed
  24. to them, this virus would only compress executables. Therefore you wouldn't
  25. have to worry about not being able to execute the decompression routine on a
  26. machine you transfered the file onto. If you have a reason to execute the
  27. file (ie it will run) then so will the decompression.
  28.  
  29. I also like your idea for having part of the code for the 'virus' installed
  30. in the marker file. All the code that needs to be in a compressed file is the
  31. decompression routine (and a code to search for the marker and pass control
  32. so the marker could put itself into memory). The code for compression of a
  33. file and the 'infection' of other files would be contained within the marker
  34. program for another bit of security (if a file happens to exist called
  35. VIRUSOK!.MRK or whatever the marker is called, it would still need to have
  36. the complete code for the virus to be able to infect).
  37.  
  38. If the marker contained part of the virus code then only the decompression
  39. routine (always the smaller in a compression/decompression pair) would need
  40. to be a part of the file to be packed (this would allow for a large/complex
  41. packer which would have a higher compression than a tiny routine).
  42.  
  43. I have a self-extracting archive maker that averages 45% of original size and
  44. only adds 12k over a normal archive of the same file, and that includes a
  45. full GUI with mouse support etc..
  46.  
  47.  
  48. In summary:   The safeguards with a virus like this are foolproof. The chance
  49. of a 30k (or so) marker file appearing in the right directory containing
  50. exactly the right code (virus would use a checksum on file) are so incredibly
  51. low you can't calculate it.
  52.  
  53.               Virus would be small enough and fast enough to be practical
  54. (mainly for people with small HDs) and wouldn't create any problems.
  55.  
  56.  
  57.  
  58. --
  59.  
  60. Clayten_Hamacher@Mindlink.bc.ca                 Land of the rising snow.
  61.