Spiel in Java - prinzipiell nicht cheatsicher?

Pogo

Also geht es hier um die Möglichkeit des Schummels durch das Verändern der class-Dateien eines Applets?
Also man kann doch überprüfen ob die Datei manipuliert worden ist, oder?

Also ich kenn mich da nicht so aus, aber ich denke das Message Digests einem das Schummelleben schwerer machen könnten.

Pogo schrieb:

Also geht es hier um die Möglichkeit des Schummels durch das Verändern der class-Dateien eines Applets?

Ja.

Also man kann doch überprüfen ob die Datei manipuliert worden ist, oder?

Und wo sollte die Ueberpruefung ablaufen? Im Applet selber?

Pogo

Ähh, naja, wäre glaube ich nicht sooo praktisch!

Tja, das is ja nicht mein Problem.

Pogo

Mh es muss doch eine Lösung geben. Also wenn ich den Cracker schon nicht daran hindern kann, mein Programm zu knacken, kann ich ihn dann nicht wenigstens bestrafen?
Ich habe mir das so gedacht. Er soll ruhig die relevante Klasse neucompilieren. Diese Klasse benutzt nun aber natürlich Methoden anderer Klassen. Sagen wir mal, ich habe verschiedene Versionen meines applets. Es verändert sich jeweils irgendeine Klasse, nur die Hauptklasse nicht. Sagen wir mal, eine Klasse, deren Methode die Hauptklasse aufruft, wird einfach durch eine umgeschriebene Version dieser Klasse ersetzt, die diese Methode garnicht besitzt. Dann wird doch bei dem Versuch diese nicht existente Methode aufzurufen ein NoSuchMethodError oder sowas geworfen. Könnte ich nicht alle Exceptions weiter werfen und irgendwo an einer Stelle, die den Cracker nicht interessiert, so behandeln, dass wenn ein NoSuchMethod error auftritt, die Festplatte des Klienten gelöscht wird?

Mh man kann wohl keinen Error fangen. Irgendeine andere Idee wie man selbst zumindest mitbekommt, dass der Code verändert wurde, damit man dann auch gleich irgendwie Schaden anrichten kann?

Pogo

sg1-nichteingeloggt schrieb:

Also man kann doch überprüfen ob die Datei manipuliert worden ist, oder?

Und wo sollte die Ueberpruefung ablaufen? Im Applet selber?

Wenn das Applet signiert ist, kann ich doch schreiben wie ich will. Vielleicht einfach ein Programm an einer Stelle des Applets, die den Cracker nicht interessiert, auf dem Rechner installieren, das das macht?

Christoph

@Pogo:
Ganz schlechte Idee.

Ich jedenfalls hätte nicht gerne potentielle Schadprogramme auf meinem Rechner, auch wenn es nur als "Crackerschutz" gedacht ist. Wie garantierst du, dass dieser "Schutz" nicht durch irgendwas anderes ausgelöst wird?

btw, wenn dein Programm einen fremden Rechner beabsichtigt beschädigt, helfen dir alle "frei von jeglicher Garantie"-Aufkleber nicht mehr.

Pogo

Ja ok mag sein, wie sicher ist es, solche Codeteile, die der Cracker möglichst nicht zu gesicht bekommen soll, wie es schon gesagt wurde, in eine dll auszulagern?
Sind die so viel schwerer zu knacken?

Wäre es "legal", wenn ich irgendwo hinschreibe: "Jeder der den Code verändert, erklärt sich automatisch damit einverstanden, dass seine Festplatte gelöscht wird." oder sowas?

TGGC

Denk mal kurz nach. Mach kann auch cheaten, ohne das Game neu zu kompilieren. Wenn man ganz naiv eine sendScore( int p ); Methode hat, dann kopiert man einfach nur diese eine Methde und ruft sendScore( 999 ); auf. Daher muss man so einen "Schutz" etwas anders aufbauen.

Bye, TGGC (Wähle deine Helden)

Pogo

Mh ich kann das cheaten wohl nich verhindern. Aber Schlimmeres.
Also wenn ich einfach so meinem Applet kompletten Zugang zu meiner Datenbank gebe, dann könnte der böse Cracker sich das einfach anschauen, sich die Zugangsdaten holen und aus lange Weile einfach mal die ganze Datenbank löschen oder andere Spieler sabotieren.
Deshalb werde ich das wohl einfach alles über php-scripts machen, die Passwort und Benutzername des Benutzers(auch vom Cracker) entgegennehmen und nur die Bearbeitung seiner eigenen Zeile in der Tabelle in der Datenbank erlauben.

Aber ich müsste doch scho wenigstens rausfinden können, ob jemand cheatet ...

TGGC

Ich hab das cheaten IMHO eigentlich gut im Griff. Glaube kaum, das Fake Scores in meinen Listen stehen.

Bye, TGGC (Wähle deine Helden)

Pogo

Und wodurch hast du es gut im Griff?
Also wie machst du das? Ok, vielleicht solltest du das lieber nicht sagen. ^^
Ich denk mir schon was aus, um das Cheaten zumindest zu erschweren ...

Bei dem Spiel, das ich jetzt schreibe gibt es ja keine Highscore-Liste. Es ist ein Mehrspieler-Spiel oder soll zumindest eins werden. Also die Applets der beiden Spieler sollen eigentlich nur 2 Werte an ein php-script senden.

1. Sieg/Niederlage/Unentschieden
2. -1/0/1/2/3/4

Also wenn beide Applets Sieg senden, kann ich mir ziemlich sicher sein, dass da jemand cheatet. Bleibt nur die Frage, was ich dann mache ...

TGGC

Pogo schrieb:

Und wodurch hast du es gut im Griff?
Also wie machst du das? Ok, vielleicht solltest du das lieber nicht sagen.

Korrekt erkannt.

Bye, TGGC (Wähle deine Helden)

dali

Naja prinzipiell sollte es immer noch sicher sein auch wenn man das Verfahren kennt

TGGC

Es ist prinzipiell unsicher. Nur praktisch ist es schwer anzugreifen.

Bye, TGGC (Wähle deine Helden)

dali

Nagut mehr wollen wir ja auch nicht

Kampino

Ich würde den Algorithmus gaaanz weit verteilen, was spricht dabegen, die Verschlüsseln Funktion auf 26 klassen und 45 Funktionen, die sich gegenseitig aufrufen usw zu packen? Auch die Idee, funktionslose Funktionen, die z.b. den String spiegeln, und zwar zweimal hinternander (durch mehrere aufrufe oder so), zu machen. dann kannst du noch Obusfaktoren usw. nutzen, die variablen seltsam benennen usw.

Einfach irgendwelche Server anpingen geht nicht, weil ein Applet nur zu seinem Heimatserver Kontakt aufnehmen kann. Es würde eine SecurityException geworfen werden.

Pogo

Nicht wenn ich mein Applet signiere.

TGGC

Kampino schrieb:

Ich würde den Algorithmus gaaanz weit verteilen, was spricht dabegen, die Verschlüsseln Funktion auf 26 klassen und 45 Funktionen, die sich gegenseitig aufrufen usw zu packen? Auch die Idee, funktionslose Funktionen, die z.b. den String spiegeln, und zwar zweimal hinternander (durch mehrere aufrufe oder so), zu machen. dann kannst du noch Obusfaktoren usw. nutzen, die variablen seltsam benennen usw.

Was spricht dagegen bevor alle 45 Funktionen aufgerufen werden

Punkte= 1000000;

in den decompilierten Code zu schreiben und neu zu kompilieren?

Bye, TGGC (Keine Macht den Dummen)

Pogo

Mal ne Frage wegen dem Neucompilieren. Wie nutzt der Schummler diese veränderte Version des Applets z.B.?
Würde ihm das Neucompilieren überhaupt was bringen, wenn ich es so einrichten würde, dass das gesamte Applet immer wieder komplett neu heruntergeladen werden muss(wie erreicht man das? )?

TGGC schrieb:

Kampino schrieb:

Ich würde den Algorithmus gaaanz weit verteilen, was spricht dabegen, die Verschlüsseln Funktion auf 26 klassen und 45 Funktionen, die sich gegenseitig aufrufen usw zu packen? Auch die Idee, funktionslose Funktionen, die z.b. den String spiegeln, und zwar zweimal hinternander (durch mehrere aufrufe oder so), zu machen. dann kannst du noch Obusfaktoren usw. nutzen, die variablen seltsam benennen usw.

Was spricht dagegen bevor alle 45 Funktionen aufgerufen werden
Punkte= 1000000;
in den decompilierten Code zu schreiben und neu zu kompilieren?

Bye, TGGC (Keine Macht den Dummen)

Kannst du nicht einfach mehrere Variablen machen die das gleiche speichern und daher syncron sein müssen? Zum Beispiel noch in einer zweiten Variable speichern die dann mit irgend einer Bitmask xored ist. Wenn man nun in den Code schaut dann findet man die erste ändert sie => die Variablen sind nicht syncron => das Program weis das etwas faul ist. Das Problem hier ist natürlich auch, dass es nicht sicher ist da man den Code lesen kann und das heraus finden kann allerdings man muss ihn lesen. Gut verunstaltet sollte das aber ein paar abhalten.