VIRUS-L Digest Monday, 16 Sep 1991 Volume 4 : Issue 161 Today's Topics: Encrypted search strings Scanners Virus Simulator Virus Simulator NAV 1.5 + Desqview (PC) IBM Anti-Virus Miscellany (PC) INFO PLEASE: self-replicating-systems Re: Preventing boot from floppy - problem with Int 13 from TSR (PC) FAT Infection (PC) Name that virus! (PC) Virus Simulator Stoned virus Help needed to cure Joshi virus (PC) 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: Tue, 10 Sep 91 22:10:35 -0700 >From: turtle@darkside.com (Fred Waller) Subject: Encrypted search strings frisk@rhi.hi.is (Fridrik Skulason) writes: > There are several products which only rely on published search > strings, but they are not very secure - virus writers have > access to the same search patterns and they often modify their > viruses so they will not be detected by those patterns. One sees this assertion often, and just as often I wondered how true it really is. If we consider the 500 or so commonly-recognized main types, the immense majority are either "originals" or coded "variations" in which the code derives from a previous virus in an evolutionary manner. When a new virus appears, the search strings determined for previous version(s) are frequently useless, and new ones become necessary. A virus writer has no need to fool around with the previous virus code to specifically "alter" only those portions that are used as search strings by the scanners - simply rewriting his code slightly, without ever knowing the precise search string used by any scanner, is enough. All the search-string encryption in the world doesn't affect him one bit. Yes, there _are_ a few viruses which have been coarsely altered so that only that portion which some virus scanner uses as a search string was changed. But these are in the minority and their number does not provide credence to the theory that encrypting search strings for this purpose is a practical necessity. As a proof of this, IBM has never encrypted the great many search strings used in their VIRSCAN product. Perhaps Dave Chess could tell us if, in their wide experience, there have been many _actual_ instances of viruses intentionally changed to avoid detection by their string scanner? My own feeling is that string encryption is a competitive tactic and is not related to user or program security. Its purpose is to prevent competitors from learning those precious search strings and using them in their _own_ scanners... At least one publisher of scanners has "copyrighted" (?!), and then "licensed" his search strings to others. > Yes, if it indeed uses the patterns included in the virus > simulator - but how can you know if it does ? Very simply: if the scanner thinks it has "found" a virus, then obviously its search string is the same. > I also maintain that it is advisable to use a couple of scanners, > which use different set of patterns (or a single scanner using > two different sets), as it increases the chances of detecting > real-world viruses. Hmmm... no, this doesn't help in the case of the Virus Simulator. The Virus Simulator seems to have anticipated this: it inserts _several_ search strings in each one of its fake viruses! So various scanners, using different search strings, will each "find" a "virus" in its files. ------------------------------ Date: Tue, 10 Sep 91 22:03:02 -0700 >From: turtle@darkside.com (Fred Waller) Subject: Scanners Writes Bill Arnold of IBM: > I rarely see complaints that virus scanning is a non-specific > approach. It aims at being virus-specific, but the general public doesn't realize just how non-specific a procedure it is to look for a few bytes of code and, on having found them, announce that "this file is infected with the ABC virus". There may exist reasonable correlation between a given virus and a given chosen search string, but as a general method, such comparison is very non-specific. No search string should be assumed to exist only in a virus, which the scanners assume. Rosenthal's Virus Simulator proves just that, if proof was ever needed. > Seriously, the reason that vendors use identification strings is > that it is *easy*; id (or search) strings are easy to extract, > easy to transmit and share, it's easy to write efficient scanners > for search strings, etc. Search strings also happen to be compact > (at least relative to the size of most of the viruses that they > detect). Those are very practical reasons. I have no trouble recognizing that. > Precise identification doesn't require much more space per > virus, but it does require a complete analysis of each virus > to be reliable. But why do we need "precise identification"? As a user, I don't much care whether the virus infecting my system is the "Mpghffhmx Virus, version 1-A" or version 1-B, five bytes different. Nor should anyone. Yet, the entire antivirus industry was based from the beginning on the idea that it was somehow indispensable to "name" and "identify" each "virus". To a large extent, the industry still carries that "mission". The idea that defense against computer viruses must include "precise identification" is rather peculiar and unsatisfactory. In this sense, hardware protection, such as has been suggested here for write-protecting hard disks, would probably be much simpler, less expensive, more durable and perhaps far more effective than any software approach. I often wonder if we shouldn't credit the virus-naming penchant of antivirus publishers (and the attendant publicity), as well as the quest for "precise identification", with being at least partially responsible for the extraordinary proliferation of new viruses, and the concomitant increase in virus incidents worldwide. I'm not referring to any possible collusion, or virus-production, by anti- virus entities, but to the obvious invitation that "orthodox" virus authors must feel to rise to the challenge and produce new creations that could trick a given scanner, if only ephemerally. > The virus needs to be mapped, the constant extents in the > virus need to be determined, a degarbler functionally identical > to the virus degarbler may need to be written, etc. If I were writing such software, I would seldom bother composing dergablers. Each encrypted virus has its own degarbler built in. Why not just use that? It usually works rather well... . Sliding-window encryptors do not respond well, but the rest do. > There's certainly room for improvement; search strings are > a rather primitive identification mechanism. Yes, and assuming that "identification" is what is really needed. As mentioned, I don't think it matters what the peculiar version and subversion (!) of a virus are. I only want to prevent it from invading my system and from multiplying on it. That's all *any* user wants. In practice, virus scanners have not accomplished that. In fact, some contend that scanners have accomplished just the opposite. Now, Rosenthal graphically demonstrates how fallible scanners really are. So, from both theoretical and practical viewpoints, virus scanning is not useful. And from what I've seen so far, the "heuristic virus analyzers" are even worse than the scanners in the number of false alarms they produce. ------------------------------ Date: Tue, 10 Sep 91 22:13:05 -0700 >From: turtle@darkside.com (Fred Waller) Subject: Virus Simulator William Walker (walker@aedc-vax.af.mil) tried to summarize pro and con postings made on the subject of Rosenthal Engineering's Virus Simulator. Among other things, he quoted Tim Martin saying: "The Virus Simulator... will simply generate false security and false paranoia..." Well, it could also be said that the virus scanners are the ones generating false security, and the Virus Simulator is exploding that. The Virus Simulator may actually help remove some of that false security. Regarding "false paranoia", all paranoia is, by definition, false. > It seems to me that the real basis for the disagreements about > the Virus Simulator are its effects in the real world. I would say that the cause for much of the criticism (and some of the abuse) heaped on Rosenthal is that the Virus Simulator publicly exposes a known but generally-tacit weakness of all the string scanners. Mostly, what we are seeing is a reaction by software publishers at having a weakness of their products so openly exposed. That may not have been Rosenthal's purpose, but it's the effect that the software publishers are seeing and obviously disliking, and reacting to. > But one subject which both sides have missed is cleanup. > > If the "bait" files contain only the signatures, then how > can one test the removal capabilities of an anti-virus package? > You can't. I think Rosenthal never said that his program could test the _removal_ capabilities of virus scanners. It would have been nice had it been able to, but it isn't. Many scanners have rather poor removal capabilities anyway. Mostly, they are meant to act as detectors. Rosenthal's Virus Simulator was apparently meant to test their ability as detectors, not removers. Frankly, it doesn't really test the scanners in quite the way Rosenthal said. What it does, and rather well, is expose a glaring deficiency of such software, and shows that the scanners aren't nearly as reliable as their publishers might have prospective buyers believe. Rosenthal's Virus Simulator does this: it shows that virus scanners can be made to produce false alarms at the incredible rate of 100%!!! Of course the antivirus publishers have no kind words for it. Would anyone expect otherwise? > Some comments have dealt with the problems of unscrupulous > people using the simulator to leave simulated viri lying around. Yes, but frankly, unscrupulous people don't need to leave _simulated_ viruses "lying around"; unscrupulous people put _real_ viruses in your system. In any case, remember that the majority of computer virus `infections' are not the work of unscrupulous people: most of them are unintentional. Only the first release, or a few after that, are probably intentional. That, after all, is the nature of computer viruses. > Patricia Hoffman's VSUM document is an excellent starting point. I have to disagree. While Hoffman's VSUMxx document makes colorful occasional reading, it's not a serious substitute to testing scanners to see whether they actually do or do not detect the viruses they *claim* to detect. Hoffman's VSUMxx is heavily biased in favor of one vendor (McAfee Associates), and has often neglected to even mention up-to-date competitive products, as others have noticed here. Hoffman's VSUMxx contains many errors of fact; even after being publicly pointed out, they have remained uncorrected. In any case, the VSUMxx document was never intended as a competitive evaluation. And it couldn't test a given scanner in every particular environment that every prospective buyer might wish to test the scanner in. No, I don't think there is a substitute for individual testing. Those prospective buyers who wish to conduct their own tests should be able to do so. Unfortunately, they can't, because the necessary large collections of test virus samples are not available to them for that purpose. Nor is there a truly independent testing organization; most of the suggested ones consist, one way or another, of the same anti-virus industry members that produce the software to start with. The problem of testing antivirus software is not trivial. It is a very real one and one that is bound to become worse as time goes on. Even assuming that all vendors agree on a standardized testing protocol and agent, it would still be desirable for the larger prospective buyers to conduct their own testing and evaluation. Finally: > People who are tasked with finding and removing viri do not > like wasting time tracking fake viri It shouldn't be necessary to `track' them down at all. Fake viruses do not self-reproduce! If one is found, it's likely to stay in one place. But I think the problem derives not so much from the presence of the Virus Simulator as from inadequacies of the scanners, which are unable to tell a fake virus from a real one. The main task of a virus scanner is, by definition, to identify viruses. They fail at it, rather miserably, as the Virus Simulator demonstrates. ------------------------------ Date: Tue, 10 Sep 91 22:07:10 -0700 >From: turtle@darkside.com (Fred Waller) Subject: Virus Simulator In answer to a post, bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Vladimirov Bontchev), writes: > Yes, indeed, and this is a quite old and well-known problem. It > is still unsolved, and I don't see it solved in the near future. Perhaps the best way to solve it is to move away from string scanning as a viral "detection" technique. The assumption that, in order to *stop* a virus one needs to *identify* it is, in my view, an incorrect assumption. > And the notorious virus simulator is certainly not a step towards > the solution. It just shows that simple scanning may cause false > positives (something that everybody knows... or doesn't?). It's a "step" in the sense that it will make a lot of people aware of the inadequacy of string scanning as a virus-detection technique. Not just the few experts (who already know that), but the public. String scanning _is_ useful at times, but it suffers from so many conceptual problems that it shouldn't have been instituted as a universal antivirus method. Yet, it was. Vesselin Vladimirov quoted me: > > instead of complaining about its inadequacy, we might have > > addressed the reason for the appearance of such software. > > I fear we are not doing that at all, but should. And replied: > Once again? But wasn't addressed it wide enough? At least I've > seen this problem addressed in most proffessional journals that > test anti-virus products... Virus Bulletin comes to mind at once. We shouldn't expect evryone to read the same trade publications... :-) But no, I don't think it was addressed. I certainly haven't seen anything similar to the Virus Simulator being announced before. Did I miss something? If I did, my apologies. However, I was referring specifically to the rather flaming response by Fridrik Skulason. Instead of admitting the *reason* why Rosenthal saw an opportunity to produce his Virus Simulator, Frisk was simply complaining about how bad the program had to be. It's bothersome that some members of the virus/antivirus business seem so prone to censoring or abusing others... An occupational trait? :-). Rosenthal Engineering made a civil, straightforward announcement here, not very different from the announcements that others make of *their* software. Imagine the appearance of things if, every time Frisk announces a new version of F-PROT, Rosenthal were to launch into a stream of abuse criticizing how F-PROT was a useless program because it could not remove certain viruses (which it can't), or gave incorrect identifications (which it gives) or otherwise caused problems to its users (which it does). > It doesn't "test" anything. It just fools some (stupid) scanners > and that's all. Yes, I am in total agreement with the above. And shows how easy it is to fool them. How easy it has *always* been to fool them. > It's normal for SCANV .... IBM's VIRSCAN, TBSCAN, HTSCAN - all > these are not virus scanners - Hmmm... could've fooled me, and many other people who call them "virus scanners", including their publishers. I wonder why they all include the word "scan" in their names? :-) > ...they are pattern matching engines that verify the presence > of a pattern (possibly including wildcards) in the files. Last I heard such "pattern matching engines" were widely called "virus scanners"... but I'm not adverse to a change of name... If they are to be called something else now, it's fine with me. > However, F-Prot and Dr. Solomon's Anti-virus Toolkit are anti- > virus tools, that also cerefully check whether a file that is > found to contain a virus signature is really infected. If they are reliable and do not produce false alarms, like the scanners do, then they will be more useful. We'll have to wait and see. > Especially F-Prot probably says that the file is "Possibly > infected" or "seems to be infected by a new variant of..." > and refuses to disinfect the file. Check it again, and you'll > see that I'm right. I imagine that by "F-PROT" what is meant here is "F-FCHK", the signature-scanning program in the pre-2.0 F-PROT package. Or its derivative, the scanning facility built into F-PROT 2.0. Yes, both will indeed give two levels of "identification", one `possible' and one `certain', depending on whether it finds only one or both of the *two* signature strings it uses for each virus. No matter, in both cases, the process is similar and the program is equally easy to fool into thinking it has found a virus when, in reality, there are only a few innocent, chosen bytes there. I imagine such a two-step process would be the next challenge for Rosenthal's Virus Simulator. Actually, it's easy to make a two-string fake virus file that totally fools F-FCHK. Maybe even cause it to try to "disinfect" the "virus"? As far as the "heuristic virus analyzer" built into F-PROT v2.0, that's another matter: it doesn't use scanning strings at all so Rosenthal's Virus Simulator files have no effect on it. But let us not rejoice too soon: Frisk's "heuristic virus analyzer" is *extremely* prone to false alarms, much more so than his string scanner. In fact, it produces more false alarms than any other virus detector I've tested. It would be even easier to make fake viruses to cause it to trigger, in the same way that the fake viruses cause false alarms with string scanning. Already many of my utilities caused it to issue false alarms. Sorry, but at this stage of the art, I see no advantage in using these "heuristic virus analyzers" either. One thing that is rather unpleasant is that the author takes the liberty of judging what somebody else's program should or should not be coded like: if it finds something it dislikes, it puts out a message that "it is a badly-written program". What gall! Rosenthal's Virus Simulator is "useless"; the utilities many cherish are "badly written"; only "his kind" of programs are "well-written", etc. I really think such attitude ought to be controlled. As an example of *actually* successful antivirus software, I just downloaded from the McAfee BBS a program called SECURE, by Mark Washburn. This is an excellent Interrupt monitor which performs almost flawlessly and succeeds in stopping every known virus from multiplying. Now, I really don't know whether it satisfies everyone's pet theoretical considerations or not, but I do know that it *works* extremely well and that it stops every virus I've tried on it. SECURE never bothers to identify any given virus, it simply stops it from replicating. It's very difficult to cause SECURE to produce false alarms, even intentionally. It doesn't interfere with normal program operation. It uses but 4kB of RAM. I call *that* successful antivirus software. And, of course, it remains totally unaffected by Rosenthal's Virus Simulator. > Oh, well, but this is rather well known... Do we need a special program that demonstrates it? At the general-public level, yes! Some of us might not be overly impressed with the Virus Simulator, but the majority of lay users have been `trained' to believe that virus scanners are trustworthy. Rosenthal's Virus Simulator provides a rude awakening from such dangerous dreams. > This only means that you are unable to understand the appropriate > theory and need such childish example. Well, maybe you're right > after all - there certainly exist other people that will need it > too... > > What is remarkable is the fact that you consider it as some kind > of wonder... :-) Yes, there are many people who will be interested in the Virus Simulator. But I protest again at the seeming ease with which we seem to be willing to slight and demean each other here... why stoop to such expressions at all? _Ad hominem_ attacks are odious and achieve nothing except exacerbate the ill will of people. They don't prove anything; they don't disprove anything. They only make people mad at each other. What for? > Yes. All this means that Rosenthal has fished these signatures > from the different scanners. Does it need to mean anything else? So he fished them out. Good place to get them. Many scanners use strings that were also determined by someone else. Apparently, so does Rosenthal. > Therefore, they have been provided by the scanners' authors This depends on how one defines the word "provided". And if they were provided, then Frisk was mistaken in suggesting that they weren't. In either case, it's not relevant whether they were or not. ------------------------------ Date: Wed, 11 Sep 91 09:17:22 +0000 >From: edc242u@monu6.cc.monash.edu.au (n. michelis) Subject: NAV 1.5 + Desqview (PC) When I am running Norton Antivirus and using desqview, I have encountered a problem. NAV only gives a warning beep when an innoculated file has been altered. It doesn't display the usual warning box. This is really annoying as I don't know inside DV if it was activated because of a virus or because of an innoculated file being edited. I am running DV 2.34 and Qemm 5.13 and DOS 5. . I am wondering if anyone else has encountered this problem. P.S. I have contacted SYMANTEC AUSTRALIA and they also find the same problem. Thanks !!! ------------------------------ Date: 11 Sep 91 11:15:01 -0400 >From: "David.M.Chess" Subject: IBM Anti-Virus Miscellany (PC) A couple random points about the IBM Anti-Virus Product: - The announcements I've posted here apply most to the U.S.. Other countries' IBMs make their own decisions about when and how to release any given product. If you're outside the U.S., contact your local IBM representative for information. In particular, the fact the IBM U.K. is not currently selling the IBM Anti-Virus Product does *not* mean that it no longer exists; you just can't get it from IBM U.K. at the moment. That was a local country decision, and doesn't affect any other countries. It's still available in the U.S., for instance. - The $35 price (in the U.S.) is for an "enterprise" license. That means that if you're a business, you pay $35 total for as many copies as your business (or university, or whatever) needs to make for the use of employees. DC P.S. I'll be on vacation starting on Friday, and back on the 25th or so. Just in case anyone's trying to get hold of me. Have a non-annoying Friday the 13th! *8) ------------------------------ Date: 12 Sep 91 01:48:41 +0000 >From: anthony@eeyore.cs.adelaide.edu.au (Anthony Dunstan) Subject: INFO PLEASE: self-replicating-systems Hello, I have a friend who is interested in self replicating systems. Is there anybody out there who could give us some information? I know there is an ftp site with such information, but I don't know the address. Any help would be appreciated. Thanks, Anthony. Please e-mail me directly (address shown below). - ----------------------------------------------------------------------------- | Anthony Dunstan | Apple Consortium & Sun Shop - Adelaide University | | A Macintosh CyberMan | anthony@cs.adelaide.edu.au | - ----------------------------------------------------------------------------- ------------------------------ Date: Thu, 12 Sep 91 01:37:56 +0000 >From: userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) Subject: Re: Preventing boot from floppy - problem with Int 13 from TSR (PC) flaps@dgp.toronto.edu (Alan J Rosenthal) writes: >padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) writes: >> 1: Trap cntrl-alt-del sequence >> 2: Check for floppy in drive A: >> 3: Disallow boot if floppy in drive > >Won't this leave a window during which the user can insert a floppy >disk? Insert floppy but leave the drive door open, press >control-alt-delete, close the door. I may have missed the context of this thread, but if the system protected this way allows any kind of programming, execution of .COM or .EXE files from A:, or access to DEBUG, they can circumvent this trap with: JMP FFFF:0000. - -------------------+------------------------------------------- Al Dunbar | Edmonton, Alberta | Disclaimer: "not much better than CANADA | datclaimer" - -------------------+------------------------------------------- ------------------------------ Date: Thu, 12 Sep 91 11:17:58 +0000 >From: HTORRES@HELENA.HQ.NASA.GOV Subject: FAT Infection (PC) I'd like to know if there is a possibility of a virus infection into the file alocation table. I understand that boot sector viruses are known but I have not heard about a FAT virus. If this is true, will it infect the two FATs what a re thepossibilities of losing the index. What is the repair procedure to fix the FAT if an infection occurs? Please reply ASAP. ------------------------------ Date: 12 Sep 91 15:43:22 +0000 >From: lindwall@beowulf.ucsd.edu (John Lindwall) Subject: Name that virus! (PC) An associate of mine suspects that he is infected with a PC virus. He has a program which is 19K in size (a .EXE file). When this program is executed, DOS complains that there is not enough memory and it exits. Upon re-examining the file size, it can be seen seen to have magically grown to 23K! Are there any virus that fit these symptoms? - -- John Lindwall lindwall@cs.ucsd.edu "Oh look at me! I'm all flooby! I'll be a son of a gun!" -- Flaming Carrot ------------------------------ Date: 12 Sep 91 04:00:37 +0000 >From: p4tustin!ofa123.fidonet.org!Ray.Mann@uunet.uu.net (Ray Mann) Subject: Virus Simulator bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes in response to a post by Doren Rosenthal on his Virus Simulator: >I can't believe that F-Fchk has reported your simulation file to >be INFECTED by any virus. Please, check again. Doesn't it report >"possibly infected", "new variant of..", etc.? Does it try to >disinfect you file? And does it succeed? No, I definitvely can't >believe that. I run that test using FPROT 1.16 and the program reported many of the fake viruses to be "possible infections". It also reported some of them to be "Infected" for sure, with things like the MG virus, the 600 virus, the Telecom virus, etc. Not all the fake viruses triggered FPROT but about 50% did. Only about 10% were determined to be certain infections. >First of all, they do not need any virus simulator (or live >viruses), in order to test the speed and easy of use of any >anti-virus product. Second, the speed cannot be tested on ONE file >only; you need huge amount of files to obtain a reliable average >number. Third, any user (not only the administrators) is able to >test the speed and easy of use of ANY product (including the >anti-virus ones), WITHOUT having any kind of viruses - live or >simulated. Let's remember that speed and ease of use are not what we buy scanners for - we buy them to detect viruses. Ease of use and scanning speed are important, but they aren't the primary function of a scanner. Incidence of false alarms is also an important consideration. Any test that limits itself to speed and ease is grossly inadequate. By the way, Rosenthal's virus simulator seems to have disclosed a real weakness in the area of false alarms... >>Especially when a collection of hundreds of real >>viruses is not available > >This is a serious and yet unsolved problem, indeed. My oppinion >is that such collection should be a vailable at some central >organization (VTC?, CERT?, NIST?, NCSC?), and this organization >should perform an objective test of different anti-virus products. It might be difficult to find any organization with a large collection of viruses that is not somehow part of the AV community and, therefore, potentially biased. If a government agency were to do the testing, it'd be viewed as impartial, but I think it's not a realizable hope. An AV consortium such as the NCSA has been trying to setup will probably run into difficulties. If they test severely and impartially, there'll only be one winner and many losers. The losers will see ample reason to abandon the consortiom, since it's hurting them. If they test less severely, there'll be many "winners" and a loser or two but candidate buyers will no doubt see through it and refuse to take the test results seriously. Regardless of any centralized tests, large organizations will probably insist on running their own testing, as they've usually done in the past with many other products. > The feedback that you received in this forum (which I >consider as highly professional) seems overwhelmingly negative... I'm not so sure that the Virus Simulator is such a bad idea. It's no panacea, and it doesn't REALLY test anything, but it offers some interesting possibilities. For example, it could be useful in training sessions, where the fake viruses could be used by instructors to teach scanning procedures, etc. without fear of contamination with real viruses. Sure, we'll see a number of pranks, etc., but I'd rather have pranksters using fake viruses than real ones! - --- Opus-CBCS 1.14 * Origin: Universal Electronics, Inc. [714 939-1041] (1:103/208.0) - -- Ray Mann Internet: Ray.Mann@ofa123.fidonet.org Compuserve: >internet:Ray.Mann@ofa123.fidonet.org ------------------------------ Date: 13 Sep 91 07:00:17 +0000 >From: psgrbbc@prism.gatech.edu (Brian Cooper) Subject: Stoned virus I just started checking my system for viruses. I've been using McAfee's SCAN. My system checked out fine. I used the /a and /m options so all the files were checked as well as the boot sector and memory. I then started scanning some old floppies that I had. I found about a dozen floppies containing the Stoned Virus in the boot sector. Since my system was clean, I just pitched the floppies; none of the programs on the floppies were important nor were they on my hard disk. What does it mean when a virus is in the boot sector of a floppy disk? How could such a virus become active when there are no files executable files containing the virus? Thanks in advance. Brian Cooper - -- Brian Cooper Georgia Institute of Technology, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!psgrbbc Internet: psgrbbc@prism.gatech.edu ------------------------------ Date: 15 Sep 91 19:50:31 +0000 >From: ellard@bbn.com (Dan Ellard) Subject: Help needed to cure Joshi virus (PC) A IBM PC clone at my father's office has becomre infected with a virus that McAfee's virus scanner identifies as 'Joshi'. The scanner seems to take care of the virus, but it always seems to pop up again within a short time. The principal symptom of the virus (so far, at least) is that it has become impossible to format disks-- the format operation just never finishes. It doesn't appear that any of the data on the hard drive has been corrupted (or at least not enough to easily notice) but the disk operations seem slower than usual. My questions are: 1. What does he have to do to shake this virus? He's using the most up to date McAfee product, which was highly recommended, but doesn't seem to be up to the task. 2. Does this virus corrupt data, or do anything else malicious? 3. Is this virus very contagious, and how long is the dormant period? As soon as the virus was detected, the machine was isolated, but since they exchange data diskettes often among dozens of machines, he's wondering if he is going to lose ALL his PCs sometime in the future. Please forgive my lack of details-- I can try to get more specifics if necessary. - -Dan Computer science: it's only fun until someone loses an eye. ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 161] ****************************************** Downloaded From P-80 International Information Systems 304-744-2253