home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl2 / virusl2.151 < prev    next >
Text File  |  1995-01-03  |  24KB  |  524 lines

  1. VIRUS-L Digest   Thursday, 13 Jul 1989    Volume 2 : Issue 151
  2.  
  3. Today's Topics:
  4.  
  5. Re: FAT information (PC)
  6. Re: nVIR and AppleTalk (Mac)
  7. Viruscan.arc (PC)
  8. Ashar virus article
  9. Denzuk virus article
  10. ANCIENT MACS AND VACCINE
  11. Re: icons altered (Mac)
  12. Re: system folder question (Mac)
  13. Shareware? Hmm... (Mac)
  14. INIT29 and data files (Mac)
  15.  
  16. ---------------------------------------------------------------------------
  17.  
  18. Date:    Wed, 12 Jul 00 19:04:00 -0400
  19. From:    Bob Babcock <PEPRBV%CFAAMP.BITNET@IBM1.CC.Lehigh.Edu>
  20. Subject: Re: FAT information (PC)
  21.  
  22. MIROWSKI@FRECP12.BITNET writes:
  23.  
  24. >It's rarely necessary to care about the distinction between 360 Ko and
  25. >1.2 Mo disks, because the information about the format is in the second
  26. >sector of the disk (the first FAT sector) and DOS will take this second
  27. >information in consideration.
  28.  
  29. The information is also in the Bios Parameter Block (BPB) in the
  30. boot sector, and you're asking for trouble if the FAT and BPB
  31. disagree.  A while back there was a claim in PC Magazine that
  32. PC-DOS 3.3 required that the OEM id field in the boot sector
  33. contain the characters "IBM".  The evidence offered for this was
  34. that if the boot sector on a disk which PC-DOS 3.3 rejected was
  35. replaced by a boot sector from an acceptable disk, the disk
  36. became acceptable.  In fact, what was really happening was that
  37. there was bad information in the BPB, and PC-DOS was complaining
  38. about this.  I have a program called SCAT, which I got off of
  39. BIX, which writes a valid boot sector on a floppy.  The original
  40. purpose was to replace a non-standard boot sector which FastBack
  41. writes, but perhaps it would also be useful for removing a boot
  42. sector virus.  If there's any interest, I could send a copy to
  43. the moderator for posting.
  44.  
  45.  
  46. ------------------------------
  47.  
  48. Date:    Wed, 12 Jul 89 22:23:00 -0400
  49. From:    "Mark H. Anbinder" <THCY@VAX5.CCS.CORNELL.EDU>
  50. Subject: Re: nVIR and AppleTalk (Mac)
  51.  
  52. *On 5 July Joe McMahon <XRJDM@SCFVM.GSFC.NASA.GOV> said...
  53. >If your AppleTalk network only is used for mail or access to
  54. >LaserWriters, you shouldn't have a problem. If you have AppleShare
  55. >servers, make sure the servers are protected. You may have to disinfect
  56. >the odd machine here and there, but the servers should be safe.
  57.  
  58. It's true that if your network is only used for printing that CURRENTLY
  59. KNOWN Mac viruses can't spread over the network.  Some electronic mail
  60. software, though, lets users exchange files or even applications.  If an
  61. application that's infected is transferred in this way, the infection
  62. WILL be transferred.
  63.  
  64. There is no simple way of "protecting" servers themselves against the
  65. infection of the files they hold.  If an application stored on the server
  66. is executed by a person using an infected machine, that application will
  67. probably be infected.  You cannot run such things as Vaccine or GateKeeper
  68. or SAM Intercept on a server machine.  Well, you can, but it only keeps
  69. software being run ON the server from being infected; it does nothing to
  70. prevent software that RESIDES on the server from being infected.  The
  71. best way to do that is still to make sure that each workstation is as
  72. secure as possible, using frequent checks with Disinfectant, Virex, or
  73. SAM (currently the three most up to date programs), and protection with
  74. such programs as Vaccine, GateKeeper, or SAM Intercept (the best of the
  75. three, but not free).
  76.  
  77. For the curious, SAM is a new package of antiviral utilities from Symantec,
  78. the same people who created SUM.  It stands for Symantec Antivirus for
  79. the Macintosh.  I haven't finished evaluating it, but it looks great.  I
  80. will post more about it shortly.
  81.  
  82. Mark H. Anbinder
  83.  
  84. ------------------------------
  85.  
  86. Date:    Wed, 12 Jul 89 23:48:47 -0500
  87. From:    "Mark Moody" <UC364774@UMCVMB.BITNET>
  88. Subject: Viruscan.arc (PC)
  89.  
  90. Hi, Some one recently asked if Viruscan from Simtel20 had
  91.      actually detected anything.  I used it to scan some
  92.      floppies and it did detect the Yale/Alemadea Virus on
  93.      some.  I knew it was there but wanted to see what the
  94.      Prog would do. Hope this helps!
  95.  
  96.      Mark
  97.  
  98. ------------------------------
  99.  
  100. Date:    Thu, 13 Jul 89 00:38:49 +0000
  101. From:    Alan Solomon <drsolly@ibmpcug.co.uk>
  102. Subject: Ashar virus article
  103.  
  104. A comparison of Ashar and Brain
  105.  
  106. Recently, an academic institution in the South of England (who do not
  107. wish to be named) finished cleaning out a virus that put " (c) ashar"
  108. as the volume label.  They sent us a specimen for analysis - here are
  109. our findings.
  110.  
  111. Ashar is very similar to Brain, which has been described in detail
  112. elsewhere.  But there are some interesting differences, which are
  113. worth documenting, and they lead to a tentative conclusion.
  114.  
  115. Difference 1
  116.  
  117. The volume label that is put on the diskette is " (c) ashar" instead
  118. of " (c) Brain".  The text in the boot sector contains "(c) 1986 ashar
  119. & ashars (pvt) Ltd      VIRUS_SHOE RECORD" and the "V9.0" is absent.
  120. The rest of the text "Dedicated to the dynamic memories" etc is
  121. exactly the same, including the mis-spelling of "messeges" and the
  122. grammatical errors.
  123.  
  124. Difference 2
  125.  
  126. In Ashar, the volume label is put into the first available directory
  127. entry, whereas with Brain, it cannot be put into the first or second
  128. entry.  If there is a volume label on one of the first two entries, an
  129. attempt to install the system will fail, making the virus more
  130. noticeable and more of a nuisance.
  131.  
  132. Difference 3
  133.  
  134. The body of the virus, and the stored (original) boot sector, is
  135. placed in three fake bad clusters.  In Brain, this must be on or after
  136. cluster 55;  the purpose of this is probably to allow space for the
  137. Dos system files.  Ashar allows the body of the virus to be on any
  138. free cluster on the diskette.
  139.  
  140. Difference 4
  141.  
  142. Brain uses quite a complicated encryption scheme to encode the volume
  143. label that it places on diskettes, presumably to make it harder for
  144. someone to change it.  Ashar uses a much simpler scheme.  It stores
  145. the volume label as a character string, in negated form, so that all
  146. you have to do to decode it is a NEG instruction.
  147.  
  148. There are 11 bytes in Brain, which was previously thought to contain
  149. rubbish.  These 11 bytes are the negated " (c) ashar ".  Immediately
  150. after these, there is " (c) ashar $" in clear.  These 11 bytes, and
  151. the cleartext, are unused by Brain.
  152.  
  153. Difference 5
  154.  
  155. Ashar resets the floppy disk controller before reading or writing to
  156. the device in a number of places;  Brain does the reset after the
  157. access if it fails.
  158.  
  159. Difference 6
  160.  
  161. When Brain is installed in memory, and you try to look at the boot
  162. sector of a diskette, Brain reads the original boot sector that has
  163. been stored further down the diskette, and shows you that normal boot
  164. sector instead.  This applies to programs that use the data in the
  165. boot sector, but also to Debug, Norton, Mace, PC-Tools and other disk
  166. sector editors.  One of the effects of this is to mislead you into
  167. thinking that the diskette is normal.
  168.  
  169. Ashar stores the original boot sector of the diskette, and uses it to
  170. continue the boot process after an attempt has been made to boot from
  171. an infected floppy.  But it does not redirect subsequent attempts to
  172. read the boot sector.  When you look at the boot sector, you see an
  173. infected boot sector.
  174.  
  175. Conclusion on Brain
  176.  
  177. Ashar and Brain are definitely two versions of the same virus;  the
  178. code is nearly the same, apart from the differences documented above.
  179. But Brain has a sophistications that Ashar doesn't have, such as the
  180. boot-read redirection, the space left in the FAT and directory for the
  181. installation of the system, and the greatly improved encryption
  182. system.
  183.  
  184. Brain contains, as an unused remnant, the NEG-encrypted Ashar volume
  185. label.  That would tend to imply that Ashar predates Brain, and the
  186. greater sophistications in Brain tend to confirm this.  This would
  187. imply that Ashar was the precursor to Brain.
  188.  
  189. If this is true, then the version of Brain which has not got the
  190. telephone numbers on the boot sector (but has "Dedicated to the
  191. memories"), is previous to the version with the telephone numbers,
  192. which would imply that the telephone numbers version is a hack of the
  193. real Brain.  It is very easy to change the boot sector - any disk
  194. sector editor would allow that.
  195.  
  196. Until Ashar, we had no way of telling whether the "Dedicated to the
  197. memories" version came before or after the telephone numbers version.
  198. Now we have a strong indication that the telephone numbers version
  199. came afterwards.
  200.  
  201. One possibility is that Ashar is a kind of hoax;  a computer-virus
  202. Piltdown that is intended to mislead virus researchers.  It would be
  203. very difficult to change Brain to Ashar or vice versa unless you had
  204. the source code, or a very good disassembly.  Why should anyone try to
  205. fool virus "palaeontologists" in this way, when such researchers
  206. scarcely exist (yet).  And it would seem to be a pretty pointless
  207. exercise - if a programmer was that good and wanted to make their
  208. mark, they would not have simplified Brain, they would have
  209. complicated it, or even used it as a basis to write a completely
  210. different, and much worse, virus.
  211.  
  212. So, if the telephone-numbers version of Brain comes after the
  213. "Dedicated to the memories", the numbers are probably nothing to do
  214. with the virus, and the whole story of the Brain brothers and the
  215. writing of the virus comes into doubt.
  216.  
  217. More general conclusion
  218.  
  219. In order to discover this kind of information, viruses from the field
  220. must be carefully analysed.  We need some way for virus researchers to
  221. be able to exchange specimens.  Reports of vcrus sightings, and
  222. summaries and catalogues of viruses are obviously very useful, but to
  223. generate the raw material from which these can be produced, actual
  224. specimens must be analysed by researchers.
  225.  
  226.  
  227. Dr Alan Solomon                    Day voice: +44 494 791900
  228. S&S Anti Virus Group               Eve voice: +44 494 724201
  229. Water Meadow                       Fax:       +44 494 791602
  230. Germain Street,                    Data:      +44 494 724946
  231. Chesham Bucks, HP5 1LP             Usenet:    drsolly@ibmpcug.co.uk
  232. England                            Gold:      83:JNL246
  233.  
  234. ------------------------------
  235.  
  236. Date:    Thu, 13 Jul 89 00:41:06 +0000
  237. From:    Alan Solomon <drsolly@ibmpcug.co.uk>
  238. Subject: Denzuk virus article
  239.  
  240. DENZUK
  241.  
  242. DENZUK is a Boot Sector Virus.  It replaces the original boot sector
  243. with its own - this looks very like a normal boot sector, as it has
  244. the usual messages "Non-System disk or disk error", "Replace and
  245. strike any key when ready" and "Disk Boot failure".  It also has the
  246. references to IBMBIO.COM and IBMDOS.COM.  If your system files are
  247. called IO.SYS and MSDOS.SYS, DENZUK doesn't realize this, but it does
  248. mean that the boot sector looks normal.
  249.  
  250. When the boot sector runs, it loads in the rest of the virus, which is
  251. located on track 40 (normal 360k diskettes have tracks numbered 0 to
  252. 39), head 0, sectors 33 to 41 (normal tracks are numbered from 1).
  253. Putting the virus in this place means that some disk-searching
  254. utilities won't find it there.  It also means that if you Diskcopy the
  255. infected diskette, most of the virus fails to copy.  This gives us one
  256. simple way to clean up an infection - DENZUK could almost be called a
  257. copy-protected virus!  If you Diskcopy an infected diskette, the
  258. DENZUK boot is copied, but not the rest of DENZUK.  If you use COPY or
  259. XCOPY to copy the diskette, then the infected boot is left behind
  260. also.  Of course, you must boot from a known clean diskette before you
  261. start.
  262.  
  263. When DENZUK runs the code that it has loaded in from track 40, it
  264. replaces two of the PC's interrupts, $13 (diskette) and 9 (keyboard).
  265. A new interrupt is installed, $6F, which is the old interrupt $13;
  266. DENZUK uses this as a short way to call the original routine.  The new
  267. interrupt 9 looks for two keystrokes.  On seeing a Ctrl-Alt-Del, it
  268. calls a routine that displays its logo (if it is running on anything
  269. apart from a mono monitor), and then reboots.  The other keystroke is
  270. Ctrl-Alt-F5, which just triggers a reboot.  This is a convenient test
  271. to see if you are infected, as on a PC that is not running DENZUK,
  272. Ctrl-Alt-F5 does nothing.  All other keystrokes are passed on to
  273. the original interrupt 9 routine.
  274.  
  275. The DENZUK logo is a graphic, with the words "DEN ZUK" in large red
  276. letters.  The pixels making up these letters come in from each side
  277. until they merge making the words; there is also a symbol to the side
  278. that looks rather like a stylised globe.
  279.  
  280. Interrupt $13 is used to infect more diskettes.  Every time interrupt
  281. $13 is called, provided it is referencing one of the two floppy drives
  282. (DENZUK will not infect a hard disk), and provided the call is a read,
  283. write, verify or format, DENZUK will decrement its infection counter
  284. (which is initially set to eight).  When the counter reaches zero,
  285. this triggers the infection process, and the counter is set back to
  286. two.
  287.  
  288. The infection process works like this.  First it reads the sector at
  289. cylinder 0, head 0, sector 1.  It looks for two bytes that are found
  290. in DENZUK, and if it finds them, it doesn't infect.  If they are
  291. absent, it looks for two other bytes which we surmise are an old
  292. version of DENZUK;  if it finds those, it calls the "Find Denzuk Boot"
  293. routine, whereby it reads the boot sector from trach 40, head 0,
  294. sector 33 which is where the original boot is stored.  Thus, DENZUK
  295. will update you if it finds that you are running an out-of-date
  296. version of the virus.
  297.  
  298. If DENZUK finds Brain (or Ashar) virus on the boot sector (which it
  299. does by looking for the $1234 signature of Brain) then it upgrades you
  300. from Brain to DENZUK.  First, though, it has to go and find the boot
  301. sector from where Brain has put it;  Brain has three bytes on sector
  302. cylinder 0, head 0, sector 1 that tells you where the original boot
  303. sector is, and DENZUK decodes these and reads the boot sector.
  304.  
  305. Whether the diskette was clean, old-DENZUK or Brain, DENZUK now has
  306. the original boot sector.  It formats track 40 head 0, and writes its
  307. nine sectors there.  If this write is successful (some diskette drives
  308. may not allow writing beyond track 39) then it replaces the sector at
  309. cylinder 0, head 0 sector 1 with its own version of the boot sector.
  310. The infection process is now complete.  It then scans through the
  311. directory to see if there is a volume labels there.  Brain, you may
  312. recall, puts " (c) Brain" as a volume label on the diskette.  DENZUK
  313. overwrites that with its own label, which is "Y.C.1.E.R.P", where the
  314. .  is character $F9.  DENZUK assumes that it is looking at a 360k
  315. diskette, but makes no attempt to ensure that this is the case.
  316. This directory scan starts at sector 0, 0, 6, and scans through
  317. seven sectors; just right for a 360k diskette.  The meaning of this
  318. volume label is obscure.
  319.  
  320. There is also a generation counter, which keeps track of how many
  321. generations have passed;  if this is less than three, then DENZUK
  322. refrains from its visible signs - the logo is not displayed on reboot,
  323. and the volume label is not changed.  The specimen that we had
  324. was generation $14. This feature is probably to give it a chance to
  325. spread a bit before detecting it becomes easy.
  326.  
  327. DENZUK puts the BRAIN signature on the boot sector - this would stop
  328. Brain from infecting a DENZUK-infected diskette. So in a population
  329. of Brain-infected diskettes, DENZUK would tend tobe the virus that
  330. would get the upper hand.
  331.  
  332. There are a couple of text messages in the virus, which are not
  333. displayed. These are:
  334.  
  335. At the beginning:
  336.  
  337. "Welcome to the
  338.     C l u b
  339. - --The HackerS--
  340.     Hackin'
  341. All The Time   "
  342.  
  343. At the end:
  344.  
  345. "The HackerS"
  346.  
  347. It might be thought that DENZUK is actually a helpful virus, in that
  348. it kills Brain.  This is not so - consider what will happen if DENZUK
  349. infects a diskette with more than 40 tracks.  Track 40 would be
  350. overwritten, and data could be lost as a result.  Even worse, DENZUK
  351. assumes that all diskettes are 360 kb diskettes, so when it infects
  352. them, it puts a 360 kb diskette boot sector on top of the old boot
  353. sector.  This tells Dos that the diskette has 2+2 FAT sectors and 7
  354. directory sectors, which is not the case.  So Dos is not able to read
  355. the diskette properly, and interprets the directory as part of the
  356. FAT, and (depending on what diskette it is) can get the cluster size
  357. wrong, and might ignore some of the sectors on each track.  In other
  358. words, DENZUK infecting a 5 1.4 inch 1.2 mb diskette leaves it
  359. unreadable, although putting a correct boot sector back in place will
  360. rescue most of the data (trach 40 head 0 is gone for ever).  Other
  361. capacity diskettes (other than 360 kb) will also have problems.
  362.  
  363. Our specimen of DENZUK came from an academic institution in the UK,
  364. which prefers to remain unnamed. It is the only reported instance
  365. of DENZUK in the UK so far, apart from lab specimens.
  366.  
  367. We have added tools for dealing with DENZUK to our Anti Virus Toolkit.
  368. If you need more information about this virus, or any of the others,
  369. please contact me at the address below.
  370.  
  371. Dr Alan Solomon                Day voice:     +44 494 791900
  372. S&S Anti Virus Group           Eve voice:     +44 494 724201
  373. Water Meadow                   Fax:           +44 494 791602
  374. Germain Street,                BBS:           +44 494 724946
  375. Chesham,                       Fido node:     254/29
  376. Bucks, HP5 1LP                 Usenet:        drsolly@ibmpcug.co.uk
  377. England                        Gold:          83:JNL246
  378.                                CIX, CONNECT   drsolly
  379.  
  380. ------------------------------
  381.  
  382. Date:    Thu, 13 Jul 89 13:48:57 -0000
  383. From:    LBA002@PRIME-A.TEES-POLY.AC.UK
  384. Subject: ANCIENT MACS AND VACCINE
  385.  
  386. Sorry to have to keep replying to the LIST at large but I haven't quite
  387. got the hang of replying to individual addresses.
  388. I've checked our machines and they are only 512K, upgraded to take 800K
  389. discs.
  390. I've been able to ResEdit Vaccine into my System 3.2 and all seems to be
  391. OK now. Not that it will stop our students using their own discs and
  392. infecting each other, or from pirating software!
  393. Many thanks to everyone who has offered advice and information.
  394. Rgds,
  395. Iain Noble
  396.  
  397. ------------------------------
  398.  
  399. Date:    Thu, 13 Jul 89 10:25:40 -0400
  400. From:    Joe McMahon <XRJDM@SCFVM.GSFC.NASA.GOV>
  401. Subject: Re: icons altered (Mac)
  402.  
  403. >Date:    Wed, 12 Jul 89 11:52:48 -0500
  404. >From:    Lee Brannon <CCREBEL@INDST.BITNET>
  405. >system, and I now suspect that I may have found a third...
  406. >                                          ...My System, Finder, Clipboard
  407. >                     and scrapbook icons have changed.
  408. >
  409. >                     Unlike the scores virus...they have changed to better
  410. >                     drawings of the mac plus with shaded screens...
  411.  
  412. Not to worry. Sounds like someone has installed ColorFinder on your
  413. Mac.  It just hooks the ICON-drawing trap and puts up prettier icons.
  414. Look around in your System Folder for the ColorFinder file. You can
  415. simply trash it if you don't like it.
  416.  
  417.  --- Joe M
  418.  
  419. ------------------------------
  420.  
  421. Date:    Thu, 13 Jul 89 09:35:34 -0500
  422. From:    <ACSH@UHUPVM1.BITNET>
  423. Subject: Re: system folder question (Mac)
  424.  
  425. >Date:    Wed, 12 Jul 89 11:52:48 -0500
  426. >From:    Lee Brannon <CCREBEL@INDST.BITNET>
  427. >Subject: Macintosh system folder looks suspect
  428. >
  429. >I am a Mac user who has already run across two virus programs on my
  430. >system, and I now suspect that I may have found a third. Any of you
  431. >who are using a macinto sh and have come across the following symptons
  432. >please drop me a line (especiall y if you know the cause):
  433. >
  434. >                     Like the scores virus...My System, Finder, Clipboard
  435. >                     and scrapbook icons have changed.
  436. >
  437. >                     Unlike the scores virus...they have changed to better
  438. >                     drawings of the mac plus with shaded screens
  439.  
  440. Sounds to me like the Beta Release of Multi-Finder (called Juggler I
  441. believe) which vastly improved the Macintosh Icons, but, alas, they
  442. were their same old ugly selves when it was finally released.
  443. Acknowledge-To: <ACSH@UHUPVM1>
  444.  
  445. ------------------------------
  446.  
  447. Date:    Thu, 13 Jul 89 11:36:59 -0400
  448. From:    Joe McMahon <XRJDM@SCFVM.BITNET>
  449. Subject: Shareware? Hmm... (Mac)
  450.  
  451. I received a visit from a Mac user here at NASA this morning who was
  452. very upset about a letter he received concerning Virus Detective(tm).
  453.  
  454. It seems that he had decided that he wanted to keep VD, so after reading
  455. the dialog telling where to send the money and how much, he sent in
  456. a check for $25. (He had version 2.2; I verified that the "Credits"
  457. dialog up to and including version 3.0 specified this amount).
  458.  
  459. He then received a letter from the author *billing* him for an extra
  460. $15! It seems that the price went up with version 3.0.1. (I verified
  461. that too.)
  462.  
  463. He has returned the disk which was sent him and has requested his money
  464. back. I have never heard of any shareware author billing anyone before.
  465.  
  466. I'd appreciate opinions on whether we should continue to support the
  467. author by making this software available. I'd even more appreciate a
  468. direct response from the author, if he reads this list.
  469.  
  470. I'm posting this partly in the hope that he will respond, and partly
  471. because I truly dislike denying access to a good tool possibly because
  472. of a one-time mistake or misunderstanding. I'd appreciate _direct_ replies
  473. from the readers of this list as to their thoughts and feelings on the
  474. subject. Thanks.
  475.  
  476.  --- Joe M.
  477.  
  478. Internet: xrjdm@scfvm.gsfc.nasa.gov |  "NOOOOO one expects the Spanish
  479.    Phone: (301) 286-8090            |  Inquisition!" -- Cardinal Ximenes
  480.  
  481. ------------------------------
  482.  
  483. Date:    Thu, 13 Jul 89 10:41:00 -0500
  484. From:    Holly Lee Stowe <IHLS400@INDYCMS.BITNET>
  485. Subject: INIT29 and data files (Mac)
  486.  
  487.  
  488. Chris Krohn (>) replies to Michael Niehaus (> ##) about viruses
  489.     spreading from data files:
  490.  
  491. > ##All of the other files on the
  492. > ##network are data files.  Viruses cannot be spread from these data files.
  493. >
  494. >     Not true.  The Init29 virus, for example, will infect data files
  495. > as well as applications.
  496.  
  497. Chris, I think you've misunderstood what Michael stated.  INIT29 can indeed
  498. spread to data files, but as far as I know, it is not capable of spreading
  499. *from* data files back to applications.
  500.  
  501. Also, for anyone using Macs and trying to teach others about what things
  502. to be aware, may I recommend highly a Hypercard stack called the Virus
  503. Encyclopedia which is available on GEnie and probably other places.
  504. (The author's name is Henry C. Schmitt, and he's from the Northwest of
  505. Us, a user group in Arlington Heights, IL.)  Also the informational
  506. screens from John Norstad's Disinfectant are very helpful.
  507.  
  508. - -Holly
  509.  
  510.   If something is preposterous, does it later become postposterous?
  511. +---------------------------------------------------------------------+
  512. |    @@@ @@@   @@@ @@@@@@@@@ @@@   @@@ @@@   Holly Lee Stowe          |
  513. |   @@@ @@@   @@@ @@@   @@@ @@@   @@@ @@@    Bitnet:  IHLS400@INDYCMS |
  514. |  @@@ @@@   @@@ @@@@@@@@@ @@@   @@@ @@@     IUPUI Computing Services |
  515. | @@@  @@@@@@@@ @@@        @@@@@@@@ @@@      799 West Michigan Street |
  516. | Indiana U. - Purdue U. at Indianapolis     Indianapolis, IN   46202 |
  517. +---------------------------------------------------------------------+
  518.  
  519. ------------------------------
  520.  
  521. End of VIRUS-L Digest
  522. *********************
  523. Downloaded From P-80 International Information Systems 304-744-2253
  524.