Zugriff auf Speicher meines Programms verhindern

[Mikko]

Zitat:

Zitat von Luckie

Im Prinzip würde ich mir für ein Free- / Shareware Game nicht so eine Mühe machen und selbst für ein teures Spiel würde ich es wohl nicht machen. Sollen sie sich doch selber besch**ßen. :roll:

Auf dem gleichen Standpunkt stehe ich auch. Man entwickelt für ein Haufen Geld einen Kopierschutz, bei dem man denkt, daß es das Nonplusultra ist, und nach 14 Tagen hat es ein 10-Jähriger gecrackt. :lol:
Beispiel: Wenn ich mir Musik-CDs anschaue, die 'nen Kopierschutz haben, können nur noch eingeschränkt auf manchen Player abgespielt werden. Aber kopiert werden sie trotzdem. Wo liegt da also die Relation???? Das Gleiche gilt auch für Software.

[Tyrael Y.]

Zitat:

Tyrael Y. hat folgendes geschrieben:
und erhält die zu schützenden Speicherbereiche deines Programms....
..und überprüft bei jedem Speicherzugriff, ob es zu den zu schützenden Speicherbereichen gehört..

Wie stellst du dir das bitte vor?

Das waren nur allgemeine Überlegungen, alleine der Programmteil, um jeglichen Speicherzugriff zu registrieren ist nicht trivial und nicht in zwei Zeilen erzählt.

Zitat:

Tyrael Y. hat folgendes geschrieben:
... also ich kenne keine Methode dafür, aber prinzipiell könnte man ein zweites
Programm schreiben,...
..dieses Programm wird immer mit deinem Programm zusammen gestartet und erhält die zu schützenden
Speicherbereiche deines Programms....
..und überprüft bei jedem Speicherzugriff, ob es zu den zu schützenden Speicherbereichen gehört..

Dann crackt man halt das zweite Programm. Alles kein Problem.

..sag ich ja auch so ein Programm wäre in null komma nix ausgeschaltet..

[Luckie]

Äh, vorsicht. Dies sollte hier keine große Diskussion über Sinn und Unsinn seines Vorhabens werden.

[Mikko]

Wenn man unbedingt seine Variablen bei Spielen schützen will, sollte man mehrere Schutzmöglichkeiten einbauen und immer wieder abfragen (wie z.B. Isdebuggerpresent; haben sich Speicherbereiche, in denen meine Variablen stehen, geändert; eventuell Variablen packen/verschlüsseln usw.). Dabei sollte man aber keine Prozedur schreiben, die aufgerufen wird, sondern den Code immer wiederholen, sodaß viele Stellen gecrackt werden müssen. Man muß eine Kombination von verschiedenen Sachen coden. Aber die absolute Sicherheit gibt es nicht. Außerdem sollte man den Aufwand beachten. Lieber mehr Zeit in die Funktionalität des Spiels selbst stecken als in solche "Schutzmaßnahmen", die meist nur gegen Anfänger Schutz bieten.

Edit: Die Überprüfung sollte aber 100% bugfrei sein und man sollte das Spiel nur abbrechen, wenn man einwandfrei weiß, daß geschummelt wurde. Ansonsten wird man sich keine Freunde machen.

[Spezi1980]

Ich würde die Spielstäde einfach codiert (mittels einfacher xor Verschlüsselung) in 2 verschiedenen Variablen mit unterschiedlichem Schlüssel codiert speichern und dann kurz vor dem arbeiten mit dem Inhalt der Variablen diese decodieren und vergleichen.

Das ist zwar ein sehr einfacher Schutz, sollte aber vielleicht den Aufwand für einen der das cheaten will etwas heraufsetzen. Die Passwörter selbst sollten natürlich auch nur codiert gespichert werden.

[Mikko]

Zitat:

Zitat von Spezi1980

Ich würde die Spielstäde einfach codiert (mittels einfacher xor Verschlüsselung) in 2 verschiedenen Variablen mit unterschiedlichem Schlüssel codiert speichern und dann kurz vor dem arbeiten mit dem Inhalt der Variablen diese decodieren und vergleichen.

Das ist zwar ein sehr einfacher Schutz, sollte aber vielleicht den Aufwand für einen der das cheaten will etwas heraufsetzen. Die Passwörter selbst sollten natürlich auch nur codiert gespichert werden.

Sorry, aber den "Aufwand" kann man sich sparen. Ist wirklich nicht böse gemeint, aber wer einen Trainer proggen will, für den ist das absolut keine Hürde. Außer das man eine Zeile mehr hat.

[negaH]

Zitat:

Musste wohl auf TCPA warten, hrhr...

Mit TCPA kann man da auch nichts absichern. TCPA definiert nur einen Cryptochip Onboard. Die zu schützenden Daten müssen dann aber immer noch per ungeschützeter Spiele-Softare gelesen und geschrieben werden. Man kann also immer noch dieses Lesen + Schreiben hacken.

Eher trifft dann schon Microsofts Palladium ins Schwarze. Dort wird TCPA + Geschützer Speicher + ein zusätzlicher Nexus in der CPU dafür sorgen das man vollständig geschützte Programm hat. Ein Program das durch den Nexus im geschützten Bereich des Palladiums ausgeführt wird kann NICHT ohne entsprechnende Rechte abgeschert durch die TCPA Kryptographie debuggt werden. Da der benutzte Speicher in physikalischen Krypto-Speicher-Chips residiert sind sogar alle Informationen bei Lesen und Schreiben in diesen Speicherchip kryptographisch verschlüsselt. D.h. auch ein Hardware-Debugger hat keine Chance mehr. Nur derjenige der die korrekten Schlüssel besitzt kann solche Aktionen durchführen.

Auch ich würde die Spielstände in mehreren verschiedenen Variablen im Programm speichern, eventuell leicht verschlüsselt. Wichtig ist aber nur das die Aktualisierung der einzelnen Variablen in einem unterschiedlichen Intervall erfolgt. An verschiedenen Stellen im Program werden nun diese Variablen auf "Gleichheit" abgefragt. Ein Cracker wird mit Sicherheit erstmal nur eine dieser Variablen finden und die Schattenvariablen übersehen. Im Verlaufe einer Zeitspanne selektiert dein Program aber eine dieser Schattenvariablen als neue Hauptvariable. Wurde in der Zwischenzeit gepatcht so läuft nun das Programm mit dieser Schattenvariable weiter. Also, angenommen ein Lebenszähler. Wir benutzten an verschiedenen Stellen zB. 5 solcher Lebenszähler. Die Synchronisation erfolgt indem man eine Schattenvariable per Zufall auswählt, ein Leben davon abzieht und den Wert in den aktuellen Lebenszähler reinschreibt. Im Hintergrund werden über den Messagequeue nun die Schattenvariablen geupdatet. Wird nun der aktuelle Lebenszähler gepatcht so hat das eigentlich keine Auswirkungen wenn nicht auch alle Schattenvariablen gleichzeitigt gepatcht werden.

Eine Benutzung von IsDebuggerPresent() würde ich allehöchstens als Mittel zur Irritation benutzen. Der Cracker sucht als allererstes im Binary nach dem String "IsDebuggerPresent". Findet er diesen lösst er diese Konstantenadresse zum Code indem diese Funktion aufgerufen wird auf. Nun hat er mit hoher Sicherheit sofort einen Schutzcode deinerseits gefunden. D.h. solche primitiven Funktionen würde ich strikt vermeiden da sie nur die Arbeit des Crackers beschleunigen.

Gruß Hagen

[Mikko]

Zitat:

...An verschiedenen Stellen im Program werden nun diese Variablen auf "Gleichheit" abgefragt. Ein Cracker wird mit Sicherheit erstmal nur eine dieser Variablen finden und die Schattenvariablen übersehen. Im Verlaufe einer Zeitspanne selektiert dein Program aber eine dieser Schattenvariablen als neue Hauptvariable. ...

Aber: Wenn ich eine Variable habe, habe ich alle. Ich möchte hier niemanden eine Anleitung zum Cracken geben, aber wenn ich die erste Variable herausgefunden habe, bereitet es keine Mühe mehr, alle Zugriffe auf diese Variable zu überwachen. Somit sind z.B. tausend Vergleichsvariablen nur noch lästiges Beiwerk, was einem Cracker Zeit kostet. Mühe hat er aber keine mehr damit.

[negaH]

Dies stimmt so nicht. Es ist entscheidend das die Addresse der Speicherung der Variable unabhänig von deren Aktualisierung erfolgt. D.h. man aktualisiert und schreibt diese Variablen zeitgesteuert, zufällig über längere Zeiträume. Somit wird der tatsächliche Aufwand für den Cracker zeitlich enorm erhöht. Angenommen 10 solcher Variablen wobei pro Tag ab nur 3 dieser Variablen tatsächlich benutzt werden. Somit müsste der Cracker schon 3 Tage lang cracken und immer die korrekten zweitlichen Abläufe finden. Bei der Aktualisierung der Schattenvariablen ist es wichtig das diese Aktualisierung durch schwer debugbare Ereignisse gesteuert wird. Das wären zB. separate Theads, geschummelte Exceptionsbehandlungen oder eben per PostMessage() gesendete Nachrichten. Vorstellbar wäre auch ein DDE Nachtichtendienst innerhalb der gleichen Anwendung. Dadurch wird ein enorm großer Teil des Betriebssystemes in die Ereigniskontrolle durch den Cracker einbezogen. Am Ende wird der Cracker aus lauter Frust aufgeben. Dies IST das einzigst praktikable ZIEL des Programmieres. D.h. das Program erzeugt in seinem Programfluß eine enorme Menge an sinnlosen Stör-Code der immer nur in sehr kleinen Teile wirklich relevante Aktionen ausführt. Für uns Programmier ist sowas mit ziemlich wenig Aufwand zu erledigen, der Cracker hingegen sieht Millionen von Assemblerzeilen die er alle debuggen muß. Er wartet also ein enorm lange Zeit auf das entscheidende Ereigniss das ihm weiterhilft. Nur dies ist unser Vorteil, denn der Cracker ist ein ungeduldiger, schlampiger und unexakter Mensch !

Gruß Hagen

[Mikko]

Zitat:

Zitat von negaH

Dies stimmt so nicht. Es ist entscheidend das die Addresse der Speicherung der Variable unabhänig von deren Aktualisierung erfolgt. D.h. man aktualisiert und schreibt diese Variablen zeitgesteuert, zufällig über längere Zeiträume. Somit wird der tatsächliche Aufwand für den Cracker zeitlich enorm erhöht. Angenommen 10 solcher Variablen wobei pro Tag ab nur 3 dieser Variablen tatsächlich benutzt werden. Somit müsste der Cracker schon 3 Tage lang cracken und immer die korrekten zweitlichen Abläufe finden.

Muß er nicht. Wenn er eine Variable hat, sucht er alle Stellen im Speicher (die mit dem Programmablauf zu tun haben), die dem Inhalt der Variable entsprechen. Danach sucht er im Programmablauf, wo auf diese Stellen zugegriffen wird und überprüft, ob sie tatsächlich eine Variable sein könnten. Wieso also 3 Tage warten, was in einem Abwasch geht?

Zitat:

Zitat von negaH

Für uns Programmier ist sowas mit ziemlich wenig Aufwand zu erledigen, der Cracker hingegen sieht Millionen von Assemblerzeilen die er alle debuggen muß.

Muß er nicht, er kann die kommpletten Assemblerzeilen vor sich haben, ohne auch nur eine Zeile davon zu debuggen (auch mit Interpretation). Alles eine Frage des Debuggers.

Zitat:

Zitat von negaH

Nur dies ist unser Vorteil, denn der Cracker ist ein ungeduldiger, schlampiger und unexakter Mensch !

Ich würde dem nicht so ohne weiteres bepflichten und alle über einen Kamm scheren. Genau das ist nämlich der Vorteil des Crackers!

Aber um es auf den Punkt zu bringen: Was ich sagen will und was ich oben schon gesagt habe, nicht so viel Zeit und Elan in Sachen stecken, die eh nicht den 100%igen Erfolg haben, sondern eher in die Funktionalität des Spiels. Was nützt es, wenn keiner einen Trainer proggen kann, aber das Spiel keiner spielt, weil es Sch...ße ist.