Protecting Source?

[Sparx]

Hi there,

is there a possibility of protecting the source of a game made with LÖVE?

[bartbes]

You can compile them to some bytecode (using luac from the lua package), but the question is how safe that is.., but generally speaking there is no effective way.

[osuf oboys]

Could also make a program that takes the source and produces something horribly obscure.

[bartbes]

Or you can download the source everytime you start, but I don't think that's practical.

[Gerrit]

You can compile them to some bytecode (using luac from the lua package), but the question is how safe that is.., but generally speaking there is no effective way.

That would be the best way and 95% of the people who would be interested won't try to do anything about it. The last 5% may try do decompile it. But you can decompile almost anything. There's no 100% safe thing.

Or you can download the source everytime you start, but I don't think that's practical.

That would be a bad idea because the source has to be saved somewhere. At least in RAM which you can read out with a program. If you do it encrypted there's the point where you have to encrypt it (to use it yourself) to RAM and you can read it out there again.

Short: Use LUAC to make it safer. There's no 100% protection and there won't be (ever). If you protect it better there will be more people attracted to it (to crack it). So keep it simple

[osuf oboys]

That would be a bad idea because the source has to be saved somewhere. At least in RAM which you can read out with a program. If you do it encrypted there's the point where you have to encrypt it (to use it yourself) to RAM and you can read it out there again.

Short: Use LUAC to make it safer. There's no 100% protection and there won't be (ever). If you protect it better there will be more people attracted to it (to crack it). So keep it simple

Obfuscating does not mean during run-time or encryption. The obfuscated code should work as it is, just doing plenty of unnecessarily complicated and nonsensical things. The code could certainly be worked out but it would take plenty of time, sort of like working out what a program does where from reading the assembly code.

[Sparx]

Perhaps i could just encrypt the zip-file with a password and then loading it into LÖVE via a CLOSED-SOURCE library integrated in the compiled LÖVE binary?

[appleide]

If you open binaries as plain text you can see their strings. Then look for the password.

Could also decode the binary file to assembler. Since all your program does is feed the password to the zip file to open it, it shouldn't be too complicated. You'd need to deliberately obfuscate it.

On some systems you can keep malloc(...) and see the contents of used memory. So after shutting down the closed source lib you could repeatedly run malloc and reading contents until you find string likely to be password.

I learnt all this in uni lectures. Fun turning up to class.

[Gerrit]

Perhaps i could just encrypt the zip-file with a password and then loading it into LÖVE via a CLOSED-SOURCE library integrated in the compiled LÖVE binary?

That would be possible. Although you have to save the key in the binary then which means that I could just decompile the orginal Löve binary, then yours and look at the differences. And in a couple of minutes I should find the key As I said: there's NO solution to protect your source 100%. You can only make it harder for those that are interested. Since you need to know assembler after compiling to LUAC there shouldn't be many people left

PS: appleide was a bit faster then me..

[osgeld]

i thought luac would leave the source script in the comments