4. Spiel in Java - prinzipiell nicht cheatsicher?

Spiel in Java - prinzipiell nicht cheatsicher?


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

    Bye, TGGC (Der Held ist zurück)

    0
  • ?

    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

    0

  • 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)

    0
  • P

    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.

    0
  • ?

    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?

    0
  • P

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

    Tja, das is ja nicht mein Problem. 😃

    0
  • P

    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? 😃

    0
  • P

    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?

    0
  • C

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

    0
  • P

    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? 😉

    0

  • 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)

    0
  • P

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

    0

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

    Bye, TGGC (Wähle deine Helden)

    0
  • P

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

    0

  • 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)

    0
  • D

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

    0

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

    Bye, TGGC (Wähle deine Helden)

    0
  • D

    Nagut mehr wollen wir ja auch nicht 😉

    0
  • K

    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.

    0
  • P

    Nicht wenn ich mein Applet signiere. 🙂

    0
Anmelden zum Antworten