home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl2 / virusl2.118 < prev    next >
Text File  |  1995-01-03  |  11KB  |  246 lines
  1. VIRUS-L Digest            Wednesday, 17 May 1989       Volume 2 : Issue 118
  2.  
  3. Today's Topics:
  4. Re: blown floppy disk (PC)
  5. INITs and CUSTOM resources (Mac)
  6. Re: blown floppy disk (PC)
  7. Non Boot Disks (PC)
  8. Virus that infect resource forks (MAC)
  9. (From Jim Goodwin) re: Certus
  10. Stop a BOOT loaded virus at BOOT time (PC)
  11.  
  12. ---------------------------------------------------------------------------
  13.  
  14. Date:    Tue, 1989 May 16   18:51:40 EDT
  15. From:    Bob Babcock   <PEPRBV@CFAAMP.HARVARD.EDU>
  16. Subject: Re: blown floppy disk (PC)
  17.  
  18. >     I have a 5-1/4" floppy disk under examination for possible virus
  19. >damage, and have run into an interesting problem. The disk acts like
  20. >it is totally unformatted; neither CHKDSK, RECOVER, the Norton stuff,
  21. >or anything else seems to be able to access it. The result of this is
  22. >that I cannot see anything about what has happened to the disk. What I
  23. >need is a good pd or shareware sector editor that can get at the
  24. >absolute sectors w/o trying to read the directory
  25.  
  26. One technique I have sometimes used for data recovery is to start
  27. out using a sector editor (PATCH is the one I usually use, but
  28. most any should do) on an undamaged disk with the same parameters
  29. (number of sides, sectors/track, etc.).  Once you read past the
  30. initial sectors, swap in the damaged disk without telling the
  31. program about it.  If you are lucky, you can just keep on
  32. reading.  A similar swapping technique with some file copying
  33. utilities allows copying files off a disk where the directory is
  34. unreadable.
  35.  
  36. Another possibility is the Ultra Utilities.  These are an old
  37. shareware package, I think no longer supported.  With them, you
  38. can pick a range of track numbers, sector numbers and sides and
  39. attempt to read them to see if anything is there.
  40.  
  41. ------------------------------
  42.  
  43. Date:    Tue, 16 May 89 16:44:08 EDT
  44. From:    Joe McMahon <XRJDM@SCFVM.GSFC.NASA.GOV>
  45. Subject: INITs and CUSTOM resources (Mac)
  46.  
  47. >>      ... the virus as a code resource that is preloaded to override an
  48. >> application code resource...
  49.  
  50. If the application in question allows custom resources (i.e., custom code
  51. supplied for a particular purpose), it could be used as a vector, but
  52. as a single source for spread, it would not be tremendously useful.
  53. The document in question could only spread infections if the CUST
  54. resource was invoked, which keeps most applications from spreading it.
  55. It might be a way that viral code could be introduced, though,
  56. especially if the custom feature was "nice to have". This is documented
  57. (although not from the virus standpoint) in some Tech Note or another,
  58. titled "Getting Through CUSToms".
  59.  
  60. >INITs, cdevs, and the like are "data" files; they contain no CODE
  61. >resources that make an application an application.  Conceivably, they
  62. >could be used to spread a virus as the information in the
  63. >INIT/cdev/... is executed at system startup if the file is in the
  64. >system folder...
  65.  
  66. Correct, but I think the INIT 31 mechanism (at least in System 6.0 and
  67. up) limits the files that are checked to those of type INIT, cdev, or
  68. rdev, and those files are not allowed to be invisible. Most Mac viruses
  69. (except for ANTI) try to do this to ensure they get back into RAM at
  70. boot time. Some install the INIT resources in the System file (nVIR,
  71. Peace); others take over legal files (Scores). INIT 29 just hits everything
  72. in sight, depending on luck to get something appropriate in the System folder.
  73.  
  74.  --- Joe M.
  75.  
  76. ------------------------------
  77.  
  78. Date:    Wed, 17 May 89 07:44:26 EDT
  79. From:    Harold Pritchett <HAROLD@UGA.UGA.EDU>
  80. Subject: Re: blown floppy disk (PC)
  81.  
  82. >Date:    Tue, 16 May 89 13:40:55 EDT
  83. >From:    "W. K. (Bill) Gorman" <34AEJ7D@CMUVM.BITNET>
  84. >Subject: blown floppy disk (PC)
  85. >
  86. >     I have a 5-1/4" floppy disk under examination for possible virus
  87. >damage, and have run into an interesting problem. The disk acts like
  88. >it is totally unformatted; neither CHKDSK, RECOVER, the Norton stuff,
  89. >or anything else seems to be able to access it. The result of this is
  90. >that I cannot see anything about what has happened to the disk. What I
  91. >need is a good pd or shareware sector editor that can get at the
  92. >absolute sectors w/o trying to read the directory (or else a
  93. >reasonably cheap commercial one), although I am not sure that will do
  94. >any good, since I cannot write to the disk (no, it is not write
  95. >protected) either.
  96.  
  97. The answer here is to use Norton Utilities.  While NU will not load if
  98. the bad disk is in the machine, It will work if you start NU with a
  99. good disk in the drive, and then after it is initialized, put your bad
  100. disk in and go into the sector editor.
  101.  
  102. [Ed. Norton should load with the bad disk if you use its "maintenance
  103. mode", by entering: NU /M on the command line.  As with any sector
  104. editor, proceed with due caution.]
  105.  
  106. Hope this helps
  107.  
  108. Harold C Pritchett         |  BITNET:  HAROLD@UGA
  109. BITNET TechRep             |    ARPA:  harold@fevax.uga.edu
  110. The University of Georgia  |    uucp:  gatech!ugacs!csun1!harold
  111. Athens, GA 30602           |    fido:  1:370/16
  112. (404) 542-3135             |     Bbs:  SYSOP at (404) 354-0817
  113.  
  114. ------------------------------
  115.  
  116. Date:    Wed, 17 May 89 9:51:28 CDT
  117. From:    "Len Levine" <len@evax.milw.wisc.EDU>
  118. Subject: Non Boot Disks (PC)
  119.  
  120. Steven C. Woronick <XRAYSROK@SBCCVM.BITNET> says, in his recent
  121. posting:
  122.  
  123. >   Stanley Fragakis suggests altering boot sectors so that the boot
  124. >program over-writes everything in memory with F4FA, but this of course
  125. >kills the machine, should you attempt to boot from such a disk(ette).
  126. >So I must assume that the intention is to do this only to non-system
  127. >diskettes which nobody in their right mind would want to boot from
  128. >anyway (although some of us try).  Hence, the penalty for trying to
  129. >boot a non-system diskette is no longer the usual message, but a
  130. >(temporarily) dead computer which must be powered down and back up
  131. >again.
  132. >[...]
  133.  
  134. The scheme would be a good one but for one problem.  The virus that it
  135. intends to stop has already done its dirty work before the boot block
  136. strikes.  If so, the hard disk may be already infected before the
  137. machine halts.
  138.  
  139. An advantage of the system is that the penalty foor booting from a
  140. data disk is increased, thus giving a greater and more strident
  141. reminder to the user not to do this.  For this reason I would
  142. recommend it.  It does however really smash the user who does not
  143. fully understand the system as s/he will be sure that the symptoms are
  144. those of a hardware problem.
  145.  
  146. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
  147. | Leonard P. Levine               e-mail len@evax.milw.wisc.edu |
  148. | Professor, Computer Science             Office (414) 229-5170 |
  149. | University of Wisconsin-Milwaukee       Home   (414) 962-4719 |
  150. | Milwaukee, WI 53201 U.S.A.              Modem  (414) 962-6228 |
  151. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
  152.  
  153. ------------------------------
  154.  
  155. Date:    Wed, 17 May 89 10:38:47 EDT
  156. From:    dmg@mwunix.mitre.org
  157. Subject: Virus that infect resource forks (MAC)
  158.  
  159. I'm confused.  I thought INIT 29 could infect the resource fork of any
  160. file, not ANTI, but if you are certain it is the other way around, I
  161. will not dispute you, as my knowledge of these two is not firsthand.
  162.  
  163. ------------------------------
  164.  
  165. Date:    Wed, 17-May-89 08:08:27 PDT
  166. From:    portal!cup.portal.com!Alan_J_Roberts@Sun.COM
  167. Subject: (From Jim Goodwin) re: Certus
  168.  
  169.         David Zoz was not entirely correct in his comments about the
  170. Certus program.  He did indeed help us with the initial selection for
  171. our evaluation and I appreciate his time and efforts.  We did not,
  172. however, consider including Certus as a recommended product.  We found
  173. numerous serious bugs in the product and we considered it overall to
  174. be too inflexible for the average user.  As to Dave's statement that
  175. Certus was second only to Sentry in it's ability to detect infections,
  176. I don't know where he obtained that information.  We performed
  177. full-blown tests against only the five products listed in the review.
  178. The initial selection process involved limited testing against live
  179. viruses.
  180.  
  181.         Jim Goodwin
  182.  
  183. ------------------------------
  184.  
  185. Date:    17 May 89, 18:25:05 HMT
  186. From:    Stanley Fragakis  <SSTU011@GRCRUN11.BITNET>
  187. Subject: Stop a BOOT loaded virus at BOOT time (PC)
  188.  
  189. Hello net-ppl
  190.  
  191.  Those who understood my last posting will find it easy to
  192. modify a boot sector and add the following program: (values in hex)
  193.  
  194.          Cld
  195.          Xor ax,ax
  196.          Mov ds,ax
  197.          Mov si,0445
  198.          Lodsb        ;get the track
  199.          Or al,al
  200.          Jnz Error
  201.          Lodsb        ;get the head
  202.          Or al,al
  203.          Jnz Error
  204.          Jmp 36       *****
  205. Error:   In al,61
  206.          Or al,3
  207.          Out 61,al
  208.          Cli
  209.          Hlt
  210.  
  211. The first instruction is at offset 1DBh in my MSDOS 3.2 boot sector.
  212. You should change the JMP which is at offset 0 to point to the CLD.
  213. The *ed JMP must branch to the command the offset 0 JMP used to
  214. branch.  Modify the boot sector using the DEBUG i.e.  Enter DEBUG,
  215. Load the boot sector, make the changes, write sector.
  216.  
  217. How it works:
  218.  There is a 7 byte area starting at 0:442h which contains the status
  219. of the disk controller chip e.g. where was the last read/write Using
  220. these information the BIOS can compute the total number of sectors
  221. transfered from/to disk.  Location 0:445h contains the track in which
  222. the read/write was completed, 0:446h the head value.  It should(?) be
  223. clear what I am trying to do. It is at least logical that, right after
  224. the BOOT sector is loaded the track we 'land on' should be 0, since
  225. the boot sector is in track 0 and we only read 1 sector. So the byte
  226. in 0:445h should be 0.  For the same reason the byte at 0:446h (head)
  227. should be 0.  Every boot loaded virus (any objections ?) copies the
  228. original BOOT sector in another part of the disk. When the virus
  229. initialization is completed, the original BOOT is loaded and given
  230. control.  Obviously at least 0:445h will be non-zero. The program I
  231. suggest suspects that something is wrong, sounds the beeper and halts
  232. the computer.  There is of course a way for a virus to bypass that
  233. 'protection'.  e.g. don't use the original boot sector at all.
  234.  
  235. If you have any questions, comments just let me know.
  236.  
  237. Stanley Fragakis, GREECE  (CSSTU011 at GRCRUN11)
  238.  
  239. PS. for the greeks: Stanley=Stelios :-)
  240.  
  241. ------------------------------
  242.  
  243. End of VIRUS-L Digest
  244. *********************
  245. Downloaded From P-80 International Information Systems 304-744-2253
  246.