AutoHotkey Community

This would require that at least one instance of the script be started. As I pointed out, a debugger may be used to extract the script without letting it get to the stage where script may actually execute. In other words, no measure implemented by a script will ever be effective, since the script won't even be started. (Excluding obfuscation; I'm not sure how effective that would be.)

Perhaps I am overestimating the majority of "script kiddies." However, it didn't take me long, with a debugger in one hand and the AutoHotkey source code in the other, to extract the source of a "no decompile" script.
Though it isn't really important, the libraries used to embed or extract a script were not written by Chris. As far as I can tell, they are closed source.
This is only true while the script is starting up, between when it extracts the script from the executable and when it finishes parsing the script. After that, the script is in "semi-compiled form," which is much more difficult to spot in a debugger or memory dump. However, since the semi-compiled code structures are documented in the AutoHotkey source code, they could still potentially be used to build something similar to the original script.


As I mentioned earlier, this might be effective: replace UPX with a custom packer that implements protection measures. For instance, a custom packer might avoid ever extracting the script or AutoHotkey itself into memory if a debugger is attached. I suppose any modifications to UPX or AutoHotkey would require source code to be released.

Finding or implementing a packer with effective anti-debugging techniques will probably be difficult and/or costly. Perhaps it would be enough to implement some simple techniques.

If all the ahk commands are given equivalent functions( Edit: I meant within AutoHotkey itself ), then the following could work:

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

How come? I had quoted that I will be loading variables from an encrypted external AxM file!

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.

How about making that function in C ? Also I could use RC4 ( again in C ) for AxM

All files included, if there is not one human readable word, would it help then?



Edit: Also, is it possible to search and overwrite the contents of my AxM routine from memory ?

It might help, or it might not. If someone "decompiles" your script, they will see how it uses the C function. If you can find some way to make it very difficult to copy or debug the C function, it might work.
I'm not sure what you mean. If you mean modify the decryption routine, perhaps from within itself, that might make things difficult, especially if it can implement effective anti-debugging.

I admit I didn't think much about your obfuscation proposal. Perhaps it could be effective enough to discourage the type of user that is likely to (need to) decompile your script. If you come up with a working prototype, I'd be glad to test it for you.

I still think the custom executable packer idea has promise. It seems like the least amount of work, and also won't affect performance the way dynamic function calls will...

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.

yes

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.

lots of us actually.

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

What do you mean? All my applications are real. Seriously though I think you misunderstood me, I asked if anyone entrusts unauthorized personnel with ahk scripts that contain trade secrets in a commercial environment - because that's the only legitimate reason for code protection. A few pages back I briefly talked about billion dollar DRM technologies being compromised and whatnot, so there's nothing of interest to this discussion - AutoHotkey, AutoIt, PHP, Perl, Java, C# (CLR) and others are all vulnerable to reverse engineering and there is nothing that can be done to prevent it.

There are many things that can be done, but they are usually more complex and more expensive than the code we would write in AHK. In a million line project or in security SW they may be worth trying.

Like what? I'm interested to know. Clearly you do not know what managed code is.