AutoHotkey Community

[Laszlo]

[Oberon]

Obfuscation does not prevent reverse engineering, it can only slightly slow down an attacker. Essentially all you achieve is higher entropy of the same set of instructions, not encryption. Even lower level polymorphing code run under secure VMs are susceptible to physical memory based hacks. Remotely run applications can also be compromised with DoS related exploits. Isn't it ironic how you use ideas that you've already contested yourself.

[Laszlo]

[DerRaphael]

obfuscated ahk code example:

[Laszlo]

It is still too simple, but a more complex version would be useful. It could implement mutual recursive function calls, dynamic fuction calls, where the function names are computed, dynamic variables, where their names are computed by complex functions, hotkeys are replaced by sytem calls, fake system calls are inserted, lots of GoTo's... It would make decoding harder. This obfuscator has to process your script before compiling, otherwise you would never find a bug.

[SKAN]

[Laszlo]

I don’t think cryptic variable names help much. The attacker can just rename them to A, B,... Also, if you make a simple function name assignment (jh5438758jcsw=MessageBox), this one level indirection is easy to decode. You should compute the string MessageBox from several pieces, treated as a base64 number, etc., and the instructions should be in different subroutines. Until we don’t have several thousand commands, the obfuscation is not very effective. But then it slows down your script.

[SKAN]

[Lexikos]

Since the script must be able to load the variables, how will you prevent a hacker from simply using the script to decrypt it for them? Whatever methods you use to retrieve a key and decrypt the file will be practically in plain sight. Even if it is obfuscated, a hacker may still use it without knowing how it works.

That is, assuming that anyone competent enough to extract a script from a "no decompile" executable will also be competent enough to edit the script...

On the other hand, if you use a custom script loader - i.e. convert the script to byte code, as Adam suggested - even if someone extracts the script, they will not be able to see how it works or edit it unless they understand the byte code format, which is unlikely. It shouldn't be very difficult: load the script as normal, call some function which dumps the code structures, and write and compile a script to load the structures back into memory. Of course, I haven't released the necessary functions yet... (Maybe I should spend less time arguing. )

[Laszlo]

[SKAN]

[Laszlo]

[Guest]

here's the thing, even if you are a supergenious and can use the code, theres other supergeniouses who are smarter than you who will figure out how to do it anyway.

There are windows APIs to see if debuggers are attached. There are countermeasures the hacker can take to fool the API (eg by detouring it, or by modifying the debuggerpresent flag in memory). There are countercountermeasures that the developer can take (checking to see if the api isnt hooked, verifying the flag in memory). There are countercountercountermeasures the hacker takes to get around that.

If your script is valuable enough to someone, it will get cracked. Look how much money the music industry is throwing at music encryption technology, and pirates still get hacks to remove the protection.

[Laszlo]