You're sure it was your code signing one and not one created by the script after you changed the name to "my_cert.pfx"? Since you don't know how to re-install the certificate, I wonder how you would have installed it in the first place. (Double-clicking the pfx file should start the install wizard.)using certmgr checked personal certificates to find Autohotkey one plus my code signing one
Enable interaction with administrative programs
I built a downloadable utility using Ahk - compiled it to an exe and packgaged it to a setup.exe using smart install maker and it works well. But most of my potential users are put off by the warnings of virus / malware that browsers provide when downloading the software. To solve this I was advised to buy a code signing digital certificate from COMODO that I now want to apply to the packaged download - so my users will have the assurance that it is valid and comes from me.
To answer your question - certificate was supplied and installed by Comodo using IE directly with their website. They provided instructions to make back up file but none that I found so far on re-instatement. (must be possible - I tried double clicking on pfx file and using wizard but no sign of new or duplicate certificate when using certmgr.msc).
Also I think the original certificate is intact because it shows Comodo as source plus all relevant validity dates purposes etc seem intact as per original and not Ahk.
Before coming to the AHK community I used the standard windows signtool and am able to sign either the compiled exe from my AHK script or the setup.exe produced by Smart Install Maker the package builder. Comodo support identified the issues that I was having as specific to the AHK code.
Clearly you understand these security issues and I was hoping for a solution. So last plea - is there a solution to this problem and if so where do I find it? PS many thanks to you for the support you have provided - it really is appreciated -
I have applied it to two versions of the RTM Window 8. The enterprise one worked immediately but I had problems with the professional. I'm not certain if I was using a different approach on Pro (missed steps?) but I did resolve it in the end by launching a version of Explorer with administator privileges and then also launching the script "run as administrator."
Now it works perfectly which is a relief.
Note: I required this to get SendPlay to work on AutoHotkey_L_Install.exe version 1.1.08.00
I just tried again with 1.1.08.01 and the script was still required to get SendPlay to work.
If I wanted to set uiAccess="true" in the manifest of another executable, however, can an AutoHotKey script do that? I'd like to do this for Logitech's SetPoint.exe itself so it can send Alt+Tab directly instead of having to call an ahk each time (which is slower and less reliable). Could I modify your script to change the manifest for SetPoint.exe instead of AutoHotkey.exe, and if so, how?
Thanks again.
But that won't work. The script cannot sign an executable that has already been signed. SetPoint.exe has been signed by Logitech. You will need to remove this signature. To do this, you can use delcert.exe.
Furthermore, the script was unable to handle the XML namespace prefix used in SetPoint.exe's manifest. I have fixed this. You will (of course) need to download the script again.
Note:
- Make a backup copy of SetPoint.exe before modifying it.
- I have not tested the patched SetPoint.exe, as I have UAC disabled.
- Currently the script does not support exe files that do not have a manifest resource.
I was able to successfully resign and change the manifest with delcert.exe and your tool. SetPoint.exe does launch. However, it only shows an about tab and basic software settings tab, and it is missing all the options for configuring my mouse. In essence, all functionality of SetPoint for my mouse was somehow removed during the process of resigning and setting UIAccess="true".
Here's a screenshot to illustrate the problem:
I'd happily settle with launching an ahk to send Alt+Tab, but if you're willing to look into the problem, I'd definitely appreciate it, and I thank you for all that you've done so far to solve my problem.
Here's a link to download the original and new SetPoint.exe's if you'd like to take a look:
http://www.mediafire.../?icjm23i6dhglc
Maybe this is trivial, but I can't figure it out... how would a script be started at log of an user (with admin privileges) with "Run with UI Access"?
I thought about adding a task in the the task scheduler or putting a shortcut in the startup folder, but I'm not sure how to include the "Run with UI Access" option.
Start the exe which you created using this script and pass the path of your script as an argument.
That seems to work. Thanks a lot!!
Will you please provide the steps to get this technique to work with AutoHotHey 64 bit on Windows 8? I downloaded, extracted and ran the script. The AutoHotKey.exe file in the C:\Program Files\AutoHotkey\ folder was modified with today's date. The AutoHotkeyA32.exe, AutoHotkeyU32.exe and AutoHotkeyU64.exe files were not modified from their December 24th creation dates. When I performed the express install of AutoHotKey I believe it installed the AutoHotkeyu64.exe version of AutoHotKey on my 64 bit machine. I ran a script that includes the following line code after I rebooted after I downloaded and ran the script provided in this blog::
Run C:\Program Files\Microsoft Office\Office14\winword.exe /q /t "C:\Users\Me\Desktop\test.rtf"
The above AHK command successfully opened the rtf document in Word in 64 bit Windows 8, as it has been doing for quite some time in 32 bit Vista.
The AHK script completely stopped functioning after the above code was executed as evidenced by the observed behavior when I include via copy and paste immediately after the above Run command an AHK MsgBox command that worked perfectly twice earlier in the script before the run executed, that not even the MsgBox would display. Instead, executing the run command in 64 bit Windows 8 in an AHK script that works in Vista causes that same script to stop working in Windows 8.
I love AHK! But since switching to Windows 8 I can't get it to work like it did before. Scripts won't run on startup and "Send {Alt down}{Tab}{Alt up}" doesn't work either.
I've tried everything and as far as I can tell the AutoHotkey.exe was signed.
Here's the result:
This was my latest attempt. I'm running W8 Pro x64 and here I tried signing it again for the 32-bit exe, since I thought maybe 64bit gave issues.
I also tried Task Scheduler to the AutoHotkey.exe with my script as parameters and "Run with highest priviliges" but the result is always the same: "The requested operation requires elevation. (0x800702E4)".
I don't know what to do anymore, I've tried everything in my powers and knowledge but this stupid Windows 8 thing just won't let me run it.
What else I've tried:
* 32bit exe
* 64bit exe
* "Run as administrator"-checkbox in the properties of those exe-files
* Running the "EnableUIAccess.ahk" with "Run as administrator" from the AHK subdirectory in Program Files
* Creating batch files and shortcuts with "Run as administrator" checked
This has been bugging me for 3 days now and I'm out of options. My workflow is completely broken (some of my AHK scripts are to remap mouse buttons to useful commands like "Alt+Tab" which I can't use anymore in my work).
Please help and advise on what might be the problem. Others seem have to fixed it with the EnableUIAccess.ahk and it seems like I also successfully signed the .exe but still always the ""The requested operation requires elevation. (0x800702E4)" in Task Scheduler ;-(
Thank you!