AHK Script Encryption Topic is solved

[guest3456]

Is there a way to make the software connect to the web and verify the user and then temporary download encrypted items or to memory? I don't know a lot about this.

yes, iv'e done this with one of my ahk scripts. however, i don't see why someone couldn't just scan the memory and grab the script after its decrypted

Another approach might be to compress your exe with a modified UPX which obfuscates its decompression to fool the payload method used by the ahk decompiler tool.

https://dl.packetstormsecurity.net/papers/general/Using_UPX_as_a_security_packer.pdf

if you accomplish this, i'd be very grateful if you shared the method with us

[pneumatic]

For large scripts (eg. 40,000 lines) decryption on exe launch is slow. Around 3-4 seconds with CPU pegged at 100% on an i7-4790k.

That was on Win10 btw. On Win7 I'm finding it only adds ~1 second load time, which is totally fine. No third party antivirus installed on either.

edit: but on my Win7 laptop it won't launch at all ("the application was unable to start correctly 0xc000007b"). So my fears about _H being less reliable were justified it seems.

if you accomplish this, i'd be very grateful if you shared the method with us

Of course I would, but I'm not knowledgeable enough. It would have to be someone fluent in C++ and already knows a lot about PE files and associated WinAPI functions.

[SOTE]

For large scripts (eg. 40,000 lines) decryption on exe launch is slow. Around 3-4 seconds with CPU pegged at 100% on an i7-4790k.

That was on Win10 btw. On Win7 I'm finding it only adds ~1 second load time, which is totally fine. No third party antivirus installed on either.

edit: but on my Win7 laptop it won't launch at all ("the application was unable to start correctly 0xc000007b"). So my fears about _H being less reliable were justified it seems.

You might want to post specifics about that on the AutoHotkey_H sub-forum. Perhaps it's author, HotKeyIt might have the answer or suggestion.

[HotKeyIt]

It seems that some machines are missing some required dlls, simply download and install MS Redistributable.
Btw MT_... versions should not have that problem!

Microsoft Visual C++ Visual Studio 2017
X64: https://go.microsoft.com/fwlink/?LinkId=746572
x86: https://go.microsoft.com/fwlink/?LinkId=746571

[SOTE]

So I managed to recompile AHK_H in VS2017 with a custom encryption password.

It works! But ultimately I might not use it. Here's why...

1. For large scripts (eg. 40,000 lines) decryption on exe launch is slow. Around 3-4 seconds with CPU pegged at 100% on an i7-4790k. On a low spec system (eg. dual core laptop) this could be a long wait. If I could put up a splash screen letting the user know it's loading, maybe that would be acceptable. Since my script runs at Windows startup too, that's a 3-4 second 100% CPU burst at every Windows startup. That snappy instant portable feeling of ahk is lost a bit. Though once the script is running, performance appears to be fine and normal.

There are several "tricks" for speeding up script execution. You should probably try them out and see how it goes.
https://www.autohotkey.com/boards/viewtopic.php?t=6413
(How to optimize the speed of a script as much as possible.)

I suppose if you went crazy and tried everything at once, it might look something like this at the top of the script. Though I would recommend being much more conservative and figure out what each does and if you really want each one.

Code: Select all

#NoEnv
#MaxMem 512 ; change number based on your situation
#MaxHotkeysPerInterval 99000000
#HotkeyInterval 99000000
#KeyHistory 0  ; this and below are good ones to use
ListLines Off ; good one to use in many cases
Process, Priority, , A  ; be careful, be sure script plays well with other programs
SetBatchLines, -1  ; be careful, can be less aggressive so script plays well with other programs
SetKeyDelay, -1, -1
SetMouseDelay, -1
SetDefaultMouseSpeed, 0
SetWinDelay, -1
SetControlDelay, -1
SendMode Input

In addition to this, AutoHotkey_H is multi-threaded versus AutoHotkey_L being single-threaded, so if you go that route, you might want to study up on how to use multi-threading.

[pneumatic]

There are several "tricks" for speeding up script execution. You should probably try them out and see how it goes.

The sustained 4 second CPU load occurs before the first line of ahk code is even executed. The fact that it doesn't occur on my Win7 machine leads me to speculate that it's not actually Ahk_H busy decrypting the script, but rather Win10's built in antivirus having a long hard look at it, trying to figure out if it's malicious, possibly running it in some kind of sandbox mode. Again no 3rd party antivirus.

Btw MT_... versions should not have that problem!

Thanks!

[SOTE]

There are several "tricks" for speeding up script execution. You should probably try them out and see how it goes.

The sustained 4 second CPU load occurs before the first line of ahk code is even executed. The fact that it doesn't occur on my Win7 machine leads me to speculate that it's not actually Ahk_H busy decrypting the script, but rather Win10's built in antivirus having a long hard look at it, trying to figure out if it's malicious, possibly running it in some kind of sandbox mode. Again no 3rd party antivirus.

Btw MT_... versions should not have that problem!

Thanks!

AHK_H is usually well behaved in my experiences, almost as much as AHK_L, so it's hard to say what might be your issue or what your code is doing. You can submit false-positives to Microsoft and other companies (https://www.autohotkey.com/boards/viewtopic.php?f=17&t=62266). Microsoft is very good at giving you tracking information and reporting the results of their findings pretty quickly.

It's not clear what version of AHK_H that you are running as well, as sometimes that can be a factor with Anti-Virus companies. Often the latest version, because AV companies haven't updated their databases yet (and can be quite lazy about getting around to it unless pushed by users), or very old versions (5 years old or more) because nobody was submitting false-positive or requests to have them update their databases, so they still have incorrect information in their databases. Another thing, if you are running the program on computers or networks that you control, you can configure your Anti-Virus to make an exception and leave the AutoHotkey programs alone This is after you verify that you downloaded an official and authentic version of AutoHotkey, and clarify that any 3rd party add-ons or includes you are sending with the program is not an issue

[guest3456]

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?

[SOTE]

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++.

[guest3456]

For large scripts (eg. 40,000 lines) decryption on exe launch is slow. Around 3-4 seconds with CPU pegged at 100% on an i7-4790k.

That was on Win10 btw. On Win7 I'm finding it only adds ~1 second load time, which is totally fine. No third party antivirus installed on either.

i've just built AHK_H with custom pw

my script is large also, approx 30,000 lines after all libs are included

i'm seeing:
~3s load time on my win10 laptop
~2s load time inside win7 vm

both with windows builtin antivirus just like you. not terrible

[SOTE]

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?

I have revisited this question and looked into a bit more. Also, as part of that question, we can include MCode as well, as something that could be added separately from just Feiyue Encryptor. Yes, it's possible to combine both. However, it would arguably provide only a marginal increase in protection, because of the tools that can be used by hackers/crackers.

If such attackers are so sophisticated as to crack open a AHK_H executable, having to deal with MCode as well may slow them down a little. But it would be no more difficult for them to attack it than a normal compiled binary (like C/C++, Pascal, Go, Swift, etc...). They would convert machine code to Assembly, which can also be converted into pseudo C code for increased readability by various tools. They would not get the exact source code, but probably would be able achieve a decent understanding of what that section of code does. Such sophisticated hackers/crackers would likely be able to read/understand a decent level of Assembly and/or C code. We must also combine this that they can spend weeks or months examining the executable for any weaknesses and information. And to be clear (for casual users), such vulnerabilities are not specific to AutoHotkey, but to software in general, no matter what language.

Consequently, I stand by earlier comments that legal protection has greater value. Lawless people will likely always be outside of any circle of friendship, value, or business to the author. A programmer should arguably never have the expectation of ever creating a hackerproof application. The probably better weapon would be for the author to attempt legal action against such hackers/crackers and ISPs, when found.