Signing with digital certificate results in "Corrupted
This seems to work - but when I start the EXE, it displays an error "EXE corrupted".
I do not think that signing actually corrupts the file itself, neither the runtime part nor the script part. It adds the certificate and the appropriate header fields to the EXE.
So I guess the functionality of the AHK runtime and the script is still there, but the EXE loader calculates some sort of checksum which of course has changed after signing.
Is there an option to prevent this ?
Together with Compile_AHK http://de.autohotkey.../topic1884.html which makes the UAC control so much easier, a working solution to sign the resulting .exe would be fantastic.
Thanks!
Did you try without UPX? Search the forum it has been asked before, not a "bug" should be moved to "wishlist"
I did try without UPX, even renamed UPX.exe to UPX.old.
I did check the forum for similar problems (only 2 show up, and none have been solved). One posting pointed to AutoHotkeySC.bin.
In summary so far, I have tried the following options:
1) Disable UPX
2) Rename UPX (just to be sure that the option of no UPX is respected)
3) sign AutoHotkeySC.bin
4) unpack AutoHotkeySC.bin and sign the contained binary blob .text, then repack AutoHotkeySC.bin
All of those options result in "Exe corrupted".
Is really nobody signing their AHK exes?
Have you tried signing AutoHotkeySC.bin?
Yes, as indicated in the post that I wrote at the same time you wrote yours :-)
If i sign AutoHotkeySC.bin and then run
Ahk2Exe.exe /in service-install.ahk /out install.exe
I get the following error:
---------------------------
Ahk2Exe Error
---------------------------
Error: Error opening the destination file.
---------------------------
Aceptar
---------------------------
so apparently AutoHotkeySC.bin becomes "corrupted" for ahk2exe in a certain way. I do not understand enough of the interl processes of ahk2exe to venture a guess, but I guess there is some sort of checksum stored in the binary files (AutoHotkeySC.bin and install.exe) that is not correct anymore after signing them.
Any other ideas are welcome!
Why the double post? A topic is already started in Ask for Help (where it bolongs) on this problem. http://www.autohotke...topic26083.html
That article was "Posted: Thu Nov 29, 2007 8:03 pm" and not resolved. Are you certain this is not a bug (in the sense of "could be improved in Autohotkey"), rather than "please hold my hand on how to do it"?
Constructive criticism appreciated!
Try to run http://github.com/Le... ... uildSC.ahk after signing?
Thanks for the suggestion. After the following scenarios:
1) Run PostBuildSC.ahk on AutoHotkeySC.bin, then compile calc.ahk, then sign
2) Run PostBuildSC.ahk on AutoHotkeySC.bin, then compile calc.ahk, then run PostBuildSC.ahk on calc.exe, then sign
I still get the dreadful "exe corrupted"... if I don't sign the binary in either scenario, calc.exe works just fine.
I am also using UAC elevation on the same binary, in case there is some kind of interdependency of signining and UAC? Signing the binaries makes the resulting UAC dialogues a lot friendlier.
Try to run http://github.com/Le... ... uildSC.ahk after signing?
Thinking about this bit more, I also tried a third alternative with no success:
3) sign AutoHotkeySC.bin, run PostBuildSC.ahk on AutoHotkeySC.bin, then compile calc.ahk (which works now!), then sign.
Result: "Corrupted exe".
Why do you want to sign it again after compiling?Try to run <!-- m -->http://github.com/Le... ... uildSC.ahk<!-- m --> after signing?
Thinking about this bit more, I also tried a third alternative with no success:
3) sign AutoHotkeySC.bin, run PostBuildSC.ahk on AutoHotkeySC.bin, then compile calc.ahk (which works now!), then sign.
Result: "Corrupted exe".
I believe that is the case. However, Ahk2Exe and AutoHotkeySC use a library for archiving/extraction of the script within the executable; source code doesn't appear to be available, but I've never asked. I suppose signing can only work if support for it is added to this library.I guess there is some sort of checksum stored in the binary files (AutoHotkeySC.bin and install.exe) that is not correct anymore after signing them.
That is generally a better fit for the Wish List forum, unless it involves fixing an actual error in the code.(in the sense of "could be improved in Autohotkey")
That script merely sets the checksum field in the executable's PE header to 0, which allows the file to be used with Ahk2Exe. It is completely unrelated to AutoHotkeySC's integrity checks. Unless you are compiling AutoHotkeySC.bin yourself, the checksum should already be zero and running PostBuildSC.ahk should do nothing. In the event that it did something (i.e. modified the file), the signature would be invalidated.Try to run <!-- m -->http://github.com/Le... ... uildSC.ahk<!-- m --> after signing?
The integrity checks built into AutoHotkeySC prevent modified executables from loading. Since signing the file necessarily modifies it, you can't. Signing the file before compiling the script would be pointless, since the signature won't match the compiled script. Digital signing in the context of UAC identifies the author of the executable and verifies the file hasn't been tampered with.
I was trying to sign AutoHotkeySC, which I assume contains a loader and the required libraries for the compiled script to run, like the the 7zip executables. Then compile the target script (calc.ahk) in this case, and then sign the resulting "joint" executable (calc + AutoHotkeySC).
This is not necessarily "pointless", since Windows might be using the signatures to check the integrity of any "executable" part of a self-extracting EXE, which I think the resulting compiled scripts are.
I believe that is the case. However, Ahk2Exe and AutoHotkeySC use a library for archiving/extraction of the script within the executable; source code doesn't appear to be available, but I've never asked. I suppose signing can only work if support for it is added to this library.I guess there is some sort of checksum stored in the binary files (AutoHotkeySC.bin and install.exe) that is not correct anymore after signing them.
Correct. I am really surprised that nobody has tried to sign their AHK scripts/exes yet, given the importance of digital signatures XP (signed drivers etc), then in Vista and now in Windows 7. You basically cannot have an installer or UAC program that won't scare everybody into clicking "Cancel" without signing it.
Is there a way to use this opportunity to look into improving the underlying libraries?
That is generally a better fit for the Wish List forum, unless it involves fixing an actual error in the code.(in the sense of "could be improved in Autohotkey")
I agree that it is not a bug in the sense "3+3=7", but I do think that not being able to sign resulting binaries is an error in the design, especially given the importance of code signing/authenticode on the Windows platform since XP. Please refer to http://www.windowsec...Signatures.html for digital signature examples from 7 years ago.
If you feel more comfortable in the "Wish list" section, for me we can move the post (if that is at all possible), as long as we pay some attention to how to improve the situation.
Thanks for considering!
Compiled scripts are unlike 7zip self-extracting executables in that no files are created. When a compiled script executable loads, it "extracts" its embedded script text into memory and interprets it mostly as AutoHotkey.exe would. AutoHotkeySC.bin contains all code required to extract the script, load and run it; this is what executes when you run the compiled script. Usually this part is compressed with UPX, but that's not really relevant.I was trying to sign AutoHotkeySC, which I assume contains a loader and the required libraries for the compiled script to run, like the the 7zip executables.
Only the signature of the file being launched is important for UAC. Think about it: the UAC dialog is shown before the file begins executing. Once the user makes a choice, the file is either executed with administrative rights or not executed at all, and that's the end of UAC's role. I do not believe Windows/UAC could know that the file is UPX-compressed, let alone understand how to decompress the data and/or distinguish the AutoHotkeySC.bin part from the script data.
Can you give a practical reason to sign a compiled script, other than to make the UAC prompt more friendly? Compiled scripts are not (and will never be) drivers, so driver signing is irrelevant.... especially given the importance of code signing/authenticode on the Windows platform since XP.
Can you give a practical reason to sign a compiled script, other than to make the UAC prompt more friendly? Compiled scripts are not (and will never be) drivers, so driver signing is irrelevant.
http://www.verisign....sign-your-code/ has Verisign's perspective on the issue, which is of course not completely without bias (-:
Personally, I think that executables downloadable from a web page should be signed as a courtesy to the user (see also the red vs. yellow shield prompt).
In addition, UAC is becoming more and more important, and I thought that Autohotkey might want to adapt to that trend.
If you think that red warning signs or non-comforting UAC dialogues are OK, then I guess I simply cannot make a convincing enough case.