j'sais pas si la page va rester longtemps en ligne tellement c'est HS
j'sais pas si la page va rester longtemps en ligne tellement c'est HS
j'sais pas si la page va rester longtemps en ligne tellement c'est HS
Car je ne vais pas en rester là. Si ce premier article était pour le fun,
mais vraiment pour le fun (ils auraient pu essayer de comprendre le titre
déjà...), les autres seront bien plus scientifiques et, désolé pour eux,
bien plus décevant encore quant au résultat délivré par leurs produits.
Car je ne vais pas en rester là. Si ce premier article était pour le fun,
mais vraiment pour le fun (ils auraient pu essayer de comprendre le titre
déjà...), les autres seront bien plus scientifiques et, désolé pour eux,
bien plus décevant encore quant au résultat délivré par leurs produits.
Car je ne vais pas en rester là. Si ce premier article était pour le fun,
mais vraiment pour le fun (ils auraient pu essayer de comprendre le titre
déjà...), les autres seront bien plus scientifiques et, désolé pour eux,
bien plus décevant encore quant au résultat délivré par leurs produits.
D'abord parce qu'ils n'ont rien compris au texte.
D'abord parce qu'ils n'ont rien compris au texte.
D'abord parce qu'ils n'ont rien compris au texte.
Arnold McDonald (AMcD) wrote:
Si j'ai bien compris, vous allez mener une étude scientifique dont
vous connaissez déjà le résultat ?
Arnold McDonald (AMcD) wrote:
Si j'ai bien compris, vous allez mener une étude scientifique dont
vous connaissez déjà le résultat ?
Arnold McDonald (AMcD) wrote:
Si j'ai bien compris, vous allez mener une étude scientifique dont
vous connaissez déjà le résultat ?
http://www.ntbugtraq.com/default.asp?pid6&sid=1&A2=ind0307&L=ntbugtraq&F=P
&S=&P$24
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.
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.
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.
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.
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.
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)
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).
FAV EICAR_Test_File (exact).
Note the word "(exact)". When F-PROT says that, it *means* it.
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.
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.
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".
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).
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.
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.
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.
This is not absurd at all.
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.
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.
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.
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?!)
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)
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.
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.
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?
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.
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.
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.
FAV and VAV show stellar performance - they have detected the new
virus.
RAV is wrong, because this is not the ESATF.
The other products are just right - this is not a known virus,
so they don't detect any known viruses in the file.
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.
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.
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?
http://www.ntbugtraq.com/default.asp?pid6&sid=1&A2=ind0307&L=ntbugtraq&F=P
&S=&P$24
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.
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.
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.
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.
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.
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)
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).
FAV EICAR_Test_File (exact).
Note the word "(exact)". When F-PROT says that, it *means* it.
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.
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.
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".
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).
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.
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.
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.
This is not absurd at all.
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.
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.
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.
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?!)
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)
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.
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.
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?
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.
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.
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.
FAV and VAV show stellar performance - they have detected the new
virus.
RAV is wrong, because this is not the ESATF.
The other products are just right - this is not a known virus,
so they don't detect any known viruses in the file.
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.
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.
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?
http://www.ntbugtraq.com/default.asp?pid6&sid=1&A2=ind0307&L=ntbugtraq&F=P
&S=&P$24
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.
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.
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.
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.
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.
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)
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).
FAV EICAR_Test_File (exact).
Note the word "(exact)". When F-PROT says that, it *means* it.
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.
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.
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".
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).
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.
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.
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.
This is not absurd at all.
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.
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.
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.
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?!)
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)
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.
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.
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?
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.
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.
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.
FAV and VAV show stellar performance - they have detected the new
virus.
RAV is wrong, because this is not the ESATF.
The other products are just right - this is not a known virus,
so they don't detect any known viruses in the file.
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.
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.
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?
"Arnold McDonald (AMcD)" :
Petit conseil pour éviter les emmerdes légales comme j'ai avec Tegam:
pas de reverse engineering, même anecdotique, des anti-virus. Et/ou un
serveur ailleurs qu'en France, pays dans lequel il est un peu trop
facile de faire peur aux ISP.
Sinon, je pense que Vesselin B. a raison dans sa critique de ton
article sur NTBugtraq. Il est évidemment arrogant, ce qui est habituel
chez lui comme chez Nick F., mais il a raison sur le fond. Le fichier
EICAR doit avoir des caractéristiques très précises pour être détecté.
On ne peut pas l'utiliser pour tester la capacité des anti-virus à
détecter des virus inconnus, puisque ce sont deux mécanismes
complètement différents (détection de virus connus et détection de
virus inconnus). A partir du moment où on modifie EICAR, on ne peut
plus tirer aucune conclusion, même si c'est toujours amusant de
vérifier pour le fun les réactions de plusieurs anti-virus (je l'ai
fait aussi).
Ce qui est surprenant, ce ne sont pas les antivirus qui ne
reconnaissent pas un EICAR modifié (ce qui devrait être le comportemnt
normal), c'est que certains reconnaissent ces fichiers modifiés comme
un EICAR standart.
Quant à F-Prot, malgré ce que peut en dire Bontchev, il se plante deux
fois en reconnaissant un EICAR modifié (mais sans routine virale:
celui avec le "nop" et celui avec une boucle de cryptage XOR) comme
une version de Trivial, comme je l'ai noté tout à l'heure sur
alt.comp.virus.
"Arnold McDonald (AMcD)" <arnold.mcdonald@free.fr> :
Petit conseil pour éviter les emmerdes légales comme j'ai avec Tegam:
pas de reverse engineering, même anecdotique, des anti-virus. Et/ou un
serveur ailleurs qu'en France, pays dans lequel il est un peu trop
facile de faire peur aux ISP.
Sinon, je pense que Vesselin B. a raison dans sa critique de ton
article sur NTBugtraq. Il est évidemment arrogant, ce qui est habituel
chez lui comme chez Nick F., mais il a raison sur le fond. Le fichier
EICAR doit avoir des caractéristiques très précises pour être détecté.
On ne peut pas l'utiliser pour tester la capacité des anti-virus à
détecter des virus inconnus, puisque ce sont deux mécanismes
complètement différents (détection de virus connus et détection de
virus inconnus). A partir du moment où on modifie EICAR, on ne peut
plus tirer aucune conclusion, même si c'est toujours amusant de
vérifier pour le fun les réactions de plusieurs anti-virus (je l'ai
fait aussi).
Ce qui est surprenant, ce ne sont pas les antivirus qui ne
reconnaissent pas un EICAR modifié (ce qui devrait être le comportemnt
normal), c'est que certains reconnaissent ces fichiers modifiés comme
un EICAR standart.
Quant à F-Prot, malgré ce que peut en dire Bontchev, il se plante deux
fois en reconnaissant un EICAR modifié (mais sans routine virale:
celui avec le "nop" et celui avec une boucle de cryptage XOR) comme
une version de Trivial, comme je l'ai noté tout à l'heure sur
alt.comp.virus.
"Arnold McDonald (AMcD)" :
Petit conseil pour éviter les emmerdes légales comme j'ai avec Tegam:
pas de reverse engineering, même anecdotique, des anti-virus. Et/ou un
serveur ailleurs qu'en France, pays dans lequel il est un peu trop
facile de faire peur aux ISP.
Sinon, je pense que Vesselin B. a raison dans sa critique de ton
article sur NTBugtraq. Il est évidemment arrogant, ce qui est habituel
chez lui comme chez Nick F., mais il a raison sur le fond. Le fichier
EICAR doit avoir des caractéristiques très précises pour être détecté.
On ne peut pas l'utiliser pour tester la capacité des anti-virus à
détecter des virus inconnus, puisque ce sont deux mécanismes
complètement différents (détection de virus connus et détection de
virus inconnus). A partir du moment où on modifie EICAR, on ne peut
plus tirer aucune conclusion, même si c'est toujours amusant de
vérifier pour le fun les réactions de plusieurs anti-virus (je l'ai
fait aussi).
Ce qui est surprenant, ce ne sont pas les antivirus qui ne
reconnaissent pas un EICAR modifié (ce qui devrait être le comportemnt
normal), c'est que certains reconnaissent ces fichiers modifiés comme
un EICAR standart.
Quant à F-Prot, malgré ce que peut en dire Bontchev, il se plante deux
fois en reconnaissant un EICAR modifié (mais sans routine virale:
celui avec le "nop" et celui avec une boucle de cryptage XOR) comme
une version de Trivial, comme je l'ai noté tout à l'heure sur
alt.comp.virus.
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.
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.
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.
"Arnold McDonald (AMcD)" :Car je ne vais pas en rester là. Si ce premier article était pour le fun,
mais vraiment pour le fun (ils auraient pu essayer de comprendre le titre
déjà...), les autres seront bien plus scientifiques et, désolé pour eux,
bien plus décevant encore quant au résultat délivré par leurs produits.
Petit conseil pour éviter les emmerdes légales comme j'ai avec Tegam:
pas de reverse engineering, même anecdotique, des anti-virus. Et/ou un
serveur ailleurs qu'en France, pays dans lequel il est un peu trop
facile de faire peur aux ISP.
"Arnold McDonald (AMcD)" <arnold.mcdonald@free.fr> :
Car je ne vais pas en rester là. Si ce premier article était pour le fun,
mais vraiment pour le fun (ils auraient pu essayer de comprendre le titre
déjà...), les autres seront bien plus scientifiques et, désolé pour eux,
bien plus décevant encore quant au résultat délivré par leurs produits.
Petit conseil pour éviter les emmerdes légales comme j'ai avec Tegam:
pas de reverse engineering, même anecdotique, des anti-virus. Et/ou un
serveur ailleurs qu'en France, pays dans lequel il est un peu trop
facile de faire peur aux ISP.
"Arnold McDonald (AMcD)" :Car je ne vais pas en rester là. Si ce premier article était pour le fun,
mais vraiment pour le fun (ils auraient pu essayer de comprendre le titre
déjà...), les autres seront bien plus scientifiques et, désolé pour eux,
bien plus décevant encore quant au résultat délivré par leurs produits.
Petit conseil pour éviter les emmerdes légales comme j'ai avec Tegam:
pas de reverse engineering, même anecdotique, des anti-virus. Et/ou un
serveur ailleurs qu'en France, pays dans lequel il est un peu trop
facile de faire peur aux ISP.
Noshi wrote:J'ai un serveur stu veux... :) (enfin faut que je remette apache et
finir de configurer qmail...
Tu vis où ? Enfin, ton serveur ;o)...
Noshi wrote:
J'ai un serveur stu veux... :) (enfin faut que je remette apache et
finir de configurer qmail...
Tu vis où ? Enfin, ton serveur ;o)...
Noshi wrote:J'ai un serveur stu veux... :) (enfin faut que je remette apache et
finir de configurer qmail...
Tu vis où ? Enfin, ton serveur ;o)...
