Question about distribution.

[leiradel]

If you force me a lot, I will tell you that you might try attaching the .love file to the love executable; it will be an order of magnitude more difficult to "decrypt"; in other words, it will take more installing winzip and double-click-open the file. Sweet. We can rule moms and pops out.

That's correct, and although I've released a packer that packs the entire engine (love.exe plus DLLs) and the .love file (or directory for that matter) I really like LÖVE's approach of "engine as an application." But to use the engine as an application we have to distribute .love files which are easy to open.

But on a second thought, if LÖVE is distributed pre-compiled with an encryption key, once someone finds it all .love files become compromised. If the encryption is asymmetrical, the private key will have to be made available to developers which completely defeats the security measure. And if each developer is allowed to compile his/her own key in the executable, it defeats the "engine as an application" thing.

Maybe the easiest thing to do is to compile Lua scripts with luac. Compiled Lua scripts without debug information will be pretty hard to make sense of if decompiled. There is a complete lundump.c written by Luiz Henrique de Figueiredo, one of the Lua authors, that does byte-swapping so compiled scripts can be run on any platform despite endian mismatches between it and the compiled script. If this could make its way into the official LÖVE source it would be awesome. The post is a little old but I don't think much have changed in lundump.c that would handle the patch "unpatchable."

Now a word about my motivation. While I understand that licenses are the proper way to protect intellectual property, it doesn't stop people from reverse-engineering code. Although I love to share snippets and complete applications, I wouldn't like to have a commercial application of mine go naked into the wild. So while there's nothing you can do to completely stop hackers, I'd like to be able to stop at least boys lazy enough not to learn how to code by themselves or ask for help in forums that like to take a pick at someone else's code.

Cheers,

Andre

[Jasoco]

Thing is on OS X in order to create a self-contained app, you simply put the .love in the .app package. Don't know if you could attach the .love file to the love binary inside the package the same way you can glue files together in Windows.

[Elvashi]

Maybe the easiest thing to do is to compile Lua scripts with luac. [...] There is a complete lundump.c written by Luiz Henrique de Figueiredo, one of the Lua authors, that does byte-swapping so compiled scripts can be run on any platform despite endian mismatches between it and the compiled script. If this could make its way into the official LÖVE source it would be awesome. The post is a little old but I don't think much have changed in lundump.c that would handle the patch "unpatchable."

Its a little bit more than just the endianness, I'd say the bigger problem is that bytecodes were designed with a grand-total of zero portability in mind, and anything past what was in the design is pure gravy.

random aside, has anyone tested the ability of luaJIT to load bytecodes?

Now a word about my motivation. While I understand that licenses are the proper way to protect intellectual property, it doesn't stop people from reverse-engineering code. Although I love to share snippets and complete applications, I wouldn't like to have a commercial application of mine go naked into the wild. So while there's nothing you can do to completely stop hackers, I'd like to be able to stop at least boys lazy enough not to learn how to code by themselves or ask for help in forums that like to take a pick at someone else's code.

Your packer is probably enough to stop those "lazy boys", the law is your only real protection after that*. Besides, anyone that can't code isn't going to get far I'd wager, even with stolen source code.

* captain obvious would like to point out that any form of copy protection must include its 'solution'.

[leiradel]

Its a little bit more than just the endianness, I'd say the bigger problem is that bytecodes were designed with a grand-total of zero portability in mind, and anything past what was in the design is pure gravy.

Yeah, and there's also the problem of the choice of integer and floating point used to compile Lua. But since we're in a controlled environment here, using the luac that matches the Lua library used to compile a specific version of LÖVE (i.e. same sizes of integer and floating point and same floating point representation) would be ok if we could get past the endianess issue.

A possible solution for this that doesn't require patching Lua would be to expose a global containing the runtime platform endianess, i.e.

Code: Select all

if love.runtimeEndianess == 'little' then
  -- Run the little endian bytecode
  love.filesystem.load( 'main.luac.little' )()
else
  -- Run the big endian bytecode
  love.filesystem.load( 'main.luac.big' )()
end

-- Or...

love.filesystem.load( 'main.luac.' .. love.runtimeEndianess )()

so that the only plain text source code in an app would be main.lua. I could try to mess around with luac to add an option to generate both little and big endian bytecodes.

Or use an obfuscation app in the source code, but I couldn't find any besides one that runs online and thus not suitable for a build pipeline.

Cheers,

Andre

[Elvashi]

Yeah, and there's also the problem of the choice of integer and floating point used to compile Lua. But since we're in a controlled environment here, using the luac that matches the Lua library [SNIP]

You did notice the part about it being idiosyncratic to compilation settings and compiler, didn't you? and the part about the planned degree of portability being zero?

consider: The Windows and Linux (and probably mac) versions of love are built with different compilers. There's also nLove for the nanonote (x86? whats that?), hopefully the first of many ports to portable devices, running the full gauntlet of bitwidth, and endianness.

Don't forget that Lua also has no byte-code verifier, and no docs for designing one (its not part of the spec, remember?), so any "secure" version of love, such as a browser plug in, would have to reject byte-codes on principle. (Assuming they aren't just done with lua-alchemy, which I'm not sure even has the option of loading byte-code in the first place.)

(I think you might actually understand what you are getting into here, but I want to make clear to anyone else thats reading that this isn't simple topic, there's distinct downsides to byte-codes, and there's at least a bit of gambling involved.)

[bartbes]

nLove for the nanonote (x86? whats that?)

MIPSel actually.

But since we're in a controlled environment here, using the luac that matches the Lua library used to compile a specific version of LÖVE (i.e. same sizes of integer and floating point and same floating point representation) would be ok

Wait, what controlled environment? Due to limitations on some of the platform it links against lua statically, but on linux at least it just uses your system version.

[leiradel]

... and the part about the planned degree of portability being zero?

That's the part I'd like to solve. LÖVE is multi-platform, its applications should also be. Publishing source code is not an option to everyone, and solving this could increase the interest in LÖVE.

Don't forget that Lua also has no byte-code verifier, and no docs for designing one (its not part of the spec, remember?), so any "secure" version of love, such as a browser plug in, would have to reject byte-codes on principle.

Bytecode correctness isn't enough to ensure security. That's why you can sign Java applets and ActiveX plugins, to give their users your guarantee that the code is safe for execution although even then it could contain malicious code.

(I think you might actually understand what you are getting into here, but I want to make clear to anyone else thats reading that this isn't simple topic, there's distinct downsides to byte-codes, and there's at least a bit of gambling involved.)

Yup, it's not a simple topic, but I'd really like to distribute one and only one .love file without source code that could be executed on all LÖVE-supported platforms though portable devices will always need some tweaking because of their particularities.

[Elvashi]

That's the part I'd like to solve. [...] Publishing source code is not an option to everyone [SNIP]

Unfortunately, Lua's design is such that this can only ever be, at best, mitigated, never "solved". documentation for byte-codes is sparse, the design provides no protection against munging by the compiler. nothing short of a complete rewrite could provide any reasonable assurance of portability.

Lua is and always has been a language that was intended to be distributed as source.

Bytecode correctness isn't enough to ensure security. That's why you can sign Java applets and ActiveX plugins, to give their users your guarantee that the code is safe for execution although even then it could contain malicious code.

Correctness is prerequisite to security; if you can't confirm the code is even valid, how can you make any assurances about its operation?
and signing is only really important when an applet wishes to escape the sandbox. By default, an applet requires no special permissions, operating entirely within the restrictions of the sandbox. Exactly how a love applet is likely to behave.

Yup, it's not a simple topic, but I'd really like to distribute one and only one .love file without source code that could be executed on all LÖVE-supported platforms though portable devices will always need some tweaking because of their particularities.

I've just been reminded that nLove uses the number patch (as it must, the nanonote has no FPU), which probably absolves it of ever being able to read a byte-code intended for vanilla lua (and vice-versa). So that's already looking kinda looking grim...

Forward compatibility is also likely to be difficult, if not impossible, to provide at the byte-code level. Again I remind you that lua 5.2 is on the horizon...

[leiradel]

Wait, what controlled environment? Due to limitations on some of the platform it links against lua statically, but on linux at least it just uses your system version.

Now that's a show stopper.