Analyzing unknown binaries (exe scanner)

Fear to run unknown executables from virus, troja, malware or spywares? Well here are the solution for you.

It's not like the first time that we need to know what an executable binary file actually does. Of course, hardened reverse engineers will launch up their trusty hex editor / disassembler / debugger and spend a few days staring at the code. But for the rest of us, we need answers and we need them quick!

Traditionally one would run an AV scan on the unknown binary file and feel pretty comfortable with running it after nothing turns up. However, experience teaches that this is certainly not fool proof and just the fact that an AV reports nothing doesn't mean that the particular program was written with best intentions.

One way of going around this is to scan with multiple AntiVirus scanners. More often than not, it is not feasible to have a machine which has various AV products ready to scan your possibly malicious (but probably not) binaries. Hence a lot of people make use of services like VirusTotal and Jotti's malware scan. These two services provide a very good solution and will generally satisfy most people's needs.

However if, you have a binary which isn't caught by any AntiVirus vendor - then you might still want to decide for yourself if it is indeed malicious or not. It might not be even something that the AV companies will ever catch. Enter Anubis, Norman Sandbox and CWSandbox. The three of them will give you what a binary does based on how it behaved when ran in a virtualized or sandboxed environment. They will list things like the imported modules, files created or written to, sockets opened and so on.

I'm pretty new to Anubis - but I like the approach. They're making use of a patched version of Qemu internally. If anyone's interested in the internals of this project, they're published here. One problem that I guess is obvious with this approach, is when an executable checks for some property. Newer malware is known to check for signs of a virtual machine. Anubis and others should not have this problem.

But (there always has to be a "but") ... what happens when the executable expects a specific path to run the malicious code? For example, it might check to see if it is running from the Outlook temporary files directory before doing anything malicious. My best guess is that the methods that Anubis and other similar projects use, will fail to detect the malicious code simply because it is never run. Of course, by looking at the Outlook directory check, it can be enough indication that the executable might have malicious code.