guest3456 wrote: ↑
07 Dec 2019, 09:43
SOTE wrote: ↑
11 Nov 2019, 23:26
I lean towards Encryptor by FeiYue (for AutoHotkey_L) or AutoHotkey_H being the better ways to protect code
have you tried combining both? is it possible to use Feiyue's encryptor with _H?
No, haven't tried that nor have seen anybody mention it. I think not so many users are heavily into protection on that level. Just the usual "compiling" (binding) to make an .exe is usually over most people's heads. If you hand the average computer user an AutoHotkey executable, they wouldn't be able to tell the difference between it and any other kind from a different programming language nor have any clue on how to get the source code. So somebody trying to reverse engineer or decompile it, will already be an unusual type of person up to something or some level of programmer. Casual programmers or IT people in a different field outside of programming might tinker around with it, but not on a serious level. So that leaves advanced level programmers, who do know what they are doing, and there is no protection against this type. Especially in an interpreted language. If given enough time, they will likely crack it. It's really more of a situation that 98% of users have no interest in going down that road, and casuals involved in IT in someway, don't know enough so will give up quickly. But if they are willing to spend enough time and/or know/learn enough, you are not going to stop them. And that's pretty much true for any programming language.
FeiYue's Encryptor is an AutoHotkey_L solution using MCode. You could use MCode with AutoHotkey_H. But if you are going that route, tinkering around with C/C++ functions, I would kind of think such a person would start modifying the source code or use the AutoHotkey DLL or EXE with another compiled programming language (Object Pascal, Go, Rust, etc...). In the case of Object Pascal, it already has automation tools, libraries, and functions. Like WinAutoKey or Simba, and you can borrow or create similar libraries or functions for a project. This also includes looking at the AutHotkey source code and creating similar functions in the different compiled language.
AutoHotkey's MCode can arguably be looked at as a kind of halfway methodology, where you like the ease of use of a scripting language with a small footprint, and just want to dip your toe in C/C++ (or some other compiled language) for something extra. Arguably the same with AutoHotkey_H, play with the C++ source code a bit, but not quite go all in with outright programming in C/C++. Except for developers of course. And for somebody at that level of programming knowledge or close, they could modify the C++ source code and make a higher security fork of AutoHotkey, beyond even what AutoHotkey_H already provides. But seems a bit odd to do this in an interpreted language, and not directly create programs in C/C++.