I've read it mentioned as a request for 2.0, and it's been a controversial thing for a long time, so I thought this earns its own 2.0 blog entry.
The standard AV (antivirus) approach at scanning is filesystem based, iterating through all or selected file partitions or folders. Extend that to AS (antispyware), and you'll add a full registry iteration as well. Each file/registry entry will be compared to a set of detection rules.
Our "current" (1.x) approach is mostly pattern-based, iterating though a list of definitions and trying to find malware that way. It's actually quite a bit more complex than that, but I'll leave it there for the introduction.
Going back in time, the reason we chose the pattern based access is clear. A few dozen of threats existed somewhere around the year 2000, simple software with clear schemes to detect. A pattern based detection meant a very fast scanning time. A downside of this is that what is often called "inactive" malware does not got detected this way - if you copy malware files to a different location for example. Different locations are not a problem with active malware, since if the malware changes its behaviour where to install itself, detection patterns need an update anyway (changed files mean different hashes). Well, it soon got more a bit more sophisticated than that.
About 4 years ago, we already had a 2.0 hybrid filesystem/registry based scanner combied with a few optimization features from our pattern based scanner ready, but there we met a big disadvantage of those. If you take a look at the OpenSBI wiki, you'll notice that we are able to link various detection patterns together, e.g. using the name of a detected file to flag an associated registry entry, and vice versa. If you scan both registry and filesystem at the same time, one would all the time have to wait for "final" results from the other, creating a deadlock situation. Regular filesystem/registry iteration scanners are not capable of using result parts in other patterns because the order in which events do appear is undefined.
Another downside of filesystem scanners is relative as to when problems are fixed. We often encounter malware that uses various small stubs to re-install themselves. On a pure on-demand scan and with partial fixing appearing the moment a problem is encountered, a pattern iterating scanner is able to scan and fix problems that belong together in as shorter timespan, reducing the chance that the re-installation cycle of the malware has time to complete before it has been completetely removed.
Third, the time a scan takes is essential. Users already now complaint about a scan that takes "an hour". A filesystem/registry iterating scanner would, similar to AVs, take multiple hours, and most users probably would not accept such a timespan. The best method to counter this obviously would be realtime on-access protection, which would make regular full on-demand scans less necessary (still very much needed after an infection/when cleaning from a bootable PE CD for example). The big problem with on-access scanning are AV companies of course, which already now, while we still have a near-access scanner designed especially to not conflict take the on-access scanning as a reason to force users to uninstall our product. Switching to a system that depends on a filesystem/registry based scan iterator therefore in the current situation would mean product suicid for us really. A "nice" (for them) illegal way of improper competition by the mentioned AVs to keep competition like us down; something which we're not going to tolerate for much longer, so don't take this is any indicator of what might or might not appear in a final 2.0.
Well, this blog entry already has reached some length just discussing the theories of the two approaches, so I'll save going into how we're working at hybrid modes for another post.
The standard AV (antivirus) approach at scanning is filesystem based, iterating through all or selected file partitions or folders. Extend that to AS (antispyware), and you'll add a full registry iteration as well. Each file/registry entry will be compared to a set of detection rules.
Our "current" (1.x) approach is mostly pattern-based, iterating though a list of definitions and trying to find malware that way. It's actually quite a bit more complex than that, but I'll leave it there for the introduction.
Going back in time, the reason we chose the pattern based access is clear. A few dozen of threats existed somewhere around the year 2000, simple software with clear schemes to detect. A pattern based detection meant a very fast scanning time. A downside of this is that what is often called "inactive" malware does not got detected this way - if you copy malware files to a different location for example. Different locations are not a problem with active malware, since if the malware changes its behaviour where to install itself, detection patterns need an update anyway (changed files mean different hashes). Well, it soon got more a bit more sophisticated than that.
About 4 years ago, we already had a 2.0 hybrid filesystem/registry based scanner combied with a few optimization features from our pattern based scanner ready, but there we met a big disadvantage of those. If you take a look at the OpenSBI wiki, you'll notice that we are able to link various detection patterns together, e.g. using the name of a detected file to flag an associated registry entry, and vice versa. If you scan both registry and filesystem at the same time, one would all the time have to wait for "final" results from the other, creating a deadlock situation. Regular filesystem/registry iteration scanners are not capable of using result parts in other patterns because the order in which events do appear is undefined.
Another downside of filesystem scanners is relative as to when problems are fixed. We often encounter malware that uses various small stubs to re-install themselves. On a pure on-demand scan and with partial fixing appearing the moment a problem is encountered, a pattern iterating scanner is able to scan and fix problems that belong together in as shorter timespan, reducing the chance that the re-installation cycle of the malware has time to complete before it has been completetely removed.
Third, the time a scan takes is essential. Users already now complaint about a scan that takes "an hour". A filesystem/registry iterating scanner would, similar to AVs, take multiple hours, and most users probably would not accept such a timespan. The best method to counter this obviously would be realtime on-access protection, which would make regular full on-demand scans less necessary (still very much needed after an infection/when cleaning from a bootable PE CD for example). The big problem with on-access scanning are AV companies of course, which already now, while we still have a near-access scanner designed especially to not conflict take the on-access scanning as a reason to force users to uninstall our product. Switching to a system that depends on a filesystem/registry based scan iterator therefore in the current situation would mean product suicid for us really. A "nice" (for them) illegal way of improper competition by the mentioned AVs to keep competition like us down; something which we're not going to tolerate for much longer, so don't take this is any indicator of what might or might not appear in a final 2.0.
Well, this blog entry already has reached some length just discussing the theories of the two approaches, so I'll save going into how we're working at hybrid modes for another post.
