Game Maker Exe Dekompiler in freier Wildbahn

    • Game Maker

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Wenn der GML-Code wirklich im RAM liegt, gibts nur noch eine möglichkeit, zumindest das Auslesen erheblich zu erschweren: Einen Obfuscator - nicht zu unterschätzen, sowas.

      © 2008 by Teamgrill Productions

    • Kennst du einen, der mit GM8 definitiv funktioniert?
      █████ ██ █ ████ everything ███ █████ is █████ ████ ████ fine ████ ███ █ ██████ love.
      █████ ███████ ███ your █████ ████ government.

    • Weil das mit dem Ram aufgekommen ist: Mit entsprechenden tools (und wenn man ungefähr weiß, wonach man suchen muss, von hand mehrere mb daten zu durchsuchen macht sicher keinen Spaß) lassen sich größere Blöcke gml code finden, die wahrscheinlich durchs interpretieren dort landen. Decompilen ist damit eher nicht möglich, allerdings sollte man Passwörter nur obfuscated und auf keinen fall über sachen wie password=xyz reincoden, das findet man dann relativ leicht.
      Gruß, Spellmaker
      ___________________________________________________________
      Beware of wild pointers      ______Hinweis für Allergiker: Kann Spuren von Ironie enthalten_____

    • Ich weiß nicht, ob folgendes hier schon mal Thema war:

      Anti-decompiler

      Und im Gegensatz zum Namen, kann das Ding noch einiges anderes, als vor Decompilern zu schützen. Es macht RAM-hacks unmöglich ( verschlüsselt die Scripte mit zufälligen Keys und entschlüsselt die dann wieder bei Bedarf). Zudem liegt noch ein kleines Programm bei, welches auch noch gleich komprimiert.

      Das einzige Manko ist allerdings, dass das YYG instantplay nicht mehr nach allem dem was man damit anstellt, funktioniert. Kann man jemand versuchen, da noch was anzurichten. ^^

      MfG SDX

    • Ich glaub davon wurde hier noch nichts geschrieben (zumal das Thema lange auf Eis war). Bin ich letztens schonmal drauf gestoßen als mauge nach dem Protector gesucht hat - aber ich hätte schwören können, dass da zu dem Zeitpunkt noch nichts von GM8-Support stand, weshalb ich es hier auch nicht gepostet hatte. Jedenfalls stimmt's: scheint echt ziemlich geil zu sein. Feedback zu dem Prog wäre cool (also Feedback hier im Thread - ich vertraue hiesigen Usern mehr ;)).

    • SDX schrieb:

      [...]
      Und im Gegensatz zum Namen, kann das Ding noch einiges anderes, als vor Decompilern zu schützen. Es macht RAM-hacks unmöglich ( verschlüsselt die Scripte mit zufälligen Keys und entschlüsselt die dann wieder bei Bedarf). Zudem liegt noch ein kleines Programm bei, welches auch noch gleich komprimiert.
      [...]
      Darf ich deine Euphorie bremsen?

      At the moment, this does:
      • Moves game data to a random position. (Slightly increases filesize, but never by more than 0.07MB)
      • Encrypts game data with random keys.
      • Overwrites all version info with random data.
      • Integrates itself into the game EXE - doesn't extract any DLLs, doesn't save any temporary files.
      • Has an extremely small decryption time.
      Es bewegt die Spieldaten innerhalb der Exe an zufällige Positionen und verschlüsselt die selber nochmals.
      Q: If the data's encrypted and relocated, how does Game Maker read it?
      A: It decrypts at runtime, this program hooks the required functions.
      So wie sich das liest wird das Spiel von diesem Programm dann zur Laufzeit direkt in den RAM entpackt. Irgendwo muss es ja schließlich sein, damit der Game Maker Runner es ausführen kann. Ansonsten müsste da ein eigener Runner her oder der Runner selber gehackt werden, letzteres ist durch die Lizenzvereinbarung verboten.

      Gegen eine Hexeditor der die Datei öffnet hilft das, klar - aber ich seh da nicht mal eine Behauptung, das es den Speicher schützen würde. Das ist in dem Fall btw der Bequemlichkeit geschuldet. Wenn der Game Maker bei Fehlern im Klartext die Zeile mit dem Fehler anzeigen können soll, dann muss der komplette Quelltext in Ursprungsform im Spiel enthalten sein. Sonst geht das nicht.
      Das Bequemliche hieran ist, dass in dem Fall nicht zwischen einem Debug und einem Release Build unterscheiden werden kann. Der GM bietet zwar Debug an, aber da läuft eben nur der GM eigene Debugger mit. Die Daten zum Debuggen sind auch im Release drin.

      Und das sinnvollste wäre - bevor man kopfstände macht um irgendwelche Windows APIs mit Hooks umzubiegen - einfach seitens YYG endlich mal den lesbare Quellcode aus dem fertigen Spiel zu nehmen und dort direkt nur den Bytecode reinzupflastern, den das Spiel momentan (zumindest bei GM 5, 6 und 7) erst beim Start erzeugt.

    • Ich sehe auch keine Möglichkeit ein Spiel vor RAM-hacks zu schützen. Aus einem unverschlüsselten spiel kann man mit Hexeditor schon diverse daten auslesen.
      Die einzige Möglichkeit es absolut unmöglich zu machen, ein GM-spiel (bis und ikl. GM8 ) zu schützen, wäre die Installation eines Rootkit. Damit könnte man per hook alle nicht genemigten anfragen auf eine DummieFile oder ins Nirvana leiten lassen und das Rootkit selber ist eh so gut wie unangreifbar. Das machen sogar Firmen wie Sony, könnte aber theoretisch (meinses wissens noch nicht passiert) als schwere Straftat ausgelegt werden.
      Battle Command - WeltraumEchtzeitStrategie | Meine GM Spiele auf Box.net
      GCM/FA/O d-(--)@>---xpu s-:- !a C++$@ U- P L+ E W++ N o K-- w++ O? M V PS PE-- Y PGP t 5 X R+++ tv+ b DI D G e+ h? r-- x

    • zum passwortschutz müsste mach doch nur nen Hash-String generrieren und diesen dann abspeichern^^

      edit: btw: gibts eigtl i.was seitens YYG, dass der GM iwann mal einen RICHTIGEN Compiler bekommt und man kein GML mehr aus dem RAM zu bekommen kann :motz: oda sogar via notepad 8|
      яёchtschreibfähler sint Spezїal-Effekts meiner TaϨtatur

    • Da gibts ganz sicher keinen Machine-Code Compiler... und es ist auch unwahrscheinlich, dass sich in nächster Zeit was am Bytecode und dahinterliegenden gml-Sourcecode in der Exe ändern wird, die haben doch erst nen C++ Runner geschrieben, ich denk, wenn, dann hätten sie gleich einen neuen Interpreter zusammen mit dem neuen Runner konzipiert, und nicht jetzt erst danach.
      Es müsste ja nichtmal ein richtiger Compiler sein, ein anständiger JIT-Compiler/Bytecode-Interpreter würds auch schon tun(Eh besser). Am besten würden se eh gleich mit C# / Java / Python / Lua fahren, wobei sich zumindest bei C# und vermutlich auch Java der Code anständig obfuscaten lässt.
      "das war meine letzte flamewar PM an dich ."

    • @Famous

      Wenn du der englischen Sprache mächtig bist lies dir mal in diesem Tread ab Seite 79 durch
      gmc.yoyogames.com/index.php?showtopic=416278&st=1560
      Dort schreiben ein paar schlaue Köpfe über Kompiler (und anderen Pro-programmier-Kram den ich nicht verstehe) und darüber ob es wirklich vorteilhaft wäre GM mit einem vollständigen Sourcecode-Kompiler auszustatten.

      Willst du auf diese Drachen und -eier klicken?
      Sie werden sich freuen ;)

    • Der Anti-decompiler ist zur Zeit nicht wirklich unter Entwicklung, da ständig neue GM8.1 Versionen auf den Markt geschmissen werden. Es gibt ihn für 8.1.91. Soweit es mir bekannt ist, hat noch niemand ein Spiel Decompiled bekommen, dass dieses Tool durchlaufen hat.

      Es gilt also einfach abzuwarten, gm8.0 zu nutzen oder auf .91 downzugraden - welches nicht empfehlenswert ist, da das ein recht verbuggter Release war ;)

      MfG SDX