Spiel in Java - prinzipiell nicht cheatsicher?

SirLant

Optimizer schrieb:

Dann lass doch das Programm eine Checksumme von sich selbst erstellen und schick die mit.

Könnte aber genaus Checksumme vom Original einmal erstellen und diese schicken.
Es ist nunmal Tatsache, dass man das gleiche Problem unter Maschienencode hat,
nur dort ist es durch die Komplexität um einige Ecken schwieriger, was man bei
Java nicht wirklich behaupten kann, dank den decompilern.

TGGC

Eben, auch so eine Überprüfung des Programms kann man RuckZuck knacken und auf das Originalprogramm "umleiten"...
Eine Überprüfung immer nochmal zu überprüfen macht die sache nicht sicher, wenn die Überprüfung slbst unsicher ist. Höchstens etwas aufwendiger zu umgehen.

Bye, TGGC (Der Held ist zurück)

Sgt. Nukem

Optimizer schrieb:

Physikalisch ist es die ideale Landung, sich so weit es geht, ohne Schub fallen zu lassen und genau im richtigen Moment vollen Schub zu geben um dann genau mit v = 0 aufzusetzen.

Mit v = 0 wirst Du niemals aufsetzen!

Ich meinte ob Spritreserve / gebrauchte Zeit irgendwas an der Punktzahl ändern...

Klar kannst du - zumindest rechnerisch - genau den Boden berühren, wenn v = 0 erreicht ist.
Und ja, ich gehe davon aus, dass das für die Punkte ausschlagebend ist, sonst würde ja das ganze Spiel noch weniger Sinn ergeben.

CengizS

Worin besteht die Motivation einem Hobby-Projekt - das wirklich viele Realisierungen besitzt - eine ultrasichere Highscore-Liste zu verpassen? So bahnbrechend ist die Entwicklung ja - wenn man es auf den Punkt bringen will - nicht, oder? Ich denke das ist mit Kanonen auf Spatzen geschossen. Wenn jemand wirklich die Punktezahl cheaten will dann lässt er einen Socket-Sniffer laufen und sieht dann so auch die Aufrufparameter und den Server - so what?

TGGC

CengizS schrieb:

Ich denke das ist mit Kanonen auf Spatzen geschossen. Wenn jemand wirklich die Punktezahl cheaten will dann lässt er einen Socket-Sniffer laufen und sieht dann so auch die Aufrufparameter und den Server - so what?

Achso? Na dann mach doch mal, wenn das so einfach geht! Bin an jedem Verbesseerungsvorschlag interessiert. (Das ist auch der Grund => Interesse!)

Bye, TGGC (Der Held ist zurück)

TGGC

Hast du (wer auch immer es probiert hat) schon nach 3 Versuchen aufgegeben? Oder hat es danach doch noch geklappt?

Bye, TGGC (Der Held ist zurück)

CengizS

Nein ich habe es nicht probiert. Habe doch oben gesagt, dass meine Motivation dafür gleich null ist.

TGGC

Ich rede ja auch nicht mit dir, sondern mit dem, der es versucht hat. Da ich letztens folgende Angriffe registriert habe, bin ich mir recht sicher, das es einer der Mitleser hier war.

cheater.log schrieb:

80.143.233.xxx TEST 458000
80.143.233.xxx 12345678901234567890 458001
80.143.233.xxx Java ist prinzipiell nicht cheatsicher 1048688

Bye, TGGC (Der Held ist zurück)

Hi

Mal überlgen. Der Anwender kann alle class und jar fils die er in die finger krigt auslesen decompilieren und dadurch modifizieren. bzw im debuger können alle variablen modifiziert werden.

Schlussfolgerung, die kriteschen methoden dürfen nicht als java class file auf das system gelangen. weiter wie kann sichergestellt werden das nichts verändert wurde.

1. Möglichkeit auslagern in eine DLL und über nativ drauf zugreifen. was aber bei nem applet nicht gehen kann. (selbst heir hat an den code und kann modifizieren)

2. möglickeit. die berechnung erfolgt auf dem server. problem wie kommen die daten unverändert auf den server. auch die datenmengen die übertragen wird kann problematisch sein.

jetzt fang ich mal ein bischen an zum rumspinnen.

Ein Spieler läd sich ja das Jar Paket vom server. ( ich glaub doch das das bei applets so war) das Jar packet wird vom server entsprechend vorbereitet. keyfils im paket austauschen,... diser daraus resultierende key gilt in verbindung mit der IP Adresse an die das Packet ging als berechtigung einträge im Higscore vorzunehmen.
Angreifer, er holtsich einmal den alg, und kann somit den veränderten keys der Pakete folgen wen er das einmal rausgefunden hat, das sich die keys dauernd ändern.

erweiterung
Der key wird im game aus den dateien berechnet. es existieren mehrere verschiedene versionen des Spiels mit unterschiedlichen algs.
Angreifer.
er sucht sich die classe und die methode die das ganze macht und verwende sie für seinen Angriff.

Schlussfolgerung bei den unterschiedlichen versionen dürfen die classen und methoden nicht gliech heissen, es müssen mehrer verschiedene mit gleicher oder ähnlicher parameterliste existieren, umd dies nicht automatsich suchen zu lassen.

weitere gemeinheit, die verwendeten keys haben nur eine eingeschránkte gültigkeit, ( ablauf nach einer bestimmten zeit). Einträge mit falschen keys werden akzeptiert. Nach n Stunden werden diese einträge aber dann automatisch wieder gelöscht.

schlussfolgerung. die absulute sicherheit gibt es nicht.
mann kann es den jungs nur schwermachen.

gruss Michael

Pogo

Also ich habe da mal ne Frage, kenn mich ja nun nicht so gut aus:

Kann man das Attribut einer Datei, wann sie zuletzt geändert wurde, manipulieren? Vielleicht kann man da ja gucken ob die Datei nochmal verändert wurde, oder so....

Ja, kann man.

TGGC

@Termite_: Ähh, sehe ich das richtig, du hast deine Ideen jetzt schon wieder alle selbst verworfen?

Bye, TGGC (Der Held ist zurück)

Hi

so in etwa. Ich vergleich mal deine Bemühungen damit ein Haus vor Einbrechern sicher zu machen. Das ist auch unmöglich, wer genug Zeit Geld und Geduld hat kommt in jedes Haus rein. Das einzige was man erreichen kann, ist das man die Kleinganoven abschreckt. Oh die haben ne Alarmanlage, gesicherte Scheiben, ... da lass ich mal besser die finger davon. Aber für alles gibt es mittel und wege sie auszuhebeln. Und wenns so läuft das der Einbrecher jeden abend die Alarmanlage auslöst und dann wieder abzieht. Das speil macht er dann solange bis es dem Besitzer zu blöd wird und sie abschält. Und dann freut sich einer.

Man kann vielleicht Teile des von mir Vorgeschlagenen dazuverwenden den Einbrechern das Leben schwer zu machen, komplet verhindern wirst du es nie können. Schau dir die ganzen bemühungen der Spieleindustrie und der Musikindustrie an, wie lang gings bisher, bis ein Kopierschutz ausgehebelt war?

Gruss Termite

TGGC

Tja darum habe ich ja auch keinen Vorschlag hier benutzt, der mehr als 2h Arbeit bedeutet.

Es gibt einfach nur ein paar kleine Nickligkeiten damit nicht jedes Scriptkiddie es schafft...

Bye, TGGC (Der Held ist zurück)

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?