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