LÖVE

kikito wrote: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.

leiradel wrote: 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."

leiradel wrote: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.

Elvashi wrote: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.

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 )()

leiradel wrote: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]

Elvashi wrote:nLove for the nanonote (x86? whats that?)

leiradel wrote: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

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

Elvashi wrote: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.

Elvashi wrote:(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.)

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

leiradel wrote: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.

leiradel wrote: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.

bartbes wrote: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.