Ability To Compile RPGMaker Games From Command Line?

[StrangeWill]

Was dorking around with the idea of getting one of our RPGMaker games on CI/CD so it's easier for us to package/deploy/distribute test builds, as far as I can tell the only actionable exes that come with the application is the nwjs package which via the RMMVCookTool program we can compile the *javascript* files to binary...

But the only app that seems to handle the actual compliation of the project is RPGMV.exe which I cannot seem to pass a project/parameters/etc. to cause it to compile. Am I missing anything or is there zero support for this (or even unsupported way to do this?)

 

[Andar]

you made a wrong assumption - there is no compiler involved in any RM at all.

all RPG Maer Games are interpreted games, and the exe you found is an interpreter that contains nothing of the game itself.
In the case of MV/MZ that interpreter is basically a chromium based browser that has its adress fixed to the index.html of the game.

there are programs that pack the game and the interpreter together into a single exe, but those are packagers and/or virtual machines, not compilers

 

[StrangeWill]

Ah, I was expecting some sort of intermediate build process that packaged/minimized/removed debug tools (maybe there is for encryption but RMMVCookTool has us covered as much as we need to be honest).

It does look like the output is just a copy of the nwjs-win/lnx directories with the game files dropped right into www/

That should be pretty easy to reproduce, I'll play with that.


Thanks!

 

[Andar]

removed debug tools

no, the editor launches a slightly different browser for playtest, and it is that browser that contains the additional debug functions (like holding ctrl to override passability for map testing etc.)
the browser placed in the project directory has no special playtest override or debug functions at all.

 

[Arthran]

It does look like the output is just a copy of the nwjs-win/lnx directories with the game files dropped right into www/

If you don't need to encrypt your assets.

 

[StrangeWill]

If you don't need to encrypt your assets.

_Yeah_ that's been something we've been debating back and forth -- it's the one thing I don't have _full_ coverage for, RMMVCookTool.CLI.exe does get us some coverage on the Javascript files, but not for any other assets.

We've been debating going down this path while we've been doing closed betas, but aren't sure what the value is -- as I understand it there's a couple of major pain points here:

1) Anything that is encrypted by a 3rd party runtime can also have its keys ripped and decrypted by another runtime
2) And this has been made trivial with already available online tools

-- If #2 isn't actually true, anyone got any pointers for running that encryption routine from a CLI app?

 

[Andar]

What you need to understand is that all encryptions and protections can be broken.
AAA-Companies pour literally millions into DRM systems and copy protection, and they still get only months until their games are cracked - but they calculate with those months to give them enough sales.

As a small independent you can't pay that much for DRM servers - but on the other hand the interest in cracking your protection is a lot lower than for AAA-games.

There are several medium-level companies that decided to simply forgoe copyright protection for their games due to this, and are instead working on adding incentives to purchase by constantly upgrading their games - you might consider going that route as well.
It depends on how much worth your resources are outside your game.

For the legal requirements of purchased DLC even the build-in encryption is considered enough.
Not because it is especially strong (everyone knows it had been hacked years ago) but because using it makes proving intend when suing easy - since you cannot get the unencrypted resources by accident the fact that someone has them from a game proves that he/she hacked that game.

 

[StrangeWill]

What you need to understand is that all encryptions and protections can be broken.
AAA-Companies pour literally millions into DRM systems and copy protection, and they still get only months until their games are cracked - but they calculate with those months to give them enough sales.

As a small independent you can't pay that much for DRM servers - but on the other hand the interest in cracking your protection is a lot lower than for AAA-games.

There are several medium-level companies that decided to simply forgoe copyright protection for their games due to this, and are instead working on adding incentives to purchase by constantly upgrading their games - you might consider going that route as well.
It depends on how much worth your resources are outside your game.

For the legal requirements of purchased DLC even the build-in encryption is considered enough.
Not because it is especially strong (everyone knows it had been hacked years ago) but because using it makes proving intend when suing easy - since you cannot get the unencrypted resources by accident the fact that someone has them from a game proves that he/she hacked that game.

Yep, definitely not looking to spend a lot of time and effort into it, just a small barrier to prevent dropping all of our assets would be enough, I've already eyeballed decryption efforts and tools plus where and how keys are stored and I know it's pretty weak (which in general encrypted content can only be secured so well when the person wanting to do the decryption has access to the keys, you can only get more clever on how to hide them generally).

Just curious if anyone had any insight into how RPG maker does this, if it's a library/standard they're using that we can pack with a 3rd party tool, or if it's propritary and built directly into their MV exe and not worth trying to reproduce (even 3rd party tools look like more of a pain then I'm willing to jump through since I'll have to fiddle around with someone else's tooling that isn't made to put the project back together to do so -- not nearly that interested in it)

Definitely not a barrier, if no one has any answers, we'd just be deploying it as-is.

 

[Andar]

MV Games are HTML-Based games, and it is difficult to impossible to encrypt something that needs to run in a browser. There are limits of what you can do with obfuscation to hide the code and the key.

The only way to have even a minimal chance is to use a wrapper that pack the game including the exe into an encrypted archive and then hides the files for the game when extracting and running it.

and even that has limits

 

[StrangeWill]

I mean if you don't know the answer to the question that's okay -- but going over basic information I already know (and have explained I understand in earlier posts) isn't really helpful.

 

[kyonides]

On my Linux box I've got a file named libquazip and it gotta be related to the MV executable for obvious reasons for they're both are located side by side.

Package libquazip-dev
stretch (oldoldstable) (libdevel): C++ wrapper for ZIP/UNZIP (development files, Qt4 build)
0.7.2-1: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x
buster (oldstable) (libdevel): C++ wrapper for ZIP/UNZIP (development files, Qt4 build)
0.7.6-2: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x

What if you were looking at the wrong place or library from the very beginning?

 

[Zeriab]

If you don't have any assets that required enccryption it's probably simpler if you create your own packaging CLI. You can then connect that via git hooks to get that CI/CD goodness.

 

[Poryg]

Why hasn't anyone tagged me? I know everything about how MV handles deployment.

For the starters, the editor does all the work - nothing is handled through 3rd party applications and there is no native support for a CLI.
The editor supports two deployments. An unencrypted deployment and encrypted deployment. In the unencrypted one it only copies the nwjs-win folder and your project files. The encrypted deployment encrypts the asset files as they're copied.

You can create your own CLI to handle deployment yourself. Since it's basically copy pasting, it shouldn't be that difficult. But then unless you'd also encrypt the resources, you won't have any asset encryption. Although if you care about security of your assets, MV's default asset encryption is not something you'd want to rely on anyway, because it's a total joke and if you dig, you will find asset decrypters (the devs aren't really at fault tho - the engine is 100% open source, so they could throw any encryption they wanted and since the decryption algorithm is inside the game's javascript files, it would always be accessible).

 

[Arthran]

1) Anything that is encrypted by a 3rd party runtime can also have its keys ripped and decrypted by another runtime
2) And this has been made trivial with already available online tools

Correct. The reason I brought it up anyway is because if you are using any DLCs, you are probably legally required to encrypt your assets. At least, DLCs published by Degica usually have a clause similar to this one included somewhere in the EULA:

Resources may be packaged with commercial or non-commercial
games and shared as long as they are protected via some means of
encryption.

Just curious if anyone had any insight into how RPG maker does this, if it's a library/standard they're using that we can pack with a 3rd party tool, or if it's propritary and built directly into their MV exe and not worth trying to reproduce

As Poryg mentioned, the method they use is proprietary. However, it's so simple that no special libraries would be required to reproduce it anyway. It would be a pretty trivial matter to create a command line tool that reproduces the process, but if you were going to create your own tool anyway, then I suppose there wouldn't really be a good reason to use the same method that they use.

 

[StrangeWill]

@Poryg Awesome, thanks for the insight, yeah I was hoping there was something but not surprised there isn't.

@Arthran Ah yeah good point on 3rd party assets and the requirements we're bound to on that -- looks like a couple of the asset packs fall under that, so will probably have to look into rolling our own tooling on that. Any guides or known implementations since we have to have it play ball with nwjs-win/nwjs-linux?

 

[StrangeWill]

Actually, I went ahead and started pulling at the core js scripts and found the decryption routines, and it looks like it would be pretty easy to:

1) Provide our own custom encryption via a plugin
2) Expose that plugin to our CLI to handle encryption too


If anyone knows of off-the-shelf tooling to help with that it would be awesome, but it seems I'm on a good track here otherwise, thanks for the help (and will probably publish this ourselves on github or something)!

 

[kyonides]

You'd have stopped needing more info after I posted the libquazip stuff. That had proved that it simply sent some sort of ZIP commands to the library, something you could handle with your eyes wide closed.

 

[Arthran]

You'd have stopped needing more info after I posted the libquazip stuff. That had proved that it simply sent some sort of ZIP commands to the library, something you could handle with your eyes wide closed.

Sorry to be blunt, but that library is not even remotely related to what any of us are talking about.

Any guides or known implementations since we have to have it play ball with nwjs-win/nwjs-linux?

The editor's encryption method is to XOR each of the first 16 bytes of the file against the byte represented by the characters in the corresponding position of the encryption key. Then it also inserts an arbitrary 16 byte header in front of those bytes.

So supposing that the first 16 bytes of my png file are this:

89 50 4E 47 0D 0A 1A 0A 00 00 00 0D 49 48 44 52

And my encryption key (which will always be 32 characters that can represent valid hexadecimal digits) is this:

19a07ed4c99c4f630a92f62888ded38e

We'd first separate the encryption key into 16 strings of 2 characters, and parse them into hex integers. These would be the resulting hex integers:

19 A0 7E D4 C9 9C 4F 63 0A 92 F6 28 88 DE D3 8E

Then you'd XOR each byte from the first code box against each corresponding byte from the last code box. So for examples:
89 XOR 19 = 90
50 XOR A0 = F0
4E X0R 7E = 30
47 XOR D4 = 93
etc...

And you'd wind up with this:

90 F0 30 93 C4 96 55 69 0A 92 F6 25 C1 96 97 DC

The editor will replace the first 16 bytes of the file with these new bytes.

After all of that, the editor will also insert an arbitrary 16 byte header in front of those. The header will always look like this:

52 50 47 4D 56 00 00 00 00 03 01 00 00 00 00 00

So then the beginning of the file winds up looking like this:

52 50 47 4D 56 00 00 00 00 03 01 00 00 00 00 00
90 F0 30 93 C4 96 55 69 0A 92 F6 25 C1 96 97 DC

I'm pretty sleepy, so I don't know if I explained any of this well. But basically, the encryption method just changes 16 bytes in the file, and adds an additional 16 bytes to the file. The entire remainder of the file is untouched.

You should be able to use pretty much any programming language to write a console application that can perform these operations. Though like I mentioned in my previous post, if you're going to go through the trouble of writing such a tool, then you might as well go ahead and alter the algorithm a bit.

Personally, I wouldn't change it drastically, because you don't wanna do anything that might slow down the decryption process. But even a very minor change will make it so that none of the existing RPG Maker decrypters will work on your game, so then unskilled individuals can no longer rip your assets with the click of a button. It would make it so that someone with the right skillset would need to be determined enough to write a dedicated tool in order to decrypt your game. Of course, you would also have to create a plugin (or edit your core scripts) to accommodate the new encryption method.

 

[StrangeWill]

@Arthran Ah actually excellent help, I was already kind of digging into throwing some tougher encryption on but the way that data is streamed makes things like block ciphers a bit difficult to "keep track of" (and some of the implementations have some pretty rough performance penalties), so far I'm planning on sticking to a modified variant of the built-in encryption system like you recommended.

I actually had _most_ of an AES cipher working but various JS libraries messed with formats making streaming music a no-go (images worked fine though).

I've been debating just not encrypting music (since we're able to do that), but... still unsure.

Either way, I appreciate the guidance, I'll play with it a bit more and get something working, thanks!

 

[Zeriab]

Using an AES cipher will not make your code more secure. All you are likely to gain is reduced performance. AES is still really fast so the performance cost may be completely negligible.

Nobody broke the default encryption by doing a frequency analysis. Why spend time doing that when it is way easier to simply snatch the decryption part from the game itself.
A variant XOR encryption will manage to accomplish the same purpose of preventing the current available tools from working.

Regarding the design of the CLI itself I recommend reading: https://clig.dev/
The site itself is open-source and the source can be found here: https://github.com/cli-guidelines/cli-guidelines
A key part is designing the program to be composable with other programs. Being able to compose different CLI programs together can allow you to accomplish so much stuff so fast. It does come with a pretty high learning barrier though.

*hugs*