LÖVE

Deltise wrote:You could run through your code, make 2 copies of the game, and then make all your variables and function names miscallaneous numbers and letters, and in a second copy use comments to annotate which function is which so that you may edit your 'encrypted' code with a bit more ease.

I wouldn't bother, if I were you. It's like spending a dollar to save a penny: it's not going to stop someone who wants to cheat bad enough that they read the code. It's not going to be worth the time investment and maintenance penalty to possibly stop or delay a possible fraction of your cheaters.

If someone wants to figure out your code hard enough, they will. And you can't stop them. It's like pirates who put movies on the internet, shut one down and another will pop up. DRM on the original video? Nope, no problem. We have tools for that.

Face it, if it's created by a human, it can be uncreated by a human. And the harder you try to keep people out, the harder they will try to get in.

I'll actually be honest on this one, I like the Open Source world, so I'd rather not see code Obfuscated so that I can go in and inspect it and see if there's anything worth learning. And I say learning because I've learned that attempting to steal code is fruitless. There's nothing to be taken that isn't very specific to the game that it's part of. So, while everyone is saying that you can't stop thieves, I'm saying please don't stop students.

You'd have to modify the LOVE source and build new binaries, but I think that ZIP obfuscation would be an option. Like what Ogre has built-in: http://www.ogre3d.org/tikiwiki/tiki-ind ... +Zip+I%2FO
I do think that something like this would be a nice, useful addition to LOVE - something that would be optional to use, but would be available. Then again, this could be much harder to implement into LOVE than I'm imagining.

Or, for online games, perhaps you could figure out a way for your server to securely provide the key (thus possibly avoiding modifying LOVE's source)?

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

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

And perhaps more importantly: where does the key go? Because, let's face it, in the end you'll have to give it to your user anyway (the person that is supposedly conspiring against us).

A better way would be to compile to lua bytecode. There is no good decompiler out there. And of couse you could modify the lua vm to make generate incompatible bytecode. I saw this in "Legend of Grimrock".

But i can't say how to get lua bytecode working in LÖVE. Maybe someone else knows?

SiENcE wrote:A better way would be to compile to lua bytecode. There is no good decompiler out there.

Actually there are a few working decompilers out there. I've personally used one very successfully. Bytecode generated by regular Lua will not be compatible with different Lua versions (e.g. LuaJIT) or different architectures (32 bit vs 64 bit).

slime wrote:

SiENcE wrote:A better way would be to compile to lua bytecode. There is no good decompiler out there.

Actually there are a few working decompilers out there. I've personally used one very successfully. Bytecode generated by regular Lua will not be compatible with different Lua versions (e.g. LuaJIT) or different architectures (32 bit vs 64 bit).

not to mention, the bytecode for the standard 5.1 interpreter (and to some extent luajit's as well) is also documented; if a decompiler fails on a certain bytecode it is entirely possible for a sufficiently motivated person to reverse it by hand

also obfuscation + debugging = NOPE

anyway, legal protection (licenses/copyrights) is much more powerful than code protection anyway, if it really comes to that

Xgoff wrote:

slime wrote:

SiENcE wrote:A better way would be to compile to lua bytecode. There is no good decompiler out there.

Actually there are a few working decompilers out there. I've personally used one very successfully. Bytecode generated by regular Lua will not be compatible with different Lua versions (e.g. LuaJIT) or different architectures (32 bit vs 64 bit).

not to mention, the bytecode for the standard 5.1 interpreter (and to some extent luajit's as well) is also documented; if a decompiler fails on a certain bytecode it is entirely possible for a sufficiently motivated person to reverse it by hand

also obfuscation + debugging = NOPE

anyway, legal protection (licenses/copyrights) is much more powerful than code protection anyway, if it really comes to that

Sure. The main reason of this would be only to push the level of skill needed to reverse it , but some people might take this as challenge .