Glenna
Glen...@ix.netcom.com
Interesting question. I don't know of any incompatibilities between them.
There are some good generic capabilities in the Toolkit, but it's main
strength is the known-virus scanner. IV, as I understand it,
concentrates on generic capabilities, and the scanner is less important.
If you need technical support on either of them, do make sure you ask the
right vendor - we don't know enough about IV to be able to give you
support.
If you do get both, I'd be interested to hear your experiences.
Dr Alan Solomon, S&S International
Chief Designer of Dr Solomon's Anti Virus Toolkit
US tel (617) 273 7400 UK tel +44 1296 318700
Business: sup...@drsolomon.com http://www.drsolomon.com
Personal: drs...@ibmpcug.co.uk http://www.ibmpcug.co.uk/~drsolly
>
>
>I ... am wondering if Invircible
>would add an additional type of protection or simply duplicate the
>functions of the tool kit. Also would they get in the way of each
>other or run successfully side by side?
>
Please be advised that InVircible is one of the products my
company sells and supports.
Yes, InVircible will add an additional layer of protection
to any known-virus based AV product such as Dr. Solomon's
Toolkit. Here are a few thoughts:
1.)InVircible operates primarily generically. That means
that installation establishes a database of information about
your system. When viral changes occur, InVircible has multiple
and partially redundant tools to restore your files and boot
block to their original state. It doesn't matter if the changes
are due to known or new viruses as is true with known-virus
AV products that must know about the virus in advance to
both detect ( especially stealth viruses )and restore your system.
2.) Additionally, InVircible uses technology to prevent viruses
from using any of its programs from acting as a vector to spread
viruses. Most products can only do this _if_ they know about
the virus in advance. If they don't, they can spread the virus.
3.)InVircible has very effective boot block recovery ability in
the ResQdisk program and resqdiskette you create. With the Pro
version, you can even rebuild partitions damaged by virus or
accident. There really is no equivalent to it amongst AV products.
4.) It does not generally conflict with well behaved AV TSR's
though very oppressive behavior blockers can interfere with
the functioning of InVircible's programs. Dr. Solomon's programs
will not conflict with InVircible's or vice versa.
The bottom line is that it is a worthwhile addition to your
AV protection tools. You can install InVircible, create a
resqdiskette, and forget about it untill a viral incident occurs.
You also do not need to worry about frequently updating it.
What Dr. Solomon's program's miss, such as a new virus not in its
database, InVircible will very likely detect and restore your system
from quite effectively. Since it is generic, it will have a much
longer life than known-virus toolkits. Paul Williams recently
demonstrated this in his study comparing a year old version
of InVircible to the current releases of 5 other AV products
including F-Prot, McAfee, and NAV. InVircible performed more
effectively in every category examined.
You can download an evaluation version of InVircible from the
ftp site in my signature or from any of the major online services
such as CompuServe.
-rcc
--
________________________________________________________________________
Robert C. Casas, Ph.D. COMSEC Ltd. - Computer Security Consultants
On CompuServe: GO INVIRCIBLE V: 708-729-3565 F:708-729-3575
7516...@compuserve.com <> ca...@netcom.com <> ca...@netcom.com
INVIRCIBLE BY FTP AT: pyro.slip.ais.net/crypto/invircible/
________________________________________________________________________
>I have ordered Dr. Solly's tool kit and am wondering if Invircible
>would add an additional type of protection or simply duplicate the
>functions of the tool kit. Also would they get in the way of each
>other or run successfully side by side?
Oh...boy....this might result in an interesting discussion :-)
Well, being a competitor of both, I should be able to give a reasonably
unbiased answer.
"add an additional type of protection" Well, *if* you run Invircible
on your machine, and then get infected by a totally unknown virus, the
chances are fairly good that the best part of DSAVTK (the scanner)
will fail to detect it, nut the best part of Invircible (the integrity
checker/generic remover) will be able to handle it.
Having said that, it should be noted that the chances of the above happening
are very small indeed...decent virus scanners (like the one in DSAVTK) will
generally have been updated to handle viruses before they become a "real world"
problem.
As for compatibility, I don't know...while I use DSAVTK regularly for
comparisons with F-PROT, I deleted Invircible off my machine within a few minutes
of seeing it the first time, so I have no real experience with it.
-frisk
--
Fridrik Skulason Frisk Software International phone: +354-5-617273
Author of F-PROT E-mail: fr...@complex.is fax: +354-5-617274
If possible, could you answer a few more questions?
>1.)InVircible operates primarily generically. That means
>that installation establishes a database of information about
>your system. When viral changes occur, InVircible has multiple
1. Does InVircible take up a lot of disk space? I wonder how much
information it will need in order to recover my files without knowing
the specific virus.
2. Does it deal with removable disk cartridges well?
>You can install InVircible, create a
>resqdiskette, and forget about it until a viral incident occurs.
3. An email reply I got said InVircible isn't a TSR. How does it
detect viruses? Would I need to run it periodically like a scanner?
Thanks for your help!
rc.c...@ix.netcom.com(Robert Casas) wrote:
>
>You can download an evaluation version of InVircible from the
>ftp site in my signature or from any of the major online services
>such as CompuServe.
>________________________________________________________________________
>Robert C. Casas, Ph.D. COMSEC Ltd. - Computer Security Consultants
>On CompuServe: GO INVIRCIBLE V: 708-729-3565 F:708-729-3575
>7516...@compuserve.com <> ca...@netcom.com <> ca...@netcom.com
>INVIRCIBLE BY FTP AT: pyro.slip.ais.net/crypto/invircible/
>________________________________________________________________________
>
Glenna
Glen...@ix.netcom.com
>In <30e838bb...@nntp.ix.netcom.com> Glen...@ix.netcom.com writes:
>-frisk
Just to throw in my two cents worth (that's all I can afford :-) ) .
It seems to me that deleting something without giving it a try first doesn't make good sense.
While it is true that the generic scanning abilities of Invircible are not as "effective" as a scan
from DSAVTK, the recovery tools included in the Invircible package more than pay for themselves
in the event of virii infection (this is the voice of experience talking, please pay attention)
I have used Invircible for about a year now and it has never failed to remove an infection from my
machine (granted, if I was a little more carefull, these things would happen less. But what's life without
a little adventure every now and then.)
I also would like to complement the Invircible staff. They have always been helpful when I've called to ask
questions and the tech support is second to none.
So my suggestion is, at least get the shareware, at least it will secure your files and check for system changes
and then if you do get hit by a virus, all you need to do is register it or by a licensed copy and away you go.
Thank you for your time
And of course, I work for Dr. Solomon.
>Yes, InVircible will add an additional layer of protection
>to any known-virus based AV product such as Dr. Solomon's
>Toolkit. Here are a few thoughts:
Are you unaware of the extremely powerful generic component
of Dr. Solomon's AntiVirus Toolkit ? It is an integrity checker,
called Viverify, and is extremely efficient at detecting new viruses
through detecting viral changes. It is rarely used by our customers,
because it is very rare for a Toolkit customer to have an infection
from a virus that we have not already seen, and written detection
and repair for, already. This is without them having to avail
themselves of our guaranteed 48-hour detect and repair turn-
around on samples received from customers with infections.
Also, people that buy our product tend to *prefer* to be
told that they have exactly varient .429 of Albania virus, or
whatever, and that we know exactly what its done to their
system and can reverse the damage, based on that knowledge.
>1.)InVircible operates primarily generically.
The Toolkit, though it has totally effective generic detection
through its Viverify component and excellent zero-false-alarm
Advanced Heuristics, operates "primarily" through its known-virus
detection and repair components. When I say "primarily", I mean
that that is how our users CHOOSE to use it.
>That means that installation establishes a database of information
>about your system. When viral changes occur
Make that "Only After viral changes occur...", and it is more obvious
why most users prefer to use a powerful known-virus tool over
even the best generic systems.
>You also do not need to worry about frequently updating it.
We update Dr. Solomon's AntiVirus Toolkit monthly, unless we need
to do it more often - in which case we issued an extra driver that
can detect AND repair. This is rarely necessary, what with monthly
updates already. We are proud of our ability to keep up with new
viruses !
Invircible undergoes updates, too, now and then. The last time I
heard about it was due to some false alarms caused by the way
Win'95 worked, and other improvements in the generic detection.
Do you expect that eventually you will make a version of your
product that will work perfectly, forever ? If so, when should
we expect to see it ? People will need to keep an eye out for
it so they won't ever have to worry about updating Invircible,
yet again...
Anyway, we'll keep on plugging away at the problem - at least
until you get your perfect solution in order. :-)
If you are dead set on generic solutions, try "Victor Charlie" by
Bangkok Security Consultants. Several years ago they introduced
"The World's First Generic Anti-Virus Defense" and when "Used
correctly VC will protect you from any active virus KNOWN or
UNKNOWN." Anyone remember them ? These things come and go.
I've got a copy here, maybe I should compare it to Invircible ?
C. Glenn Jordan - Senior Technology Consultant, S&S Software Intl.
617-273-7400 is our Boston, MA, USA office number
http://www.drsolomon.com is our WEB page with the eval version
> I have ordered Dr. Solly's tool kit and am wondering if Invircible
> would add an additional type of protection or simply duplicate the
> functions of the tool kit. Also would they get in the way of each
> other or run successfully side by side?
InVircible provides overall and self-contained antiviral protection for daily
use, in areas not covered by scanners or TSR. As stated in IV's
documentation, a good third party scanner is recommended for the
pre-screening of new software.
Non-resident programs do not interfere with each other and InVircible has
none. The only interference found from DSAV (not only to IV) was from its
TSR. When GUARD (ver 7.54) was loaded with its default parameters, it slowed
down IVB's daily check by a factor of TWELVE (a one minute check took now
twelve minutes), although it didn't interfere functionally with IV's checks.
The combined efficiency of IV and a good scanner is high enough so that you
won't need a TSR anyhow. Still, if you wish to use an antivirus TSR then load
it _after_ IV had completed its daily check.
IV has fairly unique disk and data recovery features. It could be worth
installing IV even if for this capability alone.
The new fully functional (freeware) version of InVircible is now available on
the ftp sites and from the major services. The file's name is invbfree or
iv-free, depending on the service and its date is January 1 or later.
A happy new year and safe computing to all!
Zvi Netiv
-------------------------------------------------------------------------
NetZ Computing Ltd, Israel Voice: +972 3 532 4563 Fax +972 3 532 5325
Developer & Producer of InVircible Web page: http://invircible.com/
E-mail: ne...@actcom.co.il ne...@datasrv.co.il ne...@invircible.com
Anonymous ftp: ftp.datasrv.co.il/pub/usr/netz/ ftp.invircible.com
Compuserve: NCSA Vendors forum, 'GO INVIRCIBLE' Zvi Netiv 76702,3423
-------------------------------------------------------------------------
> >comparisons with F-PROT, I deleted Invircible off my machine within a few minutes
> >of seeing it the first time, so I have no real experience with it.
> It seems to me that deleting something without giving it a try first doesn't make good sense.
Well, Frisk did try it. It seems that two minutes of trying it were
enough to make up his mind. Don't forget that Frisk is expert in
anti-virus stuff...
> While it is true that the generic scanning abilities of Invircible are not as "effective" as a scan
What do you mean by "generic scanning"? The author of InVircible
boasts it percisely for its generic virus detection capabilities. If
even these are not good (according to you), what is it good for, then?
Virus-specific scanning? With 4% detection rate? Don't be ridiculous.
> from DSAVTK, the recovery tools included in the Invircible package more than pay for themselves
> in the event of virii infection (this is the voice of experience talking, please pay attention)
For the sayings of another experienced (I dare say) voice, see
http://www.primenet.com/~mwest/iv-toc.htm
> I have used Invircible for about a year now and it has never failed to remove an infection from my
> machine (granted, if I was a little more carefull, these things would happen less. But what's life without
> a little adventure every now and then.)
Well, you're a courageous person. Most people (in my experience)
prefer when their anti-virus product detects the viruses *before* they
manage to infect their machine.
> I also would like to complement the Invircible staff. They have always been helpful when I've called to ask
> questions and the tech support is second to none.
I think that we're seeing not that a bad support and responsivness
from Dr. Solomon's team and from many other producers as well. But
this was not the subject. The subject was the *quality* of the
anti-virus product and the protection it provides; not the quality of
the technical support department of the company that sells it.
> So my suggestion is, at least get the shareware, at least it will secure your files and check for system changes
> and then if you do get hit by a virus, all you need to do is register it or by a licensed copy and away you go.
Please make sure to check the URL mentioned above for some tests of
how well it secures your files and how well it detects system changes,
and how likely it is to succeed to repair these changes.
Regards,
Vesselin
----
Vesselin Vladimirov Bontchev, not speaking for FRISK Software International,
Postholf 7180, IS-127, Reykjavik, Iceland producers of F-PROT.
e-mail: bont...@complex.is, tel.: +354-561-7273, fax: +354-561-7274
PGP 2.6.2i key fingerprint: E5 FB 30 0C D4 AA AB 44 E5 F7 C3 18 EA 2B AE 4E
> I have ordered Dr. Solly's tool kit and am wondering if Invircible
> would add an additional type of protection or simply duplicate the
> functions of the tool kit.
It will definitely not duplicate the toolkit's functions - they are
two very different products. If you are already using InVircible, the
Toolkit is definitely something I would recommend to you, especially
its scanner (FindVirus). If it is the other way around (i.e., if you
are already using the toolkit)... nahh, I won't say it. :-) I'd just
say that it *is* a good idea to combine a good scanner with some good
generic virus detection methods (like integrity checking). If these
generic virus detection methods are good, of course.
> Also would they get in the way of each
> other or run successfully side by side?
They cannot "run side by side" - they are two different and cannot be
compared very well. Sure, both products provide both on-demand
scanning and integrity checking, but... nahh, they simply cannot be
compared.
This, of course, depends on the speed of your computer. If you have, say,
a 386 with, say 2mb of memory, then the slowdown would be a lot less, I
would expect. If you have a 486 or Pentium, you might need a stopwatch to
detect any difference in speed. It depends on your computer.
>The combined efficiency of IV and a good scanner is high enough so that you
>won't need a TSR anyhow. Still, if you wish to use an antivirus TSR then load
>it _after_ IV had completed its daily check.
Or, let the AV TSR load first (early on is the obvious place for an
antivirus TSR to load), and tell IV to do it's check weekly, or monthly,
whichever you prefer. Or use Virus Guard in a machine that isn't as slow
as Zvi maybe used.
And, if you're running Windows, the VxD means that the TSR is irrelevant
anyway. The VxD is 32 bit, and better, and faster than Virus Guard.
> 1. Does InVircible take up a lot of disk space? I wonder how much
> information it will need in order to recover my files without knowing
> the specific virus.
It depends on your directory structure but in general no, InVircible
doesn't take that much disk space. The answer of this and the other
questions can be found in
http://www.primenet.com/~mwest/iv-toc.htm
> 2. Does it deal with removable disk cartridges well?
I don't know the answer of this one but my guess it that it probably
will - except that the stealth boot sector virus detection technology
might not work for them.
> 3. An email reply I got said InVircible isn't a TSR.
That's perfectly true.
> How does it
> detect viruses?
It waits until the virus infects your system and attempts to detect
the modifications caused by this.
> Would I need to run it periodically like a scanner?
Yes, in order to see whether the virus has infected your system
already. It installs some parts of itself in AUTOEXEC.BAT, so this
happens automatically every time you boot.
My experience with Invircible showed me that its "See-Thru"
technology ONLY works on standard ST-506 (ATA interface)
hard disks. It does not work with SCSI devices at all, like most
available removable drives are.
C. Glenn Jordan - Senior Technology Consultant, S&S Software Intl.
(617) 273-7400 in Boston, MA, USA
http://www.drsolomon.com
> Are you unaware of the extremely powerful generic component
> of Dr. Solomon's AntiVirus Toolkit ? It is an integrity checker,
> called Viverify, and is extremely efficient at detecting new viruses
Glenn, I am sorry, but, to be honest, the integrity checker in AVTK
certainly could use some improvements. (And so can the integrity
checker in the professional version of F-PROT, sniff.) The quality of
the scanner and the heuristic analyser is incomparably better than
that of the integrity checker. I believe that S&S are working in this
direction (and so are we).
> The Toolkit, though it has totally effective generic detection
> through its Viverify component
I'm afraid that I have to dispute this. Could you post an analysis of
how well does ViVerify handle the different attacks against integrity
checkers outlined in my paper?
> and excellent zero-false-alarm
> Advanced Heuristics, operates "primarily" through its known-virus
> detection and repair components. When I say "primarily", I mean
> that that is how our users CHOOSE to use it.
A pity, because the heuristic analyser is really great. Maybe they are
just not used to using it - ours do use our heuristic analyser a lot.
> Invircible undergoes updates, too, now and then.
It underwent quite a few after some sucker from Hamburg made a lot of
noise about its security bugs... :-)
> If you are dead set on generic solutions, try "Victor Charlie" by
> Bangkok Security Consultants. Several years ago they introduced
> "The World's First Generic Anti-Virus Defense" and when "Used
> correctly VC will protect you from any active virus KNOWN or
> UNKNOWN." Anyone remember them ?
Sure. Must have been a really great product, 'coz I haven't seen it
updated for years... :-)
> InVircible provides overall and self-contained antiviral protection for daily
> use, in areas not covered by scanners or TSR.
Could you please name some of these areas? There are all kinds of TSRs
around, you know...
> Non-resident programs do not interfere with each other
Sure they do. InVircible's non-resident programs used to delete a
non-resident file of mine called SOFIA.
> and InVircible has
> none.
Has none what? Non-resident programs? :-)
> The only interference found from DSAV (not only to IV) was from its
> TSR. When GUARD (ver 7.54) was loaded with its default parameters, it slowed
> down IVB's daily check by a factor of TWELVE (a one minute check took now
> twelve minutes), although it didn't interfere functionally with IV's checks.
Hmm, what was the overall slowdown of the system if IV *wasn't* used?
If it wasn't comparatively big then maybe IV is doing something that a
normal system isn't supposed to?
> The combined efficiency of IV and a good scanner is high enough so that you
> won't need a TSR anyhow.
Only if you have the self-discipline to remember to scan all incoming
software. Most people (like me) are lazy and prefer a memory-resident
scanner to do it automatically for them.
> The new fully functional (freeware) version of InVircible is now available on
> the ftp sites and from the major services. The file's name is invbfree or
> iv-free, depending on the service and its date is January 1 or later.
No version number any more? I guess, you have reached the perfect
version Glenn was talking about? :-)
> A happy new year and safe computing to all!
Same to you.
> My experience with Invircible showed me that its "See-Thru"
> technology ONLY works on standard ST-506 (ATA interface)
Oh, it will work with almost any IDE/EIDE hard disk - the latest
versions of InVircible, I mean.
> hard disks. It does not work with SCSI devices at all, like most
> available removable drives are.
Yep. Neither with MFM and RLL disks. But there is also another problem
- it is designed to work on hard disks, not on floppy sisks. If the
removable cartridges report themselves as large floppies, it might
have problems with that too. But when I examined the product in
Hamburg I had no access to such devices, so I couldn't check.
Therefore, I do not know for sure.
Regards,
Vesselin
>1. Does InVircible take up a lot of disk space? I wonder how much
>information it will need in order to recover my files without knowing
>the specific virus.
>
Relatively little. The main exe's and hypertext files require
about 600k.
>2. Does it deal with removable disk cartridges well?
I not sure what you mean. Zip drives? Tape cartridges? If you
can read/write to the media in real-time then you can use IV's
integrity based analysis methods. Tape cartridges are out
of the equation. Iomega Zip drives, on the other hand, would work
well.
>
>3. An email reply I got said InVircible isn't a TSR. How does it
>detect viruses? Would I need to run it periodically like a scanner?
IV doesn't use TSR's, correct. No, you do not have to manually
check your system for integrity though you can do so if you wish.
The defaults are either a daily or weekly full system integrity
analysis during initial boot up. You can run any of the individual
programs on demand if you wish.
>
>Thanks for your help!
>
Your welcome.
-rcc
--
>Also, people that buy our product tend to *prefer* to be
>told that they have exactly varient .429 of Albania virus, or
>whatever, and that we know exactly what its done to their
>system and can reverse the damage, based on that knowledge.
>
I find that people want to know when they have a virus on their
system, possess the tools to remove it, and restore their
systems to operational status quickly and reliably.
I am aware of S&S's product and like it.
>Make that "Only After viral changes occur...",
InVircible can be used to prescreen software using a test machine,
or even your floppy drive, so this isn't necessary at all.
We run across new viruses not detected by known virus scanners, and
which fool integrity checkers, all of the time. Where InVircible
differs from other "generic" tools is in generic detection _and_
repair. It isn't enough to know that you have a virus though this
is the correct starting place. Repair is handy, too.
>Anyway, we'll keep on plugging away at the problem - at least
>until you get your perfect solution in order. :-)
<g> The dream of every product producer is to create the
"perfect solution". But, a someone once said,
"You can fool some of the people all of the time, and all of
the people some of the time, but you can't fool all of the people
all of the time." ( or something like that )
I'll leave superlatives such as "perfect to others since it
certainly isn't applicable to any software I've tried.
> 1.)InVircible operates primarily generically. That means
> that installation establishes a database of information about
> your system. When viral changes occur, InVircible has multiple
> and partially redundant tools to restore your files and boot
> block to their original state. It doesn't matter if the changes
> are due to known or new viruses as is true with known-virus
> AV products that must know about the virus in advance to
> both detect ( especially stealth viruses )and restore your system.
Robert, please expound for us InVircible's product enhancement plans to
deal with macro or "document" viruses. Unless I'm mistaken, IV has no
defences against these whatsoever (and building them in would be
impossible with seriously redesigning the product??).
> 2.) Additionally, InVircible uses technology to prevent viruses
> from using any of its programs from acting as a vector to spread
> viruses. Most products can only do this _if_ they know about
> the virus in advance. If they don't, they can spread the virus.
Which is very nice for the few dozen people who -ever- contract such
new, unknown viruses -and- have absolutely "standard" hardware so IV can
use all its "tricks"...and completely meaningless in the realm of macro
viruses!
> 3.)InVircible has very effective boot block recovery ability in
> the ResQdisk program and resqdiskette you create. With the Pro
> version, you can even rebuild partitions damaged by virus or
> accident. There really is no equivalent to it amongst AV products.
I haven't looked at the Pro version, but from what I understand IV does
no more than certain other freeware and/or shareware MBR/DBS fixers.
> 4.) It does not generally conflict with well behaved AV TSR's
> though very oppressive behavior blockers can interfere with
> the functioning of InVircible's programs. Dr. Solomon's programs
> will not conflict with InVircible's or vice versa.
This is nice for IV and AVTK I'm sure, but aren't "oppressive behavior
blockers" the ones that are likely to be more effective??
> The bottom line is that it is a worthwhile addition to your
> AV protection tools. You can install InVircible, create a
> resqdiskette, and forget about it untill a viral incident occurs.
This is -far too strongly overstated- Robert. Please explain to us how
IV could have helped those thousands (maybe many hundreds of thousands!)
of Word users who have contracted a Word macro virus--or have the
authors of IV redefined the term "computer virus"??
> You also do not need to worry about frequently updating it.
> What Dr. Solomon's program's miss, such as a new virus not in its
> database, InVircible will very likely detect and restore your system
> from quite effectively. Since it is generic, it will have a much
> longer life than known-virus toolkits. Paul Williams recently
> demonstrated this in his study comparing a year old version
> of InVircible to the current releases of 5 other AV products
> including F-Prot, McAfee, and NAV. InVircible performed more
> effectively in every category examined.
And if macro viruses become legion???
Given the nature of macro viruses--interpreted code embedded in files
with a currently very poorly defined (outside of MS) structure--and what
macro viruses can do with the further cloaking of OLE, etc, etc it is
unlikely that anything other than totally oppressive behavior blockers
(that would render most contemporary popular application s/w useless) or
scanning will be effective tools against them.
How -will- IV deal with the "macro virus threat"?
And, will IV stop using completely false advertising claims such as
Robert's earlier claim:
You can install InVircible, create a resqdiskette, and forget
about it untill a viral incident occurs."
Sounds very like the equally bogus Victor Charlie claim of a few years
back (maybe they're still making it??) to the effect it could detect
"..all current and future..." viruses without need of updating.
Sorry if "macro viruses" sounds a bit repetitious here, but it only
takes one counterpoint to defeat an absolutist claim...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Nick FitzGerald, PC Applications Consultant, CSC, Uni of Canterbury, N.Z.
n.fitz...@csc.canterbury.ac.nz TEL:+64 3 364 2337, FAX:+64 3 364 2332
PGP fingerprint = 2E 7D E9 0C DE 26 24 4F 1F 43 91 B9 C4 05 C9 83
>> Non-resident programs do not interfere with each other and InVircible has
>> none. The only interference found from DSAV (not only to IV) was from its
>> TSR. When GUARD (ver 7.54) was loaded with its default parameters, it slowed
>> down IVB's daily check by a factor of TWELVE (a one minute check took now
>> twelve minutes), although it didn't interfere functionally with IV's checks.
> This, of course, depends on the speed of your computer. If you have, say,
> a 386 with, say 2mb of memory, then the slowdown would be a lot less, I
> would expect. If you have a 486 or Pentium, you might need a stopwatch to
> detect any difference in speed. It depends on your computer.
It has (almost) nothing to do with the speed of the computer but on how
intensive in file access is the application. AV TSRs, yours included,
intercept file access and this is the reason for the slowdown, not CPU
processing time. You don't need a stop watch to test this, scanning with a
third party scanner will show a very noticeable slowdown, by just counting
"twenty one, twenty two ... two hundred and ten ... etc.". ;)
>> The combined efficiency of IV and a good scanner is high enough so that you
>> won't need a TSR anyhow. Still, if you wish to use an antivirus TSR then load
>> it _after_ IV had completed its daily check.
> Or, let the AV TSR load first (early on is the obvious place for an
> antivirus TSR to load), and tell IV to do it's check weekly, or monthly,
> whichever you prefer. Or use Virus Guard in a machine that isn't as slow
> as Zvi maybe used.
(come on, we just upgraded our computers from charcoal to diesel! ;)
IV provides a safety net that TSR (and scanners and checksummers too) lack. I
did as you suggested, and here are the results! I got my whole drive infected
with Nightfall! I let the machine boot with an infected command.com and the
TSR (VirusGuard 7.54) loaded first in the autoexec without even noticing that
something was wrong. InVircible was REM-ed out for the length of the test.
To be on the safe side I also scanned the 1 giga drive with FindViru (from
DSAV ver 7.54). It joyfully went on, infecting all my 3000 executables, being
piggybacked by Nightfall. BTW, it's the the third (or fourth) successive
version of DSAV that fails on Nightfall when active, although your
programmers are familiar with (FindVirus detects it, but only when inactive,
and Dmitry Gryaznov is one of the two that reported NF to Joe Wells' latest
in-the-wild lists. The other one is Jimmy Kuo).
Something bothers me in Findviru. Once FV starts scanning, there is no way to
abort except with a forced hardware reset. This is not advised since you may
screw up your FAT (in case of an incomplete write to the FAT). When Nightfall
was piggybacking Findviru, I could tell something was wrong from the
excessive disk access, but didn't dare stopping it for the reason mentioned
above. I would think that Findvirus could gain from letting the user abort or
escape the scan, like in F-Prot, for example.
To complete the tests with Nightfall, I ran Viverify, the generic and
cryptographic checksummer. Obviously, it didn't find anything. BTW, how was I
supposed to know something went very very wrong, if I had used only DSAV?
Isn't this the classical scenario by which new stealth viruses become
widespread? Yet Nightfall isn't new at all, it even appears in the toolkit's
virus encyclopedia. How can you guarantee that there aren't alike lapses in
the toolkit? How can you qualify both the scanner and the TSR for 6000+
viruses, with every new release? Seems impossible to me, and the results
above support it.
There was no real damage in my case, as I could recover all files to the byte
(DSAV's included) with IV's generic and cooperative restoration (to
distinguish IVB from plain checksummers).
Next I ran the same scenario - starting with an infected command.com, this
time with IV enabled. Nightfall was trapped pretty fast as IV sensed there
was piggybacking going on. Piggybacking sensing is just one of many generic
methods by which IV captures the activity or presence of virus doing.
Integrity analysys (unlike checksumming, as in DSAV) is another one, and not
even the most important one. BTW, IV's integrity analysis distinguishes
between viral changes and benign ones, unlike checksumming that will flag any
change, benign or viral.
Generic virus capturing, upfront, provides the necessary safety net to
protect from TSR and scanner misses. Besides, I doubt if an intelligent user
will keep scanning for long, especially when held captive in a scan with no
possibility to escape. :-)
As for the TSR, I just demonstrated why it isn't worth the hassle. Generics
(plural) do better, with no penalty at all, unlike with the TSR.
> And, if you're running Windows, the VxD means that the TSR is irrelevant
> anyway. The VxD is 32 bit, and better, and faster than Virus Guard.
Antivirus VxD are irrelevant just the same. Once you are in Windows, viruses
are of no concern. It could even be risky to mess with viruses under Windows,
especially with the boot ones - and they are the most prevalent. The problem
is until Windows starts, i.e. in DOS. And there, VxD are useless, just like
selling ice to Eskimos.
Regards, Zvi
yeah, who cares about the oppression of computer programs... i have a
strict police state running on my machine... some people even use reverse
onus - "infected until proven clean"...
we should be as hard and unfair to our binaries as we can...
> We run across new viruses not detected by known virus scanners, and
> which fool integrity checkers, all of the time. Where InVircible
> differs from other "generic" tools is in generic detection _and_
> repair. It isn't enough to know that you have a virus though this
> is the correct starting place. Repair is handy, too.
whatever happened to your blessed backups?
This is incorrect. You may like to consult the manual for details on how
to do this. There is at least one documented way, and one un-documented
way.
> To complete the tests with Nightfall, I ran Viverify, the generic and
> cryptographic checksummer
Did you boot clean?
Regards
Graham
---
Graham Cluley CompuServe: GO DRSOLOMON
Senior Technology Consultant, UK Support: sup...@uk.drsolomon.com
Dr Solomon's Anti-Virus Toolkit. US Support: sup...@us.drsolomon.com
Email: gcl...@uk.drsolomon.com UK Tel: +44 (0)1296 318700
Web: http://www.drsolomon.com USA Tel: +1 617-273-7400
(Evaluation version available via Web: webpage will tell you password)
> Something bothers me in Findviru. Once FV starts scanning, there is no way to
> abort except with a forced hardware reset. This is not advised since you
There is a break. The exact escape sequence escapes me at the moment, but
there is one :).
Regards
StF
Hmm. I think people want to prevent a virus from getting on their
system, because we all know that generic integrity techniques will not
save you from all viruses.
Ripper. WordSwap. Dark Avenger. Nomenklatura. One Half.
Need I continue?
>>Make that "Only After viral changes occur...",
>
>InVircible can be used to prescreen software using a test machine,
That's not funny. If you have an extra machine just lying around, then
you don't need IV to "prescreen" software. What about hardware
incompatibilities and such? Unless you have a network of totally
homogeneous systems, this would be a foolhardy method of testing!
What about viruses which are only active on certain days, seconds, or
years? How long do I have to keep my software on my prescreening
computer before I decide it's okay?
Minutes?
Hours?
Months!?
>or even your floppy drive, so this isn't necessary at all.
Unless I disconnect the hard drive, it is possible to damage data
stored on the fixed disk of a computer, regardless of CMOS settings.
Don't encourage users to do it.
>We run across new viruses not detected by known virus scanners, and
>which fool integrity checkers, all of the time. Where InVircible
>differs from other "generic" tools is in generic detection _and_
>repair. It isn't enough to know that you have a virus though this
>is the correct starting place. Repair is handy, too.
Have you looked at NAV's Innoculation abilities? What about Integrity
Master? Oh yeah, NAV and IM both have much better scanners than IV. Hell,
you'd do even better with MSAV/CPAV.
>>Anyway, we'll keep on plugging away at the problem - at least
>>until you get your perfect solution in order. :-)
>
><g> The dream of every product producer is to create the
>"perfect solution". But, a someone once said,
>
>"You can fool some of the people all of the time, and all of
>the people some of the time, but you can't fool all of the people
>all of the time." ( or something like that )
Please. I have seen the IV cronies post all too many times about their
"new antivirus testing method" and the "we detect and repair all known and
unknown viruses".
Luckily, I haven't seen the latter of the two recently. Because, as most
people with a computer science background know, we can mathematically
prove that statement is false. (Not just case examples, Strange, Macro,
cough, cough.)
--
Kevin Marcus: http://cs.ucr.edu/~datadec
CS Dept, U/CA, Riverside: mailto:dat...@cs.ucr.edu
Virus-L archives: ftp://cs.ucr.edu/pub/virus-l
OKRA net.citizen Directory Services: http://okra.ucr.edu/okra
>>> Non-resident programs do not interfere with each other and InVircible has
>>> none. The only interference found from DSAV (not only to IV) was from its
>>> TSR. When GUARD (ver 7.54) was loaded with its default parameters, it slowed
>>> down IVB's daily check by a factor of TWELVE (a one minute check took now
>>> twelve minutes), although it didn't interfere functionally with IV's checks.
>
>> This, of course, depends on the speed of your computer. If you have, say,
>> a 386 with, say 2mb of memory, then the slowdown would be a lot less, I
>> would expect. If you have a 486 or Pentium, you might need a stopwatch to
>> detect any difference in speed. It depends on your computer.
>
>It has (almost) nothing to do with the speed of the computer but on how
>intensive in file access is the application. AV TSRs, yours included,
>intercept file access and this is the reason for the slowdown, not CPU
>processing time. You don't need a stop watch to test this, scanning with a
>third party scanner will show a very noticeable slowdown, by just counting
>"twenty one, twenty two ... two hundred and ten ... etc.". ;)
Sorry, but the speed of the computer's cpu does affect how long it takes to
do processing, and Virus Guard (and every other AV TSR does processing).
Also important, is what sort of computer. If you use a computer with XMS
memory, then Virus Guard will keep it's database there. If you use an
8088, then not only do you have a slow chip, but also no XMS, so Virus
Guard has to keep it's database on disk, and has to keep reading it, which
is slow. Fortunately, almost no users are now using 8088s (hence the
justification for the design). But you didn't mention what you used for
your timing trials.
Other people doing sensible and realistic timing trials, on sensible
and realistic hardware platforms, have reported very little speed
degradation.
>>> The combined efficiency of IV and a good scanner is high enough so that you
>>> won't need a TSR anyhow. Still, if you wish to use an antivirus TSR then load
>>> it _after_ IV had completed its daily check.
And the combined efficiency of a good TSR and a good scanner means that
you won't need a generic product, with all the potential false alarms and
copmpatibility problems that you might get with the ones that are not so
good.
>> Or, let the AV TSR load first (early on is the obvious place for an
>> antivirus TSR to load), and tell IV to do it's check weekly, or monthly,
>> whichever you prefer. Or use Virus Guard in a machine that isn't as slow
>> as Zvi maybe used.
>
>(come on, we just upgraded our computers from charcoal to diesel! ;)
Hmm. Try using electricity? :-)
>IV provides a safety net that TSR (and scanners and checksummers too) lack. I
>did as you suggested, and here are the results! I got my whole drive infected
>with Nightfall! I let the machine boot with an infected command.com and the
>TSR (VirusGuard 7.54) loaded first in the autoexec without even noticing that
>something was wrong. InVircible was REM-ed out for the length of the test.
The problem with safety nets, is that if they are too large and heavy, you
keep tripping over them, and break your arm. This, of course, only
applies to inferior safety nets. I'm here making the point that a safety
net, of the wrong type, or in the wrong place, can be a hazard!
>To be on the safe side I also scanned the 1 giga drive with FindViru (from
>DSAV ver 7.54). It joyfully went on, infecting all my 3000 executables, being
>piggybacked by Nightfall. BTW, it's the the third (or fourth) successive
>version of DSAV that fails on Nightfall when active, although your
>programmers are familiar with (FindVirus detects it, but only when inactive,
>and Dmitry Gryaznov is one of the two that reported NF to Joe Wells' latest
>in-the-wild lists. The other one is Jimmy Kuo).
Ah - you've found a security problem with Findvirus. Possibly a
differant version of Nightfall from the one we are familiar with?
Anyway, thanks for reporting it. Vesselin has reported a number of security
holes in a number of different products; all vendors work to close these
holes up. How are you doing on the ones that he reported in Invircible?
I can't remember how many problems he reported.
>Something bothers me in Findviru. Once FV starts scanning, there is no way to
>abort except with a forced hardware reset.
I guess you didn't notice in the documentation where it says that you can
abort in mid-scan, by pressing Ctrl-break, if you use the switch /YESBREAK
(I don't have a manual handy, so you should check the exact syntax). If you
don't have a manual, do let me know, and we'll send you a complimentary copy
of our product, hoping for a complimentary copy of yours in return.
I've often wondered how good Invircible is. With a generic product, the
main way for a user to test it, is not to try it on viruses, but to
install it on his working machine, and see how soon he's screaming for it
to be taken off. I've not tried IV, so please don't take this as a
comment on your product, but with every generic product I've ever tried, I
lasted less than a day or so. Other people report similar experiences to
me.
I remember one of my favourites. It was a hardware product (I'll not
embarrass the vendor by naming it). I installed it on my 486, set it up
as suggested in the manual, and started using my computer. For some
reason, it blocked *all* writes to the hard disk. But Dos didn't know
that! So when I saved a file, Dos thought it had saved; even if you did a
DIR, the file seemed to be there (because the directory information was
being cached in the Dos buffers). After I'd used it for about an hour, I
realised why I kept losing files, and yanked the card. The vendors
weren't able to fix the problem in any reasonable length of time, (I'm
sure they fixed it eventually) and I believe that the hardware product is
now pretty much unobtainable.
I also tried a generic behaviour blocker, but it popped up a blue box with
a false alarm at me a few times each day, until I got fed up with it and
took it out.
Now, of course, I'm not saying that Invircible gives incompatibility
problems like the card did, or excessive false alarms like the generic I
mentioned, since I haven't tried IV. But that, in my opinion, would be the
main thing to look for in testing.
By the way, if I did look at IV, I wouldn't publish my findings. I think
there's something rather unconvincing about one vendor criticising
another vendor's product in public, so I try not to do it too much. Of
course, public discussion of the possible weaknesses and problems in a
particular approach, that's different.
>I would think that Findvirus could gain from letting the user abort or
>escape the scan, like in F-Prot, for example.
There's two schools of thought on this. A lot of our customers who run
PC Support departments, don't want users to be able to abort the scan, so
they install it without /YESBREAK and make sure that users always get
scanned properly.
>To complete the tests with Nightfall, I ran Viverify, the generic and
>cryptographic checksummer.
Again, I guess you didn't read the manual sufficiently carefully to see
that:
a) you should boot from a clean Dos disk before running that program, in
which case, stealth won't happen, or
b) there's a way that Viverify can de-stealth, using a tunneling
technique (you've got some unusual name for this method - we call it
Anti-stealth), again you would want to use the relevant switch.
>How can you guarantee that there aren't alike lapses in
>the toolkit?
No program can be guaranteed free from mistakes. Vesselin Bontchev, while
a PhD student at the University of Hamburg, has published numerous papers
covering numerous products, pointing out security flaws in them. I believe
one of his papers covers Invircible. Have you dealt with all the points he
raised in that? He also published papers pointing out weaknesses in the
Dr Solomon's Toolkit, TBAV, F-Prot, McAfee, IBMAV, VET, CPAV, NAV, and
many, many other products. I'm not saying that these products are awful,
and neither did Vesselin. Many of them are good. But his papers
documenting flaws have helped more than one vendor improve their product.
I would still recommend Vess's papers (I think you can ftp them from
Hamburg; maybe Vess could give the address) to anyone serously interested
in the quality of AV products, and in the methodology of testing.
Vesselin going to Iceland, was a great gain for Frisk, a great loss to the
rest of the world.
>How can you qualify both the scanner and the TSR for 6000+
>viruses, with every new release? Seems impossible to me, and the results
>above support it.
Simple. We have a collection that consists of all those viruses we know
about (currently more like 8,000), and we run the scanner over the
collection, including multiple instances of polymorphics. What we don't do,
is do that test with each virus in memory, because to do that for each
virus, would extend the test time to over a month, and that would delay
release of the product too much. We do a large number of other tests, such
as a false alarm test (required number of false alarms is zero, even using
heuristics). I'm not going to list all the tests we do; it would be a long
list. But, of course, we don't test every possible combination of
situations, otherwise we'd be releasing the product several months after
it was finished.
How do you test the statement that IV detects the same 8,000 viruses? And
how do you answer the question that another poster asked, about how IV can
detect macro viruses in DOC files (they don't necessarily infect DOT
files, of course).
By the way, how would IV detect a virus that worked like Brain (a fairly
old virus vintage 1986, at least used to be in the wild)? Does IV detect
Brain, after a user has installed IV in the recommended manner? Have you
tested that?
>Integrity analysys (unlike checksumming, as in DSAV) is another one, and not
>even the most important one. BTW, IV's integrity analysis distinguishes
>between viral changes and benign ones, unlike checksumming that will flag any
>change, benign or viral.
Have you tested that on the 8,000-odd known viruses, or are you just going
on theoretical suppositions? Maybe some virus changes look benign, or
maybe some benign changes look virus-like?
>Generic virus capturing, upfront, provides the necessary safety net to
>protect from TSR and scanner misses.
I'd be inclined to put that the other way round. TSRs and Scanners provide
the protection when generic products fail, and are the only way that a
user can determine that a generic product has just given a false alarm. Of
course, I'm only talking about inferior generic products here.
>Besides, I doubt if an intelligent user
>will keep scanning for long, especially when held captive in a scan with no
>possibility to escape. :-)
Unless, of course, he read the manual :-) Or phoned for technical support
:-)
>As for the TSR, I just demonstrated why it isn't worth the hassle. Generics
>(plural) do better, with no penalty at all, unlike with the TSR.
Some generics (the inferiors ones, perhaps) give a lot of false alarms.
That is a penalty - a big one. Because it means that the user never knows
whether he has a false alarm "file changed, looks like a virus maybe" or a
virus "file changed, looks like a virus maybe".
>> And, if you're running Windows, the VxD means that the TSR is irrelevant
>> anyway. The VxD is 32 bit, and better, and faster than Virus Guard.
>
>Antivirus VxD are irrelevant just the same. Once you are in Windows, viruses
>are of no concern.
Maybe not to you. But to someone with the Concept macro virus, or the
Nuclear macro virus (which *can* only work under Windows (or on a Mac)),
they are a big concern. Also, as I'm sure you are aware, most boot sector
viruses work just fine under Windows 95; they infect hard disks, they
infect floppy disks, and they trigger their payload (if there is one).
>It could even be risky to mess with viruses under Windows,
>especially with the boot ones - and they are the most prevalent. The problem
>is until Windows starts, i.e. in DOS. And there, VxD are useless, just like
>selling ice to Eskimos.
But you run your TSR until Windows starts up (which is pretty soon, on
many users computers). Then, when Windows runs, the VxD starts up, and (at
least for our product) we have a lovely ceremony called "The Changing of
the Guard", when Winguard takes over the job from Virus Guard.
So, a VxD isn't like selling ice to an eskimo, it's more like selling ice
to an Englishman. 99% of the days here, there's no free ice to be had,
because our climate is more concentrated on rain (there are 83 synonyms
for rain in England, and only one word for sunshine). The other 1% of the
time, you can find ice if you look for it, but not very much, and it
usually isn't drinking quality (yes, I know you don't drink ice, but you
know what I mean). So it does make sense to sell ice to Englishmen, and it
makes sense to sell a VxD to someone who uses Windows.
>Please. I have seen the IV cronies post all too many times about their
>"new antivirus testing method" and the "we detect and repair all known and
>unknown viruses".
>
>Luckily, I haven't seen the latter of the two recently. Because, as most
>people with a computer science background know, we can mathematically
>prove that statement is false. (Not just case examples, Strange, Macro,
>cough, cough.)
Heh heh. I didn't do Computer Science (it didn't exist when I was at
college), so I don't know this. And in my ignorance, I shall now reveal
to you (and everyone else who hasn't already seen this)
.... Fanfare of trumpets ...
.... Roll of the drums ...
.... Very loud noise from 76 trombones ....
THE PERFECT ANTIVIRUS
Definition. I shall now give you, free of charge, an antivirus that if used
correctly, detects all past, present and future viruses, never gives a false
alarm, and has a zero cost. Sceptical? Then watch carefully ...
P1.BAT
Echo %1 is infected by a virus!!!
You'll agree, I think, that P1.BAT will detect all past, present and
future viruses. That alone meets the "mathematically impossible" task you
set me! But, I hear you thinking, aren't there rather a lot of false
alarms? Well, you didn't say you wanted a low false alarm rate.
OK, OK. I'm used to projects where the user specification changes in
the middle. Never mind. I can deal with the false alarms ...
P2.BAT
Echo %1 is NOT infected by a virus!!!
You'll agree, I think, that P2 will never, ever, tell you that you have a
virus when you don't. Of course, it has a pretty poor detection rate. I
admit that. But I can fix it. See here ...
PERFECT.BAT
Echo Is %1 a virus? (Y/N)
If the user types Y, you run P1. If the user types N, you run P2. Remember
what I promised you? An antivirus that *if used correctly*, detects all
past, present and future viruses, never gives a false alarm, and has a
zero cost.
All very amusing, but what can we learn from this?
1. If something is superb at detecting viruses, it's no use if it gives a
lot of false alarms.
2. Anything that relies on the user to make a correct decision, on
matters that he is not likely to be able to decide about, is useless.
3. You can receive something that is *exactly* what the salesman promised
to deliver, and it's nevertheless useless.
>
> > If you are dead set on generic solutions, try "Victor Charlie" by
> > Bangkok Security Consultants. Several years ago they introduced
> > "The World's First Generic Anti-Virus Defense" and when "Used
> > correctly VC will protect you from any active virus KNOWN or
> > UNKNOWN." Anyone remember them ?
>
> Sure. Must have been a really great product, 'coz I haven't seen it
> updated for years... :-)
AFAIK, Alan Dawson is still around and hasn't updated VC because he
hasn't seen any need to.
I never really tried VC since it has a very pervasive install routine
that I didn't feel comfortable with. Since I've been using OS/2 (about
1 year) I haven't even paid any attention to this type of DOS-based AV
product.
--
----------------------------------------------------------------
Stuart Krivis stu...@apk.net
[Team OS/2] stuart...@pcohio.com
bp...@cleveland.freenet.edu
----------------------------------------------------------------
>Maybe not to you. But to someone with the Concept macro virus, or the
>Nuclear macro virus (which *can* only work under Windows (or on a Mac)),
>they are a big concern. Also, as I'm sure you are aware, most boot sector
>viruses work just fine under Windows 95; they infect hard disks, they
>infect floppy disks, and they trigger their payload (if there is one).
Ha! if ever there was a reason to choose OS/2 over Win95, it is this -
BSI do not spread from OS/2 machines.
Surely the whole virus problem would almost disappear if everyone
switched to OS/2 and ran native 32-bit OS/2 executables?
Cheers, Ian
--------------------------------------------------------------------
ian...@lia.co.za P.O. Box 484, Sanlamhof 7532, South Africa
36 : 1,73 : 58 : blue : dark brown PGP key available Galileo II
http://www.lia.co.za/users/iandoug I'm an iN*T*j. I can do anything. :-)
> It has (almost) nothing to do with the speed of the computer but on how
> intensive in file access is the application.
That's true. Ineffective applications which use unnecessarily
extensive file access tend to slow the computer down - especially if
it is using an anti-virus TSR. Or any other TSR that intercepts file
access, for that matter.
> AV TSRs, yours included,
> intercept file access and this is the reason for the slowdown, not CPU
> processing time.
Oh, not all AV TSRs intercept file access. Some intercept only file
execution and others (Dr. Solomon's incusive) can be configured to
intercept only file execution, not access. Also, the different
anti-virus TSRs cause different slowdown. Admittedly, Dr. Solomon's is
on the slower side - but then it detects more viruses. Ours is faster
but it (the TSR) detects less viruses.
And yes, TSRs tend to slow the machine down - this goes for all TSRs,
like keyboard drivers, other device drivers, utilities, crypo-,
anti-virus and other kinds of security-oriented software, even
COMMAND.COM! Of course, some cause more slowdown than others. On a
fast machine the slowdown is usually negligible, compared to the
services provided by all these programs - but then, every user should
make up his/her mind him/herself about this.
> (come on, we just upgraded our computers from charcoal to diesel! ;)
Ah, that probably explains it. When your R&D department discovers
electricity, you will undoubtedly find out that anti-virus TSRs aren't
that slow, after all... :-)
> IV provides a safety net that TSR (and scanners and checksummers too) lack.
For instance?
> I
> did as you suggested, and here are the results! I got my whole drive infected
> with Nightfall!
Oh, I can do such "tests" too! As the document
http://www.primenet.com/~mwest/iv-toc.htm
explains, I ran a Tremor-infected virus (or a Dir_II virus, or a
companion virus, or...) on a system protected with InVircible and got
the whole drive infected too!
> Something bothers me in Findviru. Once FV starts scanning, there is no way to
> abort except with a forced hardware reset.
Of course there is. You just haven't found it yet. Maybe it's time to
call the technical support? :-)
> When Nightfall
> was piggybacking Findviru, I could tell something was wrong from the
> excessive disk access,
Then you have a *really* slow drive - or have run the tests on a
floppy.
> I would think that Findvirus could gain from letting the user abort or
> escape the scan, like in F-Prot, for example.
It already can do that although, unlike F-PROT, it doesn't ask the
"are you sure?" question.
> To complete the tests with Nightfall, I ran Viverify, the generic and
> cryptographic checksummer. Obviously, it didn't find anything.
Curious, the very same thing happened when I tried InVircible with a
Tremor virus active in memory. Could there be some similarity between
the two products in this aspect after all?
> BTW, how was I
> supposed to know something went very very wrong, if I had used only DSAV?
You were supposed to run the anti-virus product after having booted
from a clean floppy - just as you have to do with InVircible every now
and then (or you'll miss a Tremor and a bunch of other viruses).
> Isn't this the classical scenario by which new stealth viruses become
> widespread?
It is, except that they are not that widespread actually.
> Yet Nightfall isn't new at all,
Neither was Tremor at the time when I registered InVircible's faulure
to detect it.
> How can you qualify both the scanner and the TSR for 6000+
> viruses, with every new release?
That figure stands for running the scanner without viruses active in
memory. If a virus controls your computer then the game is, in
general, lost - regardless of whether you run InVircible, Dr.
Solomon's scanner, or anything else. That's why we keep telling the
users to "always boot clean". Except that they don't. :-(
> Seems impossible to me, and the results
> above support it.
I don't think so.
> There was no real damage in my case, as I could recover all files to the byte
> (DSAV's included) with IV's generic and cooperative restoration (to
> distinguish IVB from plain checksummers).
Ah, so *that* is what makes IVB so different from plain checsummers!
That it allows you to use a stealth virus' stealth mechanism to
recover the original files. Well, believe it or not, even PKZIP allows
you to do it. I guess we should classify PKZIP as an anti-virus
utility which is much better than plain checksummers, yes?
> Next I ran the same scenario - starting with an infected command.com, this
> time with IV enabled. Nightfall was trapped pretty fast as IV sensed there
How about Tremor?
> was piggybacking going on.
How about Skid_Row?
> Piggybacking sensing is just one of many generic
> methods by which IV captures the activity or presence of virus doing.
To the readers of this newsgroup - see the URL mentioned above for an
explanation of what this really means.
> BTW, IV's integrity analysis distinguishes
> between viral changes and benign ones, unlike checksumming that will flag any
> change, benign or viral.
Wrong. As the document pointed by the URL mentioned above explains,
IV's integrity analisis fails to flag as a "viral change" a file that
has been overwritten by a virus at the beginning - either because it
is an overwriting virus (like Burger), or because it overwrites the
beginning of the file and stores the original at the end (like
Anti-Pascal does), or because it's a file system infector (like
Dir_II). Furthermore, IV is by far not the only integrity checker
which uses some heuristics to figure out whether the change is likely
to be caused by a virus. Untouchable did, ADINF does, IBM Antivirus
does, many others do it as well. I think that even ours (in the
Professional version of F-PROT) does it as well.
> Generic virus capturing, upfront, provides the necessary safety net to
> protect from TSR and scanner misses.
It's *a* line of defense, not *the* line of defense.
> Besides, I doubt if an intelligent user
> will keep scanning for long, especially when held captive in a scan with no
> possibility to escape. :-)
Obviously the users of scanners disagree with you. Or maybe they just
prefer to have the virus detected (and to be told which virus it is)
instead of waiting for the virus to infect their system and for their
integrity checker (or analyser or whatever buzzword you decide to use
this Wednesday) manages to detect it and tell them that something is
amiss (but what?).
> As for the TSR, I just demonstrated why it isn't worth the hassle. Generics
> (plural) do better, with no penalty at all, unlike with the TSR.
Wrong. First, you didn't demonstrate anything - except maybe that it
is dangerous to do anything with a virus active in memory (which is
exactly what your product does). Second, generic anti-virus measures
are usually more *secure* (if implemented properly, of course) but not
necessarily "better". They have a lot of drawbacks which have been
mentioned here several times. Third, there are generic anti-virus TSRs
too - any monitor (or behaviour blocker, as they are sometimes called)
is such a generic anti-virus TSR.
> > And, if you're running Windows, the VxD means that the TSR is irrelevant
> > anyway. The VxD is 32 bit, and better, and faster than Virus Guard.
> Antivirus VxD are irrelevant just the same.
They are not irrelevant at all, considering the huge numbers of users
who want one.
> Once you are in Windows, viruses
> are of no concern.
Of course they are. There are plenty of viruses which happily run and
infect under Windows. There are even Windows-specific viruses. Do you
know how popular Ph33r is getting these days?
> It could even be risky to mess with viruses under Windows,
That for sure - if the virus is active (as InVircible expects and even
relies on), then it is very dangerous to mess with it. But not only
under Windows - it is dangerous to do it under DOS too...
> The problem
> is until Windows starts, i.e. in DOS. And there, VxD are useless, just like
> selling ice to Eskimos.
You're missing the point. The need for a VxD scanner under Windows is
for two purposes. First, to prevent the user from accidentally
executing an infected program. Second, to scan the incoming software
without leaving his/her favorite environment (although you don't need
a VxD scanner for this; a scanner implemented as a Windows application
will do).
> THE PERFECT ANTIVIRUS
> Definition. I shall now give you, free of charge, an antivirus that if used
> correctly, detects all past, present and future viruses, never gives a false
> alarm, and has a zero cost. Sceptical? Then watch carefully ...
> P1.BAT
> Echo %1 is infected by a virus!!!
> You'll agree, I think, that P1.BAT will detect all past, present and
> future viruses. That alone meets the "mathematically impossible" task you
> set me! But, I hear you thinking, aren't there rather a lot of false
> alarms? Well, you didn't say you wanted a low false alarm rate.
I hate to be a spoilsport (I lied; actually I love it <grin>) but:
1) The actual claim is that "you cannot detect all possible computer
viruses by their appearance or by their beheaviour on a Turing Machine
without causing either an infinite number of false positives or of
false negatives or both". Your example causes an infinite number of
false positives.
2) Real computers aren't Turing Machines.
3) The above programs, if used alone, misses all boot sector viruses.
> P2.BAT
> Echo %1 is NOT infected by a virus!!!
> You'll agree, I think, that P2 will never, ever, tell you that you have a
> virus when you don't. Of course, it has a pretty poor detection rate. I
Yep, an infinite number of false negatives.
> PERFECT.BAT
> Echo Is %1 a virus? (Y/N)
> If the user types Y, you run P1. If the user types N, you run P2. Remember
> what I promised you? An antivirus that *if used correctly*, detects all
> past, present and future viruses, never gives a false alarm, and has a
> zero cost.
Nope, although debunking this one is a tricker exercise. But first the
nitpicks:
1) You can't get user input from a BAT file running under COMMAND.COM,
unless you use an additional external program.
2) It still doesn't detect boot sector viruses.
Now, the real argument. Imagine a virus which executes the above
program. If the user replies "Y" ("yes it is a virus") then the virus
doesn't replicate - i.e., it is not a virus. If the user replies "N"
("no, it is not a virus") then the virus replicates, i.e., it is a
virus. As you can see, regardless of what the user enters, the reply
is wrong.
> All very amusing, but what can we learn from this?
Your conclusions are right, however. :-)
> Alan Solomon writes:
> >
> > P1.BAT
> > Echo %1 is infected by a virus!!!
>
> I hate to be a spoilsport (I lied; actually I love it <grin>) but:
>
> 3) The above programs, if used alone, misses all boot sector viruses.
Not if the parameter given by the user (if used correctly, remember) is
"BOOTSECTOR" or "MBR" or (if we're going for a really easy to use
interface for extra points from the NSTL) "PC".
Regards
Graham
---
Graham Cluley CompuServe: GO DRSOLOMON
Senior Technology Consultant, UK Support: sup...@uk.drsolomon.com
Dr Solomon's Anti-Virus Toolkit. US Support: sup...@us.drsolomon.com
Email: gcl...@uk.drsolomon.com UK Tel: +44 (0)1296 318700
Web: http://www.drsolomon.com USA Tel: +1 617-273-7400
NEW:Evaluate Dr Solomon's FindVirus 7.55! Download it from our webpage
I was responding to the claim that was posted here, which was a lot easier
to handle. I agree that the claim you post above is a better target! And,
of course, I agree that P1.BAT gives an infinite number of false
positives.
>2) Real computers aren't Turing Machines.
Real users don't care about that.
>3) The above programs, if used alone, misses all boot sector viruses.
No it doesn't. Look at this output from it:
"The boot sector of drive C is infected with a virus!!!"
You see? It detects boot sector viruses too - you just have to use it
correctly :-)
It even detects viruses in the little rubber feet under the computer -
I'll leave it as an exercise for you to work out how. :-)
>
>> P2.BAT
>> Echo %1 is NOT infected by a virus!!!
>
>> You'll agree, I think, that P2 will never, ever, tell you that you have a
>> virus when you don't. Of course, it has a pretty poor detection rate. I
>
>Yep, an infinite number of false negatives.
Yep.
>
>> PERFECT.BAT
>> Echo Is %1 a virus? (Y/N)
>
>> If the user types Y, you run P1. If the user types N, you run P2. Remember
>> what I promised you? An antivirus that *if used correctly*, detects all
>> past, present and future viruses, never gives a false alarm, and has a
>> zero cost.
>
>Nope, although debunking this one is a tricker exercise. But first the
>nitpicks:
>
>1) You can't get user input from a BAT file running under COMMAND.COM,
>unless you use an additional external program.
Ptui! That's a real nitpick - there's plenty of little proggies around you
can use. I simplified the explanation of PERFECT.BAT by not going into that
detail.
>
>2) It still doesn't detect boot sector viruses.
Yes it does, very easily, see above.
>
>Now, the real argument. Imagine a virus which executes the above
>program. If the user replies "Y" ("yes it is a virus") then the virus
>doesn't replicate - i.e., it is not a virus. If the user replies "N"
>("no, it is not a virus") then the virus replicates, i.e., it is a
>virus. As you can see, regardless of what the user enters, the reply
>is wrong.
First, lets take the case of a virus that is just sitting on a floppy
disk, not being executed. There's no way that the virus can predict what
the user will answer. Therefore, such a virus (that predicts the user's
input) cannot be written.
Now let's take the case when the virus is in control, and is running
PERFECT.BAT. It is a virus (replicating when the user types N). So, if the
user types Y, then he is correct (even though it didn't replicate on that
occasion - plenty of viruses need specific conditions to replicate). So,
PERFECT.BAT, if used correctly, still works.
Therefore, you have not produced a counter-example. It's not that easy
to fool THE PERFECT ANTIVIRUS. Try again.
Hint: The user is not part of the virus/PC system!
>
>> All very amusing, but what can we learn from this?
>
>Your conclusions are right, however. :-)
Thank you. I already knew that :-)
Snarl, grown, snurf snurf snurf. All these pedants. I thought Compuserve
had censored the pedants off the net...
OK, what about:
"The_boot_sector_of_drive_C is infected with a virus!!!"
Not at all. There are some people that don't like certain programs, but most
of the rivalry in this group is healthy competition that makes programs
better. I'm sure that Vesselin's comments and papers have helped to make
Invircible a better product -- by pointing out security holes, they can be
patched.
>
>If seems to me that there are quite a few good anti-virus programs around.
>I happen to use Invircible for the simple reason that it has worked well so
far.
I'd have to question your logic here. Define 'it has worked well so far'.
Have you had any infections? Has IV been able to clean them successfully?
Has IV had a high false alarm rate (this is often worse than a real
infection)?
>Sure I make backups of my stuff but I doubt that anyone scans each and every
>diskette that they use to install a new program. It's just not always
>convienent ("Get that job finished NOW!!!!!!!")
I'd have to disagree here too. I scan EVERY disk/CD/downloaded program for
viruses before I even consider running it. This is especially important for
files downloaded off of the internet, as I don't know where they came from, or
how reliable the source is. It's the equivalent (as Dr. Solomon would say) of
picking up something off of the road, and eating it. You wouldn't do it, even
if you smelled it first.
The benefit of scanners is that they detect viruses BEFORE they infect your
system. Integrity checking programs rely on a virus attack happening before
they do the infection.
>BTW, That's a quote from my boss :-)
Sounds familiar. I think I've heard it before. :) Hmm... didn't my boss say
that... :-)
>So use what makes you happy, if it does the job, why bother with anything
>else unless you just want to expand your horizons.
Using 'what makes you happy' is a good rule, but not everybody will be happy
with certain characteristics of a program. Suppose I write a hypothetical
anti-virus program that has a beautiful user interface, is remarkably fast,
and is extremely convenient to use. I don't include any virus-scanning code
in the program, just a screen that SAYS that it is scanning. This program
would have zero false alarms, and many users would be thrilled to run it. Of
course, this ends when a virus infection occurs and causes damage. What I'm
saying is that being happy with a program isn't exactly the best way to
compare a program that protects your data.
Regards,
George Wenzel
("`-''-/").___..--''"`-._ George Wenzel <gwe...@gpu.srv.ualberta.ca>
`6_ 6 ) `-. ( ).`-.__.`)Student of Wado Kai Karate
(_Y_.)' ._ ) `._ `. ``-..-' University of Alberta Karate Club
_..`--'_..-_/ /--'_.' ,'
(il),-'' (li),' ((!.-'