home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl2 / virusl2.115 < prev    next >
Text File  |  1995-01-03  |  7KB  |  177 lines
  1. VIRUS-L Digest              Monday, 15 May 1989        Volume 2 : Issue 115
  2.  
  3. Today's Topics:
  4. Macintosh Virus query
  5. Follow-up to "Yet another virus?" (Mac)
  6. Certus (PC)
  7. Stop a BOOT virus at BOOT time (PC)
  8. re: data disks (PC)
  9.  
  10. ---------------------------------------------------------------------------
  11.  
  12. Date:    Fri, 12 May 89 10:50:06 EDT
  13. From:    rocksanne!rainero@cs.rochester.edu (Emil Rainero)
  14. Subject: Macintosh Virus query
  15.  
  16. Has there ever been a macintosh virus than is part of a document? The
  17. macintosh has both data and resource forks. It would be interesting to
  18. create a macwrite or MS-word document with the document in the data
  19. fork and the virus as a code resource that is preloaded to override an
  20. application code resource (the printing code comes to mind). This
  21. would allow documents as well as applications to transfer the virus.
  22.  
  23. ------------------------------
  24.  
  25. Date:    Fri, 12 May 89       14:55:24 PST
  26. From:    Donna Reynolds <DR9021@UCSFVM.UCSF.EDU>
  27. Subject: Follow-up to "Yet another virus?" (Mac)
  28.  
  29. Yesterday we posted a notice to the net describing a number of
  30. apparently virus-like problems experienced in the UCSF Computer
  31. Center.  All were detected while MacDraw was in use.  It now appears
  32. that all problems were unrelated and that none were virus-induced.
  33. Just an unhappy coincidence, it would seem, that three separate
  34. machines developed similar-looking difficulties at the same time.
  35.  
  36. Ken Walter, a software engineer with Claris, solved one of our
  37. problems for us.  The system errors on one machine appear to be the
  38. result of running MacDraw 1.9 with System 6.02.  We now suspect the
  39. problems exhibited by the two remaining machines to be
  40. hardware-related.  They just happened to show up at about the same
  41. time while users just happened to be running MacDraw.  We are
  42. currently running additional diagnostic tests, just to be certain.
  43.  
  44. That said, we'd like to thank everyone who responded to our posting.
  45. The ever-helpful folks at BMUG were quick to get in touch and offer
  46. their assistance.  Ken Walter of Claris, and the Claris folks in
  47. general, were exceptionally helpful.  We sincerely appreciate both
  48. their expert assistance and their genuine concern.
  49.  
  50. Once again, our most sincere thanks.
  51.  
  52. Donna Reynolds
  53. Senior Editor
  54. UCSF Computer Center
  55.  
  56. ------------------------------
  57.  
  58. Date:    Sun, 14-May-89 22:14:15 PDT
  59. From:    portal!cup.portal.com!Alan_J_Roberts@Sun.COM
  60. Subject: Certus (PC)
  61.  
  62.         I'll have to disagree with Bill Gorman's comments about the
  63. Certus virus protection package.  I worked on the preliminary
  64. selection for Jim Goodwin's evaluation project and I found none of the
  65. negative's that Mr.  Gorman indicated.  Additionally, Certus proved
  66. second only to Sentry in it's ability to detect viruses.  I believe
  67. Jim would have included it in his final paper had he not thought that
  68. the steep price of the product limited its interest for most
  69. researchers.
  70.  
  71.                         David Zoz
  72.                         HomeBase  408 988 4004
  73.  
  74. ------------------------------
  75.  
  76. Date:    15 May 89, 12:14:09 HMT
  77. From:    Stanley Fragakis <CSSTU011@GRCRUN11.BITNET>
  78. Subject: Stop a BOOT virus at BOOT time (PC)
  79.  
  80. The idea:
  81.  When the boot sector is read in memory and given control its the only
  82. valid program in RAM. Other valid RAM locations include the interrupt
  83. vector table etc. Normally a boot loaded virus has it's own boot
  84. sector which loads the virus in memory and gives control to the
  85. original boot sector of the disk.  (the original boot sector is saved
  86. somewhere in the disk).  If we modify the original boot sector of the
  87. disk in such a way that clears the computer memory when executed, we
  88. will kill the virus code since it HAS TO be somewhere in RAM.
  89.  
  90. What to do and how :
  91.  The MSDOS 3.2 disk boot sector contains in offset 0 a JMP instruction
  92. (JMP 36). In the boot sector there is just enough space to add a few
  93. instructions that will clear the memory starting at 7e0:0h. Again in
  94. MSDOS 3.2 the 1st free location is at offset 1DBh. We enter the MSDOS
  95. DEBUG and type :
  96.  
  97. - - L 0 0 0 1 (enter)
  98. - - a 1db     (enter)
  99. then we type the following commands
  100.  
  101.  CLI
  102.  CLD
  103.  MOV AX,07E0
  104.  MOV ES,AX
  105.  XOR DI,DI
  106.  MOV CX,8
  107.  MOV AX,F4FA
  108.  REP STOSW
  109.  PUSH ES
  110.  POP AX
  111.  INC AX
  112.  CMP AX,A000
  113.  JB 1E0
  114.  JMP 36
  115.  
  116. Now we type :
  117. - - A 0
  118. then
  119.  JMP 1DB
  120.  
  121. finally we save the new boot using
  122. - - W 0 0 0 1
  123.  
  124. let's see what's the use of this program.
  125. Staring at seg 7E0 it fills the memory locations with hex value
  126. F4FA  witch represents the assembler instructions CLI, HLT
  127. It stops when the segment reaches A000 (the 640K limit)
  128. the JB 1E0  jumps to instruction MOV ES,AX
  129. the JMP 36  jumps to the location the JMP at offset 0 originally
  130.             points to.
  131.  
  132. Note that the locations 36,1E0,1DB as mentioned above could
  133. be different in your MSDOS version.
  134.  
  135. Why fill the memory with F4FA :
  136.  When the original boot sector gets control and we are about to clear
  137. the memory, the virus is already active. That means one or more
  138. interrupt vectors point into virus code. Sooner or later these
  139. interrupts will be activated. If we fill the memory with e.g. 0 that
  140. would represent an ADD instruction and the computer would execute ADD
  141. instructions even beyond the valid RAM. We wish to halt the computer.
  142. A simple HLT instruction would not be enough since the external
  143. interrupts are enabled (e.g. timer tick so we have the same problem as
  144. before).  The solution is CLI then HLT, that is make sure that
  145. interrupts are disabled then halt the CPU till an interrupt occurs.
  146. (which is never going to happen, so computer is 'dead' ).
  147.  
  148. What's the use :
  149.  It is quite clear that any Ping Pong style virus will be stopped. How
  150. will you know that ? Well the computer will crash if you boot with an
  151. infected disk (you get no message at all).  You can't even use
  152. CTRL-ALT-DEL to re-Boot. This is the time to check your disk.  This
  153. program will not prevent a virus from entering your disk.  However it
  154. will not let you boot from that disk, not even once |
  155.  
  156. if you have any questions let me know.
  157.  
  158. * Stanley Fragakis, Greece (CSSTU011 at GRCRUN11)
  159.  
  160. ------------------------------
  161.  
  162. Date:    Wed, 10 May 89 19:22:34 -0400
  163. From:    William Bader-84668 <wbader@scarecrow.csee.Lehigh.EDU>
  164. Subject: re: data disks (PC)
  165.  
  166. Someone mentioned viruses propagating on data disks.  I don't know if
  167. this was said before, but MSDOS formatted data disks are bootable,
  168. just that all the boot program does is to print "Non-System disk or
  169. disk error. Replace and strike any key when ready".
  170.                                                 William Bader
  171.  
  172. ------------------------------
  173.  
  174. End of VIRUS-L Digest
  175. *********************
  176. Downloaded From P-80 International Information Systems 304-744-2253
  177.