Some antiviruses are just too paranoid.

I wanted to do a simple test of antivirus software. That's what I did:

1.Took a simple .exe file made in C++ (basically displays just some text) and uploaded to virustotal. No threat found. (you can try it yourself http://rapidshare.de/files/39365744/test1.exe.html)
1-b.Took the file again
2.Compressed it with PECompact
3.Put it in a zip file
4.Uploaded to VirustTotal.com

The result EC edit: Removed virus total results. Please read our TOS.

3 Anti viruses report the file as suspicious, probably only because it has been compressed. And guess what? PrevX, the famous virus scanning, company flagged my file as malicious.

Got the same result with other C++ file treated in the same way. Now, it's good that antiviruses are having strong heuristics, but aren't they just too much paranoid?

 

maybe its not heuristic but just packer detection....

 

wow you actually discovered something most of us knew for a long time
it's packer detection, some will just flag a lot of packers (even upx which is a "standard" packer).

 

Hi, these antiviruses belong to group, which is very, very paranoid in this thing. I don't know why, but my experiences say that they detect malware or suspicious behaviour in clean files and infected files are signed as clean (besides Prevx, Panda maybe).

My experience with Avira's detection of Win32/IRCBot.AAH says that they use method besides others, which is based on packers, which used by malware.

http://secit.sk/files/predstavujeme/avira/avira_detection.png

 

Nearly all malware is packed, so detecting packed files becomes a shortcut to zero day detection.

The problem is a lot of benign software from smaller software publishers is packed to prevent reverse engineering.

 

yeah, packing is a very popular form of malicious binary obfuscation these days...

except that packing doesn't really prevent reverse engineering... it slows it down enough to create a problem when you're releasing 1000 binaries a day, but if you're a legit software publisher then you've probably only got a handful of executables and you probably only update them once every few months (otherwise your customers would become annoyed)...

truly preventing reverse engineering is technically not possible - if the cpu can figure out what the instructions are supposed to be (which is necessary to run the program) then so can a person with the right tools... protecting intellectual property with technological controls has always been a dumb idea if you ask me (and i'm one of the primary sources of IP for the 'smaller software publisher' i work for)...

 

Very true. The most you can hope for is to piss off the guy trying to reverse your code as much as possible, but at the end of the day there is no way you can stop a sufficiently knowledgeable/determined attacker from eventually getting there. Most of the time, binary obfuscation is just meant for a very different purpose instead: to fool computer algorithms (aka antivirus scanners) instead of human reverse-engineers.

Consider a packed trojan. There are several ways to detect it: first, you can generate a fingerprint for the packed trojan, and put that new fingerprint into the signature database. Obviously this is not going to work, because for each unique virus you'd have to generate fingerprints for when it's packed with any of the thousands of different packers out there, and the amount of work your analysts have to do, and the amount of bandwidth you need for which to push out updates every month (depending on your userbase) is going to bankrupt you.

Another approach you can use is to strip away the packer and scan the underlying file. You can do this using static unpackers, which are algorithms that work only against the packers they're designed to unpack, or dynamic emulators, which run the binary in a virtual environment and then scan the code when it unpacks itself. Static unpackers are fast, but work only against a small subset of packers. Dynamic emulators are are the opposite; they work against a wide range of packers, but are many times slower than static unpackers. So many engines use a combination of two approaches: if the scan engine can recognize what packer is used, it passes the binary to the corresponding static unpacker, otherwise it emulates the file. Here problems arise because the emulated environment is not identical to what the real CPU can actually do. Take NSPack; you can hand-modify the identifying characteristics so that the scanner fails to recognize that the binary is packed with NSPack. When passed to the emulator, what usually happens is that the code ends up as invalid data to the emulator, which cannot fully emulate the entire range of instructions needed to unpack the file. The more instructions an emulator tries to emulate, the more system resources and scanning time is needed, up to the point where some packers can easily cause system freezes when passed into an emulator. I've seen plenty of cases where NOD32 for instance spends up to 40 seconds at 100% CPU trying to unpack a malware binary – and still fail.

So what's left? Scan engines then turn to detecting the packer. Though not common knowledge, this has been done by many vendors for years now (yes, even scanners with "advanced" emulators and heuristics like BitDefender, NOD32, Kaspersky etc). Many packers used in malware are actually written for the express purpose of defeating dynamic emulators. Many of those packers also have their compiled binaries and/or source code unavailable to the public, for the simple reason that they're created in-house and used only by malware writers. And even then, a reasonably intelligent 12-year-old can quickly modify a publicly-available packer into a new variant of a packer (yes, we not only have variants of malware, we also have variants of packers). In these cases, faced with the very practical consequences, any arguments of sticking only to "elitist" (to quote Stefan) unpacking/emulating approaches usually fade away very quickly.

Of course, one can always argue that packers commonly used for malware binaries are not malicious by themselves. Now, ski masks and guns are also not malicious by themselves. However, ski masks are not allowed in banks and guns are not allowed in schools for very good reasons, and antivirus vendors have simply decided that malware packers are not allowed on their users' computers either. Given the scenarios, it's a perfectly legitimate strategy.