DE69802831T2

DE69802831T2 - Dynamisches heuristisches verfahren zur erkennung von computerviren

Info

Publication number: DE69802831T2
Application number: DE69802831T
Authority: DE
Inventors: S Nachenberg
Original assignee: Symantec Corp
Current assignee: Gen Digital Inc
Priority date: 1997-09-23
Filing date: 1998-08-25
Publication date: 2002-04-25
Anticipated expiration: 2018-08-26
Also published as: CA2304163C; WO1999015966A1; US6357008B1; EP1018077A1; DE69802831D1; CA2304163A1; EP1018077B1

Description

1. Hintergrund

A. Technisches Gebiet

Diese Erfindung betrifft Computer-Antivirensoftware. Insbesondere betrifft diese Erfindung Software zur Erkennung unbekannter Computerviren, wobei Emulation und künstliche Intelligenz verwendet wird.

B. Verwandte Technik

Die Computer-Viruserkennungstechnologie kann in Kategorien wie Signaturabtastung, Integritätsprüfung und nicht auf Integrität beruhende Erkennung von unbekannten Viren (auch als Heuristik bezeichnet) unterteilt werden. Dieser Abschnitt erläutert diese Kategorien der Antivirentechnologie.
Signaturabtastungs-Antivirenprogramme arbeiten, indem sie Dateien nach Signaturen von bekannten Viren abtasten. Eine Signatur ist eine Sequenz von Bytes, die in einem Virusprogrammcode gefunden werden können, jedoch unwahrscheinlich woanders zu finden sind. Um eine Signatur zu "extrahieren", muß ein Antiviren-Forscher den Virus analysieren. Sobald diese Signatur festgestellt ist, wird sie in einer Datenbank von Virussignaturen aufgezeichnet, die durch ein Antivirenprogramm verwendet werden soll. Das Antivirenprograxnm tastet ein Zielprogramm (ausführbare Datei, Startroutine oder möglicherweise eine Dokument-Datei mit einem Makro) ab, um das Vorhandensein einer Virussignatur zu erkennen. Wenn eine Signatur gefunden wird, dann wird das Zielprogramm als infiziert betrachtet. Andernfalls wird das Zielprogramm als nicht infiziert betrachtet.
Ein Signaturabtastungs-Antivirenprogramm kann bestimmte Virusmerkmale zur Entfernung erkennen und kann eine niedrige "Scheinpositiv"-Rate, wenn sich richtig implementiert sind. Jedoch können nur Viren, deren Signaturen schon bestimmt und in der Signaturdatenbank gespeichert worden sind, unter Verwendung der Signaturabtastung erkannt werden. Überdies muß die Signaturdatenbank häufig aktualisiert werden, um die neuesten Viren zu erkennen.
Eine Integritätsprüfung (die "Impfung" genannt wird, durch das kommerzielle Norton Antivirus-Produkt von Symantec Corp.) ist eine Technik, in der "Schnappschüsse" oder "Fingerabdrücke" von Programmen (ausführbaren Dateien, Startroutinen) auf dem Computer unter der Annahme gemacht werden, daß sich all diese Dateien in einem nicht infizierten Zustand befinden. Diese Fingerabdrücke werden typischwerweise genommen, nachdem der Computer mit einem Virusabtaster abgetastet worden ist, der vernünftigerweise sicherstellt, daß der Computer virenfrei ist. Diese Fingerabdrücke werden dann in einer Datenbank für spätere integritätsbasierte Abtastungen gesichert.
Während nachfolgender integritätsbasierten Abtastungen des Computers verifiziert das Antivirenprogramm, daß jedes Programm auf dem Computer, von dem vorher Fingerabdrücke genommen wurden, zu seinem Fingerabdruck paßt. Wenn ein Programm nicht zu seinem Fingerabdruck paßt, dann verwendet das Antivirenprogramm typischwerweise künstliche Intelligenz, um festzustellen, ob die Modifikation "virusähnlich" oder lediglich eine gültige Programmaktualisierung ist. Wenn es scheint, daß die Modifikation auf eine Infektion durch einen Virus zurückzuführen ist, alarmiert das Antivirenprogramm typischwerweise den Benutzer von der Modifikation und gibt den Benutzer die Option, den Schaden zu reparieren, falls möglich.
Da eine Integritätsprüfung nicht nach Virussignaturen abtastet, kann sie verwendet werden, um neue und (bis jetzt) unbekannte Virusmerkmale zu erkennen. Die Integritätsprüfung funktioniert, da Viren im allgemeinen Änderungen an ihrem Wirtsprogramm vornehmen müssen, und diese Änderungen können erkannt werden, wenn die Datenbank der Fingerabdrücke sauberer Programme geeignet erzeugt und unterhalten wird. Jedoch funktioniert die Integritätsprüfung nicht, wenn der Computer nicht virusfrei ist, wenn von den Programme Fingerabdrücke genommen werden. Ein virusinfiziertes Programm, das zusammen mit anderen sauberen Programmen "geimpft" wird, würde ein sicherer Hafen sein, von dem der Virus andere Programme infizieren kann. Ferner ist es häufig für das Antivirenprogramm schwierig festzustellen, wenn eine Änderung durch die Integritätsprüfung erkannt wird, ob die Änderung virusverursacht oder benutzerverursacht ist (z. B. kann der Benutzer ein Programm aktualisieren, indem er eine neue Version installiert oder eine aktualisierte Datei kopiert). Wenn diese Bestimmung durch das Antivirenprogramm nicht durchgeführt werden kann, muß der Benutzer aufgerufen werden, diese Bestimmung durchzuführen, und viele Benutzer sind nicht kenntnisreich genug, um dies zu tun.
Eine nicht auf Integrität beruhende (auch als "heuristisch" bezeichnete) Erkennung unbekannter Viren wird verwendet, um neue und unbekannte Viren ohne jede Integritätsinformation zuerkennen. Ein heuristisches Antivirenprogramm untersucht ein Zielprogramm (ausführbare Datei, Startroutine oder möglicherweise Dokument-Datei mit einem Makro) und analysiert seinen Programmcode, um festzustellen, ob der Code virusähnlich erscheint. Wenn der Code des Zielprogramms virusähnlich erscheint, dann wird die mögliche Infektion dem Benutzer mitgeteilt.
Heuristische Viruserkennung kann neue und unbekannte Viren erkennen, die noch nicht von Antiviren-Forscher analysiert worden sind, da sie keine Virussignaturen verwendet. Da die heuristische Technik keine Integritätsinformation verwendet, erfordert sie nicht, daß Fingerabdrücke von Programmen genommen und gesichert werden, wenn sich der Computer in einem bekannten sauberen Zustand befindet.
Heuristische Viruserkennung kann entweder als statisch oder dynamisch klassifiziert werden. Der Hauptunterschied zwischen diesen beiden Erkennungsverfahren ist es, daß das dynamische Verfahren eine CPU-Emulation verwendet, während es das statische Verfahren nicht tut.

i. Statische heuristische Erkennung

Bei der statischen heuristischen Viruserkennung durchsucht das Antivirenprogramm die Befehle eines Zielprogramms nach Sequenzen von Befehlen, die Operationen ausführen, die typischwerweise von Viren verwendet werden. Im Gegensatz zu Virussignaturen sind diese Sequenzen nicht so gestaltet, daß sie für einen einzelnen Virus spezifisch sind. Stattdessen sind sie dazu bestimmt, so allgemein wie möglich zu sein, um die Operation von vielen unterschiedlichen Viren zu erkennen.
Zum Beispiel kann die folgende Sequenz von X86 (Intel Mikroprozessor) Maschinencode-Befehlen verwendet werden, um eine Datei zu öffnen:

Assemblersprache Maschinencode

MOV DX,???? BA?? ??
MOV AX, 3D02 B8 02 3D
INT 21 CD 21
wobei ?? anzeigt, daß das Byte bei unterschiedlichen Viren varieren kann. Entsprechend kann die folgende Sequenz von X86 Maschinencode-Befehlen verwendet werden, um in eine Datei zu schreiben:

Assemblersprache Maschinencode

MOV DX, ???? BA?? ??
MOV CX, ???? B9?? ??
MOV AX, 4000 B8 00 40
TNT 21 CD 21
wobei ?? wieder anzeigt, daß das Byte bei unterschiedlichen Viren variieren kann.
Statische heuristische Antivirenprogramme suchen nach Sequenzen von Bytes, wie den oben gezeigten, nehmen dann eine Bewertung der Virusinfektion beruhend auf den Sequenzen vor, die sie gefunden haben. Wenn zum Beispiel das statische heuristische Antivirenprogramm eine Dateiöffnungsoperation findet, der sich Dateilese- und Schreiboperationen anschließen, und auch eine Zeichen- (ASCII-) Kette "VIRUS" im Programm findet, kann es mitteilen, daß die Datei durch einen unbekannten Virus infiziert ist.
Einige (selbstverschlüsselnde) Computerviren weisen verschlüsselte Viruskörper auf. Sequenzen von Befehlen, die ein virusähnlichen Verhalten zeigen, sind nicht erkennbar, weil sie verschlüsselt sind. Daher schicken einige statische heuristische Erkennungsprogramme der Verhaltenssuchphase eine Entschlüsselungsphase voraus, die typischwerweise unter Verwendung eines CPU-Emulators durchgeführt wird.
Obwohl statische heuristische Erkennungsprogramme verhältnismäßig schnell sein können, können sie nur einige der zahlreichen Arten erkennen, verschiedene virusähnliche Operationen durchzuführen. Zum Beispiel kann ein Virus-Autor die Befehle der obigen Dateiöffnungssequenz wie folgt umordnen:

Assemblersurache Maschinencode

MOV AX, 3D02 B8 02 3D
MOV DX,???? BA ?? ??
INT 21 CD 21.
Als ein weiteres Beispiel kann ein Virus-Autor die Befehle für eine Dateiöffnung radikaler ändern, wie folgt:

Assemblersprache Maschinencode

MOV AX, 3E00 B8 00 3E
SUB AX, 0100 2D 00 01
MOV DX, 1234 BA 34 12
ADD AL, 02 0402
INT 21 CD 21
Folglich muß das statische heuristische Erkennungsprogramm nach einer großen Anzahl unterschiedlicher Arten suchen, in der jede virusähnliche Operation implementiert sein kann, um zuverlässig ein virusähnliches Verhalten zu erkennen. Eine Datenbank, die eine große Anzahl möglicher Permutationen dieser Operationen abdeckt, kann unhandlich werden. Dieses Problem würde insbesondere akut werden, wenn ein Virus-Autor ein "Virusgenerator"-Programm schreiben würde, das tausende von Viren auf einmal erzeugen, die Ordnung ihrer Code-Abschnitte permutieren, jedoch nicht ihr effektives Verhalten ändern würde. Es wäre sehr schwer für statische heuristische Erkennungsprogramme mit einer solch großen Menge von Viren umzugehen.

ii. Dynamische heuristische Erkennung

Bei einer dynamischen heuristischen Viruserkennung emuliert das Antivirenprogramm das Zielprogramm in einer virtuellen Umgebung und überwacht die emulierten Befehle auf virusähnliche Operationen. Wenn das Zielprogramm emuliert wird, werden seine virusähnlichen Operationen erkannt und katalogisiert. Aus dem Verzeichnis virusähnlicher Operationen kann das dynamische heuristische Antivirenprogramm feststellen, wenn das Zielprogramm wie ein Virus aussieht. Wenn der Virus natürlich einen verschlüsselten Viruskörper aufweist, kann es dieses emulationsbasierte dynamische Verfahren zulassen, daß sich der Virus entschlüsselt, bevor es seine virusähnlichen Operationen (Öffnen von Dateien, Finden von Dateien, usw.) beobachtet.
Eine dynamische heuristische Viruserkennung kann viele unterschiedliche Permutationen einer gegebenen Operation einfacher als das statische heuristische Verfahren erkennen. Man betrachte zum Beispiel die dynamische heuristische Erkennung einer Dateiöffnungsoperation. Jedesmal, wenn eine Unterbrechung während der Emulation aufgerufen wird, prüft das dynamische heuristische Antivirenprogramm die Werte in den Registern. Diese Werte geben die Aufgabe an, die das Zielprogramm durch das Betriebssystem zu seinen Gunsten ausführen lassen will. Wie oben hinsichtlich der statischen Heuristik erläutert, kann ein Virus, der das Zielprogramm infiziert, es auswählen, bestimmte Werte in die Register in einer großen Vielfalt von Arten zu setzen. Wenn jedoch die Unterbrechung schließlich aufgerufen wird, müssen die Register die bestimmten Werte enthalten, die der gewünschten Operation entsprechen. Ein dynamisches heuristisches Antivirenprogramm ist nur mit den Werten der Register zur Zeit des Unterbrechungsaufrufes beschäftigt.
Während die dynamische heuristische Technik bei der Erkennung virusähnlicher Operationen überlegen ist, gibt es mindestens drei Probleme, die bei seiner Implementierung überwunden werden müssen. Das Folgende ist eine Erläuterung dieser drei Probleme.
Erstens kann eine ausgedehnte Emulation erforderlich sein, bevor die virusähnlichen Operationen vorkommen. Zum Beispiel kann ein Virus vor einer Dateiöffnungsoperation 50000 mal eine Leerlaufschleife durchlaufen. In diesem Fall müßte eine große Anzahl von Befehlen emuliert werden, bevor die Dateiöffnungsoperation erreicht ist. Dies würde das Antivirenprogramm beträchtlich abbremsen.
Zweitens aktivieren sich einige Viren nur, wenn bestimmte willkürliche Bedingungen erfüllt werden. Man betrachte zum Beispiel den folgenden Pseudocode eines Virus:
1. Finde die erste Datei im aktuellen Dateiverzeichnis, das eine ".com" Erweiterung (*.com) aufweist.
2. Wenn die Datei gefunden wurde, gehe zu Schritt 4.
3. Gebe Kontrolle an das Wirtsprogramm zurück.
4. Wenn die Datei weniger als 1000 Byte lang ist, gehe zu Schritt 3.
5. Wenn der Dateiname nicht mit "EL" endet, gehe zu Schritt 3.
6. Öffne die Datei.
7. Lese die ersten 3 Byte.
8. Suche nach dem Ende der Datei.
9. Schreibe Virusbytes in die Datei.
10. usw.
Wenn ein dynamisches heuristisches Antivirenprogramm ein Wirtsprogramm emulieren würde, das mit einem solchen Virus infiziert ist, würde es zuerst im Virus den Schritt 1 antreffen, der befiehlt, die erste *.com-Datei im aktuellen Dateiverzeichnis zu finden. Hier kann das Antivirenprogramm den DOS-Aufruf simulieren und dem Virus anzeigen, daß ein Schein-* .com-Programm gefunden wurde.
Anschließend wird dem Emulator in Schritt 4 befohlen, die Kontrolle vom Virus an das Wirtsprogramm zurückzugeben, wenn das Schein-*.com-Programm keine Dateigröße von mindestens 1000 Byte aufweist. Wie trägt das Antivirenprogramm dazu bei, eine solche willkürliche Bedingung nachzuahmen?
Vielleicht wird das Antivirenprogramm Glück haben, und das Schein-*.com-Programm wies eine Dateigröße von mindestens 1000 Byte auf. Anschließend wird im Schritt 5 dem Emulator befohlen, die Kontrolle vom Virus zum Wirtsprogramm zurückzugeben, wenn der Dateiname nicht mit "EL" endet. Wiederum wird sich der Virus sofort beenden und die Kontrolle an das Wirtsprogramm zurückgeben, wenn dieses Kriterium nicht erfüllt wird (z. B. ist der Dateiname "FOO.COM," der mit "00" endet).
Folglich kann ein Virus so gestaltet sein, in seinem Infektionsprozeß willkürlich "wählerisch" zu sein, und wenn irgendein Kriterium (wie daß das Datum der 5. des Monats ist) nicht erfüllt ist, wird der Virus sein infektiöses Verhalten nicht ausführen. Folglich wird ein dynamisches heuristisches Antivirenprogramm das infektiöse Verhalten nicht beobachten und wird den Virus nicht erkennen.
Drittens, während ein "direkt wirkender" Virus (wie die oben erläuterten Beispiele) andere Programme infiziert, sobald ein infiziertes Wirtsprogramm gestartet wird, installiert ein "speicherresidenter" Virus sich selbst als einen residentes Unterbrechungsprogramm und bleibt untätig, bis die geeignete Unterbrechung aufgerufen wird. Nachdem er sich selbst als ein residentes Unterbrechungsprogramm installiert hat, gibt der speicherresidente Virus die Kontrolle an das Wirtsprogramm zurück.
Ein dynamisches heuristisches Antivirenprogramm beginnt die Emulation an der Haupteintrittsstelle eines Zielprogramms. Jedoch wird der infektiöse Viruscode (der Teil des Virus, der andere Programme infiziert) eines speicherresidenten Virus über die Haupteintrittsstelle seines Wirtsprogramms nicht erreicht. Stattdessen wird der infektiöse Viruscode nur ausgeführt, wenn die Unterbrechung, in die sich der Virus eingehakt hat, aufgerufen wird, und ein solcher Aufruf an das Betriebssystem kann durch ein anderes Programm als das infizierte Wirtsprogramm vorgenommen werden.
Daher kann der infektiöse Viruscode nicht erreicht werden, selbst wenn das dynamische heuristische Antivirenprogramm das infizierte Wirtsprogramm für eine sehr lange Zeit emuliert, und folglich können verdächtige Virusoperationen unentdeckt bleiben.
Es ist aus EP-A-0636977 bekannt, Computerviren zu erkennen, indem Befehle eines Zielprogramms emuliert und Operationen analysiert werden, die während der Emulation beobachtet werden, um ein Virusverhalten, wie eine Replikation zu erkennen.
Die vorliegende Erfindung trachtet danach, ein verbessertes Verfahren bereitzustellen.
Aspekte der vorliegenden Erfindung werden in den beigefügten unabhängigen Ansprüchen bekanntgegeben.
Eine bevorzugte Ausführungsform weist drei Phasen auf: eine Entschlüsselungsphase, eine Untersuchungsphase und eine Auswertungsphase. Ein Zweck der Entschlüsselungsphase ist es, eine ausreichende Anzahl von Befehlen zu emulieren, um es zuzulassen, daß ein verschlüsselter Virus seinen Viruskörper entschlüsselt. Ein Zweck der Untersuchungsphase ist es, mindestens einmal alle wesentlichen Codeabschnitte innerhalb eines Bereichs zu emulieren, von dem als wahrscheinlich angesehen wird, daß er irgendeinen Virus enthält, der im Zielprogramm vorhanden ist. Ein Zweck der Auswertungsphase ist es, jedes verdächtige Verhalten zu analysieren, das während der Entschlüsselungs- und Untersuchungsphasen beobachtet wird, um festzustellen, ob das Ziel infiziert zu sein scheint.

III. Kurze Beschreibung der Zeichnungen

Fig. 1 ist ein Blockdiagramm, das eine Struktur einer Computerplattform veranschaulicht, die eine bevorzugte Ausführungsform der vorliegenden Erfindung enthält.
Fig. 2A ist ein höherer Ablaufplan eines ersten und herkömmlichen dynamischen heuristischen Verfahrens zur Erkennung von Computerviren.
Fig. 2B ist ein höherer Ablaufplan eines zweiten und bevorzugten erfindungsgemäßen dynamischen heuristischen Verfahrens zur Erkennung von Computerviren.
Fig. 3 ist ein Ablaufplan der Entschlüsselungsphase des zweiten Verfahrens gemäß einer bevorzugten Ausführungsform der Erfindung.
Fig. 4A ist ein Ablaufplan der neunten (Analyse-/Aufzeichnungs-) Prozedur der Entschlüsselungsphase gemäß einer bevorzugten Ausführungsform dieser Erfindung.
Fig. 4B ist ein Ablaufplan der zehnten Prozedur (zum Setzen des Viruseigenen) der Entschlüsselungsphase gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung.
Fig. 5 ist ein Ablaufplan der Untersuchungsphase des zweiten Verfahrens gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung.
Fig. 6 ist ein Ablaufplan der ersten Prozedur (zum Setzen des virtuellen CS:IP) der Untersuchungsphase gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung.
Fig. 7A ist ein Ablaufplan der vierten (Abruf-/Emulations-) Prozedur der Untersuchungsphase gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung.
Fig. 7B ist ein Ablaufplan des vierten (Befehlverarbeitungs-) Schrittes der vierten Prozedur der Untersuchungsphase gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung.
Fig. 8 ist ein Ablaufplan der Auswertungsphase des zweiten Verfahrens gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung.

IV. Beschreibung der bevorzugten Ausführungsformen

Fig. 1 ist ein Blockdiagramm, das eine Struktur einer Computerplattform veranschaulicht, die eine bevorzugte Ausführungsform der vorliegenden Erfindung enthält. Die Computerplattform 100 weist Hardwarevorrichtungen 102 und ein Speichermodul 104 zur Speicherung von Programmen und Daten auf. Eine Kommunikation zwischen dem Speichermodul 104 und den Hardwarevorrichtungen 102 findet durch eine Kommunikationseinrichtung 106 (z. B. einen Bus) statt.
Vorzugsweise umfassen die Hardwarevorrichtungen 102: eine Zentraleinheit (CPU) 108 (z. B. einen Intel "x86" oder einen Motorola PowerPC-Prozessor), die in Verbindung steht mit: einer Speichervorrichtung 110 (z. B. einem Festplattenlaufwerk) und einer Eingabe-/Ausgabe (I/O)- Schnittstelle 112 (z. B. einer Kleincomputersystem-Schnittstelle (SCSI) oder einer (PCMCIA) Schnittstelle der internationalen Vereinigung für Personalcomputer-Speicherkarten.), sind aber nicht darauf beschränkt. In Verbindung mit der I/O-Schnittstelle 112 stehen: ein Speicherlaufwerk 114 (z. B. ein Diskettenlaufwerk), das Programme und Daten von einem Speichermedium 116 (z. B. einer Diskette) lesen kann, und eine Netzwerk-Schnittstelle 118 (z. B. einer Ethernet- Karte oder ein Modem), die mit einem entfernten System 120 über ein Netzwerk 122 (z. B. ein lokales Netzwerk, ein weiträumiges Netz, ein Intranet oder dem globalen öffentlichen Internet) in Verbindung steht. Ein Zielsoftwareprogramm (oder eine Zieldatendatei), die in Verdacht steht, einen Computervirus aufzuweisen, kann entweder auf dem Speichermedium 116 (A), der Speichervorrichtung 110 (B) oder dem entfernten System 120 (C) gespeichert sein.
Vorzugsweise umfassen die Programme und Daten, die im Speichermodul 104 gespeichert sind: ein Betriebssystem (OS) 150, wie DOS, Windows 3.1, oder Windows 95 von Microsoft (oder sogar Windows NT von Microsoft, oder OS/2 von IBM, oder Macintosh OS von Apple Computer oder eine Art UNIX), ein Antiviren-Hauptmodul 151, ein Entschlüsselungsmodul 152, ein Untersuchungsmodul 154, ein Auswertungsmodul 156, einen CPU-Emulator 158 und einen virtuellen Speicher 160, sind jedoch nicht darauf beschränkt.
Eine Beschreibung der Operation des Entschlüsselungsmoduls 152, des Untersuchungsmoduls 154 und des Auswertungsmoduls 156 beginnt unten in der Erläuterung, die Fig. 2B betrifft.
Der CPU-Emulator 158 führt Dateien in einer vollständig abgeschlossenen virtuellen Umgebung aus. Die virtuelle Umgebung umfaßt den virtuellen Speicher 160, der effektiv unabhängig vom Speicher des Wirtscomputersystems ist. Auf diese Weise ist der CPU-Emulator 158 effektiv von den tatsächlichen Hardwarevorrichtungen 102 isoliert, so daß kein Schaden durch einen Virus angerichtet werden kann, während eine Datei simuliert wird.
Fig. 2A ist ein höherer Ablaufplan eines ersten und herkömmlichen dynamischen heuristischen Verfahrens 200 zur Erkennung von Computerviren. Im ersten Verfahren 200 emuliert eine einzige Phase 202 das Zielprogramm und überwacht die Emulation auf virusähnliche Operationen hin. Ein solches Verfahren nach dem Stand der Technik wird im US-Patent Nr. 5, 3 98,19 6 beschrieben, das am 14. März 1995 an David A. Chambers erteilt wurde.
Fig. 2B ist ein höherer Ablaufplan eines erfindungsgemäßen zweiten und bevorzugten dynamischen heuristischen Verfahren 250 zur Erkennung von Computerviren. Das zweite Verfahren 250 beginnt mit einer Entschlüsselungsphase 252, die eine Emulation einbezieht. Ein Zweck der Entschlüsselungsphase 252 ist es, eine ausreichende Anzahl von Befehlen zu emulieren, um es zuzulassen, daß ein verschlüsselter Virus seinen Viruskörper entschlüsselt. Die Entschlüsselungsphase 252 wird unten in Bezug auf Fig. 3 beschrieben. Wenn die Entschlüsselungsphase 252 vollendet ist, fährt das zweite Verfahren 250 mit einer Untersuchungsphase 254 fort, die ebenfalls eine Emulation beinhaltet. Ein Zweck der Untersuchungsphase 254 ist es, mindestens einmal alle Codeabschnitte innerhalb eines Bereichs zu emulieren, von dem es wahrscheinlich ist, daß er irgendeinen vorhandenen Virus enthält, wobei dieser Bereich als der viruseigene Bereich bezeichnet wird. Im Gegensatz dazu ist die Emulationsphase 202 in Fig. 1 nicht so umfassend, daß sie alle Codeabschnitte in einem solchen Bereich emuliert. Die Untersuchungsphase 254 wird unten in Bezug auf Fig. 5 beschrieben. Anschließend an die Untersuchungsphase 254 fährt das zweite Verfahren 250 mit einer Auswertungsphase 256 fort. Ein Zweck der Auswertungsphase 256 ist es, alle verdächtige Operationen zu analysieren, die während der Entschlüsselungs- und Untersuchungsphasen 252 und 254 beobachtet werden, um festzustellen, ob das Zielprogramm durch einen Computervirus infiziert zu sein scheint oder nicht. Die Auswertungsphase 256 wird unten in Bezug auf Fig. 8 beschrieben.
Fig. 3 ist ein Ablaufplan der Entschlüsselungsphase 252 gemäß einer bevorzugten Ausführungsform der Erfindung. Wenn das Antiviren-Hauptmodul 151 eingestellt wird, um ein Zielprogramm (A, B oder C in Fig. 1) abzutasten, um heuristisch festzustellen, ob das Zielprogramm virusähnlichen Code enthält oder nicht, beginnt das Hauptmodul 151 die Entschlüsselungsphase 252, die die folgenden zehn Prozeduren 302, 304, 306, 308, 310, 312, 314, 316, 318 und 320 aufweist.
In einer ersten Prozedur 302, setzt das Entschlüsselungsmodul 152 den virtuellen Codesegment:Befehlszeiger (CS:IP) des CPU-Emulators 158 auf die Eintrittsstellenadresse des Zielprogramms. Wenn zum Beispiel das Zielprogramm ein *.com-Progralran ist, dann würde der virtuelle IP rückgesetzt, um auf das Wort bei iQOh im Codesegment des *.com-Programms zu zeigen, das die Speicherstelle der ersten ausführbaren Adresse des Programms ist. Wenn als ein weiteres Beispiel das Zielprogramm ein *.exe!!.... Programm ist, dann würde das virtuelle CS auf den Wert des Wortes bei 16 h gesetzt werden und der virtuelle IP würde auf den Wert des Wortes bei 18 h im EXE-Anfangsblock gesetzt werden, da dieser virtuelle CS:IP auf die erste ausführbare Adresse des Programms zeigen sollte.
In einer zweiten Prozedur 304 stellt das Entschlüsselungsmodul 152 fest, ob der Befehl am virtuellen CS:IP vorher durch einen anderen emulierten Befehl modifiziert wurde oder nicht (d. h.. ob die Adresse des Befehls vorher durch einen früheren emulierten Befehl überschrieben wurde oder nicht). Wenn der Befehl am virtuellen CS:IP vorher modifiziert wurde, zeigt dies an, daß es scheint, daß eine Entschlüsselungsroutine eines selbstverschlüsselnden Virus die Entschlüsselung des Viruskörpers beendet hat und nun versucht, einen entschlüsselten Befehl aus dem Viruskörper auszuführen. Wenn daher der Befehl am virtuellen CS:IP vorher modifiziert wurde, dann endet die Entschlüsselungsphase 252 und die Untersuchungsphase 254 beginnt.
Wenn der Befehl am virtuellen CS:IP vorher nicht modifiziert wurde, dann führt das Entschlüsselungsmodul 152 eine dritte Prozedur 306 aus, um zu prüfen, ob eine erste Schwellenzahl von Befehlen emuliert worden ist oder nicht. Die erste Schwellenzahl emulierter Befehle wird so vorbestimmt, daß ein typischer verschlüsselter Virus zu der Zeit, zu der die erste Schwellenzahl von Befehlen emuliert worden ist, begonnen hätte, sich zu entschlüsseln. In einer bevorzugten Ausführungsform beträgt die erste Schwellenzahl emulierter Befehle dreihundertvierundachtzig (384) Befehle. Wenn die erste Schwelle noch nicht erreicht worden ist, dann setzt das Entschlüsselungsmodul 152 die Emulation fort, indem es zu einer sechsten Prozedur 312 geht, die unten detaillierter beschrieben wird, die den Befehl am CS:IP abruft.
Wenn andererseits die erste Schwellenzahl erreicht worden ist, dann stellt das Entschlüsselungsmodul 152 in einer vierten Prozedur 308 fest, ob es so scheint, daß ein Bereich einer bestimmten minimalen Größe oder größer entschlüsselt worden ist. Es scheint, daß Befehle entschlüsselt worden sind, wenn sie überschrieben worden sind. In einer bevorzugten Ausführungsform beträgt diese bestimmte minimale Größe 24 Byte. Diese bestimmte minimale Größe des Bereichs ist nur ein Bruchteil (ein sechzehntel in diesem Fall) der ersten Schwellenzahl emulierter Befehle. Wenn es so scheint, daß kein solcher Bereich entschlüsselt worden ist, dann endet unter der Annahme, daß es unwahrscheinlich ist, daß irgendein vorhandener Virus ein verschlüsselter Virus ist, die Entschlüsselungsphase 252 und die Untersuchungsphase 254 beginnt.
Wenn es andererseits so scheint, daß ein Bereich entschlüsselt worden ist, dann geht die Emulation in der Entschlüsselungsphase 252 weiter, um eine weitere Entschlüsselung zuzulassen, indem der Befehl am virtuellen CS:IP in der sechsten Prozedur 312 abgerufen wird, wenn nicht eine zweite Schwellenzahl emulierter Befehle erreicht worden ist.
Eine Prüfung darauf, ob die zweite Schwelle erreicht worden ist, wird in einer fünften Prozedur 310 durchgeführt. In einer bevorzugten Ausführungsform wird die zweite Schwelle auf etwa dreißigtausend (30000) Befehle gesetzt. Sobald die zweite Schwellenzahl emulierter Befehle erreicht worden ist, endet die Entschlüsselungsphase 252 und die Untersuchungsphase 254 beginnt. Der Zweck der zweiten Schwelle ist es, die Zeit zu begrenzen, die gebraucht wird, um es einem Virus zu gestatten, sich zu entschlüsseln. Wenn die zweite Schwelle erreicht wird, beginnt die Untersuchungsphase 254 unter der Annahme, daß ein bedeutender Bereich des Viruskörpers entschlüsselt worden ist und eine Untersuchung dieses Bereichs garantiert ist.
In der sechsten Prozedur 312 veranlaßt das Entschlüsselungsmodul 152 den CPU-Emulator 158, den Befehl abzurufen, der an der Speicheradresse gespeichert ist, die durch den virtuellen CS:IP angezeigt wird.
In einer siebten Prozedur 314 veranlaßt das Entschlüsselungsmodul 152 den CPU-Emulator 158, den virtuellen CS:IP zu erhöhen, so daß er auf den nächsten Befehl im Zielprogramm zeigt (d. h.. auf den Befehl, der dem gerade abgerufenen unmittelbar folgt).
In einer achten Prozedur 316 veranlaßt das Entschlüsselungsmodul 152 den CPU-Emulator 158, den gerade abgerufenen Befehl zu emulieren. Da der gerade abgerufene Befehl durch den CPU-Emulator 158 vielmehr in einer virtuellen Umgebung emuliert wird, als daß er durch die tatsächliche CPU 108 des Computersystems 100 ausgeführt wird, sind das Computersystem 100 und seine Dateien vor jedem Schaden durch den Befehl geschützt, der emuliert wird.
In einer neunten Prozedur 318 analysiert das Entschlüsselungsmodul 152 den gerade emulierten Befehl und zeichnet alle "verdächtigen" Operationen auf, die durch die Analyse angezeigt werden. Diese Analyse/Aufzeichnungsprozedur 318 wird unten in Bezug auf Fig. 4A in weiteren Details beschrieben.
In einer zehnten Prozedur 320 setzt das Entschlüsselungsmodul 152 den viruseigenen Bereich. Diese Setzprozedur 320 wird unten in Bezug auf Fig. 4B weiteren Details beschrieben. Anschließend an die zehnte Prozedur 320 springt das Entschlüsselungsmodul 152 zur zweiten Prozedur 304 zurück.
Ein Vorteil der oben beschriebenen Entschlüsselungsphase 252 ist es, daß es zugelassen wird, daß die wesentliche Mehrheit der selbstverschlüsselnden Viren vieles oder alles ihrer Viruskörper entschlüsselt, und dies geschieht, ohne zu viel Verarbeitungszeit pro Datei aufzuwenden. Die entschlüsselten Abschnitte jedes verschlüsselten Viruskörpers können dann in der anschließenden Untersuchungsphase 254 untersucht werden.
Fig. 4A ist ein Ablaufplan, der einen Prozeß für die neunte Prozedur (die Analyse/Aufzeichnungsprozedur) 318 der Entschlüsselungsphase 252 gemäß einer bevorzugten Ausführungsform dieser Erfindung beschreibt. Diese Analyse/Aufzeichnungsprozedur 318 beginnt, nachdem der CPU-Emulator 158 den gerade abgerufenen Befehl in der achten Prozedur 316 der Entschlüsselungsphase 252 emuliert.
Die neunte Prozedur 318 beginnt mit einem ersten Schritt 402, in dem das Entschlüsselungsmodul 152 feststellt, ob der gerade emulierte Befehl den Inhalt modifiziert oder nicht, der an einer (virtuellen) Speicheradresse innerhalb des (virtuellen) Adreßraums des Zielprogramms gespeichert ist. Eine solche Modifikation ist kennzeichnend für eine stattfindende Entschlüsselung.
Wenn eine solche Modifikation durch den gerade emulierten Befehl ausgeführt wird, dann führt das Entschlüsselungsmodul 152 einen zweiten Schritt 404 der Aufzeichnung jener Modifikation zur zukünftigen Bezugnahme auf, (wobei eine solche Bezugnahme in der zweiten Prozedur 304 der Entschlüsselungsphase 252 stattfindet) bevor es einen dritten Schritt 406 ausführt. Wenn andernfalls eine solche Modifikation nicht ausgeführt wird, dann geht das Entschlüsselungsmodul 152 vom ersten Schritt 402 direkt zum dritten Schritt 406.
Im dritten Schritt 406 stellt das Entschlüsselungsmodul 152 fest, ob irgendeine verdächtige Operation aus einer vorbestimmten Liste verdächtiger Operationen durch den gerade emulierten Befehl ausgeführt wird oder nicht. Die vorbestimmte Liste verdächtiger Operationen umfaßt Operationen, die durch Viren charakteristischerweise durchgeführt werden, jedoch typischwerweise nicht durch "legitime" nicht infizierte Programme durchgeführt werden.
In dieser Ausführungsform umfaßt die Liste verdächtiger Operationen die folgenden verdächtigen Operationen, ist jedoch nicht auf sie beschränkt:
1. Dateiöffnen (nur Lesen, Schreiben/Lesen, usw.);
2. Dateilesen (Unterkategorien: 3-4 Bytes, zwischen 5 und 8 Bytes, 12-14 Bytes, 128 oder mehr bytes, usw.. Diese Werte werden aufgrund ihrer besonderen Bedeutung bei bestimmten Computerviren gewählt.);
3. Dateischreiben (Unterkategorien: 3-4 Bytes, zwischen 5 und 8 Bytes, 12-14 Bytes, 1Ch bis 1Eh Bytes, 128 oder mehr Bytes, usw.); .
4. Dateisuche (nach dem Anfang der Datei, nach dem Ende der Datei, usw.);
5. Holen/Setzen eines Dateiattributs;
6. Holen/Setzen des/der Datei-Datums/Zeit;
7. Finden von erster Datei/Finden von nächster Datei;
8. Dateilöschen;
9. Dateierzeugen;
10. Dateiumbenennen;
11. Änderung des Dateiverzeichnisses, hole aktuelles Dateiverzeichnis, setzt aktuelles Dateiverzeichnis;
12. Holen/Setzen von Datei-DTA;
13. Unterbrechungsumleitung (Unterbrechung 13 für Plattendienste, Unterbrechung 21 für DOS-Dienste, Unterbrechung 24 zur Fehlerbehandlung, usw.)
14. Modifikation der Speicherzuordnung (insbesondere Lesen/Schreiben im Programmsegmentpräfix);
15. Programmausführung;
16. Programmresidenz-Selbstprüfungsaufrufe (die typischerweise durch Viren verwendet werden);
17. Lesen/Schreiben in Masterstartroutine (MBR) unter Verwendung von BIOS-Plattendiensten (das typischwerweise in Multipartite- und Dropper-Viren verwendet wird);
18. Speicherinterne Modifikation von CS:100 in * .com-Programmen (was typischwerweise bei Viren geschieht, die *. com-Prograipine infizieren).
Wenn festgestellt wird, das eine verdächtige Operation durch den gerade emulierten Befehl ausgeführt wird, wird die verdächtige Operation durch das Entschlüsselungsmodul 152 in einem vierten Schritt aufgezeichnet.
Im fünften Schritt 410 stellt das Entschlüsselungsmodul 152 fest, ob der gerade emulierte Befehl einen Verzweigungspunkt aufweist oder nicht. In dieser Beschreibung ist ein Verzweigungspunkt ein Befehl, der bedingt oder unbedingt die Kontrolle an einen Befehl überträgt, der dem Verzweigungspunktbefehl nicht sequentiell folgt. Ein solcher Verzweigungspunkt zeigt an, daß während ein Befehlszweig genommen wird, ein alternativer Befehlszweig nicht genommen wird.
Wie oben im Hintergrundabschnitt bezüglich dem zweiten Problem früherer dynamischer heuristischer Antivirenverfahren beschrieben, können solche nicht genommenen Verzweigungen infektiösen Viruscode enthalten, der sich nur bei Erfüllung bestimmter willkürlicher Bedingungen aktiviert. Man betrachte zum Beispiel den folgenden Abschnitt von Assemblersprachenbefehlen aus einem hypothetischen Virus:
180 MOV AX, [ZielWirtProgrammGröße]
185 CMP AX, 1000
188 TLE 210
...
210 HLT
Der obige Abschnitt von Befehle prüft, um festzustellen, ob das potentielle Wirtsprogramm, das lokalisiert ist (das Zielwirtsprogramm), größer als eine minimale Größe ist (1000 h Byte). Wenn das potentielle Wirtsprogramm größer ist, dann wird es für eine Infektion in Betracht gezogen (d. h. der Sprung wird nicht unternommen). Andernfalls wird das potentielle Wirtsprogramm nicht für eine Infektion in Betracht gezogen und der Virus hält lediglich an (d. h. der Sprung wird unternommen). Verzweigungspunkte wie dieser sind kritisch, da wenn die Kriterien des Virus für ein Wirtsprogramm nicht erfüllt werden, kann der infektiöse Code in einer nicht genommenen Verzweigung bleiben, die durch ein dynamisches heuristisches Antivirenprogramm des Stands der Technik nicht untersucht wird.
Im Lichte eines Bedarfs, solche nicht genommenen Verzweigungen schließlich zu analysieren, wenn der gerade emulierte Befehl einen Verzweigungspunkt aufweist, speichert dann das Entschlüsselungsmodul 152 in einem sechsten Schritt 412 die Zieladresse der nichtgenommenen Verzweigung (d. h. die Adresse des ersten Befehls der nicht genommenen Verzweigung) und den gegenwärtigen Status des CPU-Emulators 158 an einer Warteschlange, bevor es die neunte Prozedur 318 beendet und die zehnte Prozedur 320 beginnt. Der Status des CPU-Emulator 158 bezieht sich nicht auf den gesamten virtuellen CPU/Speicher-Zustand, der untragbar groß ist, sondern vielmehr auf einen kleinen. Teilsatz jenes Status. Dieser Teilsatz ist ausreichend, um die Mehrheit der gegenwärtig interessierenden Viren zu erkennen. In dieser Ausführungsform umfaßt der Status des CPU-Emulators 158 den virtuellen CS:IP, bestimmte gewöhnlich verwendete Register, wie die AX-, BX-, CX-, DX-Register, und verschiedene Worte am oberen Teil des SS:SP-Stapels, ist jedoch nicht darauf beschränkt.
Wenn nur die Zieladresse der nicht genommenen Verzweigung, jedoch nicht der CPU-Emulatorstatus gespeichert würde, dann würden bestimmte Operationen unentdeckt bleiben, wenn die Verzweigung von Befehlen später während der Untersuchungsphase 254 untersucht würde. Man betrachte zum Beispiel den folgenden hypothetischen Codeabschnitt aus einem Virus:
Wenn der obige Code im Emulator auszuführen wäre und der Suchbefehl am Versatz 109 zu einem CARRY-Ergebnis führen würde (das einen Suchfehler anzeigt), dann würde der Sprung am Versatz 10B zum Befehl am Versatz 120 unternommen. In diesem Fall würde die nicht genommene Zieladresse, die an der Warteschlange gesichert 3 ist, 10D sein und der Status des CPU-Emulators 158, der an der Warteschlange gesichert ist, würde CS:10D, AX = 4200, BX = ????, CX = DX = 0, die oberen 8 Worte des Stapels, usw. sein. Wenn später die nicht genommenen Verzweigung untersucht wird, würde sich der Befehl am Versatz 10D AX zu 4202 ändern, und der Befehl am Versatz 10E würde ein Suchbefehl sein, was eine verdächtige Operation ist. Wenn jedoch der Status des CPU-Emulators 158 nicht in der Warteschlange gesichert würde, dann könnte das AX- Register infolge eines Befehls, wie dem am Versatz 120, einen Wert wie FFFF enthalten. Wenn in diesem Fall die nicht genommenen Verzweigung untersucht wird, würde der Befehl am Versatz 10D AX auf FF02 ändern, und der Befehl am Versatz 10E würde nicht genau die Operation des Viruscode zeigen.
Wenn andernfalls der gerade emulierte Befehl kein Verzweigungspunkt ist, dann beendet das Entschlüsselungsmodul 152 die neunte Prozedur 318 und beginnt die zehnte Prozedur 320. Die zehnte Prozedur 320 wird unten in Bezug auf Fig. 4B in weiteren Details beschrieben.
Fig. 4B ist ein Ablaufplan der zehnten Prozedur 320 der Entschlüsselungsphase 252 gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung. Diese zehnte Prozedur 320 stellt eine verhältnismäßig wahrscheinliche Speicherstelle des Virus im Zielprogramm fest.
In einem ersten Schritt 420 stellt das Entschlüsselungsmodul 152 fest, ob der viruseigene Bereich schon gesetzt worden ist oder nicht (d. h. während einer früheren Ausführung entweder eines dritten Schrittes 424 oder eines sechsten Schrittes 430, wie unten weiter erläutert wird). Wenn der Bereich schon gesetzt worden ist, dann endet die zehnte Prozedur 320 und das Entschlüsselungsmodul 152 springt zur zweiten Prozedur 304 der Entschlüsselungsphase 252 zurück.
Andernfalls stellt in einem zweiten Schritt 422 das Entschlüsselungsmodul 152 fest, ob das Zielprogramm eine EXE-Datei ist. Wenn es eine EXE-Datei ist, dann setzt das Entschlüsselungsmodul 152 in einem dritten Schritt 424 den viruseigen Bereich so, daß es der Bereich vom Start des Anfangscodesegments (CS) bis zum Dateiende für das Zielprogramm ist. Anschließend an den dritten Schritt 424 endet die zehnte Prozedur 320 und das Entschlüsselungsmodul 152 springt zur zweiten Prozedur 304 der Entschlüsselungsphase 252 zurück.
Wenn andernfalls das Zielprogramm keine EXE-Datei ist, ist es im allgemeinen eine COM-Datei. Für COM-Dateien stellt das Entschlüsselungsmodul 152 in einem vierten Schritt 426 fest, ob die Anzahl der Befehle des Zielprogramms, die emuliert worden sind, größer als n ist, wobei n eine vorbestimmt Zahl ist. In einer bevorzugten Ausführungsform beträgt n = 10.
Wenn die Anzahl der emulierten Befehle größer als n ist, dann stellt das Entschlüsselungsmodul 152 in einem fünften Schritt 428 fest, ob der gegenwärtige virtuelle CS:IP sich innerhalb des Anfangsspeichersegments des Zielprogramms befindet. Wenn sich der gegenwärtige virtuelle CS:IP außerhalb des Anfangssegments befindet, dann endet die zehnte Prozedur 320 und das Entschlüsselungsmodul 152 springt zur zweiten Prozedur 304 der Entschlüsselungsphase 252 zurück.
Wenn andernfalls der gegenwärtige virtuelle CS:IP innerhalb des Anfangssegments liegt, dann wird in einem sechsten Schritt 430 der viruseigene Bereich beruhend auf dem gegenwärtigen virtuellen CS:IP gesetzt. In einer bevorzugten Ausführungsform wird der Bereich so gesetzt, daß der die 4k (4096) Byte umfaßt, die sich um den gegenwärtigen virtuellen CS:IP konzentrieren. Anschließend endet die zehnte Prozedur 320 und das Entschlüsselungsmodul 152 springt zur zweiten Prozedur 304 der Entschlüsselungsphase 252 zurück.
Fig. 5 ist ein Ablaufplan der Untersuchungsphase 254 des zweiten Verfahrens gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung. Die Untersuchungsphase 254 wird durch das Hauptmodul 151 nach der Entschlüsselungsphase 252 eingeleitet, es sei denn, das Entschlüsselungsmodul 152 hätte zurückgegeben, daß das Zielprogramm virusfrei erscheint. Die Emulation während der Untersuchungsphase 254 ist auf jene Befehle im viruseigenen Bereich beschränkt. Die Untersuchungsphase 254 umfaßt die folgenden acht Prozeduren 502, 504, 506, 508, 510, 512, 514 und 516.
In einer ersten Prozedur 502, setzt das Untersuchungsmodul 154 den virtuellen CS:IP des CPU-Emulators 158. Die erste Prozedur 502 wird unten in weiteren Details in Bezug auf Fig. 6 beschrieben.
In einer zweiten Prozedur 504 stellt das Untersuchungsmodul 154 fest, ob der Befehl am virtuellen CS:IP während dieser Untersuchungsphase 504 schon abgerufen wurde. Wenn der Befehl am virtuellen CS:IP in dieser Untersuchungsphase 504 nicht schon abgerufen wurde, dann stellt das Untersuchungsmodul 154 in einer dritten Prozedur 506 fest, ob der virtuelle CS:IP außerhalb des viruseigenen Bereichs liegt.
Wenn in der dritten Prozedur festgestellt wird, daß der virtuelle CS:IP sich nicht außerhalb des viruseigenen Bereichs befindet, dann veranlaßt das Untersuchungsmodul 154 in einer vierten Prozedur 508 den CPU-Emulator 158, den Befehl am virtuellen CS:IP abzurufen und den abgerufenen Befehl zu emulieren. Die vierte Prozedur 508 wird unten in weiteren Details in Bezug auf die Fig. 7A und 7B beschrieben. Nach der vierten Prozedur 508 springt entweder das Untersuchungsmodul 154 zur zweiten Prozedur 504 zurück (wenn eine Schwellenzahl von Befehlen nicht emuliert worden ist), oder die Untersuchungsphase 254 endet, und die Auswertungsphase 256 beginnt (wenn die Schwellenzahl an Befehlen emuliert worden ist).
Wenn andererseits in der dritten Prozedur 506 festgestellt wird, daß der virtuelle CS:IP außerhalb des viruseigen Bereichs liegt, dann stellt das Untersuchungsmodul 154 in einer fünften Prozedur 510 fest, ob eine Warteschlange nicht genommener Verzweigungen leer ist. Diese fünfte Prozedur 510 wird auch erreicht, wenn das Untersuchungsmodul in der zweiten Prozedur 504 feststellt, daß der Befehl am virtuellen CS:IP während dieser Untersuchungsphase 254 schon abgerufen wurde.
Wenn in der fünften Prozedur 510 festgestellt wird, daß die Warteschlange nicht genommener Verzweigungen nicht leer ist, dann "reiht" das Untersuchungsmodul 154 in einer sechsten Prozedur 512 die nächste nicht genommene Verzweigung aus der Warteschlange nicht genommener Verzweigungen "aus". Das Ausreihen der nächsten nicht genommenen Verzweigung umfaßt das Setzen des virtuellen CS:IP auf die gespeicherte Zieladresse der Verzweigung und das Setzen des Status des CPU-Emulators 158 auf den entsprechenden gespeicherten Status (wobei beide vorher während des achten Teilschrittes 754 des vierten Schrittes 708 der vierten Prozedur 508 gespeichert wurden, siehe Fig. 7B und die entsprechende Beschreibung unten). Nach der sechsten Prozedur 512 springt das Untersuchungsmodul 154 zur zweiten Prozedur 504 zurück.
Wenn andererseits in der fünften Prozedur 510 festgestellt wird, daß die Warteschlange nicht genommener Verzweigungen leer ist, dann stellt das Untersuchungsmodul 154 in einer siebten Prozedur 514 fest, ob irgendein nicht emulierter Codeabschnitt im viruseigenen Bereich übrigbleibt. Wenn ein solcher nicht emulierter Codeabschnitt im viruseigen Bereich verbleibt, dann setzt das Untersuchungsmodul 154 in einer achten Prozedur 516 die virtuellen Haupt-CPU-Register (auf null) zurück und setzt den virtuellen CS:IP so, daß er auf den Start des nicht emulierten Codeabschnitts zeigt. Nach der achten Prozedur 516 springt das Untersuchungsmodul 154 zurück und führt die zweite Prozedur 504 aus. Wenn andererseits kein nicht emulierter Codeabschnitt im viruseigenen Bereich verbleibt, dann endet die Untersuchungsphase 254, und die Auswertungsphase 256 beginnt. In einer bevorzugten Ausführungsform der vorliegenden Erfindung wird ein nicht emulierter Codeabschnitt in der Untersuchungsphase 254 emuliert werden, selbst wenn der Abschnitt nur ein Byte (d. h. ein Befehl) groß ist. Jedoch kann diese minimale Größe größer gemacht werden.
Fig. 6 ist ein Ablaufplan der ersten Prozedur 502 der Untersuchungsphase 254 gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung. Wenn keine Entschlüsselung während der Entschlüsselungsphase 252 beobachtet wurde, dann setzt die erste Prozedur 502 den virtuellen CS:IP des CPU-Emulators 158 zurück, um die Untersuchungsphase 254 zu beginnen.
Die erste Prozedur 502 beginnt mit einem ersten Schritt 602, in dem das Untersuchungsmodul 154 feststellt, ob die Entschlüsselung während der Entschlüsselungsphase 252 beobachtet wurde. Wenn insbesondere das Entschlüsselungsmodul 152 in der sechsten Prozedur 312 der Entschlüsselungsphase 252 feststellt, daß der gerade emulierte Befehl vorher modifiziert wurde, dann wird die Entschlüsselung als beobachtet betrachtet.
Wenn die Entschlüsselung im ersten Schritt 602 beobachtet wurde, dann bleibt der virtuelle CS:IP unverändert, so daß die Emulation des Zielprogramms von dem Befehl aus fortfahren wird, der dem letzten Befehl folgt, der während der Entschlüsselungsphase 252 emuliert wurde. In diesem Fall endet nach dem ersten Schritt 602 die erste Prozedur 502 der Untersuchungsphase 254, und die zweite Prozedur 254 beginnt.
Wenn andererseits die Entschlüsselung im ersten Schritt 602 nicht beobachtet wurde, dann setzt das Untersuchungsmodul 154 in einem zweiten Schritt 604 den virtuellen CS:IP auf die Eintrittsstellenadresse des Zielprogramms zurück.
Nachdem der virtuelle CS:IP im zweiten Schritt 604 rückgesetzt: wird, setzt das Untersuchungsmodul 154 in einem dritten Schritt 606 den viruseigen Bereich erneut fest. Diese Neufestsetzung des viruseigen Bereichs kann implementiert werden, indem eine Prozedur, die ähnlich zu der Prozedur 320 ist, die in Fig. 4B gezeigt wird, in eine Schleife eingebaut wird, die die Prozeduren umfaßt, die ähnlich zu den Prozeduren 312, 314 und 316 sind. Nachdem der viruseigene Bereich im dritten Schritt 606 erneut festgesetzt wird, endet die erste Prozedur 502 der Untersuchungsphase 254, und die zweite Prozedur 504 beginnt.
Fig. 7A ist ein Ablaufplan, der einen Prozeß für die vierte Prozedur 508 der Untersuchungsphase 254 gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung beschreibt. Die vierte Prozedur 508 ruft den Befehl am virtuellen CS:IP ab und emuliert ihn, wenn festgestellt wurde 506, daß der virtuelle CS:IP innerhalb des viruseigenen Bereichs liegt.
Die vierte Prozedur 508 beginnt mit einem ersten Schritt 702, in dem das Untersuchungsmodul 154 eine Bitdarstellungsaufzeichnung von Befehlen aktualisiert, die aus dem viruseigenen Bereich abgerufen wurden. Eine Bitdarstellungsaufzeichnung weist ein Bit pro Byte des viruseigenen Bereichs auf. Wenn das Bit null ist, dann ist das entsprechende Befehlsbyte noch nicht abgerufen worden. Wenn andererseits das Bit eins ist, dann ist das entsprechende Befehlsbyte schon abgerufen (und emuliert) worden. Folglich wird das Bit, das dem Befehlsbyte entspricht, auf das durch den virtuellen CS:IP gezeigt wird, in diesem ersten Schritt 702 auf eins gesetzt. Man beachte, daß dieser erste Schritt 702 nicht ganz am Anfang der vierten Prozedur 508 stattfinden muß und in einer anderen Ausführungsform in der vierten Prozedur 508 an einer anderen Stelle stattfinden kann.
Anschließend an den ersten Schritt 702 veranlaßt das Untersuchungsmodul 154 in einem zweiten Schritt 704 den CPU-Emulator 158, den Befehl abzurufen, der an der virtuellen Speicheradresse gespeichert ist, auf die durch den virtuellen CS:IP gezeigt wird.
Anschließend an den zweiten Schritt 704 veranlaßt das Untersuchungsmodul 154 in einem dritten Schritt 706 den CPU-Emulator 158, den virtuellen CS:IP zu erhöhen, so daß er auf den nächsten Befehl im Zielprogramm zeigt (d. h. auf den Befehl, der dem gerade abgerufenen unmittelbar folgt).
Anschließend an den dritten Schritt 706 verarbeitet das Untersuchungsmodul 154 in einem vierten Schritt 708 den Befehl, bevor die Emulation stattfindet. Diese Verarbeitung 708 übt die Kontrolle über bestimmte Befehle aus, wie Unterbrechungen und Speicherschreibvorgänge innerhalb des viruseigenen Bereichs, und zeichnet das Vorhandensein dieser bestimmten Befehle zur späteren Verwendung auf, falls notwendig. Dieser vierte Schritt 708 wird unten in Bezug auf Fig. 7B detaillierter beschrieben.
Anschließend an den vierten Schritt 708 stellt das Untersuchungsmodul 154 in einem fünften Schritt 710 fest, ob der gerade abgerufene Befehl eine verdächtige Operation aufweist, die nicht schon im vierten Schritt 708 aufgezeichnet wurde. Wenn eine solche verdächtige Operation beobachtet wurde, dann zeichnet das Untersuchungsmodul 154 in einem sechsten Schritt 712 die verdächtige Operation auf. Eine Liste solcher verdächtiger Operationen ist vorbestimmt und wurde aus einer Analyse erzeugt, um Virusverhaltensweise oder deren Kombinationen zu finden, von denen es sehr unwahrscheinlich ist, daß sie in nicht infizierten Programmen verwendet werden. Eine Liste verdächtiger Operationen wurde oben in Bezug auf Fig. 4A gegeben. Nach dem sechsten Schritt 712 oder direkt nach dem fünften Schritt 710, wenn keine verdächtige Operation beobachtet wurde, veranlaßt das Untersuchungsmodul 154 in einem siebten Schritt 714 den CPU-Emulator 158, den gerade abgerufenen Befehl zu emulieren.
Nach dem siebten Schritt 714 stellt das Untersuchungsmodul 154 in einem achten Schritt 716 fest, ob nach der Eintrittsstelle des Zielprogramms eine Schwellenzahl von Befehlen emuliert worden ist. In einer bevorzugten Ausführungsform wird die Schwellenzahl auf die Anzahl der Bytes im viruseigenen Bereich gesetzt. Da für einen Intel-X86-Mikroprozessor ein Befehl eine Länge von minimal einem Byte aufweist, ist diese Schwellenzahl gleich der maximalen Anzahl von Befehlen im viruseigenen Bereich. Diese Schwellenzahl stellt sicher, daß die Emulation nicht sehr weit über die Anzahl der Befehle im viruseigenen Bereich weitergeht. Wenn das Untersuchungsmodul 154 feststellt, daß die Anzahl der nach der Eintrittsstelle emulierten Befehle die Schwellenzahl erreicht hat, dann beendet es die Untersuchungsphase 254, und das Hauptmodul 151 veranlaßt das Auswertungsmodul 156, die Auswertungsphase 256 zu beginnen. Wenn andererseits die Anzahl der nach der Eintrittsstelle emulierten Befehle die Schwellenzahl noch nicht erreicht hat, dann springt das Untersuchungsmodul 154 zur zweiten Prozedur 504 zurück, wo es feststellt, ob der nächste Befehl schon während der Untersuchungsphase 254 abgerufen wurde.
Fig. 7B ist ein Ablaufplan, der einen Prozeß für den vierten Schritt 708 der vierten Prozedur 508 der Untersuchungsphase 254 gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung beschreibt. Dieser vierte Schritt 708 verarbeitet den Befehl vor einer Emulation.
Der vierte Schritt 708 beginnt mit einem ersten Teilschritt 740, in dem das Untersuchungsmodul 154 feststellt, ob der gerade abgerufene Befehl ein Aufruf an einen Unterbrechungsvektor isst. Wenn es ein Aufrauf an eine Unterbrechung ist, dann behandelt das Untersuchungsmodul 154 in einem zweiten Teilschritt 742 die Unterbrechung als einen NOP- (keine Operation) Befehl, "täuscht" jedoch die Vollendung der Unterbrechung "vor", indem es geeignete Register des CPU-Emulators 158 ändert, geeignete Werte vom Stapel abhebt und so weiter. Im zweiten Teilschritt 742 prüft das Untersuchungsmodul 154 auch das geeignete Register, um die Beschaffenheit des gegenwärtigen Befehls festzustellen, der über die Unterbrechung aufgerufen wird, und der gegenwärtige Befehl wird aufgezeichnet, wenn er als verdächtig betrachtet wird.
In einem dritten Teilschritt 744 stellt das Untersuchungsmodul 154 fest, ob der gerade abgerufene Befehl virtuellen Speicher innerhalb des viruseigenen Bereichs modifiziert (d. h. in ihn schreibt). Ein solche Speicherschreibvorgang kann zum Beispiel anzeigen, daß der Virus seinen Code zu verschieben scheint oder daß der Virus Daten innerhalb des viruseigenen Bereichs speichert. In dieser Ausführungsform werden solche Schreibvorgänge verhindert. Wenn der gerade abgerufene Befehl in einen Speicher im viruseigenen Bereich schreibt, dann leitet das Untersuchungsmodul 154 in einem vierten Teilschritt 745 den Speicherschreibvorgang auf eine virtuelle Speicheradresse in einem anderen virtuellen Segment um, wobei es dieses virtuelle Segment als Segment S definiert, und zeichnet einen solchen 0 Schreibvorgang am Segment S auf. Wie unten erläutert, werden anschließende Datenschreibvorgänge aus dieser Speicheradresse zum Segment S umgeleitet.
Das Untersuchungsmodul 154 implementiert eine solche Umleiturig anschließender Speicherlesevorgänge über die fünften und sechsten Teilschritte 748 und 750. Im fünften Teilschritt 748 stellt das Untersuchungsmodul 154 fest, ob der gerade abgerufene Befehl einen Lesevorgang von Daten von einer Speicherstelle im viruseigenen Bereich des Speichers einleitet, den das Zielprogramm vorher versucht hat, zu modifizieren. Wenn im fünften Teilschritt 748 festgestellt wird, daß der gerade abgerufene Befehl einen solchen Speicherlesevorgang von Daten einleitet, dann leitet das Untersuchungsmodul 154 im sechsten Teilschritt 750 diesen Speicherlesevorgang zum Segment S um. Man beachte, daß in dieser Ausführungsform jene Abrufe vom Befehlsstrom nicht umgeleitet werden sollen.
In einem siebten Teilschritt 752 stellt das Untersuchungsmodul 154 fest, ob der gerade abgerufene Befehl einen Verzweigungspunkt aufweist. Ein Verzweigungspunkt wird hier als ein Befehl in einen Computerprogramm definiert, an dem ein Sprung auftritt oder auftreten kann.
Wenn im siebten Teilschritt 752 festgestellt wird, daß der gerade abgerufene Befehl keinen Verzweigungspunkt aufweist, dann endet der vierte Schritt 708 in Fig. 7A, und das Untersuchungsmodul 154 fährt damit fort, den fünften Schritt 710 auszuführen. Wenn andererseits im siebten Teilschritt 752 festgestellt wird, daß der gerade abgerufene Befehl ein Verzweigungspunkt ist, dann speichert das Untersuchungsmodul 154 in einem achten Teilschritt 754 den gegenwärtigen Status des CPU-Emulators 158 und die (auch als Ziel bezeichnete) Zieladresse der (nicht genommenen) Verzweigung an einer Warteschlange nicht genommener Verzweigungen. Anschließend endet der vierte Schritt 708 in Fig. 7A und das Untersuchungsmodul 154 fährt damit fort, den fünften Schritt 710 auszuführen.
Fig. 8 ist ein Ablaufplan der Auswertungsphase 256, die stattfindet, nachdem die Untersuchungsphase 254 endet, gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung. Die Auswertungsphase 256 analysiert die während der Entschlüsselungs- und Untersuchungsphasen 252 und 254 beobachteten und aufgezeichneten verdächtigen Operationen, um festzustellen, ob das Zielprogramm durch einen Computervirus infiziert zu sein scheint oder nicht. Während diese Ausführungsform eine besondere Herangehensweise verwendet, um zu bewerten, ob es wahrscheinlich ist, daß das Zielprogramm infiziert ist, oder nicht, kömnen viele andere "Expertensystem"-Herangehensweisen in der Auswertungsphase 256 verwendet werden.
In dieser Ausführungsform beginnt die Auswertungsphase 256 mit einer ersten Prozedur 802, in der das Auswertungsmodul 156 feststellt, ob eine sogenannte harmlose Operation während den Entschlüsselungs- oder Untersuchungsphasen 252 oder 254 beobachtet wurde. In einer bevorzugten Ausführungsform umfassen harmlose Operationen:
1. Drucken eines Zeichens auf einem Drucker oder Anzeigen eines Zeichens auf einem Monitor oder einer anderen sichbaren Ausgabevorrichtung;
2. ein Programmbeendigungsbefehl im viruseigenen Bereich, der direkt von der Eintrittsstelle erreichbar ist;
3. Umleitung des Nulldivisionsfehlervektors (Viren brauchen im allgemeinen keine Division auszuführen); und
4. Aufrufen von innerhalb des viruseigenen Bereichs einer Funktion, die weit weg (in einer bevorzugten Ausführungsform mehr als vier Kilobyte) von der gegenwärtigen Position in der Datei angeordnet ist (dann dies würde eine Routine anzeigen, die größer als die meisten Viren ist),
sind jedoch nicht darauf beschränkt.
Wenn irgendeine der letztgenannten drei harmlosen Operationen beobachtet wurde. dann stellt das Auswertungsmodul 156 in einer zweiten Prozedur 804 fest, ob spezifische hochverdächtige Operationen oder Merkmale beobachtet wurden oder nicht. In einer bevorzugten Ausführungsform umfassen hochverdächtige Operationen oder Merkmale das Folgende:
1. Vergleich eines Wortes in irgendeiner Register- oder Speicherstelle mit "MZ" (ein solcher kann verwendet werden, um das Vorhandensein eines EXE-Anfangsblocks festzustellen, da "MZ" eine identifizierende Markierung oder Hinweissymbol oder Etikett eines solchen Anfangsblocks ist);
2. ein Dateischreibvorgang derselben oder einer verdächtig ähnlichen Größe in Bytes wie der Abstand in Bytes von der Eintrittsstelle des Zielprogramms zum Dateiende des Zielprogramms (ein Dateischreibvorgang einer solchen Größe kann im Prozeß des Anhängens des Virus an das nächste Wirtsprogramm verwendet werden);
3. ein Suchen nach dem Dateiende, um die Dateigröße zu bestimmen, dem sich ein Dateischreibvorgang eines Sprungbefehls anschließt, dessen Sprungabstand verdächtig ähnlich zur Dateigröße ist (ein solcher Sprungbefehl kann durch einen angehängten Virus verwendet werden, um den sauberen ursprünglichen Körper des nächsten Wirtsprogramms zu umgehen);
4. ein Dateischreibvorgang einer Anzahl von Bytes, die ähnlich zu Anzahl von Bytes in einem EXB-Anfangsblock ist, wobei die geschriebenen Bytes "MZ" umfassen (ein solcher Dateischreibvorgang kann verwendet werden, um einen neuen Anfangsblock an das nächste Wirtsprogramm zu schreiben);
5. das Vorhandensein eines EXE-Anfangsblocks im Körper einer EXE-Datei, der verdächtig ähnlich zum EXE-Anfangsblock der Datei ist (ein solcher Anfangsblock kann verwendet werden, um den ursprünglichen Anfangsblock des nächsten Wirtsprogramms zu ersetzen);
6. ein Kommando, ausführbare (z. B. *com- oder *.exe-) Dateien in einen Dateiverzeichnis zu finden (ein solches Kommando kann verwendet werden, um das nächste Wirtsprogramm zu finden);
7. Untersuchung und Modifikation des (DOS-) Speicherzuordnungsschemas (bei Viren nicht ungewöhnlich, jedoch selten bei sauberen Programmen);
8. Wiederholung von Kettenbewegungsoperationen, die annähernd dieselbe Anzahl von Bytes wie der Abstand von der Eintrittsstelle zum Dateiende des Zielprogramms bewegen (Kettenbewegungen einer solchen Gesamtgröße können im Prozeß des Anhängens des Virus an das nächste Wirtsprogramm verwendet werden); und
9. Lesen/Schreiben im Programmsegmentpräfix (was eine Modifikation des Speicherzuordnungsschemas auf eine Rückhandart anzeigt);
sind jedoch nicht darauf beschränkt.
Wenn keine solche hochverdächtige Operation oder Kombination von Operationen beobachtet wurde oder die harmlose Operation das Drucken oder Anzeigen eines Zeichens war, dann gibt das Auswertungsmodul 156 in einer dritten Prozedur 806 ein Ergebnis an das Antivieren-Hauptmodul 151 zurück, das anzeigt, daß das Zielprogramm virusfrei zu sein scheint.
Wenn andernfalls eine hochverdächtige Operation beobachtet wurde 804 oder wenn keine harmlose Operation beobachtet wurde 802, dann berechnet das Auswertungsmodul 156 in einer vierten Prozedur 808 das Ausmaß, in dem verschiedene verdächtige Operationen während den Entschlüsselungs- 252 und/oder Untersuchungsphasen 254 beobachtet wurden. In einer bevorzugten Ausführungsform beinhaltet die vierte Prozedur 808, für jeden der verschiedenen verdächtigen "Verhaltensweisen" einen Wert beruhend auf der Anzahl des Auftretens verdächtiger Operationen zu berechnen, die für das verdächtige Verhalten kennzeichnend sind, wobei die Anzahl des Auftretens abhängig von der kennzeichnenden Eigenschaft der Operation hinsichtlich des Verhaltens gewichtet wird und wobei der berechnete Wert normiert wird, um 100% nicht zu überschreiten.
In einer bevorzugten Ausführungsform umfassen verdächtige Verhaltensweisen das Folgende:
1. Verschlüsselung;
2. Anhängen von Bytes an eine COM-Datei;
3. Anhängen von Bytes an eine EXE-Datei;
4. Öffnen/Schließen einer Datei auf Standard- und Nichtstandardarten;
5. Einhängen eines speicherresidenten Codes oder einer Routine;
6. kritische Fehlerbehandlung (Umleiten eines kritischen Fehlervektors);
7. Kettenbewegungen oder Dateischreibvorgänge, die in ihrer Größe verdächtig ähnlich zur Zieldateigröße sind;
8. Finden einer Datei oder Finden einer ersten Datei in einem Dateiverzeichnis; und
9. Ändern der Dateidatum-/Zeitstempel oder anderer Dateiattribute;
sind jedoch nicht darauf beschränkt.
Anschließend an die vierte Prozedur 808 stellt das Auswertungsmodul 156 in einer fünften Prozedur 810 für jeden der verschiedenen Arten von Viren fest, ob ein Maß der verdächtigen Verhaltensweisen eine Schwelle erreicht oder überschreitet, die für eine Infektion kennzeichnend ist. Insbesondere wird jedem verdächtigen Verhalten ein Gewicht zugeordnet, das seinen normierten Wert multipliziert, um zu einem Beitrag des Maßes zu gelangen. Wenn das Maß eine vorbestimmte Schwelle überschreitet und jedes verdächtige Verhalten vorhanden ist, das als verbindlich für jenen Typ Virus bezeichnet wird, dann wird eine Infektion durch diesen Typ Virus angezeigt.
In einer bevorzugten Ausführungsform umfassen Typen von Viren die folgenden:
1. speicherresidente Viren, die an COM-Dateien hängen;
2. direktwirkende Viren, die an COM-Dateien hängen;
3. speicherresidente Viren, die COM-Dateien vorgeschaltet sind;
4. direktwirkende Viren, die COM-Dateien vorgeschaltet sind;
5. speicherresidente Viren, die an EXE-Dateien hängen;
6. direktwirkende Viren, die an EXE-Dateien hängen;
7. speicherresidente Viren im allgemeinen; und
8. direktwirkende Viren im allgemeinen;
sind jedoch nicht darauf beschränkt.
Wenn eine (oder möglicherweise mehrere) der Schwellen erreicht sind, dann wird in einer sechsten Prozedur 812 des Auswertungsmoduls 156 feststellt, ob irgendeine hochverdächtige Kombination von drei oder mehr verdächtigen Operationen erkannt wurde. In einer bevorzugten Ausführungsform werden diese hochverdächtigen Kombinationen festgestellt, indem verschiedene Kombinationen bezüglich des Universums bekannter Computerviren analysiert werden und als hochverdächtig jene Kombinationen ausgewählt werden, die in mehreren (z. B. fünf) Prozent oder mehr der bekannten Viren auftauchen. Andere Arten, die hochverdächtigen Kombinationen auszuwählen, sind möglich. Wenn eine hochverdächtige Kombination ein Scheinpositiv erzeugt, indem sie unkorrekt ein sauberes Programm als infiziert erkennt, dann kann diese hochverdächtige Kombination aus der Liste hochverdächtiger Kombinationen entfernt werden. Eine solche Liste sollte ziemlich robust sein, da angenommen werden kann, daß mehr als eine hochverdächtige Kombination einen typischen Virus erkennt.
Wenn eine hochverdächtige Kombination erkannt wird 814, darin führt das Auswertungsmodul 156 die sechste Prozedur 812 aus, an das Antiviren-Hauptmodul 151 den Typ von Infektion zurückzugeben, der anscheinend in der Datei vorhanden ist. Insbesondere wird ein Etikett zurückgegeben, das der/den erkannten Kombination(en) entspricht.
Wenn andernfalls keine hochverdächtige Kombination erkannt wird, dann führt das Auswertungsmodul 156 die dritte Prozedur 806 aus, an das Antiviren-Hauptmodul 151 das Ergebnis zurückzugeben, daß die Datei virusfrei zu sein scheint.
Die obige Beschreibung ist enthalten, um die Operation der bevorzugten Ausführungsformen zu veranschaulichen und ist nicht dazu bestimmt, den Rahmen der Erfindung zu beschränken. Aus der obigen Beschreibung werden Fachleuten viele Variationen deutlich werden, die dennoch durch den Geist und Rahmen der Erfindung eingeschlossen sein würden. Erstens können Gruppen von Blöcken in den Fig. 4A und 7B umgeordnet werden, ohne die Funktionalität der Ausführungsform zu ändern. (Zum Beispiel können die Schritte 402 und 404 so bewegt werden, daß sie nach den Schritten 406 und 408 liegen. Oder die Schritte 740 und 742 in Fig. 7B können so bewegt werden, daß sie nach den Schritten 748 und 750 liegen. Und so weiter.) Zweitens kann die Feststellung, wann die Entschlüsselungsphase 252 zu beenden ist, auf alternative Arten vorgenommen werden, sie sich von der Art unterscheiden, zwei Schwellen zu verwenden, die in Fig. 3 gezeigt wird. Drittens kann die Bestimmung des viruseigenen Bereichs auf alternativen Arten vorgenommen werden, die sich von der spezifischen Art unterscheiden, die in Fig. 4B gezeigt wird. Viertens kann die Auswertung, ob die Datei infiziert zu sein scheint oder nicht, auf alternative Arten vorgenommen werden, die sich von der Vektor-Herangehensweise der Auswertungsphase 256 unterscheidet, die in Fig. 8 dargestellt wird. Fünftens können andere Kriterien oder Kombinationen von Kriterien für verdächtig Operationen und Verhaltensweisen in der Auswertungsphase 256 verwendet werden, die sich von den Kriterien unterscheiden, die in der Beschreibung angegeben werden. Dies sind nur einige der Variationen, die durch die mit Recht durch die vorliegende Erfindung eingeschlossen werden. Der Rahmen der Erfindung soll nur durch die folgenden Ansprüche begrenzt werden.

Claims

1. Verfahren zur Erkennung eines Computervirus in einem Zielprogramm, wobei das Verfahren die Schritte aufweist:

Emulation von Befehlen des Zielprogramms; und

Analyse der während des Emulationsschrittes beobachteten Operationen, um dadurch den Computervirus zu erkennen;

wobei das Verfahren durch die folgenden Schritte gekennzeichnet ist:

Emulation von Befehlen des Zielprogramms während einer Entschlüsselungsphase (252), um dadurch einen Viruskörper zu entschlüsseln;

Feststellen mindestens eines Bereichs des Zielprogramms, in dem der entschlüsselte Viruskörper vorhanden sein kann, und Emulation von Code innerhalb des mindestens einen Bereichs des Zielprogramms während einer Untersuchungsphase (254); und

Analyse von Operationen, die während der Entschlüsselungs- (252) und Untersuchungsphasen (254) beobachtet werden, um dadurch den Computervirus während einer Auswertungsphase (256) zu erkennen.

2. Verfahren nach Anspruch 1, wobei die Entschlüsselungsphase mit einem Eintrittsstellencode des Zielprogramms beginnt (302).

3. Verfahren nach Anspruch 1, wobei die Untersuchungsphase (252) mit einem Code beginnt, der einem Code unmittelbar folgt, der während der Entschlüsselungsphase (252) emuliert wird.

4. Verfahren nach Anspruch 1, wobei während dar Entschlüsselungsphase (252) der Computervirus den Viruskörper nicht entschlüsselt, da der Viruskörper nicht verschlüsselt ist, und wobei die Untersuchungsphase (254) mit einem Eintrittsstellencode des Zielprogramms beginnt.

5. Verfahren nach Anspruch 1, wobei festgestellt wird, ob der Viruskörper entschlüsselt worden ist, indem ein zusammenhängender Abschnitt von Bytes im Speicher erkannt wird, der während einer ersten Emulationsperiode überschrieben wurde.

6. Verfahren nach Anspruch 1, wobei die Auswertungsphase (256) beendet wird (806), wenn eine harmlose Operation beobachtet wird (802) und wenn keine verdächtige Operationen beobachtet (804) werden.

7. Verfahren nach Anspruch 6, wobei die harmlose Operation eine des Druckens und Anzeigens eines Zeichens umfaßt.

8. Verfahren nach Anspruch 6, wobei die harmlose Operation einen Programmbeendigungsbefehl innerhalb eines besonderen Bereichs des Programms umfaßt.

9. Verfahren nach Anspruch 6, wobei die harmlose Operation das Umleiten eines Fehlervektors umfaßt.

10. Verfahren nach Anspruch 6, wobei die harmlose Operation das Aufrufen einer Funktion von innerhalb eines besonderen Bereichs des Programms aus umfaßt, die sich von der gegenwärtigen Speicherstelle deutlich unterscheidet.

11. Verfahren nach Anspruch 6, wobei eine verdächtige Operation die Paarung von Inhalten von einem eines Registers und einer Speicherstelle mit einer Identifizierung eines Dateianfangsblocks umfaßt.

12. Verfahren nach Anspruch 6, wobei eine verdächtige Operation einen Dateischreibvorgang einer ähnlichen Größe in Bytes wie eine Anzahl von Bytes von einer Eintrittsstelle des Zielprogramms bis zum Dateiende des Zielprogramms umfaßt.

13. Verfahren nach Anspruch 6, wobei eine verdächtige Operation eine Suche nach einem Dateiende umfaßt, der sich ein Dateischreibvorgang eines Sprungbefehls anschließt.

14. Verfahren nach Anspruch 13, wobei die Suche eine Größe in Bytes bestimmt und der Sprungbefehl eine ähnliche Anzahl von Bytes abdeckt.

15. Verfahren nach Anspruch 6, wobei eine verdächtige Operation einen Dateischreibvorgang einer ähnlichen Größe wie eine Größe eines Anfangsblocks umfaßt, und wobei der Dateischreibvorgang ein Hinweissymbol enthält, das für den Anfangsblock charakteristisch ist.

16. Verfahren nach Anspruch 6, wobei eine verdächtige Operation das Vorhandensein eines Anfangsblocks einer ausführbaren Datei innerhalb eines Körpers des Zielprogramms umfaßt.

17. Verfahren nach Anspruch 6, wobei eine verdächtige Operation das Finden einer ausführbaren Datei in einem Dateiverzeichnis umfaßt.

18. Verfahren nach Anspruch 6, wobei eine verdächtige Operation eines aus einer Untersuchung und einer Modifikation eines Speicherzuordnungsschemas umfaßt.

19. Verfahren nach Anspruch 6, wobei eine verdächtige Operation mindestens eine Kettenbewegungsoperation umfaßt, die annährend dieselbe Anzahl von Bytes wie eine Anzahl von Bytes von einer Eintrittsstelle des Zielprogramms bis zu einem Dateiende des Zielprogramms bewegt.

20. Verfahren nach Anspruch 1, wobei der mindestens eine Bereich einen Endabschnitt des Zielprogramms umfaßt.

21. Verfahren nach Anspruch 1, wobei der mindestens eine Bereich einen Anfangsabschnitt des Zielprogramms umfaßt.

22. Verfahren nach Anspruch 1, das ferner eine Feststellung, ob der während der Untersuchungsphase (254) zu emulierende Code schon emuliert worden ist, und wenn dem so ist, keine Emulation des zu emulierenden Codes umfaßt.

23. Verfahren nach Anspruch 22, wobei die Emulation von Code innerhalb des mindestens eines Bereichs während der Untersuchungsphase (254) ferner aufweist:

Feststellen (506), ob der zu emulierende Code außerhalb des mindestens einen Bereichs liegt; und

wenn der zu emulierende Code außerhalb des mindestens einen Bereichs liegt, keine Emulation des Befehls, der emuliert werden soll.

24. Verfahren nach Anspruch 23, das ferner umfaßt:

Feststellen (510), ob irgendein nicht genommenes Verzweigungsziel bleibt; und

wenn irgendein nicht genommenes Verzweigungsziel bleibt, Zeigen auf ein nächstes nicht genommenes Verzweigungsziel als den zu emulierenden Code und Setzen eines Status eines CPU-Emulators auf einen gespeicherten Status, der dem nächsten nicht genommenen Verzweigungsziel entspricht.

25. Verfahren nach Anspruch 24, das ferner umfaßt:

wenn keine nicht genommenen Verzweigungsziele bleiben, Feststellen (514), ob ein nicht emulierter Codeabschnitt innerhalb des mindestens einen Bereichs bleibt; und

wenn irgendein nicht emulierter Codeabschnitt innerhalb des mindestens einen Bereichs bleibt, Zeigen (516) auf einen Anfangscode eines nicht emulierten Codeabschnitts als den zu emulierenden Code und Rücksetzen des Status des CPU- Emulators.

26. Verfahren nach Anspruch 23, wobei die Emulation des Codes umfaßt:

Feststellen (406), ob der zu emulierende Befehl eine verdächtige Operation ausführt; und

Aufzeichnen (408) der verdächtigen Operation, wenn der zu emulierende Code die verdächtige Operation ausführt.

27. Verfahren nach Anspruch 23, wobei die Emulation des zu emulierenden Codes ferner umfaßt:

Feststellen (740), ob der zu emulierende Code eine Unterbrechung umfaßt; und

wenn der zu emulierende Code eine Unterbrechung umfaßt, Vortäuschen (742) einen Vollendung der Unterbrechung, jedoch keine tatsächliche Ausführung der Unterbrechung.

28. Verfahren nach Anspruch 23, wobei die Emulation des zu emulierenden Codes ferner umfaßt:

Feststellen (744), ob der zu emulierende Code einen Speicherschreibvorgang an einer Speicherstelle innerhalb des mindestens einen Bereichs umfaßt; und

Umleiten (746) des Speichers zu einem anderen Segment S, wenn der zu emulierende Code einen Speicherschreibvorgang an einer Speicherstelle innerhalb des mindestens einen Bereichs umfaßt.

29. Verfahren nach Anspruch 28, wobei die Emulation des zu emulierenden Codes ferner umfaßt:

Feststellen (748), ob der zu emulierende Code die Einleitung eines Speicherlesevorgangs von Daten umfaßt, die vorher durch Umleitung zum Segment S geschrieben wurden; und

Umleiten (750) des Speicherlesevorgangs von Daten auf das Segment S, wenn der zu emulierende Code den Speicherlesevorgang von Daten umfaßt, die vorher durch Umleitung zum Segment S geschrieben wurden.

30. Verfahren nach Anspruch 23, wobei die Emulation des zu emulierenden Befehls ferner umfaßt:

Feststellen (752), ob der zu emulierende Code einen Verzweigungspunkt umfaßt; und

Speichern (754) einer nicht genommenen Zieladresse des Verzweigungspunkts und eines CPU-Emulator-Status, wenn der zu emulierende Code einen Verzweigungspunkt umfaßt.

31. Vorrichtung zur Erkennung eines Computervirus in einem Zielprogramm, die aufweist:

eine Emulationseinrichtung (158) zur Emulation von Befehlen des Zielprogramms; und

eine Analyseeinrichtung (152, 154, 156) zur Analyse von Operationen, die während des Emulationsschrittes beobachtet werden, um dadurch den Computervirus zu erkennen;

wobei die Vorrichtung dadurch gekennzeichnet ist, daß:

die Emulationseinrichtung betriebsfähig ist, Befehle des Zielprogramms während einer Entschlüsselungsphase (252) zu emulieren, um dadurch einen Viruskörper zu entschlüsseln;

und daß sie ferner Bestimmungseinrichtung (154) zur Bestimmung mindestens eines Bereichs des Zielprogramms umfaßt, in dem der entschlüsselte Viruskörper vorhanden sein kann, wobei die Emulationseinrichtung betriebsfähig ist, während einer Untersuchungsphase (254) Code innerhalb des mindestens einen Bereichs des Zielprogramms zu emulieren; und

ferner eine Einrichtung (156) zur Analyse von Operationen umfaßt. die während der Entschlüsselungs- (252) und Untersuchungsphasen (254) beobachtet werden, um dadurch den Computervirus während einer Auswertungsphase (256) zu erkennen.

32. Computerprogramm, das prozessorimplementierbare Befehle zur Ausführung eines Verfahren nach einem der Ansprüche 1 bis 30 umfaßt, wenn das Computerprogramm auf einem Computer augeführt wird.