Kopierrschutz mit dot.NET [geht das?]

[Iwo Asnet]

Wir (meine Firma) sind auf der Suche nach einem Kopierschutz für dot.NET. Neben den üblichen Diskussionen, das das ohne Internet-Verbindung sowieso nicht geht, stellt sich uns die Frage, wie leicht es ist, den Kopierschutz mit Dot.Net zu knacken.

Bei normalen Win32-Anwendungen disassembliert man den Code, schmeisst die Abfragen nach "If Lizenz=Legal" raus und hat eine geknackte Version.
Ist das bei dot.NET noch einfacher, oder im Grunde genommen genauso 'simpel'? Bringt ein Obfuscator irgendetwas?

Gibt es robuste Lösungen, die auch für Dot.NET gelten? Von mir aus auf Basis eines Dongels und 1000facher Abfrage im Code?

Würde mich über Denkanstöße, Zurechtweisungen, Information usw. sehr freuen.

Danke schön im Voraus!

[Phoenix]

was soll denn das ausgeschriebe dot da immer?
Das heisst ganz einfach nur .Net, und fertig is.

Und ja, das geht. Ein Obfuscator ist auf jeden Fall nötig, sonst braucht man mit Schützen gar nicht anfangen.
Die Jungs von Wibu haben einen Dongle-basierten Ansatz von Schutz, und das scheint sehr gut zu funktionieren.

Ansonsten bringt .Net aus sein eigenes Licensing System mit, aber das ist relativ schwierig zu verstehen und umständlich umzusetzen. Da sind die Verschlüsselungsansätze meiner Meinung nach besser.

[EWeiss]

Zitat:

Das heisst ganz einfach nur .Net, und fertig is.

Ansonsten hieße es ja auch Dot Dot Net und nicht dot.Net
schließlich steht dot für "Punkt"

gruss

[daywalker9]

Zitat von Phoenix:

was soll denn das ausgeschriebe dot da immer?
Das heisst ganz einfach nur .Net, und fertig is.

Und ja, das geht. Ein Obfuscator ist auf jeden Fall nötig, sonst braucht man mit Schützen gar nicht anfangen.
Die Jungs von Wibu haben einen Dongle-basierten Ansatz von Schutz, und das scheint sehr gut zu funktionieren.

Ansonsten bringt .Net aus sein eigenes Licensing System mit, aber das ist relativ schwierig zu verstehen und umständlich umzusetzen. Da sind die Verschlüsselungsansätze meiner Meinung nach besser.

Dann muss man aber auch nochmal SafeNet mit dem HASP SRM in die Runde werfen. Das ist auch sehr gut und simpel in .NET integrierbar. Dort gibts sowohl den Software und Hardware-basierten Schutz.

[Iwo Asnet]

Ich wundere mich doch sehr darüber, das es auch hier doch Beiträge gibt (zumal von vornehmlich gestandenen Herren), deren Autoren eher an nervende Rechtschreibfehleraufmerksamkeitmacher erinnern, selbst aber einen eher laxen Umgang mit der deutschen Sprache pflegen.

Zitat von Phoenix:

Das heisst ganz einfach nur .Net, und fertig is.

Nein, es heißt wirklich "dot net", denn der Punkt wird in den mir bekannten Sprachen nicht gesprochen, weswegen "dot.net" auch nicht "dot dot net" ausgesprochen wird. Oder beendet man neuerdings jeden Satz mit dem Wort Punkt Fragezeichen

".NET" ist ein Logo (oder Warenzeichen). Glücklicherweise besteht dies aus Zeichen, die auf westlichen Tastaturen vorhanden sind, weshalb man dieses Logo auch eintippen kann. Araber tun sich hier z.B. schwer.

Ich bitte euch, lasst mir die Freiheit, einen Produktnamen so zu schreiben, wie man ihn spricht und nicht, wie man ihn zeichnet. Der Punkt zwischen dem 'dot' und dem 'Net' ist übrigens eine Ode an das Logo. Als Gegenleistung biete ich jedem, der sich daran stört, an, sich eins meiner vielen dot.NETs zu nehmen (ich hab genug) um es z.b. als Kratzbaum oder zum Schnabelwetzen zu verwenden.

Um zum Thema zu kommen:
Ein Dongle (=Hardware-Schutz) scheint also ausreichend zu sein. Ich gehe davon aus, das die Routine möglichst oft aufgerufen werden und der Code am durch einen Obfuscator geschützt werden sollte.

Vielen Dank

[cookie22]

Es heißt nicht dot.net sondern .Net, da liegst du einfach falsch und das hat nichts mit Freiheit zu tun. Denn man schreibt ihn auch so.

http://www.microsoft.com/net

[Phoenix]

Zitat von Iwo Asnet:

Um zum Thema zu kommen:
Ein Dongle (=Hardware-Schutz) scheint also ausreichend zu sein. Ich gehe davon aus, das die Routine möglichst oft aufgerufen werden und der Code am durch einen Obfuscator geschützt werden sollte.

Nur, wenn man ihn richtig einbaut. Es hilft nix, wenn nur einmal am Anfang geprüft wird ob der Dongle da ist. Das kann man leicht rauspatchen. Die gängigen Schutzsysteme nehmen Code aus dem Assembly, verschlüsseln ihn so, dass er nur mittels der Hardware auf dem Dongle entschlüsselt werden kann (in aller Regel Public/Private Key Verfahren, also hinreichend sicher), und somit muss immer, wenn auf bestimmte Funktionen zugegriffen wird der Dongle erstmal den Teil des Codes entschlüsseln. Lediglich Obfuskierter, aber nicht verschlüsselter Code ist mit Assembler zu vergleichen. Das macht auch keinen Spass sich da durch zu wühlen, aber es ist durchaus machbar. Die Hardware-Verschlüsselung ist dann die Komponente, die es deutlich sicherer macht. Steht und fällt natürlich damit, dass der Anbieter dessen Lösung Du wählst so arbeitet, dass der Dongel nicht gehackt werden kann, denn sonst emuliert jemand den und dann hat sich das auch.

Das ganze geht natürlich ein klein wenig auf die Performance, aber letztlich ist man nur hierdurch wirklich geschützt, denn der Aufwand an den entschlüsselten (obfuskierten) Code zu kommen ist schon so hoch, dass man sich dann nicht noch mit dem reverse Engineering des codes auseinander setzen will.

[RudiKuegler]

Wenn Du gar nichts machst, dann hast Du auch gar keinen Schutz. Es gibt Tools wie den Reflektor (oder auch neue freie Tools), die Dir aus dem Assembly wieder C# und VB.NET (ggf. auch Pascal Code) erzeugen. Es fehlen nur Deine originalen Kommentare . Dann suche ich nach der Fehlerausgabe "License not found", finde die Stelle und kann mit Plugins (z.B. Reflexil) diese Stelle ändern. Lustig ist aus einem brtrue.s ein brfalse.s zu machen. Dann geht die Software nur, wenn die Lizenz nicht da ist. Ansonsten finde ich Deine "CheckLicense" Funktion und ändere die um in "return true;". Dies macht sogar mein Azubi nach den ersten Tagen C# in der Schule.

Eine Option ist zu Obfuskieren. Da wird der Code verwurschtelt, Namen umbenannt ("CheckLicense" heißt dann "aa", oder besser noch ungültige Zeichen), und ggf. Strings verschlüsselt. Je nach Einstellungen und verwendeten Obfusktor (SmartAssembly von RedGate ist da ganz gut, wobei man RedGate wegen der Politik um den Reflektor eigentlich boykottieren müsste), muss der Azubi mich dann dazurufen, um den Code zu verstehen. Ich habe aber immer noch IL Code. Wenn die Strings verschlüsselt sind, finde ich Deine Abfrage auch nicht mehr über die Suche nach "License not found". Aber ich suche, wo Deine Anwendung MessageBox.Show aufruft. Und hangle mich von da auch zurück. WICHTIG: Nie Kopierschutzfehlermeldung mit der StandardMessageBox ausgeben. Manche empfehlen das ganze in einem Statusflag zu merken und später auszugeben. Tools wie IDA Pro finde, aber alle Stellen, in dem diese Variable geschrieben wird. Aber auch dies macht es nur etwas komplexer.

Eine bessere Option ist Verschlüsseln. Bei Wibu (für die arbeite ich, das Produkt heißt CodeMeter) wird Dein IL Code verschlüsselt und an die Anwendung angehängt. Dort wo Deine originalen Methoden waren liegt dann Code von uns. Dieser Code entschlüsselt dynamsich zur Laufzeit Deine Methoden und ruft diese dann auf. D.h. jemand der sich mit dem Reflektor oder IDA Pro Deinen Code anschauen will, sieht nichts mehr, da dieser verschlüsselt ist. Er kann maximal unseren Entschlüsselungscode sehen. Damit das ganze funktioniert benötigist Du eine Runtime von Wibu (CodeMeter.exe), welche als Dienst installiert wird. In Deiner Anwendung ist der der Aufruf für die Entschlüsselung drin, die wirkliche Entschlüsselung passiert dann in der Runtime (im Falle einer Softwarelizenz) oder im Dongle (im Falle von Kopierschutzhardware). Ein potentieller Angreifer der die Lizenz (Dongle oder Lizenzdatei) nicht hat, kann die Anwendung nicht mehr analysieren. Ein Angreifer, der die Lizenz besitzt müsste entweder versuchen alle Methoden zu entschlüsseln oder alle Methoden nach dem Entschlüsseln aus dem Speicher zu dumpen. Im ersten Fall hat Wibu Fallen eingebaut (nicht verwendete Methoden), die bei der Entschlüsslung ein Sperren der Lizenz auslösen. D.h. alle bis dahin nicht entschlüsselten Methoden sind dann auch für den Angreifer nicht mehr erreichbar. Im zweiten Fall müsstes Du dafür sorgen, dass alle Methoden zum Dumpen im Speicher liegen (also einmal aufgerufen wurde). Wenn Du ein Tool schreibst, was genau dies kann, dann kannst Du Dich damit "Dumm und Dämlich verdienen", wenn Du dies an Testabteilungen verkaufst.

Dies war natürlich nur die Spitze des Eisbergs. Du kannst Verschlüsselung mit eigenen Abfragen kombinieren. Teilweise auch Verschlüsselung und Obfuskierung, je nach "Schweinereilevel" ist dies aber ggf. inkompatibel. Du kannst die eigenen Abfragen verschleiern (Aufruf von CheckLicense über Reflektion, wobei Du den Namen CheckLicense verschlüsselt im Source ablegst). Im Entwickler Magazin 1.2011 habe ich dazu einen Artikel geschrieben ("Kein Platz für Cracker"). Als kommerzielle Produkte würde ich mir CodeMeter (von Wibu, natürlich mein Favorit) und HASP (von Aladdin/Safenet) anschauen. In beiden Fällen kannst Du zwischen Dongle und Softwarelizenz wählen, bzw. beides kombinieren.

Die Performance ist natürlich etwas, was Du testen musst. Die Entschlüsslung passiert zur Laufzeit und kostet damit natürlich Zeit. Da gibt es aber viele Stelleschrauben (Caching, Ausnahmen, ...), um dies zu optimieren.

[generic]

HK schwört auf diese Produkte:
http://www.oreans.com/products.php

Ich meine auch, dass die Idee dahinter gut ist.
Kurz:
Nimm den Cracker sein Fachwissen, durch austauschen der CPU Architektur.

[Iwo Asnet]

Zunächst möchte ich mich dafür bedanken, das das eigentliche Thema wieder im Mittelpunkt steht.
Ein spezieller Dank geht die Autoren der Beiträge, die sachlich sehr fundiert auf das Thema eingehen und meinen Horizont doch sehr erweitert haben.

Ich hatte schon vermutet, das eine Hardwarelösung das einzig wirklich sichere ist.

Zitat von RudiKuegler:

...Damit das ganze funktioniert benötigist Du eine Runtime von Wibu (CodeMeter.exe), welche als Dienst installiert wird. In Deiner Anwendung ist der der Aufruf für die Entschlüsselung drin, die wirkliche Entschlüsselung passiert dann in der Runtime (im Falle einer Softwarelizenz)...

Aber die Runtime kann ich doch knacken, oder nicht? Also, ich meine, "disassemblieren". So eine EXE ist doch auch nur eine Datei, die ich analysieren kann.. Oder ist das schon 'hinreichend' schwierig?

Die empfohlenen Lösungen schaue ich mir in Ruhe an. So wie es scheint, werden wir mit einem Anbieter arbeiten, der unsere Fragen und Sorgen ernst nimmt und uns auch hardwaretechnisch beraten kann. Der Schutz soll auch physikalisch in der Hardware verankert sein und nicht nur ein Dongle, der irgendwo dran hängt.