Deployment Protection in RPGMV

[MusicalSamurai]

I have two concerns with RPGMV... I'll first mention the least annoying and then move on to my most pressing issue.

1. RPGMV Deployment with 'Exclude Unused Files" ticked will completely ignore Images, Music & Sounds that have been referred to Programmatically (such as a custom plugin) - This is of course only a minor bug-bear because one can spend a bit of time finding the original resources and adding them back in (with the exception of when you decide to Encrypt your files, it wouldn't be good to simply plop unencrypted files amongst the encrypted ones)...
- My cumbersome approach is to deploy it twice: Copy A will be "Encrypted" with "Exclude Unused" and Copy B will be "Encrypted" but not excluding unused files. I then flick between the two, copying over any missing encrypted files from B to A so that then Copy A is fully working and still "minimalistic".

My question to this being: Is there a better way to do this?

2. Deploying my game in MV with the 'Encrypted' feature does nothing to stop the JSON data files from being openly abused via simply editing them in Notepad... I am also helping a friend with his VX game and I notice his deployed Data files are .rvdata2 files; and whilst these are not invincible to abuse via more advanced means, they immediately deter anyone handy with Notepad... Why is this not the case for MV?

I was very happy with MV with the past 10 years of working on my game 'on and off' - I was ready to start giving my game out to people, deployed it for the first time and scooted about the deployed files to see how everything got packed up... This is when I discovered the vulnerable JSON Data files that completely repelled me from the idea of sharing my game publically.

(Because one can freely edit a deployed game's enemies, exp, item costs, discover how maps relate, switches, variables, etc etc and I think this is an overwhelming flaw in data protection)...

And here's the funny thing! - I don't even care if my JS Plugins can be opened & read by a human, because they don't hint at anything 'in the game' - but the Data JSON files I really think should have a method to make them not so blindingly easy for anyone to edit - only the game needs to understand the data, not any person...

I had a quick play with various Obfuscation tools, but of course changing code structure when the engine is expecting it to be a certain way is not working for me...

So my question to this being: Is there any way to stop a human 'easily' reading the JSON files without breaking it for MV's engine?
Because this is my biggest depression with MV and I could never trust a deployment that reveals so much of a game's inner mechanics... It's either I find a fix to this, or my game will forever remain solely between friends & family.

Apologies on the huge post, but these are two things that have bugged me for quite some time and only now have I realised this is probably the best place to ask - any light on these issues will be greatly appreciated!

Kindest Regards:
- Musical Samurai

 

[Poryg]

RPGMV Deployment with 'Exclude Unused Files" ticked will completely ignore Images, Music & Sounds that have been referred to Programmatically (such as a custom plugin) - This is of course only a minor bug-bear because one can spend a bit of time finding the original resources and adding them back in (with the exception of when you decide to Encrypt your files, it wouldn't be good to simply plop unencrypted files amongst the encrypted ones)...
- My cumbersome approach is to deploy it twice: Copy A will be "Encrypted" with "Exclude Unused" and Copy B will be "Encrypted" but not excluding unused files. I then flick between the two, copying over any missing encrypted files from B to A so that then Copy A is fully working and still "minimalistic".

As far as I know, there should be a way to include filenames inside plugins, which will tell the RM to keep the files in there. I'm not sure which one is it though as I don't use MV's default deployment methods. But if I remember, it's been introduced with MV 1.5.1 among other features of the new Plugin manager.

Deploying my game in MV with the 'Encrypted' feature does nothing to stop the JSON data files from being openly abused via simply editing them in Notepad... I am also helping a friend with his VX game and I notice his deployed Data files are .rvdata2 files; and whilst these are not invincible to abuse via more advanced means, they immediately deter anyone handy with Notepad... Why is this not the case for MV?

Simply put: There's no point in doing so.
VXAce's engine is proprietary. And its decryption is already one google search away. MV is open-source, shared under MIT license. So had these files been encrypted, there'd need to be a method to decrypt them. And with open-source engine there's no need to even reverse engineer it, because the code is human readable. Making a project decrypter would therefore be even easier than in VXAce.
In fact, and it's not a secret, even MV's resource encryption is absolutely atrocious, although it is better than it was prior to 1.5.1. But there really is no need for a better one for the very same reason. Even AES-256 (military-grade) encryption would stand no chance due to the 100% open-source nature of MV.

 

[LTN Games]

1. The way to make sure images used in plugins are not excluded is to setup the parameters correctly, this is explained the in the Help documentation of the editor.

2. You should not have any issues with obfuscation after the game is deployed, but if you do it while developing it, every time you make a change in the editor it will revert back to the default, or the editor will have issues saving it at all. Have you tried obfuscation and minimization after deployment?

Simply put: There's no point in doing so.

If only it could be simply put, it seems to me the OP is not really worried about hackers, or people who know how to code and perform un-obfuscation. But more about prying eyes who can easily ready the property names in the JSON and freely change them. In this situation, obfuscation I would say is perfect, it would stop those who know nothing about code, hacking, and have no interest ion learning how to do so(which is surprisingly a lot) these people will open the file up, see it gibberish and close it most likely.

 

[MusicalSamurai]

As far as I know, there should be a way to include filenames inside plugins, which will tell the RM to keep the files in there. I'm not sure which one is it though as I don't use MV's default deployment methods. But if I remember, it's been introduced with MV 1.5.1 among other features of the new Plugin manager.

I am on version 1.6.2 or 1.6.3? Something like that - I didn't personally notice any ways to specify custom files - although now you have mentioned it I will surely look about a bit harder! - Although in all fairness I do not see this as a big problem, just an annoyance... So many thanks for this clarification!

Simply put: There's no point in doing so.
VXAce's engine is proprietary. And its decryption is already one google search away. MV is open-source, shared under MIT license. So had these files been encrypted, there'd need to be a method to decrypt them. And with open-source engine there's no need to even reverse engineer it, because the code is human readable. Making a project decrypter would therefore be even easier than in VXAce.
In fact, and it's not a secret, even MV's resource encryption is absolutely atrocious, although it is better than it was prior to 1.5.1. But there really is no need for a better one for the very same reason. Even AES-256 (military-grade) encryption would stand no chance due to the 100% open-source nature of MV.

Of course I fully understand and appreciate this - although perhaps I wasn't so clear in my initial wording, as I have no interested in "Encryption" - Please notice that I purposely tried to avoid the word "Encrypt" as I have worked with encryption and I'm aware of the caveats and I do feel this is beyond overkill for what I'm after - I'm only interested in mere "Obfuscation" (just to be slightly resistive to a plain text editor) - if someone is smart enough to break open the code and reverse engineer my game, then so be it, I will applaud them! But my specific issue is that MV supplies a way to encrypt Images/Sound (why?) But not even simple means to make the Data Files harder for humans to simply edit on a whim...

It seems far less detrimental to me for someone to obtain/extract any of my art or music than it is for them to so easily see and edit the inner game mechanics.

I'm presuming even under my clarification of definition that your answer will be the same... If this is the case and it cannot be done under any circumstances, then this is truly a sad day for myself.

I thank you for your input, nontheless!

 

[MusicalSamurai]

1. The way to make sure images used in plugins are not excluded is to setup the parameters correctly, this is explained the in the Help documentation of the editor.

Clearly I am blind - my first responder also mentions this - I need to pay more attention to what options I have available - but I'm quite sure I didn't see this option, unless I have a bugged version or something - I'll try a uninstall and reinstall tonight and test this. Many thanks!

2. You should not have any issues with obfuscation after the game is deployed, but if you do it while developing it, every time you make a change in the editor it will revert back to the default, or the editor will have issues saving it at all. Have you tried obfuscation and minimization after deployment?

I'm not sure how to interpret what you have written here, but to skim to the last part; Yes I have tried Post-Obfuscation but my methods break the JSON every time to the point MV complains about it.

If only it could be simply put, it seems to me the OP is not really worried about hackers, or people who know how to code and perform un-obfuscation. But more about prying eyes who can easily ready the property names in the JSON and freely change them. In this situation, obfuscation I would say is perfect, it would stop those who know nothing about code, hacking, and have no interest ion learning how to do so(which is surprisingly a lot) these people will open the file up, see it gibberish and close it most likely.

This is exactly correct! and exactly what I'm looking for - although have yet to find a true solution...

 

[Poryg]

@LTN Games Well, I haven't found it in the help either I know I've seen it online somewhere though.

If only it could be simply put, it seems to me the OP is not really worried about hackers, or people who know how to code and perform un-obfuscation. But more about prying eyes who can easily ready the property names in the JSON and freely change them. In this situation, obfuscation I would say is perfect, it would stop those who know nothing about code, hacking, and have no interest ion learning how to do so(which is surprisingly a lot) these people will open the file up, see it gibberish and close it most likely.

Well, everybody can open it. But how many people can read it?
Without the RPG maker not too many.

Here's for example one of the default classes of MV.

{"id":1,"expParams":[30,20,30,30],"traits":[{"code":23,"dataId":0,"value":1},{"code":22,"dataId":0,"value":0.95},{"code":22,"dataId":1,"value":0.05},{"code":22,"dataId":2,"value":0.04},{"code":41,"dataId":1,"value":0},{"code":51,"dataId":2,"value":0},{"code":52,"dataId":1,"value":0},{"code":52,"dataId":3,"value":0},{"code":52,"dataId":5,"value":0}],"learnings":[{"level":1,"note":"","skillId":8},{"level":1,"note":"","skillId":10}],"name":"Hero","note":"","params":[[1,450,500,550,600,650,700,750,800,850,900,950,1000,1050,1100,1150,1200,1250,1300,1350,1400,1450,1500,1550,1600,1650,1700,1750,1800,1850,1900,1950,2000,2050,2100,2150,2200,2250,2300,2350,2400,2450,2500,2550,2600,2650,2700,2750,2800,2850,2900,2950,3000,3050,3100,3150,3200,3250,3300,3350,3400,3450,3500,3550,3600,3650,3700,3750,3800,3850,3900,3950,4000,4050,4100,4150,4200,4250,4300,4350,4400,4450,4500,4550,4600,4650,4700,4750,4800,4850,4900,4950,5000,5050,5100,5150,5200,5250,5300,5350],[0,90,100,110,120,130,140,150,160,170,180,190,200,210,220,230,240,250,260,270,280,290,300,310,320,330,340,350,360,370,380,390,400,410,420,430,440,450,460,470,480,490,500,510,520,530,540,550,560,570,580,590,600,610,620,630,640,650,660,670,680,690,700,710,720,730,740,750,760,770,780,790,800,810,820,830,840,850,860,870,880,890,900,910,920,930,940,950,960,970,980,990,1000,1010,1020,1030,1040,1050,1060,1070],[1,16,18,19,20,21,23,24,25,26,28,29,30,31,33,34,35,36,38,39,40,41,43,44,45,46,48,49,50,51,53,54,55,56,58,59,60,61,63,64,65,66,68,69,70,71,73,74,75,76,77,79,80,81,82,84,85,86,87,89,90,91,92,94,95,96,97,99,100,101,102,104,105,106,107,109,110,111,112,114,115,116,117,119,120,121,122,124,125,126,127,129,130,131,132,134,135,136,137,138],[0,16,18,19,20,21,23,24,25,26,28,29,30,31,33,34,35,36,38,39,40,41,43,44,45,46,48,49,50,51,53,54,55,56,58,59,60,61,63,64,65,66,68,69,70,71,73,74,75,76,77,79,80,81,82,84,85,86,87,89,90,91,92,94,95,96,97,99,100,101,102,104,105,106,107,109,110,111,112,114,115,116,117,119,120,121,122,124,125,126,127,129,130,131,132,134,135,136,137,138],[0,16,18,19,20,21,23,24,25,26,28,29,30,31,33,34,35,36,38,39,40,41,43,44,45,46,48,49,50,51,53,54,55,56,58,59,60,61,63,64,65,66,68,69,70,71,73,74,75,76,77,79,80,81,82,84,85,86,87,89,90,91,92,94,95,96,97,99,100,101,102,104,105,106,107,109,110,111,112,114,115,116,117,119,120,121,122,124,125,126,127,129,130,131,132,134,135,136,137,138],[0,16,18,19,20,21,23,24,25,26,28,29,30,31,33,34,35,36,38,39,40,41,43,44,45,46,48,49,50,51,53,54,55,56,58,59,60,61,63,64,65,66,68,69,70,71,73,74,75,76,77,79,80,81,82,84,85,86,87,89,90,91,92,94,95,96,97,99,100,101,102,104,105,106,107,109,110,111,112,114,115,116,117,119,120,121,122,124,125,126,127,129,130,131,132,134,135,136,137,138],[0,32,35,37,40,42,45,47,50,52,55,57,60,62,65,67,70,72,75,77,80,82,85,87,90,92,95,97,100,102,105,107,110,112,115,117,120,122,125,127,130,132,135,137,140,142,145,147,150,152,155,157,160,162,165,167,170,172,175,177,180,182,185,187,190,192,195,197,200,202,205,207,210,212,215,217,220,222,225,227,230,232,235,237,240,242,245,247,250,252,255,257,260,262,265,267,270,272,275,277],[0,32,35,37,40,42,45,47,50,52,55,57,60,62,65,67,70,72,75,77,80,82,85,87,90,92,95,97,100,102,105,107,110,112,115,117,120,122,125,127,130,132,135,137,140,142,145,147,150,152,155,157,160,162,165,167,170,172,175,177,180,182,185,187,190,192,195,197,200,202,205,207,210,212,215,217,220,222,225,227,230,232,235,237,240,242,245,247,250,252,255,257,260,262,265,267,270,272,275,277]]},

Of course some are more readable than others, like states and skills are probably the most readable of the stuff. And the least readable are maps. But with the less readable ones you need to know what you're doing.

Nevertheless, it's not impossible to encrypt or obfuscate or whatever. The engine is 100% open-source, so that means after deployment you can edit the files as you wish as long as you also make the appropriate edits inside of the Javascripts. For example this is a portion of the Classes.json after I ran it through a basic base64 compression:

NoKAdgrgNlA0IG8BEBLAJkgXARlkgpgB4AOACgIYBO5AtgM5bADMADLAExuuysC6eAF2ooBDTMGQBjAPZp8Wdkz

And it wouldn't even be too difficult to implement. In fact I might even create a plugin that does this.

 

[MrNybbles]

Regarding @Poryg's suggestion suggestion, I think the difficulty here is that there wouldn't be a way for the unencrypted files to get automatically encrypted (unless somehow a program could hook in and execute an external program). It would need to be an extra step.

Interestingly, because the issue here is to keep people from modifying the code, this would be the perfect place to use a one-way key algorithm like OpenPGP.

Basically the Game Developer keeps the encryption key and encrypts those files, then the Game's Plug-in uses the decryption key when reading the files.

OpenPGP.js
https://github.com/openpgpjs/openpgpjs/blob/master/README.md
License: GNU Lesser General Public License v 3.0


EDIT:
From reading the OpenPGP page above, looks like Node.js might have it built-in already, but I'd want to test that as I don't know how old the Node.js in RPG Maker MV is.

https://nodejs.org/en/knowledge/cryptography/how-to-use-crypto-module/

 

[MusicalSamurai]

@LTN Games
Well, everybody can open it. But how many people can read it?
Without the RPG maker not too many.

I don't mean to be funny, but JSON to me is almost as readable as Plain Text - anyone that's familiar with either key:value pairs or even just curious as to various ways of storing data wouldn't take them too long to realise that it's quite legible and there's some kind of relationship between the files... A more curious person could simply open up something like MapInfos.json, find the name of an area say "Starting Home", find its ID (say "4") then open Map004.json and find all of the event names and potential IDs for switches... Although I'm getting a bit deep here, My main concern is simply that anyone can open the Enemies.json and then change their HP to 1, or EXP to 999999 - I want to be able to prevent this however I can...

I like the idea of your B64 encoding and have thought of this myself (although gets a little tricker considering character sets like ASCII, UTF-8 and Unicode), or a different way to pack & parse the game data entirely using scripts but to me this seems like an extreme solution to something that should be trivial... A simple option in the editor to also scramble JSON files into something only the Engine can interpret I don't think is too much to ask for... Is it?

I'm thinking of things that can be done 'at' the deployment stage, without any pre/post messing about - although to be fair if the only solution is "scrambling the files after deployment" then this may be my only viable solution and I'll just have to accept it.

Thank you both so far for helping me wrap my head around this - I feel like I'm slightly closer to some sort of solution

 

[Andar]

Something like that - I didn't personally notice any ways to specify custom files -

I haven't found it in the help either

then you didn't really look for it in the help file, because it can't be more obvious.

Open help
scroll down below "documentation"
click on the entry labeled "[exclude unused files] Plugin Configuration"

It has been there ever since the option "exclude unused files" was introduced in 1.2 or 1.3

 

[MusicalSamurai]

Regarding @Poryg's suggestion suggestion, I think the difficulty here is that there wouldn't be a way for the unencrypted files to get automatically encrypted (unless somehow a program could hook in and execute an external program). It would need to be an extra step.

Interestingly, because the issue here is to keep people from modifying the code, this would be the perfect place to use a one-way key algorithm like OpenPGP.

Basically the Game Developer keeps the encryption key and encrypts those files, then the Game's Plug-in uses the decryption key when reading the files.

The method you speak of is also borderline on what I'm wanting; scrambled JSON files that RPGMV can still pull data from although my method in mind is much simpler without needing private/public keys - if it gets 'found out' or 'reverse engineered' (basically being hacked by someone that knows what they are doing) then I have no worries of this...
I just don't want some average person like my friends or my missus to just scoot through the files and edit things as they see fit because they can clearly see

"exp":25

or

"gold":25

- it feels so dirty to me that I'm failing to express it in words properly...

Or maybe I need to think more objectively about this... Perhaps I do want a 2 way encryption but with a password of "" that can easily be 'broken' but still not 'human-readable' in Notepad...

This seems to be taking more brain cells than it's worth - I apologise for the headache people - Hopefully I'll find a solution to this amongst the great minds here

 

[Poryg]

The only solution is to deal with it after deployment. Whenever you make a small alteration to the game files in terms of game edits, the editor will create a new file with the correct values,
I don't think it's necessary to bother with ASCII, etc. The standard, under which most text files are saved and read, is UTF-8. And I tried to compress random kanji and then decompress it... And it worked flawlessly. Btw. UTF-8 is unicode. UTF-16 is unicode too. They just take different amount of space. UTF-8 takes 8 bits per character, except for where the characters are above 65535 in the unicode table. There it takes 16 bits. UTF-16 takes 16 bits for all characters and serves as a foolproof way to deal with those programs, which don't have the 16 bit characters covered. The downside to it is, the files take more space. ASCII is obsolete, because it contains only 300 characters or so.

 

[MusicalSamurai]

then you didn't really look for it in the help file, because it can't be more obvious.

Open help
scroll down below "documentation"
click on the entry labeled "[exclude unused files] Plugin Configuration"

It has been there ever since the option "exclude unused files" was introduced in 1.2 or 1.3

Ohh I scooted over this various times without even realising - I dismissed it due to the wording (and I'm a bit finnicky about wording) because it's called "Plugin Configuration" - My main project doesn't have 'Plugins' outside of my own bespoke creations which are tailored to their usage and thus on my Plugin manager is my 1 plugin, turned on, with no options to configure...

But that's still the case... I'm confused on this, as I do not have a 'Plugin' for the "Exclude Unused" - am I getting caught up on the definitions or am I actually physically missing a file that everyone else has by default? because without rooting through actual game files, I do not see anywhere I can 'configure' the deployer?

 

[MusicalSamurai]

The only solution is to deal with it after deployment. Whenever you make a small alteration to the game files in terms of game edits, the editor will create a new file with the correct values,
I don't think it's necessary to bother with ASCII, etc. The standard, under which most text files are saved and read, is UTF-8. And I tried to compress random kanji and then decompress it... And it worked flawlessly. Btw. UTF-8 is unicode. UTF-16 is unicode too. They just take different amount of space. UTF-8 takes 8 bits per character, except for where the characters are above 65535 in the unicode table. There it takes 16 bits. UTF-16 takes 16 bits for all characters and serves as a foolproof way to deal with those programs, which don't have the 16 bit characters covered. The downside to it is, the files take more space. ASCII is obsolete, because it contains only 300 characters or so.

Yes I apprecaite this, during development the files reflect what's being done in the editor - but 'Upon Deployment' is my concern.

My mention of character sets was just a detail to consider when playing with encoding/decoding, I didn't mean to elicit eduction on the different character sets and memory allocation sizes... I feel that created a bit more of a tangent than was necessary - but thank you for your input nontheless! - Everything seems to be pointing to "Do game, Deploy it, Implement Obfuscation afterwards" - which is actually my original method I've failed on a few times - Perhaps I'm simply going about it all wrong...

 

[MrNybbles]

@MusicalSamurai

A simple encoding of doing a bitwise XOR to each character in a file with a known value would do what you need.

However, how would these files get encoded/encrypted in the first place?

[Scenerio]
Plain-text Files => RPG Maker Deployment... + Encryption Key => (some) Encrypted Files + (other) Plain-text Files

If we add a Plug-in to decode those 'other' Plain-text Files then what would encode them in the first place?

I could write a simple executable in C to do a bitwise XOR using a known byte, but would you be able to compile it?
I'd rather avoid sending actual executable files to people.

Maybe the best solution would be to have the Plug-in check if the Plug-in is being run in Test Mode. If it is then don't do anything.
If not then check if the files are encoded. If not then encode them and replace the originals. Then decode wile reading from the file.

This method would require you to remember to run the final game once after Deployment + Encryption to apply the encryption to the files once.

Pseudo Code:

if(not RPGMaker_TestMode) {
    if(not FileEncoded) {
        doEncodeAndOverwiteTheFile();
    }
    doDecodeReadFromFile();
}

EDIT: I just realized I typed 'bitwise AND' instead of 'bitwise XOR'. XORing with the same value will encode & decode the byte.

 

[MusicalSamurai]

And I tried to compress random kanji and then decompress it...

Also, sorry to be 'that guy' - but Base 64 encoding isn't considered 'Compression' as it requires more characters to represent the original data than the original data - it's simply Encoding/Obfuscation

 

[MusicalSamurai]

However, how would these files get encoded/encrypted in the first place?

A good point, and also my point... It's baffling me...

To be fair, there need not be any 'secret' to the encoding/decoding process and the actual file that 'does the job' can be human readable for all I care - My top priority is the "Data/blabla.json" files - as long as these cannot be read easily by another human, then I can shut up and be happy.

And I haven't touched C in a very long time... C++ or C# perhaps is more recent in my mind... But feel free to throw me any Pseudo-Code and I'll try make heads/tails of it - a bit like your last bit - looks promising!

 

[Andar]

am I getting caught up on the definitions

You're misreading what is written there.
That section describes the javascript functions for how you need to configure the "exclude unused" options for your plugin, so that the files you specify as needed for your plugin are not removed by the engine on deployment.

This command will NEVER appear in the plugin manager, you need to use it in the javascript code of the single plugin that you're writing.

 

[MusicalSamurai]

You're misreading what is written there.
This command will NEVER appear in the plugin manager, you need to use it in the javascript code of the single plugin that you're writing.

Holy hell! - That's the words I needed to hear! - I have no idea why it didn't click in my head this whole time thinking it was literally talking about a Plugin I need to configure...

Okay that's my first problem solved, I just simply need to append the correct bits of code into my script so it's interpreted as a plugin with assets to then include with deployment... Genius!

Now if only we can solve this JSON Obfuscation Post Deployment issue... I'll be a very happy man!

 

[Poryg]

I've made a plugin. What it does is, base64 encoding of every dataFile. And if you're playtesting, it will take data from the original files (because the encoded ones don't get created until you launch the game for the first time), but in the deployed game it will take data from the encoded ones. So after deployment you just delete the unencoded ones and you're good to go.
EDIT: I just realized that since MV first loads all plugins, then it launches the game, I can create the files even before the game gets launched. So I removed one if and one alias, meaning you can see any performance hits this plugin is bound to inflict by decompression even on playtest.

Also, the reason why I call it compression is simple - the LZString function is "compressToBase64" and "decompressFromBase64".

EDIT: I uploaded it to my repository. https://github.com/Poryg1/RPG-maker-MV-small-plugins

 

[Celianna]

@MusicalSamurai you probably don't know it yet, but we have rules against double posting (posting right underneath yourself). You can just edit your previous post if you have more to add