Is it possible to make a script unchangeable?

[??????]

Probably not, cause it can still be modified and changed, and is still visible.

It may deter a fair few folk from trying to figure it out though.

 

[Andar]

Actually there is a way. You can create a dll to call ruby code from inside it - after it's compiled, your code is safe. 


There's an example on how to call ruby code from inside a dll here.


Writing custom dlls may seem complex, but it's not that hard. Here's a tutorial on how to do that.

THIS IS A BREACH OF EULA - DO NOT PERFORM THIS TECHNIQUE

Actually, only the specific example of the first link is a breach of the EULA, not the described process in general.


The breach of the EULA is because a function inside the RM's dll is called - if someone writes a dll with his own functions, not emulating or replacing the RGSS301.dll, then that other dll can be safely and legally used.


So if you use that link as an example only but use the function described with your own dll as target, then that is legal as long as the targeted dll is legally your own (or you can use it legally, something you're not allowed to do with RM's libraries)

 

[Khas]

Interesting. I was not aware that using those functions would be against EULA (it seems to be, in fact, reverse engineering), there's a lot of people who use this technique. But I removed the link, thanks!

Since all the Ruby code must be evaluated inside RPG Maker (legally), I can't think of a 100% safe way to protect your script. It's only a matter of the possible hacker figuring out what you did.

 

[Andar]

Interesting. I was not aware that using those functions would be against EULA (it seems to be, in fact, reverse engineering),

Yes, exactly that is the problem. Reverse-Engineering Ace is forbidden by the EULA, and to use the direct function calls you need data that can only be produced by reverse engineering - because Enterbrain never published this documentation. The fact that others have done the reverse engineering does not make the infos legal to use, so you can't use them legally even if you manage to find the documentation on the internet.

 

[??????]

@Ander - Oh yea, that is what I meant.  Its the use of the RGSS301.dll's functions that is the EULA breach, not the use of dll's in general.

@Khas - As mentioned, look into extending the RGSS library using a .so extension.  Its fairly similar to writing a dll, except as far as i know, nothing is breaching the EULA. 

https://dekitarpg.wordpress.com/2014/11/23/extending-rgss-ruby-with-c/

 

[Tsukihime]

Interesting. I was not aware that using those functions would be against EULA (it seems to be, in fact, reverse engineering), there's a lot of people who use this technique. But I removed the link, thanks!


Since all the Ruby code must be evaluated inside RPG Maker (legally), I can't think of a 100% safe way to protect your script. It's only a matter of the possible hacker figuring out what you did.

You're not limited to RPG Maker itself.


You can run external programs as well and move your code there: http://forums.rpgmakerweb.com/index.php?/topic/25345-running-your-game-using-a-custom-launcher/


This would then require hackers to figure out how you wrote that client.


You could even potentially make it so that the client sends some data to RPG Maker and RPG Maker uses that data somehow to verify that this is a legit client.

 

[Khas]

@Andar 
Agreed. It's very known over the web that modifying the executable and the original dlls is against the EULA, but this is the first time I see someone bringing up the "reverse engineering" problem. There are several scripts out there breaking these terms.

@Dekita
Thanks for the info! I will take a look

@Tsukihime
Since it's sending data to RPG Maker, can't someone access this data and the used method to verify the launcher?

 

[Tsukihime]

@Tsukihime


Since it's sending data to RPG Maker, can't someone access this data and the used method to verify the launcher?

They could. I don't know how, but I'm assuming it is trivial for anyone that knows what they're doing to insert breakpoints with a debugger whenever data is being transmitted from one application to another.


There may be some techniques that can be used with external programs to enhance security though.


Currently the main issue is the RM encryption being broken and tools circulating, so if you just change it up a little...

 

[??????]

Here is something you can do to make it a little harder...

Have all your scripts stored in an alternative scripts.rvdata file. Perhaps rename it 'MyScripts'  Then put this snippet at the top of your script editor... (above ALL other scripts)

$RGSS_SCRIPTS.clear$RGSS_SCRIPTS = nil$RGSS_SCRIPTS = load_data("Data/MyScripts.rvdata2").inject([]) do |r,i| r << [*i.shift(2),i.first,Zlib::Inflate.inflate(i.shift)]endWhat this does is wipe the $RGSS_SCRIPTS variable before it is properly initialized, then it replaces all the scripts with whatever scripts are contained in the 'MyScripts' file.

This would mean that in order to gain access to see your script, you have to print out all of the scripts individually ~ also, it means that the scripts used for the game are not contained within the script editor, so when hacked open, all they see is the above snippet.

Feel free to tell me how awesome I am for figuring out how they initialize the default scripts ^_^

 

[Tsukihime]

White-Flute's crypt-EX used the same approach for encrypting their scripts.


Which made it REALLY easy to get the resources because it was pretty obvious what it's doing if I can read the code myself.


Later iterations of their system used a DLL call to initialize the scripts, but the problem here is that everything is still loaded into $RGSS_SCRIPTS, so that doesn't really work.

 

[??????]

Yea, i do agree it leaves the resources fairly open for theft, but it would at least hide the scripts from the editor.  Could also conceal the code in a common class to try hide it a little more.

Didnt know whiteflutes system used that approach. Been a while since i even thought of that system. Certainly good info to know though

So their later versions, it evals a string or something to do the same thing as exampled above?

 

[Tsukihime]

I don't know how the later versions worked.


They eval'ed a string, but the string was just a DLL call and it somehow loaded all the scripts into a ruby variable.

 

[??????]

Yea, they likely just returned a string from the dll call. One of Esitroles scripts do this too which leave them really vulnerable, cause you can literally open the dll in notepad and see the code that gets evaled... Not ideal at all :/

but using the above snippet i gave, it would mean that the person hacking would have to firt figure out that the scripts are actually being loaded from elsewhere, then, they have to figure how to make the changes to allow them access to the real scripts.  I mean, its not really hard, but I imagine for someone with 0 knowledge of ruby, it could be somewhat tricky.  Alternatively, loading a .so that does the above example would make things that bit safer again

 

[Khas]

The method Dekita suggested is simple but effective. I think people that would steal a script can't code at all - that means they want an easy way get access to other people's scripts, like an one-click "decrypter" (I don't know if this word exists lol). So, if you block them from seeing the scripts by just opening the script editor after a decryption, I would say that your code is safe from a lot of thieves. Also, advanced coders prefer to write their own code. Unless it's very sensitive data, the risk level is manageable.

 

[Engr. Adiktuzmiko]

And we could also embed that extra script file into another file and make a hidden extraction script before it's even loaded... Or maybe even a few "false" methods inserted into the loading scheme would make them shy away more from touching it.

Just don't try to Marshal.dump things as a string, coz it just adds some things to the strings so it's still readable by normal people.