Reverse Engineering bei Software – Eine kleine Geschichte, Probleme und Lösungen

Einleitung
Reverse Engineering in der EDV bezeichnet den Vorgang bei dem man versucht, den Quellcode aus dem Binärcode wieder zurückzugewinnen. Dies geschieht zum Beispiel, indem ein ausführbares Programm oder eine Programmbibliothek analysiert wird. Des Weiteren besteht die Möglichkeit Disassemler oder Decompiler zu nutzen. Es gibt hierzu sogar einen Paragraphen im deutschen UrhG (http://bundesrecht.juris.de/urhg/__69e.html). Doch wo liegen Probleme und Gefahren im Reverse Engineering?

Eine kleine Geschichte
Als CED letztens wieder einmal als Qualitätssicherer unterwegs war, analysierten wir wie immer sämtliche Programmkomponenten. Eine Analyse der ausführbaren Programmdatei nach dem Reverse Engineering-Prinzip ergab im Klartext den FTP-Server, den das Programm nutze, um Updates zu laden. Neben dem Servernamen fanden wir auch das Passwort – ebenfalls im Klartext. Dadurch konnten wir auf den FTP-Server des Herstellers mit Lese- und Schreibrechten zugreifen und beliebig Dateien verändern. Es war auch möglich, Dateien hochzuladen, die sich gegenüber der Software als Update ausgeben. Dadurch hätte ein Angreifer Schadcode auf den PC des Endverbrauchers laden können.

Probleme
Manche Programmiersprachen übersetzen den Quellcode nicht vollständig in Maschinencode. So ist es hier meist leicht, Klartext aus der fertigen Datei zu filtern. Zwar bleiben Kommentare (die meistens beim Kompilieren entfernt werden) oder lokale Objektnamen meistens gut versteckt, aber in der Regel findet man sämtliche Befehle und Abfragen, wodurch eine teilweise Herstellung des Programmcodes möglich bleibt. Das Problem ist, wie in der kleinen Geschichte beschrieben, meistens mit Sicherheitsrisiken verbunden. Wer will schon, dass sein Computer mit Viren verseucht wird, weil er ein Updates geladen hat, das gar keins war? Welcher Entwickler will die wochenlange Arbeit von seinem FTP-Server gelöscht haben? Des Weiteren ließen sich mit Reverse Engineering Kopierschutzmechanismen aushebeln, da dabei Verhaltensmuster der Software abgefragt werden können.

Lösungen
Klartext im Programmcode lässt sich meistens nur durch Verschlüsselung umgehen. Im Fall der kleinen Geschichte hätte man also entweder ganz auf die FTP-Einwahl verzichtet oder das Passwort sowie den Namen der FTP-Daten verschlüsselt online hinterlegt. Die Software hätte sie dann eingelesen, entschlüsselt und sich dann eingewählt. Allerdings müsste dann auch der ausgehende Netzwerkverkehr durch die Software verschlüsselt werden, denn sonst könnte man mit einem Netzwerkanalyse-Tool das Passwort bei der Abfrage wieder auslesen. Viele Weitere Ansätze finden Sie auch im englischsprachigen Reverse Engineering-Forum (http://www.reverse-engineering.net/).