========================================================================= Date: Wed, 8 Jun 88 08:54:23 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Digest or not digest - the decision With about 50 votes in (out of about 380 people on the VIRUS-L list), I've decided what to do about the digest/moderate "problem". First, though, I want to thank everyone who sent me their vote! All of your suggestions were great, and I hope that my decision will accomodate as many of you as possible! The decision: The list will remain unmoderated and undigested. *BUT*, I now have the back logs set to be stored on a weekly basis (as opposed to a monthly basis). So, those of you who prefer digest format can pick up a weekly VIRUS-L "digest" from the LISTSERV, and unsubscribe from the list itself. The weekly log filenames are of the form: VIRUS-L LOGyymmx (where yy is 88 for 1988, etc., mm is month, and x corresponds to the week - A for week 1, etc.). So, the first log file in June, 1988 would be VIRUS-L LOG8806A. So, once a week (or whenever), anyone who wants the digest can just send a GET VIRUS-L LOGyymmx #ovmand to LISTSERV@LEHIIBM1.BITNET. If you want to submit something to the list, you'll have to send them to me, and I'll forward them to the list (since only registered subscribers can submit articles). I hope that this decision will be satisfactory to as many of you as is possible. My reasoning behind the decision (as is evidenced by the responses that I got) is that the current volume of traffic is still low enough to keep non-digest believers happy, and that moderating (censoring) is best left to the discretion of the readers. This is what the majority of responses requested - the overall vote count was 36 to 15. In addition, I'd like to briefly (if that's still possible :-) point out a rule of netiquette that I'd like to see followed a bit more closely here on VIRUS-L. Please send responses to queries directly to the author of the query - not to the entire list. That way, the author can send in a summary of his/her responses to the list, and it *should* keep redundant traffic to a minimum. This isn't an attempt to discourage discussions, it's merely an attempt to keep the quality of VIRUS-L mail to a maximum. Thank you for your time. Comments and suggestions, as always, are welcomed - send them to me directly at LUKEN@LEHIIBM1.BITNET. Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = This page intentionally = = Lehigh University Computing Center = left blank. = = Internet: = = = BITNET: = = ------------------------------------------------------------------------ ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = This page intentionally = = Lehigh University Computing Center = left blank. = = Internet: = = = BITNET: = = ------------------------------------------------------------------------ ========================================================================= Date: Tue, 7 Jun 88 17:32:39 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Mark W. Eichin" Subject: Re: Virus 101 In-Reply-To: Kelly Kreiger's message of Mon, 6 Jun 88 13:56:00 EDT <8806070318.AA14246@ATHENA.MIT.EDU> Would it not be appropriate for someone teaching a virus class to simply use the classic technique of "pseudo-machine" code? It requires more preparation on the part of the professor, but if he simply created some "virtual machine" which only existed as a sub-program or simulation somewhere, the virii could only infect this pseudo-machine. This would be far superior to testing it on, say, MSDOS/IBM-PC where the substrate exists in many places; without the appropriate pseudo-machine to infect, the virus would die, or at least fail to propagate. There are medical analogues to this technique, specifically working with E. coli (bacteria, not virus) which is harmless to humans. So, does anyone know of existing pseudo-machines which are available off the shelf, which could be used for this purpose? The MARS (core-wars) system comes to mind, though it is perhaps too simple... Mark Eichin SIPB Member & Project Athena ``Watchmaker'' ========================================================================= Date: Wed, 8 Jun 88 11:19:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Stan Horwitz Subject: Re: Virus *opinion* from the Usenet In-Reply-To: Your message of Tue 7 Jun 88 11:44:25 EDT Even though John Applegate's contention that computer spread virii and other similar types of computer maladies do not exist, I can understand how he arrived at that conclusion. In my case I have never seen anything virii but the subject is of great interest to me. I am a bit of a hacker, but a very kind one and cannot understand why someone would knowingly spread a computer illness around. It makes no sense. Here at Temple, to the best of my knowledge, I have not heard of any virii invasions. Our students do not have use of hard disk based machines and most are not aware of the capability of using BITNET. But even though I have never seen the destruction a computer virus might do, I would have to be very ignorant to say that none exist. I have never seen a person with lung cancer from smoking legal and illegal substances but that certainly doesn't mean that lung cancer does not exist. ========================================================================= Date: Tue, 7 Jun 88 19:38:01 GMT Reply-To: Malcolm Ray Sender: Virus Discussion List Comments: Warning -- original Sender: tag was malcolm@JVAX.CLP.AC.UK From: MALCOLM@JVAX.CLP.AC.UK Subject: Virus-writing classes Although there is disagreement about the ethics of teaching students about virus writing, so far everyone (at least, everyone whose submission I've seen) seems to feel that it's good programming tuition. Well yes, in some ways it is, but surely the question *should* be whether the same gains could be provided in less damaging ways. Let's look at what it is about a virus which makes writing one good training: 1. It needs to interact with the system at a low level, teaching the student a lot about the particular system and about low-level programming in general (someone who's successfully written a typical virus on a PC, for example, will have a good understanding of interrupts and disk structure); 2. It needs to be small if it is to remain undetected, so the student will gain experience in writing compact code; 3. It *may* need to be pretty fast (for example, if it's doing a fair amount of work during a frame sync), teaching the student how to hone code for speed; 4. It should remain undetected as long as possible, even if the victim is looking for it, so the student learns to think carefully about how the 'user' (can one talk about the 'user' of a virus?) will behave. There are probably other points, but these will do. Note that this is *not* a list of the salient points of a virus - I've not mentioned self-replication, for example, because (correct me if I'm wrong) the skill of writing self- replicating code is not exactly of general utility (though I'll admit I can't see into the future). Well, I think it's pretty obvious that there are *benign* programming projects which will teach all of these skills. How about device drivers, for example? (I'm a Mess-DOS novice, so I'm not sure quite how what I mean by a 'device driver' relates to the PC world, but I guess you know what I mean). What I'm *not* saying is that the professor shouldn't have taught those classes, period. Academic freedom is a very important principle and should not be lightly surrendered. What I'm saying is that if he'd taken the trouble to look I'm sure he'd have found a much safer way of imparting the skills he rightly regarded as important. I hope he grows up soon. Regards, Malcolm ------------------------------------------------------------------------ Malcolm Ray JANET: malcolm@uk.ac.clp.jvax Senior Systems Officer BitNet: malcolm@jvax.clp.ac.uk City of London Polytechnic No other routes please! How is it that little children are so intelligent and men so stupid? It must be education that does it. -- Alexandre Dumas Fils ========================================================================= Date: Wed, 8 Jun 88 11:20:15 mdt Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: Warning -- original Sender: tag was From: Bill Kinnersley Subject: Re: Virus 101 In other words, for educational purposes, have your class write viruses that only infect, say, the Apple III. With nearest hosts 50 miles apart, the chance of contagion is small. This sounds like a good argument for INcompatibility among computer systems. --Bill Kinnersley iphwk@mtsunix1 ========================================================================= Date: Wed, 8 Jun 88 13:08:42 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: Pseudo-machines and existence. I curious - what would a pseudo-machine virus do to indicate its virusness? I've seen compilers written to produce code on pseudo- machines. The code gets interpreted by the pseudo-machine later. What does pseudo-machine virus code do? A good virus would have to be self-replicating. If the pseudo-machine provides disk I/O, there's no technique I know of that the pseudo-machine could use to prevent virus spread. If the virus is to be a good example, it must infect something. Perhaps it infects other pseudo-code? Students are still perfectly free to have it infect regular machine-code, or possibly the pseudo-code interpreter. While infections of pseudo- code must be done with pseudo-code, infections of normal machine-code will be just as virulent as ever, since they'll require machine-code. I never heard the guy say viruses don't exist. It sounded to me like he said: > Not one of these experts had ever found a bonified virus and only one > could claim to have found a trojan! The general consensus was that > while viruses might exist their occurance was far more rare than the > media hype would indicate! This is an expression of a consensus of opinion that specifically states that viruses may exist. I've never seen a virus myself. I've heard of two: a MS-DOS virus that infects COMMAND.COM, and a Unix virus in the AT&T C compiler that prints a happy birthday message for the author every year. - Jeff Ogata ========================================================================= Date: Wed, 8 Jun 88 14:30:09 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe McMahon Subject: Re: Virus *opinion* from the Usenet In-Reply-To: Message of Tue, 7 Jun 88 11:44:25 EDT from > >I for one publically doubt the existance of the virus they claim to have >discovered since SEX.EXE can be found on several BBS's in a harmless, >though tasteless form! When confronted on the phone their rep still refused >to participate in our discussion or to produce this virus in order to >confirm it was anything other than a marketing ploy. > Could be. I can't see why the company in question would be uninterested in addressing a group of potential cutomers. >The panel consisted of several sysops, a security expert from Storage Tek, >a computer crime lawyer and a law professor. > Well, scratch the last 3. Viruses are tough to get in to a well-guarded IBM mainframe system. And why should a lawyer or a law professor ever have seen a virus unless he or she is an avid user of PD software? > ... claim to have found a trojan! The general consensus was that while >viruses might exist their occurance was far more rare than the media >hype would indicate! > I agree. But I would substitute "do exist". >It was also agreed that much of this hype is a result of advertizing from >companies claiming to have a solution to viruses... it was even proposed >that some of these viruses might originate with such companies. > Well, I don't know about this claim. From my experience on the Mac, only real people who have had real problems have been writing programs to get rid of viruses. I don't think people who are distributing software for free are profiting all that much from a virus plague, imaginary or real. ========================================================================= Date: Wed, 8 Jun 88 14:48:21 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe McMahon Subject: Virus Simulation Mark Eichin, thank you. That removes the last problem I had with teaching how to write viruses. Write all of the viruses you want. They won't screw up anybody's system. --- Joe M. ========================================================================= Date: Wed, 8 Jun 88 16:19:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: ACS045@GMUVAX Subject: Virus 101 class... My general feeling about this is that the idea was good, but it was the execution that was flawed. Some sort of "confined" pseudo-environment would have been more appropriate for viral development, if the project itself was apprpriate in the first place. Which I think it was. Mind you I say the *IDEA*, not the actual way it was executed(trying to avoid the FLAMES of hellfire--not to mention those of the net). What it comes down to is basically something that society has gone over and over in countless other fields. How do you teach somebody how to make a strain of wheat grow 50% larger than normal?---teach them genetic engineering...How do we keep the country safe from others nuking it?--educate people on how to assemble missiles for ourselves... How can you teach people to defuse a bomb?--try starting with what makes on tick Of course there's nothing to prevent prevent anybody from taking any of this sort of knowledge and perverting it into something destructive(making their own virus, building their own a-bomb,etc.) save for numerous preliminary tests, security clearances, and basically trusting them(which is what is ULTIMATELY comes down to), which really isn't worth that much in hand.... You can either lock up the information and hide it away on the grounds that its too dangerous and destructive for anyone to know,(which doesn't stop those out there who know already), or you can give it to people who(hopefully) you can trust will put it to appropriate use. There really isn't any other option... As to whoever said that Virii don't exist Trust me, they do, I've seen them and lost numerous files and floppies to the peksy buggers...We got majorly "(c)BRAIN"ed this past semester here at George Mason, and it wasn't funny... However, I must admit that I have only seen 2 strains so far..the "Brain" virus and the PLAYBOY virus, both of which only affect PCs.... They certainly aren't as big a threat as the media would like them to be, but they are out there.... ========================================================================= Date: Wed, 8 Jun 88 17:46:54 CST Reply-To: Virus Discussion List Sender: Virus Discussion List From: David Camp Subject: Re: Virus *opinion* from the Usenet In-Reply-To: Message of Wed, 8 Jun 88 11:19:00 EDT from > Even though John Applegate's contention that computer spread virii and >other similar types of computer maladies do not exist, I can understand how >he arrived at that conclusion. Even before the advent of VIRUS-L, the lists occasionally flurried with reports of viruses and trojans as they were discovered. The obvious practice is to notify the archive servers, so that the infection can be nipped-in-the-bud. Perhaps it has been this practice of voluntary cooperation that has prevented any major epidemics from occurring, and a consequent low observation rate. -David- > > In my case I have never seen anything virii but the subject is of great >interest to me. I am a bit of a hacker, but a very kind one and cannot >understand why someone would knowingly spread a computer illness around. >It makes no sense. Here at Temple, to the best of my knowledge, I have not >heard of any virii invasions. Our students do not have use of hard disk >based machines and most are not aware of the capability of using BITNET. >But even though I have never seen the destruction a computer virus might do, >I would have to be very ignorant to say that none exist. I have never seen >a person with lung cancer from smoking legal and illegal substances but that >certainly doesn't mean that lung cancer does not exist. *----------------------------------------------------------------------* | (314) 362-3635 Mr. David J. Camp | | ^ Division of Biostatistics, Box 8067 | | Room 1108D < * > Washington University Medical School | | 706 South Euclid v 660 South Euclid | | Saint Louis, MO 63110 | | Bitnet: C04661DC@WUVMD.BITNET | | Internet: C04661DC%WUVMD.BITNET@CUNYVM.CUNY.EDU | | or: david@wubios.wustl.edu | *----------------------------------------------------------------------* ========================================================================= Date: Thu, 9 Jun 88 07:20:21 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Scott Guthery Subject: Universal Viral Simulator Reprinted without permission from June 1988 IEEE Computer, p.100: "System simulates viral attacks on PCs "The National Bulletin Board Society has developed a computer virus testing system to simulate viral attacks on IBM PCs. The benign pseudo-virus, called Universal Viral Simulator, reportedly uses all known techniques found in live viruses to infect and replicate in host systems. It is based on analyses of live viruses submitted to the BBS Society. "According to the society, the simulator is meant to act as a testing and verification mechanism for antiviral systems under development. The viral simulator is executed after any antiviral systems have been loaded and activated. Each time the antiviral system blocks it, it displays a message naming the replication attempt technique and its failure. If the simulator succeeds in `infecting' the system, it identifies the procedure used. "The Universal Viral Simulator is available from the National BBS Society for $79.95." Anybody know how to contact these folks? ========================================================================= Date: Thu, 9 Jun 88 09:44:38 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: forwarded request for virus program information The following is a forwarded message which was sent to me: I am a student at Miami University currently on an internship with Ernst & Whinney's National Computer Audit Group. I am currently researching computer viruses, trojan horses, and the like. The report which I plan to prepare will include descriptions of various public domain and commercial software which claim to protect from or detect viruses. Some examples of software I am evaluating are: DataPhysician, Triad line, Protec, VI-RAID (commercial), Flushot+, Novirus, Checkup, and CRCDOS (public domain). If anyone is currently using any of these programs, or others like them, I would greatly appreciate your sending me information describing how they are implemented, access controls you have in place, and anything else which you think will be of help. I will be happy to describe the results of my research in this list. . Thanks. Neil Goldman (NG44SPEL at MIAMIU.BITNET) Kenneth R. van Wyk User Services Senior Consultant Steve Dallas: Who's driving?! Lehigh University Computing Center Opus: Oh keep your pants on, Internet: I pressed cruise control. BITNET: ========================================================================= Date: Thu, 9 Jun 88 09:47:57 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: forwarded comments on MAC hard disk locking The following is a forwarded message from abr1@cunixc.cc.columbia.edu: Subject: Protecting your hard disks... don't be misled! Recently, GREENY (MISS026@ECNCDC) wrote: >> hold down the Shift, Option, Command, and Delete keys to boot from a >> floppy....Does this actually prevent the hard drive from working?.... > >Well, that's what it is *supposed* to do for ya. But who knows with Apple? >At any rate, to avoid all of the mangled, popped out of joint fingers >that some people who aren't too limber may get from the above sequence, >just insert a trusted floppy disk into the floppy disk drive with a trusted >system and then open the System folder on it. Hold down the COMMAND and >the OPTION keys while double clicking on the icon of the Finder. This >will force the mac to make use of the system on the floppy drive. After >your finder comes back to life, close the folders, and drag the icon of the >hard drive into the trash can. This will unmount the sucker, thereby >preventing any read/writing from/to it. Wrong... depending on the driver (and possibly other things?) your hard disk will probably auto-remount itself in a matter of seconds. It may take a while if the CPU gets very busy, which could fool you into thinking that you're safe. Anyway, while I've never had occasion to use it, the S-O-C-Del combo is safer. It may in fact make it impossible for ANY software to put your SCSI drive on- line, but I doubt it. I do know (99% sure) that a sufficiently clever virus could find and use even an unmounted hard disk, assuming you can put yours in that state (didn't a fellow named Paul Mercer write a CDEV that could do this?) Therefore, presuming that S-O-C-Del does not unalterably change some state in the SCSI controler (or something like that), it is impossible to guarantee protection to your hard disk without physically cutting off the data (or at least the write) lines between it and the computer. At this point, either solution is probably safe, but they won't be when virus writers start getting a little more sophisticated. He then writes: > Just pray that the virus >doesn't get stored in your parameter ram, or you will be really screwed >because the battery back-up for the SE is *SOLDERED* to the mother >board. Solution to this deal --> Run it on a Mac Plus, and if you suspect >a virus residing in your parm ram, remove the battery from the back via the >battery door. Wait 40 seconds for all to clear and then put it back in. This is nonsense, for several reasons. 1) There isn't enough room in the PRAMs to store even the simplest virus, even on the Mac II. (The others have, I believe, *20 WHOLE BYTES* of which 12 are used.) 2) Even if there were, how would such a virus gain control of the system? Code is never stored in the PRAMs, so nothing there is ever executed. Two gotchas, though: 1) It is possible that a virus could store a counter in the PRAMs, thus enabling a 'time-bomb' effect WITHOUT ever modifying anything in the System or elsewhere. You would never know there was anything wrong, until... 2) I know of one case where a Mac II couldn't even boot off of a FLOPPY. The cause was supposed to be trashed PRAMs. I don't see how this could be, but the person complaining was fairly expert, and they sure as hell didn't miss anything obvious. Furthermore, I think the problem was solved by temporarily shorting the PRAM battery. This was broadcast over USENET some time ago, so if anyone knows better please tell me. If the short did cure the problem, this virtually proves the trashed-PRAM hypothesis. The long and the short of it is that a truly nasty virus _might_ be able to render your Mac II logic board useless (until you short your battery). I don't believe this can happen to an SE, but I don't know for sure. In any event, DON'T short your battery unless you DAMN WELL know EXACTLY what you are doing! Kenneth R. van Wyk User Services Senior Consultant Steve Dallas: Who's driving?! Lehigh University Computing Center Opus: Oh keep your pants on, Internet: I pressed cruise control. BITNET: ========================================================================= Date: Thu, 9 Jun 88 10:43:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Jim Shaffer, Jr." Subject: RE: Universal Viral Simulator >Reprinted without permission from June 1988 IEEE Computer, p.100: >"System simulates viral attacks on PCs >"The National Bulletin Board Society has developed a computer virus testing ------------------------------- WHO??? I've never heard of them. Has anyone? _______________________________________________________________________________ | James M. Shaffer, Jr. | Bitnet: shafferj@bknlvms | | P.O. Box C-2658 | Internet: shafferj%bknlvms.bitnet@cunyvm.cuny.edu| | Bucknell University | UUCP: ...!psuvax1!bknlvms.bitnet!shafferj | | Lewisburg, PA USA 17837 | CSNet: shafferj%bknlvms.bitnet@relay.cs.net | ------------------------------------------------------------------------------- | "He's old enough to know what's right and young enough not to choose it; | | He's noble enough to win the world but fool enough to lose it." | | -- Rush, "New World Man", on _Signals_ | ------------------------------------------------------------------------------- ========================================================================= Date: Thu, 9 Jun 88 11:48:46 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David M. Chess" Subject: PLAYBOY 'virus' on PCs? ACS045 at GMUVAX writes > and the PLAYBOY virus, both of which only affect PCs.... The only thing I know of called "PLAYBOY" was a Trojan horse (i.e. it didn't spread to other executables) that was reported to erase hard disks on Macs. Is this "PLAYBOY" thing on the PC similar, or is it a real spreading virus? Dave Chess T.J.Watson Research Center (Affiliation given for identification purposes at most) ========================================================================= Date: Thu, 9 Jun 88 12:26:57 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: msmith@topaz.rutgers.edu Subject: PKARC 3.6 -- Is it a VIRUS? Recently a file called PK36.EXE with a size of 118K has appeared on a BBS near me. Is this really a new version of PKARC/PKXARC? Is this a Trojan or virus? Please post your answer so that a warning/verification can reach as far as possible. Mark -- Mark Smith (alias Smitty) "Be careful when looking into the distance, 61 Tenafly Road that you do not miss what is right under your nose." Tenafly, NJ 07670 {backbone}!rutgers!topaz.rutgers.edu!msmith msmith@topaz.rutgers.edu Bill and Opus in '88!!! ========================================================================= Date: Thu, 9 Jun 88 12:42:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: ACS045@GMUVAX Subject: wHOOPS! ACS045 at GMUVAX writes > and the PLAYBOY virus, both of which only affect PCs.... >The only thing I know of called "PLAYBOY" was a Trojan horse >(i.e. it didn't spread to other executables) that was reported >to erase hard disks on Macs. Is this "PLAYBOY" thing on the >PC similar, or is it a real spreading virus? >Dave Chess >T.J.Watson Research Center >(Affiliation given for identification purposes at most) Ok...perhaps I should have been more specific....I guess by PCs I meant (P)ersonal (C)omputers.. e.g. all brands/models/makes... Actually the possibility of misinterpretation struck me after hitting the CTRL-Z to send the sucker, and by that time it was too late --Sorry for any confusion/panic caused.. "call back the bombers, stand down the missiles..."--WarGames Steve Okay(ACS045@GMUVAX) ========================================================================= Date: Thu, 9 Jun 88 22:26:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Jim Shaffer, Jr." Subject: Core Wars Has anyone out there developed a mainframe version of Core Wars that they'd be willing to distribute via the network? _______________________________________________________________________________ | James M. Shaffer, Jr. | Bitnet: shafferj@bknlvms | | P.O. Box C-2658 | Internet: shafferj%bknlvms.bitnet@cunyvm.cuny.edu| | Bucknell University | UUCP: ...!psuvax1!bknlvms.bitnet!shafferj | | Lewisburg, PA USA 17837 | CSNet: shafferj%bknlvms.bitnet@relay.cs.net | ------------------------------------------------------------------------------- | Changes can open your eyes. | | --Boston, on _Third Stage_ | ------------------------------------------------------------------------------- P.S. I've notified Rick Zellich, the maintainer of the "List of Lists," of the existance of this list. I tried to make the part about sending subscription requests to the listserv and not to the list clear, and I also included the owner's address in case anyone had any questions. The "List of Lists" is distributed to a far wider field of people than any Bitnet-oriented listserv listings I've seen. It contains listings for Internet lists in addition to listserv lists (some of which it lacks because list owners don't know about it). If anyone wants a copy (it's big, so organizing some system of distribution for multiple people at one site is recommended), it's stored on NICSERVE@BITNIC in fragments. You'll need to get the index to find their names. ========================================================================= Date: Thu, 9 Jun 88 09:37:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: riacs!ames!hc!csed-1!csed-47!roskos@rutgers.edu Subject: Uses of Self-Replicating Code >There are probably other points, but these will do. Note that this is *not* >a list of the salient points of a virus - I've not mentioned self-replication, >for example, because (correct me if I'm wrong) the skill of writing self- >replicating code is not exactly of general utility (though I'll admit I can't >see into the future). Actually, in the middle '70s, I used a system where self-replicating code in the OS was common; this was in the NCR "B1" Operating System (the name "B1" was apparently derived from the name of the principal designer, John Burnett, and the fact that it was a single-tasking OS. It had nothing to do with the "B1" of computer security). This OS, although slow and primitive, actually had a lot of interesting innovations; one of these was VOSS, the "Variable Overlay Stasher System". Depending on what hardware you had, and what options you wanted, you would set a bitmap indicating which sets of overlays (sort of like current- day "packages" or "modules") you wanted on a given disk. (They were called "overlays" because in fact the OS was one that used overlays, as opposed to virtual memory, to get large programs into a small space. Our machine had only 32K, and the OS took up only a small fraction of that, due to the overlaying, although the overlay swapping made the system enormously slow.) NCR would periodically come out with updates to the OS, which you would install onto your first disk using a utility program. But thereafter, the software update would propagate itself to your other system disks in the same way viruses propagate! Whenever you mounted a new disk (actually, I think whenever you opened a file on a new disk, but I can't remember the details) the OS would check whether the new disk contained an older version of the software than the current one; if the new disk had older software, the OS would copy the overlays you had selected onto the disk, replacing the old version with the new one. In this way, as long as you mounted all your disks eventually, all the disks would automatically be updated once you updated the first one from the distribution disk.* This was more important on that system (the Century 100 Series) than on systems nowadays because, like an old floppy disk microcomputer, the machine only had small (removable) hard disks, and you would frequently have to have a number of copies of the OS around on the different (small) disks you needed to run your various programs. Thus insuring that they were all updated without the help of this self-updating feature would have been difficult: in the installation where I worked, there were around 100 disk packs, of which a significant number had the OS on them. So, the system used the same basic technology as the virus, but for a constructive purpose. I recall that under some circumstances it was possible for this updating to go the wrong way, though; it would replace a newer version of the OS with an older version. I can't remember what caused this, just that the self-updating would sometimes malfunction. *I think it required you to answer "EE" (which meant "Ok") or "CC" (which meant "Cancel") before it would actually update the disk. ========================================================================= Date: Fri, 10 Jun 88 07:57:46 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Re: Uses of Self-Replicating Code In-Reply-To: Message of Thu, 9 Jun 88 09:37:00 EDT from >the software update would propagate itself to your other system disks in >the same way viruses propagate! Then it could be called a virus. (At least it got the user's approval before propogating...) Remember, a virus need not be harmful. All that it needs to do to be classified as a virus is to replecate itself. In Dr. Cohen's dissertation, he mentions a compression virus. This compression virus attaches itself (eventually) to all of the executable files on a system and, whenever they're executed, it uncompresses them and then loads them. Of course, when it first infects an executable file, it compresses it. Such a compression virus, according to Dr. Cohen, is capable of greatly reducing the amount of disk space that all the executable files take up. Thus, it is a *good* virus. Of course, the fact that an executable file has to be uncompressed every time it is executed slows the computer down considerably, but nonetheless, the compression virus is a good one. Ken Kenneth R. van Wyk User Services Senior Consultant Steve Dallas: Who's driving?! Lehigh University Computing Center Opus: Oh keep your pants on, Internet: I pressed cruise control. BITNET: ========================================================================= Date: Fri, 10 Jun 88 09:36:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Jim Shaffer, Jr." Subject: the media and viruses For the people who say the media are blowing the virus problem out of proportion: The media are blowing the AIDS virus problem out of proportion also. I don't know anyone who has it, or anyone who knows anyone who has it. So it's really not a problem. ========================================================================= Date: Fri, 10 Jun 88 11:21:49 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: CB Lih Subject: Re: the media and viruses In-Reply-To: Message of Fri, 10 Jun 88 09:36:00 EDT from >For the people who say the media are blowing the virus problem out of >proportion: > >The media are blowing the AIDS virus problem out of proportion also. >I don't know anyone who has it, or anyone who knows anyone who has it. >So it's really not a problem. I hope this was just a poor taste sarcasm. It would be even worse if he's serious. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Sincerly, and I mean that, =---> CB Lih <---= User Services -> Computing Services -> University of Arkansas -> Fayetteville CL06076@UAFSYSB Disclaimer: There's a hole in my ozone layer. ========================================================================= Date: Fri, 10 Jun 88 13:41:46 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: Resent-From: KPETERSEN@SIMTEL20.ARPA Comments: Originally-From: Keith Petersen From: KPETERSEN@SIMTEL20.ARPA Subject: PK36.EXE ARC maker/extractor by Phil Katz now available Now available via standard anonymous FTP from SIMTEL20.ARPA... Filename Type Bytes CRC Directory PD1: PK36.EXE.1 BINARY 117781 977FH PK36.EXE is Phil Katz's latest release (ver 3.6) of PKARC/PKXARC. It literally blows away the competition with its new features and speed. Improvements include: ability to add/delete members from existing ARC even if there is less space than required to make the new ARC (great for floppy disk use); ability to read configuration file with your favorite options to make them the defaults (nice for setting it to always make SEA-compatible ARCs) but you can still override the specified defaults with command line options; ability to display the name and version number of the ARC maker that produced any ARC file; optional paginated text extract to screen, and many more new features. This copy of PK36.EXE was obtained directly from Phil Katz in order to assure its authenticity. Keith Petersen Maintainer of the CP/M and MSDOS archives at SIMTEL20.ARPA [26.0.0.74] Arpa: W8SDZ@SIMTEL20.ARPA Uucp: {decwrl,harvard,lll-crg,ucbvax,uunet,uw-beaver}!simtel20.arpa!w8sdz GEnie: W8SDZ ========================================================================= Date: Fri, 10 Jun 88 12:44:35 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Re: the media and viruses In-Reply-To: Message from "CB Lih" of Jun 10, 88 at 11:21 am >>For the people who say the media are blowing the virus problem out of >>proportion: >>The media are blowing the AIDS virus problem out of proportion also. >>I don't know anyone who has it, or anyone who knows anyone who has it. >>So it's really not a problem. > I hope this was just a poor taste sarcasm. It would be even worse if >he's serious. I am sure he meant the remark as a sarcastic one. Clearly the existence of a virus on any machine is a threat, not just when it is on yours. We can afford to be more thick skinned than this. len@evax.milw.wisc.edu ========================================================================= Date: Fri, 10 Jun 88 13:59:30 CST Reply-To: Virus Discussion List Sender: Virus Discussion List From: David Camp Subject: Re: PKARC 3.6 -- Is it a VIRUS? In-Reply-To: Message of Thu, 9 Jun 88 12:26:57 EDT from > >Recently a file called PK36.EXE with a size of 118K has appeared on a >BBS near me. Is this really a new version of PKARC/PKXARC? Is this a >Trojan or virus? > >Please post your answer so that a warning/verification can reach as >far as possible. > >Mark This file was found in PKARCJAN.ARC on LISTSERV@RPICICGE. -David- --------------------- FILE alert doc --------------------- --------------------------- cut here -------------------------------- c: ARC+ZOO+ #1002 12-27-87 23:16 (Read 0 times) f: PHIL KATZ (REBEL LEADER) t: ALL s: TROJAN ALERT cc: SYSOP 12/27/87 There have recently been several trojan/hacked/pirated versions of PKARC/PKXARC showing up. The most vicious of the bunch is called NEWARKR.EXE. This is a (PKSFX) self-extracting file, but contains no DOCS. The programs PKXARC, PKARC, and PKSFX have been renamed to XARKR, ARKR, and RKSFX respectively. The PKWARE copyright has been removed from these programs, along with PKWARE's address and all references to ShareWare. The Copyright notice has been replaced with the phrase "Public Domain Software". These programs have been modified in other means too, and their reliability is unknown. Equally malicious, there has been a trojan patch for PKXARC that has been cirulated. It is a copy of a valid message from me posted on USENET, except the patch given in the message has been changed to write directly to the FAT and wipe out disk C. There have been also various files circulated claiming to be PKARC/PKXARC versions 3.6 and 5.3. These are all hacked or pirated. The perpetrators of these hacks are guilty of Copyright infringement, theft, libel with malice, or other applicable crimes. PKWARE Inc. will seek to prosecute these individuals to the fullest extent of the law. If you see any file claiming to be a new version of PKARC/PKXARC or a patch to those programs, and are unsure of their origin, please check the following BBS's for the authentic files: PKWARE BBS 414-352-7176 EXEC-PC 414-964-5160 RBBS OF CHICAGO 312-352-1035 SOUND OF MUSIC 516-536-8723 If you do encounter any hacked or pirated files, please inform the SYSOP of the system with these files to delete them immediately. Please also inform PKWARE inc. of these files, their origin, and all other information that you have available. We can be reached at either any of the above BBS numbers, or 414-352-3670 voice. Only with your help can these very sick individuals be prevented from causing harm to unsuspecting victims of these hacked and pirated programs. >Phil Katz> --------------------------- cut here -------------------------------- > >-- >Mark Smith (alias Smitty) "Be careful when looking into the distance, >61 Tenafly Road that you do not miss what is right under your nose." >Tenafly, NJ 07670 {backbone}!rutgers!topaz.rutgers.edu!msmith >msmith@topaz.rutgers.edu Bill and Opus in '88!!! ========================================================================= Date: Fri, 10 Jun 88 16:31:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Jim Shaffer, Jr." Subject: that comment I made (come on now,guys!) That comment I made about the media and viruses was sarcastic. But I DON'T think it was in even slightly bad taste. It was intended to make a point, which I hope it did. ========================================================================= Date: Fri, 10 Jun 88 08:55:54 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: riacs!ames!hc!csed-1!csed-47!roskos@rutgers.edu > The long and the short of it is that a truly nasty virus _might_ be able to > render your Mac II logic board useless (until you short your battery). > In any event, DON'T short your battery unless you WELL know EXACTLY > what you are doing! Don't short your battery anyway. I have forgotten the procedure, but I remember that there is a way (by holding down a combination of keys, or the mouse and some keys, but I don't recall) that will cause the parameter RAM to be reinitialized during system startup (the ROM checks for this combination and resets the RAM before it looks to see what is in the RAM, so prior contents don't affect it). This was added specifically for the models of Macintosh that had nonremovable batteries, and was put in before the ones with the nonremovable batteries even came out. I remember this from when I was working for one of the Mac applications software developers over a year ago; it was in the pre-release technical documentation. But since I don't program Macintoshes any more I don't remember the procedure; does anybody else know what it is? I guess it is remotely possible that they removed it from the startup code, but I kind of doubt it; Apple engineers aren't that forgetful, that they would not provide a way to reinitialize the PRAM. For one thing, they have to initialize it when they first assemble the machines... ========================================================================= Date: Sat, 11 Jun 88 18:05:00 MDT Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: Warning -- original Sender: tag was KPETERSEN@SIMTEL20.ARPA From: Keith Petersen Subject: [slvblc!dick: FSP_12 bugs] Forwarded from Usenet... Date: Friday, 3 June 1988 19:47-MDT From: slvblc!dick at ucscc.UCSC.EDU (Dick Flanagan) Newsgroups: comp.sys.ibm.pc Re: FSP_12 bugs Summary: Ross, ya blew it! Disclaimer: none > W8SDZ@SIMTEL20.ARPA (Keith Petersen) writes: > Greg, I have forwarded the message addressed to Info-IBMPC reporting > the problem with FSP_12 destroying files to Ross Greenberg at his > network address: formtek!ditka!ramnet!sysop@pt.cs.cmu.edu (this is an > Arpanet path). I have sent several detailed FSP bug reports to Greenberg at this address, but have never received any response. > Hopefully he will send you some communication about the bugs present > in FSP_12 and earlier versions, as reported by Sandia National > Laboratories. Greenberg's style seems to flame those who report FSP bugs with that arrogant "what do you expect for a lousy ten bucks" attitude of his. > I suggest that Ross' email address be published in Info-IBMPC digest > so bug reports can be sent directly to him. I haven't had any luck in > getting answers. Perhaps his surface mail address should be posted, too, since he doesn't appear to respond to email. It is: Ross Greenberg Software Concepts Design 594 3rd Avenue New York, New York 10016 Personally, when Ross first asked for $10, I sent him a little more than that because I thought his efforts should be rewarded in some small way. I'm sorry now that I did. I dare say his FSP has probably caused more damage than the viruses it was supposed to protect us from. Dick -- Dick Flanagan, W6OLD GEnie: FLANAGAN UUCP: ...!ucbvax!ucscc!slvblc!dick Voice: +1 408 336 3481 Internet: slvblc!dick@ucscc.UCSC.EDU LORAN: N037 04.7 W122 04.6 USPS: PO Box 155, Ben Lomond, CA 95005 ========================================================================= Date: Mon, 13 Jun 88 01:38:16 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Amanda B Rosen Subject: Re: Zapping Prams Recently, in response to my previous message, riacs!ames!hc!csed-1!csed-47!roskos@rutgers.edu (name unknown) wrote: >> The long and the short of it is that a truly nasty virus _might_ be able to >> render your Mac II logic board useless (until you short your battery). >> In any event, DON'T short your battery unless you WELL know EXACTLY >> what you are doing! > >Don't short your battery anyway. > >I have forgotten the procedure, but I remember that there is a way >(by holding down a combination of keys, or the mouse and some keys, >but I don't recall) that will cause the parameter RAM to be reinitialized >during system startup (the ROM checks for this combination and resets >the RAM before it looks to see what is in the RAM, so prior contents >don't affect it). This was added specifically for the models of Macintosh >that had nonremovable batteries, and was put in before the ones with >the nonremovable batteries even came out. > >I remember this from when I was working for one of the Mac applications >software developers over a year ago; it was in the pre-release technical >documentation. But since I don't program Macintoshes any more I don't >remember the procedure; does anybody else know what it is? I believe that you are referring to the standard PRAM-zapping procedure for both the SE and II: Hold down the command, option, and shift keys while selecting the control panel from the apple menu. In any event, there is no other user procedure to do this that is documented *anywhere* (of course you can write your own code to do it...) At any rate, this does not cover the circumstances I was describing. That situation was extremely unusual. I did not say that the Hard Disk wouldn't boot. I said that the WHOLE MAC II wouldn't boot- even from floppies. Thus there was no way to zap the PRAMS. I also didn't say that I believe this story. I simply find it likely since it comes from what I believe to be a reliable source. On the other hand, I don't understand how the PRAM settings can affect a floppy boot-up, so for now, it's a confirmed maybe... > I guess it >is remotely possible that they removed it from the startup code, but I >kind of doubt it; Apple engineers aren't that forgetful, that they would >not provide a way to reinitialize the PRAM. For one thing, they have >to initialize it when they first assemble the machines... Not so. The ROM checksums the PRAMS, and if it sees that they don't have some correct value, it resets them to some known state. Zapping the PRAMs simply writes garbage (zeros?) to them so that the next time you boot, they get reset. /a ========================================================================= Date: Mon, 13 Jun 88 02:25:15 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: shorting batteries Short your battery? That's dangerous advice...many batteries explode when shorted, some of them violently. In addition, it is likely you will give your PRAMs a mild shock from static electricity, and possibly damage them majorly. You might try removing the battery and shorting the terminals on the battery socket or whatever. This also may zap your PRAMs. Safest would be to take the battery out and wait a minute or so for the PRAMs to forget stuff. It may take longer than this, depending on the capacitance of the power supply; there might be bypass caps sitting on it, and the PRAMs are probably LP devices. The point is: don't short batteries, if you value your computer. - Jeff Ogata ========================================================================= Date: Mon, 13 Jun 88 05:04:09 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Amanda B Rosen Subject: Shorting batteries... I *KNOW* it's dangerous... Please read the entire message. 1) Mac II's don't have battery sockets. They are soldered in. 2) I know that this is dangerous. The alternative was to trash a Mac II's motherboard. The point is: don't short batteries, unless your computer is already dead... /a ========================================================================= Date: Mon, 13 Jun 88 15:11:17 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: alternative to shorting batteries The proper alternative to shorting a soldered battery is to desolder it and wait. - Jeff Ogata ========================================================================= Date: Mon, 13 Jun 88 16:01:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Ted Shapin Subject: Article on virus protection [The company that wrote this article has a BBS and also sells "C-4", a TSR program for IBM-PC's. I think FLU_SHOT+ is better and it has the advantage of being shareware and is available from Ross Greenberg's BBS (212) 889-6438 and Compuserve.] - - - - ANTI-VIRUS MEASURES Copyright InterPath Corporation 1988 All rights reserved 408 988 3832 4423 Cheeney Street, Santa Clara CA 95054 PURPOSE: This document outlines the various types of commonly found viruses and suggests measures that can be taken to minimize the risks of infection and procedures that may be used to recover from infected systems. TYPES OF VIRUSES: There are currently three classes of viruses: Boot infectors, system infectors and general executable program infectors. Their characteristics are: Boot Infectors: Boot infectors attach themselves to sector 0 of floppy disks and, occasionally, hard disks. They gain control when the system is initially booted and remain in control at all times. Many have the capability to trap warm boot requests ( ) and remain in control even if booted from a non-infected floppy, with the result that the clean floppy becomes instantly infected. Boot infectors typically create bad disk sectors to which the original boot sector is copied, along with the remainder of the virus code. Boot infectors may be from 2 to 7 sectors in length. Boot infectors can be benign or malignant. The Pakistani Brain virus, for instance, is a benign boot infector virus in its original form. It has been hacked however into a very malignant form which can infect hard disks and which destroys FAT entries, deletes files, and performs other malicious activities. System Infectors: A number of viruses attach themselves to command.com and other system files that remain memory resident. They gain control after system boot and infect hard disks or other bootable floppies that contain the appropriate system files. System infectors may activate after a given period of time or they may instantly begin subtle modifications in system processing - including increasing the time to perform system functions, subtle scrambling of data or modification of system error messages or informational messages. The Jerusalem (Israeli) virus is an example of such a virus. (The Israeli virus is also able to act as a general .com and .exe infector as well as being a system infector). Activation may take place after a specified period of time has elapsed or after a specific number of invocations. Activation may include scrambling the FAT, erasure of specific files, low level disk format or modification of non-executable files containing numeric or other ascii data. General .COM and .EXE infectors. This class of virus is the most dangerous from an infection standpoint since these viruses can spread to almost any program in any system. They infect in two generic ways: 1. By gaining control each time the infected program is executed and copying itself to other .com or .exe files on the fixed or floppy disk prior to passing control to the host program. This is the most common infection technique. 2. By remaining memory resident and infecting each program that is loaded for execution. This technique is used by the Jerusalem virus but is less common than the above method. Some of these viruses attach themselves externally to .com or .exe files and thus change the file size. They may or may not modify the creation date and time. Others insert themselves internally in the executable host program's dead space and are thus "invisible" to anything other than a binary compare routine. Some viruses continue to infect the same program multiple times until the program becomes too large to fit into memory. Most, however, check to see if the host has already been infected and pass over previously infected files. PREVENTION TECHNIQUES: Prevention can be divided into two areas: 1) safe user practices and 2) anti-viral tools. 90% of all virus infections can be easily prevented by following safe usage guidelines. Most of the other 10% of infections can be avoided by the use of anti-viral software or hardware tools. Safe user practices: 1. !! NEVER BOOT FROM ANY FLOPPY OTHER THAN !! !! THE ORIGINAL WRITE PROTECTED DISKETTE !! !! FROM THE ORIGINAL DISTRIBUTION PACKAGE !! The above recommendation is extremely important. Most of the boot sector infector viruses can ONLY infect your system if you boot from an infected floppy diskette. Booting from borrowed, unknown or multiple diskettes greatly increases the opportunity for infection. 2. One and only one boot diskette should be assigned to each and every floppy based PC (systems without a fixed disk), and that diskette should be CLEARLY labeled as the boot diskette for that system. 3. If you have a system with a fixed disk - NEVER boot from a floppy drive. The only exceptions to this involve recovering from a viral infection as described in the section below. 4. Treat public domain and shareware software with caution. Viruses are difficult to detect and usually do not modify the operation of the infected program in any way prior to activation. Thus a friend or acquaintance might in all good faith recommend a program that is infected without their knowledge of its infection. If possible, limit use of such programs to systems without fixed disks. If you do use them on fixed disks, allocate separate subdirectories for the public domain programs. This will limit exposure since some viruses limit their replication activities to the current subdirectory. You should not place public domain or shareware software in the root directory. 5. Create meaningful volume labels on all fixed and floppy disks at format time. Develop a habit of checking volume labels each time a DIR command is executed. Keep a look out for changes in the volume labels. 6. Watch for changes in the pattern of your system's activities. Do program loads take longer than normal? Do disk accesses seem excessive for simple tasks? Do unusual error messages occur with regularity? Do access lights on any of the system devices turn on when there should be no activity on that device? Do you have less system memory available than usual? Do programs or files disappear mysteriously? Do you suddenly notice a reduction in available disk space? Any of these signs can be indicative of viral infections. 7. If you are in a corporate or multi-system environment, minimize the exchange of executable code between systems wherever feasible. When using resources on someone else's PC (a laser printer, for example), transfer the necessary data on a diskette that contains no executable code. Also, do not use diskettes that are bootable or that contain system files. 8. If operating in a network environment, do not place public domain or shareware programs in a common file server directory that could be accessible to any other PC on the network. 9. If operating in a network environment, allow no-one other than the system administrator to use the file server node. 10. If using 3270 emulators connected to mainframe systems, keep all 3270 emulation software together in a separate subdirectory and do not include ANY executable code in the subdirectory that is not part of the emulator suite. If possible, limit such terminals to 3270 emulation only, and remove all other software from the disk. 3270 emulators are the major gateways through which viruses jump from PCs to mainframes. Anti Viral Tools: Hardware: Write protect tabs go a long way toward limiting viral spread. All boot floppies should be write protected as a matter of course. For certain high security environments, you can even purchase write protect systems for hard disks. Some flexibility may be lost, but the protection factor is high. In addition to write protection, you should consider removing floppies from drive slots and storing them in filing cases when they are not being actively referenced. We have yet to hear of a virus jumping direct from system memory to a diskette that was not inserted. Software: Software protection falls into two general categories: programs that help prevent the virus from initially infecting your system, and programs that help identify that your system has been infected after the infection has occurred. Both types of protection have their pros and cons. Programs that help prevent initial infection: These programs are TSR (terminate and stay resident) programs that monitor system activity and watch for characteristic viral replication activities. They check all disk I/O and cause a warning to be displayed when unauthorized activities are attempted. Such activities are: writes to executable programs, system device drivers, the boot sector, etc. They typically re- direct the operating system's interrupt vectors and thus intercept requests from all other programs. This type of protection has the advantage of stopping viruses before they enter the system, thus avoiding the difficult and time consuming tasks associated with removing viruses. The disadvantage, however, is that viruses can be written to avoid detection using this system. Also, no software technique can prevent initial infection from a boot sector virus. (Another reason to follow the above procedures to avoid boot sector infections). Programs that are available that help prevent initial infection are: Antidote, from Quaid Software 416 961 8243 C-4, from InterPath 408 988 3832 Dr. Panda Utilities, from Panda Systems 302 764 4722 Flu-Shot, from Ross Greenberg 212 889 6431 Viru-Safe, from ComNetco 201 953 0322 Programs that Identify infections after the fact: First, as a note of explanation, these programs only work if the system they are running on HAS NOT BEEN INFECTED prior to installation. They cannot tell you whether you system has already been infected. They all assume that the system is clean. They work by looking at key information on the system disks (file sizes, dates, checksums, etc.) and periodically re-checking this information to see if it has changed. The advantage of this approach is that it is much more difficult for viruses to avoid detection. The disadvantage is that the system must become infected in order to detect the virus. Thus the user runs the risk that the virus may activate before it can be detected. Activation usually implies loss of data or entire disks. If activation does not occur prior to detection, the user still faces the task of removing the virus, which, as can be seen in the following section, is a tricky task. The following are programs which provide this type of protection: Dr. Panda Utilities, from Panda Systems 302 764 4722 Retro-V, from InterPath 408 988 3832 Vaccinate, from Sophco 800 922 3001 RECOVERY FROM INFECTION It is much more difficult to recover from an infection than it is to initially prevent the infection. Nevertheless, if strict procedures are followed, recovery can be achieved with minimum loss of data. The main problem in recovering from a virus is not the loss of data (which may indeed be considerable), but the near certainty of re-infection if the proper procedures are not followed. Nine out of ten installations that get infected experience a relapse within a week of "cleaning out" the virus. Some organizations have "eradicated" a virus as many as a dozen times, only to have it re-occur shortly after each eradication. The causes of these re-appearances can be traced to two things: 1). Many viruses do not go away after a warm boot. The Pakistani Brain virus is a good example of such a virus. In many organizations, the PC is seldom turned off and the prevailing assumption is that a will clean out system memory - an incorrect assumption. 2). Viruses initially infect fixed disk systems by way of a floppy diskette. After infection, every floppy that has been placed in the system is also likely to be infected. In large organizations, this can amount to thousands of infected diskettes that can re-infect systems if not de-activated. Understanding the above issues goes a long way toward a successful recovery from a virus infection. Recovery: When an infection is detected the following procedures should be followed: 1. Determine the extent of infection. If the virus has not attacked any fixed disks go to step - 12. If the virus has infected the boot sector only, go to addendum. 2. Power down the infected system. 3. Retrieve the original DOS diskette from the distribution package. Write protect it. Place it in the floppy boot drive and power up the system. 4. Ensure that the system has booted properly. 5. Backup all non-executable files from all directories onto newly formatted floppy diskettes or to a tape backup unit. If backing up to another fixed disk, ensure that the disk has not been infected. (if there are any doubts, assume that it is infected). DO NOT USE THE BACKUP UTILITY ON THE FIXED DISK. Use a utility from the original package. NOTE - At no point in these procedures should you execute ANY program from the infected fixed disk! 6. List all batch files on the infected disk. If any line within any of the batch files seems unusual or unfamiliar do not back-up. Otherwise, include the batch files with the back-up. 7. Perform a low level format of the infected disk. Recover the initial disk configuration using FDISK and FORMAT. 8. Execute the SYS command for the fixed disk. 9. Re-structure your directories. 10. Replace all executable programs from the original distribution packages. 11. Restore the files that had been backed up. 12. Locate all floppy diskettes that may have been inserted in the infected system within the past two years. (We know it sounds EXTREME, but if this and subsequent steps is not followed, you can be guaranteed to be re-infected within a short period of time). 13. At your discretion either: A). Destroy them all -or- B). Continue with the following steps 14. Backup all non executable files onto newly formatted floppy diskettes. 15. Format the suspect diskettes. Addendum: If the virus is a boot sector infector, the recovery process is somewhat simplified. Since boot infectors do not infect executable programs, they can be removed by doing a SYS command on the affected drive. The procedures are: 1). Power down the affected system. 2). Boot from the original DOS write protected distribution diskette. 3. Perform the SYS command on all affected devices. The above procedures will leave the virus intact on the additional bad sectors originally allocated by the virus, but these viral segments will be de-activated. This document is available on InterPath/National BBS bulletin board - 408 988 4004. ------- ========================================================================= Date: Tue, 14 Jun 88 01:27:25 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Amanda B Rosen Subject: Re: alternative to shorting battery Recently, Jefferson Ogata wrote: >The proper alternative to shorting a soldered battery is to desolder >it and wait. It all depends on if you're under warranty or not. Desolder the battery and your warranty is shot. Short it and you're OK. Even if the battery blows there's a good chance your dealer won't know. Please, people, let's just agree that shorting batteries is a last-ditch effort to be used only by the desperate, and drop it... This is way off virus subjects... /a ========================================================================= Date: Tue, 14 Jun 88 02:35:17 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Amanda B Rosen Subject: Soldering vs. Shorting I agree, it's silly. This is the last I will write about the subject (sighs of relief...) I believe that in fact, the dealer DID short the battery... /a ========================================================================= Date: Tue, 14 Jun 88 09:25:59 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Any info on gerbel virus? I've just received a word of mouth report about a virus called the gerbel virus. The report was sketchy, but it *appears* to be a boot- record virus. It reportedly makes a few copies of itself and then destroys the original (much like the Lehigh virus). Well, when it does its nasty work, it supposedly puts gerbel tracks (or reasonable ASCII renditions thereof) across the bottom of the user's screen and outputs some inane (sp?) message. Note that this is all sketchy! Do *NOT* necessarily trust it as being accurate. Does anyone out there have any substantiated information on this alleged gerbel virus? If so, please forward it to the list. Ken P.S. I now know more than I ever thought I would about Mac II batteries; I hope we can get on to the real issues at hand. Which isn't to say Mac batteries aren't really awesome... :-) ...lets all try to keep the discussion to viruses, ok? Kenneth R. van Wyk User Services Senior Consultant Steve Dallas: Who's driving?! Lehigh University Computing Center Opus: Oh keep your pants on, Internet: I pressed cruise control. BITNET: ========================================================================= Date: Tue, 14 Jun 88 08:44:00 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: GREENY Subject: re: yet another alternative to shorted batteries > The proper alternative to shorting a soldered battery is to desolder > it and then wait. I agree. But since you have gone to all the trouble to desoldering the little sucker, and since this problem COULD arise again, why not drop a mini-SPST switch in there to prevent the desoldering mess again next time it happens? Radio shack has em for say $1.29....and maybe a little plastic box and a piece of velcro to stick it to the side of the power supply...about a total of $3-$4.....and somewhat helpful too... Any objections? Suggestions? bye for now but not for long... Greeny Bitnet: MISS026@ECNCDC Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU Disclaimer: Route all complaints to /dev/null ========================================================================= Date: Tue, 14 Jun 88 06:17:16 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: riacs!ames!hc!csed-1!csed-47!roskos@rutgers.edu Subject: Not presently here I am in Seattle, and thus cannot answer your mail at present. I will answer your message when I return. This reply was automatically generated. ========================================================================= Date: Tue, 14 Jun 88 11:43:15 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Re: Not presently here In-Reply-To: Message of Tue, 14 Jun 88 06:17:16 EDT from >This reply was automatically generated. If anyone else out there plans on using one of these "automatic answering machine" programs, *PLEASE* advise them not to reply to VIRUS-L! It's very rude, and won't be tolerated. 'Nuff said. Ken Kenneth R. van Wyk User Services Senior Consultant Steve Dallas: Who's driving?! Lehigh University Computing Center Opus: Oh keep your pants on, Internet: I pressed cruise control. BITNET: ========================================================================= Date: Tue, 14 Jun 88 13:12:13 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Neil Goldman (216) 861-5000" To: VIRUS-L at LEHIIBM1 Two points of interest. 1) According to Ross Greenberg, the author of FluShot+, a new version with 'all known bugs, defeciences, problem spots, and areas of concern' is currently in Beta test. It should be released next week. 2) RE: Jim Shaffer's request for info on the Universal Virus Simulator. the National BBS Society (NBBS) can be reached at: 4423 Cheeney Street Santa Clara, CA 95054 Voice - (408) 727-4559 BBS - (408) 988-4004 They have two programs. The first is called VIRUSIM.EXE, and simulates every known method (except boot sector infect) of replication. First run your protection software, then execute VIRUSIM. It will tell you which test it is running. Hopefully, your protection software will 'stop it in the act.' If not, you know which type of know virus replication mechanisms which you are *not* immune to. The second is called VIRUS-B.COM. It is a modified version of the Israeli Friday the 13th virus. The branch to the destruction mechanism has been removed, and it is restricted to the current subdirectory. Also, It will only infect COM files, but will not infect COMMAND.COM. When it infects a COM file, it changes the time/date stamp, increases the program size by about 500 bytes, and when the infected program is executed, it will display a message indicating so. Infected programs do themselves become viruses. NOTE: Before they would allow me to download these two programs, they called the Senior Manager in my department to insure I was who I claimed to be. Obviously, in the 'wrong hands', these two programs are potentially hazardous. ========================================================================= Date: Tue, 14 Jun 88 15:34:09 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Russell Nelson Subject: version number hack. Another form of delayed virus execution is based on the version number. Imagine if a virus waited until the version number of MS-DOS was 3.5 or greater until it attacked? -russ X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X Another file downloaded from: The NIRVANAnet(tm) Seven & the Temple of the Screaming Electron Taipan Enigma 510/935-5845 Burn This Flag Zardoz 408/363-9766 realitycheck Poindexter Fortran 510/527-1662 Lies Unlimited Mick Freen 801/278-2699 The New Dork Sublime Biffnix 415/864-DORK The Shrine Rif Raf 206/794-6674 Planet Mirth Simon Jester 510/786-6560 "Raw Data for Raw Nerves" X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X