-
Die
vorliegende Erfindung betrifft ein Verfahren und ein System zur
heuristischen Erkennung von Viren in ausführbarem Code durch Analysieren
der Frequenzverteilung von erzeugtem Maschinencode.
-
Eine übliche Form
der Infektion mit einem Computervirus ist, dass der ausführbare Code
des Virus an ein Programm oder eine andere Computerdatei, die ausführbaren
Code enthält,
angehangen oder in diese/s eingebettet wird, die oberflächlich betrachtet
gutartig erscheint. Eine weit verbreitete Methode der Verbreitung eines
Virus ist es, dass sich der Virus, sobald er auf einem Wirt-Gerät, wie beispielsweise
dem PC eines Users, aktiviert ist, derart an ein oder mehrere Programme,
die auf dem Wirt gefunden werden, anhängt, dass das Programm, sobald
es gestartet wird, den Code des Virus ausführt, so dass diesem die Gelegenheit
gegeben wird, sich erneut zu verbreiten und/oder sein bösartiges
Verhalten (wie zum Beispiel die Zerstörung von Dateien etc.), für das er
programmiert wurde, durchzuführen.
Diese Methode der Verbreitung bietet selbstverständlich eine Gelegenheit, den
Virus zu entdecken, zum Beispiel durch Zuordnen von Prüfsummen
zu Programmdateien und Erkennen, wenn sich die Prüfsumme verändert. Dies
ist selbstverständlich
nur eine von vielen Strategien, die zum Erkennen von Viren erdacht
wurden.
-
Ein
anderes bekanntes Verfahren zum Erkennen von Viren, das in vielen
der erhältlichen
Antivirus-Softwarepakete implementiert ist, umfasst das Scannen
eines Programms oder anderer Dateien nach bestimmten charakteristischen
Sequenzen von Bytes (bekannt als Signaturen), die das wahrscheinliche
Vorhandensein eines Virus anzeigen. Eins der Probleme in der Praxis
bei der Signatur-basierten Erkennung ist, dass einige Kenntnisse
und ein beträchtlicher
Zeitaufwand erforderlich sind, wenn ein neuer Virus das erste Mal
erkannt wird, um eine verwendbare charakteristische Signatur für diesen
festzulegen. Diese Signatur muss so sein, dass nicht zu viele falsche
Positiv-Meldungen erzeugt werden und den Virus nicht falsch identifizieren, zum
Beispiel als einen existierenden mit weiteren gutartigen Nutzdaten.
Die Information über
diese Signatur muss dann an Sites verbreitet werden, die das in
Frage kommende Antivirus-Paket verwenden, bevor es dort verwendet
werden kann, um den neu identifizierten Virus zu erkennen. In den
letzten Jahren waren an vielen der beachtlichen Viren-Ausbrüche Viren
beteiligt, die sich über
das Internet verbreiten, und die Herausgeber von Antivirus-Software
brauchen Zeit zu reagieren, wenn ein Virus ausbricht.
-
Einige
Internetdienst-Anbieter bieten das Antivirus-Scannen von Internet-Traffic,
der über
ihre Internet-Knoten geht, als zusätzlichen Dienst an.
-
In
WO 01/69356 wird ein Verfahren
zur heuristischen Erkennung von Viren unter Verwendung eines Histogramms
beschrieben.
-
Die
vorliegende Erfindung betrifft ein Verfahren zur Erkennung von Viren,
welches als nützlich
für ISPs (ISP
= Internet Service Provider; Internetdienst-Anbieter (Provider))
erachtet wird, die ein Antivirus-Scannen durchführen, zum Beispiel von Ausführbarem,
wie beispiels weise Programmdateien, die an E-Mails angehangen sind,
obwohl es keinesfalls auf diese Anwendung beschränkt ist und in jedem Antivirus-Paket
verwendet werden kann.
-
Gemäß der vorliegenden
Erfindung wird ein Verfahren zum Scannen einer Computerdatei auf
Virusinfektionen vorgesehen, wobei das Verfahren aufweist:
- a) Identifizieren von Programmcode innerhalb
der Datei;
- b) Identifizieren des Compilers, der verwendet wurde, um den
Programmcode zu erzeugen;
- c) Bestimmen der Frequenzverteilung von ausgewählten Maschinencode-Instruktionen oder
Sequenzen von solchen Instruktionen in dem Programmcode; und
- d) Kennzeichnen der Datei als möglicherweise mit einem Virus
infiziert, oder nicht, auf der Basis eines Vergleichs der bestimmten
Frequenzverteilung mit einer Frequenzverteilung von Maschinencode-Instruktionen oder
Sequenzen davon, die für
diesen Compiler erwartet werden.
-
Mit
der vorliegenden Erfindung wird ebenfalls ein System zum Scannen
einer Computerdatei auf Virusinfektionen vorgesehen, welches aufweist:
- a) Mittel zum Identifizieren von Programmcode
innerhalb der Datei;
- b) Mittel zum Identifizieren des Compilers, der verwendet wurde,
um den Programmcode zu erzeugen;
- c) Mittel zum Bestimmen der Frequenzverteilung von ausgewählten Maschinencode-Instruktionen
oder Sequenzen von solchen Instruktionen in dem Programmcode; und
- d) Mittel zum Kennzeichnen der Datei als möglicherweise mit einem Virus
infiziert, oder nicht, auf der Basis eines Vergleichs der bestimmten
Frequenzverteilung mit einer Frequenzverteilung von Maschinencode-Instruktionen
oder Sequenzen davon, die für
diesen Compiler erwartet werden.
-
Die
Erfindung wird weiter beschrieben anhand eines nicht einschränkenden
Beispiels unter Bezugnahme auf die beigefügten Zeichnungsfiguren, in
denen:
-
1 ein
kombiniertes Block- und Ablaufdiagramm der Arbeitsweise einer Virusscan-Engine
gemäß einer
beispielhaften Ausführungsform
der vorliegenden Erfindung ist; und
-
2 ein
Ablaufdiagramm der Arbeitsweise eines Beispiels für den Instruktions-Frequenzanalysators aus 1 ist.
-
Im
Folgenden werden hexadezimale Werte mit einer vorstehenden 0x wie
folgt dargestellt: 0xff78. 0x???? wird verwendet, um einen hexadezimalen
Wert darzustellen, wobei der Wert nicht von Belang ist.
-
Zunächst wird
Terminologie erläutert.
-
"MD5 (message digest
5) Prüfsumme": MD5 ist ein Einweg-Hash-Algorithmus – er erzeugt
nach Analysieren eines Byte-Stroms – wie beispielsweise einer
Datei – eine
große
Zahl (die MD5-Prüfsumme).
Die Wahrscheinlichkeit, dass für
zwei Dateien die gleiche große Zahl
erzeugt wird, ist gering. Es ist ebenfalls sehr schwierig, eine
Datei herzustellen, die irgendeine bestimmte MD5-Prüfsumme erzeugt.
-
"Falsch positiv": Ein falsch positiv
tritt auf, wenn ein Antivirus-Produkt eine bestimmte Datei 'a' als Malware identifiziert, die keine
ist.
-
"regulärer Ausdruck": Reguläre Ausdrücke sind
Strings, die zur Mustererkennung verwendet werden können. Beispielsweise
entspricht der reguläre
Perl-Ausdruck
/^he1lo [0–9]+/
jeden
String, der mit den Buchstaben 'hello' startet, wonach
eine Leertaste folgt, danach eine oder mehr Stellen.
-
"Speicherabbild": Ein Speicherabbild
ist ein eins-zu-eins-Abgleich der Stellen, die ein Programm belegen
würde,
wenn es in den Speicher geladen würde, zusammen mit einigen anderen
Stellen. Somit könnte, wenn
ein Programm die Stellen 0x400000 bis 0x410000 belegen würde, wenn
es geladen wäre,
ein Speicherabbild von 0x100000 bis 0x110000 erstellt werden. Wann
immer das Programm auf eine bestimmte Stelle Bezug nähme, könnte (in
diesem Fall) die äquivalente
Stelle im Speicherabbild bestimmt werden, indem 0x300000 abgezogen
würden.
Somit bildet sich 0x400000 auf 0x100000 ab, 0x400001 bildet sich
auf 0x100001 ab, und so weiter.
-
"Compiler": Gemäß strikter
Anwendung erzeugt ein Compiler ein oder mehrere Objektmodule aus
Programm-Quellcode. Diese Objektmodule sind üblicherweise per se nicht ausführbare Programme,
sondern sie benötigen
einen zusätzlichen
Schritt des Verknüpfens
mittels eines Linkers. Die Aufgabe eines Linkers ist üblicherweise,
ein Abbild einer ausführbaren
Datei zu erzeugen, indem das (die) Objektmodul(e) mit externen binären Programmbibliotheken
(Libraries), auf die das (die) Modul(e) Bezug nimmt (nehmen), verknüpft werden; die
Erzeugung eines Abbilds kann das Voranstellen eines Header-Bereiches
gemäß eines
ausführbaren
Dateilayouts eines Ziel-Betriebssystems wie auch das Hinzufügen von
Ressourcen wie beispielsweise Bitmaps und Ähnliches beinhalten. Der Ausdruck "Compiler" wie hier verwendet
soll einen Linker umfassen, sofern dieser aus technischer Sicht
erforderlich ist. Das, was der Compiler erzeugt, ist nicht notwendigerweise
ein eigenständiges
Programm, denn selbstverständlich:
Compiler erzeugen ebenfalls ausführbare
Dateien, wie beispielsweise dynamische Verbindungsbibliotheken (DLL
= dynamic link library) und Gerätetreiber.
-
Compiler
weisen oftmals Compiler-Flags auf (ebenso als "Schalter" bekannt), die von dem Benutzer gesetzt
werden können
und die den Kompiliervorgang und den erzeugten Code beeinflussen.
Compiler-Flags können
zum Beispiel steuern, ob erzeugter Code auf Geschwindigkeit, Code-Größe oder
gar nicht optimiert wird, ob Stack-Frames für Subroutinen-Aufrufe verwendet
werden sollen und so weiter. Unterschiedliche Einstellungen dieser
Flags können
die Frequenzverteilung von Instruktionen in dem erzeugten Code beeinflussen, und
Ausführungsformen
der Erfindung können
dies berücksichtigen,
indem erwartete Frequenzdaten für
eine Vielzahl von Kombinationen der Compiler-Flag-Einstellungen
pro Compiler vorhanden sind.
-
Der
Ausdruck "Computerdatei" wie hier verwendet
soll in einem allgemeinen Sinn verstanden werden und ist insbesondere
nicht auf Dateien auf Platte (on-disk) beschränkt.
-
Um
die Kontrolle zu übernehmen,
muss ein Virus sich selbst in den Ausführungspfad von Programmcode
einfügen.
Der Virus-Code wird ursprünglich
von einem bestimmten Compiler oder Assembler erzeugt worden sein
und fügt
sich üblicherweise
selber in ein Programm ein, das von einem anderen Compiler oder Assembler
erzeugt wurde. Oftmals erzeugt ein bestimmter Compiler Code, der
als von diesem Compiler oder dieser Compiler-Familie stammend erkannt wird. Wenn
dies der Fall ist, kann es möglich
sein zu bestimmen, dass der eingefügte virale Code nicht von dem
Compiler erzeugt wurde, der den Rest des Programms erzeugt hat,
indem die tatsächliche
Frequenzverteilung von Instruktionen in dem Programm mit der erwarteten
Frequenzverteilung von Instruktionen, die von dem identifizierten
Compiler erzeugt wurden, verglichen wird. Das Programm kann dann
entweder als verdächtig
oder als von einem Virus infiziert gekennzeichnet werden.
-
1 stellt
in Blockform eine Form eines Viruserkennungssystems 10 dar,
das die vorliegende Erfindung verkörpert und das in einer Virusscan-Engine
enthalten sein kann. Die Gesamt-Arbeitsweise dieses Systems 10 ist
wie folgt:
Zu scannende Dateien werden aufeinanderfolgend auf
einen Eingang 20 angewendet, bilden zum Beispiel eine Eingangsschlange;
wie Dateien in dieser Schlange angeordnet werden und von welcher
(welchen) Quelle(n), ist für
die vorliegende Erfindung nicht direkt von Belang, aber sie können beispielsweise
Anhänge
von E-Mails sein, die von einem Mail-Gateway bei einem ISP verarbeitet werden,
oder Dateien in einem Verzeichnis, das von einem Platten-Scanvorgang
verarbeitet wird.
-
Jede
zu verarbeitende Datei wird an einen Dateityp-Analysator 30 gegeben,
der versucht, anhand der Inhalte den Dateityp zu identifizieren.
Beispielsweise kann sie ein Programm oder ein Nicht-Programm sein. Eine
Nicht-Programm-Datei wird/werden nicht weiter analysiert, und die
Verarbeitung wird bei 40 abgebrochen. Eine Datei, die für ein Programm
gehalten wird, wird weiter abhängig
von ihrem Typ klassifiziert – zum Beispiel
DOS, Windows PE, Windows NE, Linux ELF, Macintosh etc. Wenn der
Dateityp-Analysator 30 bestimmt, dass der Dateityp bekannt
ist, wird die Datei weiter vom Compiler-Analysator 50 verarbeitet,
welcher versucht, den Compiler zu identifizieren, der zur Erzeugung
des Codes in der Datei verwendet wurde; falls er dabei scheitert,
wird die Verarbeitung der Datei bei 40 abgebrochen, andernfalls
wird die Datei als Nächstes von
einem Instruktionsfrequenz-Analysator 60 verarbeitet.
-
Der
Analysator 60 führt
effektiv das Reverse Engineering des Programms durch und bereitet
eine Aufstellung der Frequenzverteilung bestimmter Maschinencode-Opcodes
und/oder Opcode-Konstrukte vor, wie nachstehend genauer beschrieben
wird. Diese Aufstellung wird an einen Frequenzverteilungs-Prüfer 70 gegeben,
wo sie mit einer oder mehreren Sätzen
von charakteristischen Frequenzverteilungen, die in einer Datenbank 80 bereitgehalten
werden, für
den identifizierten Compiler verglichen wird. Jeder gegebene Compiler/Linker
kann in der Lage sein, mehr als einen Typ ausführbare Datei zu erzeugen (GUI-Anwendung,
Konsolen-Anwendung, Gerätetreiber
etc.), und der Kompilierungs-/Linker-Ablauf kann beeinflusst werden
von der Einstellung eines oder mehrerer Compiler-/Linker-Flags (zum
Beispiel Flags, um das Erzeugen von Stack-Frames für Subroutinen-Aufrufe
zu steuern oder nicht, um anzuzeigen, ob das erzeugte Programm eine
Debug-Version ist, etc.), was verschiedene erwartete Frequenzverteilungen
ergeben kann, die in der Datenbank gespeichert werden können und
individuell zur Berücksichtigung
von Frequenzverteilungs-Prüfer 70 ausgewählt werden können.
-
Wenn
der Frequenzverteilungs-Prüfer 70 bestimmt,
dass die tatsächliche
Frequenzverteilung von Analysator 60 mit der für den identifizierten
Compiler erwarteten ausreichend genau übereinstimmt, wird die Verarbeitung
der Datei bei 40 nicht fortgesetzt; anderenfalls wird die
Datei als verdächtig
und möglicherweise einen
Virus enthaltend erachtet. Um die Anzahl falsch Positiver zu verringern,
werden verdächtige
Dateien von einem Ausnahmelisten-Prüfer gegen eine Ausnahmeliste
abgeglichen, das heißt,
dass Dateien, die, obwohl sie gemäß Frequenzverteilungs-Prüfer 70 verdächtig sind,
trotzdem als gutartig erachtet werden können. Der Ausnahmelisten-Prüfer kann
Bezug nehmen auf eine Ausnahmeliste in Datenbank 80, zusammen
mit Eigenschaften, die verwendet werden, um zu bestimmen, ob die
zu berücksichtigende
Datei mit einer Ausnahme übereinstimmt.
Wenn die Datei nicht mit einer Ausnahme übereinstimmt, wird sie bei
Ausgang 100 als viral gekennzeichnet. Das Setzen dieses
Flags kann verwendet werden, um einen Bediener zu alarmieren und/oder um
weitere Verarbeitung der Datei zu starten und/oder um geeignete
Abhilfe schaffende Maßnahme
zu starten (zum Beispiel in Quarantäne Setzen der Datei).
-
Erkennen einer ausführbaren
Datei
-
Es
folgt ein vereinfachtes Beispiel eines Algorithmus zum Bestimmen,
ob eine Datei wahrscheinlich eine ausführbare Datei ist, welche von
Dateityp-Analysator 30 verwendet werden könnte. Durch
Analysieren der ersten paar Bytes einer Datei ist es möglich zu
bestimmen, ob sie wahrscheinlich eine ausführbare Datei ist. Um beispielsweise
eine Windows PE-Datei zu erkennen:
Lese die ersten 2 Bytes
ein. Sind diese nicht 'MZ', dann Stopp.
Weitere
58 Bytes einlesen
4 Bytes in Variable × einlesen (Behandlung unter
Verwendung von Intel-Bytesortierung)
Suche
nach Absatz (Offset) × in
Datei
Lese 4 Bytes ein
Wenn die Bytes P E\0\0 sind, dann
ist die Datei wahrscheinlich eine Windows PE-Datei.
-
Dieser
Algorithmus kann verbessert werden, um die Erkennung so vieler anderer
Typen ausführbarer Dateien
hinzuzufügen
wie gewünscht.
Wenn die ersten 4 Bytes einer Datei zum Beispiel 0x7F 0x45 0x46
sind, dann ist die Datei wahrscheinlich eine ausführbare Linux-Datei unter Verwendung
des ELF-Formats.
-
Erkennen des Compilers
-
Es
gibt verschiedene Wege, wie der Compiler-Analysator 50 erkennen
kann, welcher Compiler ein bestimmtes Programm erzeugt hat. Zum
Beispiel könnte
er die Startsequenz des Programms oder den Subroutinen-Aufruf und
die Return-Sequenz untersuchen. In einigen Fällen ist dies ausreichend,
um die verwendete genaue Compiler-Version zu identifizieren. Anders
formuliert wird dadurch eine mögliche
Compiler-Familie identifiziert.
-
Reverse Engineering des Programms
-
Es
folgt ein vereinfachtes Verfahren, durch welches dies von dem Instruktionsfrequenz-Analysator 60 ausgeführt werden
kann. Dieses Verfahren ist in 2 dargestellt
und ist wie folgt:
Erzeuge ein Speicherabbild der Stellen,
die von dem Programm verwendet wurden, wobei jedes Byte als 'nicht verwendet' gekennzeichnet wird
(Schritt 210).
Füge
den Programm-Eingangspunkt einem Stack von zu berücksichtigenden
Stellen hinzu (220).
Solange es noch Stellen zu berücksichtigen
gibt (230)
Nimm die nächste Stelle als 'aktuelle Stelle' (240)
Nächste Markierung
(LblNext):
Wenn Speicherabbild dieses Byte als 'Code' markiert (250),
stoppe Verarbeitung dieser Stelle
Lese die Instruktion an dieser
Stelle ein, wobei ihre Länge
in Bytes berechnet wird (260)
Aktualisiere den Frequenzzähler für diese
Instruktion (270)
Markiere 'Länge'-Bytes in dem Speicherabbild
als 'Code' (280)
Wenn
die Instruktion ein 'Aufruf, 'Sprung' oder eine andere
Instruktion ist, die die Stelle der nächsten Instruktion verändern könnte (290),
füge das
Ziel dem Stack von zu berücksichtigenden
Stellen hinzu (300)
Wenn die Instruktion vom Typ 'Springe immer' oder 'Return' ist, stoppe Verarbeitung
dieser Stelle (310)
Wenn die Instruktion Daten an
bestimmte Stellen lädt
oder speichert (320), markiere das Ziel in dem Speicherabbild
als 'mögliche Daten' (330)
Inkrementiere 'aktuelle Stelle' um 'Länge'-Bytes (340)
Fahre bei
LblNext mit der Verarbeitung fort
Wend
-
Dieser
Algorithmus kann auf viele Arten verbessert werden, um bessere Ergebnisse
vorzusehen. Zum Beispiel sind, wenn das Verarbeiten beendet ist,
auf dem Speicherabbild viele Bereiche als 'Code', 'mögliche Daten' und 'nicht verwendet' markiert. Sind zu
viele Bereiche als 'nicht
verwendet' markiert,
können
diese Bereiche weiter analysiert werden, um zu versuchen zu bestimmen,
ob sie Code oder Daten sind. Ein derartiger Algorithmus könnte sein:
Prüfe Daten,
um zu sehen, ob sie Zeichen im Bereich 0x20 bis 0x7F, plus ebenfalls 0x0A,
0x09 0x0d enthalten und entweder mit 0x00 oder '$' enden.
Ist dies der Fall, könnte
es sich um eine Nachricht handeln, die von dem analysierten Programm
angezeigt wird und kann als Daten markiert werden. Die der Nachricht
unmittelbar vorausgehenden Bytes können ebenfalls analysiert werden,
um zu sehen, ob diese als eine 1-, 2- oder 4-Byte-Länge der
Nachricht erscheinen. Viele andere Algorithmen sind möglich. Bestimmte
Typen von Programmdateien, zum Beispiel Windows DLLs, können mehrere
Eingangspunkte enthalten, und die oben genannten Algorithmen können auf
jeden angewendet werden.
-
Prüfen
bekannter Frequenz
-
Bestimmte
Compiler führen
jedes Mal eine bestimmte Sache auf die gleiche Art aus (wenn der
gleiche Satz Compiler-Flags verwendet wird). Wenn beispielsweise
Compiler 'A' dem eax-Register
eins hinzufügen möchte, kann
er den folgenden Code erzeugen:
add eax, 0x01
-
Das
eax-Register ist 4 Bytes lang. Jedoch erzeugt der Compiler eine
Instruktion, einen Ein-Byte-Wert hinzuzufügen, wobei bekannt ist, dass
der Prozessor korrekterweise 0x01 zu 0x00000001 auffüllt.
-
Dies
ist jedoch nicht die einzige Art, dem eax-Register Eins hinzuzufügen, wenn
also ein Teil des folgenden Codes in einem von Compiler A erzeugten
Programm gefunden wird, wäre
dies verdächtig:
-
Viele
Compiler erzeugen bestimmte Eingangs- und Ausgangssequenzen für Subroutinen.
-
Angenommen,
der Compiler erzeugt immer das Folgende: Routine:
-
Dann
wäre, wenn
das Programm 1000 'retn' enthält und wenn
es retn nur während
der Ausgangssequenz der Subroutine erzeugt, zu erwarten, dass ebenfalls
wenigstens 100 'push
ebp', 'mov ebp, esp', 'sub esp 0x????', 'mov esp, ebp' und 'pop ebp' zu sehen sind. Alles,
was darunter liegt, würde
anzeigen, dass möglicher viraler
Code eingebracht wurde. Der Compiler kann ebenfalls eine bestimmte
Art aufweisen, Subroutinen aufzurufen:
-
Wenn
also das Programm 100 'call' enthält, wäre zu erwarten,
dass wenigstens 100 'add
esp, 0x???': zu
sehen sind.
-
Der
Compiler kann manche Instruktionen niemals erzeugen. Wenn also das
Programm eine oder mehrere davon enthielte, würde dadurch angezeigt, dass
möglicher
viraler Code eingebracht wurde.
Zum Beispiel int 3, was bei
Intel-Prozessoren der Serie x86 eine Debugger-Programmstopp-Instruktion
ist
-
Ausnahmeregeln
-
Verschiedene
Ausnahmeregeln können
zu Datenbank 80 hinzugefügt und von dem Ausnahmelisten-Prüfer 90 verwendet
werden. Als Beispiel sind int 3-Instruktionen in Viren üblich, können aber
ebenfalls in Debug-Versionen von Programmen enthalten sein. Also
könnte
eine Regel sein, dass das Vorhandensein von 'int 3' ignoriert wird, wenn bestimmt wurde,
dass das Programm eine Debug-Version ist.
-
Andere
Instruktionen werden von System- oder Kernel-Programmen verwendet,
aber nicht von Anwendungsprogrammen. Somit können diese, sofern vorhanden,
ignoriert werden, wenn bestimmt wurde, dass ein Programm ein System-
oder Kernel-Programm ist.
-
Programme,
die mit einem Compiler kompiliert wurden, können mit Code aus Bibliotheken,
die von anderen Compilern erzeugt wurden, verknüpft werden. Diese Bibliotheken
können
durch Musterabgleich und reguläre
Ausdrücke
erkannt und von der Analyse ausgeschlossen werden. Dieser Schritt
könnte
ebenfalls vor Schritt 3 (Reverse Engineering) ausgeführt werden,
um Bereiche als 'von
der Analyse ausschließen' zu markieren.
-
Bestimmte
ausführbare
Dateien können
durch Vergleichen einer MD5-Prüfsumme
des Programms mit einer Liste von Ausschluss-MD5 ausgeschlossen
werden.
-
Verbesserungen
-
Dieses
kann sowohl als eigenständiger
Viruserkennungs-Algorithmus verwendet oder mit anderen Techniken
als Teil eines größeren Systems
verwendet werden. Zum Beispiel kann Programmen, die durch dieses
Verfahren als verdächtig
gekennzeichnet wurden, eine bestimmte Punktzahl zugewiesen werden,
oder eine Vielfalt von Punktzahlen, abhängig davon, welche Tests bestanden
werden oder nicht. Punktzahlen können
ebenfalls unter Verwendung anderer heuristischer Techniken zugeordnet
werden, und nur wenn die Gesamt-Punktzahl
eine Grenze überschreitet,
wird das Programm als viral gekennzeichnet.
-
Das
System kann ebenfalls als Indikator verwendet werden oder als Indikator
dafür verwendet
werden, welche Teile des Programms weiter analysiert werden. Zum
Beispiel können,
wenn unübliche
Verteilungen gefunden wurden, das Programm erneut analysiert werden,
um herauszufinden, wo diese auftreten, sowie die Grenzen des bestimmten 'sonderbaren Code'. Dieser gekennzeichnete
Code kann dann einer Analyse unterzogen werden, um zu versuchen
herauszufinden, was dieser Code tatsächlich tut. Wenn er beispielsweise
Dateien oder Massen-E-Mails löscht,
ist dies ein wahrscheinlicher Hinweis darauf, dass das Programm
viral ist.
