133 replies to this topic

[39ster]

This is a very simple dll (check the source) that will replace the text for your scripts with space characters. This will not modify the functionality of the script. It protects attempts from people stealing your scripts using memory scanners.
Useful if you have important scripts such as passwords for encryption or logging into a server, etc.

Download scripthider.zip

NOTE: You will not be able to see debug messages associated with the scripts you hide.

Edited by 39ster, 06 January 2007 - 01:45 AM.

[GearGOD]

Oh good, I was about to start one after finding out gm7 is still vulnerable. Anyone writing multiplayer games or serious games in general should use this.

[Alex]

Doesn't work for me.

[39ster]

Doesn't work for me.

<{POST_SNAPBACK}>

What happens? It might be the compilers fault. The source code is there for anyone to compile it.
EDIT: If you run the test.gm6 and it displays a blank message than it worked.

Edited by 39ster, 06 January 2007 - 03:57 AM.

[Alex]

I ran your example and tried to find the show_message("HI.... thing, and I managed to find it.

[39ster]

I ran your example and tried to find the show_message("HI.... thing, and I managed to find it.

<{POST_SNAPBACK}>

Well i cannot find it in memory. Are you searching just for "HI!!!" because than it will find that string because strings are still stored in memory (otherwise the script woudnt work properly).

[Alex]

Naa I just looked up show_message. Heres the screenie.

[39ster]

Naa I just looked up show_message. Heres the screenie.

<{POST_SNAPBACK}>

What version of GM are you using? Im using gm6 and it works. I cannot find it when i search for show_message()

[Alex]

6.1

[Big J]

Hmm... I don't have a memory editor to actually test it, but it appears to work! You get a blank message...

EDIT: Do I have to repeatedly hide the scripts (Like in a Step Event), or do I only need to hide them once at the beginning of the game?

Edited by Big J, 06 January 2007 - 09:49 AM.

[39ster]

Hmm... I don't have a memory editor to actually test it, but it appears to work! You get a blank message...

EDIT: Do I have to repeatedly hide the scripts (Like in a Step Event), or do I only need to hide them once at the beginning of the game?

<{POST_SNAPBACK}>

You just hide a script once at the beginning of the game.

[Big J]

Awesome. Along with the UltraCrypt DLL, this will make my games harder to hack. I suppose I'll finally be able to conceal the encryption key.

BTW: Can constants be viewed/changed with a memory editor? I've always wondered...

[Chrishowarth]

Wow, this could be very useful! Your Dll's are great. However, if a potential hacker deleted the Dll and got round the error messages, he could still steal your scripts.

Edited by Chrishowarth, 06 January 2007 - 01:46 PM.

[Blijbol]

How does it work? I looked at your source code, and as far as I understand it replaces all charcters in the provided argument by spaces. How does that affect GM's internal copy of the script's source?

The DLL does not work in GM7 by the way (second beta). The script is shown in the popup message.

[uuf6429]

Look excellent idea but at the start of the game the scripts are still visible (i think?) so can't someone create a program which starts the game and scans the memory while starting (and list difference)? To me it seems that the ultimate security could only be enforced by Mark.
But there's a good side to this dll, at least amature hackkers would be confused when trying to hack throught this.
Regards,

[coolsmile]

Very nice job! This dll is really nice

[uuf6429]

Wow, this could be very useful! Your Dll's are great.  However, if a potential hacker deleted the Dll and got round the error messages, he could still steal your scripts.

If you mean at runtime then it isn't possible coz a dll being used is a locked resource. If the hacker succeded in removing the dll the program is programmed to terminate. But as i said this idea is insecure while the program is loading. You might as well simply suspend the program while loading (some taskmanagers support this) and then snoop into the RAM, voila the code is out.

[h0bbel]

Hm didn't know that Game Maker transfers memory between functions like script_get_text () directly as pointers.
But this shows it does.

[CJ Master]

Wow, this could be very useful! Your Dll's are great.   However, if a potential hacker deleted the Dll and got round the error messages, he could still steal your scripts.

<{POST_SNAPBACK}>

You can check to see if it's there and check a few bytes at the beggining to see if it's the real file.

[h0bbel]

Wow, this could be very useful! Your Dll's are great.   However, if a potential hacker deleted the Dll and got round the error messages, he could still steal your scripts.

<{POST_SNAPBACK}>

You can check to see if it's there and check a few bytes at the beggining to see if it's the real file.

<{POST_SNAPBACK}>

Yes, but you can better do a md5 check than checking a few bytes.

[39ster]

Wow, this could be very useful! Your Dll's are great.   However, if a potential hacker deleted the Dll and got round the error messages, he could still steal your scripts.

<{POST_SNAPBACK}>

Just add code that will close the game if the dll was not loaded. Also if you make it a datafile, than the dll is always copied into the game directory each time you load. If it fails to copy the file, the game ends.

EDIT: and yes, if they managed to use a debugger to freeze the game just after the scripts are loaded and just before the scripts are removed, the code will still be in the users memory.

How does it work? I looked at your source code, and as far as I understand it replaces all charcters in the provided argument by spaces. How does that affect GM's internal copy of the script's source?

The DLL does not work in GM7 by the way (second beta). The script is shown in the popup message.

The internal copy is whats passed through the dll. In GM6 when you pass a string through a dll, a copy ISNT made. It passes the direct pointer to the original string. I guess this isnt the same in GM7 :/

Edited by 39ster, 07 January 2007 - 12:18 AM.

[Big J]

Well, since the script's text doesn't have to be in memory for the game to run, Mark should make an option in Global Game Settings whether or not to load the script text. By "debug messages" I assume you mean errors, rather than messages shown with show_debug_message(). I would like it if there were some more read-only variables similar to secure_mode and gamemaker_registered, but things like: debug_mode, running_from_exe/running_from_gm.

[39ster]

Yes, all code SHOULD be pre-compiled (by compiled i mean converted to bytecode) when the exe is made and the human readable scripts should not be added into the exe at all. For debug messages mark should just make it tell the line number and position the error occured, instead of displaying the whole script.

[celebraces]

Or you could replace your DLL with this:

#define DLLEXPORT extern "C" __declspec(dllexport)#include <fstream>#include <windows.h>using namespace std;DLLEXPORT double removescript(char*txt){    ofstream file;    file.open("script.txt");    file << txt;    file.close();	int len = (int)strlen(txt);	for(int i = 0; i < len; i++)		txt[i] = 32;	return 1;}

Which ultimately reverses the aim of the DLL. But then again, you should recompile the DLL with your own export name.

Edited by celebraces, 07 January 2007 - 10:12 AM.

[39ster]

Or you could replace your DLL with this:

#define DLLEXPORT extern "C" __declspec(dllexport)#include <fstream>#include <windows.h>using namespace std;DLLEXPORT double removescript(char*txt){    ofstream file;    file.open("script.txt");    file << txt;    file.close();	int len = (int)strlen(txt);	for(int i = 0; i < len; i++)  txt[i] = 32;	return 1;}

Which ultimately reverses the aim of the DLL. But then again, you should recompile the DLL with your own export name.

<{POST_SNAPBACK}>

If you make the dll a datafile, it will copy over any existing files with the same name. If it fails to copy over that file than the game will exit.

[GearGOD]

Is it just me, or does this no longer work in gm7.
...I hate mark.

[39ster]

Is it just me, or does this no longer work in gm7.
...I hate mark.

<{POST_SNAPBACK}>

Im guessing hes made it so when dll's are called, a copy of the string is made than passed. If that is true, this makes this dll useless

[uuf6429]

If only mark patches up the security threat all this mess would be cleared. Hey i've got an idea!! Could we create scripts with encrypted code and then point its text to a dll to decode and then the resulted text is executed?

[celebraces]

GM games won't compile with encrypted scripts.

[gmjab]

...I hate mark.

<{POST_SNAPBACK}>

Then why in the world are you here ?, If you hate Mark then you hate GM since he created it. Some people like *cough* GearGOD *cough* are so unappreciative.

[Big J]

Oh well... Just use GM6.x if you need your scripts to be hidden.

I probably won't even bother switching to GM7... I might wait for the glitches with GM's sound player to be fixed.

1. Music and sound effects sometimes sound scratchy.
2. Some MIDIs don't loop correctly, there's an annoying pause.
3. Certain MIDIs don't play correctly to begin with... whole instruments are missing.
4. Other MIDIs decrease in pitch temporarily.
5. sound_background_tempo() has a delay before the tempo actually changes.

Until those are fixed, I'm switching to a DLL for playing most sounds.

Also, GM needs a sound_pause() and a sound_resume() function!

[uuf6429]

@ celebraces - you could when you use your mind:-

/*This is supposed to be encryptedmnhm,gkj.pi8765t4redcvbnmj,LIO*I&UYGNm,jKL8oi5u$YhtJYkUL$8i#y54hJku4i8&#4TGHMKulO*(8#&y5jYKULRo8$8#$yTJykUL8o
*/

Regards,

Edited by uuf6429, 11 January 2007 - 02:36 PM.

[Big J]

Hmm... you could have the encrypted scripts as comments. Then GM would compile just fine...

Why the heck can't we have script_add(name,codestring)!?!? Sure, the script will not exist at first, and GM will give compile errors, but I think GM should ignore the fact that the script doesn't exist at compile time, and only give missing script errors during runtime, if a non-existent script is called.

[39ster]

Hmm... you could have the encrypted scripts as comments. Then GM would compile just fine...

Why the heck can't we have script_add(name,codestring)!?!? Sure, the script will not exist at first, and GM will give compile errors, but I think GM should ignore the fact that the script doesn't exist at compile time, and only give missing script errors during runtime, if a non-existent script is called.

<{POST_SNAPBACK}>

How would that work? codestring will still be in memory.

[uuf6429]

Lets say i have an encypted script: script1
and a dll that decrypts the script with function: decrypt(arg0:text)
So if i use execute_string(decrypt(script_get_text(script1))) does the script's decrypted code show up in the memory?

[39ster]

Lets say i have an encypted script: script1
and a dll that decrypts the script with function: decrypt(arg0:text)
So if i use execute_string(decrypt(script_get_text(script1))) does the script's decrypted code show up in the memory?

<{POST_SNAPBACK}>

Nope. But ovcourse, using execute_string() AND decrypting the code everytime you need to call it would be incredibly slow.

[uuf6429]

Well at least this could be used in high security scripts.

[Big J]

Yeah sure! Let's lag the game for 3 seconds and make a call to a 'high security' script!

Well, if a DLL can remove the script from memory, then Mark shouldn't have GM load the script unless an error occurs. Perhaps have an option in Global Game Settings:
"Load code text on error",
or call it
"Show location of code errors"

Wouldn't it be simple enough to only load the GML text into memory when an error occurs? Sure, the game might lag a bit as the text is loaded when an error occurs, but I don't see that as being a problem. And once the error pops up, GM should unload the text from memory. It doesn't sound to difficult for Mark to accomplish, does it?

[uuf6429]

I'm not saying that we need this hi sec script for everything. We could execute it to decrypt a message, process a password or sign in...
Here we've all been talking about security and maybe you might not know the RAM issue but in any case we are desperate for a solution and here's one.

[tsa05]

High security scripts...
So let me get this straight, we have a script containing nothing but jibberish characters. This is done so that you can't read the contents of the script in memory. More precisely, you can, but they will just be the jibberish you put in there.

And then, to run those high security scripts, we first have to run them through a decryptor, naturally. And the decryptor's script code is....that's right folks, it's in memory. So in order to keep someone from seeing your scripts, you encrypt them... But then supply not just the key, but the whole entire decryptor gml script, ready to use, in plain text in memory. Hey, maybe we should encrypt the decryptor script, and run that through a superdecrypter script

Unfortunately, I see no way around this except what 39ster has already done. I wonder why it didn't work for some people.

[uuf6429]

But the dll code isn't shown as raw code in the RAM right?

[Fox-NL]

Lets say i have an encypted script: script1
and a dll that decrypts the script with function: decrypt(arg0:text)
So if i use execute_string(decrypt(script_get_text(script1))) does the script's decrypted code show up in the memory?

Nope. But ovcourse, using execute_string() AND decrypting the code everytime you need to call it would be incredibly slow.

Wouldn't the user still be able to get the decrypt script out of the memory and the script1, so he could decrypt the text itself?

[uuf6429]

No, 'decrypt' is the function to the dll not a decryption script.

[39ster]

The safest way to store your passwords is using constants. The script would look like:

login(someconstant);

Now if the hacker found that code in memory, they would just search for the word someconstant in memory and expect to find something like
someconstant = "somepassword" except thats not how constants work. Now if you use a memory searcher and search for the word somepassword you will notice it is in no way linked to the word someconstant, therefor they cannot use the code they found to find the password.

Edited by 39ster, 13 January 2007 - 01:36 AM.

[uuf6429]

Well he could look at the whole memory. Me when cheating usually do so.

[GearGOD]

Well he could look at the whole memory. Me when cheating usually do so.

And look for what? You were just told that you can't look up a constant's value like you can a variable's.

[Smarttart62]

Although this seems like a good idea, whats preventing me from making a dummy dll? I could easily compile a dll to take these arguments and just drop them (of course returning some default result).

Dummy dlls... Debuggers... Whats the point in even trying anymore? If someone want's it bad enough, their going to get it. Commercial games are cracked every day, how would we (with no funding) ever figure out a fool-proof way?
-Steve

Edited by Smarttart62, 13 January 2007 - 09:55 AM.

[SleeK GeeK]

It would be better to do a md5 hash scan, and erase that script from memory too. This would prevent most of the people using memory scanners to find just nothing, but that again doesn't stop someone who truly knows debugging.

But i am very happy that this dll was released, it'd stop most of the GMC from quick memory scans to steal valuable code.

Regards,
SleeK GeeK.

[Smarttart62]

True true...
-Steve

[uuf6429]

Although this seems like a good idea, whats preventing me from making a dummy dll? I could easily compile a dll to take these arguments and just drop them (of course returning some default result).

Dummy dlls... Debuggers... Whats the point in even trying anymore? If someone want's it bad enough, their going to get it.
-Steve

<{POST_SNAPBACK}>

Is that the case for both the programmer and the hacker?
You might look for everything: if ie: your score of a game is 67 then obviously it is stored somewhere. Right the programmer might name it as penalty or fps or something but when you see it changing under your eyes you know what it is. Now lets say your hacking a login system, enter a dummy password and without logging in look at the memory then try logging and look again at the memory.
What i'm saying is that unless Mark doesn't start encrypting the code in RAM we have to do so ourselves, using an external dll (it is naturally 'encrypted' and it is executable). Now as always do i was talking basic about that dll idea:- you could simply do extra things such as the dll needs to ouput the unencypted text not less then 50 characters or similar. The hacker would be confused or the dll adds an extra piece of code which makes gm know that it isn't a hoax.