Compiling AHK v2 scripts

Get help with using AutoHotkey (v2 or newer) and its commands and hotkeys
JBensimon
Posts: 118
Joined: 19 Nov 2017, 11:19

Compiling AHK v2 scripts

Post by JBensimon » 05 Feb 2023, 11:20

Getting into v2 for the first time today, downloaded as .zip, and I notice that no .bin files are provided, so Ahk2Exe only offers compiling using the .exe's. Not a problem, but is there (or will there be) a way to prevent compiled executables from being used to run arbitrary scripts via the /script parameter?

Thanks.

Jacques.

TAC109
Posts: 1098
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Compiling AHK v2 scripts

Post by TAC109 » 05 Feb 2023, 17:16

I’m no aware of any standard method, but if you encrypt your compiled script with ScriptGuard, there is built-in prevention of using the /script parameter.

Cheers
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe

JBensimon
Posts: 118
Joined: 19 Nov 2017, 11:19

Re: Compiling AHK v2 scripts

Post by JBensimon » 05 Feb 2023, 20:15

Thank you, TAC109. I guess that will do for now, and may be beneficial for its other protections.

Generally speaking, though, does this mean that there are no .bin files for v2 and that there is no native way to prevent a compiled script from being used to execute arbitrary scripts? This could be problematic in enterprises, where compiled scripts may be installed on user machines but where IT Security doesn't want to allow the execution of unknown scripts. [Note that some security tools only allow the execution of EXE files owned by "trusted accounts", typically SYSTEM, Administrators, and TrustedInstaller, so that prevents users from downloading and using their own copy of AutoHotkey (or of any other executable), but an Administrator-installed compiled AutoHotkey script would automatically be trusted and thus open a door that should remain closed if it's capable of running scripts other than the embedded one.]

JB

TAC109
Posts: 1098
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Compiling AHK v2 scripts

Post by TAC109 » 05 Feb 2023, 23:46

I guess that you would need to take this up with @lexikos after he returns from his summer break.

Cheers
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe

lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: Compiling AHK v2 scripts

Post by lexikos » 06 Feb 2023, 01:31

A compiled script is a modified AutoHotkey binary, and the script you use to make this modification is not part of AutoHotkey itself. Thus, I do not find it meaningful to distinguish between a "native" and "non-native" way to disable the /script switch. Depending on how you look at it, there is not even a "native" way to compile a script.

What would a "native" way to disable the /script switch look like?

JBensimon
Posts: 118
Joined: 19 Nov 2017, 11:19

Re: Compiling AHK v2 scripts

Post by JBensimon » 06 Feb 2023, 04:22

Without splitting semantic hairs too much over what constitutes "native", a number of possibilities to prevent "/script" launches come to mind:
  • a documented HKLM and/or HKCU policy Registry entry that v2 interpreters would try to consult when an attempt is made to use /script,
  • a simple one-line documented compiler directive that would result in "something" that can be queried by the interpreter, maybe an added string resource or a modification to the manifest (I believe comments are allowed in manifests),
  • an installation option that would create alternative interpreters (like the current "UIAccess" alternatives) that don't obey /script and could be used as compilation bases, [I don't particularly like this suggestion]
  • back to providing .bin files [I'm guessing YOU don't like this one! ;)]
JB

JBensimon
Posts: 118
Joined: 19 Nov 2017, 11:19

Re: Compiling AHK v2 scripts

Post by JBensimon » 06 Feb 2023, 04:51

By the way, another objection to the "/script" capability, this time from the developer point of view, is the possibility that my perfectly safe, signed, and trusted compiled EXE could be used to run arbitrary code, possibly taking advantage of it having been whitelisted within some security software. Any "damage" from this foreign code would likely be forensically tied to my executable and cause me issues.

JB

JBensimon
Posts: 118
Joined: 19 Nov 2017, 11:19

Re: Compiling AHK v2 scripts

Post by JBensimon » 07 Feb 2023, 10:34

JBensimon wrote:
06 Feb 2023, 04:22
  • a documented HKLM and/or HKCU policy Registry entry that v2 interpreters would try to consult when an attempt is made to use /script,
  • a simple one-line documented compiler directive that would result in "something" that can be queried by the interpreter, maybe an added string resource or a modification to the manifest (I believe comments are allowed in manifests),
  • an installation option that would create alternative interpreters (like the current "UIAccess" alternatives) that don't obey /script and could be used as compilation bases, [I don't particularly like this suggestion]
  • back to providing .bin files [I'm guessing YOU don't like this one! ;)]
One more possibility (maybe my favorite, if feasible):
  • the v2 interpreters in a compiled script could peek at the very first line of the embedded script and decline to execute a /script invocation if it's a particular new directive, like #NoAltScripts.
The benefit of this approach is that it would require no action on the part of whoever manages the execution environment (as the policy idea would), nor from the compiler's developers, nor from the whoever writes the AHK installation scripts. Its use would be entirely in the script developer's hands.

JB

Post Reply

Return to “Ask for Help (v2)”