3. Eigener Datentyp zur Basis x à la Oktal-/Hexadezimalsystem

Eigener Datentyp zur Basis x à la Oktal-/Hexadezimalsystem

  • U

    Mhh ich habe mir nur mal Gedanken gemacht, wie man Cheating in einem Spiel verhindern könnte, es gibt da ja diverse Programme, die direkt auf den Wert im Speicher zugreifen und verändern können - das sollte die Sache imo erschweren 😃

    0
  • *

    🙄

    0
  • ?

    UNeverNo schrieb:

    Mhh ich habe mir nur mal Gedanken gemacht, wie man Cheating in einem Spiel verhindern könnte, es gibt da ja diverse Programme, die direkt auf den Wert im Speicher zugreifen und verändern können - das sollte die Sache imo erschweren 😃

    Intern wird deine Zahl aber binär gespeichert, da kannst du nichts gegen machen 😃 Selbst wenn du deine Zahl im Programm oktal verwendest, nen cheater könnt sich die auch ohne Probleme Dezimal anzeigen lassen, obwohl die meisten wohl Hex bevorzugen 😉

    0
  • *

    Soweit ich das verstanden habe, will er sie als String speichern. Bloss das sich Strings noch einfacher identifizieren lassen.

    0
  • U

    Ja, als String aber halt nicht Hex oder oktal sondern zu einer anderen Basis 17 z.B.

    Meine Frage richtete sich jetzt auf Optimierungsmöglichkeiten meines Konzeptes 😉

    Naja bin dann erstmal im WE und werde mal probieren ob ich es mit meinen bescheidenen Kenntnissen hinbekomme 🙂

    0
  • ?

    UNeverNo schrieb:

    Ja, als String aber halt nicht Hex oder oktal sondern zu einer anderen Basis 17 z.B.

    ich frage mich, wie das einen cheater abhalten sollte.

    aber naja, du willst ein wenig speicher verschwenden und dafür die zahlen verkomplizieren. irgendwie undurchsichtig machen. einfacher ansatz für lebenspunkte wäre, daß du statt der ints von 0 bis 100 nur die glatt durch 67238 teilbaren ints von 0 bis 6723800 nimmst. dürfte kein speedverlust dabei sein, zur anzeige wird eh mit nem float skaliert und ob du if(leb<672380) oder if(leb<10) macchst, ist ja egal. und hin und wieder testest du, ob leb denn in der tat noch glatt durch 67238 teilbar ist. wenn nicht, machste aber bitte kein "du hast gecheatet" und programmende. das fibnden die cracker allzu leicht. dann machste besser die waffe schlechter, ein monster dazu, das laufen lansamer oder so. und nur ein bißchen immer, aber genug, daß sich cheaten auf lange sicht nicht auszahlt.

    wenn man statt der ints immer den int mit 1676893447 multipliziert speicherst, ist das auch lustig. das hat den lustigen effekt, daß die ints nicht mehr in reihenfolge sind. es gibt eine andere zahl, mit der du den int nur multiplizieren musst, und er ist wieder der alte.

    0
  • P

    Am besten ist, die Spiellogik in einer seltenen, bizarren Programmiersprache zu schreiben, z.B. LISP, FORTH, APL, Prolog, usw.

    Wenn der Codegenerator (bei Compilern) für die Programmiersprache dämlich genug ist, kommt völlig verworrener Programmcode heraus. Ich hab das mal mit einem simplen, selbstgebauten FORTH-Compiler probiert, und das Ergebnis war sehr erheiternd (ellenlange CALL- und JMP-Ketten, Stack-Pushes und Pops). Das treibt bestimmt jeden Cracker in den Wahnsinn! 😉

    Bei Interpretern wird es dem Cracker u.U. auch ziemlich schwer gemacht, da er ja zur Erkennung des Programmablaufs (nach efolgreicher Identifizierung der verwendeten Programmiersprache) erst einen Simulator machen muss, der das Spiel soweit simuliert, dass man durch die einzelnen Programmschritte durchsteppen kann. Wenn das sehr viel Code ist, den man durchsteppen muss, wird es ziemlich schwierig. 😉

    Die meisten Cracker werden aber bloss die Datensegmente durchsuchen, ob sich bestimmte Werte verändern (z.B. Anzahl Leben, was man ja oft mit einer einfachen Zahl indentifizieren kann, wenn der Programmierer eine globale Variable verwendet hat; dann steht meist im Speicher irgendwo ein int mit dem Wert). Es kann schon reichen, die Variable auf dem Stack zu deklarieren (d.h. im Function-Scope), und als Referenz an aufgerufene Prozeduren übergeben.

    Eine zusätzliche Verschlüsselung kann auch helfen:

    int r1 = 0X107A92C3;
int r2 = 0XF39B72A9;

void randomize( void ) { // Verwuerfelung von r1 und r2
   r1 = rand();
   r2 = rand();
}

int encode( int a ) { // Kodierung
   return ( a + r1 ) ^ r2;
}

int decode( int a ) { // Dekodierung
   return ( a ^ r2 ) - r1;
}

    Jedoch findet ein Cracker solche Stellen schnell, wenn er das Spiel mit einem Decompiler zurück in Assembler-Quelltext übersetzt.

    Daher der Tip mit den bizarren Programmiersprachen. 😉

    0
  • U

    Mhh das mit als String speichern war ja nur ein Einstiegsvorschlag von mir, der relativ leicht zu realisieren sein sollte.

    Es müßte doch aber auch die Möglichkeit geben einen eigenen Datentyp ähnlich effizient wie int zu erstellen, nur wie?
    Darauf dachte ich Antwort zu erhalten 😉

    0
  • R

    Wie soll das möglich sein? Ein Integer wird ja direkt vom Prozessor verarbeitet. Bei deinem Datentyp müsstest du ja immer Umwandlungsfunktionen einbauen, die das verlangsamen.

    0
  • T

    Integer als Datentyp ist in den meisten Programmiersprachen ja meist so breit wie der Prozessor. Heute also meistens noch 32Bit - und ist somit fest im Prozessor vorhanden. Du kannst nicht einfach soo einen neuen Datentyp wie int erfinden. Die meisten anderen Datentypen sind ja auch endweder Ganzzahlen(CPU) oder Fließkommazahlen(FPU) - was anderes gibts nicht und intern sind es eh alles nur Bitfolgen die je nachdem wie sie interpretiert werden was anderes darstellen.

    0
Anmelden zum Antworten