Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
Re: Let's have fun with EICAR test file
Date: Wed Jul 09 2003 - 10:21:29 CDT
-----BEGIN PGP SIGNED MESSAGE-----
>What a piece of incompetent crap.
> (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.
That's the interesting point. Maybe you noticed that ESAFT is at the
beginning of memory in almost all the tests? Furthermore, some AVs
detect it even though it's not ESAFT!
> 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.
Good point. Some of my files are greater than 128 bytes. But, again,
I just wanted to show some weird results. No more. And whatever you
could say... some results are weird!
> 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.
But it is not ESATF remember? And according to you..."any anti-virus
product that detects as "the ESATF" something which is not it is wrong"
Maybe it explains some of the false positives of F-Prot concerning
> 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
>> FAV EICAR_Test_File (exact).
> Note the word "(exact)". When F-PROT says that, it *means* it.
What are these technical reasons for this?
> 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.
Agreed. But some AV's are definitely proving you and me wrong ;-)
> 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.
Can it be that 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".
>> 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
> Known viruses are detected using known-virus techniques. Unknown
> viruses are detected using heuristics. Since heuristics are likely
> 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
But F-Prot detects it. After all, when ESAFT is altered, it's not ESAFT
> 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.
You have uncanny insight here? ;-)
>> 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...
It's a particurlarly a big limitation. Maybe what this paper is about?
>> 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
> The result is no longer "the ESATF". Therefore, it is no longer
> suitable for the purposes that the ESATF is. End of story.
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.
Wrong. All of the anti-virus products are correct, but FAV produces
a false positive. You know that ESAFT with a NOP instruction is not
a Trivial variant at all.
>> 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
> 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?
Just call it a false positive, then....
>> 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
>> 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.
..but are all designed to detect viruses, including new ones, is that
not the sales pitch?
> FAV and VAV show stellar performance - they have detected the new
Bravo, and this time, it's not a false positive anymore for FAV !
>What you probably consider a "scientific paper" is actually full of
Please read the title again, "Let's have fun". I bet you'll find the
next one more "scientific"... or less "funny" according to your preference!
maybe, maybe not speaking for AMcD Hardware International
-----BEGIN PGP SIGNATURE-----
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.3
-----END PGP SIGNATURE-----
Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2
Free, ultra-private instant messaging with Hush Messenger
Promote security and make money with the Hushmail Affiliate Program:
Are You "Certifiable"? Summer's Hottest Certification Just Got HOTTER!
With a growth rate exceeding 110%, the TICSA security practitioner
certification is one of the hottest IT credentials available. And now, for
a limited time, you can save 33% off of the TICSA certification exam! To
learn more about the TICSA certification, and to register as a TICSA
candidate online, just go to