And that generally speaking, there's no reason why encryption can't be used with IMXLH? Is that correct? But what you're saying here, is that this is only applicable for that particular example? (ie. 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. In the end, all squiggly bits of weirdness can be turned into readable bits of weirdness haha That file is therefore only an example of the assembler capabilities. Again, it is merely obfuscation, but encryption would be possible too.
#How to compile codejock in spanish code#
The a 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. 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). 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. It just adds another step of difficulty to the compilation process, however nothing is 100% secure. IMXLH obfuscates compiled code, however that's all it does. Haha yes that's the thing with string.dump, it doesn't like stripping. 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. 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. Even Fort Knox can be gotten to, right? (And LOL, rumor has it that the all the gold went missing from there, years ago. My general longterm thought on sourcecode protection is this: that NOTHING is impenetrable. And from what little I do understand about the process, it actually generates a very low overhead, too? Correct? So the bytecode gets encrypted on HDD - but decrypted in memory. Which can be decoded in memory, right before it gets handed off to the Lua state. 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. It's obscure and accessible to all but a few. 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. Just to illustrate the point, how many are likely able to interpret this hex dump of a 'hello world' luac binary? 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. 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.
#How to compile codejock in spanish how to#
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. It'll keep out those annoying neighbours - but not the thief with a lockpick nor the crim with a sledgehammer. 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. I'm kind of in agreement with the view that Rex has alluded to above. 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?): 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.
0 kommentar(er)
