Ob es sich um den Umbau eines Automotors oder das Diagramm eines Satzes handelt, Menschen können über viele Dinge lernen, indem sie sie einfach auseinandernehmen und wieder zusammensetzen. Das ist, kurz gesagt, das Konzept des Reverse-Engineering – etwas zu zerlegen, um es zu verstehen, zu kopieren oder zu verbessern.
Ein Prozess, der ursprünglich nur auf Hardware angewandt wurde, wird Reverse-Engineering heute auf Software, Datenbanken und sogar menschliche DNA angewandt. Besonders wichtig ist Reverse-Engineering bei Computer-Hardware und -Software. Programme werden in einer Sprache geschrieben, zum Beispiel C++ oder Java, die für andere Programmierer verständlich ist. Aber um auf einem Computer zu laufen, müssen sie von einem anderen Programm, einem sogenannten Compiler, in die Einsen und Nullen der Maschinensprache übersetzt werden. Kompilierter Code ist für die meisten Programmierer unverständlich, aber es gibt Möglichkeiten, den Maschinencode wieder in ein menschenfreundlicheres Format umzuwandeln, unter anderem mit einem Software-Tool namens Dekompiler.
Reverse-Engineering wird für viele Zwecke eingesetzt: als Lernwerkzeug; als eine Möglichkeit, neue, kompatible Produkte herzustellen, die billiger sind als das, was derzeit auf dem Markt ist; um Software effektiver zusammenarbeiten zu lassen oder um Daten zwischen verschiedenen Betriebssystemen oder Datenbanken zu überbrücken; und um die undokumentierten Funktionen kommerzieller Produkte aufzudecken.
Ein berühmtes Beispiel für Reverse-Engineering ist das in San Jose ansässige Unternehmen Phoenix Technologies Ltd. das Mitte der 1980er Jahre ein BIOS für PCs entwickeln wollte, das mit dem proprietären BIOS des IBM-PCs kompatibel sein sollte. (Ein BIOS ist ein in der Firmware gespeichertes Programm, das beim Starten eines PCs ausgeführt wird; siehe Technology QuickStudy, 25. Juni).
Um sich vor dem Vorwurf zu schützen, das BIOS von IBM einfach (und illegal) kopiert zu haben, entwickelte Phoenix das BIOS in einem so genannten „Reinraum“- oder „Chinese-Wall“-Verfahren zurück. Zunächst untersuchte ein Team von Ingenieuren das IBM-BIOS – etwa 8 KB Code – und beschrieb alles, was es tat, so vollständig wie möglich, ohne den tatsächlichen Code zu verwenden oder darauf zu verweisen. Dann holte Phoenix ein zweites Team von Programmierern hinzu, die keine Vorkenntnisse über das IBM-BIOS hatten und dessen Code nie gesehen hatten. Das zweite Team arbeitete nur mit den funktionalen Spezifikationen des ersten Teams und schrieb ein neues BIOS, das wie angegeben funktionierte.
Das daraus resultierende Phoenix-BIOS unterschied sich zwar vom IBM-Code, funktionierte aber im Großen und Ganzen identisch. Durch den Reinraum-Ansatz gab es keine Urheberrechtsverletzung, selbst wenn einige Codeabschnitte identisch waren. Phoenix begann, sein BIOS an Firmen zu verkaufen, die damit die ersten IBM-kompatiblen PCs bauten.
Andere Firmen, wie Cyrix Corp. und Advanced Micro Devices Inc. haben erfolgreich Mikroprozessoren der Intel Corp. nachgebaut, um billigere Intel-kompatible Chips herzustellen.
Nur wenige Betriebssysteme wurden reverse-engineered. Mit ihren Millionen von Codezeilen – verglichen mit den etwa 32 KB moderner BIOSs – wäre ein Reverse-Engineering eine teure Option.
Aber Anwendungen sind reif für Reverse-Engineering, da nur wenige Software-Entwickler ihren Quellcode veröffentlichen. Technisch gesehen sollte eine Programmierschnittstelle (API) die Zusammenarbeit von Programmen erleichtern, aber Experten sagen, dass die meisten APIs so schlecht geschrieben sind, dass Softwarehersteller von Drittanbietern kaum eine andere Wahl haben, als die Programme, mit denen ihre Software zusammenarbeiten soll, zurückzuentwickeln, nur um Kompatibilität sicherzustellen.
Ethische Gesichtspunkte
Reverse-Engineering kann auch Sicherheitslücken und fragwürdige Datenschutzpraktiken aufdecken. Zum Beispiel hat das Reverse-Engineering der in Dallas ansässigen Digital: Convergence Corp. aus Dallas, dass jedes Lesegerät eine eindeutige Seriennummer hat, die es dem Hersteller erlaubt, die gescannten Codes mit den Registrierungsdaten des Benutzers zu verknüpfen und so die Gewohnheiten jedes Benutzers bis ins kleinste Detail zu verfolgen – eine bisher nicht veröffentlichte Funktion.
Rezente rechtliche Schritte, die von vielen großen Software- und Hardwareherstellern sowie der Unterhaltungsindustrie unterstützt werden, untergraben die Möglichkeiten der Unternehmen, Reverse-Engineering durchzuführen.
„Reverse-Engineering ist legal, aber es gibt zwei Hauptbereiche, in denen wir Bedrohungen für Reverse-Engineering sehen“, sagt Jennifer Granick, Direktorin der Law and Technology Clinic an der Stanford Law School in Palo Alto, Kalifornien. Eine Bedrohung, die noch nicht vor Gericht getestet wurde, kommt von Shrink-Wrap-Lizenzen, die es jedem, der die Software öffnet oder benutzt, ausdrücklich verbieten, sie zurückzuentwickeln, sagt sie.
Die andere Bedrohung geht vom Digital Millennium Copyright Act (DMCA) aus, der die Erstellung oder Verbreitung von Werkzeugen oder Informationen verbietet, die verwendet werden könnten, um technologische Schutzmaßnahmen zu umgehen, die Software vor dem Kopieren schützen. Auf der Grundlage dieses Gesetzes hat das in San Jose ansässige Unternehmen Adobe Systems Inc. im vergangenen Juli das FBI gebeten, den russischen Programmierer Dmitry Sklyarov zu verhaften, als dieser sich zu einer Konferenz in den USA aufhielt. Sklyarov hatte an einer Software gearbeitet, die Adobes E-Book-Dateiverschlüsselung knackte.
Die Tatsache ist, dass selbst legales Reverse-Engineering oft das Brechen solcher Schutzmaßnahmen erfordert, und der DMCA erlaubt Reverse-Engineering zu Kompatibilitätszwecken.
„Aber man darf nicht sehen, ob die Software tut, was sie tun soll“, sagt Granick, und man darf sie auch nicht zu wissenschaftlichen Zwecken untersuchen. Sie bietet eine Analogie an: „Sie haben ein Auto, aber Sie dürfen die Motorhaube nicht öffnen.“
|
|
||||
|
Schwartz ist ein freier Autor in Arlington, Mass. Kontaktieren Sie ihn unter [email protected].