Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate

Obfuscator for AutoHotkey


  • Please log in to reply
20 replies to this topic
AHKnow*
  • Guests
  • Last active:
  • Joined: --
This is related to "Securing Scripts" ( http://www.autohotkey.com/forum/viewtopic.php?t=4720 )

Was wondering if it would be possible to create an obfuscator for AutoHotkey to protect scripts that users might sell or additional protection of private company scripts from hacking.

What do you guys think?

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
Although I probably won't write one myself, I like the idea of an obfuscator because:

1) It provides an additional layer of protection for compiled scripts.
2) In some cases, it may avoid the need to compile the script (depends on the goals and needs of the author).

PhiLho
  • Moderators
  • 6850 posts
  • Last active: Jan 02 2012 10:09 PM
  • Joined: 27 Dec 2005
I don't understand. Isn't the password of ahk2exe supposed to be designed to protect from decompiling? If so, isn't that enough?
Granted, a determined individual can crack this password, at least using brute force, but this is the case for almost all software protections anyway.

If you mean an obfuscator for the source scripts, I don't see how this is possible with a standard AutoHotkey. Given the rigidity of the syntax (no multiple instructions per line, for example), this would be limited, mostly shortening variable and label/function names, etc.

Or it would need to write an alternate parser, generating the same bytecode, ie. using the same engine...

Anyway, what is the interest of giving source scripts, if the goal is to have confidentiality?
Or am I missing the point entirely?
Posted Image vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

  • Guests
  • Last active:
  • Joined: --
I like how an obfuscated script could be traded among users, but the code is protected if the author wanted it that way. The obfuscated script by itself would be much smaller (like 2k, 5k, etc...) and you would not have to combine it with the autohotkey.exe and a password to protect it.

I also could see how a user or group of user have a project or program they want to be freeware or share with everyone, but they don't want the code exposed or only want only a select group of users to know what the code is.

Overall, I see a lot of good reasons to have an obfuscator for uncompiled autohotkey scripts.

PhiLho
  • Moderators
  • 6850 posts
  • Last active: Jan 02 2012 10:09 PM
  • Joined: 27 Dec 2005
If you mean something like:
title = Untitled - Notepad
IfWinExist %title%
{
	WinActivate
}
else
{
	Run Notepad
	WinWait %title%
	WinActivate
}
being transformed to:
v001<Untitled - Notepad
c055 $v001
+c104
c007
+c023 Notepad
+c028 $v001
+c104
it can be done, with a special parser. But then, it is also easy to convert it back to real AHK code. The only thing is shortened/encrypted variable names which cannot be restored to explicit name.
Posted Image vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

toralf
  • Moderators
  • 4035 posts
  • Last active: Aug 20 2014 04:23 PM
  • Joined: 31 Jan 2005

it can be done, with a special parser. But then, it is also easy to convert it back to real AHK code. The only thing is shortened/encrypted variable names which cannot be restored to explicit name.

If you need a special parser, you could also use a encryption instead of a pure replacement. Because the system you used is easy to break (+c104 = }).

But even with a strong encryption, the plain code has to be stored to a temp-file when executed with AHK. So the code can be accessed for a split second. Of cause it would become more difficult. But then people could replace AHK.exe with a compiled AHK script that would reveal the handed over code.

Therefor I agree with PhiLho

I don't understand. Isn't the password of ahk2exe supposed to be designed to protect from decompiling? If so, isn't that enough?


Ciao
toralf
 
I use the latest AHK version (1.1.15+)
Please ask questions in forum on ahkscript.org. Why?
For online reference please use these Docs.

Koukoulina
  • Guests
  • Last active:
  • Joined: --
may be you can read that. It doesn't seems too much complicated to adapt to AHK

Laszlo
  • Moderators
  • 4713 posts
  • Last active: Mar 31 2012 03:17 AM
  • Joined: 14 Feb 2005
Toralf has a good point: AHK can only interpret unencrypted code from a file, so this temporary plaintext file has to be protected, possibly, never written to disk at all. It looks hard, and has to be done with low-level OS functions, RAM disks, etc. This is why it ought to be an AHK feature. If a script starts with a special line, like ";;;-encrypted-;;;", the interpreter could ask for a password, and decrypt the script at load time, on the fly. The encryption could preserve the line structure of the script and changing only normal letter and symbol characters, so this decryption module could be transparently inserted into the AHK line loader.

With significant performance penalty, some obfuscation can be done with an AHK script, too. Replace the instructions with function calls, where the parameters encode the original commands. The function decrypts the parameters and performs computed GoTo to a table location, where the desired instruction sits, with local variables, set after decrypting the rest of the arguments. Expression can be handled with a simple parser. It still looks like a complex coding project. This descriptor/parser/interpreter function could be a separate script, processing and executing the obfuscated script. The function calls are not even have to be spelled out, the script could read the encrypted parameters in a loop, and call the decryption function. Here a huge speedup and simplification will be possible, when AHK will allow interpreting dynamic code.

AHKnow*
  • Guests
  • Last active:
  • Joined: --
It seems AutoHotkey's cmdret.dll and/or cmdret functions could help to prevent the decrypted/plain AHK script from ever hitting the disk and give it a major advantage over how this method is used elsewhere/by other scripting languages.

Maybe, you could have an encrypt/decrypt/obfuscation function or dll. The encrypted/obfuscated AutoHotkey script could be sent to the decryption/deobfuscating function or dll via the cmdret dll or cmdret function. Thus, the decrypted/deobfuscated script never hits the disk.

Encrypted/obfuscated AHK script > decryption/deobfuscate dll/function > unencrypted/plain AHK script > cmdret dll/function > Autohotkey.exe

Just an idea.

Laszlo
  • Moderators
  • 4713 posts
  • Last active: Mar 31 2012 03:17 AM
  • Joined: 14 Feb 2005
These assume the AHK interpreter could take input from a pipe, from an environment variable, or from an AHK variable. But it only reads files.

AHKnow*
  • Guests
  • Last active:
  • Joined: --
You could also delete the temp unencrypted/plain file off of the disk pretty quickly (maybe less than 1 second) and have the location of where it is placed be random. The script could "scan" for possible locations on the disk beforehand and before selecting a random location.

Of course a more advanced solution would be better.

Laszlo
  • Moderators
  • 4713 posts
  • Last active: Mar 31 2012 03:17 AM
  • Joined: 14 Feb 2005
An adversary could run a script with Shimanov's file change notification for all the disks. When a new file is created, he quickly reads it and if it is an AHK script, writes it in another file. Automated attacks are our worst enemies, not slow responding dudes.

toralf
  • Moderators
  • 4035 posts
  • Last active: Aug 20 2014 04:23 PM
  • Joined: 31 Jan 2005
But even then I could create a compiled scipt and name it Autohotkey.exe. The exe would just post the incoming script.
Ciao
toralf
 
I use the latest AHK version (1.1.15+)
Please ask questions in forum on ahkscript.org. Why?
For online reference please use these Docs.

Laszlo
  • Moderators
  • 4713 posts
  • Last active: Mar 31 2012 03:17 AM
  • Joined: 14 Feb 2005
Although, it is a little more complicated, because you need the real Autohotkey.exe to run the first script, that is, you have to rename programs dynamically. It can surely be done.

AHKnow
  • Members
  • 121 posts
  • Last active: May 17 2009 09:11 PM
  • Joined: 03 Jul 2004

But even then I could create a compiled scipt and name it Autohotkey.exe. The exe would just post the incoming script.


In that situation, the user could use the Fileinstall command and load their own version/correct version of AutoHotkey.

An adversary could run a script with Shimanov's file change notification for all the disks. When a new file is created, he quickly reads it and if it is an AHK script, writes it in another file. Automated attacks are our worst enemies, not slow responding dudes.


I'm curious about how quickly a script with file change notification could react. The file change script would have to be scanning all the folders in every disk, because you could have a script randomly place the plain AutoHotkey script anywhere. This by itself presents an issue. The file change script would have to know that that a file was there, but would that be afterwards and too late to react. Would the "file change and read" script be fast enough to read the file before it was deleted? Obviously, the user that randomly placed the plain/unencrypted ahk script would decrease the time to the smallest interval possible.

Toralf has a good point: AHK can only interpret unencrypted code from a file, so this temporary plaintext file has to be protected, possibly, never written to disk at all. It looks hard, and has to be done with low-level OS functions, RAM disks, etc. This is why it ought to be an AHK feature. If a script starts with a special line, like ";;;-encrypted-;;;", the interpreter could ask for a password, and decrypt the script at load time, on the fly. The encryption could preserve the line structure of the script and changing only normal letter and symbol characters, so this decryption module could be transparently inserted into the AHK line loader.


Toralf's encryption solution is good, but I think the advantage of obfuscation is that you can just run the obfuscated AHK script without any passwords. The encryption method could have the same kind of ease of use, if there was a key that was used to unencrypt it. This way the script looks for the key and then just runs, if no key is found than it does not run. The script could ask you for the location of the key and then load it form that location each time, but if it did not find it than it could ask you where the new location is. I think this could be better than asking the user for the password each time the script was about to run.

If making and asking for keys is considered a bit too much, than a script that asks for the password before it is run should be still considered.

If other ways can't be found, than it appears that the AutoHotkey.exe will have to recognize encrypted scripts ( as stated by Toralf) and know to ask for the password or key file before it runs them.


Oh by the way, here is the Wiki on Obfuscated code
http://en.wikipedia....Obfuscated_code

Objuscation or additional encryption would not be the "end all" solution, it would just be an additional layer of useful protection and options for AutoHotkey users.