Kopierschutz für Software umgehen

Inhalt dieses Artikel ist es zu zeigen, wie man Software vor unbefugtem kopieren schützen kann – und wie man diesen Schutz wieder umgeht.

Wie man Software „cracken“ kann – ein einfaches Beispiel

Erst mal vorweg: Unter „cracken“ versteht man im Allgemeinen, die Umgehung eines Kopierschutzes oder die Aufhebung eines Sharewareschutzes. Um dies zu demonstrieren habe ich eine eigene kleine Anwendung geschrieben, die nur dazu dient, sie zu cracken. Solche Anwendungen nennt man auch „CrackMes“ und werden oft zu sportlichen Wettkämpfen unter Programmierer entwickelt.

Mein CrackMe ist relativ simpel: Es wird geguckt, ob eine Lizenzdatei vorhanden ist und wenn sie nicht gefunden wird, erscheint ein Dialog „Demoversion“, wird sie gefunden, entsprechend ein Dialog „Vollversion“. Das ganze kann man natürlich relativ einfach damit überwinden, in dem an eine entsprechende Datei in den Anwendungsordner legt, da der Inhalt der Datei in meinem Fall vollkommen uninteressant ist. Wir wollen aber mal so tun, als wenn sie das nicht wäre und den Schutz direkt im Sourcecode „knacken“.

Dazu brauchen wir einen Disassembler bzw. Debugger, der uns die ausführbare Datei wieder in verständlichen Code zurückverwandelt bzw. zeigt welcher Befehl wann ausgeführt wird. Mit „verständlich“ meine ich Assemblercode, weil das ist das höchste aller Gefühle, was man bekommt. Ich verwende dazu das Programm OllyDbg [1]. Es gibt natürlich noch andere und bessere, die einen die Exe regelrecht sezieren, wie zum Beispiel IDAPro [2]. Aber für unsere Zwecke reicht OllyDbg. Ich werde die nächsten Schritte mal ziemlich detailliert beschreiben, damit sie auch nachvollzogen werden können.

Zu erst muss man wissen, dass sich eine Bedingung mit einer anschließenden Verzweigung in der Exe letztendlich als einfacher Sprung manifestiert. Mögliche Sprungbefehle in ASM sind zum Beispiel: je (jump if equal), jne (jump if not equal) usw. Wie das mit dem Springen genau funktioniert, kann man auf der Seite Assembler (80×86 Prozessor)-Programmierung: Sprünge und Schleifen nachlesen. Alles was wir also tun müssen ist, den entscheidenden Sprung finden und ihn entweder umbiegen oder eliminieren.

Dazu öffnen wir die Exe mit OllyDebug und suchen erstmal nach der Zeichenfolge „Demoversion“. Wir gehen einfach mal davon aus, dass sich der entscheidende Sprung irgendwo dort in der Nähe im Code befinden müsste.

Und wie man sieht befindet sich der entscheidende Sprung auch in der Nähe, nämlich an Adresse 00407E2A. Ist die Bedingung erfüllt, wird an die Adresse 00407E41 gesprungen und dort das Programm fortgesetzt. Und genau an dieser Stelle werden die Parameter für den Dialog „Demoversion“ auf den Stack geschoben. Können wir also verhindern, dass an diese Adresse gesprungen wird, haben wir unser Programm gecrackt.

Nun kann man diese Zeile aber nicht einfach löschen, da dann sämtliche Adressen innerhalb der Exe nicht mehr stimmen. Stattdessen füllt man diese Anweisung einfach mit der Anweisung „no operation“: NOP. In OllyDebug ruft man dafür einfach das Kontextmenü für die Zeile auf und wählt den Menüeintrag „Binary -> Fill with NOP’s“. Danach sieht das dann so aus:

Anschließend wählt man den Menüpunkt „Copy to executable -> All modifications“ und speichert die neue Datei als Exe. Führt man die gecrackte Version jetzt aus, erscheint nicht mehr der Dialog „Demoversion“, sondern der Dialog „Vollversion“. Wir haben unsere Anwendung erfolgreich gecrackt.

Natürlich war es recht einfach und in Wirklichkeit wird man wohl selten auf solch einfache Kopierschutze treffen, wenn es derjenige wirklich Ernst gemeint hat. Aber es soll ja nur das Prinzip veranschaulichen, welches uns dann zu folgendem Fazit führt:

Fazit

Wie man sieht, ist jedweder Kopierschutz, der irgendwo im Code auf einen Vergleich basiert, unsicher. Man kann es dem Cracker höchstens versuchen zu erschweren. Was es da unter anderen für Möglichkeiten gibt, haben Oliver Schneider [3], Manuel Pöter[4] und ich in einem älteren Artikel schon mal aufgezeigt. Da es keinen absolut sichern Schutz gibt, sollte man immer abwägen, ob der Aufwand nicht den Nutzen übersteigt und statt einen Kopierschutz zu implemetieren, nicht doch lieber die Arbeit in die Verbesserung der Anwendung investiert.