Heuristic analysis is often considered a generic AV detection mechanism, not a virus-specific detection mechanism. What is not always considered is that the converse is also true; generic solutions use heuristic rule-sets as part of the diagnostic process.
For instance:
Mail gateway filters use rules to specify what file types and file names are yypermitted as attachments. Such filters are very good at countering obvious threats such as files with extensions like .LNK or .JPG, and .EXE, but can be rather inflexible in their rejection of whole classes of executable files. 1 Some filters use more advanced techniques, such as checking that the headers of the file scanned match the filename extension. This can significantly reduce the risk of false positives (and false negatives).
Change detectors use the rule that if an object’s yycharacteristics have changed, it should be treated as suspicious. Since there are many contexts in which a binary can legitimately change its checksum (as in self-modifying code, recompiled code, reconfiguration, run-time compression, a patched or updated program), such a crude change detection criterion (i.e., the file has changed, so it must be infected) can exhibit a high false positive rate. However, change detection can work well in conjunction with virus-specific scanning. A well-proven technique is to compare an object to its checksum and run a full scan on it only if a previously calculated checksum has changed, reducing the time it takes to process a file that hasn’t changed. This is why an initial scan of a system may take longer than subsequent scans with some AV programs.
Behavior monitors and blockers, which evaluate and act upon the way yyapplications behave, were among the earliest forms of AV software. This approach dovetails nicely with heuristics, which can enhance behavior blocking performance and actually reduce false positives. Classic AV behavior monitoring tends to check for two types of code behavior: replication and potential damage.
Replicative code, by definition, strongly suggests the presence of a virus ——(or worm, depending on the type of code and the definition you favor). This approach has an advantage in that system calls suggesting replicative code are comparatively easy to programmatically identify, especially where the code isn’t significantly obfuscated. It is, however, easier to identify a virus that replicates by writing a straight copy of itself rather than an evolved copy (i.e. a non-polymorphic virus).
Potentially damaging code reflects the likelihood of a malicious payload. ——This approach is ineffective where there is no payload, or where the payload is not obviously damaging. Some forms of damage, such as file deletion, are easier to programmatically detect than others, such as the unwanted and potentially embarrassing display of offensive messages or images. On the other hand, successful detection by payload has an advantage when it comes to detecting non-replicative malware (such as Trojans and other non-viral programs). There is a need for caution though. For instance, deleting a file is by itself an unreliable indicator of malice, since many programs routinely and legitimately delete or overwrite files such as obsolete configuration or data files.
Generic solutions use heuristic rule-sets as part of the diagnostic process. |
楼主: wasing
[复制链接]
发表于 2008-4-9 14:18:43
发表于 2008-4-9 14:30:06
