Verchlüsselung einer Datei

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

    • Verchlüsselung einer Datei

      Hi Leute!
      Ich mache mir seit einiger Zeit gedanken über das verschlüsseln einer Binären Datei.
      Ich nutze die 39DLL für das Speichern von Daten. Ich würde gerne empfindlichere Daten wie Serveradressen und passwörter speichern, jedoch kann man sie mit ei nwenig know-how ziemlich leicht auslesen.
      (Insbesondere wenn man weiss wie das Dateiformat aufgebaut ist da es ja "open Source" sein soll.)

      Die Frage:
      Was wären effektive Methoden um solche kritischen Informationen zu verschlüsseln?
      Natürlich kann man nicht alles 100%ig sicher machen, aber es sollte eine Methode sein die die meisten "Hobby-Hacker" daran hindert an diese Informationen zu gelangen.
      Die Frage ist blos: Was gäbe es für Möglichkeiten dies zu realisieren?
      Ich habe leider auf diesem Gebiet 0-Erfahrung.

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

    • Du könntest die Xor Crypt DLL von Bl@ckSp@rk dafür verwenden. So hab ich das damals bei Roll! ebenfalls gelöst.
      Nach dem Speichern der Datei musst du sofort mit der DLL über die Datei gehen und mit einen Passwort crypten.
      Das wäre zumindest die einfachste Methode, die mir jetzt in den Kopf gestiegen ist.

      edit: Natürlich sollte man für die Hard-gecodeten Passwörter noch zusätzlich einen Decompilerschutz auf die Exe packen. (edit 2: der wohl scheinbar nicht mehr für gm 8.1 verfügbar ist).

      - Joex3

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

    • Joex3 schrieb:

      edit: Natürlich sollte man für die Hard-gecodeten Passwörter noch zusätzlich einen Decompilerschutz auf die Exe packen.
      Ehm, kennst du etwa einen der erfolgreich mit GM 8.1 funktioniert? o:

      @LEWA
      Solch eine DLL zu nehmen ist wohld efinitiv die beste Lösung. XOR ist auch einigermaßen sicher (wenn das Passwort lang ist usw.)
      Man kann auch in GML crypten und decrypten (auf GMLScripts.com gibt es dazu ein paar Skripte) dies ist aber natürich nicht sonderlich schnell..

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

    • LEWA schrieb:

      Ich würde gerne empfindlichere Daten wie Serveradressen und passwörter speichern
      Eventuell finden sich auch elegantere Lösungen, da sich die lokal ablaufenden Routinen zur Entschlüsslung dieser empfindlichen Daten mit einem recht geringen Aufwand nachvollziehen lassen. Das Nachbauen dieses Verfahrens, in der Verbindung mit dem Auslesen des zum Entschlüsseln benötigten Passworts würde schon ausreichen um an die empfindlichen Daten zu kommen.

      Wenn es dir um etwas ähnliches wie Funktionalität zu einem Dateiupload geht, wäre zum Beispiel ein einfacher POST Request die bessere sowie auch sicherere Lösung. Um unerwünschten Dateiverkehr dabei zu verhindern, würde eine simple, serverseitige Validierung der übertragenen Daten ausreichen.

    • Naja... in meinem Spiel hab ich auch eine kleine Krypto-Funktion geschrieben, um Levelbeschreibungsdateien unleserlich zu machen. Im Wesentlichen basiert das Ganze darauf, dass ein String Zeichen für Zeichen um eine bestimmte, variierende Bitfolge verschoben wird (meine Formel ist jetzt nicht so irrsinnig kompliziert, aber immer noch verwirrend genug) und dann die Byte-Werte direkt in Zahlenform niedergeschrieben werden. Der entsprechende Seed kommt auch noch mit in den Ausgabestring.
      Der Nachteil: Der Ausgabestring ist viel länger als der Eingabestring.
      Der Vorteil: Das Auslesen ist extrem einfach, wenn man die Verschlüsselungsformel kennt - tut man 's nicht, beißt sich zumindest das durchschnittliche GM-Skriptkind die Zähne aus.

      Ein derart verschlüsselter String könnte etwa so aussehen:
      18661!170!163!159!66!121!168!192!111!175!49!206!180!174!268!206!152!126!216!164!110!226!211!149!
      Wer's zu entschlüsseln versuchen will, ist herzlich eingeladen. ;)

      Worauf ich hinauswill: Für weniger wichtige Daten ist so eine Verschlüsselung (vielleicht mit einer etwas komplexeren Rechenformel als meiner) ebenso geeignet wie für sensiblere - wenn es allerdings wirklich um sowas wie Webspace-Passwörter geht, solltest du die Strings, die du verschlüsseln willst, NIE in der gmk liegen haben. Exportier deine Verschlüsselungsfunktion in ein neues Projekt und lass dieses Programm dann eine Textdatei mit den verschlüsselten Strings anlegen. Im eigentlichen Spiel lässt du diese Datei dann nur noch auslesen und entschlüsseln - am besten auch auf eine Weise, die die Bedeutung des ausgelesenen Zeugs verschleiert. Das Zwischenspeichern der entschlüsselten Strings in irgendwelchen Variablen ist auch tabu, das kann per Speicher-Readout abgegriffen werden. Obfuscating kann auch nicht schaden, letztendlich muss sich dann nämlich ein Mensch hinsetzen und den ganzen Mist wieder durchschauen - und Leute wie HAUS! (na, wer erinnert sich noch an ihn?), die einfach nur mal ein bisschen Ärger stiften wollen um zu zeigen, dass sie's können, werden sich bei so vielen Hindernissen entweder richtig ins Zeug legen oder es gleich ganz bleiben lassen müssen.

    • Na dass hört sich doch nach richtig viel fun an.


      Wenn es dir um etwas ähnliches wie Funktionalität zu einem Dateiupload geht, wäre zum Beispiel ein einfacher POST Request die bessere sowie auch sicherere Lösung. Um unerwünschten Dateiverkehr dabei zu verhindern, würde eine simple, serverseitige Validierung der übertragenen Daten ausreichen.

      Ich spielte mit den gedanken herum die OHS DLL zu verwenden da ich ja online Hiughscores auf Webservern abspeichern möchte.
      Inwiefern die Verbindung da abgehalten wird weiss ich nicht mehr. Hab die seit ewigkeiten nicht mehr verwendet.

      Naja... in meinem Spiel hab ich auch eine kleine Krypto-Funktion geschrieben, um Levelbeschreibungsdateien unleserlich zu machen. Im Wesentlichen basiert das Ganze darauf, dass ein String Zeichen für Zeichen um eine bestimmte, variierende Bitfolge verschoben wird (meine Formel ist jetzt nicht so irrsinnig kompliziert, aber immer noch verwirrend genug) und dann die Byte-Werte direkt in Zahlenform niedergeschrieben werden. Der entsprechende Seed kommt auch noch mit in den Ausgabestring.
      Der Nachteil: Der Ausgabestring ist viel länger als der Eingabestring.
      Der Vorteil: Das Auslesen ist extrem einfach, wenn man die Verschlüsselungsformel kennt - tut man 's nicht, beißt sich zumindest das durchschnittliche GM-Skriptkind die Zähne aus.

      Ich muss mir mal anschauen wie das mit dem Seed funktioniert. Ich habe da keinen Plan. (*guck nach')

      wenn es allerdings wirklich um sowas wie Webspace-Passwörter geht, solltest du die Strings, die du verschlüsseln willst, NIE in der gmk liegen haben.

      Ich packe passwörter nie in die gmk rein. Die Passwörter sollen ja in den jeweiligen Dateien (mitsamt der adresse) gespeichert werden.
      So besteht die Möglichkeit, jedesmal einen anderen Server anzusprechen (je nach den Daten in der Datei)

      am besten auch auf eine Weise, die die Bedeutung des ausgelesenen Zeugs verschleiert. Das Zwischenspeichern der entschlüsselten Strings in irgendwelchen Variablen ist auch tabu, das kann per Speicher-Readout abgegriffen werden.

      Inwieweit kann man denn einen Wert auslesen und diesen auch in einem Script verwenden ohne ihn zwischenzuspeichern? Die jeweilige Information muss ja einer Variable zugeordnet werde ndamit sie überhaupt verwendet werden kann.
      Oder meinst du Variablen die mit "var" deklariert wurden? (Diese gelten dann ja nur für den jeweiligen Script)

      /Edit @ Irrenhaus3:
      Huh! Neuer Avatar?

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

    • Ich weiß nicht mehr ob die älteren Versionen das können oder GM 8.1, aber bei Studio kann man MD5 decoden und encoden.
      Zu dem haben die noch ander Decoder Fuktionen eigefügt.

      lg Calystor

    • Eine MD5-Decodierfunktion haben sie garantiert nicht eingebaut denn sie existiert nicht und wenn sie eine gefunden hätten, hätte die CIA und viele Sicherheitsfirmen sie schon längst ermorden lassen :D (wenn es den besseren Sha Algorythmus nicht schon gäbe.)

      MD5 ist ein Haschalgorythmus dessen sinn es ja ist nur in eine Richtung zu funktionieren. Dabei ist das Erbenis praktisch einzigartig. Dadurch kann man z.B. ein Passwort welches auf dem PC des Users eingegeben wird, mit dem Paawort mit der Datenbank auf dem Server überprüfen _ohne_ dass das passwort als solches durch das Netz geschickt werden würde (was ein Sicherheitsrisiko darstellen würde).


      Zum Thema: Ein grosses Problem das man beim Arbeiten im GM mit "brisanten" Dingen ist leider diese Sache mit dem Decompiler.
      Ich empfehle dir nicht ein encrypt-Skript zu schreiben welches du mehrfach benutzst sondern besser den Code direkt im Event zu schreiben (am besten in ein unerwartetes Event wie dem Draw oder so). Zudem lass dein Projekt bevor du es veröffentlichst durch den Obfuscator bearbeiten. Dies schafft zumindest ein kleines bisschen Sicherheit wenn dein Projekt einigermassen komplex ist.

      Wenn es dir nur um die Passwörter geht, dann kannst du aber doch die md5 Funktion benutzen und wie oben beschrieben anwenden (auf dem Server nur die gehashte Version des Passworts speichern). Die 39DLL besitzt bereits eine solche Funktion.

      Pass aber auf keine Sonderzeichen die nicht zum Ascii Set gehören, zuzulassen. Sonst kommt eigenartigerweise im GM ein anderes Ergebnis raus als wenn man es in PhP (auf dem Server) tun würde.

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

    • DragenGamer ich weiß was MD5 ist ich bin Web Administrator und Programmiere in meiner Firma.
      Was ich da mit gemeint habe es kann wieder aus gelesen werden!

      base64 encode
      Spoiler anzeigen

      Encode a string using base64 format.
      Syntax :
      base64_encode(string)

      ArgumentDescriptionstringThe string to encode.
      Returns : String
      Description
      This function will convert a string into a base64 format encoded string. This is a commonly used encoding scheme that is often used for any media that needs to be stored or transferred over the internet as text, and renders the output unreadable to the human eye.


      Example :
      var str, file;
      str = base64_encode(game_data);
      file = file_text_open_write("save.txt");
      file_text_write_string(file, str);
      file_text_close(file);

      The above code will covert the string stored in "game_data" into a base64 encoded string which is then stored in an external text file.


      decode
      Spoiler anzeigen

      Syntax :
      base64_decode(string)

      ArgumentDescriptionstringThe string to decode.
      Returns : String
      Description
      This function will convert a string encoded previously using base64 format, into standard text. Base64 is a commonly used encoding scheme that is often used for any media that needs to be stored or transferred over the internet as text, and renders the output unreadable to the human eye.


      Example :
      var str, file;
      str = base64_encode(game_data);
      file = file_text_open_read("save.txt");
      str = file_text_read_string(file); level_data = base64_decode(str);
      file_text_close(file);

      The above code will open a text file and read a string from it into the local variable "str". This string is then decoded and the result stored in the instance variable "level_data".



      md5
      Spoiler anzeigen
      md5_string_unicode
      Returns an MD5 of the unicode format input string.
      Syntax :
      md5_string_unicode(string)

      ArgumentDescriptionstringThe string to hash.
      Returns : String
      Description
      In cryptography, MD5 (Message-Digest algorithm 5) is a widely used cryptographic hash function with a 128-bit hash value and has been employed in a wide variety of security applications. It is also commonly used to check the integrity of files and strings. This function will take an input unicode string (which is 16bits for each char) and return the 32-character hexadecimal MD5 hash that is unique to that string. In this way you can generate a secure key which can be stored and used to check the integrity of the information being sent to (or recieved from) an external server (for example).

      NOTE : There are two formats for the MD5 encoding, UTF-8 and unicode. Both are provided to facilitate communication with different server setups, but the most common to use is unicode.


      Example :
      var hash, str;
      str = base64_encode(game_data);
      hash = md5_string_unicode(str);
      http_get("http://www.McSweeneyGames.com/CatchTheHaggis/gamedata?hash=" + hash); http_get("http://www.McSweeneyGames.com/CatchTheHaggis/gamedata?data=" + str);
      The above code will base64 encode a string and then generate an MD5 hash. Finally, both the hash and the encoded string are sent to a server.


      Spoiler anzeigen
      Returns an MD5 hash for the given file.
      Syntax :
      md5_file(filename)

      ArgumentDescriptionfilenameThe file to generate the MD5 hash for.
      Returns : String
      Description
      In cryptography, MD5 (Message-Digest algorithm 5) is a widely used cryptographic hash function with a 128-bit hash value and has been employed in a wide variety of security applications. It is also commonly used to check the integrity of files and strings. This function will take the given file and generate a unique MD5 for that file which can then be stored for later use.


      Example :
      hash = md5_file(working_directory + "\game_data.ini")
      The above code will generate an MD5 hash for the specified file and store the returned value in the variable "hash".



      auch md5 kann man aus lesen sonst würde das ganze kein sien machen, man muss nur wiesen wie. :D

    • Calystor schrieb:

      auch md5 kann man aus lesen sonst würde das ganze kein sien machen, man muss nur wiesen wie. :D

      Ich verstehe immer noch nicht, was du genau meinst. Wenn du mit "auslesen" meinst, dass man sich einen MD5-Hash von dort, wo man ihn gespeichert hat, wieder holen kann, dann stimmt das natürlich, hat aber nichts direkt mit MD5 oder Verschlüsselung zu tun. Wenn du jedoch meinst, dass man einen MD5-Hash in irgendeiner Weise "dekodieren" kann (wie du es ja in deinem vorigen Post geschrieben hast), so ist das natürlich falsch, wie auch DragonGamer schon erklärt hat. Dass so was nicht möglich ist, sieht man schon alleine daran, dass ein MD5-Hash immer 128-Bit lang ist, unabhängig der Eingabelänge. Was man mit MD5 üblicherweise macht (und du vielleicht auch meinst), ist das Verifizieren von Eingaben, beispielsweise von Passwörtern auf Webseiten. So könnte man beispielsweise nur die MD5-Hashes der Passwörter in einer Datenbank speichern, welche keinen Rückschluss auf das eigentliche Passwort liefern, aber dennoch eine Möglichkeit bieten, zu Prüfen, ob ein eingegebenes Passwort korrekt ist.

      Wenn es LEWA darum geht, die Passwörter wirklich wieder auszulesen, dann ist MD5 ungeeignet. Die XorCrypt DLL, die schon genannt wurde, ist leider nicht wirklich sehr sicher, da sie einfach Byte für Byte verschlüsselt. Schau am besten mal auf gmtoolbox.com/ vorbei. Dort gibt es einige DLLs zum Thema Verschlüsselung. Aber wie schon angesprochen, ist das größte Problem wahrscheinliche der Decompiler. Eine gute Möglichkeit, um diesem aus dem Weg zu gehen, ist das Auslagern von allem Relevanten in eine DLL, also so, dass das Passwort für die Verschlüsselung niemals in den GM gelangt. Also insbesondere sollte es auch keine exportierte DLL-Funktion geben, die einem das Passwort liefert, denn sonst hätte ein Angreifer leichtes Spiel. Diese Methode habe ich beispielsweise für den Online-Highscore in meinem Rennspiel verwendet, zusammen mit einer sicheren Verschlüsselung für die Übertragung, und das Ganze hat sich bis heute bewährt.

    • Bl@ckSp@rk schrieb:

      Also insbesondere sollte es auch keine exportierte DLL-Funktion geben, die einem das Passwort liefert, denn sonst hätte ein Angreifer leichtes Spiel. Diese Methode habe ich beispielsweise für den Online-Highscore in meinem Rennspiel verwendet, zusammen mit einer sicheren Verschlüsselung für die Übertragung, und das Ganze hat sich bis heute bewährt.

      Inwieweit soll ich das verstehen? Du meinst also dass die verarbeitung des Passworts garnicht erst im GM stattfinden soll sondern in der DLL? Vielleicht denke ich da nicht weit genug, aber das würde bedeuten dass die ganze verarbeitung der Dateien (sprich:auslesen der Daten wie Objektpositionen,Map-namen,Serveradresse,server-passwort,etc..) in der DLL zu machen wäre.
      Wie ich jetzt z.B: instanzen die die DLL ausgelesen hat im GM erstellen kann weiss ich nicht. (vielleicht durch eine eigene Funktion die mir die entsprechenden Variablen liefert.) Generell weiss ich nicht wie ich das auf der Technischen seite lösen sollte. Weder Scripttechnisch als auch die umsetzung der DLL. (noch nie DLLs gemacht geschweige denn eine Ahnung wie diese wirklich aufgebaut sind.)
      Ich nehme mal dass DLLsnicht in Java geschrieben werden können.

      Die XorCrypt DLL, die schon genannt wurde, ist leider nicht wirklich sehr sicher, da sie einfach Byte für Byte verschlüsselt.

      Sprich: Ist diese leicht knackbar? So etwas wie die Xor-Crypt DLL würde mir da schon eher liegen da ich damit nicht nur das Passwort sondern auch das gesamte file verschlüsseln könnte (im File natürlich) was somit auch vor Map-hacks/edits schützen würde. (Sprich: Man könnte nicht "einfach so" die Map editieren und sich einen Vorteil gegenüber anderen verschaffen. Ebenso wäre dann das Passwort nicht einfach so aus dem file durch einen editor auslesbar. oder?)

      Die interne verwaltung des Passworts im Spiel hingegen ist da eine etwas andere Sache...

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von LEWA ()

    • LEWA schrieb:

      Inwieweit soll ich das verstehen? Du meinst also dass die verarbeitung des Passworts garnicht erst im GM stattfinden soll sondern in der DLL? Vielleicht denke ich da nicht weit genug, aber das würde bedeuten dass die ganze verarbeitung der Dateien (sprich:auslesen der Daten wie Objektpositionen,Map-namen,Serveradresse,server-passwort,etc..) in der DLL zu machen wäre.
      Wie ich jetzt z.B: instanzen die die DLL ausgelesen hat im GM erstellen kann weiss ich nicht. (vielleicht durch eine eigene Funktion die mir die entsprechenden Variablen liefert.)

      Also ich sollte vielleicht noch erwähnen, dass ich für mein Spiel damals einen großen Teil der Spiellogik in die DLL ausgelagert habe. D.h. das eigentliche Rennen fand in der DLL statt und der GM hat nur noch mehr oder weniger die Grafik dargestellt und Benutzereingaben an die DLL übergeben. Hätte man es nicht so gemacht und beispielsweise nur am Ende eines Rennens die Rundenzeit an die DLL übergeben, welche diese dann verschlüsselt an einen Server gesendet hätte, so wäre das natürlich weit weniger sicher gewesen. Denn in diesem Fall hätte man sich ja ein Programm schreiben können, das sich der DLL zu nutze macht um beliebige Rundenzeiten abzuschicken.

      Da du aber geschrieben hast, dass du dich im Entwickeln von DLLs noch nicht so auskennst, kommt diese Methode für dich wohl eher nicht in Frage. Lassen wir aber mal den Decompiler außen vor, dann sollte es schon einigermaßen sicher sein, das Passwort für die Verschlüsselung einfach im GM zu belassen.

      LEWA schrieb:

      Ich nehme mal dass DLLsnicht in Java geschrieben werden können.

      Ja, mit Java geht das nicht.

      LEWA schrieb:

      Sprich: Ist diese leicht knackbar?

      Soweit ich weiß ist eine einfache XOR Verschlüsselung nur dann sehr sicher, wenn das Passwort mindestens so lang ist wie die zu verschlüsselnden Daten, was natürlich selten der Fall ist. Andernfalls kann man durch die immer wiederkehrende Verwendung des Passworts bei der Verschlüsselung unter Umständen auf dessen Länge schließen und eventuell dann auch auf das Passwort selber. Was auch passieren kann: Wenn du Binärdateien verschlüsselst, die lange Folgen von Nullbytes enthalten, dann steht an diesen Stellen in den verschlüsselten Dateien direkt das Passwort, da eben XOR mit 0 die Daten nicht verändert.

      Ich habe mich jetzt auch mal nach anderen DLLs umgesehen und leider gibt es da gar nicht so viel Auswahl. Die meisten schreiben auch nicht einmal dazu, welchen Algorithmus sie verwenden, sondern behaupten einfach, er wäre sicher. Sollte man sich lieber nicht einfach drauf verlassen.

    • Bl@ckSp@rk schrieb:

      Andernfalls kann man durch die immer wiederkehrende Verwendung des Passworts bei der Verschlüsselung unter Umständen auf dessen Länge schließen und eventuell dann auch auf das Passwort selber. Was auch passieren kann: Wenn du Binärdateien verschlüsselst, die lange Folgen von Nullbytes enthalten, dann steht an diesen Stellen in den verschlüsselten Dateien direkt das Passwort, da eben XOR mit 0 die Daten nicht verändert.
      Ersteres funktioniert soweit ich weiss nur wenn man irgendeinen Anhaltspunkt vom Inhalt hat. Also wenn z.B. menschlicher Text in einer bekannten Sprache übertragen wird. Dann kann man die Verschlüsselung mittels häufiger Buchstaben-folgen angreifen indem man erstmal die Länge bestimmt und dann gezielt Weiderholungen sucht. Das funktioniert aber auf jeden Fall nur bei großen Mengen an verschlüsseltem Material. Wir haben in der Schule mit dieser Verfahrensweise nur mit ziemlich viel mühe ein 6-8 stelliges Passwort anhand eines etwa 15 Seiten Langes Ausschnitts aus einem Roman knacken können (zudem war es nur die vigenere-Verschlüsselung welche meines Wissens nach schwächer ist. Die knack Methode ist aber vergleichbar). Okey, wir waren Amateure, aber..

      Dieses, sowie das Problem mit den Nullstellen sollte man aber zusätzlich durch obfuscating minimieren können. Vieleicht soetwas wie das was Irrenhaus beschrieben hat, verwenden. Es gibt auch noch deutlich einfachere Methoden (wenn du willst kann ich dir ein Skript dazu geben welches einigermaßen geheim ist. Zumindest zweifle ich dass jemand auf die Methode kommen würde.)

      Das Problem hierbei ist allerdings natürlich auch wieder der Decompiler den wohl jeder der einen Angriffsversuch starten will, benutzen wird :/

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

    • DragonGamer schrieb:

      Ersteres funktioniert soweit ich weiss nur wenn man irgendeinen Anhaltspunkt vom Inhalt hat.


      Das wäre ein kleines Problem. Der Punkt ist, dass ich einen Mapeditor open Source machen möchte. Somit kann jeder diesen erweitern als auch den Scriptinhalt anschauen.
      In diesem Editor ist auch der Script zum speichern und laden von (roh-) Maps/dateien vorhanden.
      Was meine Idee war, ist dass man zwar maps mit dem Editor speichern und laden könnte, das Spiel diese aber erst auslesen kann, sobald die Maps verschlüsselt worden sind. (Die verschlüssellung würde durch ein 2tes externes Programm erfolgen)
      Somit könnte nur der Map-ersteller die möglichkeit haben die Map zu bearbeiten.
      Ich dachte es würde genügen wenn die Bytereihenfolge dieselbe wäre blos dass man die Bytes auf irgendeine Weise verschlüsselt. So wie ich das hier lese, würde ich die Sicherheit nur noch mehr gefährden. Muss mir da also was überlegen.
      Man könnte natürlich beim verschlüsseln eine andere Bytereihenfolge nehmen, jedoch würden diese 2 Maprformate (eines verschlüsselt und das andere offen) das erweitern des Codes nur umständlich machen, da ich dann pararell mit 2 Scripts arbeiten müsste.
      Das passwort selber fängt an einer bestimmten Byte stelle an. Die länge wird vom Map-ersteller festgelegt. Evtl könnte ich das Passwort irgendwo weiter ins innere verschieben und deren Anfangsstelle variabel halten, sodass das Passwort dann nichtmehr bei jedem Mapfile an derselben Stelle beginnt, das problem ist dann nur dies, dass der Ladescrpt auf irgendeine Weise mitbekommen muss, wo das Passwort letztendlich anfängt.
      Eine eigene Variable einzusetzen die an einer festen stelle sitzt und die Anfangsposition des Passwortes angibt ist genauso unsicher da mann dann einfach durch eine leichte addition auf die stelle des Passwortes kommen könnte. (die länge selber steht auch bereits als ein wert im File.)

      Man könnte sich die Position anhand von bestimmten gegebenheiten der Map errechnen (z.B: anzahl an entitäten die im File stehen durch 4 teilen und die Zahl aufrunden = Bytestelle im File)
      Aber da der Script zum speichern der Maps ohne verschlüsselung für jeden Offen sein wird, wird der Algorithmus zur berechnung der bytestelle ebenso bekannt sein.


      Dieses, sowie das Problem mit den Nullstellen sollte man aber zusätzlich durch obfuscating minimieren können. Vieleicht soetwas wie das was Irrenhaus beschrieben hat, verwenden. Es gibt auch noch deutlich einfachere Methoden (wenn du willst kann ich dir ein Skript dazu geben welches einigermaßen geheim ist. Zumindest zweifle ich dass jemand auf die Methode kommen würde.)

      den Obfuscator werde ich auf jedenfall nutzen. Das mit dem Skript hört sich interessant an.

      Das Problem hierbei ist allerdings natürlich auch wieder der Decompiler den wohl jeder der einen Angriffsversuch starten will, benutzen wird :/

      Der Decompiler bringt aber nicht wirklich viel, wenn die exe Obfuscated wurde. Der Code wird unlerserlich und somit wird das editieren/herausfiltern der jeweilig kritischen Parts um eine ecke schwieriger.
      Man könnte die exe dann zwar wieder selbst kompilieren, aber das editieren der Scripts wird schwer bis nahezu unmöglich.

      /Edit: bzw. das "Passwort" dass ich immerwieder erwähne ist ein Passwort für einen Server. (nur um evtl Missverständnissen vorzubeugen)

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

    • LEWA schrieb:

      /Edit: bzw. das "Passwort" dass ich immerwieder erwähne ist ein Passwort für einen Server. (nur um evtl Missverständnissen vorzubeugen)

      Oh, das würde ich nie, niemals so in ein GM-Programm einbauen!
      Benutz stattdessen unbedingt den Hash des Passworts!!

      Der Decompiler bringt aber nicht wirklich viel, wenn die exe Obfusacted wurde. Der Code wird unlerserlich und somit wird das editieren/herausfiltern der jeweilig kritischen Parts um eine ecke schwieriger.
      Man könnte die exe dann zwar wieder selbst kompilieren, aber das editieren der Scripts wird schwer bis nahezu unmöglich.

      Dinge wie passwörter kann man allerdings doch halbwegs gut rausfiltern...
      Außer du bedienst dich ein par Tricks wie z.B. 20 verschiedene Variablen quer in verscheidenen Codes verteilt die jeweils einen einzigen Buchstaben/Zeichen des PAsswort enthalten.
      Aber selbst dann kann man ledier per suchfunktion recht einfach die wichtigen Funktionen finden :/

      Fazit: Sicherheit im GM 8.1 ist nahezu unmöglich :/
      Du könntest allerdings einen Teil des Spiels aber in GM 7 oder 8.0 schreiben. Dafür gibt es nämlich den anti-decompiler der angeblich unknackbar ist und auch memory-hacks vorbeugt.

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

    • DragonGamer schrieb:

      Fazit: Sicherheit im GM 8.1 ist nahezu unmöglich :/
      Du könntest allerdings einen Teil des Spiels aber in GM 7 oder 8.0 schreiben. Dafür gibt es nämlich den anti-decompiler der angeblich unknackbar ist und auch memory-hacks vorbeugt.


      Schon langsam bin ich am überlegen ob ich überhaupt onlinefunktionalität implementieren soll.
      Zwar wäre das eines der wichtigeren Features im Spiel, aber was bringt einem eine Online highscore bzw ein online system was ohne großem aufwand gecknackt werden kann?
      Werde da weiter recherchieren müssen. Ansonsten greife ich auf die Xor-Crypt DLL zurück und lese mich ein wenig in die md5 Funktionalität rein. Dannach kann ich nurnoch
      beten dass die Highscores nicht durch Script-Kiddies geschändet werden.

      Auf jedenfall vielen dank für eure Informativen Beiträge. ;)
      Falls ihr noch irgendwelche Vorschläge bezüglich dieser Problematik habt, dann nur her damit. Ansonsten greife ich wie gesagt auf die Xor-Crypt dll zu. (um wenigstens etwas sicherheit zu haben.) Oder lasse die Online funktionalität ganz bleiben.

    • LEWA schrieb:

      Zwar wäre das eines der wichtigeren Features im Spiel, aber was bringt einem eine Online highscore bzw ein online system was ohne großem aufwand gecknackt werden kann?

      Nah, Bl@ckSp@rk's OHS-Dll betreibt ja auch nicht extremen Aufwand und ist wahrscheinlich knackbar. Trotzdem benutzen es ziemlich viele.
      Du musst halt nur etwas Aufwand als "mod" (wenn mans so nennen darf) betreiben und die Idioten löschen wenn sie sich mit Scores ala 99999999 an die Spitze setzen...
      Finde das kann man einem GM-Programmierer zumuten.

      Konzentriere dich zuerst auf die Teile deines Spiels/Programms/Engines welche dem User _nutzen_ oder Spaß machen. Sicherheit sollte bei solchen Dingen immer an zweiter Stelle stehen solang es nicht um Geld, o.ä geht!

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

    • Die meisten werden versuchen mit wenig Aufwand den score manuell zu erhöhen.
      Das heißt den aktuellen score auslesen und dann abändern.

      Ich hätte spontan 2 Ideen:

      Eine doppelte Variable, die ihren wert von einer variable annimmt, welche sich immer wieder in den gleichen wert setzt.
      Schwer zu beschreiben...ich bastel morgen mal ein example.

      Zweite Möglichkeit:
      Den score mit einem zufallswert der beim starten des Spiels generiert wird multiplizieren und am ende beim upload erst wieder abzieht.
      Zb generiert das Spiel zu Anfang 1,602.

      So wird das finden so nicht mehr möglich sein, da der Cheater immer nach dem Uncodierten score suchen wird..

      Oder du bedienst dich der Kryptographie.

      Sorry kanns nicht verlinken, wegen Handy...

      google.de/url?sa=t&source=web&…zhKKXGlCNdDedBoiSnsq9srTg

      Bestimmt digitalisierbar^^
      Versuche mal einige examples zu morgen zu fertigen.

      Edit: falsch verstanden...kein score zum verschlüsseln...aber trotzdem könnte das Dokument helfen :)

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

    • DragonGamer schrieb:

      Ersteres funktioniert soweit ich weiss nur wenn man irgendeinen Anhaltspunkt vom Inhalt hat. Also wenn z.B. menschlicher Text in einer bekannten Sprache übertragen wird. Dann kann man die Verschlüsselung mittels häufiger Buchstaben-folgen angreifen indem man erstmal die Länge bestimmt und dann gezielt Weiderholungen sucht.

      Das stimmt natürlich. Wenn man nur von absolut zufälligen Ausgangsdaten ausgehen kann, dann werden einem diese Wiederholungen nicht helfen. Ich kenne mich auch ehrlich gesagt nicht wirklich gut aus mit dem Knacken von Verschlüsselungen.

      LEWA schrieb:

      Ansonsten greife ich wie gesagt auf die Xor-Crypt dll zu. (um wenigstens etwas sicherheit zu haben.)

      Ja, ist denke ich besser als nichts. Zudem ist es bei Binärdateien sicher schwerer zu knacken als bei reinem Text wo man mit Buchstabenhäufigkeiten arbeiten kann. Nur solltest du wie gesagt lange Folgen gleicher Bytes vermeiden (kann man auch beispielsweise durch RLE sicherstellen).

      DragonGamer schrieb:

      Nah, Bl@ckSp@rk's OHS-Dll betreibt ja auch nicht extremen Aufwand und ist wahrscheinlich knackbar. Trotzdem benutzen es ziemlich viele.

      Richtig. Ist leider schon vorgekommen, dass es geknackt wurde. Aber wie ich vermute vor allem durch den Decompiler. Ansonsten hat man aber auch noch die Möglichkeit, entsprechende Variablen im RAM zu ändern, um sich z.B. mehr Punkte zu verschaffen. Um das zu verhindern, hilft es, mehrere Variablen zu verwenden und diese immer miteinander zu vergleichen, wie es BaZZ schon beschrieben hat.

    • ich hab jetzt nicht den ganzen thread gelesen und hoffe einfach mal das hat noch keiner gesagt:
      wie wärs wenn du über ein extra programm eine datei mit serverpasswort auf das aktuelle hash der exe verschlüsselst? so kann wenns wirklich open source ist der serer nach dem bearbeiten nicht mehr aufgerufen werden... (klar das ist alles manipulierbar, sollte aber den durchschnitts gm-kiddie abhalten)