home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl3 / virusl3.43 < prev    next >
Text File  |  1995-01-03  |  25KB  |  552 lines

  1. VIRUS-L Digest   Thursday, 15 Feb 1990    Volume 3 : Issue 43
  2.  
  3. Today's Topics:
  4.  
  5. Re: The ethics of virus eradication
  6. Re: Many WDEF reports (Mac)
  7. Strange Macintosh Beeps (Mac)
  8. Algorithms
  9. WDef hits Carleton
  10. Undetectable Virus (Mac)
  11. Re: The AIDS "Trojan" is a Copy Protection System
  12. Re: Forwarded: Re: *UNCONFIRMED* PC virus
  13. Dr. Popp
  14. Universal Virus Detector
  15. New virus in Canada??? (Mac)
  16. UNIX discussions?
  17. Re: Many WDEF reports (Mac)
  18. Virus Buster (PC)
  19.  
  20. VIRUS-L is a moderated, digested mail forum for discussing computer
  21. virus issues; comp.virus is a non-digested Usenet counterpart.
  22. Discussions are not limited to any one hardware/software platform -
  23. diversity is welcomed.  Contributions should be relevant, concise,
  24. polite, etc., and sent to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's
  25. LEHIIBM1.BITNET for BITNET folks).  Information on accessing
  26. anti-virus, document, and back-issue archives is distributed
  27. periodically on the list.  Administrative mail (comments, suggestions,
  28. and so forth) should be sent to me at: krvw@SEI.CMU.EDU.
  29.  - Ken van Wyk
  30.  
  31. ---------------------------------------------------------------------------
  32.  
  33. Date:    14 Feb 90 20:06:52 +0000
  34. From:    jalden@eleazar.dartmouth.edu (Joshua M. Alden)
  35. Subject: Re: The ethics of virus eradication
  36.  
  37. FEDERMAN@IPFWCVAX.BITNET writes:
  38. >This week (Feb 5th-9th, 1990) marked the first occurrence of PC
  39. >computer viruses on our campus. First our Library received the census
  40. >disk, which we were warned of, and secondly a faculty member was
  41. >infected by Jerusalem B. I was able to clean-up this system with some
  42. >effort in about an hour. This was the last thing I did on Thursday
  43. >afternoon. On Friday, I posted mail to all campus mainframe account
  44. >holders (most of our campus users since our PC network is just in the
  45. >beginning phase) about the two incidents, and how to avoid virus
  46. >infections. In this E-mail message, I was particularly careful not to
  47. >mention the name or department of the faculty member involved.
  48. >
  49. >Well, that didn't work. The faculty member was extremely angry about
  50. >the E-mail message. I did mention the type of program that was the
  51. >supposed virus vector. He contended that anyone on campus would figure
  52. >out his identity from the type of program (fractals), since he was
  53. >teaching a continuing course on the subject. I won't go into the
  54. >details of the venom that was directed my way.
  55. >
  56. >My questions are these - what should I have done? Kept the infection
  57. >secret? Are computer viruses a Social Disease? Are we physicians who
  58. >are supposed to swear some form of Computerized Hippocratic Oath of
  59. >confidentiality? Or, do we paint a Scarlet-V on the heads(or
  60. >terminals) of those unfortunate ( careless enough) to become infected?
  61. >I would like to hear of similar experiences and policies enacted to
  62. >deal with virus infections.
  63.  
  64. Alan -
  65.  
  66.     It sounds to me as though you did exactly the right thing.  Taking
  67. reasonable care not to reveal who was affected by the virus was a
  68. responsible action.  So was informing as many people as possible of the
  69. incident in order to prevent any more damage.
  70.  
  71.     I don't know how you phrased the e-mail message, but my guess is
  72. that you did not insult the faculty member, nor imply awful things about
  73. his character.  Why he was upset I really can't imagine; most of us have
  74. been infected at one point or another, whether through carelessness,
  75. lack of knowledge, or whatever.  Having been hit with a computer virus
  76. certainly shouldn't be cause for ostracism or any other sort of punitive
  77. behavior.
  78.  
  79.     Furthermore, unless that fractals program was a very specific one, I
  80. doubt that it pointed to him any more specifically than any other
  81. program that generates wierd graphic output.  In high school, a friend
  82. of mine and I used to generate pretty color designs on his PC using a
  83. Mandelbrot program.
  84.  
  85.     I wouldn't worry about it too much, unless the professor continues
  86. to give you trouble about it.  Education is the key in the anti-viral
  87. world, as it is in any situation involving an epidemic.  Trying to
  88. conceal outbreaks, especially when the worst result is embarrassment, is
  89. foolish.
  90.  
  91. - -Josh.
  92.  
  93.  /--------------------------------------------------+-------------------------\
  94.  |Josh Alden, Consultant, Kiewit Computation Center | HB 48, Dartmouth College|
  95.  |   Private mail: Joshua.Alden@dartmouth.edu       | Hanover, NH     03755   |
  96.  |    Virus mail:   Virus.Info@dartmouth.edu        |      (802) 295-9073     |
  97.  
  98. ------------------------------
  99.  
  100. Date:    Wed, 14 Feb 90 12:16:31 -0600
  101. From:    John Norstad <jln@acns.nwu.edu>
  102. Subject: Re: Many WDEF reports (Mac)
  103.  
  104. CHESS@YKTVMV.BITNET (David.M..Chess) writes:
  105. > Curious as to why we're seeing all these WDEF reports, and not similar
  106. > numbers of reports of other widespread viruses.  Has it just become a
  107. > tradition to report WDEF on VIRUS-L, or is WDEF better at spreading?
  108. > If the latter, does anyone have a good feeling for what about WDEF
  109. > makes it so (um) virulent?  DC
  110.  
  111. WDEF now appears to be the most widespread of all the Mac viruses - more
  112. widespread than even nVIR A and B.  I don't know why.  I do know that by
  113. the time it was discovered in early December of 1989, it had already
  114. spread very widely.  We clearly didn't catch it until it had been around
  115. for quite some time.
  116.  
  117. One reason for not being detected earlier is almost certainly that WDEF
  118. contained special code to get past all but one of the popular virus
  119. protection INITs.  All of these INITs have since been improved to catch
  120. WDEF, but when it first began to spread only AntiToxin would catch it - it
  121. got past Vaccine, GateKeeper, SAM Intercept, and the Virex INIT.  This is
  122. a problem with the general-purpose suspicious activity monitor virus
  123. protection INITs on the Mac - with enough effort a new virus can evade
  124. their protection measures.
  125.  
  126. A properly used checksumming system is clearly the most reliable way to
  127. catch new viruses.  This topic has been beaten to death on virus-l.  The
  128. problem with such systems is convincing users to make use of them.
  129.  
  130. WDEF is also clearly one of the most buggy Mac viruses.  It doesn't
  131. attempt to do any damage on purpose, but it does contain bugs which can
  132. and do cause almost anything to go wrong with the proper functioning of
  133. Macintoshes.  We've seen everything from problems with the proper display
  134. of font styles to trashed disks.
  135.  
  136. I don't think it's necessary for everybody to report every sighting of
  137. WDEF here on VIRUS-L.  I gave up trying to keep track of all the sightings
  138. a long time ago - it's everywhere.
  139.  
  140. It's also interesting that WDEF appears to be much more widespread outside
  141. the university environment than any of the previous Mac viruses.  The
  142. so-called "serious business community" (as if universities somehow don't
  143. count in capitalist America) is getting hit hard.  Perhaps the silver
  144. lining in this very dark cloud will be an increased awareness of the
  145. problem among the public, and perhaps people will even finally start to
  146. take measures to protect their machines.
  147.  
  148. The Mac anti-viral community did an excellent job of combatting WDEF.
  149. Within two days of the discovery of the virus we had disassembled and
  150. analyzed the virus and informed the public with accurate, complete
  151. information.  Within a week there were tools available for detecting and
  152. eliminating the virus.  Within two weeks there were tools available that
  153. actually worked properly :-).  We have established a very effective group
  154. on the Internet of anti-viral tool authors (commericial, shareware, and
  155. freeware) and other experts which goes into high gear whenever a new
  156. virus, Trojan, or other kind of destructive Mac software appears.
  157.  
  158. John Norstad (author of Disinfectant)
  159. Northwestern University
  160. jln@acns.nwu.edu
  161.  
  162. ------------------------------
  163.  
  164. Date:    Wed, 14 Feb 90 16:07:15 -0500
  165. From:    dmg@lid.mitre.org (David Gursky)
  166. Subject: Strange Macintosh Beeps (Mac)
  167.  
  168. If you do not have Macintalk in your System Folder, the nVIR virus
  169. will cause the Mac to beep (or make whatever sound is selected as the
  170. System Beep) on a periodic basis.  The period is well defined, but I
  171. do not know it.  If Macintalk is installed, the Mac will speak "Don't
  172. worry".
  173.  
  174. WDEF does not make any noises.
  175.  
  176. ------------------------------
  177.  
  178. Date:    Wed, 14 Feb 90 14:25:36 -0500
  179. From:    David_Conrad%Wayne-MTS@um.cc.umich.edu
  180. Subject: Algorithms
  181.  
  182.    Could someone provide a bibliography on the subject of data
  183. verification algorithms (CRC, MD4, ...)?  Reply to me or the list.
  184. Assume access to good public and university libraries.
  185.                              Thank you,
  186.                              David R. Conrad
  187.  
  188. BITNET: David_Conrad%Wayne-MTS@um.cc.umich.edu
  189. "You cannot propel yourself forward by patting yourself on the back."
  190.  
  191. ------------------------------
  192.  
  193. Date:    Wed, 14 Feb 90 15:37:00 -0600
  194. From:    "Paul Duckenfield (Consultant, User Services)" <DUCKENFP@carleton.edu>
  195. Subject: WDef hits Carleton
  196.  
  197.         For the past four or five months, the Carleton College Micro Lab
  198. has been plagued by inexplicable crashes. In the past month, the crashes
  199. have escalated in volume to as many four or five a day. Here is our
  200. configuration-
  201.  
  202.         Macintosh IIcx file server
  203.                 o 2 MB RAM
  204.                 o twin 40MB HD's (one internal, one external, both Apple)
  205.                 o AppleShare v2.0.1
  206.         22 Macintosh Pluses in a Lab (LocalTalk)
  207.                 o 2.5MB RAM
  208.                 o Running RAM disks
  209.          8 Macintosh Pluses in a remote lab (served by TOPS Repeater)
  210.                 o same as above
  211.         10 Staff Macs scattered throughout offices
  212.                 o various types (CX, Plus, SEHD)
  213.         All running System 6.0.3 (except CX's which run 6.0.4)
  214.  
  215.         sometimes we run the Apple Print Spooler, but sometimes we have
  216. trouble with that.
  217.  
  218.         Symptoms:
  219.  
  220.                 o Print Spooler crashes 15 minutes before server (that is
  221.                         why we don't always use it)
  222.                 o Internal HD light on server turns on and stays on
  223.                 o Everyone gets the "watch" when they attempt to access
  224.                         the server and it never goes away
  225.                 o restarting the IIcx and the workstations temporarily
  226.                         solves the problem (until the next crash!)
  227.  
  228.         What we did:
  229.  
  230.                 Reformatted the HD from scratch and reinstalled software.
  231. The server still crashed. Then we ran Disinfectant v1.6. It told us that
  232. the server was infected with WDef. We removed WDef. Problems began appearing
  233. a few days later, same as before. Again we checked for WDef, but it wasn't
  234. there. A few days later, it reappeared (it is possible that it accidentilly
  235. found its way in through a server administration disk).
  236.                 Finally, we killed the DESKTOP file to prevent WDEF from
  237. having a refuge of any sort. This appears to have worked for there haven't
  238. been any crashes in awhile.
  239.  
  240.         Conclusions-
  241.  
  242.         o WDef is never "really" eradicated, even when Disinfectant kills
  243. it. Like pnuemonia, it goes away, but lasting damage remains.
  244.         o WDef infections to file servers can be prevented by canning the
  245.                 DeskTop file which is unused.
  246.         o WDef is extremely virulent and elusive.
  247.  
  248.                         Paul Duckenfield
  249.                         Micro Consultant
  250.                         Carleton College
  251.                         User Services
  252.                         DUCKENFP@CARLETON.EDU
  253.  
  254. ------------------------------
  255.  
  256. Date:    14 Feb 90 21:58:28 +0000
  257. From:    harvey@nems.dt.navy.mil (Betty Harvey)
  258. Subject: Undetectable Virus (Mac)
  259.  
  260.         I have seen two Macintoshes that have a virus that I can't seem
  261. to recognize.  I have run Disinfectant 1.6 because I thought it was the
  262. WDEF virus that I have been reading about but disinfectant didn't find
  263. anything abnormal.  I have also ran several other virus eradicaters and
  264. they didn't recognize anything out of the ordinary.
  265.  
  266.                         Symptoms:
  267.  
  268.         The system file increases in size and the date changes
  269.         each time the system is rebooted.  One system file was
  270.         2 meg long before all application program ceased to work.
  271.  
  272.         Applications unexpectedly stop.
  273.  
  274.         The system hoses up occasionally when going to the printer.
  275.  
  276. Is anyone aware of any new viruses or what I might be dealing with.
  277. We had a massive outbreak of Scores and nVir about 1 year ago, but
  278. have had fairly healthy machines since then.
  279. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
  280. Betty Harvey  <harvey@nems.dt.nav.mil>              |
  281. David Taylor Research Center                        |
  282. Office Automation/Microcomputer Support Branch      |
  283. Bethesda, Md.  20084-5000                           |
  284.                                                     |
  285. (301)227-4901                                       |
  286. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/
  287.  
  288. ------------------------------
  289.  
  290. Date:    14 Feb 90 16:49:40 +0000
  291. From:    attcan!ram@uunet.UU.NET (Richard Meesters)
  292. Subject: Re: The AIDS "Trojan" is a Copy Protection System
  293.  
  294. Interesingly enough, much of the previous discussions that I read on
  295. this topic (and posted on, as well) has little to do with the fact
  296. that a demo version of the software can have a self-destruct mechanism
  297. (a time bomb).
  298.  
  299. However, what we are dealing with here is the fact that this program
  300. does not destroy itself, but rather renders all your programs and data
  301. un-usable.  In fact, you have no evidence to back up the fact that
  302. even if I did send in the money for the purchase of the program, that
  303. I would get the fix back.  The fact that the address was an unknown
  304. post-office box in Panama seems to indicate that the whole thing was a
  305. scam.
  306.  
  307. I agree that if the persons receiving this program had read the
  308. notice, they probably wouldn't have installed the program, but don't
  309. confuse that with justifying the actions taken by the program after
  310. installation.
  311.  
  312. The issue here is, in my opinion, twofold.  First, did the auhor of
  313. this trojan commit a fraudulent act.  And can someone who sends you an
  314. un-solicited copy of a program make you pay for the use of the
  315. package.  This was NOT a demo version of the software, from all
  316. indications.
  317.  
  318. Regards,
  319.  
  320. - ------------------------------------------------------------------------------
  321.      Richard A Meesters                |
  322.      Technical Support Specialist      |     Insert std.logo here
  323.      AT&T Canada                       |
  324.                                        |     "Waste is a terrible thing
  325.      ATTMAIL: ....attmail!rmeesters    |      to mind...clean up your act"
  326.      UUCP:  ...att!attcan!ram          |
  327. - ------------------------------------------------------------------------------
  328.  
  329. ------------------------------
  330.  
  331. Date:    15 Feb 90 00:31:53 +0000
  332. From:    kelly@uts.amdahl.com (Kelly Goen)
  333. Subject: Re: Forwarded: Re: *UNCONFIRMED* PC virus
  334.  
  335. rogers@marlin.nosc.mil (Rollo D. Rogers) writes:
  336. >hi, does anyone else have knowledge/experience with this alleged PC
  337. >virus?
  338. >
  339. >[Ed. As with all such reports, I urge people to NOT BELIEVE this
  340. >without some reliable third party confirmation.  We've all seen that
  341. >rumors can be just as time consuming as The Real Thing...]
  342. >
  343. >Forwarded mail follows:
  344. >Date: Tue, 13 Feb 90 14:52:02 -0800
  345. >From: Yong Kim <yjkim@milton.u.washington.edu>
  346. >Subject: Re: virus
  347. >
  348. >...
  349. >this one lives in the setup-memory (CMOS) that was backed up by the
  350. >computer battery.
  351. >...
  352.  
  353. Well sorry this one isnt plausible... infectious code will not be
  354. using CMOS to spread from(standalone...) just isnt enough memory in
  355. there on standard AT architectures...on Micro-channel there is enough
  356. space...  however the data is simply read or written not executed...
  357. (n.b. I have run into programs which through programming mistakes
  358. rendered CMOS data unusable... but not a virus living in
  359. there...caused by poor coding though not a virus or trojan) this one
  360. kind of reminds me of the hilarious(at least to myself and chuck
  361. forsberg) MODEM virus SCARE of 1988(NO IT wasnt and isnt REAL)...
  362.      cheers
  363.      kelly
  364. p.s. on microchannel architectures there is adequate unused space in
  365. cmos adapter ram... but another cooperating process would be needed
  366. to read the cmos for the code and place it into main memory as
  367. code cannot be executed in CMOS RAM Buffers...
  368.  
  369. ------------------------------
  370.  
  371. Date:    Wed, 14 Feb 90 19:26:00 -0500
  372. From:    WHMurray@DOCKMASTER.NCSC.MIL
  373. Subject: Dr. Popp
  374.  
  375. >Ed: ... did he break any U.S. laws?  Will Dr.  Popp be
  376. >tried here or in Britain?  Just a few thoughts...]
  377.  
  378. Dr. Popp was arrested in Willowick, OH on an extradition warrant.  He
  379. is not charged with any crime in the US.  His defense against
  380. extradition is technical, i.e., being treated for mental problem, not
  381. substantive.  [It is a mere coincidence that Dr. Popp and RTM hold
  382. degrees from the same elite institution.  Few inferences would be
  383. justified.]
  384.  
  385. William Hugh Murray, Fellow, Information System Security, Ernst & Young
  386. 2000 National City Center Cleveland, Ohio 44114
  387. 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
  388.  
  389. ------------------------------
  390.  
  391. Date:    Wed, 14 Feb 90 18:49:00 -0500
  392. From:    "Science:Controlled Paranoia" <IAQR100@INDYVAX.BITNET>
  393. Subject: Universal Virus Detector
  394.  
  395. I agree with Russell McFatter's [russ@alliant.Alliant.com] rules in that
  396. they would work.  However, I don't believe it would be successful with
  397. some shareware products, or quick-fixes/patches.  Not that any of us
  398. INTENTIONALY program that way, but at 3 in the morning when a quick
  399. long jump will solve the problem over rewriting an entire 5000 line
  400. module...  And as (it would seem) more people contract viruses through
  401. shareware than anything else, the problem is compounded.
  402.      I am curious as to why everyone seems to stick to a Universal
  403. Virus Detector that 'detects on the fly.'  Wouldn't it be more feasible
  404. for a Universal Virus Detector to act as more of a high-security Operating
  405. System, than a program?
  406. Let me elaborate...
  407.  
  408. Boot up a PC from a clean DOS, then implement this Virus Detection
  409. Operating System (VDOS).  VDOS now clamps down on every interrupt, AND
  410. watches for every redirect interrupt command.  Then you give it a
  411. program to check.  VDOS pseudo-executes the program, checking for
  412. every possible outcome and attempts to write to disk.  Any attempt to
  413. write to an area locked out by you constitutes a virus.  (Or at least
  414. something not kosher...)  Theoreticallly, so long as the VDOS isn't
  415. contaminated, and so long as you don't add a program that hasn't been
  416. checked, you're clean.  The positives for this are 1.  Unhampered
  417. program execution.
  418.  
  419. 2.  More control over Virus checking then 'check on the fly' detection.
  420.   (algorithms can be more complex...)
  421.  
  422. The negatives are
  423. 1.  Time to detect.  I'm figuring this may take awhile for long programs.
  424. It may not even be feasible with large menu driven programs...
  425. (DBase IV, and Lotus 1-2-3, for example) to check every possible outcome
  426. or result...(But if you're willing to wait an hour to backup your
  427. hard drive, maybe its worth it?)
  428.  
  429. 2.  Wouldn't defend against viruses that just replicate themselves, unless
  430. you looked for it specifically.
  431.  
  432. 3.  Of course it's not 100% fool-proof.
  433.  
  434. Overall though, you could have more complex algorithms than a virus-scanner,
  435. plus more control than a memory resident detector (flu-shot).
  436. But then this was all just a thought, anyway.
  437.  
  438. (Oh, once you've finished with the program, you then reboot to Normal DOS,
  439. with the knowledge of whether or not you have an infected disk...)
  440.  
  441. Charles Cafrelli   Bitnet:  IAQR100@INDYVAX
  442. Computer Constultant for the IUPUI English Department
  443. Disclaimer:
  444. "I don't know what they're saying, and they don't know what I'm saying."
  445.  
  446. ------------------------------
  447.  
  448. Date:    Wed, 14 Feb 90 21:37:07 -0700
  449. From:    Ben Goren <AUBXG@ASUACAD.BITNET>
  450. Subject: New virus in Canada??? (Mac)
  451.  
  452. I have heard rumors from people here at Arizona State University that
  453. there is a new Macintosh virus on the loose.  I am currently trying to
  454. trace these rumors, and will let the list know when I hear anything.
  455.  
  456. It is supposed to be intentionally and maliciously destructive, has not
  457. yet made it out of Canada, and "Disinfectant probably won't catch it."
  458. (the person who said that was not an overly experienced Mac user).
  459.  
  460. Let's keep our fingers crossed that this is just a rumor.
  461.  
  462. ........................................................................
  463.  Ben Goren                                               T T T        /
  464.      Trumpet Performance Major                    )------+-+-+--====*0
  465.      Arizona State University                        ( --|-| |---)    
  466.      Internet: AUBXG%ASUACAD@ASUVM.INRE.ASU.EDU        --+-+-+--
  467. ........................................................................
  468.  
  469. ------------------------------
  470.  
  471. Date:    Thu, 15 Feb 90 04:24:18 +0000
  472. From:    SMSgt Michael L. Shamel <email!lgdelta!mshamel@tachost.af.mil>
  473. Subject: UNIX discussions?
  474.  
  475. I have just started monitoring this group and am new to the unix
  476. environment.  Has there been any discussion on viruses trojans or
  477. other nasty things that unix systems are vulnerable to?  I am
  478. particularly interested in how one guards against things sent through
  479. the internet either by regular mail, or some of the UUCP processes.
  480. uux seems like a particularly good candidate for mischief.  If this
  481. subject has come up before, please point me in the direction of the
  482. proper archive.
  483.  
  484.                 Thanks
  485.                 Mike Shamel....
  486.  
  487. ------------------------------
  488.  
  489. Date:    15 Feb 90 01:48:18 +0000
  490. From:    MINICH ROBERT JOHN <minich@a.cs.okstate.edu>
  491. Subject: Re: Many WDEF reports (Mac)
  492.  
  493. CHESS@YKTVMV.BITNET (David.M..Chess) writes:
  494. > Curious as to why we're seeing all these WDEF reports, and not similar
  495. > numbers of reports of other widespread viruses.  Has it just become a
  496. > tradition to report WDEF on VIRUS-L, or is WDEF better at spreading?
  497. > If the latter, does anyone have a good feeling for what about WDEF
  498. > makes it so (um) virulent?  DC
  499.  
  500.   I don't know about the "tradition" part, but WDEF is easily the most
  501. virulent entity on the Mac, and probably any computer. The only way to
  502. make it spread faster would be to have all the Macs connected together
  503. with zero protection of the desktop files. All it takes is one
  504. insertion of an infected disk, and the unprotected machine gets it.
  505. Kind of like what some weird people used to (still do, perhaps?) think
  506. about AIDS (the human kind.) "Touch someone and you get it."
  507.  
  508. Robert Minich
  509. minich@a.cs.okstate.edu
  510. Oklahoma State University
  511.  
  512. ------------------------------
  513.  
  514. Date:    Thu, 15 Feb 90 15:36:24 +0200
  515. From:    Yuval Tal <NYYUVAL@WEIZMANN.BITNET>
  516. Subject: Virus Buster (PC)
  517.  
  518. About a month or so, I've posted a message about beta testers for the
  519. next version of Virus Buster. Well, a few days after posting this
  520. message, a big software house here, in Israel, have asked Uzi, the
  521. second author, and me about whether we agree to sell Virus Buster to
  522. them. After thinking about it, we've decided to agree and sell Virus
  523. Buster to them.
  524.  
  525. Here I would like to thank all the beta-testers who accepted to test
  526. Virus Buster. Thank you guys! But now, of course, it would be improper
  527. to ask them to test it.
  528.  
  529. Another version with bugs correction will probably be released soon,
  530. but I can't promise.
  531.  
  532. Thank you very much,
  533.  
  534.                Yuval Tal
  535.  
  536. +--------------------------------------------------------------------------+
  537. | BitNet:   NYYUVL@WEIZMANN        Domain: NYYUVAL@WEIZMANN.WEIZMANN.AC.IL |
  538. | InterNet: NYYUVAL%WEIZMANN.BITNET@CUNYVM.CUNY.EDU                        |
  539. +----------------------+---------------------------------------------------+
  540. | Yuval Tal            | Voice:   +972-8-474592  (In Israel: 08-474592)    |
  541. | P.O Box 1462         | BBS:     +972-8-421842 * 20:00-7:00 * 2400 * N81  |
  542. | Rehovot, Israel      | FidoNet: 2:403/136                   (CoSysop)    |
  543. +----------------------+---------------------------------------------------+
  544. |  "Always look on the bright side of life" *whistle*  -  Monty Phython    |
  545. +--------------------------------------------------------------------------+
  546.  
  547. ------------------------------
  548.  
  549. End of VIRUS-L Digest
  550. *********************
  551. Downloaded From P-80 International Information Systems 304-744-2253
  552.