1998 in Prag: Die Geschichte einer bahnbrechenden Technologie

Produkte Spezielle Projekte

Was ist das Erfolgsgeheimnis des Unternehmens?

Diese Frage wird mir tatsächlich des Öfteren gestellt. Selbstverständlich kann es auf diese Frage keine einfache Antwort geben. Die richtige Formel zu finden, so viel wie möglich und all das auch richtig zu machen, ist nicht gerade einfach. Unser Erfolg ist auf zahlreiche Faktoren, vor allem aber auf Faktoren technologischer Natur, zurückzuführen. Deshalb möchte ich Ihnen in diesem Beitrag von einem unserer Schlüssel zum Erfolg erzählen: eine fundamentale Technologie, die uns seit vielen Jahren dabei hilft, bahnbrechende Produkte aller Kategorien zu entwickeln und gleichzeitig maximalen Schutz gegen alle möglichen Malware-Bedrohungen zu gewährleisten.

Die Technologie nennt sich „Prag“.

Warum? Ganz einfach deshalb, weil sie in Prag erfunden wurde.

Im Frühling 1998 versammelten wir uns in einer kleinen Gruppe, um gemeinsam Bier zu trinken und tschechische Leckereien zu probieren über einen möglichen Kandidaten für die Architektur unserer zukünftigen Produkte nachzudenken. Ich muss zugeben, dass unser kleines Treffen in Prag extrem erfolgreich war: Wir entwickelten eine neue Technologie – die Unified Component Architecture (UCA) – die zahlreiche Produkte auf allen möglichen Plattformen (Betriebssystemen) miteinander verknüpfen konnte. Die UCA befindet sich auch heute noch konstant in der Entwicklungsphase und bildet das Grundgerüst für fast alle unsere Produkte.

Auch andere Unternehmen, die auf das Problem der „multilingualen“ Projekte und Entwicklungen gestoßen sind – was besonders bei komplexen Projekten, bei denen viele Teams involviert sind, oder bei Unternehmenszusammenschlüssen relativ häufig vorkommt – haben bereits ein Auge auf die UCA geworfen.

Unser „Zusammentreffen in Prag“ feiert dieses Jahr bereits 20-jähriges Jubiläum. Das wurde mir allerdings erst bewusst, als ich dabei war einige alte Archive durchzusehen und dabei über eine Datei namens „Technologiedokumentation Prag“ vom 22. Juni 1998 gestolpert bin. Damals waren wir damit beschäftigt, einige wirklich „innovative“ Viren zu bekämpfen und rein technische Probleme mit der AV-Engine zu lösen. Die Lösung, die wir fanden, war um einiges umfangreicher, leistungsfähiger und nützlicher als wir erwartet hätten. Man kann sagen, dass Prag in vielerlei Hinsicht die Kerntechnologie unserer Produkte beeinflusst hat.

Wie alles begann

Damals, als sich unser Unternehmen noch irgendwo in der Garagenphase – in unserem Fall im zweiten Stock eines Kindergartens im Moskauer Stadtteil Strogino – und der Glasbüro-Phase befand. Wir lizenzierten unsere Engine an verschiedene ausländische Partner. Zu dieser Zeit hatten wir bereits eine extrem erfolgreiche Version namens Antiviral Toolkit Pro 3.0 auf dem Markt. Trotzdem gab es auch Zeiten, in denen es für unsere technologische Zukunft nicht immer so rosig aussah.

Denn zwei große Herausforderungen blieben bestehen: Dinge, auf die wir auf gar keinen Fall verzichten konnten, aber deren Umsetzung nicht ganz einfach waren. Zum einen die Fähigkeit, verdächtige Objekte unabhängig von der Art und Weise, wie sie gespeichert wurden, zu verarbeiten (ein typisches Beispiel ist eine „Matroschka“ eingebetteter Objekte. Das heißt, eine ausführbare Malware-Datei befindet sich in einem Archiv, das sich wiederum in einem anderen Archiv befindet). Und zum anderen eine AV-Engine zu erstellen, die so schnell wie möglich aktualisiert werden konnte und minimale (idealerweise gar keine) Änderungen für das Portieren zwischen zwei Plattformen erforderte.

Für diejenigen, die sich eventuell nicht mehr daran erinnern können: Die Virenentwickler der 90er waren sehr erfinderisch, und einige völlig neue Viren erforderten nicht nur die Aktualisierung der Datenbanken, sondern auch der Engine selbst. Benutzer hatten entweder überhaupt keine oder extrem langsame Internetverbindungen, sodass ein Update mit einer Größe von einigen Megabytes ein ernsthaftes Problem darstellte. Angesichts der Tatsache, dass Windows 98 gerade seinen Vormarsch auf der ganzen Welt begonnen, DOS aber noch nicht vollständig ersetzt hatte, mussten alle Erkennungsinnovationen unverzüglich auf  beiden Betriebssystemen funktionieren.

Allgemein gab es so einiges, worüber wir nachdenken mussten, als wir, Alexey De-Monderik, Andrey Kryukov, Andrey Nikishin, Vadim Bogdanov, Larisa Gruzdeva und meine Wenigkeit zum Brainstorming für eine Woche in Prag landeten. Wir mieteten den Konferenzraum eines Hotels, und jeden Tag von 9:00 bis 17:00 Uhr malten und diskutierten wir über unsere Ideen und verzogen uns dann ins Restaurant und Billardzimmer, um bei tschechischem Bier abzuschalten und unsere Einfälle sacken zu lassen.

Die Arbeit war sehr produktiv, und als wir zurück nach Moskau kamen, hatten wir bereits ein ausgeklügeltes Konzept in der Tasche. De-Monderik schrieb unsere Ideen nieder; und genau das war das Dokument, das mir die Idee zu diesem Blog-Artikel gegeben hat. Sehen Sie selbst:

Kryukov und Nikishin debattierten zwar weiterhin über „Prag“, aber erst als Andrey Doukhvalov 1999 unserem Team beitrat, wurde unsere Theorie auch tatsächlich in die Praxis umgesetzt. Seine Erfahrung in der Systementwicklung machte unser Prag-Konzept zu mehr als einem bloßen Plugin-System für die AV-Engine.

Tatsächlich entpuppte sich Prag als eigenständig entwickeltes, objektorientiertes und modulares System, in dem Objekte nach der Anwendungsausführung erstellt und verwaltet wurden, die Objekthierarchie beobachtet wurde und der Kernel Funktionen wie beispielsweise die Speicherverwaltung und das Messaging aktivierte. All das kommunizierte mit dem Betriebssystem und der Benutzeroberfläche über eine ziemlich dünne Schicht, sodass der gesamte Kernel des AVs in Form von „Prag-Plugins“ geschrieben werden konnte.

Doukhvalov entwickelte daraufhin die erste gebrauchsfertige Version für AVP 4.0. Zwar waren wir noch nicht an unserem Ziel angekommen, aber die Stärken der Architektur waren bereits offensichtlich:

  • Das Problem, komplexe verschachtelte Objekte zu verarbeiten wurde vollständig gelöst. Das AV-Programm der Prag-Engine war das Erste auf dem Markt, das infizierte Dateien in Archiven problemlos heilte oder Viren innerhalb eines Multivolumen-Archivs entdeckte. Dabei war es den Erkennungs- und Behandlungsmodulen egal, wo sich das infizierte Objekt ursprünglich befand; in welchem Archiv, Dateisystem, usw.
  • Die AV-Engine konnte problemlos mit den Datenbanken aktualisiert werden und musste nach der Aktualisierung nicht neu gestartet werden.
  • Die Module waren winzig und konnten leicht an verschiedene Plattformen angepasst werden. So konnte KAV 6 beispielsweise problemlos auf Mac-Rechner portiert werden.
  • Der benötigte Speicher war minimal und Prag verbrauchte viel weniger Ressourcen als jedes existierende Objekt-Framework zu der Zeit.

Dank der Nutzung von Prag befanden wir uns auf dem allerneuesten Stand der IT-Branche. Zu dieser Zeit war der modulare Ansatz zur Softwareentwicklung noch nicht so weit fortgeschritten. Später erhielten wir sogar vier US-Patente für Prag: 7386885, 7730535, 7418710, 8234656.

Darüber hinaus war Prag unheimlich leicht zu integrieren, weshalb die Technologie anfangs zur Problemlösung in Version 4.0 eingebaut wurde. Sie bewährte sich so gut, dass Doukhvalov, als bei der Entwicklung der Version 5.0 größere Probleme auftraten, auf die Idee kam, eine neue Version vollständig auf Prag basierend ins Leben zu rufen – das führte zur revolutionären Kaspersky Anti-Virus Version 6, die bereits detailliert beschrieben wurde.

Um ein „Antivirus-Plugin“ in ein Framework zur Erstellung eines ganzen Produkts einzubauen, mussten einige Ansätze verallgemeinert und neu konzipiert werden. Die Hauptdenker hierbei waren Andrey Doukhvalov und Pavel Mezhuev – hätten wir sie nicht gehabt, wäre Prag für solch komplexe Aufgaben nicht geeignet gewesen.

Natürlich ist auch in der Entwicklungswelt nicht alles perfekt, und Prag hatte zwei große Nachteile.

Zum einen war das Debuggen nicht ganz einfach. Und zum anderen hatten Entwickler Schwierigkeiten, die neue Technologie anzunehmen. Egal, von welcher Seite man das Ganze betrachtet: es handelte sich um ein neu entwickeltes Objektsystem, das ziemlich hohe Anforderungen an das Code-Design stellte. Darüber hinaus mussten die Module zunächst in reinem C geschrieben werden. Es war schwierig, Mitarbeiter schnell genug zu schulen, und mit der Zeit benötigten wir immer mehr Entwickler, da unser Unternehmen wuchs und die Produkte immer komplexer wurden.

Somit wurde für uns die Entwicklungsgeschwindigkeit zur Priorität. Uns blieb deshalb nichts anderes übrig als nach und nach auf bekanntere und konventionellere Objekt-Frameworks umzusteigen. Fragmente, die auf Prag basieren, haben wir aber immer noch erfolgreich in unseren Produkten implementiert.

Natürlich hätten diese „Nachteile“ damals behandelt werden können und sollen, weil die Vorteile der Umsetzung von Prag die aufgewandten Ressourcen voll und ganz gerechtfertigt hätten. Prag hat eines der schwierigsten (und teuersten) Probleme gelöst, das besonders in den letzten zehn Jahren relevant wurde – die Portabilität von Technologie (darunter auch die binäre Portabilität) auf verschiedene Plattformen.

Anstatt für jedes Betriebssystem und jeden Prozessor ein neues Produkt von Grund auf neu zu erstellen, haben wir eine vorgefertigte Debug-Engine verwendet. Diese langfristigen Investitionen haben sich nicht nur ausgezahlt, sondern haben bis heute für unsere technologische Führerschaft gesorgt – die Unified Component Architecture, die Nachfolgerin von Prag, wird effektiv ausgenutzt, und bislang sehen wir noch immer keine Probleme, die UCA nicht lösen kann. Ein weiterer Beweis dafür, dass gute Architektur Jahrzehnte überdauert.

Wie Alexei De-Monderik gerne sagt, hat Prag in unserem Unternehmen eine sehr wichtige Rolle gespielt, und das nicht nur im technologischen Sinne. Denn im Grunde genommen hat diese Technologie das Team der berühmten „Sechs“ zusammengebracht. Also ein Hoch auf das Team!

Und selbstverständlich ein Hoch auf dieses unerwartete Jubiläum unserer wichtigsten und wegweisenden Technologie!