Zugriff auf Speicher meines Programms verhindern

[Cybersurfer]

Hallo

Gibt es eine möglichkeit zu überwachen ob andere Programme auf den Speicher meines programms zugreifen?

Beispiel wäre in einem Game hat man einen Wert für sein Geld.
Nun will einer schummeln und benutzt einen Trainer um sein geld mal fix zu erhöhen was ich natürlich verhindern möchte!!

Wie kann ich das Prüfen und verhindern???

[Luckie]

Such mal nach delphi isdebuggerpresent.

[Mikko]

ISDEBUGGERPRESENT kann man überlisten und ist somit nutzlos.

[Luckie]

Man kann wohl so ziemlich alles überlisten. Aber wie sieht es denn mit einem besseren Vorschlag, deinerseits, aus? :roll: Außerdem habe ich nie behauptet es wäre das non plus ultra. Es ist eben nur eine von mehreren Möglichkeiten, wobei mir jetzt keine weiteren einfallen bzw. bekannt sind.

Wo wir gerade dabei sind. Wie überlistet man denn IsDebuggerpresent?

[Tyrael Y.]

... 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..

...aber...

..auch so ein Programm ist leicht zu überlisten und die Mühe die man da reinstecken müsste ich für die Katz...(nicht für sakura *g*)...auch wenn du das Programm verstecken würdest, hätte man es null in komma nix ausgeschaltet...


...war halt nur so ne Überlegung...

bis denne

[Luckie]

Zitat:

Zitat von Tyrael Y.

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? :gruebel:

[Mikko]

Zitat:

Zitat von Luckie

Man kann wohl so ziemlich alles überlisten.

Genau das ist das Problem.

Zitat:

Zitat von Luckie

Aber wie sieht es denn mit einem besseren Vorschlag, deinerseits, aus? :roll: Außerdem habe ich nie behauptet es wäre das non plus ultra. Es ist eben nur eine von mehreren Möglichkeiten, wobei mir jetzt keine weiteren einfallen bzw. bekannt sind.

Ich wollte ja nur sagen, daß es Gegenmaßnahmen gibt. Ein Debugger ist ein verdammt mächtiges Werkzeug. Dagegen ist (fast) kein Kraut gewachsen. Alles eine Frage der Hartnäckigkeit des Bedieners von Debuggern. Es gibt wohl keinen 100%igen Schutz. Es gibt zwar viele Möglichkeiten, sich zu schützen, aber es gibt auch verdammt viel Gegenmaßnahmen. Es kommt halt auf die Frage drauf an, wie stark ein Schutz sein muß/soll. Darauf muß man sich einrichten (was will ich schützen).

Zitat:

Zitat von Luckie

Wo wir gerade dabei sind. Wie überlistet man denn IsDebuggerpresent?

Es gibt Plug-Ins für Debugger, die "IsDebuggerpresent" ausschalten. Wie das funktioniert, weiß ich nicht, aber es funzt problemlos.

[Mikko]

Zitat:

Zitat von Tyrael Y.

... 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.

[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:

[Vjay]

Musste wohl auf TCPA warten, hrhr...

[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.

[negaH]

Zitat:

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?

Das funktioniert NUR wenn im Code des Programmieres direkt auf diese Schattenvariablen zugegriffen wird. Ich gehe aber bei solchen Spielereien immer davon aus das solche Variablen indirekt addressiert werden. D.h. in diesem Moment wird per Program in anderen Variablen die reale Adresse der Schattenvariable dynamisch berechnet. Nun funktioniert dein obiger Vorschlag nicht mehr so einfach. Eine einfache Methode wäre die Anwendung von OOP. Bei dynamischen Objecten werden deren Felder ja immer indirekt adressiert.

Zitat:

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.

Da stimme ich dir voll zu, der Aufwand sollte gerechtfertigt sein. Grundsätzlich bin ich aber der Meinung das der normale Programmierer bei komplexen und großen Anwendungen durch seine enorme Entwicklungsgeschwindigkeit den Vorteil auf seiner Seite hat. Mit wenigen Mausklicks erzeugen wir ganze Programme die der Cracker mit recht "primitiven" Werkzeugen in "unverständlichem" Assembler vor sich sieht. Im Grunde dürften es garnicht so viele Cracks geben, wenn die Cracker nicht so verdammt gut wären. Programme erstellen ist heute Fließband-Arbeit, Programme cracken dagegen manuelle Hand-Arbeit.

Gruß Hagen

[Mikko]

Zitat:

Zitat von negaH

Das funktioniert NUR wenn im Code des Programmieres direkt auf diese Schattenvariablen zugegriffen wird. Ich gehe aber bei solchen Spielereien immer davon aus das solche Variablen indirekt addressiert werden. D.h. in diesem Moment wird per Program in anderen Variablen die reale Adresse der Schattenvariable dynamisch berechnet. Nun funktioniert dein obiger Vorschlag nicht mehr so einfach. Eine einfache Methode wäre die Anwendung von OOP. Bei dynamischen Objecten werden deren Felder ja immer indirekt adressiert.

Stimmt. Da hätte der Cracker Mehrarbeit und es ist eine relativ einfach zu verwirklichende Methode.

Zitat:

Zitat von negaH

Im Grunde dürften es garnicht so viele Cracks geben, wenn die Cracker nicht so verdammt gut wären. Programme erstellen ist heute Fließband-Arbeit, Programme cracken dagegen manuelle Hand-Arbeit.

Genau. Es ist auch immer eine Frage Aufwand zu Nutzen. Wenn niemand ein Programm haben will, wird sich auch kaum ein Cracker mit ihm beschäftigen. Ist aber ein Programm sehr gefragt, dann sieht das schon anders aus. Da ist der Elan weit höher, auch wenn der Schutz noch so hoch ist.

[Cybersurfer]

Vielen dank für die vielen schnellen antworten

1. Meine erkenntnis der speicher ist nicht sicher man kann nur hindernisse einbauen!

2. Unter google danach zu suchen is blöd weil ich kein Russisch kann und von den 3 seiten sind die meisten auf russisch oder japanisch sind! Aber was ich bisher nun dazu finden konnte sagt mir das ich mit der funktion nur prüfen kann ob das prog selbstständig läuft oder ob es von einem anderen prog aufgerufen wurde! Stimmt das so?

Danke auch für die anderen anregungen ich denke ich werde einige davon umsetzen!

Was ich noch sagen wollte. Es ist leicht zu sagen derjenige der schummelt beschummelt sich nur selber und wäre es so würde ich ihm das auch gönnen denn er kann ja dadurch mehr spaß am game haben aber wenn es um online oder netzwerk spiele geht sieht es anders aus! Dort beschummelt derjenige nämlich seine gegner und denen kann so die lust am spielen vergehen!!

edit: hab noch was vergessen.

Das man mit der funktion einen debugger finden kann ok aber ein einfaches trainer programm das den speicher liest und beschreibt gilt das auch als debugger und wird dadurch gefunden?

[negaH]

Zitat:

... um online oder netzwerk spiele geht sieht es anders aus! Dort beschummelt derjenige nämlich seine gegner und denen kann so die lust am spielen vergehen!!

Das verändert die Situation total. Netzwerkspiele sind wesentlich sicherer zu bekommen als reine PC Spiele. Das liegt daran das der Spiele-Server kein Interesse hat einen Vollzugriff auf die Server-Scripte/Datenbanken/CGI's oder eben DLL's zuzulassen. Somit kann man die Server Software wie einen einbruchsicheren Safe konstruieren. Auf dem Server selber werden die Spieler-Informationen wie Passwort/Lebenszähler/Levels usw. gespeichert. Die Kommunikation zwischen Server und PC-Spiele ist relativ einfach sicher zu bekommen.

Zitat:

Das man mit der funktion einen debugger finden kann ok aber ein einfaches trainer programm das den speicher liest und beschreibt gilt das auch als debugger und wird dadurch gefunden?

Natürlich nicht. Es können nur "Debugger" gefunden werden die dem OS als Debugger bekannt gegeben wurden. Leider hat das OS-API nicht sehr viel mit echtem Debuggen zutun. D.h. IsDebuggerPresent() unterstützt 1. nur eine ganz spezielle Form des Debuggings von Windows Programmen, 2. kann diese Funktion aus Sicht deines Programmes modifiziert werden und liefert FALSE und 3. ist es der ideal Startpunkt für einen Cracker seinen Angriff zu starten.

Gruß Hagen