DE69712635T2

DE69712635T2 - Zustandsbasiertes cache für antivirensoftware

Info

Publication number: DE69712635T2
Application number: DE69712635T
Authority: DE
Inventors: S Nachenberg
Original assignee: Symantec Corp
Current assignee: Gen Digital Inc
Priority date: 1996-11-27
Filing date: 1997-11-17
Publication date: 2003-01-30
Anticipated expiration: 2017-11-18
Also published as: CA2273982A1; US5999723A; DE69712635D1; US5854916A; EP0941512A1; CA2273982C; EP0941512B1; WO1998024023A1

Description

Die vorliegende Erfindung betrifft das Gebiet der Antivirensoftware auf Emulatorbasis, wobei eine Programmdatei durch Ausführen in einem CPU-Emulator auf Softwarebasis auf das Vorhandensein von Computerviren untersucht wird.
Viele einfache Computerviren bewirken das Kopieren von exakten Duplikaten ihrer selbst in jede ausführbare Programmdatei, die sie infizieren. Wird ein infiziertes Programm ausgeführt, übernimmt der Virus die Kontrolle über den Computer und versucht, weitere Dateien zu infizieren. Wenn er eine ausfuhr- und infizierbare Zieldatei findet, kopiert er sich selbst Byte für Byte in die ausführbare Zieldatei. Da diese Art von Virus bei jeder Infektion einer neuen Datei identische Kopien seiner selbst repliziert, kann der Virus leicht dadurch erfaßt werden, daß in den Dateien nach einer bestimmten Folge von Bytes (d. h. einer "Signatur") gesucht wird, die aus dem Virus erhalten wird.
Einfache (nicht-polymorphe) kodierte Viren weisen eine Dekodierroutine (auch als Dekodierschleife bekannt) und einen verschlüsselten Viruskörper auf. Wenn eine mit einem einfachen Kodiervirus infizierte Programmdatei ausgeführt wird, übernimmt die Dekodierroutine die Kontrolle über den Computer und entschlüsselt den kodierten Viruskörper. Die Dekodierroutine überträgt dann die Kontrolle auf den entschlüsselten Viruskörper, der in der Lage ist, den Virus zu verbreiten. Der Virus wird dadurch verbreitet, daß die identische Dekodierroutine und der verschlüsselte Viruskörper in die ausführbare Zieldatei kopiert wird. Auch wenn der Viruskörper verschlüsselt und dadurch nicht sichtbar ist, können diese Viren durch Suchen nach einer Signatur für die sich nicht verändernde Dekodierroutine erfaßt werden.
Polymorphe verschlüsselte Viren ("polymorphe Viren") umfassen eine Dekodierroutine und einen verschlüsselten Viruskörper, der einen statischen Viruskörper und einen Maschinencodegenerator umfaßt, der oft als "Mutationsmaschine" bezeichnet wird. Anfänglich ist die Arbeitsweise eines polymorphen Virus ähnlich der Arbeitsweise eines einfachen (nicht-polymorphen) verschlüsselten Virus. Wird eine mit einem polymorphen Virus infizierte Programmdatei ausgeführt, übernimmt die Dekodierroutine die Kontrolle über den Computer und dekodiert den verschlüsselten Viruskörper. Die Dekodierroutine überträgt dann die Kontrolle über den Computer auf den dekodierten Viruskörper, der in der Lage ist, den Virus zu verbreiten. Der Virus wird dabei jedoch dadurch verbreitet, daß zusammen mit dem verschlüsselten Viruskörper eine neu erzeugte Dekodierroutine in die ausführbare Zieldatei einkopiert wird. Die neu erzeugte Dekodierroutine wird durch die Mutationsmaschine immer wieder variiert. Bei vielen polymorphen Viren erzeugt die Mutationsmaschine Dekodierroutinen, die zwar für alle infizierten Dateien funktionell gleich sind, jedoch unterschiedliche Sequenzen von Funktionsanweisungen verwenden. Die üblichen Mutationsstrategien der Mutationsmaschinen umfassen das Umordnen von Anweisungen, das Ersetzen von Befehlen durch gleichwertige Anweisungen oder gleichwertige Folgen von Anweisungen und das Einfügen von Anweisungen, die sich nicht auf die Funktion auswirken. Wegen dieser vielfältigen Mutationsmöglichkeiten können diese Viren nicht durch einfaches Suchen nach einer Signatur der Dekodierroutine erfaßt werden, da jede Dekodierroutine eine andere Signatur haben kann.
Um die wachsende Zahl von polymorphen Viren zu erfassen, beginnen die Antivirus-Softwarefirmen damit, die emulatorbasierte Antivirentechnologie anzuwenden, die auch als Generische Dekodiertechnologie (GD) bekannt ist. Ein GD-Scanner arbeitet auf die folgende Weise. Vor dem Ausführen eines Programms, das infiziert sein könnte, auf der tatsächlichen CPU (Zentraleinheit) des Computers liest der GD-Scanner das Programm in einen CPU-Emulator auf Softwarebasis, der als simulierter virtueller Computer dient. Das Programm kann sich in diesem virtuellen Computer frei ausführen. Wenn das Programm tatsächlich einen polymorphen verschlüsselten Virus enthält, kann die Dekodierroutine dabei den Viruskörper entschlüsseln. Der GD-Scanner kann dann durch Suchen nach einer Signatur für den dekodierten Viruskörper im virtuellen Speicher des virtuellen Computers den Virus erfassen.
Ein Problem, das bei der Ausführung der GD-Technologie auftritt, ist eine Verringerung der Anzahl von Anweisungen eines Programms, die simuliert werden müssen, bis die Feststellung des nicht infizierten Zustands zuverlässig erfolgen kann. Im allgemeinen wenden GD-Scanner einen Satz von Regeln an, um festzustellen, wie lange jedes Programm zu simulieren ist. Wenn zum Beispiel in der anfänglichen Phase der Emulation das Programm eine Dekodierroutine zu enthalten scheint, wird der GD-Scanner das Programm noch länger simulieren, damit der Virus eine ausreichende Anzahl von Anweisungen ausführen kann, um sich selbst zu dekodieren. Umgekehrt bricht der GD-Scanner die Emulation fast sofort ab, wenn während der anfänglichen Phase der Emulation starke Hinweise dafür vorhanden sind, daß das Programm ein nicht infiziertes (ein "sauberes") Programm ist.
Unglücklicherweise enthalten nicht infizierte Programme manchmal Anweisungen in der Maschinensprache, die wie Dekodierschleifen aussehen. Außerdem enthalten Datendateien manchmal auch binäre Daten, die wie Dekodierschleifen aussehen können, und in manchen Betriebssystemen, etwa MS-DOS, können Datendateien generell nicht von ausführbaren Dateien unterschieden werden. Wenn der GD-Scanner in einem Programm (oder in einer Datendatei, auf die von einem Programm zugegriffen wird) eine mögliche Dekodierschleife erfaßt, dann sollte die Simulation des Programms (oder der Datendatei) fortgeführt werden, bis zuverlässig feststeht, daß das Programm nicht infiziert ist. Diese Emulation kann viele Sekunden dauern und daher möglicherweise für den Computernutzer ziemlich störend sein.
Eine Motivation für die vorliegende Erfindung ist daher die Entwicklung einer GD-Technologie, die so wenig Anweisungen eines Programms (oder für eine Datendatei) wie möglich ausführt, bis sie in der Lage ist, zuverlässig festzustellen, das es bzw. sie nicht infiziert ist. Dieses Ziel ist deshalb so schwierig zu erreichen, da eine polymorphe Dekodierroutine sehr viele verschiedene Formen annehmen kann und es daher schwer ist, sie ohne Emulation einer großen Anzahl von Anweisungen zu identifizieren.
Ein anderes Problem bei der Ausführung der GD-Technologie ist das Vermeiden der redundanten Emulation von Anweisungen für ein Programm (oder eine Datendatei), von dem oder der bereits früher festgestellt wurde, daß es bzw. sie nicht infiziert ist. Häufig greift ein Nutzer oder ein Programm immer und immer wieder auf die gleiche Datei zu. Zum Beispiel kann ein Nutzer während einer Sitzung das gleiche E-Mail- oder Wortverarbeitungsprogramm mehrfach aufrufen. Außerdem neigen diese Programme dazu, wiederholt auf die gleichen Datendateien zuzugreifen. Zum Beispiel kann, wenn ein Nutzer das oft verwendete Lotus-CC:Mail-Programm für Windows zum ersten Mal aufruft, dieses die Konfigurationsdatei "CCMAIL.CFG" achtundzwanzigmal getrennt öffnen und schließen. Wenn gleichzeitig ein Echtzeit-Antivirusscanner auf GD-Basis läuft, durchsucht der GD-Scanner in der Regel die Datei CCMAIL.CFG jedesmal in den achtundzwanzig Fällen, in denen sie geöffnet wird. In einem typischen Fall dauert die Durchsuchung zwar nur einige Millisekunden, es kann aber auch mehrere Sekunden dauern, wenn die Datei Daten enthält, die wie eine Dekodierschleife aussehen. Diese mehrfache sekundenlange Verzögerung addiert sich auf eine völlig unakzeptable Verzögerung von mehreren Minuten, wenn die Datei achtundzwanzigmal durchsucht wird.
Eine andere Motivation für die vorliegende Erfindung ist daher die Entwicklung einer GD-Technologie, bei der die redundante Emulation von Anweisungen für solche Programme oder Datendateien vermieden wird, von denen bereits früher festgestellt wurde, daß sie nicht infiziert sind.
Novell's NetWare-Software ist ein oft verwendetes Netzwerk-Betriebssystem, bei dem jede Datei auf dem Server durch eine eindeutige Identifikationsnummer identifiziert wird. Die gegenwärtige Version der Norton Antivirus-Software (NAV), die in Verbindung mit NetWare verwendet wird, nutzt einen Cache-Speicher zum Speichern der Identifikationsnummern derjenigen Dateien auf einem Server, von denen bereits durch Untersuchen festgestellt wurde, daß sie virenfrei sind. Wenn die Identifikationsnummer einer Zieldatei im Cache ist, vermeidet die NAV-Software die redundante Neudurchsuchung dieser Datei.
Viele Betriebssysteme einschließlich Windows 3.1 und Windows 95 haben jedoch keine eindeutigen Nummern zur Identifikation jeder Datei. Bei solchen Betriebssystemen können zwar die Dateinamen anstelle von Dateiidentifikationsnummern in einem Cache gespeichert werden; bei modernen Betriebssystemen wie Windows 95 können Dateinamen jedoch hunderte von Byte lang sein, und das Indizieren mit solch langen Dateinamen ist hinsichtlich des Speicherplatzes nicht wirtschaftlich. Darüberhinaus muß, um einen solchen Cache-Speicher aufrechtzuerhalten, die Antivirus-Software alle Anforderungen auf eine Modifikation der Dateien überwachen, deren Dateinamen sich gegenwärtig in dem Cache befinden. Wenn eine Datei modifiziert wird, deren Dateiname im Cache ist, muß der Dateiname aus dem Cache entfernt werden. Eine solche Überwachung macht die Antivirus-Software kompliziert und langsam.
Aus Nachenberg C.S.: "A new Technique for Detecting Polymorphic Computer Viruses, a Thesis Submitted in Partial Satisfaction of the Requirements for the Degree Master of Science in Computer Science and Engineering", Thesis University of California, 1995, Seiten I-V, 1-127 ist ein Verfahren zum Erfassen eines Computervirus bekannt, bei dem ein CPU-Emulator verwendet wird, um ein Zielprogramm in einem virtuellen Computer zu emulieren. Nach der Emulation von ausreichend vielen Anweisungen, um eine Dekodierung eines polymorphen Virus zu ermöglichen, wird das Programm unter Verwendung von Standard-Suchfolgen nach Viren durchsucht.
Die vorliegende Erfindung ist durch die unabhängigen Ansprüche definiert.
Aspekte der vorliegenden Erfindung sind in den abhängigen Ansprüchen genannt.
Die bevorzugte Ausführungsform der vorliegenden Erfindung umfaßt ein Computer-implementiertes Verfahren zum Ausführen einer Computerdatei in einem CPU- Emulator (154) für die Erfassung eines Computervirus. Das Verfahren umfaßt das Simulieren (302) der Ausführung einer vorgegebenen Anzahl von Anweisungen der Computerdatei im CPU-Emulator (154), das Aussetzen (303) der Ausführung, das Erstellen (304) eines Zustandsberichts, das vorübergehende Speichern (305) des Zustandsberichts in einem Speicher, das Vergleichen (306) des erstellten Zustandsberichts mit Zustandsberichten, die in einem Zustands-Cache (158) gespeichert sind, und die Anzeige (308), daß die Datei virenfrei ist, wenn der erstellte Zustandsbericht mit einem der gespeicherten Zustandsberichte übereinstimmt.
Die bevorzugte Ausführungsform reduziert die Anzahl von Anweisungen eines Programms, die simuliert werden müssen, bis zuverlässig die Feststellung des nicht infizierten Zustands erfolgen kann, da das redundante Emulieren von Anweisungen vermieden wird. Die Arbeitsgeschwindigkeit eines Computers, auf dem eine Antivirus-Software auf Emulatorbasis in Echtzeit läuft, wird dadurch insgesamt höher.

Kurzbeschreibung der Zeichnungen

Diese und andere, genauere und bestimmtere Aufgaben und Merkmale der vorliegenden Erfindung sind vollständiger in der folgenden Beschreibung angegeben, die sich auf die beiliegende Zeichnung bezieht. Es zeigen:
Fig. 1 eine Blockdarstellung für den Aufbau einer Computerplattform, die eine bevorzugte Ausführungsform der vorliegenden Erfindung umfaßt.
Fig. 2 ein Flußdiagramm für ein Verfahren zur Feststellung, ob eine Datei infiziert ist, durch Emulation einer Vielzahl von Versionen einer CPU gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung.
Fig. 3 ein Flußdiagramm für ein Verfahren zur Simulation der Ausführung einer Datei zum Erfassen eines Computervirus gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung.
Fig. 4 eine Tabelle mit den ersten Bytes einer (nicht infizierten) Datei, die durchsucht wird.
Fig. 5 eine Liste für einen Zustandsbericht, der erstellt wird, nachdem die ersten acht Anweisungen der Datei in der Fig. 4 ausgeführt sind.
Fig. 6 eine Tabelle mit den ersten Bytes der Datei der Fig. 4, nachdem die Datei durch einen Computervirus infiziert wurde.

Genaue Beschreibung der bevorzugten Ausführungsformen

Die Fig. 1 ist eine Blockdarstellung für den Aufbau einer Computerplattform, die eine bevorzugte Ausführungsform der vorliegenden Erfindung umfaßt. Die Computerplattform 100 umfaßt Hardwaregeräte 102 und ein Speichermodul 104 zum Speichern von Programmen und Daten. Die Kommunikation zwischen dem Speichermodul 104 und den Hardwaregeräten 102 erfolgt über das Bussystem 106.
Vorzugsweise umfassen die Hardwaregeräte 102, ohne darauf beschränkt zu sein, eine Zentraleinheit (CPU) 108 (z. B. einen Intel "x86" oder einen Motorola Power PC Prozessor), die mit einer Speichereinrichtung 110 (z. B. einer Festplatte) und einem Eingabe/Ausgabe-Interface (I/O-Interface) 112 (z. B. einem Systeminterface für kleine Computer, SCSI, oder einem Personal Computer Memory Card International Association Interface (PCMCIA-Interface))in Verbindung steht. Mit dem I/O-Interface 112 sind ein Speicherlaufwerk 114 (z. B. ein Diskettenlaufwerk), das Programme und Daten von einem Speichermedium 116 (z. B. einer Diskette) lesen kann, und ein Netzwerkinterface 118 (z. B. eine Ethernet-Karte oder ein Modem) verbunden, das über ein Netzwerk 122 (z. B. ein lokales Netzwerk, ein weiträumiges Netz, ein Intranet oder das globale öffentliche Internet) mit einem räumlich getrennten System 120 in Verbindung steht. Ein Softwareprogramm (oder eine Datendatei), das oder die verdächtigt wird, einen Computervirus zu enthalten, kann entweder auf dem Speichermedium 116 (A), der Speichereinrichtung 110 (B) oder dem räumlich getrennten System 120 (C) gespeichert sein.
Vorzugsweise umfassen die im Speichermodul 104 gespeicherten Programme und Daten, ohne darauf beschränkt zu sein, ein Betriebssystem (OS) 150 (z. B. Windows 3.1, Windows 95 oder Windows NT von Microsoft, OS/2 von IBM oder Macintosh OS von Apple Computer oder eine UNIX-Variante), eine Emulationssteuerung 152, einen CPU-Emulator 154, einen virtuellen Speicher 155, einen Signaturscanner 156 und einen Zustands-Cache 158.
Die Emulationssteuerung 152 steuert den CPU-Emulator 154. Unter anderem bestimmt die Emulationssteuerung 152, wann die Emulation einer Datei zu beenden und mit dem Durchsuchen nach Virus-Signaturen zu beginnen ist.
Der CPU-Emulator 154 führt die Dateien in einer vollständig virtuellen Umgebung aus. Die virtuelle Umgebung umfaßt den virtuellen Speicher 155, der effektiv vom Speicher des Host-Computersystems unabhängig ist. Auf diese Weise ist der CPU-Emulator 154 wirkungsvoll von den tatsächlichen Hardwaregeräten 102 isoliert, so daß bei der Simulation einer Datei von einem Virus keine Gefahr ausgeht.
Wenn die Datei danach aussieht, als ob sie einen kodierten Virus enthält, führt die Emulationssteuerung 152 die Emulation fort, bis der Virus entschlüsselt ist und/oder die Kontrolle übernommen hat. Nach dem Ende des Simulation durchsucht der Signaturscanner 156 den virtuellen Speicher 155 nach bekannten Virussignaturen.
Der Zustands-Cache 158 wird von der Emulationssteuerung 152 dazu verwendet, um festzustellen, ob bereits früher festgestellt wurde, daß die Datei virenfrei ist, so daß die Emulation frühzeitig beendet werden kann. Der Zustands-Cache 158 kann nach der Methode "am längsten nicht benutzt" (LRU) oder einer anderen Methode aktualisiert werden. Die Arbeitsweise des Zustands-Caches 158 im Zusammenwirken mit den anderen Komponenten des Systems wird nun anhand der folgenden Darstellungen beschrieben.
Die Fig. 2 und 3 sind Flußdiagramme zur Erläuterung des Verfahrens gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung zur Feststellung, ob eine Datei mit einem Computervirus infiziert ist.
Bestimmte Software kann auf verschiedenen Versionen eines Mikroprozessors laufen, und Computerviren können so beschaffen sein, daß sie nur auf bestimmten Versionen solcher Mikroprozessoren aktiv werden. Zum Beispiel können polymorphe Viren Anweisungen in der Dekodierschleife enthalten, die Anweisungen an anderer Stelle im Viruscode modifiziert. Diese selbstmodifizierende Eigenschaft kann bewirken, daß sich ein polymorpher Virus anders verhält, wenn die infizierten Dateien auf Prozessoren mit unterschiedlichen Größe für die Prefetch-Warteschlange oder Emulatoren für diese Prozessoren laufen. Insbesondere kann ein polymorpher Virus auf Emulatoren mit gewissen Größen für die Prefetch-Warteschlange entschlüsselt werden, auf Emulatoren mit anderen Größen für die Prefetch-Warteschlange jedoch nicht. Wegen des möglichen Einflusses der Größe der Prefetch-Warteschlange auf die Entschlüsselung eines polymorphen Virus ist es möglich, daß eine Datei mit einem selbstmodifizierenden Code wiederholt zu emulieren ist, damit jeder mögliche Virus richtig entschlüsselt werden kann.
Die Fig. 2 ist ein Flußdiagramm für ein Verfahren zur Feststellung, ob eine Datei infiziert ist, durch Emulation der Datei auf einer Anzahl von Versionen einer CPU. Wenn eine Datei (A, B oder C) auf eine Virusinfektion zu untersuchen ist, stellt die Emulationssteuerung 152 in 202 den CPU-Emulator 154 so ein, daß die Version V (V = 1, 2, 3, ...) der CPU emuliert wird. Es sei V = 1 für die erste emulierte Version der CPU. Zum Beispiel kann der CPU-Emulator 154 in 202 so eingestellt werden, daß ein Intel 80386 Prozessor mit einer Prefetch-Warteschlange von 16 Byte oder ein Intel 80486 Prozessor mit einer Prefetch-Warteschlange von 32 Byte emuliert wird.
Nachdem der CPU-Emulator 154 in 202 auf die Version V eingestellt ist, bewirkt die Emulationssteuerung 152 in 204, daß auf dem CPU-Emulator 154 der Prozeß zur Simulierung der Ausführung der Datei auf der Version V der CPU abläuft. Dieser Prozeß ist genauer in der Fig. 3 dargestellt und wird weiter unten anhand der Fig. 3 näher beschrieben.
Nach dem Ablaufen des in der Fig. 3 gezeigten Prozesses stellt die Antivirus- Software in 206 fest, ob es eine weitere Version V der CPU gibt, auf der die Ausführung der Datei auch simuliert werden soll. Wenn es eine weitere Version V der CPU gibt, auf der die Ausführung der Datei ebenfalls simuliert werden soll, geht die Emulationssteuerung 152 zurück zu 202 und stellt den CPU-Emulator 154 auf diese andere Version ein und läßt in 204 wieder den in der Fig. 3 gezeigten Prozeß ablaufen. Wenn es keine weitere Version V der CPU gibt, auf der die Ausführung der Datei auch simuliert werden soll, stellt anderenfalls die Antivirus-Software in 208 fest, ob die Gesamtzahl N(V) an Anweisungen der Datei, die in der Version V simuliert wurden, größer ist als eine vorgegebene Schwellenzahl J.
Wenn N nicht größer ist als J, geht die Antivirus-Software zu 210, was heißt, daß die Datei virenfrei zu sein scheint. Wenn andererseits N größer ist als J, wird in 212 im Zustands-Cache 158 der Zustandsbericht R(1) gespeichert. (Wenn der Zustands-Cache 158 voll ist und eine LRU-Aktualisierungsmethode angewendet wird, ersetzt der Zustandsbericht für die erste CPU-Version, R(1), den am wenigsten verwendeten Zustandsbericht, der im Zustands-Cache 158 gespeichert ist.) Nachdem der Zustandsbericht R(1) in 212 im Zustands-Cache 158 gespeichert ist, kann die Antivirus-Software zu 210 gehen, um anzuzeigen, daß die Datei virenfrei zu sein scheint.
Die Fig. 3 ist eine Flußdiagrammerweiterung des Blocks 204 der Fig. 2, in dem die Antivirus-Software den Prozeß zur Simulation der Ausführung einer Datei auf der Version V der CPU ablaufen läßt.
Zuerst veranlaßt die Emulationssteuerung 152 in 302 den CPU-Emulator 154 (der so eingestellt ist, daß er wie die Version V der CPU arbeitet), die ersten I Anweisungen der Datei zu simulieren. I sei eine vorgegebene Zahl und I < J. Zum Beispiel kann, wenn J = 2048 ist, I gleich 1024 sein.
Wenn in 302 die ersten I Anweisungen simuliert worden sind, unterbricht die Emulationssteuerung 152 in 303 die Simulation und erstellt in 304 einen Zustandsbericht R(V), den sie in 305 vorübergehend speichert. R(V) benötigt zur Speicherung in der Regel weniger Speicher als ein Dateiname und enthält typisch die folgenden Informationen über den Zustand des CPU-Emulators 154:
1) Den virtuellen Anweisungszeiger. Zum Beispiel sollte für einen virtuellen x86 Prozessor der Zustandsbericht CS:IP enthalten. Das CS-Register (Code-Segment- Register) zeigt auf die Startadresse des Codesegments im Speicher, während das IP- Register (Instruktions-Pointer-Register) auf die genaue Stelle im Codesegment zeigt, von der die nächste Anweisung auszulesen ist.
2) Mehrere der Anweisungsbytes vor und/oder nach dem Byte, auf das der virtuelle Anweisungszeiger zeigt. Zum Beispiel kann bei einem x86 Prozessor der Zustandsbericht die Bytes bei CS:IP-8, CS:IP-7, ..., CS:IP-2, CS:IP-1, CS:IP, CS:IP+1, CS:IP+2, ..., CS:IP+6 und CS:IP+7 enthalten.
3) Die Werte der virtuellen allgemeinen Register des CPU-Emulators 154. Zum Beispiel kann bei einem x86 Prozessor der Zustandsbericht die Werte von EAX, EBX, ECX, EDX, EBP, ESI, EDI und ESP enthalten.
4) Mehrere der Bytes vor und/oder nach dem Byte, auf das der Stapelzeiger zeigt. Zum Beispiel kann bei einem x86 Prozessor der Zustandsbericht die Bytes bei SS:SP-8, SS:SP-7, ..., SS:SP-2, SS:SP-1, SS:SP, SS:SP+1, SS:SP+2, ..., SS:SP+6 und SS:SP+7 enthalten. Das SS-Register (Stapel-Segment-Register) zeigt auf die Startadresse des Bereichs im Speicher, der für den Stapel verwendet wird, während das SP-Register (Stapel-Pointer-Register) auf die genaue Stelle im Stapelsegment zeigt, an der die letzte Einheit gespeichert wurde.
Zusätzlich zu den obigen Eigenschaften des Zustands des CPU-Emulators 154 kann R(V) auch Identifikationseigenschaften enthalten, die nicht Teil des CPU-Zustands sind, die jedoch trotzdem nützlich sind, wenn sie als Teil von R(V) gespeichert werden. Solche Eigenschaften sind:
5) Die Größe der Datei, die simuliert wird.
6) Die Anzahl der Einschreibvorgänge in den virtuellen Speicher 155, die bei der Emulation der ersten I Anweisungen ausgeführt wurden.
7) Die Werte für die zyklische Redundanzprüfung (CRC) der bei der Emulation der ersten I Anweisungen in den virtuellen Speicher 155 eingeschriebenen Daten. Die CRC-Werte werden dazu verwendet, um Datenfehler wirkungsvoll festzustellen; ihre Anwendung ist dem Fachmann bekannt.
Nachdem in 305 der Zustandsbericht R(V) vorübergehend abgespeichert wurde, vergleicht die Emulationssteuerung 152 in 306 den Zustandsbericht R(V) mit den im Zustands-Cache 158 gespeicherten Zustandsberichten. Wenn R(V) mit einem der Berichte im Zustands-Cache 158 identisch ist, geht die Antivirus-Software zu 308, um anzuzeigen, daß kein Virus festgestellt wurde, da eine Übereinstimmung im Zustands-Cache vorliegt. Wenn R(V) mit keinem der Berichte im Zustands-Cache 158 übereinstimmt, veranlaßt die Emulationssteuerung 152 den CPU-Emulator 154, in 310 die normale Simulation für das nächste Intervall von Anweisungen wieder aufzunehmen, das mit der nächsten, noch nicht simulierten Anweisung beginnt.
Nachdem in 310 das Intervall von Anweisungen simuliert wurde, verwendet die Emulationssteuerung 152 den Signaturscanner 156, um in 312 das Vorhandensein eines aus einem Satz von bekannten Viren festzustellen. Wenn der Signaturscanner 156 das Vorhandensein eines Virus feststellt, geht die Antivirus-Software zu 314, um anzuzeigen, daß ein Virus festgestellt wurde, und um die Identität des erfaßten Virus anzugeben. Wenn der Signaturscanner 156 keinen Virus findet, stellt die Emulationssteuerung 152 in 316 fest, ob bereits genug Intervalle simuliert worden sind, um die Feststellung, daß die Datei virenfrei ist, mit einem hohen Grad an Sicherheit treffen zu können.
Wenn dazu noch nicht genug Intervalle simuliert wurden, veranlaßt die Emulationssteuerung 152 den CPU-Emulator 154, in 310 die normale Simulation für das nächste Intervall von Anweisungen wieder aufzunehmen, das mit der nächsten, noch nicht simulierten Anweisung beginnt. Wenn andererseits genug Intervalle simuliert wurden, wird in 318 N(V) vorübergehend im Speicher abgespeichert, und der Prozeß geht, da bisher noch kein Virus erfaßt wurde, zu dem in der Fig. 2 gezeigten Block 206 über.
Die Fig. 4, 5 und 6 zeigen die Vorgehensweise bei der vorliegenden Erfindung anhand eines Beispiels. In diesem Beispiel ist die CPU eine einfache Version eines x86 Prozessors, und der Zustandsbericht umfaßt den Anweisungszeiger (CS:IP); die Anweisungsbytes bei CS:IP, CS:IP+1, CS:IP+2, ..., CS:IP+6, CS:IP+7; den Inhalt der allgemeinen Register EAX, EBX, ECX, EDX, ESP, EBP, ESI, EDI; die Dateigröße und die Anzahl der Speicher-Schreibvorgänge, die bei der Ausführung der ersten I Anweisungen aufgetreten sind. Des weiteren ist in diesem Beispiel I = 8 und J = 100.
In der Fig. 4 sind die ersten paar Bytes der in diesem Beispiel untersuchten (nicht infizierten) Datei gezeigt. Nachdem die Antivirus-Software in 302 die ersten I = 8 Anweisungen simuliert hat, wird in 304 ein Zustandsbericht erstellt, der in der Fig. 5 gezeigt ist.
Wenn die (nicht infizierte) Datei das erste Mal untersucht wird, simuliert die Antivirus-Software in 310 das nächste Intervall an Anweisungen, bis in 316 festgestellt wird, daß die Datei wahrscheinlich virenfrei ist. In diesem Beispiel werde nach der Simulation von N = 5000 Anweisungen in 316 festgestellt, daß die Datei wahrscheinlich virenfrei ist.
Da N = 5000 größer ist als J = 100, wird in 212 der in der Fig. 6 gezeigte Zustandsbericht im Zustands-Cache gespeichert, und die Antivirus-Software zeigt in 210 an, daß die Datei virenfrei zu sein scheint.
Die Fig. 6 zeigt die ersten paar Byte der Datei, nachdem sie mit einem Virus infiziert wurde. Die Fig. 6 zeigt auch den Anfang und das Ende des Viruskörpers. Wenn die infizierte Datei untersucht wird, wird der nach I = 8 in 302 simulierten Anweisungen in 304 erstellte Zustandsbericht sich radikal von dem in 304 nach der Simulation von I = 8 Anweisungen der nicht infizierten Datei erstellten Zustandsbericht unterscheiden.
Die obige Beschreibung soll die Vorgehensweise bei den bevorzugten Ausführungsformen darstellen und ist nicht dafür gedacht, den Umfang der Erfindung einzuschränken. Der Umfang der Erfindung wird nur von den folgenden Ansprüchen festgelegt. Aus der obigen Beschreibung ersieht der Fachmann zahlreiche Variationen, die innerhalb des Umfangs der Erfindung liegen.

Claims

1. Computer-implementiertes Verfahren zur Ausführung durch ein Computersystem zum Erfassen von Computerviren in Computerdateien, wobei

das Ausführen einer Computerdatei in einem CPU-Emulator (154) emuliert wird (302); und

die Datei zur Erfassung von Viren durchsucht wird (321);

dadurch gekennzeichnet, daß die Emulation so gesteuert wird, daß sie ohne Durchsuchen beendet wird (308), wenn festgestellt wird (306), daß die Datei zuvor durchsucht wurde, ohne daß ein Virus erfaßt wurde;

wobei in dem Verfahren ferner

die Ausführung einer Subjektdatei suspendiert wird (303), nachdem eine erste vorbestimmte Anzahl von Anweisungen emuliert wurde (302);

ein Zustandsbericht für die Subjektdatei erstellt wird (304), wobei der Zustandsbericht Werte umfaßt, die den gegenwärtigen Betriebszustand des CPU-Emulators wiedergeben;

der Zustandsbericht zeitweise in einem Speicher gespeichert wird (305);

der für die Subjektdatei erstellte Zustandsbericht mit in einem Zustands-Cache- Speicher (158) gespeicherten Zustandsberichten verglichen wird (306), wobei der Zustands-Cache-Speicher Zustandsberichte enthält, die von den zuvor für die erste Anzahl von Anweisungen emulierten Dateien erhalten wurden und für die beim darauffolgenden Durchsuchen kein Virus erfaßt wurde; und wobei

angezeigt wird, daß hinsichtlich der Subjektdatei kein Virus erfaßt wurde, wenn der erstellte Zustandsbericht mit einem der gespeicherten Zustandsberichte übereinstimmt.

2. Verfahren nach Anspruch 1, wobei ferner die Ausführung wieder aufgenommen wird (310), bis eines der folgenden Kriterien erfüllt ist:

Erfassung (314) eines Computervirus; oder

Feststellung (318) mit einem hohen Grad an Sicherheit, daß die Computerdatei frei von jeglichem Computervirus ist.

3. Verfahren nach Anspruch 2, wobei ferner

der erstellte Zustandsbericht in dem Zustands-Cache-Speicher gespeichert wird (212), wenn mit einem hohen Grad an Sicherheit festgestellt wird, daß die Computerdatei virenfrei ist, und wenn die Gesamtzahl der von dem CPU-Emulator ausgeführten Anweisungen der Computerdatei größer ist als eine zweite vorbestimmte Anzahl von Anweisungen.

4. Verfahren nach einem der vorstehenden Ansprüche, wobei der Zustandsbericht einen Wert eines Anweisungszeigers des CPU-Emulators einschließt.

5. Verfahren nach einem der vorstehenden Ansprüche, wobei der Zustandsbericht Werte allgemeiner Register des CPU-Emulators einschließt.

6. Verfahren nach einem der vorstehenden Ansprüche, wobei der Zustandsbericht die Gesamtzahl von Dateneinschreiboperationen in einen virtuellen Speicher (155) während der Ausführung der Computerdatei durch den CPU-Emulator einschließt.

7. Verfahren nach Anspruch 6, wobei der Zustandsbericht einen zyklischen Redundanzprüfwert für die Dateneinschreiboperationen in den virtuellen Speicher während der Ausführung der Computerdatei durch den CPU-Emulator einschließt.

8. System zum Erfassen von Computerviren in Computerdateien, mit

einem CPU-Emulator (154) zum Emulieren der Ausführung einer Computerdatei; und mit

einem Scanner (156) zum Durchsuchen (312) der Datei zum Erfassen von Viren;

gekennzeichnet durch

eine Emulationssteuerung (152) zum Steuern des Emulators so, daß die Emulation ohne Durchsuchen beendet wird (308), wenn festgestellt wird (306), daß die Datei zuvor durchsucht wurde, ohne daß ein Virus erfaßt wurde, wobei die Emulationssteuerung so ausgelegt ist, daß sie die Ausführung einer Subjektdatei nach der Emulation einer ersten vorbestimmten Anzahl von Anweisungen suspendiert;

eine Einrichtung zum Erstellen eines Zustandsberichts für die Subjektdatei, wobei der Zustandsbericht den gegenwärtigen Betriebszustand des CPU-Emulators wiedergebende Werte einschließt;

eine Einrichtung zum zeitweisen Speichern (305) des Zustandsberichts in einem Speicher;

eine Einrichtung zum Vergleichen (306) des für die Subjektdatei erstellten Zustandsberichts mit in einem Zustands-Cache-Speicher (158) gespeicherten Zustandsberichten, wobei der Zustands-Cache-Speicher Zustandsberichte enthält, die von den zuvor für die erste Anzahl von Anweisungen emulierten Dateien erhalten wurden und für die beim darauffolgenden Durchsuchen kein Virus erfaßt wurde; und durch eine Einrichtung zur Anzeige, daß hinsichtlich der Subjektdatei kein Virus erfaßt wurde, wenn der erstellte Zustandsbericht mit einem der gespeicherten Zustandsberichte übereinstimmt.

9. System nach Anspruch 8, ferner mit einer Einrichtung zur Wiederaufnahme (310) der Ausführung, bis eines der folgenden Kriterien erfüllt ist:

Erfassung eines Computervirus; oder

Feststellung mit einem hohen Grad an Sicherheit, daß die Computerdatei frei von einem Computervirus ist.

10. System nach Anspruch 9, ferner mit einer Einrichtung zum Speichern des erstellten Zustandsberichts in dem Zustands-Cache-Speicher, wenn mit einem hohen Grad an Sicherheit festgestellt wird, daß die Computerdatei virenfrei ist, und wenn die Gesamtzahl der von dem CPU-Emulator ausgeführten Anweisungen der Computerdatei größer ist als eine zweite vorbestimmte Anzahl von Anweisungen.

11. System nach einem der Ansprüche 8 bis 10, wobei der Zustandsbericht einen Wert eines Anweisungszeigers des CPU-Emulators einschließt.

12. System nach einem der Ansprüche 8 bis 11, wobei der Zustandsbericht Werte allgemeiner Register des CPU-Emulators einschließt.

13. System nach einem der Ansprüche 8 bis 12, wobei der Zustandsbericht die Gesamtzahl von Dateneinschreiboperationen in einen virtuellen Speicher (155) während der Ausführung der Computerdatei durch den CPU-Emulator einschließt.

14. System nach Anspruch 13, wobei der Zustandsbericht einen zyklischen Redundanzprüfwert für die Dateneinschreiboperationen in den virtuellen Speicher während der Ausführung der Computerdatei durch den CPU-Emulator einschließt.

15. Computerprogrammprodukt, in dem ein computerlesbarer Code zum Ausführen eines Verfahrens nach einem der Ansprüche 1 bis 7 gespeichert ist.