Resident Scanners and AV-Comparatives

In reviewing the results of AV-Comparatives, I understand the On-Demand comparative and the Retrospective/ProActive Test are both done with the on-demand scanner. The difference being the virus definitions are frozen three months prior to testing with the Retrospective/ProActive Test.

My question is will the resident scanner of Product A perform the same and produce the same results as Product A’s two different on-demand tests referenced above using the exact same sorting and testing methodology and the exact same samples?

I understand that many resident scanners, with default settings, do not scan archived files and packed files. However, from reading the FAQ on sorting and testing methodology at AV-Comparatives, all the samples are unarchived prior to testing.

I am using AV-Comparatives only because it provides a baseline and helps me explain more clearly my question.

Again, the question is will the resident scanner of Product A perform the same and produce the same results as the on-demand scanner tests of Product A on the exact same unarchived and unpacked samples?

I hope I have made the question clear. Any input is appreciated.

 

do you mean "on-access" or "on-execution" ?

 

IBK,

Thank you for the response. In regard to terminology I am not sure. Hopefully you can clarify for me. When I used the term resident scanner I am referring to, as examples, Bitdefender’s Virus Shield and NOD32's AMON. Hope this helps. Thanks again.

 

Yes the results should be the same. While some AV's do not scan archives or some types of compressed files, but once the baddie is unpacked and executed it will still detect it. The performance degradation from scanning compressed files can be extreme and the malware in a copmressed file can not hurt you any way, so the resident scanner/on access/on execution scanner of most AV's do not scan archives.

BTW On access scanner or Resident scanner are the two most common descriptors although some people do call it an on execution scanner.

 

This is not always true : for some AVs, some options that are available with the on-access scanner are not available for the resident monitor. For example, Norman Virus Control can use it's sandbox for on-demand scans, for scanning incoming files (email, instant messaging or network shares) but not for the on-access scanner. Most probably because it would cause an excessive slow down.

On the other hand, on-access scanners can sometimes catch malwares that on-demand ones would miss. This situation happens with malware droppers : it is possible that the dropped malware is detected by the on-access scanner while its dropper is not. An some* on-demand scanner will not see the dropped file.

However, these differences are generally small and would probably not change much the result of a "zoo" comparative test. It would mainly affect pro-active test results (not for all scanners, though).

I think that IBK reffered to IPS-like technologies (Panda truprevent, KAV proactive detection, etc.) or memory scanning (after execution ?) for "on execution scanners". Not sure, though, since on-access monitors might be triggered by different actions (reading/writing/executing file) depending on the AV.

In any case, these "proactive" technologies may significantly improve the detection rate of a scanner. But they are more risky than file scanning.

---

* Note that some on-demand scanners may see the dropped files :
- some low-tech scanners like ClamAV will look for search strings (signatures) through the entire file. If the dropped file is not encrypted or otherwise encoded (this is often the case), ClamAV may find a signature in a file located e.g. in the resource section of the scanned executable, without even noticing it.
- some high-tech scanners will emulate through the file, see what files would be dropped by the executable, and recursively scan such files. Bitdefender and Norman are known to do that, it is likely that others do it also.
- It might also be possible to look explicitely for the pattern MZ...PE inside every scanned executable (or its resources, if any), or every executable that imports functions for writing something to the disk/launching another executable. But I don't know if any scanner use this technique, since it would probably be quite slow and not improve the detection rate much (?).