GM4HTML5 und Decompilen

  • HTML5

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

  • GM4HTML5 und Decompilen

    Hallo,
    wie es bei den vorherigen Game Maker Versionen passiert ist, passiert nun auch bei dem Game Maker für HTML5: Man kann aus dem Spiel eine fast vollständige Projektdatei gewinnen.
    Bei dem GM:HTML5 wird der Code in Javascript umgewandelt und die Engine angehängt. Das ganze ist dann noch "obfuscated", also der Code wird in einem für den Menschen schwer lesbare Form umgewandelt: Kommentare werden weggelassen, Variablennamen werden durch nichts sagende Buchstabensalate ausgetauscht und die Formatierung wird geändert.
    Falls man ein wenig Zeit investiert, könnte man einen Decompiler entwickeln. Es gibt eigentlich keine Schutzmaßnahmen dagegen. Bis jetzt gibt es meines Wissens keinen Decompiler, aber es ist einer möglich.
    Was ist nicht möglich? Den GML Code wieder vollständig zu bekommen, die Variablennamen sind nicht mehr wieder zuzuordnen und die Kommentare sollten auch vorher entfernt sein. Strings (z.B. Passwörter für Datein) werden vom Obfusactor jedoch nicht angefasst und die sind dann im Klartext.

    Das ganze stellt nur Theorie da, vielleicht hab ich auch was übersehen und ich erzähle hier nur Mist.

    MfG henrik1235
    PS: Hoffe ich poste im richtigen Foren-Bereich.
    wupto.net/ Nicht meine Seite!
    We love Koalas.

    GM-D-Spam-o-Meter: 32%
  • Da kannst du sehr gut recht haben. Html5 ist nunmal ein Problem. Da es Client-seitig (also nicht wie z.B PHP Server-seitig) funktioniert muss der Code in irgendeiner Form auf dem Computer da sein. Also genau wie bei normalem Html...
    Wirklich was dagegen machen kann YoYogames aber nicht. Es müsste schon der Html5-Standard selbst geändert werden. Z.B. so dass der code nur sicher (mitels einer Methode ala PGP) zum Rechner übertragen wird. Allerdings wäre selbst dann der Code irgendwo im Speicher zu finden.

    Es macht keinen Sinn über diese Problem zu reden. Es wird wohl _immer_ bestehen wenn eine interpreter-Sprache zum EInsatz kommt.

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

    Es wird wohl _immer_ bestehen wenn eine interpreter-Sprache zum EInsatz kommt.

    Das Problem besteht auch, wenn eine kompilierte Sprache zum Einsatz kommt (naja gut, bei Java und .NET-Sprachen wird man da erfolgreicher sein, als bei C/C++).

    Und wenn jemand ein Spiel dekompilieren bzw. einen Decompiler schreiben will, dann macht er sich strafbar. Ist dann halt seine Sache.
    Zudem muss man sich auch bewusst sein, dass der Code viel leichter und schneller dekompiliert werden kann, wenn man ein Spiel auf HTML5-Basis erstellt. Das Problem gibt es ja auch bei den alt bekannten Flash-Games. Diese Risiko muss man in Kauf nehmen. So ernst sollte man die Sache nicht sehen, es sei denn man will mit dem Erstellen von HTML5-Spielen Millionär werden.

    Albert Einstein schrieb:

    Probleme kann man niemals mit derselben Denkweise lösen, durch die sie entstanden sind.
  • Vielmehr Sorgen mache ich mir um Resources. Du kannst einfach so rausfinden wo der Game-Ordner/Verzeichnis ist, nur durch "View Source". Deine ganzen Grafiken usw. sind quasi Schutzlos... aber wer kann schon etwas dagegen tun? Schaut euch Blizzard und Machima (oder wie das heisst an), was Video-Editioren verwenden um World of Warcraft Movies zu machen. Die koennen auch ihre MPQ's nich vor reverse-engineering schuetzen.

    Der Quellcode/Script ist nich wirklich so problematisch in meinen Augen, da man nun wirklich selbst genug "gegen" Logging-Spionage tun kann. Da hat man wenigstens noch etwas mehr Kontrolle.

    Aber... wie gesagt, mir ist Resource-Protection viel wichtiger, denn da steckt oftmals 10mal mehr Arbeit und wertvolle Originalitaet dahinter, als bei ein paar Zeilen Script.

    Ich vermisse zum Beispiel extensives File-handling, und Hard-Data-Funktionalitaet im HTML5/JavaScript Bereich, um Resource-Files wenigstens Header-technisch unlesbar zu machen, wie ich das bislang im GM8 gehandhabt hatte.

    Naja, hoffen wir auf das Beste fuer die Zukunft im GM:HTML5 Department =)

    Gruss
  • Ich vermute mal, dass eine Startfunktion ausgeführt wird die, die einzelnen Script/Objekte/Sounds/... ins
    Register liest. Die sind dann für ungefähr 1 millisekunde da ( vllt. sogar noch weniger ) und sind schon fertig geladen.
    Würde man an der Stelle einen CodeCave setzen so könnte man alles herausfiltern.
  • Ich vermute mal, dass eine Startfunktion ausgeführt wird die, die einzelnen Script/Objekte/Sounds/... ins

    Register liest. Die sind dann für ungefähr 1 millisekunde da ( vllt. sogar noch weniger ) und sind schon fertig geladen.

    Würde man an der Stelle einen CodeCave setzen so könnte man alles herausfiltern.
    Sounds und Grafiken werden extern gelagert, der Code wird in Javascript umgewandelt und die restlichen Spielinformationen werden angehängt. Ist also das selbe wie bei den alten Game Maker Versionen, nur das die Spieldateien in der Anwendungsdatei gelagert wurden.
    wupto.net/ Nicht meine Seite!
    We love Koalas.

    GM-D-Spam-o-Meter: 32%
  • Dein Code alleine ist nicht so wichtig, wie du glaubst. Ein guter Entwickler hat das wahrscheinlich selbst geschrieben, bevor er deinen Code für seine Zwecke verwenden kann.
    Wirklich wertvoll ist nur das Gesamtpaket. Auch wenn ich den gesamten Quellcode von Zelda hätte, wäre ich weit davon entfernt, ein Spiel in ähnlicher Qualität abzuliefern.

    Klar, es gibt Leute, die deshalb das Gesamtpaket klauen und dann vielleicht noch etwas modden, aber gegen die kannst du dich auch nicht sicher schützen.
    Stattdessen bietet sich da dann der juristische Weg an - den du vielleicht sogar mit YoYo-Games zusammen beschreiten kannst.

    Kurz: Mach dir darüber keinen zu großen Kopf. Solange du nicht die nächste Unreal-Engine im GM schreibst, kräht kein Hahn nach deinem Source-Code.
    Und: Grafiken und Sounds lassen sich IMMER auch mit einfachen Hausmitteln rippen - und die werden daher auch am ehesten entwendet.
  • Benutzer online 1

    1 Besucher