Softwareschutz aus der Sicht eines Hackers

Мы должны знать намерения своих врагов. „Man muss die Argumente seiner Feinde kennen.“, so die Antwort eines Großgrundbesitzers in einem russischen Roman auf die Frage, warum er Karl Marx im Bücherregal habe. Im Bereich Softwareschutz ist ein guter Schutz ohne Kenntnisse der Methoden und Werkzeuge der Hacker auch nur schwer realisierbar.

Nehmen wir an, ich wäre ein Hacker; natürlich nur rein hypothetisch. Warum hacke ich Software? Natürlich vor allem, weil ich es kann und weil es mir Spaß macht. Aber auch, weil ich damit mein Geld verdiene. Ich verteile meine Hacks nicht frei im Internet, ich verkaufe sie. Und ich bin nicht politisch motiviert wie die Hackergruppen, die in Online-Systeme eindringen und Webseiten von Behörden und staatlichen Organisationen lahmlegen.

Mit wem habe ich es zu tun?

Bevor ich loslege, versuche ich so viele Informationen wie möglich über die geschützte Software zu erhalten. Mit welchem Kopierschutzsystem ist sie geschützt? Ist es ein professionelles Kopierschutzsystem oder Marke Eigenbau? Wie ist der Kopierschutz eingebunden? Über ein API oder einen Wrapper? Wird ein Dongle verwendet oder eine rechnergebundene Aktivierung? Bekomme ich von meinem Auftraggeber eine lauffähige Version oder muss ich es ohne Lizenz versuchen? Und letztendlich: Mit welchen Gegenmaßnahmen habe ich zu rechnen?

Ich unterteile meine Hacks in zwei Kategorien: Trivialhacks, die ich ohne Besitz der Lizenz durchführe, und Herausforderungen, bei denen ich eine Lizenz benötige. Im Falle der Herausforderungen geht es mir ähnlich wie Rambo am Ende von Buch 1. Nein, nicht der Film, das Buch. Ich gehe nur langsam und sorgfältig vor, da ich nicht weiß, in welche (für die Lizenz) tödliche Gegenmaßnahmen ich laufen könnte. Dies passiert mir vor allem bei CodeMeter. Ich habe schon viele von deren Dongles gekillt, weil sich die Jungs von Wibu immer wieder neue Fallen einfallen lassen. Falls ich mal die Seiten wechsle, werde ich zu Wibu gehen.

Crack ohne Lizenz

Zuerst untersuche ich die Software und schaue, ob der ausführbare Code verschlüsselt ist. Es gibt doch Menschen, die glauben, sie könnten mich durch die Verwendung eines Packers wie UPX abschrecken. Gepackte Software ordne ich natürlich in die Kategorie „Unverschlüsselt“ ein. Durch die Charakteristika der Anwendung erkenne ich meist sehr einfach, welcher Packer oder welches Verschlüsselungswerkzeug verwendet wurde. Sehr oft ist schon die Benennung der Sektionen ein eindeutiger Hinweis.

Falls ich die Anwendung als unverschlüsselt erkenne, analysiere ich die Anwendung mit einem Disassembler. Bei nativen Anwendungen eignet sich IDA Pro sehr gut, bei einer .NET-Anwendung nehme ich den Reflector, auch wenn dieser jetzt Geld kostet. Während der native Disassembler läuft, zocke ich an meiner Playstation ein oder zwei Stunden. So lange dauert das Disassemblieren. Aber es lohnt sich. Nun kann ich mir einen graphischen Programmablauf anschauen, sehe die Funktionsnamen der verwendeten Bibliothek und finde bei Lösungen Marke Eigenbau meist sehr schnell eine zentrale Stelle, an der ich einen Jump umbiege. Das heißt, aus JNZ einen JZ machen, frei nach dem Motto „Laufe nur, wenn die Lizenz nicht da ist“. Diese Art von Hack mag ich übrigens gar nicht, da sie sich nicht gut verkaufen lässt. Wie kontrolliere ich die Verbreitung meines Hacks und wie sorge ich dafür, dass kein anderer Hacker das Gleiche kostenlos verschenkt? Meist gebe ich so einen Trivialhack kostenlos raus. Wer so wenig macht, hat es verdient, kopiert zu werden.

Man kann mich übrigens auch als Consultant buchen. Dann bin ich der Gute und analysiere Ihre Software in Ihrem Auftrag, ähnlich wie Robert Redford in „Sneakers –  die Lautlosen“. Dann höre ich oft abenteuerliche Konstrukte, was die Entwickler alles Tolles in der Software getrieben haben, um mich zu verwirren. Das Verwirrende daran ist meist nur, dass ich bei meinem JNZ Patch nichts davon gemerkt habe.

Memory Dumping

Wenn die Software verschlüsselt ist, dann habe ich zwei Ansatzmöglichkeiten. Bei beiden benötige ich eine Lizenz. Bei Möglichkeit eins starte ich die Software und warte, bis sie entschlüsselt im Speicher liegt. Dann mache ich einen Memory Dump und rekonstruiere damit die Software.

Erwähnte ich schon, dass ich CodeMeter hasse? Hier ist die Software meist nicht komplett entschlüsselt im Speicher. Das Dumpen ist wie ein großes Puzzlespiel, aber ohne Vorlage. Mein größtes Problem ist es, die Software so laufen zu lassen, dass alle Teile entschlüsselt werden. Dazu müsste ich die Software intensiv benutzen. Ich bin doch kein Experte in der Benutzung einer langweiligen Geologie-Software. Und selbst wenn ich es wäre, woher soll ich wissen, dass alle Funktionen einmal aufgerufen wurden? Selbst der Testplan des Herstellers deckt im Schnitt im besten Fall nur 80% des Codes ab. Wenn ich dies könnte, dann würde ich eine Firma gründen und mit Testwerkzeugen so reich werden, dass ich meine Schirmchen-Drinks in der Karibik genießen kann. Oder ich würde mir eine Villa in Baden-Baden kaufen.

Auch diese Art des Hacks mache ich nur ungern. Zum einen muss ich diesen Hack wiederum schützen, wenn ich ihn verkaufen möchte, und ich muss den Hack mit jedem neuen Release neu machen. Wie soll ich denn reich werden, wenn ich nichts automatisieren kann?

Bei Möglichkeit zwei wandele ich den Hack ab und schreibe mir selber Werkzeuge, die den Schutzumschlag der Verschlüsselung automatisch entfernen. Dann muss ich bei einem neuen Release nur auf den Knopf drücken. Oder wenn mir eine Software mit dem gleichen Schutzumschlag unterkommt, dann drücke ich auch nur den Knopf. Anpassungen an neue Versionen waren bisher nur selten notwendig. Diese Werkzeuge sind mein Vorsprung gegenüber meiner Konkurrenz. Erwähnte ich schon, dass ich CodeMeter hasse? Bei CodeMeter sind verschlüsselte Fallen im Code versteckt. Stoße ich mit meinen Werkzeug auf eine solche Falle, sperre ich die Lizenz und kann den Rest nicht mehr entschlüsseln. Und ich habe es noch nicht geschafft, diese Fallen vorher zu erkennen. Die müssen da viel Zeit hineingesteckt haben. Heute nehme ich mir aber erst einmal die anderen beiden Aufträge mit einem anderen Dongle vor. CodeMeter schaue ich mir nochmal nächste Woche an, wenn ich Langeweile habe.

Record Playback / Emulation

Mein Lieblingshack ist die Emulation, oder ein Record Playback Hack. Ich hänge mich zwischen die Software und den Dongle. Da gibt es doch Menschen, die glauben, dass sie mich mit verschlüsselter Kommunikation abhalten können. Vielleicht viele andere, aber nicht mich. Auch hier habe ich einen Vorsprung gegenüber der Horde an Möchtegern-Hackern.

Ich hatte es ja schon erwartet: Bei CodeMeter ist die Kommunikation verschlüsselt. Auf den ersten Blick so, wie bei den anderen ordentlichen Dongles. Da bietet die Tatsache, dass CodeMeter einen öffentlichen Treiber (den USB Flash Treiber) verwendet, weder mehr noch weniger Ansatzpunkte für mich als ein proprietärer Treiber. Die Anti-Debug Maßnahmen der CodeMeter.exe kosten mich viel mehr Zeit und Mühe als bei anderen Dongles.

Nun lausche ich den Verkehr auf der Leitung mit und mache eine Simulation, eine Emulation oder einen Playback Treiber. Diesen kann ich wunderbar gegen Raubkopien schützen und verkaufen. Und in der Regel ist dieser Hack einfach für weitere Versionen skalierbar. Meine Gelddruckmaschine. Bei einigen älteren Dongles muss ich gar nicht mehr lauschen. Mir reichen ein paar Daten aus dem Dongle, um ihn komplett zu emulieren. Ein eigener Algorithmus war noch nie eine gute Idee. Seitdem viele AES verwenden, ist dies leider nicht mehr möglich. Übrigens war CodeMeter auch hier einer der ersten Dongles, die AES verwendet haben. Sogar der alte WibuKey hatte mit dem FEAL einen Standard-Algorithmus, an den ich mir lange die Zähne ausgebissen habe. Dank 40-Bit Exportkontrolle habe ich es dann doch irgendwann geschafft. Die neue WibuKey Version mit 64-Bit FEAL haben bisher weder ich noch meine Konkurrenten gehackt. Ein guter verwendeter Standard war noch nie der Freund des Hackers.

Auch mein Record Playback versagt bei CodeMeter. Die nennen dies P-RID. Die gleichen benötigten Daten (RID = Required Information Decryption) werden mehrfach in der Software hinterlegt. Zufällig (abhängig von Zeit und Rechner, P = Probabilistic) sollen verschiedene Sequenzen genommen werden. Soweit kam ich bisher aber noch gar nicht, denn es scheint noch eine weitere Verschlüsselungsschicht innerhalb des verschlüsselten Kanals zu geben. Scheinbar direkt von der geschützten Anwendung bis in den CmDongle. Da finde ich aber auch nichts im Handbuch und im verfügbaren API. Das Konzept von Wibu basiert auf drei Schutzschichten bei der Kommunikation: Äußere (einfache) Verschlüsselung, innere Verschlüsselung und zufällige Komponenten. Erwähnte ich schon, dass ich CodeMeter hasse? Ich muss mir dies bei Gelegenheit mal genauer anschauen. Ich mache erst mal die anderen Hacks.

Schlusswort

Natürlich ist die Welt nicht nur schwarz-weiß und ich kombiniere Ansätze in meinen Hacks. Da ich Geld damit verdiene, schütze ich meine Hacks wieder und versuche vor allem skalierende Hacks. Einmal etwas machen und immer wieder Geld verdienen mit dem, was schon da ist. Bei CodeMeter ist das Ganze immer wieder ein Puzzlespiel. Ich muss mit jedem neuen Update fast von ganz vorne anfangen und habe mir und meinem Auftraggebern schon mehrere Lizenzen zerschossen. Die waren nicht so erfreut.

Eine sportliche Herausforderung stachelt mich an. Bei CodeMeter ist es die Fülle der Sequenzen und die immer wieder gleiche, langweilige und langwierige Analyse, die ich hasse. Ich bin mir nie sicher, ob ich jetzt alles habe. Auch hier gibt es natürlich Unterschiede. Ich habe schon schlechte Integrationen von CodeMeter gesehen. Die sind natürlich lösbar. Bei einem Memory Dump einer gut mit CodeMeter geschützten Software reklamiert mein Kunde meist schon nach kurzer Zeit, dass viele Sachen nicht gehen oder mein Hack falsch rechnet. Dazu müsste ich aber die komplette Software verstehen. Ich bin zwar ein sehr guter, aber einfach nur ein Hacker.            

Ergebnis des Hacker‘s Contest 2011 in Russland

Zum ersten Mal fand der von Wibu-Systems initiierte Hacker‘s Contest in Russland statt. Die 114 registrierten Teilnehmer hatten vom 23. November bis zum 8. Dezember 2011 Zeit, den mit 20.000 Euro dotierten Preis zu gewinnen. Das Ziel war es, eine mit CmStick geschützte Software ohne den Sicherheitsschlüssel zu starten.

Das Ergebnis war überwältigend. Es gab weder Teillösungen noch Lösungen und der Gewinn von 20.000 Euro bleibt bei Wibu-Systems. 
Russland ist weltweit für seine Hacker und deren enormes Wissen über Entschlüsselungsverfahren bekannt. Aber selbst die Originalität und der Scharfsinn der Profis half nicht, die Sicherheitsmechanismen zu umgehen oder auszuspionieren.  

Das Ergebnis zeigt, das Wibu-Systems mit seinen Produkten ein Höchstmaß an Sicherheit und Zuverlässigkeit bietet, auf das sich Entwickler beim Schutz  ihres geistigen Eigentums stets verlassen können.

 

KEYnote 23 – Frühjahrsausgabe 2012