Re: VirusHammer data structure

Nick FitzGerald <nick-jd3pj1bJWvoG2Il/[email protected]> Tue, 23 Mar 2004 11:58:25 +1200
Newsgroups gmane.comp.security.virus.openantivirus.devel
Organization Personal account
Message-ID <40602661.13798.1FF7D214@localhost>
"Antony Stone" asked:

> As a somewhat naive onlooker, can I ask what the current view of things is, as 
> far as (presumably) non-open source anti-virus programs are concerned?
> 
> I think I understand what a glorified binary grep is, but what are the 
> up-to-date (within the last decade) programs doing to detect viruses?

The open source AVs all missed the first 10+ years of AV product 
development, where all manner of code emulation, generic decryption,
"X-Ray techniques" and so on had to be developed to detect highly 
polymorphic malware.  It also missed starting in the era of the 
horrible resource and performance constraints imposed by OSes like DOS 
running on machines like 4.77MHz 8086/8088s.  That may not, in fact, be 
much (or any) of a disadvantage for now -- there is still some ugly 
baggage in some commercial products because of design decisions made 
way back then... 8-) -- but it also means that various tricks of 
necessity to speed up detection engines were learnt and the extent to 
which these are still effective provide a large part of the scanning 
speed differences between current products.

Note that, aside from in gateway scanning situations (which do not need 
to be "realtime" anyway), most things that are seen by a scanner are 
clean so the trick to being faster than the competition in normal 
scanning is (well, was) to be able to reliably determine when to stop 
scanning an object _sooner than_ the competition's product stopped.  
"Offline" grunt scanners never needed to worry about such niceties and 
the current surfeit of hardware performance (I mean, who really uses or 
"needs" all of the power in a typical multi-GHz desktop computer and 
how close and for how long does the typical desktop computer user come 
to saturating the I/O bandwidth of their machine's HDD/RAM/CPU buses??) 
probably covers for most of the relative inefficiencies of grunt 
scanning.  Heck, Norman Antivirus has even enabled its scan engine's 
Win32 emulation _when the engine is used in on-access scanning mode_ -- 
they decided it was OK to do this after discovering that it had 
accidentally been enabled in the shipping NetWare server builds for 
many months and not a single customer had complained about the 
performance impact!

Now, some of the things that are currently done have, more or less, to 
be retained for backwards compatibility reasons.  If your scanner 
detects some group of several hundred (or thousand) viruses due to a 
cunning (but weird) "optimization" you made to your detection engine 
for what was a really stellar reason back in 1994, you cannot decide to 
remove that mechanism from your engine _without_ committing to re-
analyze all the things that are detected as a result of (some partial) 
use of that method.  This is, in fact, one of the fundamental issues 
that potentially arises immediately you introduce greater complexity 
than just simple grunt scanning (or some form of "pre-processing" 
followed by (directed) grunt scanning), though there are approaches 
that can make working around even these type of gotcha relatively 
easy).

This doesn't all really ansewr your question directly, but hopefully it 
gives you some insights.


Regards,

Nick FitzGerald



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click