Resources are open - any way to compress or encode them?

Hey guys,

so far - all works flawless, all cool.

But is there are way to compress ‘Resources’ folder? and check if it was unchanged at launch?

couse now all resources are open, and players can modify very easely. It is a big concern for free games.

Even zip and any summ check that it still same - whould be great.

Right now, the plan is to not protect them for several reasons.  First it would create a situation like Android where the files are inside another file and we would have to deal with extracting things on the fly.  This makes thinks more complex and hurts performance.  OS-X does not protect its file, and many Windows apps do not protect them as well.

Right now the focus is on getting to build and monetize the apps.

Rob

That great.

I can always hard-code xml data files for that reason.

Monetization is best focus =)

Hi Rob, 

I think the “resource” folder should get some improvement. Right now it even displays the folder hierarchy and image name/extention exactly like I have them in my project folder.

There are other ways to protect your assets, but I guess that the main program calls the assets in that exactly folder and there is no way to hide them right?

I mean, some games might have their assets unprotected, but these are so easily geteable… 

PS.   resource.car encrypts just lua code, all corona APIs / strings are readeable.

I’m just going to add my 2 cents here.  Any game can easily have its assets stolen.  Even the AAA games that do bundle and encrypt their assets have them stolen or hacked too.  You can also easily screen capture the app to fetch its graphics that way.  So, the most you can do is make it difficult for people to extract them, but by doing that, you’re also making it difficult for your app to use its own assets and sometimes at the cost of performance.  The same can be said about your app bundles on Android, iOS, and OS X.  Their assets are packaged within the app in standard ways and can easily be extracted.  And if you think about, all website assets are exposed too.  They have to be or else the browser wouldn’t be able to display them.  But that said, and in my opinion, I think it’s more important for an app developer to worry about how to make money from a desktop app (ie: monetization solutions) and how to protect the app from being pirated, because this dictates the success of the app.  Once your app does get popular, well then shoot, there’s no stopping hackers from figuring how to extract and hack your app’s assets then.  And there’s a term for that.  It’s called modding and it’s popular scene on Windows.  And if you have a modding community invested in your app, well then I think you’re likely doing well for yourself.  :slight_smile:

Currently, our point of view is that its more important to implement features Corona developers want on Windows such as game controller support, video support, text entry support, etc. rather than impede our development time with supporting embedded/bundled files in all of our core APIs (it’s actually a large lengthy undertaking).  You already have the power to encrypt, zip, and extract files for yourself.  So, if you are feeling very passionate about this, then you already have the tools to do this for yourself.

And regarding the “resource.car”, it’s contents are not encrypted on any platform.  It’s effectively a tar ball of all of your compiled Lua scripts.  It’s not our job to encrypt your strings.  Just like how Visual Studio, Xcode, and the Android SDK do not automatically encrypt strings in compiled binaries either.  If you have strings you need to protect, then you have to encrypt them yourself before copying them into your code.  You can then decrypt them with Corona’s crypto.* APIs.  Again, it isn’t any different for native developers either and you can easily see string inside of *.exe and *.dll files too.

Hi Joshua,

I understand there are a lot of important features to add yet, this is an open beta and it was just released today, and as far as I can tell is working perfectly.

What i was trying to say is that we have the main EXE program compiled by Corona and, for example: it calls an image under “resources/assets” called character.png. Right now we don’t have a way to change this behaviour, right? Even if we package the game libraries and other files for installation… so there wouldn’t be a way to protect them. Please correct me if i’m wrong. 

Even if .apk’s assets are really easy to get, it’s not so easy for normal users to get assets from other standalone games. There might be well known tools but they are usually for engines like UE that always used the same way to store them.

Regards

Let’s say you’re only interested in protecting your PNG files.  You could zip up all of the PNG files in your project and then set up your “build.settings” file to:

  • Include the zip plugin.

  • Exclude all PNG files for win32 builds.

  • Exclude the zip file for all other platform builds.

Then on windows app startup, you can unzip the zip file on app startup (if not done already) to a temp directory and load your PNG files from there.  Your PNG files will now be exposed under that temp directory, *but* it’s located under a hidden directory on Windows.  With the one not-so-nice thing about this solution is that your app doesn’t have an easy way of cleaning up the temp directory after an uninstall (or however you decide to distribute your app).

I haven’t put it through its paces, but so far this seems to work nicely: Enigma Virtual Box

Process seems to be: point it at your exe, add folder recursively (Resources), add files (the DLL files), then run it. In the end, you get a boxed executable that you can pass around.

That said, I was mostly investigating a means to keep things in a more familiar exe form, not protection per se. I’d be interested in any similar programs, too.

Hmm… that’s an interesting idea.  And I’m curious how they do this without extracting the files.  They document that they virtualize file I/O access somehow.  Anyways, I’d be interested to know how well it works for you.

I didn’t notice any speed issues, but so far I’ve only tried it briefly. State persisted fine between a couple runs.

It was mentioned in the Node WebKit docs as a packaging approach: How to package and distribute your apps (near the bottom)

Right now, the plan is to not protect them for several reasons.  First it would create a situation like Android where the files are inside another file and we would have to deal with extracting things on the fly.  This makes thinks more complex and hurts performance.  OS-X does not protect its file, and many Windows apps do not protect them as well.

Right now the focus is on getting to build and monetize the apps.

Rob

That great.

I can always hard-code xml data files for that reason.

Monetization is best focus =)

Hi Rob, 

I think the “resource” folder should get some improvement. Right now it even displays the folder hierarchy and image name/extention exactly like I have them in my project folder.

There are other ways to protect your assets, but I guess that the main program calls the assets in that exactly folder and there is no way to hide them right?

I mean, some games might have their assets unprotected, but these are so easily geteable… 

PS.   resource.car encrypts just lua code, all corona APIs / strings are readeable.

I’m just going to add my 2 cents here.  Any game can easily have its assets stolen.  Even the AAA games that do bundle and encrypt their assets have them stolen or hacked too.  You can also easily screen capture the app to fetch its graphics that way.  So, the most you can do is make it difficult for people to extract them, but by doing that, you’re also making it difficult for your app to use its own assets and sometimes at the cost of performance.  The same can be said about your app bundles on Android, iOS, and OS X.  Their assets are packaged within the app in standard ways and can easily be extracted.  And if you think about, all website assets are exposed too.  They have to be or else the browser wouldn’t be able to display them.  But that said, and in my opinion, I think it’s more important for an app developer to worry about how to make money from a desktop app (ie: monetization solutions) and how to protect the app from being pirated, because this dictates the success of the app.  Once your app does get popular, well then shoot, there’s no stopping hackers from figuring how to extract and hack your app’s assets then.  And there’s a term for that.  It’s called modding and it’s popular scene on Windows.  And if you have a modding community invested in your app, well then I think you’re likely doing well for yourself.  :slight_smile:

Currently, our point of view is that its more important to implement features Corona developers want on Windows such as game controller support, video support, text entry support, etc. rather than impede our development time with supporting embedded/bundled files in all of our core APIs (it’s actually a large lengthy undertaking).  You already have the power to encrypt, zip, and extract files for yourself.  So, if you are feeling very passionate about this, then you already have the tools to do this for yourself.

And regarding the “resource.car”, it’s contents are not encrypted on any platform.  It’s effectively a tar ball of all of your compiled Lua scripts.  It’s not our job to encrypt your strings.  Just like how Visual Studio, Xcode, and the Android SDK do not automatically encrypt strings in compiled binaries either.  If you have strings you need to protect, then you have to encrypt them yourself before copying them into your code.  You can then decrypt them with Corona’s crypto.* APIs.  Again, it isn’t any different for native developers either and you can easily see string inside of *.exe and *.dll files too.

Hi Joshua,

I understand there are a lot of important features to add yet, this is an open beta and it was just released today, and as far as I can tell is working perfectly.

What i was trying to say is that we have the main EXE program compiled by Corona and, for example: it calls an image under “resources/assets” called character.png. Right now we don’t have a way to change this behaviour, right? Even if we package the game libraries and other files for installation… so there wouldn’t be a way to protect them. Please correct me if i’m wrong. 

Even if .apk’s assets are really easy to get, it’s not so easy for normal users to get assets from other standalone games. There might be well known tools but they are usually for engines like UE that always used the same way to store them.

Regards

Let’s say you’re only interested in protecting your PNG files.  You could zip up all of the PNG files in your project and then set up your “build.settings” file to:

  • Include the zip plugin.

  • Exclude all PNG files for win32 builds.

  • Exclude the zip file for all other platform builds.

Then on windows app startup, you can unzip the zip file on app startup (if not done already) to a temp directory and load your PNG files from there.  Your PNG files will now be exposed under that temp directory, *but* it’s located under a hidden directory on Windows.  With the one not-so-nice thing about this solution is that your app doesn’t have an easy way of cleaning up the temp directory after an uninstall (or however you decide to distribute your app).

I haven’t put it through its paces, but so far this seems to work nicely: Enigma Virtual Box

Process seems to be: point it at your exe, add folder recursively (Resources), add files (the DLL files), then run it. In the end, you get a boxed executable that you can pass around.

That said, I was mostly investigating a means to keep things in a more familiar exe form, not protection per se. I’d be interested in any similar programs, too.

Hmm… that’s an interesting idea.  And I’m curious how they do this without extracting the files.  They document that they virtualize file I/O access somehow.  Anyways, I’d be interested to know how well it works for you.

I didn’t notice any speed issues, but so far I’ve only tried it briefly. State persisted fine between a couple runs.

It was mentioned in the Node WebKit docs as a packaging approach: How to package and distribute your apps (near the bottom)

Hi Star Crunch. This is a very old conversation, but I have just started using Enigma Virtual Box to box some solar2d window builds into a single exe. But I can’t get it to work properly. I have made numerous attempts and consulted ChatGPT but still no luck. I started with a simple project that just draws a red circle and built it. I then boxed it with Enigma, making sure I added all the dlls etc and the Resource directory and it all looks fine – and the boxed exe runs, but only if it’s in the original build folder. If I move it elsewhere it fails with error message that it can’t find main.lua or resources.car. Do you have any more info on using Enigma Virtual Box with solar2d or any tips for things to try. Thanks in advance.