Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate

Signing with digital certificate results in "Corrupted


  • Please log in to reply
20 replies to this topic
ajl
  • Guests
  • Last active:
  • Joined: --
I signed a compiled script with a Authenticode certificate, using the signtool.exe from the Windows Platform SDK.

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!

SoLong&Thx4AllTheFish
  • Members
  • 4999 posts
  • Last active:
  • Joined: 27 May 2007
Did you try without UPX? Search the forum it has been asked before, not a "bug" should be moved to "wishlist"

ajl
  • Guests
  • Last active:
  • Joined: --

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?

HotKeyIt
  • Moderators
  • 7439 posts
  • Last active: Jun 22 2016 09:14 PM
  • Joined: 18 Jun 2008
Have you tried signing AutoHotkeySC.bin?

wrong section alert
  • Guests
  • Last active:
  • Joined: --
Why the double post? A topic is already started in Ask for Help (where it bolongs) on this problem. http://www.autohotke...topic26083.html

ajl
  • Guests
  • Last active:
  • Joined: --

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!

ajl
  • Guests
  • Last active:
  • Joined: --

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!

HotKeyIt
  • Moderators
  • 7439 posts
  • Last active: Jun 22 2016 09:14 PM
  • Joined: 18 Jun 2008
Try to run <!-- m -->http://github.com/Le... ... uildSC.ahk<!-- m --> after signing?

ajl
  • Guests
  • Last active:
  • Joined: --

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.

ajl
  • Guests
  • Last active:
  • Joined: --

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

HotKeyIt
  • Moderators
  • 7439 posts
  • Last active: Jun 22 2016 09:14 PM
  • Joined: 18 Jun 2008

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

Why do you want to sign it again after compiling?

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
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 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.

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.

(in the sense of "could be improved in Autohotkey")

That is generally a better fit for the Wish List forum, unless it involves fixing an actual error in the code.

Try to run <!-- m -->http://github.com/Le... ... uildSC.ahk<!-- m --> after signing?

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.

ajl
  • Guests
  • Last active:
  • Joined: --
Hello Lexikos:

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

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.


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?

(in the sense of "could be improved in Autohotkey")

That is generally a better fit for the Wish List forum, unless it involves fixing an actual error in the code.


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!

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

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.

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.

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.

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

ajl
  • Guests
  • Last active:
  • Joined: --

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.