Produktschlüsselüberprüfung

[Stormscud]

Hallöchen!
Ich mache mir gerade Gedanken darüber wie ein Programm überprüfen kann, ob der eingegebene Produktschlüssel korrekt ist. Irgendwie fällt mir da nix ein, was halbwegs sicher wäre.

Sicher könnte das Programm mit einem Server Kontakt aufnehmen und den Schlüssel abgleichen, aber die Methode fällt eigentlich flach bei mir.

Was mir noch eingefallen ist: eine bestimmte Folge von Werten in den Schlüssel einarbeiten, allerdings hätte man dann einen statischen Schlüsselteil, womit man leicht selbst einen erstellen könnte.

Habt ihr Ideen?

[Kampf-Sushi]

Hab sowas nie gemacht, aber mein erster Gedanke ginge in die Richtung Private/ Public Key bzw Digitale-Signaturen

[Stormscud]

Hmm also ne RSA Verschlüsselung z.B..
Das wäre ein ganz schöner Aufwand. Ich glaube der lohnt sich nicht so recht, das Programm worum es hier geht wird momentan eh nur innerhalb der Hochschule eingesetzt. Extern gab es bisher nur einen Kunden.

Mir geht es zwar nur um das Prinzip, Zeit um sowas einzubauen hab ich nicht mehr, muss die Diplomarbeit fertig kriegen, aber ich wollte ein paar Vorschläge machen diesbezüglich.

Ich meine für unseren Fall würde es reichen, dass das Programm ca. 50 oder auch 100 Schlüssel akzeptiert, welche in irgendeiner Art und Weise im Programm hinterlegt sind. Der Lizenznehmer bekmmt dann einfach einen Schlüssel, allerdings ist das alles andere als sicher.

Der Hintergrund ist folgender: Bisher war es so, dass der Schlüssel aus der individuellen Gerätenummer des Messgerätes erstellt wurde. So hat man gleich den Abgleich, es geht also immer nur ein bestimmter Schlüssel.
Allerdings hab ich schon für einige Messgeräte Treiber geschrieben, die einfach keine Gerätenummer ausspucken. Das ist halt nicht vorgesehen...
Damit ist das ganze System hinfällig.
Ich mach mir deswegen nun ein paar Gedanken, was man stattdessen machen könnte.

Die Schlüsselerstellung ist auch nicht das Problem, aber der Schlüsselabgleich.

[Neomi]

Ein halbwegs akzeptabler Schlüssel, der nicht auf Online-Aktivierung oder Gerätekennungen zurückgreifen darf, kann z.B. eine Kombination aus eigentlicher Schlüsselnummer und einer Checksumme sein. Die Schlüsselnummer kann beliebig transformiert sein. Die Checksumme sollte nicht nur über die Schlüsselnummer selbst, sondern zusätzlich über einen hartgecodeten Wert gehen, der nicht Teil des Schlüssels ist, quasi ein Salt-Wert. Dann können die Schlüsselkomponenten beliebig vermischt werden. Wenn z.B. die Schlüsselnummer abcd und die Checksumme ABCDEF vorliegen, kannst du daraus einen Schlüssel CaBdcEFbDA mixen, du mußt ihn nur wieder programmtechnisch richtig auseinandernehmen können. Auch eine richtige Verschlüsselung aus Schlüssel und Checksumme z.B. per AES ist denkbar.

Letztendlich wirst nur durch deine Phantasie begrenzt. Gegen Leute, die das System knacken wollen und wissen, was sie tun, hilft zwar kein System, gegen den Gelegenheitskopierer aber schon.

[Stormscud]

Ja das mit der Prüfsumme ist mir tatsächlich nicht in den Sinn gekommen. Das scheint mir doch eine relativ unkomplizierte Art und Weise des Datenabgleichs zu sein. Ich glaube so werd ich das mit aufnehmen, zumal ich über den AES auch was geschrieben habe. Passt ja gut zusammen.

Danke.

[Berni]

Gibt doch genug fertige (Kryto-)-Bibliotheken um die genannte PublicKey-Verschlüsselung zu machen. Braucht man ja nicht selbst erfinden. Sollte dann schnell einzubauen sein, sehe da kein Problem.
100%ige Sicherheit gibts natürlich nie. Man müsste ja auch die Binary schützen so dass z.B. niemand die Überprüfung einfach entfernt. Mehrmalige Verwendung eines Schlüssels erkennen geht eigtl. nur online.
Die GeräteID ist übrigens auch nicht so sicher wenn du hier von eigenen Treibern schreibst...der Treiber kann die ID ja wohl dann auch ändern.

[Stormscud]

Naja das Problem ansich ist wohl das hier noch VB6 verwendet wird :freak:
Und der Begriff Treiber ist in dem Zusammenhang auch so ne Sache. Es wird ja nur ein String ins Messgerät gesendet und die Antwort anschließend ausgewertet. Das ganze über das MSCOMM Steuerobjekt. Also kein Ding prinzipiell.
Erschüttert war ich, als ich mir Gedanken über einen USB Treiber für ein Messgerät gemacht habe. Da findet man ja so gut wie nix für VB6. Einfach extrem alt die Umgebung.
Aber zum Glück hatte der Hersteller einen virtuellen Com-Port Treiber mitgeliefert.

Problematisch sehe ich aber die Verwendung von fertigen Programmroutinen, immerhin handelt es sich hier um ein Projekt für die kommerzielle Nutzung. Oder kann man die Dinge einfach so mitverwenden? Ich denke nicht.
Außerdem ist das kein Programm, das großartig Interesse bei den Hackern da draußen erregen wird. Man muss es also nicht übertreiben mit dem Schutz ;)

[_Gast]

Naja das Problem ansich ist wohl das hier noch VB6 verwendet wird :freak:Das ist eher kein Problem.

Du kannst ja auch problemlos externe Programme ausführen, wie beispielsweise GnuPG (http://www.gnupg.org/index.de.html).

[Gnafoo]

Man kann sicher auch die CryptoAPI von Microsoft aus VB6 ansprechen:

http://msdn.microsoft.com/en-us/library/aa380255(VS.85).aspx

Siehe "API declaration in Visual Basic 6.0" hier:
http://support.microsoft.com/kb/821762/en-us

Damit dürfte so etwas doch vermutlich gehen.

[Stormscud]

interessant, hab ich mir mal als Lesezeichen gemerkt, danke.

[BAGZZlash]

Die beste Verschlüsselung mit Salt und allem (und am Besten nur eine Hash des eigentlichen Schlüssels speichern!) nützt nichts gegen Reverse Engineering, insbesondere Debugging.

Bei Ersterem kann man mit 'nem Disassembler einfach den bedingten Sprung bei der Auswertung des Schlüssels umdrehen. Bei Letzterem macht man sich zunutze, dass der Schlüssel während der Auswertung zwangsläufig irgendwo unverschlüsselt im Speicher liegt.

Gegen ersteres kann man sich einigermaßen schützen, indem man beim Programmdesign Fallen einbaut, z.B. viele (hunderte) Abfragen, die ins Leere laufen und Multi-Stage-Abfragen. Es gibt auch Tricks, die Standard-Disassembler wie z.B. W32DASM beim Disassemblieren abstürzen lassen. Auch Abfragen, die von (mehreren) externen Modulen (DLLs) geprüft werden, machen dem Cracker das Leben schwer.

Gegen Standard-Debugger wie SoftICE gibt es ähnliche Mittel, die die Programme erkennen (und dann etwa den Start des Programms mit einer Fehlermeldung verhindern) oder abstürzen lassen.

Letztlich muss klar sein: Gegen erfahrene Cracker hilft alles nichts. Sieht man ja schon daran, dass es kein einziges Computerspiel gibt, dessen Kopierschutz nicht geknackt wurde.

/Nachtrag: Wie mit VB6 die CryptAPI angesteuert wird, zeigt auch diese (http://www.activevb.de/tutorials/tut_cryptoapi/cryptoapi.html) schöne deutschsprachige Anleitung.

[Coda]

Es gibt auch noch Kernel-Mode-Debugger (Rasta Ring 0 z.B.). Dagegen hilft gar nichts ;)

[Berni]

Wenn im Programm nur der PublicKey vorhanden ist, ist es egal ob man ihn aus dem Speicher oder mittels Debugging auslesen kann. Das ist ja gerade der Sinn asymmetrischer Kraptografie. Insofern die asymmetrische Kryptomethode selbst nicht Müll ist (oder ein sehr kurzes Passwort bzw. Signatur verwendet wird) kommt ein Cracker hier also meiner Meinung nach um die Modifizierung des Programms nicht rum (also entweder Entfernung des Überprüfungscodes oder Einschleusen eines PublicKeys zu dem der PrivateKey bekannt ist). Wenn es kein Programm ist das hohe Beachtung findet wird das aber sicher niemand machen. Insofern ist das meiner Meinung nach die am Einfachsten zu implementierende Methode bei einem durchaus anspruchsvollen und für den Einsatzzweck angemessenen Sicherheitsniveau.

[BAGZZlash]

Asymmetrische Verschlüsselung ist hier

ungeeignet. Wie soll das denn gehen?
überflüssig, es werden ja schließlich überhaupt keine Informationen durch einen (potenziell zugänglichen) öffentlichen Raum transportiert.

Ich kenne auch kein Programm, das so einen Ansatz verfolgt.

Sei es, wie es sei: Am Ende liegen immer zwei Werte im Speicher, die miteinander verglichen werden. Sind sie gleich (oder verschieden), ist der Code korrekt, sonst eben nicht. Das ist ein prinzipbedingtes Problem der Programmierung.

[Berni]

Das geht ganz einfach:
Im Programm ist der PublicKey gespeichert sowie ein erwarteter String (Beispiel: "abcdefghjk").
Eine Lizenz ist der erwartete String + Randomteil + Checksumme ("Beispiel: "abcdefghjk 1i_9pö*A chksum") und wird mit dem PrivateKey vom Entwickler verschlüsselt.
Das Programm decrypted die erhaltene Lizenz mittels des PublicKey und überprüft die Checksumme. Stimmt diese und ist der Anfang gleich dem erwarteten String, so ist die Lizenz gültig. im "Randomteil" kann man auch den Namen/Adresse oder Ähnliches noch mitspeichern und das im Programm dann anzeigen.

Der erwartete String und auch der PublicKey dürfen hier dem User sogar bekannt sein. Das ist eben der Vorteil der asymmetrischen Krypto. Denn ohne PrivateKey kann er das Programm trotzdem nicht mit der korrekten Lizenz füttern. Nur durch tatsächliche Änderung am Binary (Tausch PublicKey oder eben komplette Umgehung des Codes) kann hier angegriffen werden

[Kampf-Sushi]

@BAGZZlash: Welche Ansätze benutzen denn die Programme die du kennst? :p
Es geht hier im Grunde eigentlich um eine Signatur, nicht um die Verschlüsselung ansich. Die ist nur Sinn zum Zweck.
Du glaubst doch auch nicht dass man eine Digitale Signatur einfach kopieren kann, weil "der Wert ja irgendwo stehen muss" oder?
Der CD-Key wird im Endeffekt signiert, und das Programm kann dann sicherstellen dass der Key vom Entwickler kommt. Die Daten die der Key enthält können dann sehr einfach sein, z.B. einfach eine eindeutige Nummer. Das ist dann auch gegen Disassemblieren usw sicher.

Ich glaub nur dass der Kram der bei "echter" Krypografie zusammenkommt viel zu lang für einen CD-Key ist, aber das kann man sicher kürzen. Sind ja keine Militärpläne, da ist das schon ok wenn der Key nach nem Jahr im Rechenzentrum geknackt werden kann.

PS: Gegen Cracken (modifizieren der ausführbaren Datei) ist natürlich nix sicher.... schon klar.
Nicht dass mir noch jemand damit kommt :p
Es geht hier um die Sicherheit des Keys, nicht der Keyüberprüfung ;)

[Stormscud]

Uiuiui das hört sich ja hier an als hätte ich vor ein Fort Knox für das Programm zu entwerfen ;D
Aber interessante Dinge die ihr hier aufführt, in Sachen Kopierschutzumgehung bin ich nämlich extrem grün hinter den Ohren.

Noch was zu dem Programm: Jeder der möchte kann es sich von der Internetseite der Hochschule runterladen und es als Demo nutzen (Messwertaufnahme + verarbeitung ist nicht möglich). Der einzige Schutz besteht in der Tat im Produktschlüssel. Im Übrigen bin ich auch der min. 4. oder 5. Student, der an dem Programm arbeitet. Ich kenne also auch nicht das ganze Konzept dahinter und kann mal eben so ein neues Sicherheitskonzept auflegen. Von den fehlenden Kenntnissen darüber ganz zu schweigen.

Es wird also davon ausgegangen, dass jemand, der sich das Programm kaufen will die Version aus dem Netz zieht und von uns einen Key zugeschickt bekommt.
Wenn wir nun nen Schlüssel erstellen plus Prüfsumme (wie weiter am Anfang erwähnt), dann ist das doch auch kein bißchen sicher, oder? Zwar kann ich mit der Prüfsumme feststellen, ob der Schlüssel echt ist, aber man könnte sich ja auch einfach nur einen Schlüssel erstellen und anschließend die richtige Prüfsumme dafür berechnen. Oder hab ich nen Denkfehler drin? Den Schlüssel selbst würde ich zwar verschlüsseln, z.B. per AES, aber auch das hilft doch an dieser Stelle nicht weiter oder?

Also bliebe doch nur eine digitale Signatur übrig, damit es nicht allzu umfangreich wird.

[Kampf-Sushi]

Wenn wir nun nen Schlüssel erstellen plus Prüfsumme (wie weiter am Anfang erwähnt), dann ist das doch auch kein bißchen sicher, oder? Zwar kann ich mit der Prüfsumme feststellen, ob der Schlüssel echt ist, aber man könnte sich ja auch einfach nur einen Schlüssel erstellen und anschließend die richtige Prüfsumme dafür berechnen. Oder hab ich nen Denkfehler drin? Den Schlüssel selbst würde ich zwar verschlüsseln, z.B. per AES, aber auch das hilft doch an dieser Stelle nicht weiter oder?

Also bliebe doch nur eine digitale Signatur übrig, damit es nicht allzu umfangreich wird.
Sicher im Kryptografischen Sinne nicht, weils keinen Private-Key gibt.

Aber ganz ehrlich, eh ich den Key-Algorithmus knacke, cracke ich doch lieber die Software, das kannst du eh nicht umgehen.
D.H. wenn Du mich fragst reicht ne billige Prüfsumme ohne Verschlüsselung.

Einfach einen festen Saltwert bestimmen (lässt sich zwar auslesen mit Disassembler, aber was solls?)
Produktkey mit gewünschter Länge, dazu die ersten (z.B. 4) Zeichen des Hashes und gut ist.
Kryptografisch sicher: nein
Angemessen: ja

Wenn Du das kryptografisch sicher haben möchtest müsstest du eh viel zu lange Produktschlüssel wählen. Wer hat schon bock 100 Zeichen und mehr abzutippen??

[Stormscud]

Da hast du recht, das kommt nicht in Frage.
Allerdings könnte man ja einen etwas längeren Schlüssel verwenden, den der Kunde nur noch kopieren muss, da der Schlüssel sowieso per Mail kommt glaube ich.

Prinzipiell nutzt man also nur die Unwissenheit der Nutzer aus, in diesem Fall zumindest, stellt ja eh keinen interessanten Wert für Cracker / Hacker dar.

Edit:
Angenommen ich würde einen längeren Schlüssel in Betracht ziehen, würde für AES ein 128 bit Block reichen? Oder ist die Qualität des Verfahrens erst mit mehreren Blöcken gut? 16 Byte wären ja nicht zu viel verlangt zum Eintippen, wobei kopiren ja viel einfacher ist, aber man muss ja auf alles gefasst sein :D
Wenn ja, würde ich einfach per Zufallsgenerator 14 Byte an Hexcode erzeugen lassen, die mit der LRC Prüfsumme versehen und anschließend per AES verschlüsseln lassen. Damit sollte doch die Einfachheit vom LRC ausgebügelt sein oder? Der Kunde würde dann die 16 Byte ins Programm eingeben, das entschlüsselt den String und prüft die LRC-Summe.

[_Gast]

Du könntest den Schlüssel auch personalisieren. Dann könntest du wenigstens nachvollziehen, von wem aus die Verbreitung stattgefunden hat.

[Kampf-Sushi]

Edit:
Angenommen ich würde einen längeren Schlüssel in Betracht ziehen, würde für AES ein 128 bit Block reichen? Oder ist die Qualität des Verfahrens erst mit mehreren Blöcken gut? 16 Byte wären ja nicht zu viel verlangt zum Eintippen, wobei kopiren ja viel einfacher ist, aber man muss ja auf alles gefasst sein :D
Wenn ja, würde ich einfach per Zufallsgenerator 14 Byte an Hexcode erzeugen lassen, die mit der LRC Prüfsumme versehen und anschließend per AES verschlüsseln lassen. Damit sollte doch die Einfachheit vom LRC ausgebügelt sein oder? Der Kunde würde dann die 16 Byte ins Programm eingeben, das entschlüsselt den String und prüft die LRC-Summe.

AES? Verschlüsseln? Wenn Verschlüsselung dann Asynchron ansonsten isses möchtegern.
Ich mach Dir grad mal ein Beispiel wie ich das machen würde.
Mir würde das reichen, sicher gegen einen decompiler ist das nicht, aber wie gesagt: dann kann man die exe auch einfach cracken.

Beispiel:
Du brauchst 3 Werte:
1. den Key mit 8 Zeichen laenge
2. den pseudo-private salt
3. die ersten 6 Zeichen des hashes

Berechnung:

produktschluessel = key + first6charsfrom(md5(key + salt))


Validierung:

hash = last6charsfrom(produktschluessel)
key = first8charsfrom(produktschluessel)
valid = first6charsfrom(md5(key + salt)) == hash


Ich hoffe das ist verständlich und ich habe keinen Fehler gemacht.
Der Hash-Algorithmus ist austauschbar. Genauso wie die Längen der 3 Komponenten.


//edit:
Rechenbeispiel

key = hans1337
salt = privat012345679

//hash berechnen
fullHash = c4f97fb838570ee16df4d93f25589b0c
hash = c4f97f

//key + hash
produktschluessel = hans1337c4f97f

//ab jetzt wieder zurueck
hash = c4f97f //die letzten 6 Zeichen von produktschluessel
key = hans1337 // die ersten 8 Zeichen von produktschluessel

fullHashvalidation = md5(hans1337 + privat012345679) //das ergebnis ist: c4f97fb838570ee16df4d93f25589b0c
hashValidation = first6charsfrom(c4f97fb838570ee16df4d93f25589b0c)

hashvalidation ist jetzt == c4f97f und kann mit hash verglichen werden


Der Produktschlüssel ist mit 14 Zeichen (hans1337c4f97f) noch akzeptabel.

[Stormscud]

Damit hätt ich dann aber ein Problem, ich hab nämlich über AES genauer geschrieben und hätte das gerne mit in einen Vorschlag eingebaut.
Nagut ich könnte ja meinen und deinen aufschreiben.

Die Hintergründe noch groß zu erklären bzgl Hashwert und so wird wohl etwas zu viel über das Thema, da ich ja nicht nur darüber schreibe.

Zum "möchtegern": So ähnlich würd ich mich in der Beziehung sehen. Ich kenne ja auch nur einen Ausschnitt (grob) vom Thema, sodass die Bezeichnung durchaus passen würde. Aber so machen könnte man es, oder?
Ich meine die Professoren sind alle keine Informatiker, ich mach schließlich Maschinenbau(informatik), wobei der Schwerpunkt absolut auf Maschinenbau liegt.
Deswegen gehts bei mir über "Hobbykenntnisse" nicht hinaus ;)

Aber verstanden hab ich es erstmal im Prinzip. Danke für das Beispiel.

[Kampf-Sushi]

Zum "möchtegern": So ähnlich würd ich mich in der Beziehung sehen. Ich kenne ja auch nur einen Ausschnitt (grob) vom Thema, sodass die Bezeichnung durchaus passen würde. Aber so machen könnte man es, oder?
Ich meine die Professoren sind alle keine Informatiker, ich mach schließlich Maschinenbau(informatik), wobei der Schwerpunkt absolut auf Maschinenbau liegt.
Deswegen gehts bei mir über "Hobbykenntnisse" nicht hinaus ;)

Aber verstanden hab ich es erstmal im Prinzip. Danke für das Beispiel.
AES macht deshalb keinen Sinn weil Du an der Stelle wo Du den Schlüssel zum Entschlüsseln von was auch immer speicherst, auch die Daten direkt unterbringen könntest. Eins von beiden steht so oder so im Quellcode... (auch wenn der vll in Maschinensprache formuliert ist). Zumindest vermute ich das. So ganz verstanden hab ich nicht was du damit machen möchtest.

[Stormscud]

Naja ich hab mir das so gedacht, dass ich AES nehme um zu verschleiern, wie der echte Schlüssel aufgebaut ist. Dafür brauch dann zwar noch nen Schlüssel, aber daran soll es nicht scheitern.
Das macht deine Variante ja auch.

[Kampf-Sushi]

Naja wenn Du unbedingt das Wort verschlüsseln in deiner Arbeit erwähnen willst, gibt es sicherlich Wege das irgendwie damit zu machen.

Aber wenn du den Schlüssel gleich mitlieferst kannst Du genausogut auch gleich eine einfache XOR Verschlüsselung machen. Das Sicherheitslevel dürfte ähnlich sein ;)
Darum geht mein erster Gedanke auch eher Richtung Hash, der tut nämlich garnicht erst so als ob er was verschlüsseln wollen würde. Kannst auch n CRC oder was einfacheres nehmen. Md5 hatte ich jetzt nur schnell ne Website gefunden wo man sich die ausrechnen lassen kann für das Beispiel.

AES kann man glaub ich auch als Hash missbrauchen (Whirlpool?) aber ich find das eher umständlich. Sozusagen mit Kanonen auf Spatzen schießen und doch daneben treffen ;p

Wenn du technisch wirklich glänzen willst such dir ne möglichst simple Signiermethode raus und gut ist :-) Kannst glaub ich sogar den von mir vorgeschlagenen Algorithmus übernehmen und den Hash einfach Asynchron verschlüsseln/ entschlüsseln.

[Gast]

du könntest teile des programms selber verschlüsseln. Das hat dann schonmal den vorteil, dass ein jemand, der sich die demo version von euch runterläd, das programm nicht zur vollversion machen kann, der potentielle cracker müsste also erstmal selber eine lizenz erwerben...

[Stormscud]

Also praktisch die Datei, in denen die ganzen Treiber sind verschlüsseln? Darin ist auch die Abfrage, ob ein Passwort eingegeben wurde.
Edit:
Und natürlich das Modul zur Passwortüberprüfung.

[pest]

du könntest teile des programms selber verschlüsseln. Das hat dann schonmal den vorteil, dass ein jemand, der sich die demo version von euch runterläd, das programm nicht zur vollversion machen kann, der potentielle cracker müsste also erstmal selber eine lizenz erwerben...

sowas habe ich selbst schon ge...hackt ;) ... ist zwar schwieriger aber auch kein prob

[Gast]

Naja wenn die Daten wirklich verschlüsselt sind und der Schlüssel nicht in irgendeiner Form im Programm vorhanden ist bezweifel ich dass man das knacken kann (bei einem ausreichend starken Schlüssel und einem als sicher geltenden Verschlüsselungsverfahren, beispielsweise AES)

[Neomi]

Klar ist das knackbar. Nicht die Verschlüsselung, aber der ausführbare Code. Ein noch so guter Schlüssel hilft nicht, wenn er nicht mehr nötig ist, weil ein falscher Schlüssel ohne Konsequenz (z.B. Beendigung des Programms) bleibt.

[Gast]

Also ich würde das ganze so machen:

Jeder Benutzer muss sich mit seinem Namen registrieren. Der Name wird dann in der Registry hinterlegt und wird auf der Programmoberfläche unten klein dargestellt (lizensiert für xyz). Eine Ausweiskontrolle wäre wahrscheinlich zu viel des guten, aber es sollten schon die echten Namen sein.

Dann bildest du einen Hashcode des Benutzers und generierst daraus einen Private und Public Key. Den Public Key hebst du dir auf, den Private Key lieferst du in Form des Product Keys aus.
Zusätzlich verschlüsselst du mit dem generierten Public Key (der für jeden Benutzer anders ist) die wichtigste Datei der Software, am Besten die, die auch die Benutzerinformationen enthält. Diese verschlüsselte Datei lieferst du mit dem Product Key elektronisch mit und nicht mit der Installations CD der Software (spart auch Arbeit, weil man nicht 1.000 verschiedene CDs brennen muss).

Die Software entschlüsselt mit dem Private Key (Product Key) die Datei zur Laufzeit und bindet sie ins System ein (wenn möglich nur im RAM halten und nicht auf die Platte legen).

Damit ist sichergestellt, dass:

1.) Der Benutzer seine Software nicht an zig andere Leute verteilt oder ins Netz stellt, weil ja sein Name drauf steht.
2.) Man kann die Installations CDs mit dem Großteil der Dateien frei vertreiben und hat auch bei Software Updates kein Problem, da der Benutzer damit alleine ja eh nichts anfangen kann.
3.) Da ein wichtiger Teil, ohne den die Software nicht läuft verschlüsselt ist, kann der User auch cracken, bis er schwarz wird, weil er an die Informationen ohne Product Key nicht heran kommt. Da hilft es bei .NET Programmen auch nicht, wenn er einfach die .exe und .dlls mit dem Reflector analysiert, da dort ja nicht alles vorhanden ist.

Der Benutzer könnte nur noch sich einen Product Key besorgen, die Software analysieren, eine veränderte Version bauen, die die Daten auf die Platte schreibt und eine weitere, die den verschlüsselten Teil der Software unverschlüsselt von der Platte liest und dann noch die Benutzerinformationen heraus nimmt. Das könnte man noch umgehen, indem man den relevanten Teil nicht in managed Code schreibt oder mit einem Obfuscator etwas nachbehandelt.

[pest]

Naja wenn die Daten wirklich verschlüsselt sind und der Schlüssel nicht in irgendeiner Form im Programm vorhanden ist bezweifel ich dass man das knacken kann (bei einem ausreichend starken Schlüssel und einem als sicher geltenden Verschlüsselungsverfahren, beispielsweise AES)

der Code wird immer, irgendwann ausgeführt, und dann sehe ich ihn ;)
selbst wenn man es dann nicht schafft die Exe zu patchen, weil Checksummenüberprüfung, patch man halt das Programm im Speicher

[Gast]

ok wenn du erstmal von irgendwem einen gültigen (gekauften) schlüssel hast kannst du das machen, aber es schützt zumindest davor, dass sich jemand die demo version läd und sich dann mal eben so an sein sice oder sein olly setzt um die abfrage herauszupatchen.