Request for Lua Script Compiler GUI

[Imagine Programming]

Am just experimenting with some of Riz's old Base64-Blowfish examples to see how they may be further 'hardened - for use in the graphic tutorial mentioned up top.

Ah okay, clear enough!

[BioHazard]

Am just experimenting with some of Riz's old Base64-Blowfish examples to see how they may be further 'hardened - for use in the graphic tutorial mentioned up top.

[Imagine Programming]

BioHazard what is it precisely that you want to encrypt? If the algorithm is known, but the key is not / keys are not known, then encryption is perfectly fine.

[kingzooly]

Some more musings on sourcecode protection / obfuscation:

@kingzooly

Hey Rex,
Years ago you were working on a RAMDisk project as a means of addressing the security-flaw associated with using encryption in AMS. The idea was to have AMS use RAMDisk space as an alternative to dumping unencrypted strings to a temp file during the decryption process. The most recent post I can find about this project is one from 2010, here: https://forums.indigorose.com/forum/...649#post243649

Did anything more ever became of this project? Or did development stop there?

.................................................. ...............................

PS.
Also, you mentioned above about compiling your sourcecode as a plugin, instead of compiling it to bytecode? Do you (or anyone else for that matter) know how one might go about compiling Lua sourcecode as a standard DLL? (ie. not a plugin but a standard DLL)

I was thinking along the lines of compiling it as a PureBasic DLL, for instance? Is this easily do-able? Or would the entire Lua sourcecode have to be re-expressed as a set of PureBasic functions first?

This is just a quick reply I am moving in a day so I don't have time to look back but give me a week and I will give the ram disk a look again I do have a few drives that might have it still on so I can see if it matchs if I still have it.

[BioHazard]

Some more musings on sourcecode protection / obfuscation:

@kingzooly

Hey Rex,
Years ago you were working on a RAMDisk project as a means of addressing the security-flaw associated with using encryption in AMS. The idea was to have AMS use RAMDisk space as an alternative to dumping unencrypted strings to a temp file during the decryption process. The most recent post I can find about this project is one from 2010, here: https://forums.indigorose.com/forum/...649#post243649

Did anything more ever became of this project? Or did development stop there?

.................................................. ...............................

PS.
Also, you mentioned above about compiling your sourcecode as a plugin, instead of compiling it to bytecode? Do you (or anyone else for that matter) know how one might go about compiling Lua sourcecode as a standard DLL? (ie. not a plugin but a standard DLL)

I was thinking along the lines of compiling it as a PureBasic DLL, for instance? Is this easily do-able? Or would the entire Lua sourcecode have to be re-expressed as a set of PureBasic functions first?

[BioHazard]

... I don't mean you shouldn't implement encryption at all ... Encryption can always be used ...

Thanks for clarifying, IP .. was hoping that was the case!

I assure you that my coding skills are like Karate Kid skills compared to some people ...

Modesty - more proof of an awesome, sensei.

[Imagine Programming]

Righty-o then. Thanks for that, sensei. Could you clarify a point though? In the documentation for IMXLH, you warn not to use with encryption? Thereby suggesting that it shouldn't be used at all. But what you're saying here, is that this is only applicable for that particular example? (ie. hide-mem.lua). And that generally speaking, there's no reason why encryption can't be used with IMXLH? Is that correct?

It's hard to fugure out because you're coding is so advanced. And (LOL) has a tendencty to give me brain aneurysms. I assume though (from what you're saying here) is that by using encryption with IMXLH, it's not going to give the end user's computer a similar aneurysm???

I swear IP, if coding were kungfu, you'd be like one of those shaolin monks whose powers of levitation leave all his students completely mystified.

With that notice in the Manual I mean that when you develop an encryption method for your software, you shouldn't store any key pair or password in an LH file; I don't mean you shouldn't implement encryption at all. I might have to clarify that, I haven't read the manual since the last update of IMXLH and MemoryEx haha! Encryption can always be used, if you store the shiny key in your not-so-shiny pocket where people can't see it

I assure you that my coding skills are like Karate Kid skills compared to some people, man there are some Jackie Chan's out there!

[BioHazard]

... Again, it is merely obfuscation, but encryption would be possible too. That file is therefore only an example of the assembler capabilities...

Righty-o then. Thanks for that, sensei. Could you clarify a point though? In the documentation for IMXLH, you warn not to use with encryption? Thereby suggesting that it shouldn't be used at all. But what you're saying here, is that this is only applicable for that particular example? (ie. hide-mem.lua). And that generally speaking, there's no reason why encryption can't be used with IMXLH? Is that correct?

It's hard to fugure out because you're coding is so advanced. And (LOL) has a tendencty to give me brain aneurysms. I assume though (from what you're saying here) is that by using encryption with IMXLH, it's not going to give the end user's computer a similar aneurysm???

I swear IP, if coding were kungfu, you'd be like one of those shaolin monks whose powers of levitation leave all his students completely mystified.

[Imagine Programming]

Haha yes that's the thing with string.dump, it doesn't like stripping.

IMXLH obfuscates compiled code, however that's all it does. It just adds another step of difficulty to the compilation process, however nothing is 100% secure. IMXLH was made to allow modular programming with complete WinAPI interfacing (hence the MemoryEx plugin) with a little additional sense of security, however I always warn people to not use Lua when they want their code completely protected.

In the end, in AMS, the byte code that is executed by AMS' Lua implementation needs to follow the Lua 5.1 rules and thus can be caught in memory and reversed back to somewhat readable Lua code (when the debug information was stripped).

The hide-mem.lua example is merely an example which uses the assembler of IMXLH (Flat Assembler) to compile a chunk of x86 32-bit executable code that allows you to obfuscate a block of memory. Again, it is merely obfuscation, but encryption would be possible too. That file is therefore only an example of the assembler capabilities.

In the end, all squiggly bits of weirdness can be turned into readable bits of weirdness haha

[BioHazard]

Thanks for the feedback, guys. I actually requested Shadow's little creation because I'm in the process of making a graphic tutorial. And just wanted to include something with a GUI. Interacting directly with Luac via the command-line tends to scare off the n00bs. So thought this might be a 'gentler' means of introduction. Will probably just end up using my own GUI instead, though. Here's where it's at thus far:



Looking kinda sexy with that Codejock skin, don't ya' think? .

.................................................. ..........

As kingzooly says, beware; Lua bytecode is quite easy to reverse...

Given the prevalence of decompiling tools such as LuaDec and UnLuac, yes, I'd concur with that observation. But at risk of beating a dead horse, these are my thoughts on the matter (LOL, didn't we already, all discuss this topic about a hundred times, over the years?):

I'm kind of in agreement with the view that Rex has alluded to above. And here's why: Have always seen the idea of trying to protect sourcecode as being akin to putting a deadlock on one's front door. It'll keep out those annoying neighbours - but not the thief with a lockpick nor the crim with a sledgehammer.

Nevertheless, how many users actually possess sufficient insight to attempt decompilation in the first place? I'd speculate it's maybe one-in-a-hundred who even know what bytecode is? Let alone how to decompile it. And those who actually do know, soon discover that popular decompilers like LuaDec and ChunkySpy fail when the bytecode has been stripped of its debugging info.

Which leaves, how many? The cluey few who can read and interpret the contents of a Hex dump from a stripped file? I'd venture to speculate it'd be just a handful of a few. Just to illustrate the point, how many are likely able to interpret this hex dump of a 'hello world' luac binary?



Looks like absolute 'greek' to me! And this one still has its debugging info! So, you get where I'm coming from, yeah? It's a niche field of knowledge. It's obscure and accessible to all but a few.

Just in furtherance to this line of thought: A secondary measure can always be employed by also encrypting the bytecode with something like an AES-256 algorithm standard. Which can be decoded in memory, right before it gets handed off to the Lua state. Correct? So the bytecode gets encrypted on HDD - but decrypted in memory. And from what little I do understand about the process, it actually generates a very low overhead, too?

My general longterm thought on sourcecode protection is this: that NOTHING is impenetrable. Even Fort Knox can be gotten to, right? (And LOL, rumor has it that the all the gold went missing from there, years ago. Hee-hee-hee). So one's aim IMHO, should be to obfuscate up to (and only to) the point necessary, where the effort required to break in, outweighs the potential rewards for doing so. And how does one decide where this point is? Well, how long is a piece of string? And no matter how long you make that piece of string, someone will always reach its end.

... Especially when the code isn't stripped from its debug information.

Yes, as a matter of standard practice, I'd certainly encourage inclusion of an -s (strip) parameter when interfacing with Luac via the command-line.

luac -s input.lua (outputs default luac.out - debugging stripped)
luac -s -o output.luac input.lua (ditto with custom ouput name)
luac -o myLuacStripped.luac myLuaScript.lua (custom ouput name - no stripping)

... And in addition to improved security, it also reduces filesize somewhat.

You can also do it from AMS if you'd like, string.dump does it for you.

Yes, instead of Luac, the Lua interpreter is used for the compiler, right?
So then, like this, sensei?

local file = io.open("output.luac","wb");
input = loadfile("input.lua");
output = string.dump(input);
file:write(output);
file:close();

But as I understand it, when using this method in Lua5.1, there's no way to apply stripping of the debug info? There's no '-s' (strip) parameter for the string.dump() command, right? Only became possible in Lua5.3, I think?

LOL, with all this talk about 'stripping', thread's becoming positively XXX rated!

Hey, I've been reading up about your IMXLH Compiler, IP. Which 'seems' to be the next logical step in terms of getting more serious with the bytecode process. I don't quite yet understand how it obfuscates, though? The documentation warns not to use it for encryption? How exactly does it hide the data in memory ... you kind of 'lost me' there in the hide-mem.lua example? Damm, IP - I just can't keep up with your lethal ass!

Y'know, Con-the-Fruiter might be my role-model ...


"Ahhhh, duzzn't mutter."
"Cuppla dayzzz!"

... But we Lua aficionados really do bow before the alter of IP before booting up our laptops each day!


"squiggly bits of weirdness!"

- LOL

[Imagine Programming]

Nah, it's v5.1 apparently. Gonna compile me some bytecode! (or "squiggly bits of weirdness" as IP once called it)
Mmmm, bytecode. Yum!

You can also do it from AMS if you'd like, string.dump does it for you. As kingzooly says, beware; Lua bytecode is quite easy to reverse. Especially when the code isn't stripped from its debug information.

[kingzooly]

These days if I really want to hide it I just don't make it lol or I will make it as a plugin, not as easy to just see it in plain lua

[BioHazard]

Nah, it's v5.1 apparently. Gonna compile me some bytecode! (or "squiggly bits of weirdness" as IP once called it)
Mmmm, bytecode. Yum!

[kingzooly]

Isn't that for a older version of Lua ? I sure it's for lua 5

[BioHazard]

Awesome. Thanks very much!