VIRUS-L Digest Friday, 10 Nov 1989 Volume 2 : Issue 238 VIRUS-L is a moderated, digested mail forum for discussing computer virus issues; comp.virus is a non-digested Usenet counterpart. Discussions are not limited to any one hardware/software platform - diversity is welcomed. Contributions should be relevant, concise, polite, etc., and sent to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's LEHIIBM1.BITNET for BITNET folks). Information on accessing anti-virus, document, and back-issue archives is distributed periodically on the list. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@SEI.CMU.EDU. - Ken van Wyk Today's Topics: Sophisticated Viruses Re: Sophisticated Viruses 386 Isolation Pam Kanes book and the CVIA Undecidability RE: MacWight dilemma (Mac) Details of Ogre, Dark Avenger, etc. (PC) Another attack?!? (PC) Re: Sophisticated Viruses? Re: Checksum programs; Hardware protection Ping Pong virus (PC) at UIUC Re: virus problem undecidability New IBMPC anti-virals Re: future viruses on a PC Pull plug before cleaning In Search Of Virus Info [Ed. In an effort to send out one digest per day, this digest is longer than usual. If anyone has truncation problems due to its length (~32k), please let me know.] --------------------------------------------------------------------------- Date: Thu, 09 Nov 89 09:59:00 -0500 From: WHMurray@DOCKMASTER.ARPA Subject: Sophisticated Viruses Thanks to Jim Frost for a very thought provoking posting. Here are some that I had while reading it. >Limiting Propagation Rates. Simple viruses, and often not-so-simple >ones, will proliferate without bounds. Rampant proliferation will >cause the virus to be noticed early in its lifetime and will probably >lead to its early demise. The internet worm did not do this. Most PC viruses do not do it either. When the vector is a diskette, it need not. Most of the network worms have not done it; they wanted to be noticed. Therefore, the requirement is a function of both the chosen vector and the motive. >Detecting and Avoiding "Virus-Protected" Hosts. I have yet to see a >virus which looked at the state of a system to detect virus detection >mechanisms to nullify them and/or avoid infecting them. Biological viruses simply ignore potential but immune hosts. If the potential population is sufficiently large, the presence of immune subjects is not important. However, again motive is important. We have not seen any viruses that were determined to conceal their existence, in part because writing a virus that no one notices is not any fun. If no one notices, then it is not possible to know about propagation or survival. What fun is that? >Count our blessings now because you >won't believe how bad tomorrow's nightmares will be unless we start >teaching ethics to tomorrow's programmers! I will settle for simple self interest. ALL computer users have a vested interest in an orderly environment in which programs can be relied upon to do only what they advertise. Virus writers are soiling their own nests. William Hugh Murray, Fellow, Information System Security, Ernst & Young 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 ------------------------------ Date: Thu, 09 Nov 89 10:37:36 -0500 From: Kenneth R. van Wyk Subject: Re: Sophisticated Viruses WHMurray@DOCKMASTER.ARPA writes: >> We have not seen any viruses that were determined to conceal their >> existence... In theory anyway, what proof to we have of their non-existence? If they're determined to conceal themselves, then why would we expect to notice them in the first place? In Cliff Stoll's book, "The Cuckoo's Egg", Dr. Stoll points out that for every forty (approximately) computers that the hacker invaded, only one or two system administrators ever noticed. The connections were relatively overt in that they left behind audit trails ('lastlog' entries), yet very few people noticed. (In my personal opinion, by the way, "The Cuckoo's Egg" should be considered required reading by anyone who runs, or is interested in, computers - *highly* recommended.) >> ...in part because writing a virus that no one notices is not any >> fun. If no one notices, then it is not possible to know about >> propagation or survival. What fun is that? There's an important distinction to be made here - detection during propagation vs. detection after (presumably) successful propagation. A virus could well attempt to conceal its existence while propagating, and then do quite the opposite (!) during a destructive phase. No one would notice until it would be too late. I'm not trying to sound like the voice of gloom and doom, really. I don't believe that the sky is falling. The purpose of this posting isn't to sound sensationalistic - merely to raise some questions. Ken van Wyk ------------------------------ Date: Thu, 09 Nov 89 10:50:00 -0500 From: WHMurray@DOCKMASTER.ARPA Subject: 386 Isolation The isolation hardware in the I386 makes it possible to construct a contained execution environment in which all the effects of execution are contained within the envrionment. Such an environment would be a useful place to test untrusted programs. Has anyone constructed such an environment? William Hugh Murray, Fellow, Information System Security, Ernst & Young 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 ------------------------------ Date: 08 Nov 89 02:38:45 +0000 From: kelly@uts.amdahl.com (Kelly Goen) Subject: Pam Kanes book and the CVIA Hi I am passing this note on for the CVIA... no endorsement is made nor representation implied by Amdahl Corp or Onsite consulting as to the information that follows: I am the Acting Technical Director of the National BBS Society and, though I spend a great deal of time on computer virus related activities, I am not an active participant in any of the virus discussion forums, such as Virus-L. I do keep current with important virus issues and virus-related publications and occasionally come across something that requires comment. Pam Kane's book "V.I.R.U.S. - Vital Information Resources Under Siege" from Bantam Books is one such thing. Aside from the many technical inaccuracies and misleading product information contained in the book, Pam Kane's portrayal of the National BBS Society, the Computer Virus Industry Association and John McAfee's involvement in each is highly charged and grossly fallacious. Her assertion, for example, that Mr. McAfee 'owns' the National Bulletin Board Society and controls its virus-related activities is absurd to the point of comedy. The claim that the donation of a five-line bulletin board, months of unpaid time, and the responsibilities of coordination for a loose-knit and highly independent group of 2,000 SysOps is "ownership" cannot be taken seriously. Her entire discussion of the National Bulletin Board Society shows a blatant disregard for the facts and an alarming lack of understanding of the dynamics of virus research. More amazing, though, is her recollection of the events surrounding the formation of the Computer Virus Industry Association, an event that I witnessed first hand. Ms. Kane would have us believe that Mr. McAfee was strongly interested in having herself and other small antiviral product vendors as members and went out of his way to try and force membership on these companies. My own recollection was that Mr. McAfee extended these invitations out of politeness. It is hard to imagine why an organization that includes Microsoft, Lotus, Novell, Boeing Computer Services, Amdahl, Locus, Fujitsu, Ford Aerospace, Martin Marietta and 35 other such companies would be so interested in having Panda Systems as a member. I asked for and received permission from Mr. McAfee to include part of a May 2, 1988 letter from Mr. McAfee to Kate Drew-Wilkerson describing his intent to form the CVIA. I hope this puts his intent in proper perspective: "May 2, 1988 "Kate, " It is clear, at least to me, that computer viruses will not go away of their own accord. On the contrary, they must, based on all known laws of statistics, increase in prevalence. What we see today is merely a shadow of the problems we will face in the future. The number of individual strains will increase at some linear rate, and the incidences of infection will increase geometrically. This much is clear. The time frame is the only unknown. " Accordingly, I feel that the most urgent need is to organize. A consortium of hardware and software developers focused on the unique problems posed by an impending rash of infections is Priority One. For this to work, we mustobviously have the corporate computer industry leaders involved. How to do so at this juncture is the problem. The companies that shape the computer markets and policies have not yet been directly impacted, and by and large they dismiss the issue. In time this will change. For now, however, I will content myself with the three or four security firms who have branched out into the computer virus marketplace and with whom I have established a rapport. We can jointly form the foundations for the later entry of the industry giants. " From a sense of responsibility, and to embark with the necessary open forum required for success, I will extend an invitation to all parties that are known to me to be active in the virus field. It is doubtful, however, given the existing antagonism between the various vendors, that I shall have much success at achieving a quorum. In truth, I am counting on the probability that those vendors who would prove embarrassing as members will, for obvious reasons, decline participation. ... " /s/John McAfee" I would like to thank the moderator of this virus forum for providing a means of voicing my viewpoints in what I feel is an important computer virus area. Aryeh Goretsky, Acting Technical Director National BBS Society 1429 Dry Creek Road San Jose, CA 95125-4617 408 265 8499 Kelly Goen/ Cybernetic Systems Specialists Inc. Disclaimer: neither Amdahl Corp nor Onsite consulting offer any representation warranty or guarentees as to the accuracy of the information in this e-mail. ------------------------------ Date: Thu, 09 Nov 89 12:52:00 -0500 From: "Joseph M. Beckman" Subject: Undecidability The hypothesis of viral detection is that it is an undecidable task to determine whether an arbitrary program on an arbitrary "machine" contains a virus or not. This does not mean the viral detection question is undecidable. First, one is primarily interested in a subclass of the question. This subclass is a Type II error, or false acceptance (saying a program is virus free when it is not). Crocker & Pozzo have argued that it is feasible to create a filter which has a Type II error rate of 0. Naturally, some programs without viruses are rejected by a filter of this type. See their paper in the 1989 IEEE Security & Privacy Conference Proceedings. Second, neither programs nor machines are arbitrary in the real world. One can certainly think of machines (and then of programs running on those machines) where it can be trivially and without error shown whether a particular program is infected with a virus or not. All of this assumes that one has a definition of "virus." Joseph ------------------------------ Date: Thu, 09 Nov 89 12:49:00 -0500 From: Subject: RE: MacWight dilemma (Mac) Possible (though unlikely) solution to the MacWight (MacWrit, or whatever) Virus: Anyone out ther familiar with Timbukto? That nice little DA that allows one user on a net to actually attach his mac to another running on the same net. Even take over the other mac if the other person does not know what is happening. That way it is possible to have something change right before your eyes if you are on a net, running Timbukto and have someone else (who is probably in hysterics) running Tim on another mac on the net. Try capturing someone's mac when he's netTrek and just have fun with the poor boy. it's possible... Alex Z... . . . ------------------------------ Date: Sun, 05 Nov 89 15:01:02 +0000 From: Alan Solomon Subject: Details of Ogre, Dark Avenger, etc. (PC) There has been a number of people recently calling for information about some of the newer viruses, like Ogre, and Dark Avenger. What follows are excerpts from the manual of a commercial product; it's OK for me to post this, as I wrote it and have the copyright! I shan't mention the name of the product, but I must apologise that the pages of the manual do refer to various components of the product. Where it refers to Findvirus, please take this as meaning any virus scanning program that knows about the virus in question; when it refers to Peeka, please take this as meaning any disk sector editor. The paragraph numbers are the chapter numbers in the manual. I've taken the liberty of calling Ross Greenberg's discovery Fumble instead of Typo, as there is already a Typo in the literature, and we don't want two viruses with the same name. Sorry, Ross. If anyone finds any errors or significant omissions in these descriptions, please respond via email or fax to me directly. Finally, could I please lay one myth to rest. Datacrime (called Columbus day in the US) does the low level format on October 13th and every day thereafter until December 31st. It does this in versions 1168, 1280 (infective lengths) and Datacrime II. It does NOT do anything on October 12th, and Datacrime II does NOT go off on Jan 1 to Oct 12th. Datacrime II refrains from the format on Mondays. The whole October 12th thing was caused by a misunderstanding about dates, picked up by the media and turned into a factoid. The other important thing about Datacrime, is that it is extremely uncommon indeed. We have had no (zero, nil) cases in the UK, and I know of only two cases in Holland. Does anyone know of any *confirmed*, definite, sightings? Apart from Fridrik's self inflicted accident, of course :-) Dr Alan Solomon Day voice: +44 494 791900 S&S Anti Virus Group Eve voice: +44 494 724201 Water Meadow Fax: +44 494 791602 Germain Street, BBS: +44 494 724946 Chesham, Fido node: 254/29 Bucks, HP5 1LP Usenet: drsolly@ibmpcug.co.uk England Gold: 83:JNL246 CIX, CONNECT drsolly [Ed. Because of the length of the excerpts, I've sent them to the comp.virus documentation archive sites. Access information will be posted shortly.] ------------------------------ Date: Thu, 09 Nov 89 13:51:40 -0600 From: CA6692@SIUCVMB.BITNET (Vince Laurent - work id) Subject: Another attack?!? (PC) We have encountered something that appears to be a virus of some sort. The symptoms are : 1. When an EXE file is run that is 'infected' the screen gets lines and garbage that looks like 'snow' (TV term there...) 2. After a few runs it changes the file length to 0. 3. When the disk is checked using some utilites there are numerous 'bad sectors' scattered on the disk. Side Note: The color of the 'snow' is the same as the last application that ran (ie when Norton Editor is run with a green screen - there is green snow, white screen editing makes white snow, etc...) I have not been able to 'capture' this virus to get a look at the code. I know of 3 cases so far, some of my coworkers have run across it too. Any ideas on what it might be? --------------------------------------------- | Vincent J. Laurent | | Help Desk | | Computing Affairs | | Southern Illinois University - Carbondale | | CA6692@SIUCVMB | --------------------------------------------- p.s. please! no comments about yellow snow... ------------------------------ Date: Thu, 09 Nov 89 15:17:25 -0400 From: "Joel B. Levin" Subject: Re: Sophisticated Viruses? >I don't agree with you on any of these points, Terry. Say, on the >Macintosh all calls to ROM are done through trap vectors in RAM. These >trap vectors are patched by the system file (to fix bugs), by some >programs and by all anti-virus tools. However, it doesn't take a >genius to figure out that one could restore the trap vector to it's >original value and thereby bypassing the "safe" system. . . . > . . . A patch like this wouldn't occupy much space and is quite >simple to write. Except that when system patches or INIT patches or program patches to the traps were removed by the virus (and how would the virus decide what value to restore them to?--this is different for each ROM and system release version) the user would certainly be likely to notice the resultant changed program behavior -- or system crashes. /JBL ------------------------------ Date: Thu, 09 Nov 89 14:51:40 +0200 From: Y. Radai Subject: Re: Checksum programs; Hardware protection Concerning checksum programs, Paul Kerchen writes: > where does one store these checksums and their keys? If >they are stored on disk, they are vulnerable to attack just like >programs. That is, a virus could infect the program and then update >its checksum, since the key must be somewhere on disk as well (unless >the user enters it every time they compute a checksum--yecch!) and one >must assume that the checksum algorithm is known. Or, >more simply, a virus could simply wipe out all the checksums, >leaving the user to decide which files were infected. Storing the >'sums off line would insure security, but at what cost? Checking >and updating the 'sums with any frequency would become tedious at best. First, let's rule out the possibility of wiping out the checksums. To be successful, a viral attack (as opposed to a Trojan Horse attack) must not be obvious. Such an action would immediately be noticed. That leaves us with the more subtle action of altering checksums. Now there are two types of CSPs (checksum programs), sometimes called "dynamic" and "static", and most of Paul's remarks seem to be based on the assumption that we are using the dynamic type. Dynamic CSPs are resident programs which checksum each program which is execu- ted just before its execution. A well-known example is the checksum feature of FluShot+. Static CSPs are non-resident programs which checksum a list of many files on demand, usually at boot time by vir- tue of being placed in the AUTOEXEC.BAT file. An example is Sentry. Now the dangers described above by Paul are no problem for static- type CSPs. In this case one can keep the CSP, along with the CSB (checksum base) and key (generating polynomial in the case of a CRC), on a write-protected, non-infected bootable diskette, and execute the CSP from that diskette after cold-booting from it. Since the CSP is static, this need be done only once per boot, and the additional in- convenience relative to doing this from the hard disk will be very slight. (In fact, there are even utilities which allow you to specify that the program is to be executed only once a day, once a week, etc. even though the command is in AUTOEXEC.BAT.) But suppose one wants to execute the program from the hard disk any- way. We can still foil the checksum forger by simply requiring the user to supply the key interactively. "Yecch!", says Paul, but he is probably thinking of dynamic checksumming. Again, if one uses static checksumming, the key need be supplied only once per boot at the most. Now let's suppose we're using a dynamic-type CSP and prefer the con- venience of doing everything from the hard disk. Would this really make the checksum and keys vulnerable, as Paul claims? Even if it's true that *theoretically* a virus could find the CSB and key and then alter the former, in practice that seems to me rather unlikely for a variety of reasons: First, if the CSB is stored under a name that is not fixed, how would the virus find it? If it does it by searching all files on the hard disk looking for a certain type of content, then infecting some file and computing its new checksum from the key which it has discovered and updating the CSB, that would take a lot of time. One must remember that any modification in a program which causes it to take much more time than usual is likely to be noticed by the user, causing him to suspect a virus. Secondly, forging checksums would make a lot more sense if there were a single CSP which was used by a majority of the users of a given type of computer. But what good does it do to write a program to forge checksums used by a particular type of CSP when it is use- less on the overwhelming majority of computers? Unless the virus creator is satisfied with attacking a very limited environment, such as a student lab, in which all computers use the same CSP, checksum forging hardly seems worthwhile. This is not to say that there are no dangers to CSPs. But checksum forging is not the main one. On most systems there are CSP-fooling techniques which are not only much faster and independent of the par- ticular CSP, but also easier to write. To give a PC example, suppose the hard disk and RAM are infected by a boot-sector virus which hooks Int 13h in such a way that any attempt to read the boot sector results in reading the sector in which the virus has stored the original boot sector (i.e. it works like the Brain virus except that it infects the hard disk also). If the com- puter is booted from the hard disk, the CSP will be activated only after the virus has installed itself in RAM, hence checksumming the boot sector will not reveal that the boot sector has been modified. This particular trick can be overcome by booting from a clean disk- ette before activating the CSP. But on the PC, at least, there are several other ways of fooling a naively designed CSP which cannot be overcome in this way. Chuck Kichler says things similar to what Paul says above, except that he suggests looking in the program (the CSP) instead of in the CSB. The answers are similar. However, he also suggests using a hardware device. This is not a new idea, and there is at least one commercial implementation of this for PCs, called Disk Defender, con- sisting of a card placed between the disk drive and the controller. It comes with software for dividing the hard disk into two logical drives, one of which is left unprotected for necessary writing, while the other is completely write protected, except when it is necessary to transfer files to it. I agree that this is one of the best types of anti-viral protection. But even if we ignore the tedious installa- tion required (if the disk is not initially empty) and the relatively high price ($240, last I heard), one should not assume that it neces- sarily provides absolute protection; it may still be possible for a virus to infect the normally protected drive during those periods when the protection is removed in order to transfer new files to it. Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI1@HBUNOS.BITNET ------------------------------ Date: Thu, 09 Nov 89 14:56:05 -0500 From: "Mark S. Zinzow" Subject: Ping Pong virus (PC) at UIUC This is a slightly edited copy of our local warning. Today (Thursday, November 9, 1989) the Ping Pong B virus was found on an XT in Newmark hall here at the University of Illinois at Urbana-Champaign. This is the third virus to infect IBM PC's here. The previous PC viruses were Brain and Jerusalem. This virus is a boot sector infector and also goes by the names Bouncing Ball, Italian, VERA CRUZ, and VERA CRUZ B. Please use scanv48.arc (anonymous ftp'able from uxe.cso.uiuc.edu in the directory pc/virus) to search systems for infection, and unvir6.arc (from the same place) to remove the virus from infected systems. VIRUSCAN, the name for the package of programs in scanv48.arc, is a shareware product. Just this week CSO has purchased a site license for the U. of I. so you may ignore the request for a $25 registration if you are using this software here. SCAN.EXE (in scanv48.arc) will report two versions of Ping Pong when it is found. This is a bug, the B version also triggers the message for the non-B version. So far, we think we only have one version of this virus floating around. The program IMMUNE by Yuval Ratavy in unvir6.arc will make your system immune to the Ping Pong, Jerusalem, and several other viruses. Please call me (244-1289 or email markz@vmd.cso.uiuc.edu) if you find a copy of PING PONG as I'm trying to figure out the extent and locations where this virus has spread. In the local versions of this announcement, excerpts from the following VIRUS-L Digests were included: VIRUS-L Digest Wednesday, 18 Jan 1989 Volume 2 : Issue 18 Subject: Re: The Ping-Pong virus (PC) VIRUS-L Digest Thursday, 9 Mar 1989 Volume 2 : Issue 61 Subject: Re: Bouncing ball virus (PC) VIRUS-L Digest Friday, 10 Mar 1989 Volume 2 : Issue 62 Subject: bouncing ball virus (PC) VIRUS-L Digest Wednesday, 10 May 1989 Volume 2 : Issue 112 Subject: Yet more on SYS (PC) VIRUS-L Digest Friday, 12 May 1989 Volume 2 : Issue 114 Subject : 1 byte can save us from the Ping Pong virus (PC) - -------Electronic Mail---------------U.S. Mail--- ARPA: markz@vmd.cso.uiuc.edu Mark S. Zinzow, Research Programmer BITNET: MARKZ@UIUCVMD.BITNET University of Illinois at Urbana-Champaign CSNET: markz%uiucvmd@uiuc.csnet Computing Services Office "Oh drat these computers, they are 150 Digital Computer Laboratory so naughty and complex I could 1304 West Springfield Ave. just pinch them!" Marvin Martian Urbana, IL 61801-2987 USENET/uucp: {uunet,convex,att}!uiucuxc!uiucuxe!zinzow Phone: (217) 244-1289 Office: CSOB 110 \markz%uiucvmd ------------------------------ Date: 09 Nov 89 23:09:50 +0000 From: kerchen@iris.ucdavis.edu (Paul Kerchen) Subject: Re: virus problem undecidability OSPWD@EMUVM1.BITNET (Peter W. Day) writes: >A note to the virus-l digest of 6-Nov-89 said that "the virus problem (at >least detection anyway) is undecidable." Does anyone know if there are >any papers where this result is proved? Or where the problem is >shown to not be NP complete? Or even where the problem is stated >precisely? (Sorry about the mail loop, Peter) I base my arguments upon Fred Cohen's paper "Computer Viruses: Theory and Experiments," which can be found in _Computer Security: A Global Challenge_ ( a collection of security-related papers). In this paper, Cohen talks about the undecidability of detecting viruses in a program and proves why this is the case (although, purists wouldn't call it a proof). Paul Kerchen | kerchen@iris.ucdavis.edu [Ed. The cited Cohen paper was also published in the _Computers and Security_ journal (though I don't have an issue number), as well as directly from Dr. Cohen.] ------------------------------ Date: Thu, 09 Nov 89 20:46:04 -0600 From: jwright@atanasoff.cs.iastate.edu (Jim Wright) Subject: New IBMPC anti-virals More anti-virals. It's getting hard to keep up these days... :-) In brief: alert14g.zip Checks files for changes, use in AUTOEXEC ckot094.zip *** Serious bugs, do not use *** datacure.arc Removes DataCrime virus and prevents damage m-dav.zip Removes Dark Avenger virus netscan.zip Network compatible program to scan for viruses scanrs48.arc Resident program to scan for viruses scanv48.arc Scans files, directories, drives for viruses validat3.zip Use this to check downloads for integrity alert14g.zip Update to the alert13u program in the archives. Add to your AUTOEXEC and it will check the files you specify to make sure they have not changed. Free to government, shareware otherwise. ckot094.zip CHECKOUT, a shell program to simplify use of scanv when scanning multiple archives. Shareware. WARNING!!!! This program has a tendency to delete any file it can find. This is a rather nasty bug. I would recommend you not use any version of this program until an update is released and independently tested. It should already be removed from the anti-viral archives. datacure.arc A working version of the DataCure program to replace the apparently mangled version I got earlier. Includes a program to cure infected files and a program to prevent the DataCrime virus from zapping your disk. Shareware. m-dav.zip A program to remove the Dark Avenger virus. Shareware. netscan.zip Network compatible program to scan disks for viruses. An update to the previous archive of the same name. This program is not quite shareware, in that a site license is required for continued use rather than a simple registration. scanrs48.arc Resident program to scan programs for viruses before execution. Update replaces previous version. Shareware. Includes the VALIDATE program. scanv48.arc Program to scan files, directories and drives for viruses. Update replaces previous version. Shareware. Includes the VALIDATE program. validat3.zip Checksum program to use for validating downloads. Run this on a file, note the numbers it gives, and compare this with the numbers provided by a trusted source. What is a trusted source? That is being worked out. :-) Jim ------------------------------ Date: 10 Nov 89 07:38:05 +0000 From: kelly@uts.amdahl.com (Kelly Goen) Subject: Re: future viruses on a PC Pull plug before cleaning Sorry again turning off power will stop the current execution of the virus... but... unless you are perfect in your safe computing habits and your tools are up to snuff and you give your harddisk an engineering prep as you power up and ALL your software is clean.. you can still be hit upon power up... following post you invok int19 to read the boot tracks in loc 7c00 it is at this point you are first vunerable...and not under control of ANY antiviral tool I have heard about...(VIRUS_PROOF pc designs not withstanding... even cd-rom has been infected during the production of shareware libaraies...) but you wont incurr damage to your data while power is off but neither can you get to it either...I am not saying the problem is unsolvable nor hard to deal with just realize the power off switch is no REAL protection some time or another you will eventually power up... cheers kelly ------------------------------ Date: 10 Nov 89 07:53:56 +0000 From: wugate!smu.edu!mazanec@uunet.UU.NET (Bob Mazanec) Subject: In Search Of Virus Info I am trying to find any and all information available on computer (UNIX & others) viruses for a report in an ethics class (gee, i bet this stuff might even be useful to me in running my little VAX, huh?). Please E-MAIL me any information you might have (or even just references to magazines/books that might have same) on known viruses what/where/when/how/etc. psychology of virus writers immunology what can/has been done bug exploitation/fixing etc. MANY Thanks in advance!! Robert L. Mazanec @ Southern Methodist University {attctc, convex, texsun}!smu!mazanec == mazanec@smu.edu DISCLAIMER: You think they TAUGHT me this stuff?? ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253