http://www.ntbugtraq.com/default.asp?pid=36&sid=1&A2=ind0307&L=ntbugtraq&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)
(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.
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".
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.
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.
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.
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.
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]
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.
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.
The previous time it was a good answer too - better than necessary, in fact.
Nope.
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
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!
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-
