PureBoard

Hallo,

Ich mache mir seit einiger Zeit Gedanken, wie ich Software gegen Serial-Cracker schützen kann. Im Moment dauert es maximal ein paar Wochen bis eine Software geknackt ist. Darum habe ich mir was überlegt - weiss aber nicht ob ich auf dem Holzweg bin. Also, mal kurz lesen und schreiben was Ihr davon haltet (ich glaube das nennt man Virtualisierung):

1.
Ich gedenke, einen eigenen Interpreter zu bauen (oder einen bestehenden zu verwenden). Dieser soll Scripte mit einfachen Basic-Befehlen direkt ausführen können (nur das nötigste).

2.
Diese Scripte sollen aber vor der Ausführung in Bytecode umgewandelt werden (also ein For = 00, To = 01, Next = 02, If = 03, EndIf = 04, etc...).

3.
Ein solches Script soll die Prüfung einer Serial-No übernehmen können.

4.
Dann soll zum einen der Interpreter und zum anderen der Bytecode des Scriptes in die zu schützende Anwendung eincompiliert werden (Interpreter als PB-Include und der Bytecode zB als HEX-String).

5.
In der Anwendung soll beim Programmstart der Interpreter mit dem Script aufgerufen werden. Dieses Script prüft dann die übergebene Serial-No und setzt dann Ergebnisse in verschiedene Rückgabewerte in übergebene Speicherbereiche.

Problem:
Irgendwo muss ich ein True/False an die Anwendung zurückgeben, oder? Dieses muss ich dann prüfen (If, Select, etc.). Und dort wird man mich wieder packen.

Was, wenn das Script einige Faktoren zurückgibt die im Laufe des Programmes verwendet werden? Also fixe Zahlenwerte für einen Algorithmus der für das Programm notwendig ist? Dann muss der Hacker mindestens eine funktionierende Lizenz haben um überhaupt die richtigen Werte herauszufinden, oder?

Wie denkt Ihr darüber?

Volker

Klingt interessant. Ich würde dem Interpreter sowie dem Bytecode-Generator noch eine Zufallsanordnung der Nummern im Bytecode zuordnen. Sprich die beiden Programme nutzen eine Datenbank, welche die Nummer der einzelnen Befehle und die Befehle enthält. Vorm kompilieren werden diese zufällig generiert - der Bytecode erfolgt mit dieser neu generierten Numerierung und der Interpreter wird auch mit den hartkodierten Numerierungen generiert.

Wenn du den Interpreter als direkt als Quelltext kompilierst, dann kannst du ganz bequem aus der Datenbank der Interpreter generieren, ansonsten musst du wohl (und das wäre aufwändiger) die kompilierte Datei oder Dll per Programm hardcodiern und die Einträge ändern.

Die Idee klingt in der Tat sehr gut.

Was, wenn das Script einige Faktoren zurückgibt die im Laufe des Programmes verwendet werden? Also fixe Zahlenwerte für einen Algorithmus der für das Programm notwendig ist? Dann muss der Hacker mindestens eine funktionierende Lizenz haben um überhaupt die richtigen Werte herauszufinden, oder?

Das halte ich für nötig, ansonsten nützt der Interpreter wenig.

Volker Schmid hat geschrieben: Was, wenn das Script einige Faktoren zurückgibt die im Laufe des Programmes verwendet werden? Also fixe Zahlenwerte für einen Algorithmus der für das Programm notwendig ist? Dann muss der Hacker mindestens eine funktionierende Lizenz haben um überhaupt die richtigen Werte herauszufinden, oder?

Wie denkt Ihr darüber?

Volker

Was macht das für einen Unterschied gegenüber 'True' or 'False'?

Musst Du den nicht auch hier letzendlich auf 'True' oder 'False' überprüfen?

So nach den Motto:
If faktor1 +faktor2 + faktorN = <irgendwas> then <ok>

Ehrlich gesagt versteh ich nicht so ganz, wo hier die große Sicherheit liegen soll... Dein Programm muß ja dann die "überschriebenen Speicherbereiche" später wieder abprüfen um zu wissen, ob es sich als Vollversion verhalten soll... und diese Stelle zu finden ist nicht grad schwer.

Hi,

@Dr. Shrek

Was macht das für einen Unterschied gegenüber 'True' or 'False'?

Einen sehr grossen.

Angenommen ich habe einen Algorithmus zur Bildverarbeitung (nur ein Beispiel). Da gibt es immer eine Menge 'magic numbers' wie zB ein Schwellenwert oder ein Multiplikationsfaktor. Man könnte im Programm die Ergebnisse aus dem Interpreter verwenden. Und diese Ergebnisse stammen evtl. zum Teil aus dem Registrierungscode oder sind darin verschlüsselt oder werden damit freigeschaltet. Wenn der Hacker nie eine richtige Lizenz hatte, dann kann er den passenden Rückgabewert einfach nicht wissen. Und das Programm macht nur Schrott

Problem dabei: Eine Demoversion ist schwer zu erstellen, da diese ja 100% gute Ergebnisse liefern soll. Und das auch ohne Key.

Weiterer Vorteil von diesem Interpreter: Er könnte den Nerv-Dialog anzeigen und damit dem Hacker die Kontrolle darüber deutlich erschweren. Denn er müsste zuerst den Interpreter re-engineeren...

Ich habe auch schon überlegt, ob der Registrierungsschlüssel selbst nicht der Lizenz-Key sein könnte. Sozusagen der Bytecode als Key in einer Lizenzdatei?

Volker

Achso Du willst also mehrere Stellen überschreiben... naja ok das klingt schonmal besser. Die Idee aber den Bytecode als Lizenzschlüssel zu verteilen, wäre - mal sehr platt formuliert - total dämlich, denn dann gibt's ja nur einen einzigen korrekten Schlüssel und den kann ich dann an beliebig viele Freunde verteilen