RAM Hack Protection

    • GEX

    • RAM Hack Protection

      Der eine oder andere hat vielleicht schon das Problem gehabt, dass er ein tolles Spiel mit Online-Highscore erstellt hat, und dann landen nach einer gewissen Zeit Einträge in dieser, die völlig unrealistisch sind. Schuld daran sind Eingriffe in den Arbeitsspeicher, mit denen man die Punktzahl hochschraubt, oder die Spielzeit runter dreht - sogenannte Ramhacks.

      Um allerdings den Wert einer Variable (Munition, Anzahl von Leben, Punkte, Spielzeit, etc.) durch einen Ramhack ändern zu können, muss man erst einmal herausfinden, wo diese Variable im Arbeitsspeicher abgelegt ist. Und um genau dies zu verhindern, existiert diese Erweiterung.

      Wer also zu denen gehört, die sich mit Ramhackern in ihren Onlinehighscores rumschlagen müssen, oder wem es einfach nicht gefällt, dass andere in seinem Spiel zumpfuschen um sich irgendwelche Vorteile zu verschaffen, der kann diese Erweiterung verwenden.

      Das Verwenden externer Funktionen zum Speichern und Laden von Variablen mag im Bezug auf auf Rechenzeit vielleicht etwas teurer sein, als die vorgefertigten Mechanismen des Game Maker zu verwenden, aber das wird dadurch wieder ausgeglichen, dass keine Verschlüsselungs- oder Hashalgorithmen verwendet werden, und auch keine Redundanz durch Backupvariablen erzeugt wird.
      Wenn man diese Funktionen also nur in Maßen bei den Werten einsetzt, die wirklich geschützt werden müssen, sollte es sich nicht negativ auf die Performance auswirken.

      Angehangen sind 2 Versionen.
      Einmal die Erweiterung mit einem einfachen Beispiel, wie man sie verwendet für diejenigen, die den GM7 verwenden,
      und einmal ein Paket, bestehend aus einer DLL und den kommentierten Skripten, um diese zu verwenden, für diejenigen, die lieber den GM6 verwenden wollen.

      Für Fragen, Kritiken und Wünsche bin ich jederzeit offen.
      Dateien

      • rhp_extension.zip

        (96,88 kB, 298 mal heruntergeladen, zuletzt: )

      • rhp_dll.zip

        (77,58 kB, 252 mal heruntergeladen, zuletzt: )

    • Eine Extension oder DLL um gegen RAM-Hacks vorzugehen? Snowball scheint praktisch unhackbar zu sein, dabei hat mauge da ein ganz ganz simples internes Konzept verwendet, welches anscheinend auch Leistungsfreundlich ist. Natürlich ist es sehr freundliche Unterstützung eine Extension gegen Hacker anzubieten, aber ich halte diese für ziemlich überflüssig. :huh:

    • @CAS: Mich würde einfach interessieren, wie genau du vorgegangen bist, bzw. auf welche Weise dein System arbeitet. So könnte man etwas dazu lernen, oder zumindest abwägen, ob und in welchen Spielen deine Technik Sinn macht. Schließlich haben wir nach dieser kurzen Einführung keine Ahnung, wie effektiv es ist.
      █████ ██ █ ████ everything ███ █████ is █████ ████ ████ fine ████ ███ █ ██████ love.
      █████ ███████ ███ your █████ ████ government.

    • Moin,
      die sache mit einer DLL anzugehen finde ich unverhältnismäßig, man kann auch die variablen so auf Konsistenz prüfen...
      z.B.: wenn der Spieler ein leben verliert. Bevor ein leben abgezogen wird den Wert speichern, und danach überprüfen ob sich die Leben geändert haben(was sie eigentlich müssten)... Ich werde mal ein Tutorial für soetwas schreiben.

      MfG Genesis

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Genesis ()

    • @CAS: Mich würde auch die Technik dahinter interessieren, aber ich denke, dass deine DLL sehr sinnvoll ist, vor allem wenn man mit sensiblen und online-relevanten Daten umgeht, die gegen RAM-Hacks geschützt werden müssen. Ich fände es aber sinnvoll, wenn du noch eine crypt / hash Funktionalität mit einbauen würdest, da man sonst ja mit etwas Glück durch durchsuchen des RAM-Bereiches des Spiels (außerhalb dessen die Daten ja nicht liegen können, da die DLL diesem Prozess angehört - oder startest du einen Subprozess?) die Position des Wertes finden kann. Oder nutzt du irgendwelche Obfuscation? (Wobei ja bekanntlich Security by Obscurity nicht so sinnvoll ist)

      @Genesis: Und woher weißt du, dass der Wert nicht geändert wurde, bevor das Game ihn selbst ändert? Ich kann den Wert ja jederzeit manipulieren, nicht nur wenn ich gerade zufällig ein Leben verliere.

    • T-Moe schrieb:

      @Genesis: Und woher weißt du, dass der Wert nicht geändert wurde, bevor das Game ihn selbst ändert? Ich kann den Wert ja jederzeit manipulieren, nicht nur wenn ich gerade zufällig ein Leben verliere.

      Logik! :D
      Bei einer gut durchdachten Handhabung der Variablen, kann man jede art von Manipulation abfangen!

      Und da ein Speichermanipulationsprogramm alle 50 Millisekunden ein update des Speichers macht ist die prüfung ausreichend(wer sich schonmal mit ram hacks auseinadergesetzt hat kennt das problem des Updatens)

      MfG Genesis

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Genesis ()

    • Ich wollte im ersten Post, der ja quasi auch ne Form von Werbung sein sollte, nicht mit technischen Details langweilen, aber da offenbar doch größeres Interesse besteht:

      T-Moe schrieb:

      Ich fände es aber sinnvoll, wenn du noch eine crypt / hash Funktionalität mit einbauen würdest, da man sonst ja mit etwas Glück durch durchsuchen des RAM-Bereiches des Spiels (außerhalb dessen die Daten ja nicht liegen können, da die DLL diesem Prozess angehört - oder startest du einen Subprozess?) die Position des Wertes finden kann.


      Dieses Durchsuchen sieht dann ja entweder so aus, dass man nach nach unbekannten Werten sucht, und diese auf Änderungen filtert, wenn man den exakten Wert nicht kennt, oder indem man den Speicher nach Variablen mit dem gesuchten Wert durchsucht, wenn man ihn kennt. Im zweiten Fall erhält man aber i.d.R. sehr viele Adressen, so dass man auch da Veränderungen an den Variablen vornehmen muss, um herauszufinden, an welcher Adresse genau nun dieser Wert gespeichert ist.

      Und genau da setzt meine DLL (die in der Erweiterung verwendet wird) an: Jedes mal, wenn man dort etwas speichert, wird neuer Speicher reserviert, und der alte Speicher dieser Variable wieder freigegeben. D.h. bei jedem schreibenden Zugriff "zieht die Variable um". Deswegen funktioniert auch das Durchsuchen des RAMs nicht mehr, da die gesuchte Variable immer aus der Menge beobachteter Adressen herausspringt.

      Was nun genau getan wird: Wenn man speichert, wwerden nur 3 Elementare Anweisungen ausgeführt: Alten speicher freigeben, soweit er belegt war, neuen Speicher allokieren, Wert zuweisen. Wenn man ausliest wird einfach nur der Wert zurückgegeben, der dort gespeichert ist.

      Der Vorteil gegenüber Verschlüsselungen oder Hashs besteht darin, dass diese sowohl beim Schreiben als auch bei jedem Auslesen zunächst irgendwelche Berechnungen anstellen müssen, um entweder den eigentlichen Wert zu erhalten oder um zu überprüfen, on der gespeicherte Wert immer noch der ist, der er sein sollte.
      Auch mit Backup-Variablen muss man immer erst noch Vergleiche anstellen. Hinzu kommt, dass diese dann auch zusätzlichen Speicher fressen, und man immer noch manipulieren kann, indem man auch die Backup-Variablen bearbeitet.

      Das einzige, was hier also "teuer" ist, ist der Aufruf von externen Funktionen an sich; und bei denen habe ich keine Ahnung, wieviel Performance im Vergleich zu GM-internen Funktionen wirklich verloren geht.

    • Genesis schrieb:


      Logik! :D
      Bei einer gut durchdachten Handhabung der Variablen, kann man jede art von Manipulation abfangen!

      Und da ein Speichermanipulationsprogramm alle 50 Millisekunden ein update des Speichers macht ist die prüfung ausreichend(wer sich schonmal mit ram hacks auseinadergesetzt hat kennt das problem des Updatens)

      MfG Genesis


      Eine solche Methode würde natürlich das einfrieren des Speichers verhindern. Jedoch ist das Einfrieren nur eine von vielen Arten der Manipulation, und deine Methode überprüft nur, ob eine Änderung der Variable tatsächlich durchgeführt wird. Sie überprüft jedoch nicht, ob eventuell zwischen den Zeitpunkten, an denen deine Änderung - und somit Prüfung - stattfindet eine externe Veränderung der Daten erfolgt ist. Dafür müsste wieder eine - hier bereits mehrfach angesprochene - Verschlüsselung oder Hash-Funktion (bzw. CAS System) verwendet werden.

      @CAS: Ok, das mit dem ständigen "Bewegen" der Daten fügt natürlich eine zusätzliche Sicherheit hinzu, dann kann man auch auf Hash-Werte verzichten. Man könnte zwar mit großem Aufwand beobachten, dass genau zu dem Zeitpunkt, wo die Änderung stattfindet der neue Wert an eine bestimmte Adresse geschrieben wird, man benötigt jedoch großes Glück damit dieses Verfahren funktioniert. Und wer sich diese Mühe macht würde sich auch die Mühe machen eines Verschlüsselung zu reversen oder den Speicherort eines Hashes zu suchen.
      Sowas würde aber weit über normales Ram Hacking hinaus gehen, also ist eine solche Bewegung durchaus als sicher zu betrachten.

    • CAS schrieb:

      Und genau da setzt meine DLL (die in der Erweiterung verwendet wird) an: Jedes mal, wenn man dort etwas speichert, wird neuer Speicher reserviert, und der alte Speicher dieser Variable wieder freigegeben. D.h. bei jedem schreibenden Zugriff "zieht die Variable um". Deswegen funktioniert auch das Durchsuchen des RAMs nicht mehr, da die gesuchte Variable immer aus der Menge beobachteter Adressen herausspringt.

      Was nun genau getan wird: Wenn man speichert, wwerden nur 3 Elementare Anweisungen ausgeführt: Alten speicher freigeben, soweit er belegt war, neuen Speicher allokieren, Wert zuweisen. Wenn man ausliest wird einfach nur der Wert zurückgegeben, der dort gespeichert ist.

      Der Vorteil gegenüber Verschlüsselungen oder Hashs besteht darin, dass diese sowohl beim Schreiben als auch bei jedem Auslesen zunächst irgendwelche Berechnungen anstellen müssen, um entweder den eigentlichen Wert zu erhalten oder um zu überprüfen, on der gespeicherte Wert immer noch der ist, der er sein sollte.
      Auch mit Backup-Variablen muss man immer erst noch Vergleiche anstellen. Hinzu kommt, dass diese dann auch zusätzlichen Speicher fressen, und man immer noch manipulieren kann, indem man auch die Backup-Variablen bearbeitet.

      Das einzige, was hier also "teuer" ist, ist der Aufruf von externen Funktionen an sich; und bei denen habe ich keine Ahnung, wieviel Performance im Vergleich zu GM-internen Funktionen wirklich verloren geht.

      Simpel aber effektiv, ich denke schon das diese Methode wirksam ist(erst dachte ich, dass du die variablen bei jedem zugriff verschlüsselst was sich ja als sehr ineffektiv herausstellt)

      gibt es auch gml scripts für den GM6.x oder hattest du "nur" die GEX geplant?(hab mir noch nicht heruntergeladen da ich keinen GM 7 benutze und GEX somit nutzlos für mich sind)
      MfG Genesis

    • T-Moe schrieb:

      @CAS: Ok, das mit dem ständigen "Bewegen" der Daten fügt natürlich eine zusätzliche Sicherheit hinzu, dann kann man auch auf Hash-Werte verzichten. Man könnte zwar mit großem Aufwand beobachten, dass genau zu dem Zeitpunkt, wo die Änderung stattfindet der neue Wert an eine bestimmte Adresse geschrieben wird, man benötigt jedoch großes Glück damit dieses Verfahren funktioniert. Und wer sich diese Mühe macht würde sich auch die Mühe machen eines Verschlüsselung zu reversen oder den Speicherort eines Hashes zu suchen.
      Sowas würde aber weit über normales Ram Hacking hinaus gehen, also ist eine solche Bewegung durchaus als sicher zu betrachten.

      Die Chance, solch ein System durch Beobachten zu knacken, ist gleich null. Mehrere Leute haben (in meinem Auftrag) versucht, "Snowball" zu knacken - ohne Erfolg. Die wichtige Variable springt in jedem Step in eine andere RAM Adresse. Ich hab noch zusätzliche Sicherheitsmaßnahmen getroffen, die aber eigentlich völlig unnötig sind.
      @CAS: Danke für die Info. Du verwendest offensichtlich eine ähnliche Technik wie ich; mit dem Unterschied, dass ich keine Extension benutze. Wie man es nun macht, spielt keine Rolle. Das bleibt jedem selbst überlassen, denke ich.
      █████ ██ █ ████ everything ███ █████ is █████ ████ ████ fine ████ ███ █ ██████ love.
      █████ ███████ ███ your █████ ████ government.

    • Genesis schrieb:

      gibt es auch gml scripts für den GM6.x oder hattest du "nur" die GEX geplant?(hab mir noch nicht heruntergeladen da ich keinen GM 7 benutze und GEX somit nutzlos für mich sind)
      MfG Genesis


      Deswegen liegt auch das zweite Archiv bei, in dem sich die DLL entsprechenden Skripten befindet.

      @mauge:
      Ich nutze deshalb ne DLL, weil ich nicht wüsste, wie ich das mit GM-internen Mitteln umsetzen sollte, außer anstelle einer Variable ein Array zu verwenden und zyklisch durch den Index zu wechseln, oder ständig neue Instanzen von unsichtbaren Objekten zu erzeugen, die als Datenkontainer dienen, oder irgendwas derart mit Datenstrukturen umzusetzen. Alle Methoden, die mir da so in den Sinn kommen wirken auf mich entweder relativ rechenintensiv oder speicherlastig, während ich unter C++ mit new und delete recht simple Methoden habe, Speicher zu allokieren oder wieder freizugeben. Die DLL dient lediglich dazu, die C++ Funktionen auch im GM nutzen zu können. (Und die Extension wurde für den GM7 gebastelt, da in der Hilfe explizit erwähnt wird, dass die DLL Funktionen veraltet sind, und man lieber Extensions nutzen soll.)

      Jedenfalls war ich irgendwie der Meinung, dass die Aufrufe und Abarbeitungen dieser zwei Funktionen weniger kosten würden, als alles, was ich mir im GM zurecht schustern könnte. Evtl. zeigt ein Benchmark auch, dass meine vermeintlich effiziente Lösung der absolute Performancekiller ist...

    • Hey! Wo sind denn meine Schutzskripte da gelandet? (@mauge) :P

      Also, da mauge meine Schutzskripte da (auch) benutzt, zusätzlich zu anderen Schutzmaßnahmen natürlich, kann ich dazu sagen: das frisst praktisch überhaupt keine Performance. Der Rechenaufwand ist wirklich minimal und das ganze wirkt sich nichteinmal minimal auf die Performance des Spiels selbst aus. Diesen wirklich minimalen Unterschied festzustellen oder auszudiskutieren lohnt sich meiner Meinung nach einfach nicht. Beide Systeme funktionieren wahrscheinlich, und beide werden wohl auch sehr sparsam sein.

    • LEWA schrieb:

      Mich würde es sehr interessieren wie man mit dem Game Maker eine Variable immerwieder jedes Step in eine andere RAM Adresse stecken kann. :P (@mauge)

      (Falls das für Spam giltet: Sorry...)


      Mit CAS' Extension. ;)
      Ich werde meine Technik nicht verraten, sorry. Ich bin froh, dass es bisher keiner geknackt hat.
      █████ ██ █ ████ everything ███ █████ is █████ ████ ████ fine ████ ███ █ ██████ love.
      █████ ███████ ███ your █████ ████ government.

    • Mich würde sehr interessieren wie genau Ram Hacks funktionieren. (Also wie man in den Ram speicher kommt.)

      Ich habe nähmlich vielleicht eien Idee, wie so ein sicheres Variablensystem funktionieren könnte. (Ohne DLL.) Aber dazu müsste ich selsbt i nden Ram speicher kommen müssen. :)