Compiling AHK v2 scripts
Compiling AHK v2 scripts
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.
Thanks.
Jacques.
Re: Compiling AHK v2 scripts
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
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
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
Re: Compiling AHK v2 scripts
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
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
Re: Compiling AHK v2 scripts
I guess that you would need to take this up with @lexikos after he returns from his summer break.
Cheers
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
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
Re: Compiling AHK v2 scripts
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?
What would a "native" way to disable the /script switch look like?
Re: Compiling AHK v2 scripts
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! ]
Re: Compiling AHK v2 scripts
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
JB
Re: Compiling AHK v2 scripts
One more possibility (maybe my favorite, if feasible):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! ]
- 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.
JB