Selbstprüfende Binärdateien?

8

Meine Frage ist ziemlich einfach: Sie sind eine ausführbare Datei, die "Zugriff gewährt" oder "Zugriff verweigert" ausgibt und böse Personen versuchen, Ihren Algorithmus zu verstehen oder Ihre Innereien zu reparieren, damit Sie ständig "Zugriff gewährt" sagen .

Nach dieser Einführung fragen Sie sich vielleicht, was ich mache. Wird er Diablo3 knacken, sobald es draußen ist? Ich kann deine Sorgen beruhigen, ich bin keiner dieser Cracker. Mein Ziel sind Crackes.

Crackmes finden Sie zum Beispiel auf www.crackmes.de. Ein Crackme ist eine kleine ausführbare Datei, die (meistens) einen kleinen Algorithmus enthält, um eine serielle und eine Ausgabe "Zugriff gewährt" oder "Zugriff verweigert" abhängig von der Seriennummer zu verifizieren. Das Ziel ist es, diese ausführbare Ausgabe die ganze Zeit "Zugriff gewährt" zu machen. Die Methoden, die Sie verwenden dürfen, können vom Autor eingeschränkt werden - kein Patching, keine Disassemblierung - oder alles, was Sie mit einem Binär-, Objdump- und Hex-Editor tun können. Cracking Crackes ist ein Teil des Spaßes, aber als Programmierer frage ich mich, wie man Crackes erstellen kann, die schwierig sind.

Grundsätzlich denke ich, dass das Crackme aus zwei Hauptteilen besteht: einer gewissen seriellen Verifizierung und dem umgebenden Code.

Es ist sehr möglich, die serielle Verifizierung schwierig zu machen, indem nur Assembly verwendet wird. Ich habe zum Beispiel die Idee, die serielle Schnittstelle als Eingabe für einen simulierten Mikroprozessor zu verwenden, der in einem bestimmten Zustand enden muss, um die serielle Akzeptanz zu erhalten . Auf der anderen Seite könnte man billig werden und mehr über kryptographisch starke Möglichkeiten erfahren, diesen Teil zu sichern. Daher sollte es nicht so schwierig sein, dies so hart zu machen, dass der Angreifer versucht, die ausführbare Datei zu patchen t schwer.

Der schwierigere Teil ist jedoch die Sicherung der Binärdatei. Nehmen wir eine vollkommen sichere serielle Verifizierung an, die nicht irgendwie rückgängig gemacht werden kann (natürlich weiß ich, dass es umgekehrt werden kann, im Zweifelsfall reißt man Teile aus der Binärdatei, die man versucht zu knacken und zufällige Serien zu werfen, bis es akzeptiert). Wie können wir verhindern, dass ein Angreifer Sprünge in der Binärdatei einfach überschreibt, damit unsere Binärdatei alles akzeptiert?

Ich habe zu diesem Thema ein wenig gesucht, aber die meisten Ergebnisse in Bezug auf binäre Sicherheit, selbstüberprüfende Binärdateien und solche Dinge enden in Artikeln, die versuchen, Angriffe auf ein Betriebssystem mit kompromittierten Binärdateien zu verhindern. indem Sie bestimmte Binärdateien signieren und diese Signaturen mit dem Kernel validieren.

Meine Gedanken bestehen derzeit aus:

  • prüft, ob explizite Positionen in der Binärdatei Jumps sind.
  • checksumming Teile der binären und vergleichen Prüfsummen zur Laufzeit mit diesen berechnet.
  • haben positive und negative Laufzeitprüfungen für Ihre Funktionen im Code. Mit Nebenwirkungen bei der Serienverifizierung. :)

Können Sie sich mehr Möglichkeiten ausdenken, einen möglichen Angreifer länger zu nerven? (Natürlich kannst du ihn nicht für immer fernhalten, irgendwann werden alle Prüfungen abgebrochen, es sei denn, du hast es geschafft, einen Prüfsummengenerator zu zerbrechen, indem du die richtige Prüfsumme für ein Programm in das Programm einbetten kannst, hehe)

    
Tetha 19.09.2008, 06:09
quelle

6 Antworten

6

Sie kommen in "Anti-Umkehr-Techniken". Und es ist grundsätzlich eine Kunst. Schlimmer noch, selbst wenn Sie Neulinge stampfen, gibt es "anti-anti-reverse-Plugins" für olly und IDA Pro, die sie herunterladen und viele Ihrer Gegenmaßnahmen umgehen können.

Gegenmaßnahmen umfassen Debugger-Erkennung durch Trap-Debugger-APIs oder Erkennung von "Single-Stepping". Sie können Code einfügen, der nach dem Erkennen eines Debugger-Breakin weiterhin funktioniert, aber viel später im Programm zu zufälligen Zeiten startet. Es ist wirklich ein Katz und Maus Spiel und die Cracker haben eine signifikante Oberhand.

Auschecken ... Ссылка - Etwas von dem, was da draußen ist.

Ссылка - Dieses Buch hat wirklich gute Anti-Rückwärts-Informationen und schreitet durch die Techniken. Toller Ort, um zu starten, wenn Sie im Allgemeinen Umkehrung bekommen.

    
kervin 19.09.2008, 06:33
quelle
1

Ich glaube, dass diese Dinge im Allgemeinen mehr Probleme bereiten, als sie wert sind.

Sie haben viel Mühe darauf verwendet, Code zu schreiben, um Ihre Binärdatei zu schützen. Die bösen Jungs geben weniger Mühe, sie zu knacken (sie sind in der Regel erfahrener als du) und lassen dann den Riss los, damit jeder deinen Schutz umgehen kann. Die einzigen Leute, die Sie ärgern werden, sind jene ehrlichen, die durch Ihren Schutz belästigt werden.

Betrachten Sie Piraterie einfach als Geschäftsaufwand - die zusätzlichen Kosten von Raubkopien sind gleich null, wenn Sie sicherstellen, dass der gesamte Support nur für zahlende Kunden erfolgt.

    
paxdiablo 19.09.2008 06:21
quelle
1

Es gibt TPM-Technologie: tpm auf wikipedia

Es ermöglicht Ihnen, die Verschlüsselungs Prüfsummen eines binären auf speziellen Chip zu speichern, die als Einweg Überprüfung handeln könnte.

Hinweis : TPM Art einen schlechten Ruf hat, weil es für DRM verwendet werden könnte. Aber Experten auf dem Gebiet, das ist irgendwie unfair, und es gibt sogar eine Open TPM Gruppe, die es Linux-Benutzern ermöglicht, genau zu steuern, wie ihr TPM-Chip verwendet wird.

    
Purfideas 19.09.2008 06:26
quelle
1

Eine der stärksten Lösungen für dieses Problem ist Trusted Computing . Im Grunde würden Sie die Anwendung verschlüsseln und den Entschlüsselungsschlüssel an einen speziellen Chip (das Trusted Platform Module ) übertragen. Der Chip würde nur entschlüsseln Sie die Anwendung, nachdem Sie sich vergewissert haben, dass sich der Computer in einem "vertrauenswürdigen" Zustand befindet: keine Speicher-Viewer / Editoren, keine Debugger usw. Sie benötigen spezielle Hardware, um nur den entschlüsselten Programmcode anzeigen zu können.

    
Rasmus Faber 19.09.2008 06:36
quelle
0

Sie möchten also ein Programm schreiben, das am Anfang einen Schlüssel akzeptiert und im Speicher ablegt und anschließend von der Disc abruft. Wenn es der richtige Schlüssel ist, funktioniert die Software. Wenn es der falsche Schlüssel ist, stürzt die Software ab. Das Ziel ist, dass es für Piraten schwierig ist, einen funktionierenden Schlüssel zu erzeugen, und es ist schwierig, das Programm mit einem nicht lizenzierten Schlüssel zu versehen.

Dies kann tatsächlich ohne spezielle Hardware erreicht werden. Betrachten Sie unseren genetischen Code. Es basiert auf der Physik dieses Universums. Wir versuchen es zu hacken, Drogen zu schaffen, etc., und wir scheitern kläglich und schaffen normalerweise Unmengen von unerwünschten Nebenwirkungen, weil wir die komplexe "Welt", in der sich der genetische "Code" entwickelt hat, noch nicht vollständig umgesetzt haben . Wenn Sie alles auf einem gemeinsamen Prozessor (einer gemeinsamen "Welt") ausführen, auf den jeder Zugriff hat, ist es praktisch unmöglich, einen solchen sicheren Code zu schreiben, wie die aktuelle Software zeigt, die so leicht geknackt werden kann.

>

Um Sicherheit in Software zu erreichen, müssten Sie im Wesentlichen Ihre eigene ausreichend komplexe Plattform schreiben, die andere vollständig und gründlich zurückentwickeln müssten, um das Verhalten Ihres Codes ohne unvorhersehbare Nebenwirkungen zu modifizieren. Sobald Ihre Plattform jedoch rückentwickelt ist, sind Sie wieder auf Platz eins.

Der Haken dabei ist, dass Ihre Plattform wahrscheinlich auf gewöhnlicher Hardware läuft, was Ihre Plattform einfacher macht, Reverse Engineering durchzuführen, was wiederum Ihren Code ein bisschen einfacher macht, Reverse Engineering zu machen. Natürlich kann dies bedeuten, dass der Balken für die Komplexität, die von Ihrer Plattform benötigt wird, um ein ausreichend schwer zu rekonstruierendes System zu sein, etwas angehoben wird.

Wie würde eine ausreichend komplexe Softwareplattform aussehen? Zum Beispiel gibt die siebte Addition, möglicherweise nach jeweils 6 Additionsoperationen, das mit PI multiplizierte Ergebnis dividiert durch die Quadratwurzel des Logarithmus des Moduls 5 der Differenz der Gesamtzahl der seit der Systeminitialisierung durchgeführten Subtraktions- und Multiplikationsoperationen zurück. Die Plattform müsste diese Zahlen unabhängig voneinander verfolgen, ebenso wie der Code selbst, um korrekte Ergebnisse zu dekodieren. Ihr Code würde also basierend auf dem Wissen über das komplexe zugrundeliegende Verhalten einer von Ihnen entwickelten Plattform geschrieben werden. Ja, es würde Prozessorzyklen verschlingen, aber jemand würde dieses kleine Überraschungsverhalten zurückentwickeln und es in irgendeinen neuen Code umbauen müssen, damit es sich richtig verhält. Darüber hinaus wäre es schwierig, Ihren eigenen Code zu ändern, sobald er einmal geschrieben wurde, weil er in eine nicht reduzierbare Komplexität zerfallen würde, wobei jede Zeile von allem abhängt, was zuvor passiert ist. Natürlich wäre die Komplexität in einer ausreichend sicheren Plattform viel komplexer, aber der Punkt wäre, dass jemand Ihre Plattform rückentwickeln würde, bevor er Ihren Code rückentwickeln und ändern könnte, ohne die Nebenwirkungen zu lähmen.

    
Triynko 20.05.2009 02:23
quelle
0

Toller Artikel zum Kopierschutz und zum Schutz des Schutzes Die Piraten in Schach halten: Crack Protection für Spyro implementieren: Jahr des Drachen

Die interessanteste darin erwähnte Idee, die noch nicht erwähnt wurde, ist Kaskadierungsfehler - Sie haben Prüfsummen, die ein einzelnes Byte ändern, das eine andere Prüfsumme zum Fehlschlagen bringt. Irgendwann führt eine der Prüfsummen dazu, dass das System abstürzt oder etwas Seltsames tut. Dies führt dazu, dass Versuche, Ihr Programm zu missbrauchen, instabil erscheinen und die Ursache weit vom Absturz entfernt auftreten.

    
Tom Leys 20.05.2009 03:20
quelle

Tags und Links