Game Obfuscation

[scutheotaku]

The problem with any and all encryption schemes. Where does it get the key from?

Well, if you're using a method like Ogre uses, you'd store the key in the compiled binary. This isn't unbreakable, but very little is. With LOVE, the obvious issue you'd have is that people would have to compile the various builds themselves, though if they want this extra layer of security then this shouldn't be a huge deal (though it would make it harder to support Linux).

Though, of course, having a feature that requires the user to build LOVE's source to use doesn't really fit with LOVE's direction, so that way of storing the key probably isn't sufficient as far as including obfuscated ZIP i/o in LOVE. Unless someone comes up with a multi-platform publishing tool (where from Windows, Mac, or Linux, you can publish your project into Windows, Mac, and Linux packages; like what Polycode has) for LOVE, anything like this is probably pretty unrealistic/a bad fit for LOVE.

One other thing: for always-online games (like an MMO), perhaps the server could provide the key?

[Robin]

Again: where does the key go to? It goes right into the hands of the user. You give the key to the user. The user has the key. And you were trying to hide everything from the user! The only thing you're doing is making things complicated for yourself.

[scutheotaku]

Again: where does the key go to? It goes right into the hands of the user. You give the key to the user. The user has the key. And you were trying to hide everything from the user! The only thing you're doing is making things complicated for yourself.

If you are referring to my post: while the methods I mentioned would be unrealistic/inappropriate to implement into LOVE in-general (though may be appropriate for developers themselves to add on a game-by-game basis by modifying LOVE's source), none of them send the keys "right into the hands of the user." In one, the key is stored in the compiled application, in the other (which is much less secure) the key would be stored on the server and then sent when needed. While it's possible that a tech-savvy and determined user could retrieve the key in the binary in the case of the first method, and that the user may be able to intercept/collect the key in the case of the second method, I don't think that either is giving the key directly to the user. Unless I'm missing something (which I fully admit I may be), I do believe that either method would make it MUCH harder for the user to access the project's code and/or assets. As I mentioned, neither methods is foolproof, but none of these types of things really are. Instead, they offer one more layer of protection.

As for me, I'm not really concerned about obfuscation. For now at least, any game I'm releasing would be free, and I wouldn't/don't really care about people stealing code or assets (well, actually, I DO care about them stealing assets and calling them their own...). If I were to sell a game, I'd put some more thought into it, but for now this doesn't concern me much. The exception to that would be 1. in online games (though, as people have mentioned here and elsewhere on the forum, there are other ways to secure that), and 2. games that have some sort of high score feature where it would be imperative to prevent cheating.

[Robin]

I'm looking at it from a security point of view, and looking at it that way, both scenarios are equivalent to just giving the user the key (in security, one must never assume the attacker isn't smarter and more tech-savvy then oneself), making the added value of such a system basically zero (after all, it only takes one user to figure it out), but it still has a non-trivial cost to build and maintain. Security is always a trade-off, and in the case of key-in-compiled-binary and key-sent-from-server, it's a very bad trade-off in my opinion.

[slime]

I'm looking at it from a security point of view, and looking at it that way, both scenarios are equivalent to just giving the user the key (in security, one must never assume the attacker isn't smarter and more tech-savvy then oneself), making the added value of such a system basically zero (after all, it only takes one user to figure it out), but it still has a non-trivial cost to build and maintain. Security is always a trade-off, and in the case of key-in-compiled-binary and key-sent-from-server, it's a very bad trade-off in my opinion.

The point of most game source content obfuscation/encryption isn't the same point as most traditional computer security. It's simply to discourage most users from viewing or distributing the original source and/or art assets, rather than completely preventing anyone from ever accessing them - if you want that sort of protection, you shouldn't put the data on the client's system in the first place.

Discouraging users from viewing the original code and art isn't a new idea by any means - it's pretty common in many widely used game engines, and somewhat effective if you understand its true intention.
Going by Lua's philosophy of mechanism over policy, I believe LÖVE should offer a reasonable choice to game developers as long as it's simple to implement, cross-platform, and doesn't get in the way of those who choose the current route.

[Robin]

The point of most game source content obfuscation/encryption isn't the same point as most traditional computer security. It's simply to discourage most users from viewing or distributing the original source and/or art assets, rather than completely preventing anyone from ever accessing them

No practical security system can completely prevent everyone from doing something forever. Like I said, security is about trade-offs, and for the reasons I stated earlier, I think that a trade-off like we're discussing here is fruitless.

[slime]

The point of most game source content obfuscation/encryption isn't the same point as most traditional computer security. It's simply to discourage most users from viewing or distributing the original source and/or art assets, rather than completely preventing anyone from ever accessing them

No practical security system can completely prevent everyone from doing something forever. Like I said, security is about trade-offs, and for the reasons I stated earlier, I think that a trade-off like we're discussing here is fruitless.

I think the question we'd answer differently is: If your goal is to discourage people from viewing your original code and art and you discourage 90% of the people, is that worth it or not?

Now, what if the effort was already done for you by being built into LÖVE?

I think the more important question, though, is: should LÖVE provide an easy choice for game developers to make themselves (assuming an implementation would work out internally), or should the game developers have to search for their own solutions every time, possibly requiring knowledge of C++ and LÖVE's source?

This question is more pertinent as we start to think about the ramifications of potential mobile versions of LÖVE: the reasons for wanting game source content obfuscation/encryption are orders of magnitude more relevant on those platforms compared to on the desktop.

[Robin]

Now, what if the effort was already done for you by being built into LÖVE?

That would tip the scale for the lovers. Marginal effect for trivial effort? Great!

This effort now would lie with the LÖVE devs. Would it be worth it for the devs?

I think the more important question, though, is: should LÖVE provide an easy choice for game developers to make themselves (assuming an implementation would work out internally), or should the game developers have to search for their own solutions every time, possibly requiring knowledge of C++ and LÖVE's source?

Or framed differently: should LÖVE do the game developers' job by providing some kind of DRM, or is it outside of the scope of LÖVE and should those who really want it use tools and libraries seperate from LÖVE?

This question is even more pertinent as we start to think about the ramifications of potential mobile versions of LÖVE: the reasons for wanting game source content obfuscation/encryption are orders of magnitude more relevant on those platforms compared to on the desktop.

Why is that?

[scutheotaku]

The point of most game source content obfuscation/encryption isn't the same point as most traditional computer security. It's simply to discourage most users from viewing or distributing the original source and/or art assets, rather than completely preventing anyone from ever accessing them

No practical security system can completely prevent everyone from doing something forever. Like I said, security is about trade-offs, and for the reasons I stated earlier, I think that a trade-off like we're discussing here is fruitless.

I think the question we'd answer differently is: If your goal is to discourage people from viewing your original code and art and you discourage 90% of the people, is that worth it or not?

Now, what if the effort was already done for you by being built into LÖVE?

I think the more important question, though, is: should LÖVE provide an easy choice for game developers to make themselves (assuming an implementation would work out internally), or should the game developers have to search for their own solutions every time, possibly requiring knowledge of C++ and LÖVE's source?

This question is more pertinent as we start to think about the ramifications of potential mobile versions of LÖVE: the reasons for wanting game source content obfuscation/encryption are orders of magnitude more relevant on those platforms compared to on the desktop.

It's also worth mentioning that LOVE is one of the few popular Lua game frameworks (or game frameworks in general) that does not have any such security in place for devs. I realize that this mainly has to do with the community around LOVE (which is very open-source-centric, as opposed to the communities of frameworks/engines like Polycode, Corona, Moai, etc... [even though some of those engines themselves are open source]) and the general direction of the project, so I'm not criticizing it here. It's just that, from a "LOVE competing with other engines" point of view (whether this point of view is flawed or not), LOVE has a big disadvantage here.

While I don't know how practical something like this is because of how cross-platform deployment works with LOVE, I'd love for such securities to be provided as part of LOVE. Most importantly, I'd love for them to be optional - I think that this would truly make everybody happy. All of "open source crowd" could keep things open source (which is great!), and the community could encourage newbies and such to release their source, etc.. At the same time, the more protective or commercial minded users could easily keep things closed if they so desired. And, as slime mentioned, this would be a huge (if not essential) asset on mobile platforms.

It seems to me that one possible path, at least for code, would be an optional LuaC compiler and packager. I know that there are some compatibility and portability issues with LuaC though. If any LOVE devs/contributors are interested in looking into this, you may want to contact Ivan of the Polycode project, as I believe he is working on a way around this (currently in Polycode, another framework with Lua scripting, you can publish to a "polyapp" format which is run by a platform-specific player, like LOVE, that is automatically packaged for each platform you publish to. Currently, also as with LOVE, the "raw" Lua scripts and assets are in a disguised ZIP file. He has mentioned that he is implementing the ability to compile the Lua to bytecode for multiple platforms from one; e.g., you could publish compiled Lua and everything to Linux, Mac OSX, and Windows, all from a Windows computer). Not sure what his progress is on this, or that I'm even remembering correctly (haha), but it might be worth contacting him since both projects are open source.

EDIT:
As far as whether or not source and asset obfuscation is outside of the scope of LOVE...well, that's up to the the devs (and community?) I suppose, but I would say it's not. If LOVE was simply middleware or something, then I would agree that it is. But LOVE isn't really "sold" as something to be expanded on; it's basically sold as an easy-to-use, one-stop-shop. And, unlike some other Lua frameworks like Moai, LOVE is definitely not geared towards "if you want more features, go modify the source!" As opposed to that, it seems like it is closer in design philosophy to frameworks like Pygame, engines like Flixel and Flashpunk, and even "game makers" like Game Maker and Construct.

EDIT AGAIN:
As far as compiled Lua...while LOVE is chiefly based on vanilla Lua, LuaJIT's string.dump feature would be very useful here.

string.dump(f [,strip]) generates portable bytecode
...
The generated bytecode is portable and can be loaded on any architecture that LuaJIT supports, independent of word size or endianess.

http://luajit.org/extensions.html#string_dump

[raidho36]

Given that Lua is a scripting language, you can't "close" source files and they can always be accessed as plain text (the basic prerequesite of scripting language files). Therefore, your best shot is either using source obfuscation or precompiling the whole thing.