Tweet
Ich habe eine Sicherheits-DLL geschrieben, in der ich die Registrierung von meiner Software überprüfe (Registry/Verschlüsselt). Aber was nütz mir die tollste Verschlüsselung, wenn die Funktion (Bsp: function CheckLIZ: Boolean) einen lesbaren Wert zurückgibt?? Da kann ja jeder einfach die DLL austauschen und eine Funktion schreiben, die immer TRUE zurückgibt! Ich müsste ja auch die Kommunikation zur DLL verschlüsseln. Hat jemand Erfahrungen damit bzw. einen Lösungsansatz? Hab mir überlegt, das ich einen verschlüsselten Datenblock zurückgebe, der vom Anwendungsprogramm entschlüsselt und interpretiert wird. Was sagt Ihr dazu?
-
-
ich würde folgende Funkton definieren:
function CheckLIZ(Key: PChar): Boolean;
Du übergibst der DLL einen verschlüsselten String (z.B. mit dem gleichen Algorithmus verschlüsselt wie dein Registry-Eintrag) und diese Prüft den übergebenen schlüssel + den Registry-Schlüssel und übergibt im Erfolgsfall sowohl ein True zurück als auch im Key-Parameter einen anderen verschlüsselten Wert zurück, durch den die Exe überprüfen kann ob die DLL ok. ist -
Ist trotzdem ziemlich einfach zu knacken. Der Cracker wird den Aufruf der DLL und "CheckLIZ" Funktion in der EXE Suchen, und dort anfangen zu patchen. Er patcht so das die DLL nicht mehr benötigt wird.<br>
Ich will dir nicht die Illusion rauben, aber so lange dein Schutz nur auf reiner Software basiert kann man ihn knacken. Meistens sogar einfacher als der Aufwand um den Schutz einzubauen.<br>
Lösung?? Mach es dem Cracker so schwer wie möglich, sprich Tarnen und Täuschen. Das bedeutet das genau deine Methode der falsche Weg wäre. Der Schutzcode muß in der EXE integriert sein, und möglichst unauffälig und an vielen Stellen im Code direkt implementiert werden. Die Überprüfung der Freischaltung sollte nicht immer erfolgen, sondern nur Wochentageweise. Keine daten in Registry reinschreiben oder auslesen, denn es gibt dehr gute Registry Monitore die dem Cracker sofort mitteilen was deinen Anwendung macht.
Egal ob du Dateien oder Registry benutzt, NIEMALS den Key/File direkt öffnen. Immer das kmplette Verzeichnis das die Datei/Key enthält scannen. JEDEN RegistryKey/Datei in diesem Verzeichnis öffnen und einlesen, ABER nur bei deinem Key/File wird die eigentliche Überprüfung gemacht. Das hat zur Folge wenn z.B. ein KeyFile von dir getarnt als DLL im Windows/System Ordner liegt, scannst du alle Dateien in diesem Ordner und öffnest sie. Das hört sich zwar enorm aufwendig an, ist aber für heutige Rechner ein Klacks von Aufgabe. Allerdings dem Cracker und seiner Monitorsoftware zur Überprüfung der File/Registry Aktivitäten quillt alles über. Denn statt nun EINE Datei/Regitrykey angezeigt zu bekommen, versteckt sich DEIN Key/File unter 1000'enden von anderen Log's.
So aber!, bekommt der Cracker einmal eine EXE mit gültiger Serial in die Finger so kann er einfach cracken. Er installiert die Software, gibt den Key ein und kann nun die EXE analysieren und patchen. Er erzeugt eine lauffähige Kopie deiner Anwendung. Deshalb ist es wichtig das die Überprüfung des Keys mit mehreren Methoden die unabhänig voneinander und zeitlich versetzt in der EXE stehen und auch so abgefragt werden. D.h. z.B. nur jeden 13 Tag wird Methode 1 benutzt. Nur jeden 7 Tag Methode 2. Der Cracker müsste nun erstmal alle diese Schutzfunktionen in der EXE finden, und hoffentlich übersieht er eine.<br>
Die meisten "Cracker" sind aber normale User die deren Freunde ihre Serial geben. Deshalb mußt du auch jede Softwarekopie an den entsprechnden Rechner koppeln. D.h. für jede Hardware muß die Serial speifisch sein um zu verhindern das die gleiche Serial auf mehreren Rechnern funktioniert. Jetzt haste aber das Problem was passieren soll wenn der User z.B. die HD austauscht, oder wenn mit einer Serial Mehrplatzsysteme geschützt werden sollen.<br>
Du siehst das System artet aus. Deshalb ist es das fairste für beide Seiten, wenn 1. der Entwickler Interesse hat das es User gibt die die Funktionalität benötigen und 2. der User Interesse hat ehrlich sein Geld in deine Software zu investieren da er die Funktionalität benötigt. Nun wird über den registrierten Support der User an dich gebunden und er bekommt was für sein Geld. D.h. die Software an sich sollte eine reine Dienstleistung werden.
Gruß HageComment
-
Hallo Hagen!!
Erstmal Danke für deine ausführlichen Lösungsansätze. Ich kann dir sagen, das ich schon sehr viel bereits davon implementiert habe. Habe ja auch deine DEC I verwendet - echt toll! Habe mich mit dieser Materie eh schon monatelang beschäftigt, da mein Projekt sehr gesichert werden muß (mil. Bereich). Die Freischaltung meines Projektes erfolgt mittels Telefonanruf - der PC des Users generiert eine Nummer bestehend aus pers. Benutzerdaten und Hardware-Eigenschaften sowie Datum und Zufallszahl. Dieser Code wird mir übermittelt und daraus rechnet sich der Aktivierungscode (ähnlich XP). Fuktioniert auch recht gut, solange wiegesagt ich die DLL nicht direkt angreife. Lege auch über all meine Anwendungen und DLLs und Module CRCs, um sie zu überprüfen.
So danke noch mal und ich werde deine restlichen Ideen in mein Projekt einfliessen lassen.
Ciao,
WerneComment
-
<i>Lege auch über all meine Anwendungen und DLLs und Module CRCs</I>
Auch das hilft nichts. Erstens nutzt du CRC's die sind echt leicht durch nachberechnete Werte zu ersetzen. D.h. der Cracker patcht EXE/DLL und errechnet die CRC's neu. Zweitens berechnest du die CRC's über die binäre Datei auf der HD und NICHT im Speicher. Somit patcht der Cracker zur Debugzeit diese CRC Überprüfung erstmal weg. Damit hat er erstmal leichteres Spiel und kann sich auf die anderen Schutzmechanismen konzentrieren. Hat er alle "geistig" geknackt so baut er nun succesive alle Schutzmechanismen raus und eine neue EXE/DLL. Um es genauer zu sagen: es gibt Programme die andere Programme zur Laufzeit patchen können. Diese Patchprogramme benötigen nur die Adresse an der gepatcht werden soll und den neuen Wert. Selbst das Window-OS enthält so ein System. D.h. in der Registry kann man dem OS mitteilen was an welcher Adresse gepatcht werden soll.
Gruß HageComment
Comment