DE69702335T2

DE69702335T2 - Emulierendes reparatursystem

Info

Publication number: DE69702335T2
Application number: DE69702335T
Authority: DE
Inventors: Carey Nachenberg
Original assignee: Symantec Corp
Current assignee: Gen Digital Inc
Priority date: 1996-02-09
Filing date: 1997-02-03
Publication date: 2000-11-30
Anticipated expiration: 2017-02-04
Also published as: US6067410A; CA2244892C; WO1997029425A2; DE69702335D1; CA2244892A1; EP0880743A2; WO1997029425A3; AU1848597A; EP0880743B1

Description

Hintergrund der Erfindung

Querverweis auf verwandte Anmeldungen Diese Patentanmeldung hängt mit der mitanhängigen Patentanmeldung WO-A-97/12 322 mit dem Titel "Polymorphic Virus Detection Module" zusammen, wobei diese Patentanmeldung auf denselben Rechtsnachfolger wie hierin übertragen ist.
Gebiet der Erfindung Diese Erfindung betrifft Systeme und Verfahren zum Reparieren von Dateien, die mit Computerviren infiziert worden sind und insbesondere Systeme und Verfahren, die infizierte Dateien unter Verwendung einer Kombination von generischen und virusspezifischen Reparaturroutinen reparieren. Technischer Hintergrund Die Infektion von verschiedenen Startobjekten und ausführbaren Dateien mit Softwareviren ist ein wohlbekanntes und wachsendes Problem. Eine Hauptaufgabe von Antiviren-Anstrengungen ist die Erkennung von infizierten Dateien, und eine Anzahl unterschiedlicher Systeme, einschließlich des oben genannten polymorphen Virenerkennungsmoduls, sind zu diesem Zweck entwickelt worden. Eine Virenerkennung begrenzt den Rahmen der Beschädigung von nichtinfizierten Teilen des Systems, jedoch ist das nur eine der Aufgaben von Antiviren- Programmierern. Eine weitere Aufgabe ist es, jene Dateien zu reparieren, die schon mit dem erkannten Virus infiziert sind (Wirtsdateien). Dies erfordert es, den Viruscode aus der gespeicherten Version der Wirtsdatei zu entfernen und in der Wirtsdatei jeden Code wiederherzustellen, der durch den Virus modifiziert worden sein kann.
Die meisten Computerviren setzen eines von mehreren wohlbekannten Verfahren ein, um Wirtsdateien und Startobjekte zu infizieren. Typischerweise hängt sich der Virus an die Wirts datei an oder stellt sich ihr voran und ersetzt Befehle an der Eintrittsstelle der Wirtsdatei (Wirtsbytes) mit Viruscode, der die Steuerung des Prozessors an den Virus übergibt, wenn die Wirtsdatei ausgeführt wird. Eine andere Gruppe von Viren überschreibt einfach kritischen Code (Wirtsbytes) an der Wirtsdatei-Eintrittsstelle. In fast allen Fällen sichert der Virus die Wirtsbytes, die er überschreibt, so daß die Wirtsbytes in der Wirtsdatei-Abbildung im Speicher anschließend an die Ausführung des Viruscodes wiederhergestellt werden können. Die Steuerung des Prozessors wird dann an die Wirtsdatei-Abbildung im Speicher zurückgegeben, was es gestattet, sie normal auszuführen. Ohne diesen letzten Schritt würde der Prozessor wahrscheinlich abstürzen, was die Aufmerksamkeit auf die Tatsache lenken würde, daß es ein gewisses Problem mit der Wirtsdatei geben kann. Eine solche frühe Erkennung würde den Schaden begrenzen, den ein Virus einem Computersystem zufügen könnte. Folglich investieren Virenentwerfer großen Anstrengung darin, das Vorhandensein ihrer Viren zu verbergen.
Für Wirtsdateien, die durch Standardstrategien infiziert sind, kann eine Reparatur häufig unter Verwendung einer kleinen Bibliothek von Antiviren-Reparaturfunktionen erreicht werden, vorausgesetzt, die Wirtsbytes können lokalisiert und wiederhergestellt werden. Für einfache, unverschlüsselte Viren sind auf Tabellen beruhende Programme, die Einträge für bekannte Viren aufweisen, üblicherweise ausreichend. Jeder Eintrag ist mit einer Reparaturroutine verbunden, die die Speicherstellen der Wirtsbytes im Virus und Subroutinen zur Wiederherstellung der Wirtsbytes in ihrer richtigen Speicherstelle in der Wirtsdatei enthält. Solche auf Tabellen beruhenden Verfahren arbeiten nur mit Viren, die bei jedem Infektionsfall identisch sind und Standard-Infektionsstrategien einsetzen. Der "Thunderbyte AntiVirus" setzt ein Reparatursystem ein, das durch den Viruscode schreitet, einen Befehl auf einmal, jeden Befehl auswertet, jene Befehle abfängt, bei denen es wahrscheinlich erscheint, daß sie das Computersystem beschädigen, und es zuläßt, daß alle anderen Befehle ausgeführt werden. Dieses System ist dazu bestimmt, es zuzulassen, daß der viruseigene Reparaturcode ausgeführt wird und die Wirtsbytes an ihrer richtigen Speicherstelle in der Wirtsdatei wiederhergestellt werden.
Neue Infektionstechniken und Virusarten haben diese bekannten Reparatursysteme zunehmend unzuverlässig gemacht. Sobald zum Beispiel das Thunderbyte-Antivirensystem den Virenentwerfern bekannt wurde, dachten sie sich Wege aus, ihre computersystembeschädigenden Befehle unschädlich erscheinen zu lassen. Thunderbyte führt diese anscheinend unschädlichen Befehle aus, was eine Infektion des Systemspeichers und der Dateien erleichtert, zu deren Schutz es entworfen wurde. Auf Tabellen beruhende Reparaturverfahren sind bei polymorphen Viren unbrauchbar, die komplexe Verschlüsselungsverfahren einsetzen, um einen statischen Viruskörper in einer polymorphen Entschlüsselungsschleife (PDL) zu verbergen. Die PDL erscheint bei jedem Infektionsfall anders, was die festen Reparaturroutinen von auf Tabellen beruhenden Reparaturverfahren unbrauchbar macht. Wenn die Wirtsdatei ausgeführt wird, geht die Steuerung auf den polymorphen Virus über, der sich selbst entschlüsselt, bis der statische Viruskörper regeneriert ist, und dann seinen Schaden bewirkt. Wie bei den meisten Viren, speichern polymorphe Viren überschriebene Wirtsbytes und enthalten Virusreparaturroutinen, die die gesicherten Wirtsbytes wiederherstellen und die Steuerung an die Wirtsdatei übergeben, sobald der Viruscode ausgeführt ist. Bei polymorphen Viren kann jedoch auf die Wirtsbytes nicht zugegriffen werden, ohne zuerst die PDL zu entschlüsseln.
Mindestens ein polymorpher Virus setzt eine neue Infektionsstrategie ein, bei der vielmehr steuerungsübergebende Befehlspakete an verschiedene Speicherstellen in der gesamten Wirtsdatei eingefügt werden, als nur an ihrer Eintrittsstelle. In diesem Fall muß eine Reihe überschriebener Wirtsbytes im verschlüsselten Virus lokalisiert werden und im Wirt wiederhergestellt werden.
Neue Reparaturverfahren, die spezifisch entworfen worden sind, um mit polymorphen Viren umzugehen, weisen CPU-Emulatoren auf, die es zulassen, daß sich der polymorphe Virus selbst entschlüsselt, ohne den Speicher und die Dateien des Computers einer Infektion durch den Virus auszusetzen. Sobald der Virus entschlüsselt ist, wird sein Typ aus seinem statischen Viruskörper identifiziert, und das Reparatursystem versucht, die Wirtsbytes zu lokalisieren und sie an ihrer richtigen Speicherstelle in der Wirtsdatei wiederherzustellen. Diese auf Emulation beruhenden Reparatursysteme setzen oben beschriebene generische Subroutinen zum Reparieren entschlüsselter Dateien ein, und mindestens eines dieser Systeme setzt Makros zum Identifizieren und Umgehen mit Viren ein, die vom Standardinfektionsverfahren abweichen, Jedoch weist die Makrosprache nur eine mäßige Funktionalität auf und ist zum Reparieren komplexer Viren ungeeignet.
Es ist aus WO-A-95/33237 bekannt, eine Viruseinfangvorrichtung bereitzustellen, in der ein Emulator eine Umgebung bereitstellt, die von einem geschützten Computersystem isoliert ist. Ein Datenstrom, der einen Virus enthält, wird in den Emulator eingegeben, wo die Aktivität des Virus erkannt wird.
Erfindungsgemäß wird ein System offenbart zum Reparieren einer Computerdatei, die mit einem Virus infiziert ist, das aufweist:
ein Emulationsmodul, das eine virtuelle Maschine aufweist, in die die Computerdatei geladen wird;
eine Steuerroutine des Emulationsmoduls, die betriebsfähig ist, eine Virusidentitätsinformation zu empfangen, die den infizierenden Virus identifiziert, und die Identitätsinformation in eine Virusdefinitionsdatei der virtuellen Maschine einzugeben, wobei die Virusdefinitionsdatei einen jeweiligen Eintrag für jeden einer Mehrzahl bekannter Viren aufweist, wobei jeder Eintrag eine Entschlüsselungsinformation und einen Zeiger aufweist, um ein virusspezifisches Überlagerungsmodul auszuwählen und um den Eintrag zu identifizieren, der dem infizierenden Virus entspricht;
wobei die Steuerroutine betriebsfähig ist, die virtuelle Maschine mit der Entschlüsselungsinformation über den infizierenden Virus zu versorgen, indem sie auf den Eintrag in der Virusdefinitionsdatei bezug nimmt;
wobei die Steuerroutine ferner betriebsfähig ist, aus der Entschlüsselungsinformation zu bestimmen, ob der Virus verschlüsselt ist, und wenn dem so ist, die Computerdatei unter Verwendung der Entschlüsselungsinformation zu emulieren, bis sich der Virus selbst entschlüsselt;
wobei die Steuerroutine ferner betriebsfähig ist, in die virtuelle Maschine ein Grundmodul zu laden, das generische Reparaturroutinen zum Durchführen einer Dateireparatur aufweist;
wobei die Steuerroutine ferner betriebsfähig ist, in die virtuelle Maschine mehrere Überlagerungsmodule zu laden, die jeweils jeweilige virusspezifische Befehle aufweisen zur Steuerung der virtuellen Maschine während einer Dateireparatur;
wobei die Steuerroutine ferner betriebsfähig ist, ein überla gerungsmodul auszuwählen, indem sie auf den Eintrag für das infizierende Virus in der Virusdefinitionsdatei bezug nimmt, um einen Zeiger auf das ausgewählte Überlagerungsmodul zu erhalten;
wobei die Steuerroutine ferner betriebsfähig ist, die Steuerung der virtuellen Maschine an das ausgewählte Überlagerungsmodul zu übergeben; und
das ausgewählte Überlagerungsmodul betriebsfähig ist, eine Reparatur der virusinfizierten Computerdatei unter Verwendung einer oder mehrerer Reparaturroutinen zu implementieren, die entsprechend dem Inhalt des ausgewählten Überlagerungsmoduls ausgewählt werden, und mindestens eine aufweisen aus:
(a) einer ausgewählten der generischen Reparaturroutinen;
(b) einer Reparaturroutine des Virus; und
(c) einer virusspezifischen Reparaturroutine des ausgewählten Überlagerungsmoduls;
wobei die Reparaturimplementierung die Lokalisierung von Wirtsbytes in der virusinfizierten Computerdatei und das Schreiben der Wirtsbytes in Speicherstellen, die den Wirtsbyte-Speicherstellen in der Computerdatei entsprechen, aus denen sie durch den Virus entfernt wurden, aufweist.
Andere Aspekte der Erfindung werden gemäß den beigefügten Ansprüchen offenbart.
Eine Ausführungsform der vorliegenden Erfindung ist ein System und Verfahren zum Reparieren von Wirtsdateien, die durch einen breiten Bereich von Virustypen infiziert sind, die eine Vielfalt von Infektionsstrategien einsetzen, ohne einen ungeschützten Speicher und Dateien einer Infektion auszusetzen. Das System (200) weist einen Emulator (210) auf, der die volle Funktionalität von Assemblersprache-Reparaturroutinen unterstützt, ohne die Portierbarkeit zu begrenzen und ohne auf Makrosprachen auszuweichen, die eine begrenzte Funktionalität aufweisen.
Gemäß dieser Ausführungsform weist ein Emulations-Reparatursystem (ERS) (200) ein Emulationsmodul (210), ein Grundmodul (240), ein Überlagerungsmodul (262) und eine Virusdefinitionsdatei (230) auf. Das Emulationsmodul (210) weist ein Steuerprogramm (218) auf, das eine virtuelle Maschine (216) erzeugt, die einen virtuellen Prozessor (212) und einen virtuellen Speicher (214) aufweist. Zusätzlich lädt das Steuerprogramm (218) verschiedene Module in die virtuelle Maschine (216). Die virtuelle Maschine (216) gestattet es dem ERS (200), durch ausgewählte Befehle zu schreiten, während es das Computersystem von den Wirkungen dieser Befehle isoliert. Die Virusdefinitionsdatei (230) weist einen Eintrag (232) für jeden bekannten Virus auf, der durch das Emulationsmodul (210) verwendet wird, um die Entschlüsselung jener Viren zu steuern, die verschlüsselt sind. Das Grundmodul (240) weist einen Satz von generischen Maschinensprache-Reparaturroutinen (242) auf, die zum Reparieren von Wirtsdateien (220) nützlich sind, die mit üblichen Viren (224) infiziert sind. Das Überlagerungsmodul (262) ist ein virusspezifisches Maschinensprache-Programm, das in der virtuellen Maschine (216) emuliert wird, um die Wiederherstellung der Wirtsdatei (220) zu steuern, sobald der infizierende Virus (224) entschlüsselt worden ist. Das Überlagerungsmodul (262) kann die Wirtsdatei (220) durch seine eigene virusspezifische (Überlagerungs-) Reparaturroutine (262), die Reparaturroutine (226) des Virus, oder irgendeiner der generischen (Grund-) Reparaturroutinen (242) wiederherstellen.
Wenn es durch ein Virenerkennungsprogramm ausgelöst wird, macht das ERS (200) eine Sicherungskopie (220') der infizierten Wirtsdatei (220), lokalisiert den geeigneten Eintrag (232) für den Virus (224) in der Virusdefinitionsdatei (230), lädt die infizierte Wirtsdatei in den virtuellen Speicher (Wirtsdatei- Abb. 220) und emuliert, falls notwendig, die infizierte Wirtsdatei-Abbildung (220), bis sich der Virus (224) selbst entschlüsselt. Der Virusdefinitionsdatei-Eintrag (232) weist genügend Daten auf, um es dem Emulationsmodul (210) zu gestatten, festzustellen, wenn der statische Viruskörper eines verschlüsselten Virus (224) freigelegt worden ist. Eine Unterbrechungstabelle (248) gestattet eine Emulation von Unterbrechungen, die durch den Virus (224) während der Emulation aufgerufen werden, ohne irgendwelche tatsächliche Verbindungen zwischen der virtuellen Maschine 216 und dem Rest des Computersystems (202) bereitzustellen.
Sobald die Virusentschlüsselung vollendet ist, beginnt eine Reparaturphase. Das Überlagerungsmodul (262) und das Grundmodul (240), die eine lokale Unterbrechungsvektortabelle (250) aufweisen, werden in den virtuellen Speicher (216) geladen, und die Steuerung des virtuellen Prozessors (216) wird an das Überlagerungsmodul (262) übertragen, das im Viruseintrag (232) benannt wird. Die lokale Unterbrechungsvektortabelle (LIVT) (250) weist Unterbrechungen auf, die durch Programme in der virtuellen Maschine (216) aufgerufen werden können, um die Sicherungsdatei (220') zu modifizieren. Der Rest des Computersystems (202) bleibt von der virtuellen Maschine (216) und ihrer virusinfizierten Abbildung der Wirtsdatei (220) isoliert. Für unverschlüsselte Viren zeigen Datenfelder (234) in der Virusdefinition (232) an, daß keine Emulation notwendig ist. In diesem Fall werden die Überlagerungs- und Grundmodule (262, 240) direkt geladen und die Steuerung des virtuellen Prozessors (216) wird an das Überlagerungsmodul (262) übertragen.
Jedes Überlagerungsmodul (262) ist für einen spezifischen Virus (224) geschrieben und enthält Information zur Lokalisie rung der Wirtsbytes (228) und, falls notwendig, der Virusreparaturroutine (226) im Virus (224). Das Überlagerungsmodul (262) verwendet diese Information in Verbindung mit einer gewissen Kombination von Überlagerungs-, Grund- und Virusreparaturroutinen (264, 242, 226), um die Wirtsbytes (228) an ihren richtigen Speicherstellen (114) in der Wirtsdatei (220) wiederherzustellen und den Viruscode (224) von der Wirtsdatei (220) abzuschneiden.
Zum Beispiel kann das Überlagerungsmodul (262), das mit einem Standardvirus (224) verbunden ist, die Steuerung des virtuellen Prozessors (216) an eine der Grundreparaturroutinen (242) übergeben, die dann die notwendigen Modifikationen an der Wirtsdatei (220) vornimmt. Ein Überlagerungsmodul (262), das mit einem Virus (224) verbunden ist, der eine Nichtstandard- Infektionsstrategie verwendet, kann eine Überlagerungsreparaturroutine (264) enthalten, die spezifisch für den Virus (224) bestimmt ist, oder kann die Virusreparaturroutine (226) hinzuwählen, um die Wirtsdatei (220) wiederherzustellen. Im letztgenannten Fall wird die Virusreparaturroutine (226) zunächst modifiziert, wobei, falls notwendig, Überlagerungs- oder Grundroutinen (264, 242) verwendet werden, um anschließend an die Reparatur die Steuerung des virtuellen Prozessor (216) auf das Überlagerungsmodul (262) zurückzuübertragen. Die Steuerung des virtuellen Prozessors (212) wird dann an die modifizierte Virusreparaturroutine (226) übertragen, die die Wirtsbytes (228) an ihrer richtigen Speicherstelle (114) in der Wirtsdatei (220) wiederherstellt und die Steuerung an das Überlagerungsmodul (262) zurückgibt.
Abhängig vom Virustyp und der Reparaturstrategie kann das Überlagerungsmodul (262) die Sicherungsdatei (220') der Wirtsdatei (220) direkt reparieren, die Sicherungs- und Abbildungs wirtsdateien (220', 220") gleichzeitig reparieren, oder die Abbildungswirtsdatei (220") reparieren und anschließend die Sicherungsdatei (220') mit dem reparierten Code überschreiben.

Kurze Beschreibung der Zeichnungen

Die Fig. 1A-1C sind Blockdiagramme von COM-, EXE- und SYS-Dateien (110, 130, 150) vor und nach einer Infektion durch einen Virus.
Fig. 2 ist ein Blockdiagramm eines erfindungsgemäßen Emulations-Reparatursystems (200).
Fig. 3A-3C sind Ablaufpläne eines erfindungsgemäßen Verfahrens, das durch ein Emulations-Reparatursystem (200) zum Reparieren einer infizierten Wirtsdatei eingesetzt wird.
Fig. 4 ist ein Ablaufplan eines Verfahrens, das durch ein Überlagerungsmodul (162) zur Verwendung einer Reparaturroutine (226) innerhalb eines Virus (224) eingesetzt wird, um eine infizierte Wirtsdatei (220) zu reparieren.

Detaillierte Beschreibung der bevorzugten Ausführungsformen

Um das Unheil zu vollenden, zu dem sie bestimmt sind, müssen Softwareviren die Kontrolle über eine Zentraleinheit (CPU) eines Computers gewinnen. Viren tun dies typischerweise, indem sie sich selbst an eine ausführbare Datei (Wirtsdatei) anbringen und die ausführbare Abbildung der Wirtsdatei ihrer Eintrittsstelle modifizieren, um die Steuerung der CPU an den Viruscode zu übertragen. Der Virus verbirgt sein Vorhandensein, indem er die Steuerung an die Wirtsdatei zurücküberträgt, nachdem er abgelaufen ist. Typischerweise tut der Virus dies, indem er die Befehle an der Eintrittsstelle der Wirtsdatei wiederherstellt, die der Virus modifiziert, wenn er die Wirtsdatei infiziert, und die Steuerung auf diese Befehle zurücküberträgt. Die Wiederherstellung findet nur in der ausführbaren Abbildung der Wirtsdatei statt, nicht in der Kopie der infizierten Wirtsda tei, die auf einer Platte gespeichert ist. In DOS-beruhenden Systemen, wo der Großteil der Softwareviren gefunden worden ist, sind die ausführbaren Dateien Befehls- (COM-) Dateien, ausführbare (EXE-) Dateien und System- (SYS-) Dateien.
Auf Fig. 1 A bezugnehmend, werden Blockdiagramme einer COM- Datei 110 vor und nach einer Infektion durch einen Virus 100 gezeigt. Ein Codesegment (Wirtsbytes) 112 der COM-Datei 110 enthält Befehle an und benachbart der Eintrittsstelle 114 der COM-Datei 110. In einer üblichen Infektionsstrategie fügt sich der Virus 100 über die Wirtsbytes 112 ein und kopiert die überschrieben Wirtsbytes 112 an das Ende der COM-Datei 110. Diese Strategie stellt sicher, daß der Virus 100 ausgeführt wird, wenn die COM-Datei 110 ausgeführt wird, während die Wirtsbytes 112 gesichert werden, um die COM-Datei 110 auszuführen, wenn der Virus 100 geendet hat. Die Steuerung wird typischerweise auf die COM-Datei 110 zurückübertragen, indem ein Reparaturcode (Virusreparaturroutine) 102 im Virus 100 enthalten ist, der die Wirtsbytes 112 an ihrer ursprünglichen Speicherstelle wiederherstellt und die Steuerung des Prozessor auf den ersten Befehl der wiederhergestellten Wirtsbytes 112 überträgt.
Die COM-Datei 110 kann auch durch eine Anzahl anderer Strategien infiziert werden. Zum Beispiel kann sich der Virus 100 der COM-Datei 110 voranstellen, so daß die Wirtsbytes 112 dem Virus 100 folgen. Alternativ kann sich der Virus 100 an die COM- Datei 110 anhängen, Wirtsbytes 112 an der Eintrittsstelle 114 mit einem JMP-Befehl zu seiner Adresse überschreiben, die der COM-Datei 110 folgt, und überschriebene Wirtsbytes 112 zum Ausführen der COM-Datei 110 sichern, nach der Virus 100 ausgeführt worden ist.
Nun auf Fig. 1B bezugnebmend, werden Blockdiagramme einer EXE-Datei 130 vor und nach einer Infektion durch einen Virus 120 gezeigt. Die EXE-Datei 130 weist einen Anfangsblock 132 auf, der eine Grundinformation über die Datei enthält. Zum Beispiel ist CS : IP (Wirtsbytes 132) ein Zeiger auf eine Eintrittsstelle 134 der Körpers der EXE-Datei 130 und ist SS : SP (Wirtsbytes 134) ein Zeiger auf einen Stapel 136, der mit der EXE- Datei 130 verknüpft ist. Bei einer Infektion hängt sich der Virus 120 selbst an die EXE-Datei 130 an, ersetzt CS : IP durch einen Zeiger CS' : IP' auf seine eigene Eintrittsstelle 124, ersetzt SS : SP durch einen Zeiger SS':SP' auf eine neue Stapelstelle 136 und sichert Zeiger CS : IP und SS : SP (Wirtsbytes 132, 134), so daß die EXE-Datei 130 anschließend an den Virus 120 ausgeführt werden kann.
Nun auf Fig. 1C bezugnehmend, werden Blockdiagramme einer SYS-Datei 150 vor und nach einer Infektion mit einem Virus 140 gezeigt. Ein SYS-Datei-Anfangsblock 151 enthält einen Strategiezeiger 152 und einen Unterbrechungszeiger 154 (jeweils Wirtsbytes 152, 154), die auf jeweils unterschiedliche Eintrittsstellen 156, 158 der SYS-Datei 150 zeigen. Bei einer Infektion hängt sich der Virus 140 selbst an die SYS-Datei 150 an, ersetzt die Wirtsbytes 152 mit einem Virusstrategiezeiger 142, und sichert die SYS-Datei-Wirtsbytes 152, um auf die SYS- Datei 150 zugreifen zu können, nachdem der Virus 140 ausgeführt worden ist.
Die in den Fig. 1A-1C gezeigten Szenarien repräsentieren einige, jedoch nicht alle der üblichen Strategien, die durch verschiedene Viren 100, 120, 140 jeweils zum Infizieren von COM-, EXE- und SYS-Dateien 110, 130, 150 eingesetzt werden. Diese und zusätzliche Infektionsstrategien werden detaillierter in Nachenberg, "A New Technique For Detecting Polymorphic Computer Viruses" Magister-Arbeit, UCLA (1995) erläutert.
In jeder Infektionsstrategie ist zu erkennen, daß der infi zierende Virus die Wirtsdatei an ihrer Eintrittsstelle modifiziert, um Kontrolle über den Prozessor zu erlangen und alle Wirtsbytes, die er modifiziert, speichert, so daß die Wirtsdatei ausgeführt werden kann, nachdem der infizierende Virus beendet ist. Um infizierte Dateien 110, 130, 150 zu reparieren, muß ein Dateireparatursystem fähig sein, die Wirtsbytes 112, 132, 134, 152 im Virus zu lokalisieren, sie an ihre richtige Speicherstelle in der Datei zu kopieren und den Virus von der Wirtsdatei abzuschneiden. Diese Reparaturen werden nur funktionieren, wenn sie auf die Sicherungsdatei gespiegelt werden, die auf der Computerplatte gespeichert ist, da die Abbildung der Wirtsdatei in der virtuellen Maschine typischerweise nicht auf die Platte zurückgeschrieben wird.
Wie oben bemerkt, wird dieser Prozeß durch die wachsende Verwendung verschlüsselter Viren kompliziert, wie polymorphe Viren, die in jedem Infektionsfall eine andere Erscheinung aufweisen. Zusätzlich sind neue und komplexere Infektionsstrategien für Viren entwickelt worden. Zum Beispiel verteilt der polymorphe Virus OneHalf steuerungsübergebende Befehle auf unterschiedliche Speicherstellen über den gesamten Körper der Wirtsdatei hinweg. Folglich können sich Reparaturroutinen nicht darauf verlassen, daß die Steuerung direkt auf den Virus übertragen wird, und mehrere Wirtsbytes von Speicherstellen über die gesamte Wirtsdatei hinweg müssen gefunden und an ihren richtigen Speicherstellen wiederhergestellt werden, um die Wirtsdatei zu reparieren.
Nun auf Fig. 2 bezugnehmend, wird ein Blockdiagramm eines erfindungsgemäßen Emulations-Reparatursystem 200 gezeigt. Das ERS 200 weist ein Emulationsmodul 210, eine Virusdefinitionsdatei 230, ein Grundmodul 240, eine lokale Unterbrechungsvektortabelle (LIVT) 250 und Überlagerungsmodule 260 auf. Das Emu lationsmodul 210 weist ein Steuerprogramm 218 zur Herstellung einer virtuellen Maschine 216 auf, die einen virtuellen Prozessor 212 und einen zugehörigen virtuellen Speicher 214 aufweist. Die virtuelle Maschine 216 führt Code isoliert vom Rest eines Computersystems 202 aus, das das ERS 200 enthält. Eine Unterbrechungsvektortabelle (IX7T) 248 unterstützt Unterbrechungsaufrufe von Dateien, die durch den virtuellen Prozessor 212 emuliert werden, ohne tatsächlich die virtuelle Maschine 216 und das Computersystem 202 zu verbinden. Der virtuelle Prozessor 212, die IVT 248 und der virtuelle Speicher 214 bilden zusammen eine virtuelle Maschine 216.
Das Grundmodul 240 weist generische (Grund-) Reparaturroutinen 242 auf, die zur Verwendung bei der Wiederherstellung von Wirtsdateien geeignet sind, die durch eine der Standard-Infektionsstrategien infiziert worden sind. Auf die Grundreparaturroutinen 242 wird durch die LIVT 250 zugegriffen, die Zeiger auf die Grundreparaturroutinen 242 aufweist. Das Grundmodul 240, einschließlich der LIVT 250, wird nur dann aktiviert, wenn das ERS 200 in seine Reparaturphase eintritt, wie im folgenden erläutert wird.
Ebenfalls wird eine ausführbare Abbildung einer Wirtsdatei 220" gezeigt, die mit einem Virus 224" infiziert ist. Es wird gezeigt, daß der Virus 224" eine Virusreparaturroutine 226 und gespeicherte Wirtsbytes 228 aufweist. Das Computersystem 202 weist eine Sicherungskopie 220' der Wirtsdatei 220" auf, die durch das ERS 200 erzeugt wird, bevor die Reparaturen beginnen. Die Wirtsdatei 220" und der Virus 224", der die Virusreparaturroutine 226" und Wirtsbytes 228" enthält, werden durch ein- und zweigestrichene Bezugsziffern angezeigt, wenn die Kopien in der virtuellen Maschine 216 bzw. dem Computersystem 202 unterschieden werden müssen. Ungestrichene Bezugsziffern werden verwen det, wenn die Erläuterung auf jede Kopie zutrifft.
Eingänge 202, 204 versorgen das ERS 200 mit dem Namen der infizierten Wirtsdatei 220 und dem Typ des Virus 224. Diese Information kann zum Beispiel durch irgendeines einer Anzahl vom Virenerkennungsmodulen bereitgestellt werden, wie dem polymorphen Antiviren-Erkennungsmodul, das in der verwandten Anmeldung offenbart wird. Tabelle 1 ist ein Speicherabbild des ERS 200, das die Speicherstelle seiner Komponentenmodule zeigt. Wie später im Detail diskutiert wird, werden Überlagerungs- und Grundmodule 260, 240 nur in die virtuelle Maschine 216 geladen, nachdem der Virus 224 entschlüsselt worden ist. Tabelle 1
Zusätzlich zu den Grundreparaturroutinen 242 weist das Grundmodul 240 Daten 244 auf, die für übliche Reparaturen erforderlich sind. Es ist wahrscheinlich, daß Grundreparaturroutinen 242 und Daten 244 regelmäßig aktualisiert werden, um neue Virusrassen und Infektionsstrategien zu unterzubringen. Um diese Änderungen zu erleichtern, wird auf die Grundreparaturroutinen 242 über die LIVT 250 zugegriffen, da nur der Zeiger in der LIVT 250 geändert werden muß, wenn Routinen modifiziert, hinzugefügt oder entfernt werden. In der offenbarten Ausführungsform weist die LIVT 250 256 Unterbrechungen auf, von denen jede auf eine zugehörige der Grundreparaturroutinen 242 zeigt. Die Überlagerungsmodule 260 können jede der Grundreparaturroutinen 242 unter Verwendung der LIVT 250 aufrufen, und jede der Grundreparaturroutinen kann andere Grundreparaturroutinen unter Verwendung der LIVT 250 aufrufen.
Typisch für die Grundreparaturroutinen 242 ist ein Prüfsummenprogramm, um zu verifizieren, daß das infizierende Virus korrekt durch den Virusabtaster identifiziert worden ist und sich die Virusreparaturroutine an ihrer erwarteten Speicherstelle im Virus befindet. Die Grundreparaturroutinen 242 weisen ebenfalls Subroutinen, um mit angehängten Standard-COM- und EXE-Viren umzugehen, zeichenkettensuchende Subroutinen und Subroutinen zum Kopieren eines angegebenen Anzahl von Bytes von einer Speicherstelle in der Wirtsdatei 220 in der virtuellen Maschine 216 zu einer Speicherstelle in der Sicherungsdatei 229 auf.
Zwei Unterbrechungen in der LIVT 250 sind für spezielle Funktionen im ERS 200 reserviert. Die Unterbrechung 21 stellt die einzeige Verbindung zwischen der virtuellen Maschine 216 und der Sicherungsdatei 220' bereit, und die Unterbrechung 3 wird verwendet, um die Steuerung des virtuellen Prozessors 212 vom der Virusreparaturroutine 226" zum Überlagerungsmodul 260 zurückzugeben. Weder die Unterbrechung 21 noch irgendwelche anderen Unterbrechungen der LIVT 250 stellen Verbindungen zu irgendeinem anderen Teil des Computersystems 202 bereit. Dies isoliert die Wirkungen des Virus 224" auf die Sicherungsdatei 220'. Details der Verwendungen der Unterbrechungen 3 und 21 werden im folgenden erläutert.
Die Virusdefinitionsdatei 230 weist einen Eintrag oder eine Virusdefinition 232 für jeden bekannten Virus auf. Jede Virusdefinition 232 enthält eine Information, die spezifisch für einen Virus oder eine Familie solcher Viren ist, einschließlich Daten, die notwendig sind, um den Virus, wenn er verschlüsselt ist, zu seinem statischen Viruskörper zu entschlüsseln. ERS 200 verwendet den Virustyp am Eingang 204 als Index auf eine geeignete Virusdefinition 232 in der Virusdefinitionsdatei 230. Die Virusdefinition 232 weist einen Index auf eine zugehörige Überlagerungsdatei 262 auf, die für den Virus 224 geeignet ist. Wenn der Virus 224 unverschlüsselt ist, wird die Steuerung des virtuellen Prozessors 212 direkt an das zugehörige Überlagerungsmodul 262 übertragen.
Die Virusdefinitionsdateien 230 gemäß der offenbarten Ausführungsform der Erfindung sind wie folgt organisiert:
Hier ist [VirusID] ein Datenfeld für eine Zahl, die den spezifischen Virus oder die Virusrasse identifiziert, für den das ERS 200 aufgerufen wird, um zu reparieren. [SigStart] und [SigEnd] klammern Virussignaturen ein, die Byteketten sind, die charakteristisch für den statischen Viruskörper des Virus 224 sind. In der offenbarten Ausführungsform sich diese Virussignaturen typischerweise die ersten Befehle, die im statischen Viruskörper anschließend an die Entschlüsselung ausgeführt werden, und beginnen häufig mit einem CALL$-Befehl (E8 00 00 in der 80 · 86-Prozessorarchitektur). Die in der Virusdefinition 232 angegebenen Virussignaturen werden durch das Emulationsmodul 210 verwendet, um verschlüsselte Dateien zu entschlüsseln, wie unten detaillierter erläutert wird.
[VirusExecutionCap] spezifiziert eine maximale Anzahl von Virusbefehlen, die notwendig sind, um den Virus zu entschlüsseln und seinen statischen Viruskörper zu enthüllen. Wenn mehr als diese maximale Anzahl von Befehlen emuliert werden, ohne eine Erkennung irgendeiner der angegebenen Virussignaturen, endet die Entschlüsselungsphase des Prozesses, und die Reparaturphase beginnt.
[RepairExecutionCap] spezifiziert eine maximale Anzahl der Befehle, die das überlagerungsmodul 262, die Virusreparaturroutine 226" und das Grundmodul 240 emulieren müßten, um eine Wirtsdatei 220 zu reparieren, die mit dem angegebenen Virus infiziert ist. Wenn mehr als [RepairExecutionCap] Befehle emuliert werden, wird eine Fehlermeldung an das ERS 200 zurückgegeben, die eine erfolglose Reparatur anzeigt. Dies hindert das Überlagerungsmodul 262, die Virusreparaturroutine 226" und das Grundmodul 240 daran, Befehle über den Punkt hinaus zu emulieren, wo es die Möglichkeit einer Reparatur gibt.
[Flags] können verwendet werden, um andere Parameter anzugeben, die mit einem Virus oder einem Wirtsdateityp verbunden sind. Zum Beispiel werden die Kennzeichenbits "STRATEGY" und "INTERRUPT" gegenwärtig unterstützt, um anzugeben, welche Eintrittsstelle einer infizierten SYS-Datei zur Emulation verwendet werden sollt.
[RepairFile] gibt den binären Dateinamen des zugehörigen Überlagerungsprogramms 260 für den identifizierten Virus an.
Virusdefinitionen 232 der Virusdefinitionsdatei 230 werden durch das Emulationsmodul 210 zum Entschlüsseln des Virus 224" und zum Identifizieren des geeigneten der Überlagerungsmodule 260 zur Wiederherstellung der Wirtsdatei 220 verwendet. Das Entschlüsseln verschlüsselter Viren ist ein notwendiger vorbereitender Schritt im Reparaturprozeß, insbesondere, wenn der Virus 224 polymorph ist. In diesen Fällen unterscheidet sich die Erscheinung des polymorphen Virus vor und nach der Entschlüsselung sehr, und die Erscheinung desselben polymorphen Virus ist bei jedem Infektionsfall anders. Andererseits variiert der statische Viruskörper des polymorphen Virus nicht von Infektion zu Infektion, und vorausgesetzt, es ist ein bekannter Virus, wird die Speicherstelle der Wirtsbytes 228" und der Virusreparaturroutine 226" im statischen Viruskörper bekannt sein. Mit einem Wort ist das Entschlüsseln verschlüsselter Viren 224 ein notwendiger vorbereitender Schritt, um sicherzustellen, daß die Speicherstellen der Wirtsbytes 228" und der Virusreparaturroutine 226" im Virus 224" richtig identifiziert werden.
Glücklicherweise müssen alle verschlüsselten Viren, ob sie polymorph sind oder nicht, sich selbst entschlüsseln, um ihre statischen Viruskörper zu erreichen, und zu diesem Zweck enthalten verschlüsselte Viren Entschlüsselungsroutinen, die typischerweise ausgeführt werden, sobald der Virus die Kontrolle über den Prozessor gewinnt. Es wird nur begonnen, den statischen Viruskörper des Virus 224 auszuführen, nachdem die Entschlüsselung vollendet ist. Die vorliegende Erfindung emuliert die Wirtsdatei 220", um es dem Virus 224" zu gestatten, die Kontrolle über den virtuellen Prozessor 212 zu erlangen und sich selbst zu entschlüsseln.
Die in der Virusdefinition 232 angegebenen Virussignaturen werden durch das Emulationsmodul 210 verwendet, um sicherzstellen, daß die Entschlüsselung vollendet ist, bevor das Überlagerungsmodul 232 versucht, auf die Wirtsbytes 228 oder die Virusreparaturroutine 226 zuzugreifen. Wenn die Ausführung der virusinfizierten Wirtsdatei 220" vorschreitet, werden Befehle am Befehlszeiger (IP) mit den Virussignaturen verglichen, und die Emulation wird angehalten, wenn eine Übereinstimmung auftritt. Sobald eine Virussignatur durch das Emulationsmodul 210 erreicht ist, wird ein Ordnungszahlenwert, der der identifizierten Virussignatur zugeordnet ist, in einem virtuellen Register CX gespeichert, bevor die Steuerung des virtuellen Prozessors 212 an das Überlagerungsmodul 262 übergeben wird. Die Inhalte des virtuellen Registers CX gestatten es dem Überlagerungsmodul 262, die Rasse des Virus 224 festzustellen, wenn das Überlagerungsmodul die Steuerung des virtuellen Prozessors 212 übernimmt.
Sobald die Emulation der infizierten Wirtsdatei 220" endet, entweder, weil der verschlüsselte Virus 224" sich selbst entschlüsselt hat oder zunächst unverschlüsselt war, oder weil die [VirusExecutionCap]-Grenze erreicht worden ist, wird das virtuelle Register CX mit einer Anzeige der Virussignatur aktualisiert. Das Steuerprogramm 218 lädt das Überlagerungsmodul 262 und das Grundmodul 240, einschließlich der LIVT 250, in den virtuellen Speicher 214, und übergibt die Steuerung des virtuellen Prozessors 212 an das Überlagerungsmodul 262. Indem die Überlagerungs- und Grundmodule 262, 240 nur geladen werden, nachdem der Virus 224" entschlüsselt worden ist, begrenzt das ERS 200 die Möglichkeit, daß eines der Module durch den Virus 224" während der Entschlüsselung verfälscht werden kann. Entsprechend stellt das Laden der LIVT 250, nachdem die Emulation des Virus 224" geendet hat, sicher, daß der Virus 224" nicht auf das Computersystem 202 zugreifen und es schädigen kann, während er emuliert wird, da nur die LIVT 250 Unterbrechungen enthält, um auf die Sicherungsdatei 220' von der virtuellen Maschine 216 zuzugreifen.
Zusätzlich zum Laden der verschiedenen Module in den virtuellen Speicher 214, wenn das Virus 224" entschlüsselt worden ist, aktualisiert das ERS 200 Register, die mit dem virtuellen Prozessor 212 verbunden sind, wie folgt:
1. ES : DI zeigt auf den CS : IP des Befehls, der der dem letzten Befehl folgt, der während der Virusentschlüsselungsphase emuliert wird. Wenn der Virus 200 nicht entschlüsselt wurde, zeigt ES : DI auf die Eintrittsstelle 124 der infizierten Wirtsdatei 120.
2. DX : AX enthält die Dateigröße der infizierten Wirtsdatei 220.
3. CX enthält eine Zahl, die mit der Virussignatur verbunden ist, die während der Entschlüsselung gefunden wird.
4. SS : SP zeigt auf einen Stapelbereich 266 für die Verwendung durch die Überlagerungs-, Grund-, und Virusreparaturprogramme
5. FS : SI zeigt auf die anfängliche CS : IP-Eintrittsstelle der infizierten Wirtsdatei 220.
Wenn der Virus 224 vollständig entschlüsselt ist und das Überlagerungsmodul 262 im Besitz der Information ist, die notwendig ist, um den Zustand des Virus 224 zu bestimmen, kann das Überlagerungsmodul 262 die Wirtsbytes 228 und die Virusreparaturroutine 226 lokalisieren, die benötigt werden, um die Wirtsdatei 220 zu ihrem Vorinfektionszustand wiederherzustellen.
Der tatsächliche Inhalt des Überlagerungsmoduls 262 hängt von der Beschaffenheit des Virus 224 ab, wie z. B. von der Komplexität der Virusreparaturroutine 226 und der Infektionsstrategie, die durch den Virus 224 eingesetzt wird. Wenn der Virus 224 zum Beispiel eine der früher erläuterten Standardinfektionsstrategien einsetzt, kann es schneller sein, die infizierte Wirtsdatei 220 unter Verwendung von einer oder mehreren Grundreparaturroutinen 242 zu reparieren. Alternativ kann das Überlagerungsmodul 260 seine eigene Überlagerungsreparaturroutine 264 enthalten, um die Wirtsbytes 228 im Virus zu lokalisieren und sie in ihre richtige Speicherstelle in der Wirtsdatei zurückzuschreiben, oder es kann die Virusreparaturroutine 226 verwenden, um dies zu tun.
Für einen komplexeren Virus, wie den OneHalf-Virus, der steuerungsübertragende Befehle auf nicht zusammenhängende Speicherstellen über die gesamte Wirtsdatei 220 verteilt, würde es sehr schwierig sein, die Wirtsdatei unter Verwendung von Grundreparaturroutinen 242 zu reparieren. In diesem Fall enthält das Überlagerungsmodul 262 Code zur Lokalisierung und Hinzuwahl von Virusreparaturcode 226. Wie oben erwähnt, modifizieren Überlagerungsmodule 260, die eine Virusreparaturroutine 226" einsetzen, um die Wirtsdatei 220 wiederherzustellen, die Virusreparaturroutine 226" und die LIVT 250, bevor sie die Steuerung des virtuellen Prozessor 212 an den Virus 224" übergeben. Die Modifikationen beinhalten das Einfügen von Befehlen, die der Virusreparaturroutine 226" folgen, die sicherstellen, daß die Steuerung des Emulationsmoduls 210 anschließend an die Reparatur zum Überlagerungsmodul 262 zurückkehrt.
Nun auf Fig. 3A bezugnehmend, wird eine Übersicht über ein Verfahren 300 zum Reparieren einer infizierten Wirtsdatei 220 gezeigt. Das Reparaturverfahren 300 beginnt, wenn das ERS 200 mit Daten aus einem (nicht gezeigten) Virenerkennungssystem initialisert wird 310. Ein virusspezifischer Code, der durch das Virenerkennungssystem bereitgestellt wird, wird als Index auf eine Virusdefinition 232 in der Virusdefinitionsdatei 230 verwendet. Wie oben erwähnt, weist die Virusdefinition auch eine Information auf, um auf ihr zugehöriges Überlagerungsmodul 262 zuzugreifen. Der Virus 224" wird dann emuliert 340, falls notwendig, bis er entschlüsselt ist, wobei Daten in der Virusdefinition 232 verwendet werden. Überlagerungs- bzw. Grundmodule 262, 240, werden dann in die virtuelle Maschine 216 geladen, und die Steuerung des virtuellen Prozessors 212 wird an das Überlagerungsmodul 262 übertragen 350. Das Überlagerungsmodul 262 ruft, falls notwendig, Überlagerungs-, Grund- und Virusreparaturroutinen 264, 242, 226, auf 360, um eine Reparatur der Wirtsdatei 220 zu bewirken. Gleichgültig welche der Überlagerungs-, Grund- und Virusreparaturroutinen 264, 242, 226 jeweils durch das Überlagerungsmodul 262 eingesetzt werden, um Reparaturen durchzuführen, muß schließlich eine reparierte Kopie der Wirtsdatei 220 auf die Platte kopiert werden. Die Überlagerungsmodule 260 verwenden eine Anzahl unterschiedlicher Unterbrechungen, um Reparaturen durchzuführen und spiegeln sie 376 auf die Plattenkopie der Wirtsdatei 220.
Am Anfang der Reparaturphase werden Überlagerungs- bzw. Grundmodule 262, 240 in die in virtuelle Maschine 216 geladen. Alle Reparaturen, die an der Wirtsdatei 220" unter Kontrolle des Überlagerungsmoduls 262 vorgenommen werden, müssen schließlich auf die Sicherungskopie 220' gespiegelt werden, um den Virus 224' aus dem Computersystem 202 zu beseitigen. Abhängig von der Beschaffenheit des Virus 224 und der Reparaturstrategie, die durch das Überlagerungsmodul 262 implementiert wird, können die Reparaturen auf die Sicherungsdatei 220' auf eine Anzahl unterschiedlicher Arten gespiegelt werden 376. In jedem Fall wird eine Kommunikation zwischen der virtuellen Maschine 216 und der Sicherungsdatei 220' im Computersystem 202 unter Verwendung einer Unterbrechung erzielt, die für diesen Zweck reserviert ist. Die Funktionen, die durch die reservierte Unterbrechung, Unterbrechung 21, implementiert werden, werden in Tabelle 2 zusammengefaßt und unten detaillierter erläutert: Tabelle 2
Zum Beispiel kann das Überlagerungsmodul 262 Wirtsbytes 228" aus dem entschlüsselten Virus 224" in der virtuellen Maschine 216 zurückgewinnen und sie direkt in die Sicherungsdatei 220' unter Verwendung von INT 21 (AH = 4OH) schreiben. Alternativ kann das Überlagerungsmodul 262 alle Reparaturen an der Wirtsdatei 220" in der virtuellen Maschine 216 durchführen und anschließend die reparierte Wirtsdatei 220" von der virtuellen Maschine 215?? über die Sicherungsdatei 220' schreiben. Schließlich kann das Überlagerungsmodul 262 INT 21 verwenden, um einen "Durchschreibe"-Modus (AH = FEH) vor dem Reparieren der Wirtsdatei 220" in der virtuellen Maschine 216 einschalten. Da die Wirtsdatei 220" auf die Sicherungsdatei 220' speicher abgebildet wird, werden alle Änderungen, die an der Wirtsdatei 220" vorgenommen werden, wenn "Durchschreiben" aktiviert ist, in die Sicherungsdatei 220' im Computersystem 202 gespiegelt. Diese Herangehensweise ist insbesondere nützlich, wenn das Überlagerungsmodul 262 die Virusreparaturroutine 226" verwendet, um die Wirtsdatei 220" zu reparieren, weil Reparaturen, die an der Wirtsdatei 220" durch die Virusreparaturroutine 226" vorgenommen werden, gleichzeitig auf die Sicherungsdatei 220' gespiegelt werden. Jedoch kann sie auch verwendet werden, um die Sicherungsdatei 220' zu reparieren, wobei das Überlagerungsmodul 262 einfach Wirtsbytes 228" in die Wirtsdatei 220" in der virtuellen Maschine 216 schreibt.
Eine andere reservierte Unterbrechung, INT 3, wird durch das Überlagerungsmodul 262 verwendet, wenn das Überlagerungsmodul 262 die Virusreparaturroutine 226" verwendet, um die infizierte Wirtsdatei 220" zu reparieren. In diesem Fall verwendet das Überlagerungsmodul 262 INT 3, um sicherzustellen, daß die Virusreparaturroutine 226" die Steuerung des virtuellen Prozessors 216 an das Überlagerungsmodul 262 zurückgibt, wenn die Reparatur beendet worden ist. Wie oben erwähnt, schaltet das Überlagerungsmodul typischerweise den Durchschreibe-Modus ein (INT 21, AH = FEH), bevor es die Steuerung des virtuellen Prozessors 212 an die modifizierte Virusreparaturroutine 226" übergibt, so daß alle Änderungen, die an der Wirtsdatei 220" in der virtuellen Maschine 216 vorgenommen werden, auf die Sicherungsdatei 229 gespiegelt werden.
Nun auf Fig. 3B bezugnehmend, wird ein detaillierter Ablaufplan eines erfindungsgemäßen Verfahrens 300 gezeigt. Anfänglich empfängt 312 das ERS 200 Daten, die die infizierte Wirtsdatei 220 und den Typ des infizierenden Virus 224 identifizieren. Die Virusdaten indizieren 314 eine Virusdefinition (VD) 232 in der Virusdefinitionsdatei 230. Die Virusdefinition weist auch einen Zeiger auf das entsprechende Überlagerungsmodul (OM) 262 auf, so daß das korrekte der Überlagerungsmodule 260 geladen (Schritt 349) werden kann, wenn die Entschlüsselungsphase vollendet ist. Bevor irgendeine Emulation vorgenommen wird, erzeugt 316 das ERS 200 eine Sicherungskopie der infizierten Datei 220 und lädt 318 die Wirtsdatei 220" in den virtuellen Speicher 214.
Unter Verwendung der Virusdefinition 232 stellt das ERS 200 fest 320, ob der Virus 224 entschlüsselt werden muß. Wenn dem so ist, wird der Virus 224 emuliert 330 und seine Befehle an den Befehlszeiger (IP) des virtuellen Prozessors 212 werden mit den Virussignaturen, die in der Virusdefinition 232 angegeben werden, an jedem Punkt der Emulation verglichen 334. In der offenbarten Ausführungsform werden 32 Bytes, beginnend mit der Adresse bei IP mit den Virussignaturen verglichen. Wenn eine Virussignatur unter den Bytes erkannt wird 334, wird die Entschlüsselungsphase als beendet betrachtet und die Reparaturphase beginnt. Das Überlagerungsmodul 262 und das Grundmodul 240, einschließlich der LIVT 250, werden in die virtuelle Maschine 216 geladen 340, und die Steuerung des virtuellen Prozessors 216 wird an das Überlagerungsmodul 262 übertragen 350. Wenn das ERS aus der Virusdefinition 232 feststellt 320, daß der Virus 224 nicht verschlüsselt ist, rückt das ERS direkt zum Ladeschritt 340 vor.
Das Überlagerungsmodul 232 weist eine Überlagerungsreparaturroutine 234 (ORR) auf, die Maschinensprachecode enthält, um vorbereitende Prüfungen 352 am Virus 224 auszuführen, wie die Bestätigung der Identifizierung des Virus 224 und der Wirtsdatei 220. Die vorbereitenden Prüfungen 352 können direkt durch die Überlagerungsreparaturroutine 264 oder in Kombination mit Grundreparaturroutinen (FRR) 242 erfolgen. Wenn die Überlagerungsmodul 262 die Virusreparaturroutine (VRR) 226 verwenden soll 360, um Reparaturen an der Wirtsdatei 220 auszuführen, modifiziert 362 das Überlagerungsmodul 262 zuerst die Virusreparaturroutine 226 mit einem INT 3 Befehl, wie unten erläutert, setzt den Durchschreibemodus auf Ein 366, und übergibt 268 die Steuerung des virtuellen Prozessors 212 an die Virusreparaturroutine 226.
Nun auf Fig. 3C bezugnehmend, wird ein detaillierter Ablaufplan mit den Schritten 362, 367, 368 zum Reparieren der Wirtsdatei 220 mit der Virusreparaturroutine 226" und INT 3 gezeigt. Zuerst verwendet das Überlagerungsmodul 262 Daten über den Virus 224, um die Speicherstelle der Virusreparaturroutine 226" im Virus 224" zu identifizieren 361 und insbesondere zu identifizieren, welcher Befehl im Virus 224 ausgeführt werden wird, sobald die Virusreparaturroutine 226 ausgeführt worden ist. Das Überlagerungsmodul 262 schreibt dann 362 einen CC-Operationscode (UNIT 3) in das Virus 224" an der identifizierten Speicherstelle, aktualisiert 363 NT 3 in der LIVT 250, um auf eine geeignete Wiedereintrittsstelle im Überlagerungsmodul 262 zu zeigen, stellt 364 alle Register in der virtuellen Maschine 216 ein, die für die Virusreparaturroutine 226" notwendig sind, um ihre Arbeit zu verrichten, aktiviert 365 den "Durchschreibe"-Modus, und übergibt 366 die Steuerung des virtuellen Prozessors 216 an die Virusreparaturroutine 226 unter Verwendung eines PUSH/RETF- oder JMP FAR-Befehls. Der Virusreparaturcode 226" wird ausgeführt werden, wobei die Wirtsdatei 220" und die Sicherungsdatei 220' gleichzeitig repariert werden. Wenn die Virusreparaturroutine 226 die INT 3 erreicht, wird sie die Steuerung an die angegebene Wiedereintrittsstelle im Überlagerungsmodul 262 zurückgeben 367, das nach dem Ende der Wirtsda tei 220 sucht 368 und den Virus 224 abschneidet 369.
Erneut zu Fig. 3B zurückkehrend, verwendet 370 eine alternative Reparaturstrategie, die durch ausgewählte Überlagerungsmodule 260 eingesetzt wird, eine oder mehrere der Grundreparaturroutinen 242, um die Wirtsdatei 220 wiederherzustellen. In der offenbarten Ausführungsform werden die geeigneten FRRs 242 durch die Überlagerungsroutine 264 aufgerufen 374 und die Sicherungsdatei 220" wird unter Verwendung entweder der Schreib- (AH = 4OH) oder der Durchschreib- (AH = FEH) Option der INT 21 aktualisiert 376.
In bestimmten Überlagerungsmodulen 262 kann die Überlagerungsreparaturroutine 264 Maschinensprache-Subroutinen enthalten, die für den zugehörigen Virus 224 spezifisch sind, zum Reparieren der infizierten Wirtsdatei 220 ohne Rückgriff auf entweder die Virusreparaturroutine 226" oder die Grundreparaturroutinen 242. In diesem Fall wird die Überlagerungsreparaturroutine 264 ausgeführt 380 und die Sicherungsdatei 220' wird unter Verwendung entweder der Schreib- (AH = 4OH) oder der Durchschreib- (AH = FEH) Optionen der INT 21 aktualisiert 384.
Ein Beispiel eines Überlagerungsmoduls 260, das Routinen aller drei Quellen einsetzt, wird durch das Überlagerungsmodul 262 für den OneHalf-Virus bereitgestellt. Nun auf Fig. 4 bezugnehmend, wird ein Ablaufplan des Verfahrens gezeigt, das durch das Überlagerungsmodul 262 eingesetzt wird zum Implementieren des Viruscodes, um die infizierte Wirtsdatei 220 zu reparieren.
Anfänglich bestätigt 410 das Überlagerungsmodul 260, daß der Typ der infizierten Wirtsdatei 220 mit dem Typ des infizierenden Virus konsistent ist. Diese Prüfung kann direkt in die Überlagerungsreparaturroutine 264 codiert werden. Zum Beispiel infiziert der vorher erwähnte OneHalf-Virus nur COM- oder EXE- Dateien. Wenn folglich ein Virusabtaster eine SYS-Datei iden tifiziert 312, die mit dem OneHalf-Virus infiziert ist, hat entweder der Virusabtaster den Virus 224 fehlidentifiziert oder es ist die falsche Wirtsdatei 220 dem ERS 200 identifiziert worden. In beiden Fällen wird eine Fehlermeldung erzeugt 422. Andernfalls prüft 420 das Überlagerungsmodul 260, daß die Virusreparaturroutine 226" sich an der erwarteten Speicherstelle im Virus 220" befindet. Typischerweise geschieht dies, indem eine Prüfsummenroutine auf den Code beginnend mit der in Frage kommenden Speicherstelle angewendet wird. Die Prüfsummenroutine kann Teil des Überlagerungsmoduls 262 sein oder es kann auf sie durch das Grundmodul 240 zugegriffen werden. Wenn die Prüfsumme anzeigt 420, daß der Code nicht der ist, der erwartet wurde, wird eine Fehlermeldung 422 erzeugt. Anderfalls geht der Reparaturprozeß weiter.
Wenn es festgestellt hat 420, daß sich die Virusreparaturroutine 226" an ihrer erwarteten Speicherstelle im Virus 224" befindet, identifiziert 424 das Überlagerungsmodul 262 den Befehl, der der Virusreparaturroutine 226 folgt und fügt einen INT 3 Befehl an dieser Speicherstelle ein 430. Das Überlagerungsmodul 262 ändert 434 auch den Eintrag in der LIVT 250, der mit INT 3 verbunden ist, um auf eine Wiedereintrittsstelle 266 in der Überlagerungsreparaturroutine 264 zu zeigen, aktiviert 440 den Durchschreibemodus und übergibt 444 die Steuerung des virtuellen Prozessors 212 an den Befehl, mit dem die Virusreparaturroutine 226 beginnt. Die Virusreparaturroutine 226 wird in der virtuellen Maschine 216 ausgeführt 450, bis der INT 3 Befehl erreicht wird, wobei an diesem Punkt die Steuerung auf die Wiedereintrittsstelle 266 im Überlagerungsmodul 262 übertragen wird 450. Wenn das Überlagerungsmodul 262 die Kontrolle über den virtuellen Prozessor 212 anschließend an die Virusreparaturroutine 226 zurückgewinnt 450, verwendet sie INT 21 (AH = 42H), um nach dem Ende der Wirtsdatei 220 zu suchen 460, d. h. vor dem angehängten Virus 224, und schneidet 470 den Virus 224 ab.
Es ist zu beachten, daß einige polymorphe Viren 224 Teile der Wirtsdatei 220 als auch ihre eigenen Viruscodes codieren können. In diesen Fällen enthält die Virusreparaturroutine 226 typischerweise Code, um die Wirtsdatei 220 zu entschlüsseln, d. h. die Entschlüsselung der Wirtsdatei ist als ein Teil des statischen Viruskörpers des Virus 224 implementiert. Folglich wird die Wirtsdateientschlüsselung während der Reparaturphase des ERS 200 stattfinden und wirft keine besonderen Probleme für das System und das Verfahren der vorliegenden Erfindung auf.
Es ist folglich ein System und ein Verfahren zum Reparieren von Wirtsdateien präsentiert worden, die mit einer breiten Vielfalt von Virustypen, einschließlich polymorphen Viren infiziert sind. Das System weist einen Emulator auf, der eine virtuelle Maschine zur Ausführung der Wirtsdatei, des Virus und Reparaturroutinenbefehle isoliert vom Rest des Computersystems erzeugt. Während einer Entschlüsselungsphase werden verschlüsselte Viren unter der Führung einer Virusdefinition emuliert, bis der statische Viruskörper erreicht wird. In der Reparaturphase werden ein virusspezifisches Überlagerungsmodul und ein generisches Grundmodul in die virtuelle Maschine geladen, werden Unterbrechungen zum Kommunizieren mit dem Rest des Computersystems freigegeben und die Steuerung der virtuellen Maschine wird auf das Überlagerungsmodul übertragen. Das Überlagerungsmodul verwendet Reparaturroutinen aus dem Virus, dem Grundmodul oder dem Überlagerungsmodul, allein oder in Kombination, um die virusinfizierte Wirtsdatei zu reparieren. Reparaturen, die an der Wirtsdateikopie vorgenommen werden, die in die virtuelle Maschine geladen ist, werden auf die Sicherungs wirtsdatei im Computersystem gespiegelt, wobei Unterbrechungen verwendet werden, die speziell für jenen Zweck reserviert sind.

Claims

1. System (200) zum Reparieren einer Computerdatei (220), die mit einem Virus infiziert ist, das aufweist:

ein Emulationsmodul (210), das eine virtuelle Maschine (216) aufweist, in die die Computerdatei geladen wird;

eine Steuerroutine (218) des Emulationsmoduls, die betriebsfähig ist, eine Virusidentitätsinformation zu empfangen, die den infizierenden Virus identifiziert, und die Identitätsinformation in eine Virusdefinitionsdatei (230) der virtuellen Maschine einzugeben, wobei die Virusdefinitionsdatei einen jeweiligen Eintrag (232) für jeden einer Mehrzahl bekannter Viren aufweist, wobei jeder Eintrag eine Entschlüsselungsinformation und einen Zeiger aufweist, um ein virusspezifisches Überlagerungsmodul (260) auszuwählen und um den Eintrag zu identifizieren, der dem infizierenden Virus entspricht;

wobei die Steuerroutine betriebsfähig ist, die virtuelle Maschine mit der Entschlüsselungsinformation über den infizierenden Virus zu versorgen, indem sie auf den Eintrag in der Virusdefinitionsdatei bezug nimmt;

wobei die Steuerroutine ferner betriebsfähig ist, aus der Entschlüsselungsinformation bestimmen, ob der Virus verschlüsselt ist, und wenn dem so ist, die Computerdatei unter Verwendung der Entschlüsselungsinformation zu emulieren, bis sich der Virus selbst entschlüsselt;

wobei die Steuerroutine ferner betriebsfähig ist, in die virtuelle Maschine ein Grundmodul (240) zu laden, das generische Reparaturroutinen (242) zum Durchführen einer Dateireparatur aufweist;

wobei die Steuerroutine ferner betriebsfähig ist, in die virtuelle Maschine mehrere Überlagerungsmodule (260) zu laden, die jeweils jeweilige virusspezifische Befehle zur Steuerung der virtuellen Maschine während einer Dateireparatur aufweisen;

wobei die Steuerroutine ferner betriebsfähig ist, ein Überlagerungsmodul auszuwählen, indem sie auf den Eintrag für das infizierende Virus in der Virusdefinitionsdatei bezug nimmt, um einen Zeiger auf das ausgewählte Überlagerungsmodul zu erhalten;

wobei die Steuerroutine ferner betriebsfähig ist, die Steuerung der virtuellen Maschine an das ausgewählte Überlagerungsmodul zu übergeben; und

das ausgewählte Überlagerungsmodul betriebsfähig ist, eine Reparatur der virusinfizierten Computerdatei unter Verwendung einer oder mehrerer Reparaturroutinen zu implementieren, die entsprechend dem Inhalt des ausgewählten Überlagerungsmodul ausgewählt werden, und mindestens eine aufweisen aus:

(a) einer ausgewählten der generischen Reparaturroutinen;

(b) einer Reparaturroutine des Virus; und

(c) einer virusspezifischen Reparaturroutine (262) des ausgewählten Überlagerungsmoduls;

wobei die Reparaturimplementierung die Lokalisierung von Wirtsbytes (228) in der virusinfizierten Computerdatei und das Schreiben der Wirtsbytes in Speicherstellen, die den Wirtsbyte-Speicherstellen in der Computerdatei entsprechen, aus denen sie durch den Virus entfernt wurden, aufweist.

2. System nach Anspruch 1, wobei die Entschlüsselungsinformation mehrere Virussignaturfelder aufweist, in die Bytes anschließend an die Entschlüsselung gespeichert werden, die für den spezifizierten Virus charakteristisch sind.

3. System nach Anspruch 2, wobei die Bytes, die für den spezifizierten Virus charakteristisch sind, Befehle sind, die an oder nahe einer Eintrittsstelle in einen statischen Viruskörper des spezifizierten Virus auftreten.

4. System nach Anspruch 2, wobei die Virussignaturfelder für einen unverschlüsselten Virus leer sind.

5. System nach einem der vorhergehenden Ansprüche, wobei die Steuerroutine des Emulationsmoduls Einrichtungen aufweist zum Erzeugen einer Sicherungskopie der virusinfizierten Computerdatei und Laden einer speicherabgebildeten Abbildung der Sicherungskopie in die virtuelle Maschine.

6. System nach Anspruch 5, wobei das Überlagerungsmodul eine Überlagerungsroutine aufweist, die Befehle aufweist zum Lokalisieren der Virusreparaturroutine in der virusinfizierten Datei in der virtuellen Maschine und Modifizieren der Virusreparaturroutine und der lokalen Unterbrechungsvektortabelle, um die Steuerung der virtuellen Maschine an die Überlagerungsroutine zurückzugegeben, nachdem die Virusreparaturroutine ausgeführt worden ist.

7. System nach Anspruch 5??, wobei die lokale Unterbrechungsvektortabelle eine Durchschreibroutine aufweist zur Spiegelung von Änderungen an der virtuellen Abbildung der infizierten Computerdatei auf die Sicherungsdatei und die Überlagerungsroutine ferner Befehle aufweist zum Aktivieren des Durchschreibmerkmals vor dem Übergeben der Steuerung der virtuellen Maschine an den Virusreparaturcode.

8. System nach einem der vorhergehenden Ansprüche, wobei jeder Eintrag in die Virusdefinitionsdatei ferner eine Entschlüsselungsemulationsdeckelung aufweist zum Spezifizieren einer maximalen Zahl von Befehlen, die notwendig sind, den spezifizierten Virus zu entschlüsseln.

9. System nach einem der vorhergehenden Ansprüche, wobei jeder Eintrag in der Virusdefinitionsdatei ferner eine Reparaturemulationsdeckelung aufweist zum Spezifizieren einer maximalen Zahl von Befehlen, die notwendig sind, den spezifizierten Virus zu reparieren.

10. System nach einem der vorhergehenden Ansprüche, wobei die generischen Reparaturroutinen des Grundmoduls eine Prüfsummenroutine zum Verifizieren der Identität der Befehle in einem Virus aufweisen.

11. System nach einem der vorhergehenden Ansprüche, wobei die generischen Reparaturroutinen des Grundmoduls eine Zeichenketten-Suchroutine zum Lokalisieren spezifizierter Befehle in einem Virus aufweisen.

12. System nach einem der vorhergehenden Ansprüche, wobei die generischen Reparaturroutinen des Grundmoduls eine Routine zum Schreiben von Bytes an einer ersten Speicherstelle in der virtuelle Maschine in eine zweite Speicherstelle in der virtuellen Maschine aufweisen.

13. System nach einem der vorhergehenden Ansprüche, wobei die generischen Reparaturroutinen des Grundmoduls eine Routine zum Kopieren von Bytes an einer ersten Speicherstelle in der virtuellen Maschine zu einer zweiten Speicherstelle in der Sicherungsdatei aufweisen.

14. Verfahren zum Reparieren einer Computerdatei, die mit einem Virus infiziert ist, das die Schritte aufweist:

Laden der Computerdatei (220) in ein Emulationsmodul (210), das eine virtuelle Maschine (216) aufweist;

Empfangen in einer Steuerroutine (218) des Emulationsmoduls (210) einer Virusidentitätsinformation, die den infizierenden Virus identifiziert, und Eingeben der Identitätsinformation in eine Virusdefinitionsdatei (230) der virtuellen Maschine, wobei die Virusdefinitionsdatei einen jeweiligen Eintrag (232) für jeden einer Mehrzahl bekannter Viren aufweist, wobei jeder Eintrag eine Entschlüsselungsinformation und einen Zeiger enthält, um ein virusspezifisches Überlagerungsmodul (260) auszuwählen, und Identifizieren des Eintrags, der dem infizierenden Virus entspricht;

wobei die Steuerroutine (218) die virtuelle Maschine mit der Entschlüsselungsinformation über den infizierenden Virus versorgt, indem sie auf den Eintrag in der Virusdefinitionsdatei bezug nimmt;

wobei die Steuerroutine (218) aus der Entschlüsselungsinformation bestimmt, ob der Virus verschlüsselt ist, und wenn dem so ist, die Computerdatei unter Verwendung der Entschlüsselungsinformation emuliert, bis sich der Virus selbst entschlüsselt;

wobei die Steuerroutine (218) in die virtuelle Maschine ein Grundmodul (240) lädt, das generische Reparaturroutinen (242) zum Durchführen einer Dateireparatur aufweist;

wobei die Steuerroutine (218) in die virtuelle Maschine mehrere Überlagerungsmodule (260) lädt, die jeweils jeweilige virusspezifische Befehle aufweisen zur Steuerung der virtuellen Maschine während der Dateireparatur;

Auswählen eines Überlagerungsmoduls durch Bezugnahme auf den Eintrag für den infizierenden Virus in der Virusdefinitionsdatei, um einen Zeiger auf das ausgewählte Überlagerungsmodul zu erhalten;

Übergeben der Steuerung der virtuellen Maschine an das ausgewählte Überlagerungsmodul; und

Implementieren der Reparatur der virusinfizierten Computerdatei unter der Steuerung des ausgewählten Überlagerungsmoduls, wobei eine oder mehrere Reparaturroutinen verwendet werden, die entsprechend dem Inhalt des ausgewählten Überlagerungsmoduls ausgewählt werden und mindestens eine aufweisen aus:

(a) einer ausgewählten der generischen Reparaturroutinen;

(b) einer Reparaturroutine des Virus; und

wobei die Reparaturimplementierung das Lokalisieren von Wirtsbytes (228) in der virusinfizierten Computerdatei und das Schreiben der Wirtsbytes in Speicherstellen aufweist, die den Wirtsbyte-Speicherstellen in der Computerdatei entsprechen, aus denen sie durch den Virus entfernt wurden.

15. Verfahren nach Anspruch 14, wobei der Versorgungsschritt die Teilschritte aufweist:

Empfangen einer Virusidentitätsinformation aus einem Virusabtastmodul; und

Lokalisieren einer Virusdefinition, die mit der Virusidentitätsinformation verbunden ist; und

Bereitstellen der Entschlüsselungsinformation in ausgewählten Feldern innerhalb der zugehörigen Virusdefinition.

16. Verfahren nach Anspruch 15, das den zusätzlichen Schritt des Identifizierens des Überlagerungsmoduls, das für den Virus geeignet ist, in einem ausgewählten Feld der Virusdefinition aufweist.

17. Verfahren nach Anspruch 14, wobei der Schritt des Emulierens der infizierten Computerdatei die Teilschritte aufweise:

Wiedergewinnen einer ausgewählte Anzahl von Bytes aus der infizierten Computerdatei;

Vergleichen der wiedergewonnenen Bytes mit der Entschlüsselungsinformation, um festzustellen, ob die Bytes einen ausgewählten Befehl repräsentieren, der im Virus erscheint, wenn er entschlüsselt ist;

Anzeigen, daß die Entschlüsselung vollendet ist, wenn die wiedergewonnenen Bytes mit einem ausgewählten Befehl übereinstimmen; und

Emulieren eines Befehls, der durch die wiedergewonnenen Bytes repräsentiert wird, und Wiederholen der Zurückgewinn- und Vergleichsschritte, wenn die wiedergewonnenen Bytes nicht mit einem ausgewählten Befehl übereinstimmen.

18. Verfahren nach Anspruch 14, wobei der Implementierungsschritt die Teilschritte aufweist:

Lokalisieren des Virusreparaturcodes im Virus;

Modifizieren des Virusreparaturcodes, um die Steuerung an das Überlagerungsmodul zurückzugeben, wenn der Virusreparaturcode ausgeführt worden ist; und

Übergeben der Steuerung des virtuellen Prozessors an den Virusreparaturcode.

19. Verfahren nach Anspruch 14, wobei der Implementierungsschritt die Teilschritte aufweist:

Lokalisieren von Wirtsbytes im Virus;

Bestimmen von Speicherstellen für die Wirtsbytes in der Wirtsdatei, wenn sie nicht infiziert ist; und

Aufrufen von Reparaturroutinen im Grundmodul, um die lokalisierten Wirtsbytes in die Wirtsbyte-Speicherstellen in der Wirtsdatei zu schreiben.

20. Computerlesbares Speichermedium, auf dem ein gespeicherter Programmcode zum Reparieren einer virusinfizierten Computerdatei gemäß dem Verfahren nach einem der Ansprüche 14 bis 19 gespeichert ist.