AutoHotkey Community

EnableUIAccess

Modifies AutoHotkey.exe to allow scripts to do the following even while UAC is enabled:

• Interact with windows of administrative programs without running the script as administrator.
• Use SendPlay.
  
  Download

Important Information:

This script modifies the executable file's embedded manifest, then creates and installs a self-signed certificate and uses it to sign the file. It will prompt you for source and destination file. If you select the same file as both source and destination, a backup copy will be created; otherwise, the script will ask you if you want to register a "Run with UI Access" context menu item. Either way, the destination file must be in Program Files or a sub-directory.

Do not modify the executable which this script creates or updates, since that would invalidate its digital signature.

The executable will not run on any other system, unless you install the certificate used to sign the file. To do this on Windows Vista or 7, right click the executable file, click Properties, go to the Digital Signatures tab, double-click the signature, click View Certificate, then click Install Certificate and follow the prompts. If prompted to select a certificate store, choose Trusted Root Certificate Authorities.

CreateProcess fails - Attempting to launch the executable with CreateProcess results in failure - "The requested operation requires elevation." This isn't a problem for the Run command since it falls back to ShellExecuteEx, but it may affect other programs which try to launch AutoHotkey (including SciTE and perhaps other editors).


Further Explanation:

On Windows 7 and Vista systems with UAC enabled, most programs are prevented from interacting with any windows which are running at a higher privilege level. For AutoHotkey, this usually means that hotkeys and Send won't work with administrative programs unless the script is also run as administrator. Running a script as administrator is fairly simple; however, it has at least two significant drawbacks:

• The need to deal with a UAC prompt each time the script starts.
• Any programs the script launches also receive administrative privileges.

Microsoft's recommended solution is to flag the application as one that needs "UI access," with the following additional requirements:

• The executable must be digitally signed with a trusted certificate.
• The executable must be in \Program Files\ or \Windows\System32\.
  (On my x64 system, \Program Files (x86)\ also seems to satisfy this requirement.)

This could be solved once and for all by signing AutoHotkey.exe before distribution, except for the following problems:

• Certificates signed by a trusted certificate authority cost money, and typically need to be renewed each year.
• If I were to buy a certificate and use it to sign AutoHotkey.exe, every time any script triggered a UAC prompt, my name would appear. I would not like that.
• If a self-signed certificate is used, it would need to be installed on each system before AutoHotkey.exe can run on that system.

Other Information:

The script can be supplied with one or two filenames on the command line, in which case it will attempt to silently create or update the destination executable file. If the script has been run before, it will reuse the "AutoHotkey" certificate created by a prior run. This certificate can be found in the user's "Personal" certificate store.

I have not tested the script with AutoHotkey Basic. It will not run on AutoHotkey Basic, but running the script on AutoHotkey_L and selecting an AutoHotkey Basic EXE as input will probably work.

I have not tested this script with a compiled script as input. Without a commercial digital signature, it probably wouldn't be very useful since the resulting EXE would not be very portable. However, it should work if given a script compiled with AutoHotkey_L v1.1.01 or later.

Wow. This is awesome! I've hated when I have one script (admin) launch a browser, then try to use a second scripts' hotkeys on it.
This also brings back SendPlay for those running UAC
Thank you for this.

_________________
Autofire, AutoClick, Toggle, Spam • Window Control Tools
Recommended: AutoHotkey_L

Fantastic!!

This should definitely be made a sticky!

This appears to break COM/IE
I get this error:
However running it normally (without the 'run with UI Access') works fine

_________________
Autofire, AutoClick, Toggle, Spam • Window Control Tools
Recommended: AutoHotkey_L

There's probably nothing I can do about that. Can you automate an existing IE session?

According to the above law - even if it would originally apply to mechanics only - by now, most if not all of the malware creators must be well documented as to how to circumvent the UAC in order to propagate the "fruit" of their twisted minds, so this UAC would not be a challenge for them anymore. On the other hand, the unaware user, being more and more pushed aside and out of the internals of the operating system, would have a hard time running their daily, valid applications, raising the frustration level. And indeed, this seems to be the only result of this UAC implementation. Personally I don't know one Vista/7 user that doesn't have UAC disabled following their getting fed up with its prompts and limitations.
I could get more into the opacity of the current (and definitely future) Windows OS versions, but it would be off-topic and unneeded. Thing is, all this struggle from Microsoft to keep users completely blind in respect to what the OS is and does as well as limiting users' rights and possibilities on their own hardware while using an OS that they paid for, makes me feel lucky for being poor, thus unable to "upgrade" hardware and software and become "one of the crowd".

Please, take the above rant purely as an act of freely speaking one's mind, completely unrelated to Lexikos' otherwise very well appreciated work; it just happened to "fall into" this topic, is all. And well, I also needed to post something in order to receive updates, in case I ever decide to make my scripts AHK_L compatible or in other way needed the information in this topic.

_________________
AHK tools by Drugwash (AHK 1.0.48.05 and Win98SE)

Well sure, and its also not a problem to just run it as admin instead of using the UI Access whenever I need COM. It was just a hard-to-track bug.

_________________
Autofire, AutoClick, Toggle, Spam • Window Control Tools
Recommended: AutoHotkey_L

Hello:

Is it possible to use this functionality to create digitally signed compiled scripts, as requested in http://www.autohotkey.com/forum/topic56500.html

Perhaps instead of generating the self-signed certificate, an (optional) dialog could ask the user to provide a PFX or PVK certificate s/he already has, perhaps even from Verisign et al?

This would also eliminate Lexiko's issue:



by enabling users to roll their own (custom/in-house) autohotkey.exe with their personal certificate attached to it.

Thanks for your consideration, Achim

You can edit the following to use a different certificate:

My issue was with the effects of pre-signing the executable. Requiring users to use their own certificate is no more a solution than providing this script (either way they need to specifically sign the executable).

This needs to be added to the documentation on SendPlay

_________________
Autofire, AutoClick, Toggle, Spam • Window Control Tools
Recommended: AutoHotkey_L

Excellent: that does the trick to select an already installed 3rd party Authenticode certificate. In combination with an updated call to this produces compiled, UAC-compliant signed AHK binaries!



We are saying the same thing: don't sign the default autohotkey.exe, but give users the ability to do so: just like you did!

An addition: in order to make timestamps work, I added this to SignFile.ahk immediately after the call to SignerSign:



Passing the timeserver variable directly in SignerSign should work in theory, but does not always in practise, as some other people also figured out: http://blogs.msdn.com/b/alejacma/archiv ... 70020.aspx

As a result, we first sign the binary, and then timestamp it.

Hope this is helpful for somebody?

Best regards, and thank you again, Achim

Thanks. I was wondering how to do that, though I don't have any use for it personally.
That's what I thought, but couldn't get it to work.

Great stuff. Thanks so much for this! I was scratching my head trying to figure out why my global keyboard hooks were not working while an "elevated" app was in the foreground. Some searching led me here, and after applying the manifest patch, my script is working universally now without needing to launch the main process with elevated privs.

I realize that a "real" certificate is expensive but surely the community could chip in yearly for this, each member giving $1 or something and get you to the goal amount? Or maybe I am too optimistic?

The bigger problem is that a proper certificate would have my name on it, essentially giving the impression that every script which triggers a UAC prompt is published by me personally.

Thank-you, Lexikos!

For others who may be as unclear as I was as to what, in lay terms, this achieves, one thing is - it lets you run a script from the startup folder.

My case: running Win7 with standard-level UAC, no script would launch from Startup. So I tried something mentioned in this thread - starting as a logon task in Task Manager, with elevated authority. That worked until I added Fileread operations. Other scripts did them fine, but not the startup script. No error message, no prompt - just failure. I eventually got suspicious of UAC, and tried exiting and manually starting the script (including the dim-screen authorization prompt) - which then read files. So TM's elevated privileges are not as good as those conferred when prompted, and not enough to read a file.

Tried what this post advises - putting a shortcut to AHK.exe in startup - hoping to add the script as argument, start it that way. But - add the argument, and the app won't start. So you can't actually launch a script.

Installed this patch, and my script starts & loads variables from file without a hitch - and all scripts run without the screen-dimming UAC challenge.

I think this ought to be put prominently in the path of the frustrated novice. (I tried to put a plug in the Wiki, where there's an FAQ about this, but the member list seems to be closed: the "login/signup page" has no signup area.)