A simple way to protect package.nw

[AshleyScirra]

We've found the best way to distribute games is to have package.nw side-by-side with the node-webkit files. At least on Windows, appending data to the end of the .exe file seems to make some antivirus software raise warnings.

Lots of Construct 2 users distribute games with node-webkit, but they're worried about users being able to simply rename the file to .zip and have full access to the contents, including artwork and audio (which could be ripped) or modifying game data files, configuration etc.

Is there a simple way package.nw could be protected? E.g. password protect the zip with a randomly generated password which is also somehow embedded in to the EXE (but not appending to the end, maybe updating a resource?)

[katanacrimson]

Have you considered C-level extensions to the node side of things for decrypting individual assets? Because password-protecting the zip is laughable at best and will fall over fairly quickly.

[yretenai]

Embedding a password protected zip into an .exe is no different than embedding a regular zip to an antivirus.

Proper protections like WinLicense/Themidia protect the content using virtualisation and obfuscation, but even they are possible to reverse engineer these days. In the end anything can be looked at using memory.

Just because people can look at the code doesn't mean it's illegal to do so (if you stated so in the Terms of Service), if you're still paranoid, you can listen to damianb and write a C extension that links an out-of-program encrypted package with the app.

[Subash]

Anything can be reverse engineered even C++ programs could be reversed if you have enough resources to do so. It will surely be pirated if your app becomes popular. Only thing you can protect your software is with TOS.

[Subash]

You can of course obfuscate js/css and html code.

[miklschmidt]

Even better than obfuscating js you could use v8 snapshots. You can use my tool nw-snapshot to make it easy and avoid broken snapshots. You still need a way to protect images/audio/video/css though. I was thinking about encoding them as data URI's and embedding them in the snapshot, but that would get you over the size limit pretty quickly. Furthermore the offender could just override the package.json and enable devtools which AFAIK would allow him to save it to disk if they're referenced in the DOM.

[katanacrimson]

@miklschmidt The assets are the largest problem and really can't be protected; if it's to be used, it has to be in a usable (decryptable, decipherable) state. And if it's in that state, someone's usually able to unpack and extract the assets fairly easily.

Until you start getting into exotic storage methods (in which case it becomes a matter of obfuscation of the extraction instead of actual asset protection), it's an absolute waste of time and energy.

I really don't think this issue/feature request is worth investigating at all and should be rejected.

[miklschmidt]

@damianb yea i'm afraid you're right.