Malwaretestlab Crypter vs Antivirus Test

you havent got any idea about my samples.
you cant know.
how you can say "The malware what you submit is basically a new variant that you created yourself for such tests."
but i dont want to debate any more
you are true, perfect, right, great and more...and vipre too.WoW

 

I hope I am not mistaken, but, if memory still serves me, not so long ago - perhaps 1 or 2 years ago - a Portuguese science student managed to prove that one of Einstein's theories wasn't right or totally right.

So, anything is possible.

 

It's an urban legend. Try Ginkgo Biloba for your memory.

 

Hi,

what about the results of the test?
I mean apart from - this is questionable and that is wrong - quarreling.

Kaspersky and Bitdefender have really outstanding unpack engines? Yes/No

What about this "business class detection" of packed files?
Is this just a "I am the sheriff's deputy" ambition, like Ikarus or Sophos show.
An AV should detect malicious files and not tag a non threatening keygen as most.evil.malware.ever

If it comes to PE Packers, most often you can learn more about the AV industry than about malware.

Cheers

 

Just came back from a trip and saw this thread.

The tester here has done both a on-demand test and then also executed his own packed version in realtime.

So AVs with good unpacking skills would/should pick the malware in the on-demand scan itself.
Others will catch the malware on execution, when the sample unpacks itself.

So whats the argument about ??
Any decent AV should pick the malware using heuristics, sandboxing, Behavioral Blocking, etc. during execution of malware. The really good one would probably detect the malware in both on-demand also. In all the test seems very reasonable.

 

Ok so you also don't understand what i'm trying to say...

Is it really so difficult to understand that some AV's can emulate some packers to some extend were they CAN GET ENOUGH INFO to trigger a heuristic ( i don't mean here just simple packer detecting !!!! ) but don't reach the 1:1 unpacking binary hence don't detect the signature they created for?

That means if you pick another "origin" sample and not a "virtool" (because usually av's don't have generic rules for that) then quite a lot of av's would have flagged packed samples at least as "suspicious" were they simple detect nothing in the way it was done here.

Once again: You have to know how AV companies add malware. And i give here now a really last fact and if someone doesn't understand that please don't reply here and try to educate other people. As rude as this sounds but this has to be said in this way now.

Some of the malware can be added (for example) as a full-file-crc. That means a over the file crc gets calculated. Now lets think about that:

The AV is able to partly unpack crypter named "WHATEVER". But it doesn't restore all the stuff eg section structure, header's etc. (If you do not know what a section structure or header is please stop reading here and do something else!)

So remember: You added a full file CRC over a raw, unpacked malicious file. AV usually does this when they consider a file "not to be widely used", in most cases its automated done with mass-adding. The really important files getting added in a completely different way!

So what happens now is that the file has a completely different CRC when runtime packed because the binary stream is completely different.

Now, if u unpack the file (EVEN IF YOU MANAGE TO FULLY UNPACK IT!) You won't find the full file CRC! Because a memory mapped file looks completely different than a file on disk. That has to do with different facts: There is alignment issues and some packers simply merge sections together. So even if you unpack that, the over all CRC WILL FAIL. There are a couple of tricks that you can use ( i don't reveal that now ) but still it's almost impossible to ensure a 100% detection with a full file crc and runtime packed stuff.

Now if u take ANOTHER raw sample and the AV has a let's say 64 byte signature for some specific malicious code in their database IT WILL DETECT THIS SAMPLE if it can emulate the packer to at least some content. Because this signature will be found in the unpacked data in contrast to the full file crc that will NOT be found.

That's the PROOF that you cannot write "Oh they don't support this packer" when you don't know how they added the sample you repacked in the first instance!

And the same issue applies for the generic detection! If you pick a sample that you repack and that sample isn't detected via heuristic/generic and doesn't have any valuable heuristic trigger info how do you expect the AV to say later if it's runtime compressed that it's suspicious?

Believe me, AV is not so simple... You really have to understand what's going on before you can argue. Most of the hobby-testers don't understand that.

Serious Testers are aware of THIS issue and that is the reason why nobody really tests that because the results would be wishy-washy.

You would have to sit down for every AV INDIVIDUALLY to test that. A "i just repack some samples and let all scanners test it" DOESN'T WORK IN THIS CASE.

Mike

 

Just to make things a bit easier:

some antivirus engines use full body crc for detection. What does it mean? There are several ways an antivirus can recognize a malicious software. Often, when you know that the malware body won't change (simple not polymorphic trojans, etc...etc...) a full body crc (i.e. MD5) would be enough (not the best way, but this is another topic) to detect that malware.

Yes, there are a lot of packers out there which are able to pack the malware (UPX,PECompact, ASPack, Themida, Armadillo, blablablabla). By doing so, the full body crc totally change and the signature is bypassed.

Now, antivirus engines have unpacking routines so that they are able to handle those packers.

You can think that, after the unpacking step, antivirus engine is able to check the full body crc and detect the file.

The problem is how the unpacking step is handled. Some antivirus engines are able to unpack the packed malware without rebuilding the full original file with its structure. What does it mean? Basically that the antivirus doesn't rebuild totally the original file, but it unpacks the packed file until it gets to a stage that is enough for analyzing the malware.

But, if the original malware was detected by full body crc, the signature won't be anyway recognized, because the unpacked malware has not been totally unpacked until the original form.

The fact that the malware has not been recognized if you've packed it with a specific packer, this doesn't mean that the unpacker used is not handled by the antivirus engine.

This is why doing these kind of tests isn't easy at all.

 

So, basically automatically mass-adding some simple full body hash(crc32/md5/etc.)detections for all previous test sets and virus collections is one way to get good test results and percentages in av-comparatives and similar tests that only do on-demand scanning of a large malware set?

Is it so that good detection rates in these tests are quite easy to achieve without any elegant high tech?

 

All very technical.

Just a question about the unpacking abilities of the AVs: I've read that kind of information about the different AVs on av-comparatives, but I can't seem to locate it. A nice long horizontal graph that sort of splits out the performance in unpacking and other aspects. Maybe it's the change of the forum ? If anyone can point out where I can locate it, thanks.

 

Essentially yes. But the long-term drawbacks are serious enough that I doubt any vendor with sane people staffing their viruslabs would even consider doing this en masse.

 

Not really.

Using full body crc can be useful as fast and effective way to block simple trojans which are detected in the wild. There are a lot of simple trojans that have always the same body.

You have to fight against real threats, not against malwares created ad-hoc for av testing (repacking, rebasing, etc..etc..)

 

Thank You, Inspector and EraserHW for the inside information.

So basically the unpacking to memory and AV unpack engine hinder 1:1 detection of fragment/hash of code. And to avoid FPs most AV would probably use multiple vectors to ascertain that a file is malicious. Hence when packers hide some of those vectors, some pragmatic suites will not detect them. That in no way means that they are incapable of dealing with real threats.

 

It isn`t true, we completed the similar test in 2006.
For your information - Testing of antivirus software for packers support

But we didn`t do this test again, because it included in the proactive test by default.

 

so i am wrong
thanks for test, actually same result.