VIRUS-L Digest Monday, 28 Oct 1991 Volume 4 : Issue 198 Today's Topics: Boot Sector Modified (PC) Bloomington (NoInt, StonedIII) Virus? ? ? Info (PC) Re: Experiences with hardware protection (Thunderbyte) (PC) Re: Experiences with hardware protection (Thunderbyte) Re: DIR II (Cluster) Virus (PC) Re: DIR II (Cluster) Virus (PC) Re: Virus-writing course for teenagers Stamping out "Stoned" (was Hardware) (PC) re: SVC 5.0 (PC) Re: Virus-writing course for teenagers re: Hardware and software (was: Leopards) re: Interpreted things Re: Help urgently needed for stoned virus (PC) Viral code association VIRUS-L is a moderated, digested mail forum for discussing computer virus issues; comp.virus is a non-digested Usenet counterpart. Discussions are not limited to any one hardware/software platform - diversity is welcomed. Contributions should be relevant, concise, polite, etc. Please sign submissions with your real name. Send contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to VIRUS-L at LEHIIBM1 for you BITNET folks). Information on accessing anti-virus, documentation, and back-issue archives is distributed periodically on the list. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@CERT.SEI.CMU.EDU. Ken van Wyk ---------------------------------------------------------------------- Date: Mon, 21 Oct 91 10:53:52 +0700 >From: Mike Albrecht Subject: Boot Sector Modified (PC) Hello All, I've read Virus-L for over a year now but until now have had no reason to submit a question. Hopefully some of you can help me out. The student computer labs that I manage for the College of Business and Economics at Washington State University are comprised of PC's & PC/XT's. We've had our share of the common viruses (Yale/Alameda, Jerusalem, Stoned) but have managed to almost eliminate the problem in the labs through regular scanning of student diskettes, use of (site licensed) F-Prot, and recently installing Padgett Peterson's NoFBoot (no problems so far, Padgett, and a big help.) However, twice now F-Prot has issued the warning: Warning !! - boot sector has been modified The first time this happened I attributed it to a student replacing the autoexec.bat file with the correct checksums (for f-oschk) for that machine with an autoexec from another machine in the lab with different checksums. I suspected this since I make the autoexec.bat file and others read-only and hidden and on this particular machine the autoexec had indeed been modified and was no longer hidden. I didn't check further but just re-ran f-oschk to generate the correct checksums, edited the autoexec accordingly, and forgot about it. No problems. Today another machine booted up with the above warning. I cold booted with a clean, write protected floppy, scanned for viruses, even used the analyse feature in F2.EXE -- nothing unusual reported. I looked at the boot record with Norton's Disk Edit and the only thing that appeared unusual was under the heading 'Special hidden sectors:' which reported 8388639 instead of the usual 31 for this drive (Seagate ST-225R.) I re-ran f-oschk to get new values, thought they looked strange (the last one was 0 which I'd not seen before), checked to see that I had copied them correctly, edited autoexec, and re-booted (this time from the hard drive: same warning. Ran f-oschk again and got different values (they looked more typical), edited autoexec, and re-booted: O.K. So...., both machines seem to be working normally; I checked the first machine for unusual boot sector values - looked O.K. What could be altering the boot sector causing f-oschk to trigger? I'd appreciate any suggestions on what to look for. It doesn't seem to be a big problem but it seems curious. I've got copies of the boot sector and PBR if they'd be of any use. Hope someone can help. Thanks. Mike Albrecht, Systems Analyst W.S.U. College of Business and Economics ------------------------------ Date: Mon, 21 Oct 91 16:23:27 -0700 >From: feb@pokey.dsd.trw.com Subject: Bloomington (NoInt, StonedIII) Virus? ? ? Info (PC) Recently we have found (several? ? ?) viruses on 3 ALR PC 386 machines. Norton Anti-virus says it is a boot sector infector named Bloomington. Mcafee v84 called it "Stoned III." Other scanning products have called it "NoInt" and "LastDirSect". I haven't been able to find information on any of these. (I checked CERT/Brunnstein list 7/91). Anybody know what this virus does, how to get rid of it. . . etc. etc. Thanks in advance. Frank E. Bien Email: feb@gumby.dsd.trw.com TRW Computer Security Services Phone: (213) 812-5072 One Space Park, S/2724B Redondo Beach, CA 90278 ------------------------------ Date: 21 Oct 91 20:28:48 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Experiences with hardware protection (Thunderbyte) (PC) harry@gem.stack.urc.tue.nl (Harry Stox) writes: > Although personally I don't have any experiences with the Thunderbyte > hardware, my guess is that is is unusable with modern IDE or SCSI > drives, since the hardware is placed between your MFM/RLL controller > and your harddisk. Oh, I forgot to say that the current version is not compatible with the MCA architecture. > Given the abominable quality of the TBScan software, which stems from > the same company, I personally wouldn't trust the software which > controls their hardware lock. While I tend to agree with the comment about the quality of TbScan, I still insist that the Thunderbyte card does pretty good job - at least for me. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Bontchev@Informatik.Uni-Hamburg.De Fachbereich Informatik - AGN Tel.:+49-40-54715-224, Fax: -246 Vogt-Koeln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 21 Oct 91 20:22:11 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Experiences with hardware protection (Thunderbyte) kirchner@uklirb.informatik.uni-kl.de (Reinhard Kirchner) writes: > I got produkt information about a hardware virus protector called > 'Thunderbyte' which intercepts all mysterious writings to the disk, e.g. > absolute ( not through dos ), writing to exe/com files etc. > Such a thing costs appr. the same as a software package, and it does not > depend on updates for new viruses. > So I want to ask: Is there any experience with such devices, thunderbyte > or others ? Is it worth the money ? Yes, I have some experience with it. It's really a very good product - the best one to my knowledge that realizes hardware virus protection (except the Big Red Switch ). Since it's reletively cheap, IMHO, it is worth the money, especially for a single user. I don't know if it is acceptable for companies that have to protect 100 or so PCs. I repeat, it provides an extremely good level of protection. However, if you are looking for the "ultimate protection", forget about it. There are alread viruses that are able to bypass it (without even knowing that it is present). And I can certainly see how more such viruses could be made. > From the documentation I have such a hardware protector looks like a > ultimate solution. Well, it isn't. It's just pretty good. The ultimate solution is the Big Red Switch. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Bontchev@Informatik.Uni-Hamburg.De Fachbereich Informatik - AGN Tel.:+49-40-54715-224, Fax: -246 Vogt-Koeln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 21 Oct 91 19:53:27 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: DIR II (Cluster) Virus (PC) vail@tegra.com (Johnathan Vail) writes: > My claim is that DIR 2 can legitimately be called a virus since it is > logically still part of another program and relies on a host program > being run in order to get an execution thread. Hmm, it's not that easy... Dir II does -not- attach itself to other programs. It only manipulates the system information (in this case - the directory entries), so that the files -seem- to begin with the virus. However, the boot sector and the companion viruses do similar things and we still call them viruses. I'd call it a virus - it is a virus, according to the Cohen definition and I'm happy with that. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Bontchev@Informatik.Uni-Hamburg.De Fachbereich Informatik - AGN Tel.:+49-40-54715-224, Fax: -246 Vogt-Koeln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 21 Oct 91 19:34:19 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: DIR II (Cluster) Virus (PC) grdo@botik.yaroslavl.su (Dmitry O. Gryaznov) writes: > >> listed in the structure above. The original is scrambled by using a > >> straight forward rotating xor encryption. Once an altered entry is > > > >It's not that "straight forward"... :-) It's not easily computable by > >hand and is based on a key, which tends to be different for different > >disks. The key depends on the DOS partition size, the number of > >sectors in a cluster, etc. > For anti-virus researches: this key (2 bytes) can be found at > displacement 033FH inside the virus body ("infected" cluster(s) on an > infected drive). Yeah, I know, since my disinfector uses it... :-) I meant that the - -method- is not easily computed by hand - try to rotate the key in your head as many times as the number of the current directory entry and to xor the result with the current contents of the last two of the 10 reserved bytes... :-) > >When a file, whose directory entry is infected is run on a clean > >system, the virus installs itself in memory, marking its current PSP > >as 0008 (as if it belongs to COMMAND.COM). MAPMEM will show that > 0008 mark in MCB means *NOT* COMMAND.COM but DOS itself. Yes, of course, that was a stupid mistake. > Not in the current but just in the *ROOT* and not to execute but just > to open. Maybe we have somewhat different versions of DIR II ? Very unprobable; the original spreads so fast that it just does not leave any place for other, competitive, variants... :-) You're right again - it's an open, not an execute. The execute instruction is a few bytes below and has the totally different purpose to execute the original program. So, the open only causes infection of the current directory on drive C:, not of the directories, listed in the PATH. > as "never been accessed". So DOS will re-read the root directory and > the virus will get a good chance to infect all .EXE and .COM (except > System) files in the root including COMMAND.COM. VolumeLabels and Directories are also excluded from infection. > 2) being run under DOS 5.0 the virus will "hang" a computer due > to a method it uses to call DOS. Yeah, because in DOS 5.0 the original INT 21h handler is no more at that offset in the DOS segment... However, the virus works perfectly on my copy of MS-DOS 5.00.224-beta... Reagrds, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Bontchev@Informatik.Uni-Hamburg.De Fachbereich Informatik - AGN Tel.:+49-40-54715-224, Fax: -246 Vogt-Koeln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: Tue, 22 Oct 91 17:23:00 +0300 >From: Y. Radai Subject: Re: Virus-writing course for teenagers Previously I quoted from the syllabus of a science-for-youth course: >> Assembler. In this language you'll be able to acquire tools for things >> which cannot be done in any other language, like: how to 'create >> viruses', how to write protection programs and how to crack them. and I commented as follows: >> Needless to say, the matter has been brought to the attention of the >>program director, and it is expected that the above applications will >>not actually get mentioned when the course is presented. It has also >>been suggested that part of each course be devoted to a discussion of >>computer offenses and rules of ethics. Rotan Hanrahan replies: >I don't see how avoiding mentioning such matters would avoid the >further proliferation of virus-like entities. To deny our most able >members of society the knowledge of such matters is a form of >censorship that, frankly, I cannot accept. .... > .... The most able people should be given the knowledge to tackle >this problem. I suggest that such courses in "virus construction" be >given. .... > .... It is time we changed too, and stopped trying to deny the >apparent reality which surrounds us. 1. Offering a course in creating viruses and cracking protection programs to any interested teenager is like offering a course in cracking safes or building bombs to any interested person. Do you advocate such courses too? Would you say that to deny "our most able members of society" the knowledge of safe-cracking and bomb-building is also "a form of censorship"?? Would that constitute denying the "apparent reality which surrounds us"? (Interesting phrase. Sounds to me more appropriate to Metaphysics-L than to Virus-L.) If you advocate such courses too, then you are in an extremely small mino- rity. If not, please state where you find a significant difference. 2. Such a course is even closer to Burger's book, which gives actual source code for viruses such as the Vienna virus. Today there are at least 42 variants of this virus and several similar viruses, and it's safe to assume that the overwhelming majority of them are the direct result of Burger's book. Please explain to us just what benefit has been derived from publication of the source code which could compen- sate for the damage which has been caused. From what I have written above, you might get the impression that I'm old-fashioned and unenlightened (not to mention in favor of "cen- sorship"). I could show, by several other examples, that this is not true, but I don't wish to start another debate (my original posting on the current subject was intended merely as an FYI). However, to disseminate the details of how to construct a virus is beyond the bounds of my liberalism. Whatever you imagine may be the supposed benefit to humanity of learning how to write a virus, I'm sure it's far smaller than the risk involved. >..... But denial is not the correct manner or civilized way in which >the problem should be tackled. To co-present the techniques of virus >construction with the ethical considerations is perhaps the most >desirable approach. .... > .... The medical community have established reasonable >ethical frameworks. Isn't it time the computer community did likewise? >Let's not hear any more about cencoring information about viri and >concentrate more on ensuring that the people who compose our community >are more responsible with the knowledge that is given to them. I find the comparison with ethics in the medical community almost amusing. The "community" we are dealing with here (and probably when talking of virus writers in general) is the community of youngsters, for whom virus writing is a challenge and an outlet for their mische- vious impulses. Those who are attracted to this course will be precisely those who say to themselves, "Gee, I've always wanted to write a virus, but I never knew how. Here's my chance to learn!" They may learn ethics too, but the urge to release a virus will be much greater in some cases. And even if only one of them actually does so, the damage may be much greater than the imagined benefit. Would you be willing to accept the responsibility if this happens? I wouldn't. Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI@HUJIVMS.BITNET RADAI@VMS.HUJI.AC.IL ------------------------------ Date: Tue, 22 Oct 91 17:12:13 +0000 >From: umbuhr03@ccu.umanitoba.ca (Kevin Buhr) Subject: Stamping out "Stoned" (was Hardware) (PC) tee@bullet.ecf.toronto.edu (TEE LUNS) writes: >An idea I've been toying with lately has been >to write a dummy partition table which Stoned will recognize as being >itself. This would defer infection. For $5 a shot, do you think >anybody would go for it? Wait! I've got a better idea. You should write a program that resides in the boot sector of floppy disks. When the user boots from disk, the program should go resident (possibly in the last couple of K of memory, which the user won't miss), and so the user won't always have to boot off the floppy, your program should place a copy of itself in the hard drive partition table saving the original in a safe place. Of course, your program would contain those vital first few bytes that Stoned uses to recognize itself so your hard drive would be immune. But there's still a problem! The user could boot off an infected floppy. Stoned wouldn't install itself on the hard drive (because it would find those special bytes in your program), but it would still go resident and start infecting the rest of the user's disks. The virus could still spread! For this reason, your program should also be sure to place a copy of itself on every floppy read or written (even if stoned got control of INT 13 AFTER your program, it would still think that the floppy had ALREADY been infected, because of the special signature in your program, and would not reinfect). With this measure, all the users floppies would be safe. There would be an additional fringe benefit, too. When the user passed disks he or she had used to friends, they could boot from the disks, installing the program on their own machines. Depending on the rate of prolifigation of your program, the Stoned virus could feasibly be stamped out in a matter of months! Of course, as already mentioned, the user of anti-viral products should know that they are resident. Therefore, your program should put a message on the screen on bootup. It wouldn't have to happen every time, since the user would only need to be occassionally reminded that your program was hard at work protecting him or her from the Stoned Virus. Once, say, every eight or so times, your program would display "YOUR COMPUTER IS protected from being STONED! ". Now I'd pay at LEAST $10 for a program like that! ;-> Kevin ------------------------------ Date: 22 Oct 91 13:13:41 -0400 >From: "David.M.Chess" Subject: re: SVC 5.0 (PC) > From: KADLOF@PLEARN.BITNET I tend to agree with Andrzej; the 5.0, at least, isn't really complex. Except for intercepting a few extra DOS calls in order to be stealthed, it's your typical resident virus. The style is the same rather "wordy" and awkward style as the SVC 3.1 (probably a self-taught author, hehe). > I do > not know for what reason virus do not infect files if the file name > contains characters 'MM' or 'MB' (maybe protection of author software). Most likely that's a quick-and-dirty way of avoiding infecting COMMAND.COM, IBMBIO.COM and IBMDOS.COM, the system files in IBM PC-DOS. DC ------------------------------ Date: Tue, 22 Oct 91 17:33:18 +0000 >From: umbuhr03@ccu.umanitoba.ca (Kevin Buhr) Subject: Re: Virus-writing course for teenagers werner@rascal.ics.utexas.edu (Werner Uhrig) writes: [Someone uncredited writes:] >> To co-present the techniques of virus construction with the ethical >> considerations is perhaps the most desirable approach. > then you also believe that giving everyone a gun and a course > in ethics (together with the practical training) would have > kept the nut in Killeen, Texas (just up the road from here) > from shooting all those people earlier this week? > (or make the world a safer place, in general?) :-(( The difference between guns and viri is that, while having practical knowledge about how guns fire bullets is of limited use when you have been shot, knowledge about how viri infect computers is very useful when your computer has been infected. It seems to me that there are far too many messages posted by desperate, internals-ignorant computer users on this list alone who have been infected by a virus and are trying to understand the difference between boot sector viri, EXE/COM viri, etc. The biggest problem with available methods of viral protection may be not that protection of type X is insufficient and we need protection of type Y (which is arguably true for many choices of X and Y) but that the vast majority of users know so little about how their computers work on the lowest level that they cannot be expected to know what prevention measures should be effective and how they might fail. On the other hand, I find the thought of heaping vast quantities of "how to" knowledge about viri on (possibly) immature and reckless teenage programmers more than a little scary. Some people would argue that the best way to show someone how to stop viri is to show them how to make viri. Because of the other dangers involved, this is probably not true. To use your gun analogy: if you want to teach someone how to protect themselves from bullets, you should concentrate on the effects of bullets on people (with and without bullet proof vests for example) and not on how to build a gun and make ammunition. Kevin ------------------------------ Date: 22 Oct 91 13:18:37 -0400 >From: "David.M.Chess" Subject: re: Hardware and software (was: Leopards) > From: turtle@darkside.com (Fred Waller) > when I said that it HAD worked, it was said that it > couldn't be useful against some still-unknown viruses, and now I'm > taken to task for not testing the system against such still > nonexistent viruses. ... :-) No, no one's faulting you for not *testing* against non-existent viruses. I was just pointing out that your test against existing viruses with you as the user wasn't good evidence for how the system would work against existing viruses on machines used by Real users, or against nonexistent-but-obviously-possible viruses (like database or spreadsheet infectors). It might work very well with real users, and database/spreadsheet/etc viruses might in fact not be something we need to worry about! But I don't think you can criticize people *too* strongly for not taking your word for it. *8) > It WAS proof, and it was indicative. Small-scale proof may > rightfully be extrapolated. But there can be differences of opinion about the extrapolation. You think it's clear that your test will extrapolate nicely into the real world. Others are more skeptical. An honest difference of opinion, that only time and the marketplace can judge... > But which other approaches are meant? > I don't know of any existing software method that is as effective > as hardware protection. Against existing viruses (and that's the context in which I was talking), there are *lots* of software methods (and products embodying them) that are just as effective as hardware: that is, they stop and/or detect all currently widespread viruses. > If one exists, it should be implemented > immediately everywhere! Aye, there's the rub! The reason that scanners (for instance) haven't stopped most virus problems is *not* that scanners don't work against viruses, I would claim. It's that most people don't use scanners. Every serious scanner works *perfectly* against the 1813 (Jerusalem) virus, for instance. Then why does it continue to spread? Because most PCs are not protected with (even something as trivial as) a scanner. I suspect that a good hardware solution would face the same problem? But again, market one, and we'll see if you get rich! *8) DC ------------------------------ Date: 22 Oct 91 13:32:15 -0400 >From: "David.M.Chess" Subject: re: Interpreted things >From: turtle@darkside.com (Fred Waller) Writing about viruses in databases and spreadsheets and other data-like things: > However, I also believe that it would be > much more difficult to make such virus as deceiving as our current > furtive ("stealth") viruses, or as difficult to detect. That's quite likely true. It's worth noting, though, that "stealth" techniques, while they sound snazzy in the press, and are fun to talk about at conferences, are *not* in fact a significant part of the virus problem. Most widespread viruses are not stealthed, most stealthed viruses are not widespread, and stealthed viruses are not in fact any more difficult to detect (at least from the end-user's viewpoint) than non-stealthed ones. Stealthing is a way that virus authors have extra fun (I guess), but as far as I know it hasn't really had any effect on the spread of viruses in the actual world. So even if an interpreter-virus couldn't be stealthed, all that that means is that it could only become as widespread as other non-stealthed viruses. Like the Jerusalem and the Stoned, for instance! *8) DC P.S. I have no strong opinions about how widespread a interpreter-virus could become; I don't know enough about the current, or especially the future, patterns of sharing of interpreter-things. I'm just pointing out that there's no particular evidence that stealth, or lack thereof, is relevant to the question... ------------------------------ Date: Wed, 23 Oct 91 10:20:00 +1300 >From: "Nick FitzGerald" Subject: Re: Help urgently needed for stoned virus (PC) phlux@athena.mit.edu (Peter H. Lemieux) writes: > Okay, if you know what you're doing you can try this. You need a copy > of Norton Utilities. Use the explore disk function to examine > ABSOLUTE sector 1. You should see the number 55 in the last byte of ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the sector if your disk is Stoned. Sorry, but WRONG! We continue to be a source of misinformation of the worst kind. Of all the Stoned infections I've seen, _NONE_ would be diagnosed by using this test. Most early versions of Stoned seem to overwrite the 55AA "bootable disk" flag _on floppies_ with two NULs (at least in my collection of Stoned variants), but leave these bytes intact in HD's MBR's - something to do with skipping over the partition table. Maybe the Stoned variant running rampant in Peter's neck of the woods does write 55 into the last byte, but it sure doesn't make anything like a definitive test. Whilst here, I'd like to add that while Peter's manual disinfection routine will work, it doesn't cover the situation of the possible corruption of the original boot-sector/MBR code. On a HD there is no easy solution if the original MBR has been corrupted (if you are in this situatiom, email me for detailed help), but with floppies there is. Cold boot the PC from a write-protected clean system disk. Use Nortons, PC-Tools or similar to read the boot sector from the floppy you booted from, swap the system diskette for an infectted diskette and get your disk editor to write the sector back to disk. One important caveat to this is that the disk you read the clean boot sector from _must_ be the same formatted density as the disks you are disinfecting. If you have high and low density infected disks, now that your system is clean you can safely format a disk in drive A: to get examples of clean boot sectors for both densities. - --------------------------------------------------------------------------- Nick FitzGerald, PC Applications Consultant, CSC, Uni of Canterbury, N.Z. Internet: n.fitzgerald@csc.canterbury.ac.nz Phone: (64)(3) 642-337 ------------------------------ Date: Mon, 21 Oct 91 15:18:10 -0700 >From: p1@arkham.wimsey.bc.ca (Rob Slade) Subject: Viral code association FUNPIV4.CVP 911020 Viral code "association" The simplest way for a viral program to avoid the detection that results from modifying the code of an existing program is not to modify the original program. This is an elementary solution, but would seem to have the drawback that, unless you do change the file in some way, the virus will never be called. There is a "solution" to this problem, and (if I may be allowed some enthusiasm for the concept, if not the reprehensible act) a rather elegant one at that. In a given situation, computers may be presented with a number of possible courses of action. The action taken first is decided by pre-programmed precedence. A number of programs may have very similar names, leading to potential confusion about which one is to be run in a given invocation. In the case of MS-DOS, for example, SET.COM, SET.EXE and SET.BAT are all "executable" files. In the normal course of events, any one could be invoked by giving the command "SET". If all three files exist, which one is to be run? The precedence of program invocation under MS-DOS is that .COM files are first, .EXE second and .BAT last. If three files of the same name do exist, this does not imply that all three will be run in that sequence, but rather that giving the command "SET" will always invoke only the SET.COM file. A certain class of viral programs; known variously as "companion", "spawning" or "precedence" viri; use this feature of the operating system. They "infect" a file with an .EXE extension simply by creating another file with the same name, but a .COM extension. Thus the .COM file is always executed in place of the original .EXE file. The original file remains unchanged, and no manner of "change detection" will tell you any different. (In order to further avoid detection the viral file will generally end with a very specific "call" to the original program, and the viral program has the "hidden" attribute set. In the Macintosh and other GUI operating systems, it is possible for a virus to take precendence by "overlaying" an existing icon with another which is either transparent or identical to the first.) Fortunately, companion viri are by no means perfect. For one thing, they are limited to those programs which are "lower" in the order of precedence. For another, the "hidden" attribute is relatively easy to overcome (particularly in MS-DOS), and an alphabetical listing of files will quickly turn up the anomaly of identical names. Of the antiviral packages tested so far, no change detector alerts to duplicate names, although many may alert the user by asking the user to "validate" a file that has been in use for some time. It will probably not be long, however, before this is a common feature. copyright Robert M. Slade, 1991 FUNPIV4.CVP 911020 ============= Vancouver p1@arkham.wimsey.bc.ca | "Power users think Institute for Robert_Slade@mtsg.sfu.ca | 'Your PC is now Research into CyberStore | Stoned' is part of User (Datapac 3020 8530 1030)| the DOS copyright Security Canada V7K 2G6 | line." R. Murnane ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 198] ****************************************** Downloaded From P-80 International Information Systems 304-744-2253