home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl2 / virusl2.15 < prev    next >
Text File  |  1995-01-03  |  7KB  |  178 lines
  1. VIRUS-L Digest              Monday, 16 Jan 1989         Volume 2 : Issue 15
  2.  
  3. Today's Topics:
  4. Checkup version 2.1 for IBM (PC)
  5. Encrypted/Decrypted virii
  6. Request for info on other MAC viri... (Mac)
  7. CBUG: not a virus (PC)
  8. Name this book  -- for a box of cookies!
  9.  
  10. ---------------------------------------------------------------------------
  11.  
  12. Date:     FRI JAN 13, 1989 17.51.56 EST
  13. From:     "David A. Bader" <DAB3@LEHIGH>
  14. Subject:  Checkup version 2.1 for IBM (PC)
  15.  
  16. Just a note I saw on the IBMPC-L list:
  17.  
  18. CHECKUP v. 2.1 has been released and is available from SIMTEL20 at
  19. <msdos.trojan-pro>CHKUP21.ARC and is 79k.
  20.  
  21. Checkup is a program that can be used to check files' CRCs and
  22. footprints.
  23.  
  24. David Bader
  25. DAB3@LEHIGH
  26.  
  27. [Ed. The anonymous FTP is from WSMR-SIMTEL20.ARMY.MIL.  The directory
  28. is on PD1:]
  29.  
  30. ------------------------------
  31.  
  32. Date:     Fri, 13 Jan 89 21:45 EST
  33. From:     <ACS045@GMUVAX.BITNET>
  34. Subject:  Encrypted/Decrypted virii
  35.  
  36. Homer W. Smith <CTM@CORNELLC.BITNET> writes:
  37. [Magazine review/appraisal deleted]
  38. >     One of the things it said that might be done to protect programs
  39. >from viruses is to make the operating system store all programs in a
  40. >scrambled state (encryption).  Then just before running them, decrypt
  41. >them.
  42. >     When and if a virus attaches to an encrypted program, it will get
  43. >scrambled when the program is decrypted and cause a crash.
  44. >     Seems like a very very good idea.  How say you all?
  45.  
  46. It sounds good, but there is one problem here.  The virus, in order to attach
  47. itself to the file would most likely have to be in a decrypted format in order
  48. to attach itself to the host program it is trying to infect.
  49. Heres the possible problems:
  50. 1. The virus has to be in a decrypted state in order to infect the host program
  51. which itself is encrypted.  However, when the program executed, the OS will
  52. perform the encrypt/decrypt algorithm on both the program and the virus that is
  53. now attached to it. This is good for the program because it can now execute,
  54. but the unencrypted virus code will become scrambled during this
  55. process because what you're doing is decrypting a decrypted file which can
  56. only hopelessly scramble the code.
  57. 2. Okay, so an obvious way around this is to have the virus encrypt itself
  58. after infecting the targeted file, but which method to use??. With 6.02*10^23
  59. encryption schemes out there, a virus would be too big and take too much effort
  60. to try and check for even the most popular coding or encryption schemes.
  61.  
  62. The idea sounds good but thats about it....
  63. - ---Steve
  64. - --------------
  65. Steve Okay ACS045@GMUVAX.BITNET/acs045@gmuvax2.gmu.edu/CSR032 on The Source
  66.  
  67.   Disclaimer:The contents of this are less relevant than
  68.   say, the New York Times Op Ed. page, but more relevant than, say, Plywood.
  69.         ---Bloom County "Loose Tails"
  70.  
  71. [Ed. Isn't that the whole _idea_ behind encrypting executable files on
  72. disk (so that any virus infecting them would effectively neuter itself
  73. since it would be written unencrypted to disk)?  The next time the
  74. newly infected executable file would be run, it would no doubt crash -
  75. which, imho, is a far cry better than infecting another program(s).]
  76.  
  77. ------------------------------
  78.  
  79. Date:     Sat, 14 Jan 89 22:20:56 PST
  80. From:     SPOCK@CALSTATE.BITNET  (Commander Spock)
  81. Subject:  Request for info on other MAC viri... (Mac)
  82.  
  83. I need some help here.  I am currently doing a research project for an
  84. informational resource management class, and fortunately, my project
  85. is on security systems and protection, namely viruses.  I am a
  86. Macintosh user (currently two at the moment) and have heard some
  87. shocking news regarding NEW strains of "nVIR" viruses.  News is a
  88. *BIT* slow around here, so I'm one of the last to hear things (kind of
  89. sounds familiar here, don't it?).  At any rate, what does this "Hpat"
  90. virus do?  Second, there is another virus out in the Macintosh world,
  91. called "INIT 29".  I definitely DO NOT know what type and nature this
  92. fellow is.  What does this one do?
  93.  
  94. In your reply, please be specific about type, species, and any
  95. references as to where in memory it attacks, what applications are hit
  96. most often...  often (please excuse, bad terminal line...), etc.  I
  97. will be using the material that you send me in my report about viri.
  98.  
  99. Thanks in advance.
  100.  
  101. Spock          INTERNET: cbds080@ccs.csuscc.calstate.edu
  102.                          cbds080@c730.csupom.calstate.edu
  103.                  BITNET: cbds080@calstate.BITNET
  104.  
  105. "I think it has something to do with those ears..."  -- Capta  Kirk
  106.  
  107. ------------------------------
  108.  
  109. Date:     15 Jan 89 23:00:00 EST
  110. From:     Michael Brown <BROWN@CMR001.BITNET>
  111. Subject:  CBUG: not a virus (PC)
  112.  
  113. After considerable help from the netland folk, and an extensive
  114. investigation, it has been determined that CBUG is probably not a
  115. virus, and more likely, a prank program.
  116.  
  117. I would like to thank everyone for their assistance, especially, Ken
  118. and the two individuals who offered to look at the code for me.  Not
  119. only did their efforts make my life *considerably* easier, but with
  120. their help, I was able to work on the problem efficiently, and with
  121. confidence.
  122.  
  123. I say again, CBUG.COM is not a virus.
  124.  
  125. Thanx again,
  126.  
  127.                   CP6-Mail: Michael Brown @CMR
  128.                   NET-Mail: <brownm@cmr001.bitnet>
  129. Michael Brown   Snail-Mail: Service Informatique CMR, St-Jean, Que. J0J 1R0
  130.  
  131. ------------------------------
  132. Date:     Tue, 10 Jan 89 02:10:18 PST
  133. From:     cliff@LBL.Gov (Cliff Stoll)
  134. Subject:  Name this book  -- for a box of cookies!
  135.  
  136. [Ed. This is forwarded from RISKS, with this editor's recommendation
  137. to anyone who hasn't read "Stalking the Wily Hacker" to run to their
  138. library and read it *now*!]
  139.  
  140. Fellow Riskees:
  141.  
  142. I'm writing a book, and I need a title.
  143.  
  144. It's about computer risks:  counter-espionage, networks, computer security,
  145. and a hacker/cracker that broke into military computers.  It's a true
  146. story about how we caught a spy secretly prowling through the Milnet.
  147.  
  148. Although it explains technical stuff, the book is aimed at the lay reader.
  149. In addition to describing how this person stole military information,
  150. it tells of the challenges of nailing this guy, and gives a slice of
  151. life from Berkeley, California.
  152.  
  153. You can read a technical description of this incident in the
  154. Communications of the ACM, May, 1988;  or Risks Vol 6, Num 68.
  155.  
  156. Better yet, read what my editor calls "A riveting, true-life adventure
  157. of electronic espionage" ... available in September from Doubleday,
  158. publishers of the finest in computer counter-espionage nonfiction
  159. books.
  160.  
  161. So what?
  162.  
  163. Well, I'm stuck on a title.  Here's your chance to name a book.
  164.  
  165. Suggest a title (or sub-title).  If my editor chooses your title,
  166. I'll give you a free copy of the book, credit you in the acknowledgements,
  167. and send you a box of homemade chocolate chip cookies.
  168.  
  169. Send your suggestions to    CPStoll@lbl.gov   or   CPStoll@lbl (bitnet)
  170.              Many thanx!    Cliff Stoll
  171.  
  172.  
  173. ------------------------------
  174.  
  175. End of VIRUS-L Digest
  176. *********************
  177. Downloaded From P-80 International Information Systems 304-744-2253
  178.