AutoHotkey Community

[Lexikos]

[SKAN]

[Lexikos]

That can be solved with StringReplace.


Warning: Much of the following is hypothetical, thought up within the last hour or so. It is, however, based on fact, so read on if you're game.

Consider the possibilities of a custom script loader. The script loader would be stored as a regular script, but the real script would be stored in a "byte code" format of your own design.

Of course, if the source of the script loader can be ripped, it can hypothetically be used to load the script, allowing working code to be constructed. However, since the real script need not conform to AutoHotkey syntax, it may be obfuscated in ways that will make decompilation an absolute nightmare.

For instance, functions, labels and variables that do not need to be accessed via double-derefs can be completely nameless, allowing identification only by the structure's address in memory. Other structures may be given meaningless or confusing names (preferably by some automated tool, to keep the original source code maintainable.)

Built-in functions must at some point be referenced by name, so I'm not sure there's any way of preventing calls to such functions from being mapped automatically back to the original functions. This area could be obfuscated by using some obscure technique to map built-in functions to function calls (in the "byte code" format.) For instance, mapping functions by the hash of the function name, indirected through several "mapping" tables.

Commands would be difficult to obfuscate, since each line is assigned an action value which can easily be mapped back to the original command.

Note that lines of script need not necessarily be linked in a linear fashion. Any line may lead directly on to any other line, functions may contain the bodies of other functions, loops may be created by linking a line to a previous line, and the script may even alter itself at run-time. Basically, it can be made a nightmare for decompilers, without necessarily affecting performance.

I commend anyone who could follow even half of that.

Instead of waffling on forever, I will provide a link to (a thread linking to) the preliminary documentation for the functions that may make this feasible:

LowLevel & Codegen preliminary documentation

[SKAN]

[Lexikos]

The code to decrypt your AxM file would be readily available... You could make it more difficult by embedding it as a resource - which is (probably) compressed by UPX - but it could still be extracted after decompressing the script with UPX.

[SKAN]

[Lexikos]

[Oberon]

Is it really necessary to go such lengths to hide your sources? Does anybody really use AutoHotkey in a commercial environment with trade secrets that they distribute to untrusted users? There are countless ways for a saboteur to obtain sensitive information without having your compiled exe at all - identity fraud, hacking your computer, holding you in life threatening situations etc. I've already mentioned how security through obscurity provides an acute degree of protection at best so I'd like to know your reasons Skan and others, for the continued effort to practice obfuscation and encryption of AutoHotkey scripts.

[tic]

[Lexikos]

FYI, I don't plan to use any of the ideas or suggestions I have posted in this thread, personally. I have no need for compiled scripts, let alone obfuscated anti-debugging compiled scripts. I find the topic interesting is all.

[dandy]

[tic]

Oberon, is there some reason for you to believe that ahk shouldn't be used to make "real" applications?

[Oberon]

[Laszlo]

[Oberon]