Emulation: A Headache to Develop – But Oh-So Worth It.

What’s an ideal antivirus? Something that would feature the following:

• 100% protection from malware;
• 0% false positives;
• 0% load on system resources;
• No questions asked of the user; and
• Lasts forever and is for free!

Like anything ideal though, this is of course a fantasy – quite unattainable in real life. But it’s nevertheless still worthwhile contemplating since it provides a fixed reference point for security developers: every company can then try to get as close to the ideal as it can within the limits of its financial and professional resources.

Some developers invest in virus labs, automation, and breakthrough technologies. Others (particularly free antiviruses) hardly invest in anything and release functionally mediocre products – often with lots of buttons, knobs and sliders on the interface, but which in reality are nothing more than free “fly-swatters”, which don’t get to the root of the problem at hand (comprehensive threat elimination) at all. Besides, their main antivirus functionality is commonly second-hand: they use stolen signatures detected by someone else before them and then have the gall to promote their generic %&*# at a price on a par with genuine paid-for products. All the same, even these dodgy companies aspire to an ideal product – with 100% protection, and without burdening the user with questions, resource use or dollar expenditure.

Now, out of all the abovementioned five ingredients of an ideal antivirus, today I think the most interesting is the first – 100% protection from malware. But what precisely is 100% of malware? The answer is as idealistic as all the other ingredients: 100% protection from all already known and all future threats, and nothing less.

On the former (full protection from known threats) the leaders of the pack in the antivirus industry have for years been hovering around the maximum mark. But on the latter (full protection from future threats) those same leaders of the pack can’t seem to break through the ~60% region (as you can see in the latest retrospective test by AV-Comparatives [PDF]). The reason for this relatively low mark is simple: to predict the future – that is, what threats will be raining down on users next week, next month and next year… – is a task that’s anything but a cakewalk. Besides, to the uninitiated this task smacks of… shamanism! And no, not the old-skool ravey-tech type.

A very important (but unheard to the non-trained ear) percussion instrument in the shamanic orchestra of our technologies combatting unknown threats is emulator for executable files and scripts. This is an invention that’s rather old (its first generation for DOS appeared in our products in the early 1990s), but it has been constantly developed over the years – meaning its applicability and effectiveness are maintained.

Basically what the emulator does is supply our heuristic analyzer with information on programs’ conduct – allowing the analyzer to discover what in fact programs get up to – with no risk to the security of a protected computer.

The emulator doesn’t scan files using the usual antivirus signatures – it actually executes them. It does this in an artificial environment that emulates a real operating system. This environment contains its own virtual memory, hard drive, registry, network, processes, all possible subsystems… everything needed to make a file ‘think’ it has been executed by a real user on a real computer (not an emulator).

But, unlike in a real-life scenario, (i) all the actions of the file are tracked, protocoled, and sent for heuristic analysis; and (ii) not a single action goes outside the bounds of the artificial environment – meaning unknown malware can’t harm the computer. So what you get is the emulator creating on-the-fly something like a secure virtual machine in which it studies files. It’s a bit like the kind of armored safe box you see in some subway stations for suspicious objects – even if the contents blow up (once inside) – the explosion stays inside the safe box.

And it’s not just executable files that can be studied using an emulator. Today no less useful (more likely the opposite) is the script emulator. Here, everything’s just about the same as the executable file emulator, only it emulates not the operating system but the browser. As soon as a user visits a website, the antivirus intercepts the loaded HTML code from it, locates the Java and VB scripts in it, executes them in a protected environment, and then proceeds to suss out any dangerous or suspicious actions.

To be sure, emulators’ struggle against malware has not bypassed the eternal confrontation between cyber weapons and defenses. The cyber-wretches regularly invent tricks to fool emulators. But that is what it is, and there’s not much we can do to stem this tendency – c’est la vie, as they say.

The most widespread trick used is ‘prodding’ an environment with specific tests to check if it’s real or not. And it is here where the precision of the emulator is shown up – that is, how accurately and completely it replicates the original environment. Other funny examples of the cyber-swine’s attack methods are delay mechanisms (empty cycles), which can put an emulator into a stupor and make it skip files under testing time-limits.

But have no fear – we’re not idling the time away either. In every possible way we’re combatting these tricks while at the same time perfecting our emulator. Btw, there was recently a curious post (English translation by Google) on the Russian IT-techie social network called Habrahabr detailing the results of a simple test of anti-trick capabilities of different emulators. The finalists were Microsoft and KIS. That MS is able to effectively emulate its own OS should come as no surprise, of course. But the result for KIS for me was a surprise – naturally, a pleasant one – and proof that our five developers who work on and improve this technology don’t get their salaries for nothing – far from it :)

So yes, overall, the emulator is a thing that, although complicated, is very useful. And with emulation you can test the level of true expertise of a vendor too: excellent emulator = excellent vendor. And at the other end of the spectrum – absence of an emulator is a fairly reliable sign that the vendor isn’t up to much on expertise, and probably goes in for detection-theft from their (vastly) superior competitors. Shameful!

There are lots of other advantages that come with the emulator. It’s possible to greatly speed up analysis of malware and detect it in clusters – with one heuristic entry straight away you detect several hundred or thousands of different instances of malware. It’s possible to learn about the functionality of encrypted and packed objects (rather than brute forcing them – making a special unpacker; and not unthinkingly detecting usual commercial packers as malware). In several situations the emulator proves to be almost the only proactive technology applied. For example, in a gateway solution (email/file servers, firewalls, proxies..) there simply isn’t the possibility to use HIPS and proactive defense for monitoring program activity in real time. Here the only way of combating unknown threats is by using good old (of course, constantly upgraded) heuristics on the basis of emulator data.

And now about the fly in the ointment.

The emulator, of course, is a useful thing, but it’s also quite resource intensive (though not as much as a sandbox). But if you think about it, it’s bound to be! Just imagine analyzing all scanned objects in a virtual environment. And indeed, with a major lack of Poirot’s little grey cells, this aspect becomes an over-used excuse to shut down (or not start at all) development of emulation technology. Not us. All we’re concentrating on is forever improving it. And that includes speeding it up. For speeding it up, by the way, we already use various delimiters, optimizers and settings profiles, to the extent that this feature is able to be fully turned off. There’s always a price to be paid for speed!

And now a little on our plans for development of this technology.

What we really want is full integration of the emulator with our KSN cloud (video, details) and different reputation checking services (at present only a part of the script emulator is integrated). For example, we’re aiming for a scenario in which, should a user try to launch an unknown file with no reputation in KSN, the emulator kicks in – with the most paranoid settings. Then, later, as that file’s reputation grows, scanning depth can be lowered.