Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

Enable interaction with administrative programs


  • Please log in to reply
64 replies to this topic
Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
The certificate you specified in the script does not exist, so it is trying to create a new one. Using the friendly name is probably not correct.

using certmgr checked personal certificates to find Autohotkey one plus my code signing one

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

scott64
  • Members
  • 9 posts
  • Last active: Jan 09 2012 03:02 PM
  • Joined: 17 Jan 2011
Can I please double check with you that what I want to do is sensible and reasonable (to avoid wasting your time etc):

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.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
I think that you should give up on using this script (which is intended for a specific, different purpose) and look for a more general code signing utility.

scott64
  • Members
  • 9 posts
  • Last active: Jan 09 2012 03:02 PM
  • Joined: 17 Jan 2011
The problem I have was reported in full and in detail by ajl in April 2010 in <!-- l --><a class="postlink-local" href="http://www.autohotkey.com/community/viewtopic.php?t=56500">viewtopic.php?t=56500</a><!-- l --> and following this through there is a suggestion that it has been fixed - if it has been fixed can you please point me in the correct direction.

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 -

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
The "solution" presumably found by ajl was not to use this script, but to simply compile with AutoHotkey_L v1.1.01 or later, so there is no checksum.

beenthere
  • Members
  • 2 posts
  • Last active: Dec 18 2011 07:12 AM
  • Joined: 13 Dec 2011
Thanks for the script.

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.

FishStik
  • Members
  • 3 posts
  • Last active: Jul 19 2013 03:52 PM
  • Joined: 15 Nov 2012
Thanks a lot for the script! Finally I can use this as a workaround to send Alt+Tab from my mouse through SetPoint.

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.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
The script asks you which file to modify - you can just select SetPoint.exe instead of AutoHotkey.exe.

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.


FishStik
  • Members
  • 3 posts
  • Last active: Jul 19 2013 03:52 PM
  • Joined: 15 Nov 2012
Thank you for your reply. I appreciate you going above and beyond to help noobs like me.

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:
Posted Image

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

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
It probably has something to do with removing Logitech's signature. I give up. :)

ratoeroaraari
  • Members
  • 2 posts
  • Last active: Nov 20 2012 08:51 AM
  • Joined: 19 Nov 2012
Hello,

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.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
Start the exe which you created using this script and pass the path of your script as an argument.

ratoeroaraari
  • Members
  • 2 posts
  • Last active: Nov 20 2012 08:51 AM
  • Joined: 19 Nov 2012

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!!

murphyw
  • Members
  • 7 posts
  • Last active: Jun 28 2013 05:01 AM
  • Joined: 15 Jan 2013

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.



suarsg
  • Members
  • 1 posts
  • Last active: Feb 08 2013 08:58 PM
  • Joined: 23 Jan 2013

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:

 

2013-01-23_14-453rs4g.jpg

 

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!