borton@uva.UUCP (Chris Borton) (12/01/88)
In article <223@sunset.MATH.UCLA.EDU> hgw@math.ucla.edu (Harold Wong) writes: >In article <garbage #> ll12+@andrew.cmu.edu (Laura Ann Lemay) writes: >> >>Kill Virus is equipped with a foil for the nVIR virus, which will keep it >>from getting infected. However, since the resource is called "nVIR", >>it trips up interferon and other such programs. >> >>Kill virus is currently the best program for getting rid of nVIR. THE >>PROGRAM IS ***NOT*** infected!!!! >> >Does KillVirus protect all applications or just those who were infected? >With applications (pd and others) going through and being copied onto my >drive how will I know if the real (the bad one) nVIR shows up? It might start >infecting other applications that did not get KillVirus protection. > >It seems to me that KillVirus will add confusion to this virus problem There seems to be plenty of confusion around about nVIR, which is understandable. I'll summarize this as I know it; please add corrections if necessary (but only if you REALLY know--discuss it otherwise) and spread this information around as widely as possible to avoid this confusion. nVIR has a built-in inhibitor, probably so that the originator wouldn't infect his whole system as well. The virus checks for the existence of the resource 'nVIR 10' in the System file, and if it's there then it doesn't infect anything. The KillVirus INIT from Matthias Urlichs is an INIT that installs this probitor resource into the System file. [Programmer note: given the confusion this now causes, it might have been more appropriate to build that resource on the fly]. Hence, with the KillVirus INIT your system will be immune to attacks of nVIR and further spreading of nVIR. To my knowledge, KillVirus does NOT do anything to applications at all. Hence, if you have an infected application, it will be benign on your KillVirus- protected system, but if you give it to your friend who is not protected, then he will become infected. The best solution I know of: 1) boot from locked positively-healthy system 2) Run "Vaccination" on ALL programs you have. This will remove the virus if it exists, preventing further spread. 3) Replace all Systems with a known good System. If this is too painful, it can be done with ResEdit hacking, but you'd better know what you're doing. Just remove all 7 nVIR resources and INIT 32. 4) Replace the Finder and DA Handler, as the original version of Vaccination did not recognize these and they infect. 5) Keep KillVirus, VirusWarningINIT, and/or Vaccine in your system folder. The differences: KillVirus: defends attacks, will not allow spread. Installs benign nVIR 10 resource in System file. Does not, I believe, alert you when an attack has occurred. VirusWarningINIT: emits a series of beeps when an attack (attempt at infection) has occurred. Does NOT prevent the infection, but you will know about it and hence can immediately kill it. Vaccine: will cause system bomb when nVIR attacks. This is because it is trying to use a dialog/menubar at a time when that isn't allowed. Thus, if you have a consistent bomb under MultiFinder with a program you know works, immediately check it for nVIR. I hope this clarifies a few things. There are plenty of items that might have been done much more clearly (the naming of these things, for one) but they usually originate in a crisis under duress and time pressure. The best prevention overall is user education -- a little bit can go a long way. [Personal note: unfortunately the media could use some as well in order to prevent wild rumors, spreading false information and blind fear.] [[Oh a sample? CNN during the InterNet Worm crisis: 4:12 reporter: "...but the virus apparently does not do any damage to data." 4:25 anchorperson: "stay tuned, in 10 minutes another report on the data-devouring virus attacking computers all over the country." ]] -cbb -- Chris Borton borton%uva@mcvax.{nl,bitnet,uucp} Rotary Scholar, University of Amsterdam CS
isle@eleazar.dartmouth.edu (Ken Hancock) (12/03/88)
In article <579@uva.UUCP> borton@uva.UUCP (Chris Borton) writes: >In article <223@sunset.MATH.UCLA.EDU> hgw@math.ucla.edu (Harold Wong) writes: >>In article <garbage #> ll12+@andrew.cmu.edu (Laura Ann Lemay) writes: >nVIR has a built-in inhibitor, probably so that the originator wouldn't >infect his whole system as well. The virus checks for the existence of the >resource 'nVIR 10' in the System file, and if it's there then it doesn't infect >anything. > >The KillVirus INIT from Matthias Urlichs is an INIT that installs this >probitor resource into the System file. [Programmer note: given the confusion >this now causes, it might have been more appropriate to build that resource on >the fly]. Hence, with the KillVirus INIT your system will be immune to >attacks of nVIR and further spreading of nVIR. > >To my knowledge, KillVirus does NOT do anything to applications at all. Hence, >if you have an infected application, it will be benign on your KillVirus- >protected system, but if you give it to your friend who is not protected, then >he will become infected. According to the documentation, KillVirus DOES remove nVIR from any infected application any time an infected application is launched. As far as creating the nVIR on the fly, that won't solve any problems. Everyone will still see that the system is infected with nVIR. Seeing that so many people are so hyped up about viruses, it would seem that instead of just throwing all these things in the system folder and then jumping up and down yelling "It's infected", they'd take the time to first find out what does what and stop all this blown out of proportion panicing. Ken Ken Hancock '90 | BITNET/UUCP/ Personal Computing Ctr Consultant | INTERNET: isle@eleazar.dartmouth.edu -----------------------------------+---------------------------------------- DISCLAIMER? I don't get paid enough to worry about disclaimers.
michael@taniwha.UUCP (Michael Hamel) (12/04/88)
In article <579@uva.UUCP> borton@uva.UUCP (Chris Borton) writes: >nVIR has a built-in inhibitor, probably so that the originator wouldn't >infect his whole system as well. The virus checks for the existence of the >resource 'nVIR 10' in the System file, and if it's there then it doesn't infect >anything. Actually it checks for INIT 32 as well, and my own anti-nVIR program, AntiPan, installs this into systems to immunise them instead of nVIR 10 because of the likely confusion. AntiPan exterminates nVIR from the system files and all applications on whatever volume you point it at. It also requires you to reboot if nVIR is resident in the system heap. Someone (I'm afraid I don't recall who) posted a remark recently saying that AntiPan sometimes failed. I tried to mail him, but I assume my mail got lost as I have had no reply. I would be most interested in any known cases of failure, as I know of none and will fix any bugs when I get back to the sources in New Zealand next week... -- "In challenging a kzin, a simple scream of rage is sufficient. You scream and you leap." Michael Hamel ..!{unisoft|mtxinu}!taniwha!michael
brecher@well.UUCP (Steve Brecher) (12/07/88)
In article <579@uva.UUCP>, borton@uva.UUCP (Chris Borton) writes: > The virus checks for the existence of the resource 'nVIR 10' in the System > file, and if it's there then it doesn't infect anything. Actually, nVIR checks for nVIR 10 by calling GetResource. Therefore, Suitcase II users can gain the inhibition effect by creating a file containing an nVIR 10 resource and keeping the file open with Suitcase II. I am the author of Suitcase II. -- brecher@well.UUCP (Steve Brecher)
lbaum@bcsaic.UUCP (Larry Baum) (12/08/88)
In article <226@taniwha.UUCP. michael@taniwha.UUCP (Michael Hamel) writes:
.
.AntiPan exterminates nVIR from the system files and all applications
.on whatever volume you point it at. It also requires you to
.reboot if nVIR is resident in the system heap. Someone (I'm afraid I
.don't recall who) posted a remark recently saying that AntiPan sometimes
.failed. I tried to mail him, but I assume my mail got lost as I have had no
.reply. I would be most interested in any known cases of failure, as I know
.of none and will fix any bugs when I get back to the sources in New Zealand
.next week...
As it happened we discovered nVIR on our system just as AntiPan arrived. It was
extemely effective but it did fail on a couple of files. All but one of these
were Lightspeed C applications and Lightspeed C itself. We used Virus Detective
on those and that seems to have fixed the problem. Someone has told me that LSC
has nVIR immunity built in (with dummy nVIR resources maybe?), so that might be
the reason. The only other interesting thing that happened is that even though
AntiPan reported no problem with DA Handler (i.e. it either claimed to have
diinfected it or found it clean), Virus Detective still found nVIR when we ran it
subsequent to using AntiPan.
LSBmichael@taniwha.UUCP (Michael Hamel) (12/11/88)
In article <9062@bcsaic.UUCP> lbaum@bcsaic.UUCP (Larry Baum) writes: >As it happened we discovered nVIR on our system just as AntiPan arrived. It was >extemely effective but it did fail on a couple of files. All but one of these >were Lightspeed C applications and Lightspeed C itself. Ha! We haven't got LS C at Otago, it must be doing something interesting. Thank you, I will fix this. > The only other interesting thing that happened is that even though >AntiPan reported no problem with DA Handler (i.e. it either claimed to have >diinfected it or found it clean), Virus Detective still found nVIR when we ran it >subsequent to using AntiPan. Damn. AntiPan checks files with a type of 'APPL' or a creator of 'MACS'. I thought this covered what nVIR could get into, but DA Handler must be an exception. I will enlarge its range. Thankyou very much, this is exactly the kind of feedback I need... -- Where now are those who in times past have opposed the Group of Seventeen? Michael Hamel University of Otago ..!ucbvax!michael@otago.ac.nz