Spiel in Java - prinzipiell nicht cheatsicher?
-
gut, verstanden.
du musst irgendwie code von deinem server ziehen, den keiner kennt. aber durch reflection u.ä. ist es wohl auch schwierig, da sich ja wiederum auch jeder in dem nachgeladenen code stöbern kann.....naja mir fällt gerade nix ein....aber für alles gibt es eine lösung!
-
das wäre event. eine lösung:
in der seite wo das java progamm eingebunden ist ein kleines php script einbauen, dass dir in die datenbank etc. einen unique code schreibt. diesen gibts du dann an deine java anwendung weiter. bevor du den highscore schreibst, prüfst du ob der code in der java anwendung mit den der datenbank übereinstimmt.
-
red2k schrieb:
diesen gibts du dann an deine java anwendung weiter.
Und damit in die Haende des potentiellen Angreifers. Was soll das also bringen?
-
SG1 schrieb:
red2k schrieb:
diesen gibts du dann an deine java anwendung weiter.
Und damit in die Haende des potentiellen Angreifers. Was soll das also bringen?
wie soll er an den code rankommen wenn er nur die java anwendung decompilen kann und nicht das php script??
-
Du gibst den "unique code" an die (unsichere) Java-Anwendung weiter.
-
ja und? wenn man es z.B. über parameter macht steht im code ja nur:
mycode = GetParameter(0);
und nicht der code.
-
Und was hindert den Angreifer, ebenfalls GetParameter(0) zu machen? Oder das fertige Programm nehmen, und sich mycode (nachdem dieser ausgelesen wurde) ausgeben zu lassen?
-
Vollkommen egal, was im Code steht. Der Angreifer übernimmt den einfach in sein gehacktes Programm, und dieses bekommt dann genau wie das normale Programm den Key von wo auch immer man ihn herholt. Der Angreifer brauch den Schlüssel garnicht wissen, sondern einfach nur seine gecheatete Punktzahl mit dem Originalprogramm verschlüssen. Im einfachsten Fall geht er also an die passenden Stelle, fügt dort "punkte= 999999;" und kompiliert das Programm neu.
Bye, TGGC (Der Held ist zurück)
-
Dann lass doch das Programm eine Checksumme von sich selbst erstellen und schick die mit.
-
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.
-
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)
-
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.
-
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?
-
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)
-
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)
-
Nein ich habe es nicht probiert. Habe doch oben gesagt, dass meine Motivation dafür gleich null ist.
-
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 1048688Bye, 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
-
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....