Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Party member
Posts: 184
Joined: Thu Mar 11, 2010 3:40 am
Location: Lisbon, Portugal

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.
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
Inner party member
Posts: 3650
Joined: Mon Jun 22, 2009 9:35 am
Location: Pennsylvania, USA
Contact:

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
Prole
Posts: 45
Joined: Sat Jul 04, 2009 9:17 am
Location: Australia

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."
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?
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.
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'.
"We could make a program for doing this for you, but that is for the LÖVE IDE, planned to be released in March 2142." ~mike
Networking with UDP uLove Proposal CCG: Gangrene

Party member
Posts: 184
Joined: Thu Mar 11, 2010 3:40 am
Location: Lisbon, Portugal

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.
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
else
-- Run the big endian bytecode
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
Prole
Posts: 45
Joined: Sat Jul 04, 2009 9:17 am
Location: Australia

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]
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.)
"We could make a program for doing this for you, but that is for the LÖVE IDE, planned to be released in March 2142." ~mike
Networking with UDP uLove Proposal CCG: Gangrene

bartbes
Sex machine
Posts: 4946
Joined: Fri Aug 29, 2008 10:35 am
Location: The Netherlands
Contact:

Elvashi wrote:nLove for the nanonote (x86? whats that?)
MIPSel actually.
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
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.

Party member
Posts: 184
Joined: Thu Mar 11, 2010 3:40 am
Location: Lisbon, Portugal

Elvashi wrote:... 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.
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.
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.
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.)
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
Prole
Posts: 45
Joined: Sat Jul 04, 2009 9:17 am
Location: Australia

leiradel wrote: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.
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.
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.
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.
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...
"We could make a program for doing this for you, but that is for the LÖVE IDE, planned to be released in March 2142." ~mike
Networking with UDP uLove Proposal CCG: Gangrene