Return-Path: XPUM04@prime-a.central-services.umist.ac.uk Received: from G.SEI.CMU.EDU by ubu.cert.sei.cmu.edu (5.61/2.3) id AA21775; Thu, 7 Jun 90 18:12:17 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA16472; Thu, 7 Jun 90 18:12:15 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA15042; Thu, 7 Jun 90 18:11:54 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa28358; 7 Jun 90 20:20 BST From: Anthony Appleyard To: DAVIDF@cs.heriot-watt.ac.uk Date: Thu, 07 Jun 90 15:36:48 BST Message-Id: <$TGVGDBVHFKWN at UMPA> Subject: Virus-L vol 0 issue #0727 Virus-L Digest Wed, 27 Jul 88, Volume 0 : Issue #0727 Today's Topics Re: BIOSes and ROM BIOSes reply to virus-l of 880727 Macvirus mailer Rom Bios Re: Virus List Re: Macvirus mailer Trapping Direct Disk Write Calls Re: Trapping Direct Disk Write Callss Re: Macvirus mailer Guarding against illegal DOS calls. Re: Guarding against illegal DOS calls. Campus virus letter RE: Re: Trapping Direct Disk Write Calls Re: Guarding against illegal DOS calls. ------------------------------ Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: BIOSes and ROM BIOSes Originally a BIOS was merely intended to abstract the hardware from the operating system. The BIOS would supply procedures for the operating system that were independent of the hardware involved. A case in point: CP/M (again). To have a CP/M machine, you need only supply about 30 different functions in the BIOS. These are primitive I/O functions such as console input, disk seek, et alii. The CP/M operating system itself is the same program in all CP/M computers from Osbornes to Kaypros to Altairs. As for the ROM aspect, it is just one way of handling the problem of where to keep the BIOS. Many CP/M computers keep the BIOS along with the CP/M shell on a boot track on disk. The whole shebang gets sucked in by a boot program on powerup. Others just keep the shell on disk and store the BIOS in ROM onboard the computer. The disadvantage of ROMing your BIOS is that it becomes very difficult to alter it. In my CP/M days I found a number of hacks to my machine's BIOS that improved its performance. In addition, putting BIOS in ROM in a CP/M computer is of dubious utility. If there were any CP/M viruses, they would probably live in the shell, not in the BIOS, which varies from machine to machine. In the MSDOS case we have BIOSes in ROM consistently. Many if not all clones are designed to be hardware compatible with IBM PCs as far as is possible. Thus frequently the BIOSes are interchangeable. But here my knowledge of MSDOS is quite fuzzy. But if clones had BIOS on disk, they might be more susceptible to virus infection at the BIOS level. Putting the BIOS in ROM restricts infection to the operating system level. I seriously doubt IBM had this in mind when they designed it though. Maybe someone with a good knowledge of the MSDOS details can provide more specific information. Happy trails, - Jeff -------------------- Date: Wed, 27 Jul 88 07:51:19 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Re: BIOSes and ROM BIOSes In-Reply-To: Message of Wed, 27 Jul 88 00:00:46 EDT from Jeff Ogata had a real good explanation for the ROM BIOS being the intermediary between the operating system and the specific hardware. In the CP/M world this was extremely important because hardware varied from machine to machine, thus all standard CP/M programs used only the operating system I/O facilities so that they could be sure to work on any standard CP/M computer. The end user need only supply his/her terminal specific escape codes (clear screen, reverse video, etc.) to install the program. Then along came the IBM PC and hardware compatability. It didn't take long for the software developers to realize that both the BIOS and the actual hardware *should* be the same from machine to machine as long as it (the machine) is IBM PC compatible. By bypassing the MS-DOS (PC-DOS) I/O calls and going straight to the BIOS or even the hardware, a middleman was eliminated, and the resulting program worked a lot faster. This practice also weeded out the partially compatible machines rather quickly... An anti-virus program can trap the operating system I/O calls (INT 21H) very easily. It's also rather easy to trap the BIOS routines in the same manner. It's not too simple to trap a program from working directly with the computer's hardware (such as the hard disk controller). And, since the actual memory of the PC is alterable by any program (i.e., not protected memory), it's real tough to assure that even any traps of the operating system and BIOS remain intact. Ken Kenneth R. van Wyk From the Devil's Dictionary: User Services Senior Consultant Barometer - an ingenious device Lehigh University Computing Center designed to inform the user what Internet: the weather is. BITNET: -------------------- Date: Wed, 27 Jul 88 09:33:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: ACS045@GMUVAX Subject: reply to virus-l of 880727 >>As the virus world seems to have quieted down (at least here in the >>Academic community) over the summer, I'm interested to hear what people >>think will happen in the Fall and subsequent semesters as far as viruses >>are concerned. Do you think that all the publicity has enticed some >>would be wrong doers into working on some super duper virus over the >>summer, only to be released upon their return to college? Or is this >>too cynical an outlook? Have we seen the end of viruses? Perhaps all >>of the potential virus writers have decided to change their ways? A >>lot of people who I've spoken with feel that a lot of virus writing >>efforts are taking place this summer; I hope that they're wrong. >>Opinions? >>Ken __________________________________________________________________________ >Speaking from the students point of view, I believe that if there are virus >writers working over the summer, they are not students. Several years ago, >this may have been the case. However, given the publicity that viruses have >received, it has become almost taboo among college students (at least the >sample I know). I believe college students in general lack sufficient >motivation to spend time writing a virus..... > Shawn Hernan > University of Pittsburgh Speak for yourself, but I feel that the worst has yet to come. We have several known hackers around here(banished from the system ages ago) who are probably busily hacking away at the very such things you think college students are beyond...In a sort of half-twisted way, I hope they succeed, it'll give us the one final excuse the university needs to expel(sp?) them. Plus, we are ready for them, I think. After a terrible BRAIN attack in the spring, our User Services and Support group mobilized, and everyone is quite aware of viruses and the damage they can do. Has this list been of any use??---yes, I myself know a hell of a *LOT* more about virii than I did back in May, and I know it has helped wake up a lot of people at both my jobs. Thanks to all of you who have helped us separate the hype from the truth, and what needs to/can be done about it all. - ----------------------------------------------------------------------------- Steve Okay ACS045@GMUVAX.BITNET/acs045@gmuvax2.gmu.edu/CSR032 on The Source "Disclaimers???---We don' need no STEENKING disclaimers!!" -------------------- Date: Wed, 27 Jul 88 09:42:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: JJ_KRAME@FANDM Subject: Macvirus mailer I am preparing a disk/document mailing to all the departments at my school. The topic on hand is viruses, specifically those connected with the macintosh. There seems to be a lot of dis information pertaining to viruses around the school, and I suppose someone should set the record straight (or at least into a well-fitted curve). The reason I am sending a letter to this mailer is to get feedback on what I should include. I am including Apple's own virusRx, Thurman's 'Interferon', virus detective DA, and Vaccine. I need information to draw from for the document I will be sending along. Any help would be appreciated. Joe Kramer Consultant-- Franklin and Marshall College Bitnet: JJ_kramer@Fandm -------------------- Date: Wed, 27 Jul 88 10:12:14 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: SHERK@UMDD Subject: Rom Bios In-Reply-To: Message received on Tue, 26 Jul 88 23:44:43 EDT >> Basically, Bios contains the routines that run all of your PC's I/O devices, >>inclding th Monitor, and Disk Drives... >>DOS also supplies functions that do many of the same things. >So why is there this apparently redundant duplication of services in >the IBM PC world? Is this the case with other operating systems as well? >This seems to make (as has been pointed out before by others) DOS a really >leaky way of running a safe computing environment. Mind you, how could >the deveopers know that people would conceive of viruses? It isn't really a case of "duplication of services". One isn't supposed to call the ROM Bios, instead you are supposed to call DOS which then calls the ROM Bios. This serves to hide the implementation from the programer. The advantage of this scheme is that radically different devices can be accessed with the same logical DOS calls. The disadvantage is that it is slow... -------------------- Date: Wed, 27 Jul 88 09:57:53 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe McMahon Subject: Re: Virus List In-Reply-To: Message of Tue, 26 Jul 88 11:16:00 PDT from >I'm a system programmer at a sight that supports probably 200 Macintoshes >of all types. Is there a list of programs, both comercial and public domain, >that are known to contain viruses. Such a list would not help. Once you get one, you can pretty much bet that everything else you've got has been hit, especially with the Scores virus. >By the way, I'm new to my job and the idea of worying about viruses, so >if this a dumb question, please answer it anyway. No, it's not at all a dumb question. Mac viruses in general don't seem to have been spread by Trojan programs, but by normally innocuous programs which have become infected. The infamous infection of Aldus was supposedly due to an infected copy of the program "Mr. Potato Head." There have been stories of late that infected copies of StuffIt have been uploaded (whether maliciously or not, I can't say) to private bulletin boards. PLEASE note that neither of these programs is a virus spreader! They are simply victims of this plague. I don't really know of any programs that are specifically virus "vectors". YTou really have to be careful of everything you get from anywhere other than the original author or an authorized distributor. In fact, it's not a bad idea to run one of the anti-virals on those either. If you need more information on Mac viruses and disinfection programs, order the VIRUSREM PACKAGE from our LISTSERV here at SCFVM. I'll be putting up a documentation stack sometime soon (the next day or two, I hope). - - Joe M. -------------------- Date: Wed, 27 Jul 88 11:31:56 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe Simpson Subject: Re: Macvirus mailer In-Reply-To: Message of Wed, 27 Jul 88 09:42:00 EDT from I have used Apple's Rx and recommend it. It not only looks for common virus signatures in disk files, it will write what appears to be checksum file for comparison at a later date. Rx does not prevent infection, it looks for evidence of infection. Vaccine appears to be reasonably efffective, but only if it is turned on through the control panel. Remember, changes to the Vaccine control check boxes only take effect upon reboot! I don't use virusDective, but it appears to work from the trivial testing I did. -------------------- Date: Wed, 27 Jul 88 11:55:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David E. Spiro" Subject: Trapping Direct Disk Write Calls >An anti-virus program can trap the operating system I/O calls (INT 21H) >very easily. It's also rather easy to trap the BIOS routines in the same >manner. It's not too simple to trap a program from working directly with >the computer's hardware (such as the hard disk controller). And, since >the actual memory of the PC is alterable by any program (i.e., not >protected memory), it's real tough to assure that even any traps of the >operating system and BIOS remain intact. >Kenneth R. van Wyk >Lehigh University Computing Center I remember reading in one of Peter Norton's books that he supports programming that makes DOS (rather than BIOS) calls because then the program should be more compatible with TSRs, window environments, etc. Are there a lot of programs that ask for disk writes directly (i.e. not through DOS)? If not, would it be possible to write a TSR that differentiates between disk write calls from DOS (making them legal) and those that are direct (flagging them as suspicious)? I'm not a programmer, so forgive me if this is gibberish. David Spiro Center for Interntional Affairs, Harvard University Center for International and Comparative Studies, Brandeis University DISCLAIMER: Blame it on my wife. -------------------- Date: Wed, 27 Jul 88 13:30:26 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Re: Trapping Direct Disk Write Calls In-Reply-To: Message of Wed, 27 Jul 88 11:55:00 EDT from >I remember reading in one of Peter Norton's books that he supports >programming that makes DOS (rather than BIOS) calls because then the >program should be more compatible with TSRs, window environments, etc. True, from a standpoint of compatability, using DOS calls is much better than bypassing DOS via the BIOS or the hardware. It's also probably a better programming practice (*OPINION*). The only disadvantage is that the DOS calls are horrendously (sp?) slow when compared to the BIOS or hardware calls. For example, writing characters directly to video memory instead of using DOS INT 21 to draw them is at least an order of magnitude faster (!), but won't work on all machines/display adaptors. The end-user will probably prefer the faster program (assuming that it runs on his/her hardware) and it will probably sell better... >Are there a lot of programs that ask for disk writes directly (i.e. not >through DOS)? Not too many bypass DOS on disk activity, but *most* bypass it for screen I/O. Many (all?) TSRs that do disk I/O bypass the DOS interrupts because, being a single tasking operating system, DOS is non-reentrant. This means that no two pieces of code can (or at least *should) use the same interrupt at the same time; so, if program X is doing an INT 21 when a TSR does an INT 21, program X and/or the TSR will die a horrible death. This doesn't hold true for all DOS functions in INT 21, but at least for many of them. >If not, would it be possible to write a TSR that >differentiates between disk write calls from DOS (making them legal) and >those that are direct (flagging them as suspicious)? DOS itself must be able to do direct BIOS and/or hardware calls. Like I said, it is possible to trap the DOS I/O calls, so a TSR can look out for them, and examine them to see if they're trying to do something nasty (e.g., write to an executable file). As far as I know, the closest interrupt to the hardware disk I/O level is INT 13H; it, too, can be trapped (it is in the BIOS). Since it is in the BIOS, however, it must be at an absolute memory location (in order for the machine to be truly PC compatible), so any virus should know exactly where to find it in such a way that cannot be trapped by merely stopping disk interrupts. Perhaps there is a way to trap actual hardware level calls that I'm not aware of... Any ideas? If virus Y sees that INT 13 is being grabbed by another program, it's the easiest thing in the world (well almost...) to reset the interrupt pointer to point straight to the BIOS in ROM, perform the interrupt without fear of being watched, and restore the interrupt when done (so as not to leave any traces) and continue. Assuming that the interrupts remain unaltered, it is possible to examine the interrupts return address to see whether it came from DOS or from a user program/virus. This assumes, also, that new versions of DOS use the same locations in memory... Sigh... Hope this answers your questions... Any other comments out there? Ken >I'm not a programmer, so forgive me if this is gibberish. >David Spiro >Center for Interntional Affairs, Harvard University >Center for International and Comparative Studies, Brandeis University >DISCLAIMER: Blame it on my wife. Kenneth R. van Wyk From the Devil's Dictionary: User Services Senior Consultant Barometer - an ingenious device Lehigh University Computing Center designed to inform the user what Internet: the weather is. BITNET: -------------------- Date: Wed, 27 Jul 88 13:25:43 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Re: Macvirus mailer In-Reply-To: Message from "VIRUS-L@LEHIIBM1.BitNet" of Jul 27, 88 at 9:42 am > I am preparing a disk/document mailing to all the departments >at my school. The topic on hand is viruses, specifically those >connected with the macintosh. There seems to be a lot of dis >information pertaining to viruses around the school, and I suppose >someone should set the record straight (or at least into a well-fitted >curve). The reason I am sending a letter to this mailer is to get feedback >on what I should include. I am including Apple's own virusRx, Thurman's >'Interferon', virus detective DA, and Vaccine. I need information to draw >from for the document I will be sending along. Any help would be >appreciated. Joe Kramer >Consultant-- Franklin and Marshall College >Bitnet: JJ_kramer@Fandm If and when you get it done, please publish it here. I am sure that lots of folks would be glad to steal/use with attribution the work you have done. Thanks. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U. S. A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + -------------------- Date: Wed, 27 Jul 88 15:01:42 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: SHERK@UMDD Subject: Guarding against illegal DOS calls. >>An anti-virus program can trap the operating system I/O calls (INT 21H) >>very easily. It's also rather easy to trap the BIOS routines in the same >>manner. It's not too simple to trap a program from working directly with >>the computer's hardware (such as the hard disk controller). And, since >>the actual memory of the PC is alterable by any program (i.e., not >>protected memory), it's real tough to assure that even any traps of the >>operating system and BIOS remain intact. >I remember reading in one of Peter Norton's books that he supports >programming that makes DOS (rather than BIOS) calls because then the >program should be more compatible with TSRs, window environments, etc. >Are there a lot of programs that ask for disk writes directly (i.e. not >through DOS)? If not, would it be possible to write a TSR that >differentiates between disk write calls from DOS (making them legal) and >those that are direct (flagging them as suspicious)? When DOS is active, it sets a flag (in_dos). A simple TSR could trap all ROM Bios calls and check the DOS flag. If the flag is set it could allow the interupt and if the flag is not set it could return(error). Of course it is easy to circumvent a scheme like this with a smart virus. Erik Sherk Workstation support staff - University of Maryland -------------------- Date: Wed, 27 Jul 88 16:15:45 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Re: Guarding against illegal DOS calls. In-Reply-To: Message of Wed, 27 Jul 88 15:01:42 EDT from >When DOS is active, it sets a flag (in_dos). A simple TSR could trap all >ROM Bios calls and check the DOS flag. If the flag is set it could allow >the interupt and if the flag is not set it could return(error). Of >course it is easy to circumvent a scheme like this with a smart virus. Ok, then how about having the virus attach itself (i.e., rewrite) the COPY command? Simple, COPY is *allowed* to alter and move files, so just "instruct" it to append a virus. Obviously, this flag, in-dos, would be TRUE if COPY is doing the work... Oh, and COPY need only be altered in memory, not on disk (in COMMAND.COM). Just have, say, some game alter it a bit. >Erik Sherk >Workstation support staff - University of Maryland Ken Kenneth R. van Wyk From the Devil's Dictionary: User Services Senior Consultant Barometer - an ingenious device Lehigh University Computing Center designed to inform the user what Internet: the weather is. BITNET: -------------------- Date: Wed, 27 Jul 88 13:55:29 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Campus virus letter To the group: I plan to submit this for inclusion in an all campus newsletter this fall. The audience will be faculty and staff who are reasonable, but do not understand computers or computering. Any suggestions or advice would be appreciated. Thanks. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U. S. A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + Potential virus Attacks at UWM UWM has a high probability of having its office PC's (so called IBM compatible machines) struck with a computer virus attack sometime soon, probably before June 1989. If and when it occurs, it is possible that nearly every office IBM compatible machine will fail or lose files on the same day. It will be a very unpleasant time and our professional staff will be overwhelmed by requests for help and will take some time (weeks) to get the recovery process under way. Most of us are unaware of how dependent we have become on these desktop machines and how much we will be affected by the loss of data that will ensue. Not only will the office machines be affected, but the home machines that many faculty now have will also have their files affected by the very same virus, and at the same time. If you are preparing a paper for publication, an exam, or some correspondence, you may well find that your machine readable copies of that material will become unusable both at home and at the office. This will be a very unpleasant experience. This paper discusses some evasive action that you can do now to prepare for the return of your machine to working order. What I am recommending in this paper is no more than good housekeeping and is practice that each of us should do anyhow, with or without the threat of some mysterious computer virus. What I will discuss for the next few paragraphs applies to users who have machines with either a floppy disk drive and a hard disk drive or have two floppy disk drives on their computers. Step one: Locate the original source disks for the operating system you are now using on your computer. This may no longer be the system delivered with your machine, you may well have had an upgrade. DO NOT PUT THESE DISKS INTO YOUR FLOPPY DRIVE YET. Secure a few dozen write-lock tabs and put one on each of the delivery system disks. (When you hold a disk upright the right side of the disk has a 1/4" square notch cut into the black paper jacket. The write-lock tabs are black or aluminum colored gummed paper tags about 3/4" X 1/2" that can be stuck over the edge of the disk covering the front and back of this notch. When that tab is in place it is not possible for the computer to write information onto a floppy disk.) Only after you have write-locked these disks should you put the disk into the computer and compare the system on that disk with the system you are using. STOP AND READ THE NEXT SENTENCE! The simple act of executing the DIR command on an unlocked disk is enough to infect that disk with a virus if your system is already infected and if the disk is not write-locked. I am not kidding. There is a very small probability that your system is already infected. I recommend that you compare the date and size of the file COMMAND.COM on your original source disks and on your working disk or disks to see that they are the same. For my system the results look like this: C> dir a:\command.com Volume in drive A is MS330PP01 Directory of A:\ COMMAND COM 25276 7-24-87 12:00a 1 File(s) 5120 bytes free C> dir c:\command.com Volume in drive C has no label Directory of C:\ COMMAND COM 25276 7-24-87 12:00a 1 File(s) 7391232 bytes free Note that both copies of COMMAND.COM have the same date and time of creation (midnight on July 24th 1987) and both are the same size (25,276 bytes). The numbers for your machine may well differ from mine, but both should be the same. When those disks have been found, put them away in a safe place. I recommend that they be put in a plastic storage box not too near your computer. Step two: There are a small number of software packages that you would be lost without. In my case they include WordStar, dBase III, PKARC, Kermit, and Directory Scanner. These packages may well be purchased commercial software (WordStar, dBase III), shareware (PKARC, Directory Scanner), and freeware (Kermit). In each case you should have an original source delivery disk for each of these packages. Find those disks, WRITE LOCK THEM, compare them with the copies you are now using, and put them in a save place. I recommend that they be put with the system disks discussed above. (It is probably true that the creation dates for the running copies of this sort of software will disagree with the creation dates for the delivery disks. Installation of many of these packages entails writing to the program. That is not a problem.) Step three: Using the backup procedure of your choice, perform a backup of the system files on your computer. If I was using a dual floppy based system, I would simply make copies of my working WordStar, dBase III, PKARC, Kermit, and Directory Scanner disks. If I was using a computer with a floppy and a hard disk, I would use backup-restore, or Fastback or some other package to back up the directories C:\WS, C:\DB3, C:\ARK, C:\KERMIT and C:\DS. (Of course these directories have different names on your system.) Write lock these backup disks. Label them with today's date. Using your backup system compare the disks you have just backed up with the disks you are using to ensure that the backup "took". Put the backup disks in a safe place. This will tie up half a dozen disks, but with disks now costing $0.35 each, you will probably find the $2 investment worth while. Step four: (This applies to those users who hard disk based computers.) Prepare a backup procedure that will permit incremental backups. This will entail backing up the entire system once, and then periodically backing up those files that have changed since the last backup. Perform such incremental backups regularly. After several such incremental backups, the size of the backup set will become quite large. At that time, put the backup set away in a safe place and begin with another set of disks for a full system backup followed by several increments. When the second set is full, put them away and return to the first set. This will afford a very secure set of backup files. I find that 50 disks makes a good backup set. Thus 100 disks would be used for the double backup group. I suspect that most users would need to do a full backup about 4 to 8 times per year, requiring about 1/2 hour of manipulation and should do incremental backups about twice per week, requiring less than 5 minutes. (It is a very good idea to periodically test the backup system with a verification of what you have backed up. Most file backup systems have a Verify command to do this sort of test.) Step five: Go back to your useful work. Recovery from the lost of one or a few files: Sooner or later you will lose some files. They will dissapear without apparent cause and you will blame the problem on a virus. It is my experience that no virus is involved, the loss of files will be due to an operator error. If you have been doing incremental backups, then the simplest corrective action is to use the recover feature of the backup system that you are using and simply restore the latest copy of the lost file(s) to the hard disk. If you have been consciencious then the loss of work will entail just a few minutes or hours of rework. Recovery from the loss of the entire system: It may happen that the entire hard disk seems to be lost. This is serious and is most likely not the result of a virus. Most failures of the hard disk are due to hardware problems. The best solution is to repair the hardware if the technical people judge that that is the problem, and then, after reformatting the hard disk, restore the system from your latest backup. Almost without fail, this will result in a complete return to a normal system. Really bad news, the restore does not work: This may well be the point of this memo. If a virus has been planted in your system and has been set to trigger on some event, then the only way to recover is to rebuild the system from scratch using the write locked set of disks that I advised you to prepare above. If these disks are not write locked, and if you mount them onto an infected system, then the disks will be infected in turn and you may well be unable to restore from a clean, uninfected source. On the assumption that you can build your system again from scratch, you may restore all of the data files from your backup set. (A data file is one that does not have the extension .com, .exe, or .sys.) Any other file should not be able to carry a virus either between systems or over the backup process. Some facts: There is no reason ever to boot the system from a foreign disk. There is no reason why a disk used to transport data between manchines should have a copy of the files io.sys, msdos.sys, ibmio.sys, ibmdos.sys or command.com on it. No system to date has been infected by the transport to it of data files. Only executable files can be used as trojan horses. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U. S. A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + Thanks. L. P. L. 7/27/88 -------------------- Date: Wed, 27 Jul 88 19:54:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: Robert Adsett Subject: RE: Re: Trapping Direct Disk Write Calls >Perhaps there is a way to trap actual hardware level calls that I'm not >aware of... Any ideas? If virus Y sees that INT 13 is being grabbed by >another program, it's the easiest thing in the world (well almost...) to >reset the interrupt pointer to point straight to the BIOS in ROM, perform >the interrupt without fear of being watched, and restore the interrupt when >done (so as not to leave any traces) and continue. Actually it's easier than that. All the program has to do is set up the stack properly and do a direct jump. Of course this assumes that the location of the interupt in the bios and so will not work with all bios's. I don't know of any way to trap this. Robert Adsett Dept. of Phys. Univ. of Waterloo Waterloo Ont. Canada " 'Freedom' has no meaning of itself. There are always restrictions, be they legal, genetic, or physical. If you don't believe me, try to chew a radio signal. " Kelvin Throop, III -------------------- Date: Wed, 27 Jul 88 20:33:47 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: SHERK@UMDD Subject: Re: Guarding against illegal DOS calls. In-Reply-To: Message received on Wed, 27 Jul 88 17:56:39 EDT !When DOS is active, it sets a flag (in_dos). A simple TSR could trap all !ROM Bios calls and check the DOS flag. If the flag is set it could allow !the interupt and if the flag is not set it could return(error). Of !course it is easy to circumvent a scheme like this with a smart virus. >Ok, then how about having the virus attach itself (i.e., rewrite) the >COPY command? Simple, COPY is *allowed* to alter and move files, so >just "instruct" it to append a virus. Obviously, this flag, in-dos, >would be TRUE if COPY is doing the work... Oh, and COPY need only be >altered in memory, not on disk (in COMMAND.COM). Just have, say, some >game alter it a bit. >Ken >Kenneth R. van Wyk From the Devil's Dictionary: A virus that is smart enough to hack the resident portion of command.com would probably know about IN_DOS. The TSR scheme I proposed offers a low-level of protection, no much above write protecting your disks. The advantages of it are that it can be kept active all the time with little performance degradation. Erik Sherk -------------------- *** end of Virus-L issue *** Return-Path: XPUM04@prime-a.central-services.umist.ac.uk Received: from G.SEI.CMU.EDU by ubu.cert.sei.cmu.edu (5.61/2.3) id AA25856; Tue, 12 Jun 90 06:40:29 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA12960; Tue, 12 Jun 90 06:40:25 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA04220; Tue, 12 Jun 90 06:39:47 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa09502; 12 Jun 90 11:09 BST From: Anthony Appleyard To: KRVW <@NSFnet-Relay.AC.UK:KRVW@sei.cmu.edu> Date: Tue, 12 Jun 90 11:04:32 BST Message-Id: <$TGVTCZHTCBQR at UMPA> Subject: Virus-L vol 0 issue #0727 Virus-L Digest Wed, 27 Jul 88, Volume 0 : Issue #0727 Today's Topics Re: BIOSes and ROM BIOSes reply to virus-l of 880727 Macvirus mailer Rom Bios Re: Virus List Re: Macvirus mailer Trapping Direct Disk Write Calls Re: Trapping Direct Disk Write Callss Re: Macvirus mailer Guarding against illegal DOS calls. Re: Guarding against illegal DOS calls. Campus virus letter RE: Re: Trapping Direct Disk Write Calls Re: Guarding against illegal DOS calls. ------------------------------ Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: BIOSes and ROM BIOSes Originally a BIOS was merely intended to abstract the hardware from the operating system. The BIOS would supply procedures for the operating system that were independent of the hardware involved. A case in point: CP/M (again). To have a CP/M machine, you need only supply about 30 different functions in the BIOS. These are primitive I/O functions such as console input, disk seek, et alii. The CP/M operating system itself is the same program in all CP/M computers from Osbornes to Kaypros to Altairs. As for the ROM aspect, it is just one way of handling the problem of where to keep the BIOS. Many CP/M computers keep the BIOS along with the CP/M shell on a boot track on disk. The whole shebang gets sucked in by a boot program on powerup. Others just keep the shell on disk and store the BIOS in ROM onboard the computer. The disadvantage of ROMing your BIOS is that it becomes very difficult to alter it. In my CP/M days I found a number of hacks to my machine's BIOS that improved its performance. In addition, putting BIOS in ROM in a CP/M computer is of dubious utility. If there were any CP/M viruses, they would probably live in the shell, not in the BIOS, which varies from machine to machine. In the MSDOS case we have BIOSes in ROM consistently. Many if not all clones are designed to be hardware compatible with IBM PCs as far as is possible. Thus frequently the BIOSes are interchangeable. But here my knowledge of MSDOS is quite fuzzy. But if clones had BIOS on disk, they might be more susceptible to virus infection at the BIOS level. Putting the BIOS in ROM restricts infection to the operating system level. I seriously doubt IBM had this in mind when they designed it though. Maybe someone with a good knowledge of the MSDOS details can provide more specific information. Happy trails, - Jeff -------------------- Date: Wed, 27 Jul 88 07:51:19 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Re: BIOSes and ROM BIOSes In-Reply-To: Message of Wed, 27 Jul 88 00:00:46 EDT from Jeff Ogata had a real good explanation for the ROM BIOS being the intermediary between the operating system and the specific hardware. In the CP/M world this was extremely important because hardware varied from machine to machine, thus all standard CP/M programs used only the operating system I/O facilities so that they could be sure to work on any standard CP/M computer. The end user need only supply his/her terminal specific escape codes (clear screen, reverse video, etc.) to install the program. Then along came the IBM PC and hardware compatability. It didn't take long for the software developers to realize that both the BIOS and the actual hardware *should* be the same from machine to machine as long as it (the machine) is IBM PC compatible. By bypassing the MS-DOS (PC-DOS) I/O calls and going straight to the BIOS or even the hardware, a middleman was eliminated, and the resulting program worked a lot faster. This practice also weeded out the partially compatible machines rather quickly... An anti-virus program can trap the operating system I/O calls (INT 21H) very easily. It's also rather easy to trap the BIOS routines in the same manner. It's not too simple to trap a program from working directly with the computer's hardware (such as the hard disk controller). And, since the actual memory of the PC is alterable by any program (i.e., not protected memory), it's real tough to assure that even any traps of the operating system and BIOS remain intact. Ken Kenneth R. van Wyk From the Devil's Dictionary: User Services Senior Consultant Barometer - an ingenious device Lehigh University Computing Center designed to inform the user what Internet: the weather is. BITNET: -------------------- Date: Wed, 27 Jul 88 09:33:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: ACS045@GMUVAX Subject: reply to virus-l of 880727 >>As the virus world seems to have quieted down (at least here in the >>Academic community) over the summer, I'm interested to hear what people >>think will happen in the Fall and subsequent semesters as far as viruses >>are concerned. Do you think that all the publicity has enticed some >>would be wrong doers into working on some super duper virus over the >>summer, only to be released upon their return to college? Or is this >>too cynical an outlook? Have we seen the end of viruses? Perhaps all >>of the potential virus writers have decided to change their ways? A >>lot of people who I've spoken with feel that a lot of virus writing >>efforts are taking place this summer; I hope that they're wrong. >>Opinions? >>Ken __________________________________________________________________________ >Speaking from the students point of view, I believe that if there are virus >writers working over the summer, they are not students. Several years ago, >this may have been the case. However, given the publicity that viruses have >received, it has become almost taboo among college students (at least the >sample I know). I believe college students in general lack sufficient >motivation to spend time writing a virus..... > Shawn Hernan > University of Pittsburgh Speak for yourself, but I feel that the worst has yet to come. We have several known hackers around here(banished from the system ages ago) who are probably busily hacking away at the very such things you think college students are beyond...In a sort of half-twisted way, I hope they succeed, it'll give us the one final excuse the university needs to expel(sp?) them. Plus, we are ready for them, I think. After a terrible BRAIN attack in the spring, our User Services and Support group mobilized, and everyone is quite aware of viruses and the damage they can do. Has this list been of any use??---yes, I myself know a hell of a *LOT* more about virii than I did back in May, and I know it has helped wake up a lot of people at both my jobs. Thanks to all of you who have helped us separate the hype from the truth, and what needs to/can be done about it all. - ----------------------------------------------------------------------------- Steve Okay ACS045@GMUVAX.BITNET/acs045@gmuvax2.gmu.edu/CSR032 on The Source "Disclaimers???---We don' need no STEENKING disclaimers!!" -------------------- Date: Wed, 27 Jul 88 09:42:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: JJ_KRAME@FANDM Subject: Macvirus mailer I am preparing a disk/document mailing to all the departments at my school. The topic on hand is viruses, specifically those connected with the macintosh. There seems to be a lot of dis information pertaining to viruses around the school, and I suppose someone should set the record straight (or at least into a well-fitted curve). The reason I am sending a letter to this mailer is to get feedback on what I should include. I am including Apple's own virusRx, Thurman's 'Interferon', virus detective DA, and Vaccine. I need information to draw from for the document I will be sending along. Any help would be appreciated. Joe Kramer Consultant-- Franklin and Marshall College Bitnet: JJ_kramer@Fandm -------------------- Date: Wed, 27 Jul 88 10:12:14 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: SHERK@UMDD Subject: Rom Bios In-Reply-To: Message received on Tue, 26 Jul 88 23:44:43 EDT >> Basically, Bios contains the routines that run all of your PC's I/O devices, >>inclding th Monitor, and Disk Drives... >>DOS also supplies functions that do many of the same things. >So why is there this apparently redundant duplication of services in >the IBM PC world? Is this the case with other operating systems as well? >This seems to make (as has been pointed out before by others) DOS a really >leaky way of running a safe computing environment. Mind you, how could >the deveopers know that people would conceive of viruses? It isn't really a case of "duplication of services". One isn't supposed to call the ROM Bios, instead you are supposed to call DOS which then calls the ROM Bios. This serves to hide the implementation from the programer. The advantage of this scheme is that radically different devices can be accessed with the same logical DOS calls. The disadvantage is that it is slow... -------------------- Date: Wed, 27 Jul 88 09:57:53 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe McMahon Subject: Re: Virus List In-Reply-To: Message of Tue, 26 Jul 88 11:16:00 PDT from >I'm a system programmer at a sight that supports probably 200 Macintoshes >of all types. Is there a list of programs, both comercial and public domain, >that are known to contain viruses. Such a list would not help. Once you get one, you can pretty much bet that everything else you've got has been hit, especially with the Scores virus. >By the way, I'm new to my job and the idea of worying about viruses, so >if this a dumb question, please answer it anyway. No, it's not at all a dumb question. Mac viruses in general don't seem to have been spread by Trojan programs, but by normally innocuous programs which have become infected. The infamous infection of Aldus was supposedly due to an infected copy of the program "Mr. Potato Head." There have been stories of late that infected copies of StuffIt have been uploaded (whether maliciously or not, I can't say) to private bulletin boards. PLEASE note that neither of these programs is a virus spreader! They are simply victims of this plague. I don't really know of any programs that are specifically virus "vectors". YTou really have to be careful of everything you get from anywhere other than the original author or an authorized distributor. In fact, it's not a bad idea to run one of the anti-virals on those either. If you need more information on Mac viruses and disinfection programs, order the VIRUSREM PACKAGE from our LISTSERV here at SCFVM. I'll be putting up a documentation stack sometime soon (the next day or two, I hope). - - Joe M. -------------------- Date: Wed, 27 Jul 88 11:31:56 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe Simpson Subject: Re: Macvirus mailer In-Reply-To: Message of Wed, 27 Jul 88 09:42:00 EDT from I have used Apple's Rx and recommend it. It not only looks for common virus signatures in disk files, it will write what appears to be checksum file for comparison at a later date. Rx does not prevent infection, it looks for evidence of infection. Vaccine appears to be reasonably efffective, but only if it is turned on through the control panel. Remember, changes to the Vaccine control check boxes only take effect upon reboot! I don't use virusDective, but it appears to work from the trivial testing I did. -------------------- Date: Wed, 27 Jul 88 11:55:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David E. Spiro" Subject: Trapping Direct Disk Write Calls >An anti-virus program can trap the operating system I/O calls (INT 21H) >very easily. It's also rather easy to trap the BIOS routines in the same >manner. It's not too simple to trap a program from working directly with >the computer's hardware (such as the hard disk controller). And, since >the actual memory of the PC is alterable by any program (i.e., not >protected memory), it's real tough to assure that even any traps of the >operating system and BIOS remain intact. >Kenneth R. van Wyk >Lehigh University Computing Center I remember reading in one of Peter Norton's books that he supports programming that makes DOS (rather than BIOS) calls because then the program should be more compatible with TSRs, window environments, etc. Are there a lot of programs that ask for disk writes directly (i.e. not through DOS)? If not, would it be possible to write a TSR that differentiates between disk write calls from DOS (making them legal) and those that are direct (flagging them as suspicious)? I'm not a programmer, so forgive me if this is gibberish. David Spiro Center for Interntional Affairs, Harvard University Center for International and Comparative Studies, Brandeis University DISCLAIMER: Blame it on my wife. -------------------- Date: Wed, 27 Jul 88 13:30:26 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Re: Trapping Direct Disk Write Calls In-Reply-To: Message of Wed, 27 Jul 88 11:55:00 EDT from >I remember reading in one of Peter Norton's books that he supports >programming that makes DOS (rather than BIOS) calls because then the >program should be more compatible with TSRs, window environments, etc. True, from a standpoint of compatability, using DOS calls is much better than bypassing DOS via the BIOS or the hardware. It's also probably a better programming practice (*OPINION*). The only disadvantage is that the DOS calls are horrendously (sp?) slow when compared to the BIOS or hardware calls. For example, writing characters directly to video memory instead of using DOS INT 21 to draw them is at least an order of magnitude faster (!), but won't work on all machines/display adaptors. The end-user will probably prefer the faster program (assuming that it runs on his/her hardware) and it will probably sell better... >Are there a lot of programs that ask for disk writes directly (i.e. not >through DOS)? Not too many bypass DOS on disk activity, but *most* bypass it for screen I/O. Many (all?) TSRs that do disk I/O bypass the DOS interrupts because, being a single tasking operating system, DOS is non-reentrant. This means that no two pieces of code can (or at least *should) use the same interrupt at the same time; so, if program X is doing an INT 21 when a TSR does an INT 21, program X and/or the TSR will die a horrible death. This doesn't hold true for all DOS functions in INT 21, but at least for many of them. >If not, would it be possible to write a TSR that >differentiates between disk write calls from DOS (making them legal) and >those that are direct (flagging them as suspicious)? DOS itself must be able to do direct BIOS and/or hardware calls. Like I said, it is possible to trap the DOS I/O calls, so a TSR can look out for them, and examine them to see if they're trying to do something nasty (e.g., write to an executable file). As far as I know, the closest interrupt to the hardware disk I/O level is INT 13H; it, too, can be trapped (it is in the BIOS). Since it is in the BIOS, however, it must be at an absolute memory location (in order for the machine to be truly PC compatible), so any virus should know exactly where to find it in such a way that cannot be trapped by merely stopping disk interrupts. Perhaps there is a way to trap actual hardware level calls that I'm not aware of... Any ideas? If virus Y sees that INT 13 is being grabbed by another program, it's the easiest thing in the world (well almost...) to reset the interrupt pointer to point straight to the BIOS in ROM, perform the interrupt without fear of being watched, and restore the interrupt when done (so as not to leave any traces) and continue. Assuming that the interrupts remain unaltered, it is possible to examine the interrupts return address to see whether it came from DOS or from a user program/virus. This assumes, also, that new versions of DOS use the same locations in memory... Sigh... Hope this answers your questions... Any other comments out there? Ken >I'm not a programmer, so forgive me if this is gibberish. >David Spiro >Center for Interntional Affairs, Harvard University >Center for International and Comparative Studies, Brandeis University >DISCLAIMER: Blame it on my wife. Kenneth R. van Wyk From the Devil's Dictionary: User Services Senior Consultant Barometer - an ingenious device Lehigh University Computing Center designed to inform the user what Internet: the weather is. BITNET: -------------------- Date: Wed, 27 Jul 88 13:25:43 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Re: Macvirus mailer In-Reply-To: Message from "VIRUS-L@LEHIIBM1.BitNet" of Jul 27, 88 at 9:42 am > I am preparing a disk/document mailing to all the departments >at my school. The topic on hand is viruses, specifically those >connected with the macintosh. There seems to be a lot of dis >information pertaining to viruses around the school, and I suppose >someone should set the record straight (or at least into a well-fitted >curve). The reason I am sending a letter to this mailer is to get feedback >on what I should include. I am including Apple's own virusRx, Thurman's >'Interferon', virus detective DA, and Vaccine. I need information to draw >from for the document I will be sending along. Any help would be >appreciated. Joe Kramer >Consultant-- Franklin and Marshall College >Bitnet: JJ_kramer@Fandm If and when you get it done, please publish it here. I am sure that lots of folks would be glad to steal/use with attribution the work you have done. Thanks. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U. S. A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + -------------------- Date: Wed, 27 Jul 88 15:01:42 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: SHERK@UMDD Subject: Guarding against illegal DOS calls. >>An anti-virus program can trap the operating system I/O calls (INT 21H) >>very easily. It's also rather easy to trap the BIOS routines in the same >>manner. It's not too simple to trap a program from working directly with >>the computer's hardware (such as the hard disk controller). And, since >>the actual memory of the PC is alterable by any program (i.e., not >>protected memory), it's real tough to assure that even any traps of the >>operating system and BIOS remain intact. >I remember reading in one of Peter Norton's books that he supports >programming that makes DOS (rather than BIOS) calls because then the >program should be more compatible with TSRs, window environments, etc. >Are there a lot of programs that ask for disk writes directly (i.e. not >through DOS)? If not, would it be possible to write a TSR that >differentiates between disk write calls from DOS (making them legal) and >those that are direct (flagging them as suspicious)? When DOS is active, it sets a flag (in_dos). A simple TSR could trap all ROM Bios calls and check the DOS flag. If the flag is set it could allow the interupt and if the flag is not set it could return(error). Of course it is easy to circumvent a scheme like this with a smart virus. Erik Sherk Workstation support staff - University of Maryland -------------------- Date: Wed, 27 Jul 88 16:15:45 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Re: Guarding against illegal DOS calls. In-Reply-To: Message of Wed, 27 Jul 88 15:01:42 EDT from >When DOS is active, it sets a flag (in_dos). A simple TSR could trap all >ROM Bios calls and check the DOS flag. If the flag is set it could allow >the interupt and if the flag is not set it could return(error). Of >course it is easy to circumvent a scheme like this with a smart virus. Ok, then how about having the virus attach itself (i.e., rewrite) the COPY command? Simple, COPY is *allowed* to alter and move files, so just "instruct" it to append a virus. Obviously, this flag, in-dos, would be TRUE if COPY is doing the work... Oh, and COPY need only be altered in memory, not on disk (in COMMAND.COM). Just have, say, some game alter it a bit. >Erik Sherk >Workstation support staff - University of Maryland Ken Kenneth R. van Wyk From the Devil's Dictionary: User Services Senior Consultant Barometer - an ingenious device Lehigh University Computing Center designed to inform the user what Internet: the weather is. BITNET: -------------------- Date: Wed, 27 Jul 88 13:55:29 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Campus virus letter To the group: I plan to submit this for inclusion in an all campus newsletter this fall. The audience will be faculty and staff who are reasonable, but do not understand computers or computering. Any suggestions or advice would be appreciated. Thanks. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U. S. A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + Potential virus Attacks at UWM UWM has a high probability of having its office PC's (so called IBM compatible machines) struck with a computer virus attack sometime soon, probably before June 1989. If and when it occurs, it is possible that nearly every office IBM compatible machine will fail or lose files on the same day. It will be a very unpleasant time and our professional staff will be overwhelmed by requests for help and will take some time (weeks) to get the recovery process under way. Most of us are unaware of how dependent we have become on these desktop machines and how much we will be affected by the loss of data that will ensue. Not only will the office machines be affected, but the home machines that many faculty now have will also have their files affected by the very same virus, and at the same time. If you are preparing a paper for publication, an exam, or some correspondence, you may well find that your machine readable copies of that material will become unusable both at home and at the office. This will be a very unpleasant experience. This paper discusses some evasive action that you can do now to prepare for the return of your machine to working order. What I am recommending in this paper is no more than good housekeeping and is practice that each of us should do anyhow, with or without the threat of some mysterious computer virus. What I will discuss for the next few paragraphs applies to users who have machines with either a floppy disk drive and a hard disk drive or have two floppy disk drives on their computers. Step one: Locate the original source disks for the operating system you are now using on your computer. This may no longer be the system delivered with your machine, you may well have had an upgrade. DO NOT PUT THESE DISKS INTO YOUR FLOPPY DRIVE YET. Secure a few dozen write-lock tabs and put one on each of the delivery system disks. (When you hold a disk upright the right side of the disk has a 1/4" square notch cut into the black paper jacket. The write-lock tabs are black or aluminum colored gummed paper tags about 3/4" X 1/2" that can be stuck over the edge of the disk covering the front and back of this notch. When that tab is in place it is not possible for the computer to write information onto a floppy disk.) Only after you have write-locked these disks should you put the disk into the computer and compare the system on that disk with the system you are using. STOP AND READ THE NEXT SENTENCE! The simple act of executing the DIR command on an unlocked disk is enough to infect that disk with a virus if your system is already infected and if the disk is not write-locked. I am not kidding. There is a very small probability that your system is already infected. I recommend that you compare the date and size of the file COMMAND.COM on your original source disks and on your working disk or disks to see that they are the same. For my system the results look like this: C> dir a:\command.com Volume in drive A is MS330PP01 Directory of A:\ COMMAND COM 25276 7-24-87 12:00a 1 File(s) 5120 bytes free C> dir c:\command.com Volume in drive C has no label Directory of C:\ COMMAND COM 25276 7-24-87 12:00a 1 File(s) 7391232 bytes free Note that both copies of COMMAND.COM have the same date and time of creation (midnight on July 24th 1987) and both are the same size (25,276 bytes). The numbers for your machine may well differ from mine, but both should be the same. When those disks have been found, put them away in a safe place. I recommend that they be put in a plastic storage box not too near your computer. Step two: There are a small number of software packages that you would be lost without. In my case they include WordStar, dBase III, PKARC, Kermit, and Directory Scanner. These packages may well be purchased commercial software (WordStar, dBase III), shareware (PKARC, Directory Scanner), and freeware (Kermit). In each case you should have an original source delivery disk for each of these packages. Find those disks, WRITE LOCK THEM, compare them with the copies you are now using, and put them in a save place. I recommend that they be put with the system disks discussed above. (It is probably true that the creation dates for the running copies of this sort of software will disagree with the creation dates for the delivery disks. Installation of many of these packages entails writing to the program. That is not a problem.) Step three: Using the backup procedure of your choice, perform a backup of the system files on your computer. If I was using a dual floppy based system, I would simply make copies of my working WordStar, dBase III, PKARC, Kermit, and Directory Scanner disks. If I was using a computer with a floppy and a hard disk, I would use backup-restore, or Fastback or some other package to back up the directories C:\WS, C:\DB3, C:\ARK, C:\KERMIT and C:\DS. (Of course these directories have different names on your system.) Write lock these backup disks. Label them with today's date. Using your backup system compare the disks you have just backed up with the disks you are using to ensure that the backup "took". Put the backup disks in a safe place. This will tie up half a dozen disks, but with disks now costing $0.35 each, you will probably find the $2 investment worth while. Step four: (This applies to those users who hard disk based computers.) Prepare a backup procedure that will permit incremental backups. This will entail backing up the entire system once, and then periodically backing up those files that have changed since the last backup. Perform such incremental backups regularly. After several such incremental backups, the size of the backup set will become quite large. At that time, put the backup set away in a safe place and begin with another set of disks for a full system backup followed by several increments. When the second set is full, put them away and return to the first set. This will afford a very secure set of backup files. I find that 50 disks makes a good backup set. Thus 100 disks would be used for the double backup group. I suspect that most users would need to do a full backup about 4 to 8 times per year, requiring about 1/2 hour of manipulation and should do incremental backups about twice per week, requiring less than 5 minutes. (It is a very good idea to periodically test the backup system with a verification of what you have backed up. Most file backup systems have a Verify command to do this sort of test.) Step five: Go back to your useful work. Recovery from the lost of one or a few files: Sooner or later you will lose some files. They will dissapear without apparent cause and you will blame the problem on a virus. It is my experience that no virus is involved, the loss of files will be due to an operator error. If you have been doing incremental backups, then the simplest corrective action is to use the recover feature of the backup system that you are using and simply restore the latest copy of the lost file(s) to the hard disk. If you have been consciencious then the loss of work will entail just a few minutes or hours of rework. Recovery from the loss of the entire system: It may happen that the entire hard disk seems to be lost. This is serious and is most likely not the result of a virus. Most failures of the hard disk are due to hardware problems. The best solution is to repair the hardware if the technical people judge that that is the problem, and then, after reformatting the hard disk, restore the system from your latest backup. Almost without fail, this will result in a complete return to a normal system. Really bad news, the restore does not work: This may well be the point of this memo. If a virus has been planted in your system and has been set to trigger on some event, then the only way to recover is to rebuild the system from scratch using the write locked set of disks that I advised you to prepare above. If these disks are not write locked, and if you mount them onto an infected system, then the disks will be infected in turn and you may well be unable to restore from a clean, uninfected source. On the assumption that you can build your system again from scratch, you may restore all of the data files from your backup set. (A data file is one that does not have the extension .com, .exe, or .sys.) Any other file should not be able to carry a virus either between systems or over the backup process. Some facts: There is no reason ever to boot the system from a foreign disk. There is no reason why a disk used to transport data between manchines should have a copy of the files io.sys, msdos.sys, ibmio.sys, ibmdos.sys or command.com on it. No system to date has been infected by the transport to it of data files. Only executable files can be used as trojan horses. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U. S. A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + Thanks. L. P. L. 7/27/88 -------------------- Date: Wed, 27 Jul 88 19:54:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: Robert Adsett Subject: RE: Re: Trapping Direct Disk Write Calls >Perhaps there is a way to trap actual hardware level calls that I'm not >aware of... Any ideas? If virus Y sees that INT 13 is being grabbed by >another program, it's the easiest thing in the world (well almost...) to >reset the interrupt pointer to point straight to the BIOS in ROM, perform >the interrupt without fear of being watched, and restore the interrupt when >done (so as not to leave any traces) and continue. Actually it's easier than that. All the program has to do is set up the stack properly and do a direct jump. Of course this assumes that the location of the interupt in the bios and so will not work with all bios's. I don't know of any way to trap this. Robert Adsett Dept. of Phys. Univ. of Waterloo Waterloo Ont. Canada " 'Freedom' has no meaning of itself. There are always restrictions, be they legal, genetic, or physical. If you don't believe me, try to chew a radio signal. " Kelvin Throop, III -------------------- Date: Wed, 27 Jul 88 20:33:47 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: SHERK@UMDD Subject: Re: Guarding against illegal DOS calls. In-Reply-To: Message received on Wed, 27 Jul 88 17:56:39 EDT !When DOS is active, it sets a flag (in_dos). A simple TSR could trap all !ROM Bios calls and check the DOS flag. If the flag is set it could allow !the interupt and if the flag is not set it could return(error). Of !course it is easy to circumvent a scheme like this with a smart virus. >Ok, then how about having the virus attach itself (i.e., rewrite) the >COPY command? Simple, COPY is *allowed* to alter and move files, so >just "instruct" it to append a virus. Obviously, this flag, in-dos, >would be TRUE if COPY is doing the work... Oh, and COPY need only be >altered in memory, not on disk (in COMMAND.COM). Just have, say, some >game alter it a bit. >Ken >Kenneth R. van Wyk From the Devil's Dictionary: A virus that is smart enough to hack the resident portion of command.com would probably know about IN_DOS. The TSR scheme I proposed offers a low-level of protection, no much above write protecting your disks. The advantages of it are that it can be kept active all the time with little performance degradation. Erik Sherk -------------------- *** end of Virus-L issue ***