Hi @ all,
ganz kurz zu meiner Person: ich bin zwar hauptsächlich Programmierer, jedoch auch sehr am Reversen interessiert. Ich hab mir in der letzten Zeit einige Gedanken bzgl. Cracking gemacht.
"Jedes Programm kann gecrackt werden."
Klar, aber die Frage ist, wie viel Aufwand dafür notwendig ist. Wenn es (im Extremfall) länger dauert einen Crack zu finden als die Software selbst überhaupt interessant ist (z.B. aufgrund technischer Veralterung), dann kann man wohl de facto von einem in der Praxis uncrackbaren Programm sprechen.
Der Ansatz ist daher also, das Cracken extrem zeitaufwändig zu gestalten. Das widerum könnte erreicht werden, indem ein Programm mit Hilfe von Automatismen erstellt wird, die beim Cracken jedoch nicht wieder automatisch aufgelöst werden können. So quasi nach dem Motto, dass ein Programm an z.B. 10.000 Stellen im Code manuell gepatcht werden müsste.
Das kann natürlich nur dann erreicht werden, wenn es keinen zentralen Punkt gibt, an dem das Programm angegriffen werden kann. Eine Methode um das zu erreichen könnte in etwa wie folgt aussehen:
1) An der Stelle im Programm, wo ein eingegebener Schlüssel auf Gültigkeit überprüft wird, werden mit Hilfe eines mathematischen Verfahrens ein ganzer Haufen (z.B. 1.000) unterschiedliche int-Werte aus dem Schlüssel berechnet.
2) Diese int-Werte (im Folgenden crVal[] genannt) haben die Eigenschaft, dass sie in einem bestimmten Muster "abgefragt" werden können und aus dem Ergebnis rückschließen lassen, ob ein Schlüssel gültig ist. Es ist dem Software-Autor also bekannt, dass z.B. die Bedingung
crVal[312] * crVal[92] > crVal[719] - crVal[238] + 17
erfüllt sein muss, wenn das Programm registriert sein soll. Diese Abfrage wird dann z.B. verwendet, um dem Benutzer bei der Eingabe eine "Schlüssel richtig" oder "Schlüssel falsch" Meldung auszugeben.
3) In den Teilen bzw. Funktionen des Programms, die einen gültigen Schlüssel erfordern, wird das korrekte Funktionieren des Codes von den crVal[]-Werten abhängig gemacht. Sprich dass diese Werte in Bedingungen, Schleifen, Variablenzuweisungen etc. der Ablauflogik eingebaut werden.
4) Hier kommt der angesprochene Automatismus ins Spiel: der Quellcode kann vor dem Kompilieren z.B. mit einem eigenen Präprozessor verarbeitet werden, der automatisch in die gewünschten Funktionen beliebig viele (natürlich unterschiedliche) Abhängigkeiten auf die Werte im crVal[] einbaut.
Da dem Cracker rein aufgrund dem Vorliegen einer exe nicht bekannt ist, welche Zahlen im crVal[] Array für einen korrekten Programmablauf stehen müssen, kann die exe alleine nur extrem aufwändig gecrackt werden - nämlich indem an allen Stellen der Ablauflogik die benötigten Werte des crVal[] Arrays durch Reverse Engineering manuell heraus gefunden werden. Ein aussichtsloses Unterfangen.
Die Sache schaut natürlich anders aus, wenn dem Cracker bereits ein gültiger Key bekannt ist. Auch dafür gibt es jedoch, wie ich glaube, ähnlich effiziente Gegenmaßnahmen. Bevor ich darauf eingehen möchte, bin ich aber erst mal sehr gespannt auf alle Antworten - ich freue mich auf eine interessante Diskussion!
--ar08
ganz kurz zu meiner Person: ich bin zwar hauptsächlich Programmierer, jedoch auch sehr am Reversen interessiert. Ich hab mir in der letzten Zeit einige Gedanken bzgl. Cracking gemacht.
"Jedes Programm kann gecrackt werden."
Klar, aber die Frage ist, wie viel Aufwand dafür notwendig ist. Wenn es (im Extremfall) länger dauert einen Crack zu finden als die Software selbst überhaupt interessant ist (z.B. aufgrund technischer Veralterung), dann kann man wohl de facto von einem in der Praxis uncrackbaren Programm sprechen.
Der Ansatz ist daher also, das Cracken extrem zeitaufwändig zu gestalten. Das widerum könnte erreicht werden, indem ein Programm mit Hilfe von Automatismen erstellt wird, die beim Cracken jedoch nicht wieder automatisch aufgelöst werden können. So quasi nach dem Motto, dass ein Programm an z.B. 10.000 Stellen im Code manuell gepatcht werden müsste.
Das kann natürlich nur dann erreicht werden, wenn es keinen zentralen Punkt gibt, an dem das Programm angegriffen werden kann. Eine Methode um das zu erreichen könnte in etwa wie folgt aussehen:
1) An der Stelle im Programm, wo ein eingegebener Schlüssel auf Gültigkeit überprüft wird, werden mit Hilfe eines mathematischen Verfahrens ein ganzer Haufen (z.B. 1.000) unterschiedliche int-Werte aus dem Schlüssel berechnet.
2) Diese int-Werte (im Folgenden crVal[] genannt) haben die Eigenschaft, dass sie in einem bestimmten Muster "abgefragt" werden können und aus dem Ergebnis rückschließen lassen, ob ein Schlüssel gültig ist. Es ist dem Software-Autor also bekannt, dass z.B. die Bedingung
crVal[312] * crVal[92] > crVal[719] - crVal[238] + 17
erfüllt sein muss, wenn das Programm registriert sein soll. Diese Abfrage wird dann z.B. verwendet, um dem Benutzer bei der Eingabe eine "Schlüssel richtig" oder "Schlüssel falsch" Meldung auszugeben.
3) In den Teilen bzw. Funktionen des Programms, die einen gültigen Schlüssel erfordern, wird das korrekte Funktionieren des Codes von den crVal[]-Werten abhängig gemacht. Sprich dass diese Werte in Bedingungen, Schleifen, Variablenzuweisungen etc. der Ablauflogik eingebaut werden.
4) Hier kommt der angesprochene Automatismus ins Spiel: der Quellcode kann vor dem Kompilieren z.B. mit einem eigenen Präprozessor verarbeitet werden, der automatisch in die gewünschten Funktionen beliebig viele (natürlich unterschiedliche) Abhängigkeiten auf die Werte im crVal[] einbaut.
Da dem Cracker rein aufgrund dem Vorliegen einer exe nicht bekannt ist, welche Zahlen im crVal[] Array für einen korrekten Programmablauf stehen müssen, kann die exe alleine nur extrem aufwändig gecrackt werden - nämlich indem an allen Stellen der Ablauflogik die benötigten Werte des crVal[] Arrays durch Reverse Engineering manuell heraus gefunden werden. Ein aussichtsloses Unterfangen.
Die Sache schaut natürlich anders aus, wenn dem Cracker bereits ein gültiger Key bekannt ist. Auch dafür gibt es jedoch, wie ich glaube, ähnlich effiziente Gegenmaßnahmen. Bevor ich darauf eingehen möchte, bin ich aber erst mal sehr gespannt auf alle Antworten - ich freue mich auf eine interessante Diskussion!
--ar08