As well as posting pointers to his "Fun with EICAR" article here, Arnold
posted the text to some security mailing lists. The NTBugtraq moderator
posted Arnold's message a day or so ago and it fairly quickly drew a long
and detailed response from Vesselin Bontchev who, with more paitence than
I was prepared to devote to the exercise, demolished Arnold's claims,
"experiments" and conclusions one by one.

Anyone interested in what someone with a few cluse about viruses, virus
detection, antivirus design philosophy and technology has to say about
Arnold's article and its claims can read the archived copy of that
message here:

http://www.ntbugtraq.com/default.asp...&F=P&S=&P=2424

(URL will probably wrap...)


--
Nick FitzGerald

"Nick FitzGerald" <(E-Mail Removed)> :

>and detailed response from Vesselin Bontchev who, with more paitence than
>I was prepared to devote to the exercise, demolished Arnold's claims,
>"experiments" and conclusions one by one.

> http://www.ntbugtraq.com/default.asp...&F=P&S=&P=2424

An interesting response. Vesselin Bontchev is obvously right when he
insists on these two facts: 1. the EICAR file is a very special case
and is strictly defined - so once you modify it it's no more the EICAR
file - and 2. you cannot assess the ability of a scanner to detect
unknown viruses by using variations of a known scan string (especially
EICAR, see point 1).

On the other hand, just for the sake of arguing a bit, I think he's
wrong in one minor point involving F-Prot (well, that's
understandable, he works there). Arnold does a test by inserting a
"nop" in front of the EICAR file. No anti-virus detects this new file,
and they are obviously all right. But F-Prot reports it as "New or
modified variant of Trivial". Vesselin comments on that by saying "we
try to provide even more information than strictly necessary". Well,
maybe, and we all know that F-Prot is pretty good both for identifying
known viruses and discovering unknown viruses, but in this particular
case I think F-Prot is just wrong. An EICAR file with a "nop" at the
beginning is *not* some new or modified version of a lame overwriting
virus. It does not have anything that looks like a virus. It should
have reported nothing at all. Same goes for the modification with just
a decryption loop, although it's one routine that may be found in real
viruses. The next tests are about modifications that now give the file
some real infection abilities, and of course this time F-Prot is right
by saying "New or modified variant of Trivial".

My two cents.

--
Guillermito
http://www.guillermito2.net

Nick FitzGerald wrote:

>
http://www.ntbugtraq.com/default.asp...bugtraq&F=P&S=
&P=2424

Autant j'etais globalement d'accord avec la reponse de Fridirik
Skulason, autant il y a quelques points qui me chiffonnent dans celle de
Vesselin Bontchev.
--
Actually, I mostly agreed with Fridirik Skulason answer, but there are
some points on which I disagree in Vesselin Bontchev's one.

(Xposted on fcsv and acav)

> Namely:

> (1) The above 68 characters *MUST* be at the beginning of the file.
> If they aren't there, it's not the ESATF - it's that simple.

C'est ce qui est interessant. On sait que les antivirus detectent
ESAFT. Le principe est donc de tester leur reaction face a quelque
chose qui n'est pas esaft mais qui y ressemble.
--
That's the intersting point. AV products do detect ESAFT. The idea
was just to test their reactions in front of something that is not esaft
but that is quite similar to it.

> Any anti-virus product that detects as
> "the ESATF" something which is not it is wrong. For instance,
> any product that detects it in this message is wrong. This
> message, despite that it contains these 68 characters, is not the
> ESATF, since they are not at its very beginning.

D'accord.
--
I agree.

> Keep that in mind when examining the various examples you gave. Had
> you paid attention to this requirement in the first place, you
> wouldn't have bothered writing half of your paper.

Pas d'accord. A l'origine, la discussion qui a conduit a l'ecriture
de cet article (OK, cet aspect a disparu dans l'article, et quiconque
n'a pas suivi la discussion sur fr.comp.securite ne peut pas le
deviner) tournait autour de la question suivante : "comment les
antivirus font ils pour analyser si efficacement (en terme de taux de
detection et de vitesse) autant de fichiers en utilisant un tel nombre
de signatures. Ils doivent vraissemblablement rejeter des que possible,
au cours de l'analyse, autant de signatures que possible de maniere a
reduire le nombre de faux positifs et a ameliorer la vitesse d'analyse
(si l'on suppose, et cela n'a rien de sur, que le nombre
de signatures affecte la vitesse d'analyse).J'ai donc suggere'
d'utiliser ESAFT comme base pour les tests : il n'est detecte' que
grace a sa "signature" (ce n'est pas un virus et il n'a pas de
comportement viral), il ne risque pas d'endommager le systeme de test,
tous les antivirus le detectent, c'est un simple fichier COM et il
peut etre modifie' facilement.
Effectivement, on se doutait bien qu'ESAFT devait etre traite' de
maniere un peu particuliere par les AVs, et que du coup
l'interpretation des resultats serait sujette a caution. Mais les
premiers tests (JMP et NOP en tete de fichiers) ont montre', sur
certains AVs utilises pour les tests (qui ne sont pas forcement ceux
cites dans l'article d'AMcD, d'ailleurs) ont permis de conclure que le
code etait au moins pseudo-emule', et que des fichiers qui n'etaient
pas ESAFT etaient quand meme detectes comme ESAFT (avec ces AVs).

Du coup, on a voulu pousser un peu plus loin.
--
I disagree. At the beginning of the discussion that lead to this
article (OK, this aspect disappeared in the article, and anybody that
didn't follow the whole discussion on fr.comp.securite.virus can not
guess that) was the following question :
"how do AV products manage to analyse so efficiently (in terms of
detection rate and of speed) such a large amount of files, with such a
number of "signature" (or scan strings/patterns/whatever). They
probably have to "reject" as soon as possible as much signatures as
possible in order to reduce the number of false positives and to
improve the scan speed (assuming that the number of signatures affect
the scan speed, which is not sure).I therefore suggested to use the
EICAR test string : it is detected only tanks to its "signature" (its
not a virus and does not have a viral behaviour), it's safe, every AV
detetects it, its a simple COM file and can be modified easily.

Actually, we supposed that ESAFT might not be exactly treated as a
real virus, and that we should be cautious when drawing conclusions
from the detection of ESAFT "variants". But the first tests (JMP and
NOP at the beginning of the file) have shown, done with some AVs (that
are not alwas the same as the ones used by AMcD in his article) that
the code was emulated or pseudo-emulated and that files that were not
ESAFT were detected as ESAFT (using these particular AVs). We therefore
decided to see if we could go a bit further.

> Don't know about the other products, but ours (F-PROT) even
> *disinfects* it as a virus. It treats it as a simple overwriting
> COM infector.

Mais il ne s'agit pas d'un overwriter ! Cela explique peut-etre
certains des faux-positifs d'F-Prot qui se referent a une variante de
Trivial.
--
But it does not overwrite anything ! Maybe it explains some of the
false positives of F-Prot concerning Trivial variants.

> Precisely. It's not even designed to test their virus detection
> abilities and MUST NOT be used for such purposes. The ability of an
> anti-virus product to detect the ESATF is completely unrelated to
> its ability to detect other viruses. Just because a product detects
> the ESATF does not necessarily mean that it also detects viruses
> and how well. It only tells us that the product is active and
> working.

OK.

> This is another important point, because in your experiments you
> have used the ESATF (and various modifications of it) for such
> purposes as to test the abilities of the heuristics to detect new
> variants, to discover (unsuccessfully)

Je dirais plutot "avoir une idee de". Et je parlerais plutot
d' "identification generique" plutot que d'heuristiques.
--
I would say "have some hints on". And I would talk of "generic
identification" instead of heuristics.

> what detection techniques are used, etc. This is WRONG and
> MISLEADING. The ESATF is simply NOT SUITABLE for such purposes.
> And test results obtained in this aspect are wrong, misleading,
> incompetent.

> No. The "real ones" don't "evolve". Only a very small class of them
> (the so-called polymorphic viruses) modify themselves as they
> replicate - and only in a relatively restricted way. The computer
> viruses don't "evolve" like the biological ones. They
> are only modified by humans (and occasionally by the programming
> environment).

Je crois qu'ici, il y a juste un probleme de vocabulaire :
l'"evolution" a laquelle fait reference AMcD est une modification
de l'executable d'origine qui peut avoir ete ajoutee manuellement.
--
Let's say that that this "evlution" can be due to human being. I guess
this is just a problem of vocabulary.

>> FAV EICAR_Test_File (exact).

> Note the word "(exact)". When F-PROT says that, it *means* it.

Grumpf. Il faut que je retrouve le message de F. Bonroy qui parle de
ca...
--
Grumpf. I have to find out a message of F. Bonroy on that patricular
subject.


> The result is no longer "the ESATF". Pure and simple.
> Since it is no longer that, it can no longer be used
> for the purposes for which the ESATF can be.

Heureusement qu'AMcD n'utilise pas ce fichier pour savoir si son AV
marche bien.
--
Fortunately, AMcD does not use it to see if his AV is working properly.


> PAV is wrong, because this is no longer the ESATF.
> The others are right, although AAV and FAV provide more information
> than is strictly necessary.

Pour resumer, F-Prot fait un faux positif...
--
Simply speaking, FAV does a false positive.

> Wrong. Only one of them (PAV) isn't aware of it. The others are aware
> of it and correctly no longer report the thing as "the ESATF".

D'accord.
--
I agree.


> Dunno about the other products, but F-PROT does not use signatures to
> detect this particular "virus". It uses checkpoints and a map of the
> non-variable areas (there is only one such area, covering the whole
> EICAR Test String).

Je dois dire que j'aimerais en savoir un peu plus sur ces checkpoints
et cette "map".
--
I must say that I would like to know more about these checkpoints and
this map.

> Even if somebody would use a "signature" ("scan string" is a more
> appropriate term), there is absolutely no need to use a wildcard
> scan string for a virus that contains no variable areas.

Tout depend de ce que vous entendez par "variable". Ce qui est
succeptible d'etre modifie' manuellement par quelqu'un sans affecter le
comportement de l'executable pourrait aussi etre considere'
comme "variable".
--
It depends on what you consider as "variable". What is likely to be
modified manually by a human without affecting the behaviour of the
executable might be considered as "variable".

>> Tons of viruses variants are simply alterations
>> of some bytes of the genuine virus.

> Of course. So what? You are mixing two very important things here:

> 1) The ability of the scanners to detect known viruses.

> 2) The ability of the scanners to detect unknown viruses.

> Two very different sets of methods are used to achieve these two
> goals.
> Known viruses are detected using known-virus techniques. Unknown
> viruses are detected using heuristics. Since heuristics are likely to
> cause false positives, they are usually used only to detect code that
> looks very virus-like.
> The ESATF code does not, so few producers waste heuristics to detect
> its possible modifications - not to mention that it's completely
> unnecessary.

Mais F-Prot le detecte comme une variante de trivial en utilisant des
heuristiques, non ?
--
But F-Prot detects it as a trivial variant using heuristics, am I right
?

> Wrong. The difference between a virus that formats your hard disk and
> one that doesn't can be only a single bit. And that bit doesn't have
> to be part of the executable code, either. It could be some kind of
> data flag - or even a character in a text message.

OK. Mais quand ce n'est pas le cas, et pour des chaines de caracteres
comme celle-ci, il se pourrait que ca ne soit pas un tres bon choix. Il
y a des variantes d'IRC bots ou de chevaux de troies pour lesquels la
seule variation constatee reside dans une chaine "wr1tt3n bY l4M3r".
--
OK. But when it is not the case, and for character strings like this
one, it may not be a good choice. There are some IRC bots /
trojans "variants" in which the only "variation" is contained in
a "wr1tt3n bY l4M3r" string.

> This is not absurd at all.

Je pense que si : detecter un fichier qui contient *seulement* la
chaine "Eddie lives...somewhere in time!" n'est pas tres malin, etant
donne' l'apparente sophistication des methodes utilisees par les
antivirus pour detecter des virus.
--
Actually, it is : detecting a file containing *only* the string "Eddie
lives...somewhere in time!" is not very smart, given the apparent
sophistication of the methods used by AV products to detect viruses.

> In your ignorance you probably don't know it, but besides infecting
> files, the Dark Avenger virus can also damage them. The damage is
> performed by overwriting a random sector with the first 512 bytes of
> the virus body.
> Believe it or not, these 512 bytes begin with this text message.

Cela evite sans doute les faux negatifs, mais malgre tout, ca n'est
pas une signature tres intelligente.
--
It avoids false negatives, and still, its not a smart signature.

> Your guess is wrong. The anti-virus producers have to make tradeoff
> decisions all the time. They might very well decide not to try to
> detect new variants of something that is not likely to produce new
> variants, especially if it doesn't pose a threat and/or if doing so
> is likely to cause false positives.

Comme cela a ete dit precedemment, ces decisions etaient le sujet de la
discussion qui a conduit a l'ecriture de cet article. Cela aurait du
etre mentionne' dans l'article.
--
As previously said, these tradeoff decisions were the subject of the
discussion that lead to this atricle. It should have been mentioned in
the article.

>> At last, a strange idea comes to my mind: do some AVs bypass stages
>> if a "known" virus doesn't look like what it's supposed to be? I
>> mean, if a virus isn't, for example, supposed to be encrypted, is
>> this possibility purely bypassed during scanning?

> It depends on the virus and on the product. You are making the
> capital mistake of assuming that all products work the same way and
> treat all viruses equally.

Pourquoi tester plusieurs antivirus dans ce cas ? Tester plusieurs
virus reels est une bonne suggestion.
--
If it had been assumed, why to test several AVs ? Testing several real
viruses is a good suggestion.

>> If so, detection
>> of known viruses variants is confronted with a strong limitation...

> Yep, detection of known virus variants has one very strong
> limitation - it can detect only the known virus variants! (But, hey,
> isn't that its job by definition?!)

Comment definir "variante", la est la question. Peut-etre que je
comprends mal cette phrase : doit-on comprendre variantes de virus
connus ou variantes connues de virus.
--
How do you define "variant" ? Here is the point ! Maybe I've a problem
understanding this sentence : should I understand known(virus variants)
or (known virus) variants ?

> To detect unknown virus variants, you need something else.
> There are various "something elses". There are heuristics, which
> try to detect code that seems to be performing virus-like behavior.
> There are integrity checkers, which try to detect the modifications
> the virus introduces in the infected system. There are behavior
> blockers, which try to detect the functions invoked by a virus during
> its replication. One common problem among all these different means
> is that they are not exact. They cause both false positives and false
> negatives. They also require a somewhat higher level of knowledge and
> intelligence from their users - which is why many of them aren't
> widely used (given that more than 97% of the human consists of
> idiots, as I have demonstrated in a paper of mine)

Je fais partie des 99.99% qui n'ont pas eu la chance de lire cet
article. Et des quelques uns qui aimeraient que les AVs soient plus
explicites quand ils disent "New virus detected". J'*aimais*
les "flags" de TBAV.
--
I'm one of the 99.99..9% of idiots that did not have the luck to read
this paper. And of the few ones that would like AVs to be more explicit
when they say "New virus detected". I *liked* TBAV flags.


>and when they are used they are usually toned down.

>> Let's go one step further, what about emulation? In the first test,
>> we just add a NOP (90h) instruction at the beginning of ESATF. Of
>> course,

> The result is no longer "the ESATF". Therefore, it is no longer
> suitable for the purposes that the ESATF is. End of story.

Et il n'est pas utilise' dans avec le meme objectif qu'ESAFT.
--
And it is not used here for the same purposes that the ESAFT is.

> Wrong. All of the anti-virus products are correct, but FAV provides
> more information than strictly necessary. Since the file is no longer
> the ESATF, none of the products reports it as the ESATF.
> Therefore, they are all correct.

Faux. Tous les antivirus reagissent correctement, a l'exception de
F-Prot qui produit un faux-positif.
--
Wrong. All of the anti-virus products are correct, but FAV produces
a false positive.

>> but F-Prot is on the bad path;
>> Trivial is a family of short in size COM infectors damaging one
>> single file at a time. Nothing to do with ESATF!

> Wrong again. Trivial is a very special virus family.
> Normally, viruses are grouped into families according
> to the similarity of their replication code. The Trivial family,
> however, is one of the relatively few exceptions. By definition, it
> contains simple (less than 100 bytes of code) overwriting COM
> infectors.
> As I mentioned in the beginning, our product treats the ESATF as an
> overwriting COM infector (and will even disinfect it as such).
> Is it any wonder, then, that modifications of it are reported as a
> new variant of such a virus?

Appelons ca un faux positif, alors...
En fait, ce type de detection de "trivial" est peut-etre ce que
je designais par le terme "identification generique".
--
Just call it a false positive, then....
By the way, this kind of detection of "trivial" might be what I called
"generic identification".

> But that's just us. We're perfectionists, you see - we try to provide
> even more information than strictly necessary. Just not reporting the
> file as the ESATF is correct enough.

Puis-je oser un petit "mouarf" ?
--
Can I dare a little "mouarf" ?

>> In the second test, we bypass ESATF: we simply jump to the end of
>> the code where an int 20h instruction ends the process. ESATF is
>> never ()
> [No detection]
> And rightly so! (...)
> If anything, it means that the emulation correctly detects that the
> code does nothing and just exits - that's why the products report
> nothing.

D'accord
--
I agree...

[snip the XORed ESAFT test]

>> Well, now... the great show: file search and replication parts are
>> included! The final code is similar to what we found in the past
>> inside true lamer COM overwriter viruses:

> This is now a virus (while again it is no longer the ESATF). I don't
> think that the moderator of this forum should have permitted the
> posting of virus source here.

>> You may think "well, overwriters viruses are known for ages,
>> heuristics will defeat this kind of code".

> Again, depends on the product and on its heuristics. The different
> products work in different ways and use different methods.

....mais sont tous concus de maniere a detecter les virus, y compris les
nouveaux, non ?
--
...but are all designed to detect viruses, including new ones, am i right
?


> FAV and VAV show stellar performance - they have detected the new
> virus.

Formidable, et ce coup-ci, ca n'est plus un faux positif de FAV !
--
Great, and this time, it's not a false positive anymore for FAV !

> RAV is wrong, because this is not the ESATF.

OK.

> The other products are just right - this is not a known virus,
> so they don't detect any known viruses in the file.

Ils n'on _pas_ raison, en faisant l'hypothese que la detection par
heuristiques etait activee. Ca n'est pas un virus connu et pourtant,
c'est un virus. Ils devraient avoir detecter un nouveau virus.
--
They are _not_ right, assuming heuristic detection was enabled.
It is not a known virus, and still, it is a virus. They should
have detected a new virus.

>> user. Even not really accurate, McAfee approch is more "safe".
>> F-Prot > finds a Trivial variant; this time, it's a good answer.

> The previous time it was a good answer too - better than necessary, in
fact.

Nope.

>> This time, let's replace "goat.com" by "*.com" at step 19 in
>> Figure 15 source code:
>
>> AAV Found unknown virus .EXE.COM.
>> BAV Is infected with Trivial.136.Gen.
>> CAV N/D.
>> FAV New or modified variant of Trivial.
>> KAV Type_Trivial.
>> NAV Bloodhound.DirActCOM.
>> PAV N/D.
>> RAV Trivial-based.136.
>> VAV Univ.ow/e.

> All of them are right, although I'm not quite sure what the VAV
> report means.

C'est une detection generique : ow = overwriter
--
Its a generic detection : ow == overwriter

>> Note that NAV uses a very strange naming.

> It's a very logical one, though. The "Bloodhound." prefix means that
> this report is produced by the heuristics - not by the known-virus
> scanner. The "DirAct" part means that this is a direct-action (i.e.,
> non-resident) virus. The "COM" part means that it is a COM-only
> infector. Lots of info stuffed in a short report - and all of it
> correct. Bravo, NAV!

>> Once connected to their "security response" page, I only get a "No
>> additional information."... not very explicit!

> But very correct. Since this is a new virus, by definition it is not
> a known one. Since it is not known, there can be no additional
> information about it!
> Simple, eh?

Il pourrait y avoir une courte explication, par exemple :
--
There could be a short explanation, for example :

|The "Bloodhound." prefix means that this
|report is produced by the heuristics - not by the known-virus scanner.
|The "DirAct" part means that this is a direct-action (i.e., non-
--
Direct access to this group with http://web2news.com
http://web2news.com/?alt.comp.anti-virus

...and the end (stupid web2news) :

|The "DirAct" part means that this is a direct-action (i.e., non-
|resident) virus. The "COM" part means that it is a COM-only infector.

Simple et pratique, hein ?
--
Simple and useful, eh ?

Autrement, quand ce n'est pas explique', il se pourrait que l'on
ne soit pas sur de ce que veut dire quelque chose comme "Univ.ow/e".
Particulierement s'il fait partie des 97%.
--
Otherwise, when it's not explained, one might not be sure of what means
something like "Univ.ow/e". Especially if you are part of the 97%.

[snip the end]

--
Tweakie
--
Direct access to this group with http://web2news.com
http://web2news.com/?alt.comp.anti-virus

Frederic Bonroy wrote:

> I would have preferred it if Mr. Bontchev had *refuted* the claims
> instead of *demolishing* them.

Well, actually it's a sad story... and it's not the goal I aimed!

Mr Fitzgerald and Bontchev use the power of their mind (their energy?) in
order to refuse to understand why I wrote this text; they don't even care
about the title.

Above all, Mr Bontchev shows he can be "dishonest" sometimes! First, he only
replies on ntbugtraq, a place where I never go, where I never published
anything. A place with a big moderator too ;o). Mr Skulason did not reply to
my mails either (he also replies in a place I didn't know). Then, he's very
prejudiced against me; he uses a kind of "bad faith" not very "chivalrous",
as you say, he always demolishes, he argues about nothing. Maybe he took the
story for him. It's a mistake, I have nothing against his AV or any other
AV. I just want to say that they're not perfect. So far from it!

Of course, I made some mistakes in this text, but I did not deserve so rude
reaction from them. It was a "fun" text.

How sad.

--
AMcD

http://arnold.mcdonald.free.fr/
(still in fossilization progress but now in english, thus the whole
world can see my laziness)

On Sun, 6 Jul 2003 21:35:07 +0200, "Arnold McDonald \(AMcD\)"
<(E-Mail Removed)> wrote:

>The worst disappointment relating this affair is
>that a few ones have not understood the title "let's have fun...". I'll do
>better next time.

Shouldn't be a disappointment, in fact the hypersensitivity, and
borderline immaturity, amongst the responses is quite revealing <g>

Bart

"Guillermito" <(E-Mail Removed)> wrote:

> On the other hand, just for the sake of arguing a bit, ...

Ohhh goody, argument for argument's sake... 8-)

> ... I think he's
> wrong in one minor point involving F-Prot (well, that's
> understandable, he works there). Arnold does a test by inserting a
> "nop" in front of the EICAR file. No anti-virus detects this new file,
> and they are obviously all right. But F-Prot reports it as "New or
> modified variant of Trivial". Vesselin comments on that by saying "we
> try to provide even more information than strictly necessary". Well,
> maybe, and we all know that F-Prot is pretty good both for identifying
> known viruses and discovering unknown viruses, but in this particular
> case I think F-Prot is just wrong. An EICAR file with a "nop" at the
> beginning is *not* some new or modified version of a lame overwriting
> virus. It does not have anything that looks like a virus. It should
> have reported nothing at all. Same goes for the modification with just
> a decryption loop, although it's one routine that may be found in real
> viruses. The next tests are about modifications that now give the file
> some real infection abilities, and of course this time F-Prot is right
> by saying "New or modified variant of Trivial".

I understand how you would come to that conclusion but I also understand
why F-PROT comes to its "conclusion". Self-modifying code and "only use
printable characters to make it look like something else" are probably
both fairly high-weight heuristics (and not just in F-PROT, I would guess
in most engines with heuristics for detecting "trivial" COM and/or EXE
infectors). Further, the EICAR test string, either whole or almost
complete has been used in many viruses as a "dupe" because, in the past
(fortunately this is getting better!) some (way too many!) scanners would
detect the EICAR string where they shouldn't (i.e. elsewhere than file
offset zero) and as most such scanners stop looking when they make one
detect, they would report the "safe" EICAR test string for what was, in
fact, something nasty or otherwise unwanted. It is therefore quite
conceivable that the appearance of the EICAR test string other than at
file offset zero could also be used as a fairly high weight heuristic.

If these factors come into play in F-PROT, then that could well explain
F-PROT detecting _something_ in the NOP+<EICAR> file. But why "New or
modified variant of Trivial"? This has puzzled me before, as Arnold's
"work" is not the first to "mess with" the EICAR test string. I am not
sure of the answer. Vesselin says that F-PROT uses a single invariant
area map covering the whole of the EICAR test string, and I guess it is
the fact that that map does not match but the code checkpoints do that
resulted in Arnold's "STANDARD" --> "STANDING" modification to cause
F-PROT to report "EICAR_Test_File.unknown?" for that file. Not however,
that F-PROT did not report the NOP + <EICAR> file thus, but rather as
"New or modified variant of Trivial". As the reported name form is
different from the "STANDARD" --> "STANDING" example, presumably that
means this detection is more heuristically based and less "it's bearably
close to a known virus" based. If this, or something like it, is the
case here (and I am making quite a few guesses about how F-PROT's
detection engine works) then presumably one or more (or the grouping)
of the high-weight heuristics that are triggered by the NOP + <EICAR>
file is/are associated in the F-PROT detection definition files with the
Trivial family name and a "probably a Family_X" style report, rather
than a "very simialr to Virus_Y but not quite exact" one is produced.

Or it could be all manner of other things...

Maybe you should ask Frisk, although I would understand if he were not
keen to get into the details too much! 8-)


--
Nick FitzGerald

"Arnold McDonald (AMcD)" <(E-Mail Removed)> wrote:

> Not at all Nick. You are right, someone posted a pointer to some mailing
> list, I know, but it's not me. I'm not interested by NTBugtraq and so on, I
> never go there. I don't know who is the guy who posted, I had a "polite" row
> with him relating this fact.

OK -- sorry for saying it was you then...

> > posted Arnold's message a day or so ago and it fairly quickly drew a
> > long
> > and detailed response from Vesselin Bontchev who, with more paitence
> > than
> > I was prepared to devote to the exercise, demolished Arnold's claims,
> > "experiments" and conclusions one by one.
>
> Demolish? It's your own opinion! ...

True, it is my opinion, but by my reckoning he did not leave a single
"interesting" claim of yours standing. "Demolish" seems like a good
description of such a thorough critique and is commonly used in English
in precisely that context.

> ... Sometimes he's right, sometimes he shows
> how dishonest he can be. ...

As your tone implies he does this several times, you should have no trouble
citing one clear example of this...

> ... The worst disappointment relating this affair is
> that a few ones have not understood the title "let's have fun...". I'll do
> better next time.

And what I think you misunderstand something fairly fundamental too... If
you are going to make what you present on its face as an experimental,
technical anaylsis of how some technically complex applications work, then
the folk who worked hard at creating those applications (and who have long
since solved all manner of technical problems your "analysis" quite clearly
shows you are entirely ignorant of) will feel reasonably entitled to
ridicule and belittle your "work". You claim that you were "just having
some fun", but your presentation was not satirical and you ended up coming
across as bungling amateur with next to no understanding of the fundamental
issues in the area you were analysing and criticizing. Much as the target
of such comments may be hurt by them, it is not wrong per se for informed
respondents to such efforts to point out the bungling, childish ineptitude
of the wannabe critic.

I am a critic of much of modern AV, security and OS technology, and a fairly
staunch critic of much of it, but I pretty much entirely agree with
Vesselin's response to your claims. The bottom line is you are wrong for
the reasons Vesselin cites and there are much better grounds on which to
criticize the industry, its general approaches and the products.


--
Nick FitzGerald

"Bart Bailey" <(E-Mail Removed)> replied to "Arnold McDonald \(AMcD\)":

> >The worst disappointment relating this affair is
> >that a few ones have not understood the title "let's have fun...". I'll do
> >better next time.
>
> Shouldn't be a disappointment, in fact the hypersensitivity, and
> borderline immaturity, amongst the responses is quite revealing <g>

Revealing of what Bart?

Revealing of a level of surprise at the sheer ignorance that is repeated
year after year after year by those who claim some modest technical
ability and understanding of the basics of what virus scanners do?

Revealing of a level of surprise at an apparent wilful disdain of many
would-be critics for even beginning to try to understand what it was they
are criticizing or how it works?

Fercrissakes Bart -- he tried to draw conclusions about how AV products
detect viruses using a non-malicious, non-viral test file that has been
agreed, within the industry, to be treated as a special case and detected
"as if" it were a virus. Further, he deigned to applaud and criticize
products for their -- in his ignorant and/or misinformed eyes -- "good"
and "poor" performances on his mispaced "tests". (And, in a few cases
where some sensibe suggestions along these lines could be drawn from his
results, he got most of those calls wrong, which given it was binary
call means he significantly undershot chance performance.)

He was not only wrong, he was stupefyingly obviously outright wrong.

If Arnold did not deserve to be criticized for that, how wrong does
someone have to be before they deserve being criticized?

Or is it OK for anyone to make any criticism of the AV industry but wrong
of anyoine in that industry to ever respond negatively to any criticism,
no matter how ignorant, wrong-headed, deliberately misleading, etc, etc??


--
Nick FitzGerald

Nick FitzGerald wrote :
> I understand how you would come to that conclusion but I also
> understand why F-PROT comes to its "conclusion".
> [...]
> Or it could be all manner of other things...

Although some (most ?) of the arguments presented by Mr. Bontchev
are very sensible, I am deceived by his attitude concerning a couple
of points :

1/ F-Prot false positives
2/ Lack of efficiency of heuristics vs. a simple COM overwriter
3/ Arguing for arguing about NAV naming

1/ His claims about F-Prot reporting "more information than
necessary" whereas F-Prot detection clearly corresponds to
false positives (NOP and XOR cases). IMHO, Acceptable answers
would be somethin like : EICAR_TEST_FILE.modified or N/D. On
this particular point, his argumentation is really specious :

He first says (about original ESAFT) :
|"It treats it as a simple overwriting COM infector.
|Keep that in mind - it is important when addressing some other
|of your points."

then he adds :
|"The above 68 characters *MUST* be at the beginning of the file.
|If they aren't there, it's not the ESATF - it's that simple. Any
|anti-virus product that detects as "the ESATF" something which is
|not it is wrong." and "The ESATF code does not, so few producers
|waste heuristics to detect its possible modifications - not to
|mention that it's completely unnecessary" followed by a couple of :
|"IT IS NO LONGER THE ESATF!!!"

Finally, he details :
|"Wrong again. Trivial is a very special virus family. Normally,
|viruses are grouped into families according to the similarity
|of their replication code. The Trivial family, however, is one
|of the relatively few exceptions. By definition, it contains simple
|(less than 100 bytes of code) overwriting COM infectors. As I
|mentioned in the beginning, our product treats the ESATF as an
|overwriting COM infector (and will even disinfect it as such).
|Is it any wonder, then, that modifications of it are reported as
|a new variant of such a virus?"

This is *completely inconsistent*. Moreover, after reading
Fridrik Skulason answer on mailin.unix.bugtraq, it apears to
be simply *wrong* :

Fridrik Skulason wrote :
|"Actually, it is not. A few years ago somebody wrote a virus which
|started out just like the EICAR file, but had a jump at the end to
|typical Trivial-like code. Many anti-virus programs, including F-PROT
|actually detected that file as a new variant of EICAR, which was not
|acceptable, as
|it implied the file was harmless.
|
|We decided to do the following:
|
|If the file is exactly as it should be, it is reported as Eicar
|(exact).
|
|If the code seems to be unmodified, but the text string is different,
|report a new wariant of Eicar.
|
|If the code is different, report this as a variant of the Eicar-like
|Trivial virus, just to be on the safe side. This is what we are
|doing. F-PROT is detecting the modified file as a variant of the
|Trivial file."

This make sense. And still, it is a false positive. I agree to
say that this kind of false positive does not have a great impact
(euphemism, I know). I just do not understand why Mr. Bontchev does
not concede that it is a false positive, and why he invents an
explanation that do not seem to be the good one. He acts as a marketing
guy here, not as a technician.

2/ Every user would expect the final little COM overwriter to be
detected by heuristics. It's a really lame virus and we have been
surprised to see that lots of AVs missed it. I find it surprising
that Mr. Bontchev consider that all AVs are right. And I'm quite
sure that all the AVs that have been used for the tests have
"detects unknown/new viruses" written somewhere on their box.

3/ Why not conceding that it would be better if it was easy to
find a clear explanation of NAV heuristic alert on NAV website ?
We see enough people asking "what does mean Bloodhound.*.*" on
fr.comp.securite.virus to know that it would be better if they
did so. OK, its a detail. Why to argue about such a detail, so
(and why am I doing so, wou may ask) ?

--
Tweakie

--
Direct access to this group with http://web2news.com
http://web2news.com/?alt.comp.anti-virus