To top
Resources Resources
[Translate to German:]

Kategorien: Software-Schutz

Fallen gegen Hacker

Vielleicht haben Sie bereits meinen Artikel „Softwareschutz aus der Sicht eines Hackers“ in der vorletzten KEYnote gelesen. Dort habe ich mir die Zähne an der Emulation eines CodeMeter-Dongles ausgebissen. Die verschlüsselte Kommunikation zwischen Dongle und Software ist zwar nur „State-Of-The-Art“, aber die im Datenstrom versteckten P-RID-Pakete stellen eine komplett neue Qualitätsstufe im Softwareschutz dar. Die in diesem Artikel beschriebene Art des Angriffs durch Emulation des Dongles habe ich vor allem in Russland gesehen. Daher nenne ich dies auch gerne den „Russischen Hack“. Gegen den „Russischen Hack“ kann sich CodeMeter erfolgreich wehren, aber was ist mit dem „Chinesischen Hack“?.

Der Chinesische Hack

Während der russische Hacker die Software nahezu unverändert lässt, patcht der chinesische Hacker die Software und ersetzt verschlüsselte Stellen durch den unverschlüsselten Code. Damit sind natürlich der Aufwand und die Gefahr von Risiken und Nebenwirkungen deutlich höher als beim russischen Pendant.

Der Aufwand des „Chinesischen Hacks“ hängt dabei natürlich davon ab, ob die Software überhaupt verschlüsselt ist oder reine API-Aufrufe absetzt. Falls sie verschlüsselt ist, ist es natürlich ein deutlicher Unterschied, ob es wie bei den meisten Produkten ein großer Block mit einem Schlüssel ist oder ob es wie bei CodeMeter viele kleine Puzzlesteine, evtl. sogar mit unterschiedlichen Schlüsseln, sind.

Auch hier zeigt sich CodeMeter als „Best-of-Breed“. Bei CodeMeter wird die Software mit AxProtector und IxProtector in viele kleine Puzzlesteine zerlegt und erst zur Laufzeit dynamisch wieder zusammengesetzt. Dabei werden, sogar bei der gleichen Lizenz, unterschiedliche Schlüssel verwendet. Aber wie gut ist dies gegen den „Chinesischen Hack“?

Dynamisch vs. Statisch

Prinzipiell gibt es zwei Vorgehensweisen beim Reverse Engineering. Entweder analysiert der Hacker die Software ohne diese auszuführen durch Disassemblieren und manuelles Entschlüsseln (statische Analyse) oder er führt die Software in einem Debugger aus und beobachtet und modifiziert sie dabei (dynamische Analyse).

Bei einer HelloWorld-Anwendung ist beides mehr oder weniger trivial. Bei der dynamischen Analyse besteht natürlich die Gefahr, dass die geschützte Software Anti-Debug-Maßnahmen implementiert hat und ich als Hacker in eine Debugger-Erkennung tappe.

Bei einer richtigen Anwendung stellt sich dies natürlich anders dar. Im Falle der statischen Analyse muss ich als Hacker alle Teile finden und wieder zusammensetzen. Dies ist ein großer Aufwand, den ich natürlich als Hacker gerne automatisieren möchte.

Die dynamische Analyse

Bei der dynamischen Analyse höre ich oft von angehenden Jung-Hackern, dass „man doch nur warten müsse, bis alle verschlüsselten Methoden einmal aufgerufen wurden und damit entschlüsselt im Speicher liegen“. Ich bin seit den ersten Yellow Point und Yellow Star CDs 1996 in den Bereichen Softwareentwicklung, Softwaretest und Reverse Engineering tätig. Und aus meiner Erfahrung kann ich eins ganz sicher sagen: Wer es schafft, eine fremde Software nahezu komplett zu durchlaufen, d.h. fast jede Codestelle einmal auszuführen, der hat den Stein der Weisen und den Heiligen Gral zugleich gefunden. Wer dies kann, der verdient viel Geld mit seinen Testwerkzeugen und genießt seine Schirmchen-Drinks auf seiner „eigenen“ Insel in der Südsee.

Betrachten Sie zum Beispiel eine Software wie MS Word. Selbst ein Poweruser nutzt weniger als 10% der Funktionalität. Wäre diese Software so geschützt, welcher Hacker würde es schaffen, dann 100% des Codes zu durchlaufen?

Zusammengefasst kann man sagen, dass eine dynamische Analyse bei einer mit dem IxProtector geschützten Anwendung bis auf wenige Ausnahmen, die meist die Komplexität einer HelloWorld-Anwendung nicht übersteigen oder den IxProtector nur rudimentär nutzen, nicht erfolgreich sein wird.

Ein kurzer Rückblick

Die Yellow Point CD ist übrigens ein wunderbares Beispiel, wie man es nicht machen sollte. Eine reine Marketingfirma hat von einem Ingenieur-Büro (ohne vorherige Erfahrung in Bereich Softwareschutz) eine Freischalt-CD entwickeln lassen. Das Ergebnis war in weniger als einer Woche nach Veröffentlichung geknackt. Der Grund war ein fataler Implementierungsfehler, der den verwendeten Schlüssel stark verkürzt hat. Wenn man davon ausgehen kann, dass in jedem verschlüsselten Archiv am Anfang eine exe liegt, was bei 95% der Produkte der Fall war, musste man nur die wenigen Schlüssel durchprobieren und auf „MZ“ (die Kennung einer exe“) triggern. Schon war der Hack fertig. Die Entschlüsselungsroutinen wurden mit der Software ja gleich mitgeliefert. Beim Nachfolger Yellow Star hat man dann auf eine Firma mit jahrelanger Erfahrung in diesem Bereich gesetzt. Diese CDs wurden übrigens nie gekrackt. Die Firma Yellow Point, die alles selbst hat machen lassen, war schnell vom Markt verschwunden. Die Firma hinter Yellow Star, die das Know-how und die Lösung eingekauft hatt, wurde zu einem jahrelangen Erfolg.

Die statische Analyse

Was ist, wenn ich als Hacker also die Anwendung statisch analysiere? Ich nehme mir jede einzelne Methode und entschlüssle diese separat. Dann füge ich die ganze Anwendung wieder zusammen. Und ähnlich wie bei der Yellow Point CD wird der Code zum Entschlüsseln ja gleich mitgeliefert. Ich muss mir diese Routine noch nicht einmal selber schreiben. Wobei das CodeMeter-API so gut zu benutzen ist, dass dies auch kein großer Aufwand für mich wäre.

Die Theorie ist klar, also mache ich mich an die Praxis. Und hier kommt eine große Gemeinheit von CodeMeter. Die verschlüsselte Anwendung ist mit Fallen für meine statische Analyse gespickt und ich habe mir ähnlich wie bei der Debugger-Erkennung bei der dynamischen Analyse schon wieder meine Lizenz gesperrt.

Was ist geschehen? In der Anwendung liegt Code, der eigentlich nie ausgeführt wird, also auch nie entschlüsselt wird. Bei meiner statischen Analyse finde ich natürlich alle verschlüsselten Stellen, was gar nicht so einfach war. Wenn ich alle diese Stellen nacheinander entschlüssele, dann wird auch eine solche Falle entschlüsselt. In dem Augenblick, in dem eine solche Falle entschlüsselt wird, sperrt sich der CodeMeter-Dongle intern automatisch. Aufgrund der vielen unterschiedlichen Schlüssel bei CodeMeter ist es mir unmöglich, eine Falle vorher zu erkennen. Ich merke es erst, wenn es zu spät ist. Aber dann ist die Lizenz gesperrt und ich kann es vergessen, die nächsten Stellen zu entschlüsseln. Die Lizenz ist ja gesperrt.

Diese Art der Fallen durch verschlüsselte Methoden, die beim Entschlüsseln automatisch die Lizenz sperren, ist ein weiterer Quantensprung, der CodeMeter von anderen Schutz- und Lizenzierungssystemen abhebt.

Ablaufdiagramm

Einen Versuch habe ich mir noch gegeben. Ich fange mit der Entschlüsselung der Main-Funktion an und hangle mich durch den Programmablauf. Ich suche, welche Methoden von hier aus aufgerufen werden (natürlich schreibe ich mir dafür ein Tool), entschlüssele diese und suche dort wieder. D. h. ich baue mir ein Ablaufdiagramm der Software auf und finde auf diese Weise heraus, welche Methoden aufgerufen werden und welche nicht. Übrigens, am Namen kann man dies nicht erkennen. Die Jungs von CodeMeter sind eben Profis.

Wenn ich dieses Ablaufdiagramm habe, dann – so dachte ich zumindest – kenne ich alle guten Stellen und kann die anderen als Fallen einstufen. Aber auch hier hat CodeMeter natürlich die Antwort parat. Erwähnte ich schon, dass ich als Hacker an CodeMeter verzweifle? Einige Methoden werden durch Reflection aufgerufen (natürlich sind die Methodennamen verschlüsselt) und können so nicht automatisch als gute Funktionen erkannt werden. Aber noch schlimmer; es sieht so aus, als wenn einige der Fallen in meinem Ablaufdiagramm auftauchen. Durch Verzweigungen, die nach der Logik des Programmes nie zutreffen, werden diese nie aufgerufen, tauchen aber als Verzweigung bei meiner Analyse als „gut“ auf. Und schon wieder sitze ich in der Falle.

Mein Fazit

Und wieder bin ich von CodeMeter beeindruckt. CodeMeter kannte wieder einmal die Antwort auf alle Fragen, die mir eingefallen sind. Die Unterschiede von CodeMeter zu anderen Produkten sind auf den ersten Blick zwar nur gering: fast alle bieten einen Wrapper. Aber die Funktionen unter der Haube, sorgen dafür, dass CodeMeter dem Hacker den entscheidenden Schritt voraus ist.

Natürlich ist der Schutzlevel stark von der Integration in die Software abhängig. CodeMeter kann Fallen automatisch hinzufügen, aber die volle Wirksamkeit entfaltet sich erst, wenn ich als Entwickler der Software die Fallen hinter meiner Geschäftslogik verstecke. Als Entwickler weiß ich, dass eine Böschung nie mehr als 90% geneigt ist, dass mein Kartensatz immer eine gerade Anzahl an Karten enthalten muss, dass mein Motor nie mehr als 19.000 Umdrehungen macht oder der Spitzensteuersatz nie mehr als 100% sein kann. Aber der Hacker weiß dies in der Regel nicht und wird daher in diese Fallen tappen. Und ein Hacker mit einer gesperrten Lizenz ist all seiner Waffen beraubt, CodeMeter sei Dank.  

Wibu-Systems Professional Services Team

Unser Team unterstützt Sie, um Ihre Anforderungen schnell und kostengünstig umzusetzen. Dies umfasst Konzepte und deren Implementierung, so dass Sie wertvolle Zeit sparen. Nutzen Sie unser Wissen und unsere Erfahrung und fordern Sie uns
sales@wibu.com, Tel. +49-(0)721/93172-17