- Revenera Community
- InstallShield Forum
- Using our own version of SignTool.exe with InstallShield 2021 R2.
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Printer Friendly Page
Using our own version of SignTool.exe with InstallShield 2021 R2.
We have to use a USB signing token in conjunction with our SHA-256 certificate. To make that work with InstallShield 2012, we replaced the signtool.exe in the \system folder with our own 'shim' which changes the parameters and then calls the real signtool.exe
However having upgraded to InstallShield 2021 R2, we see from our installation and from the user manual that SignTool.exe is no longer installed in the \system folder. So our question is - which signtool.exe is used and how is it located on our system?
Maybe "iSign.exe" within the folder "\system" of InstallShield is the tool you are looking for. Calling it with no arguments shows this help text:
The solution we have used is to enable so-called 64-bit signing which means the Kitbuilder calls ISSign64.exe to do the signing instead of doing it itself. Then we replace ISSign64.exe with our own shim that calls our signing tool.
Thank you for sharing this!
Now I'm curious about this "ISSign64.exe" and would like to know more about it and how it can be used. Unfortunately calling this tool with options like "-h", "--help" or "/h" does not show any help text. And I could not find anything about it within the InstallShield Help Library either (F1 help). If you are aware of any publicly available information, please feel free to let me know.
It is not designed to be used manually so is not documented. This is what I have been able to figure out:
When InstallShield signs files, it no longer calls the Microsoft Signtool.exe but uses the Microsoft signing API. You can't intercept this because the API is called directly from within InstallShield IDE or stand-alone builder (SAB). Both their GUI and SAB are 32-bit programs.
For some reason, InstallShield has the concept of 64-bit signing which can be enabled in one of their configuration files (they document this). This requires the MS API to be called from a 64-bit program so they have ISSign64.exe built for just this purpose. When 64-bit signing is enabled, the IDE or SAB run ISSign64.exe in a subprocess just to do the signing. They pass it a set of parameters which I deduced from a tracing replacement but they later confirmed to me.
So if you want your own shim to do the signing, you configure 64-bit signing and replace their ISSign64.exe with your own shim.
Many thanks to you for your insights! This made it possible for me to follow your procedure and to make my own insights. In case anyone comes across this post, I add them here for completeness (for use on your own risk 😉).
Switching to 64-bit signing is documented here (for InstallShield 2022):
I wrote a small tool called "ISSign64.exe" and copied it to folder "\system" of the InstallShield directory. The tool writes all parameters passed to it to a file (one line per parameter). I noticed that during every invocation of the tool a file with 10 lines was written to disk. I interpretate these lines/parameters as follows:
- Full pathname of the file to sign
- C:\Program Files (x86)\InstallShield\2022\System\SignTool.exe
This was always the same. This file obviously does not exist in the latest versions of IS (as stated in the initial post here). But one could take it from the Windows SDK (https://developer.microsoft.com/en-us/windows/downloads/windows-sdk/) or make use of another tool.
- Full path to certificate as specified in the IS GUI, but with added "?auto" at the end
- Filename (not full path) of the file to sign, but without file ending
For example no ".msi" at the end
- Certificate URL as specified in the IS GUI
Most probably as specified in "Settings.xml" (DigitalSignature Timestamp)
Most probably as specified in "Settings.xml" (DigitalSignature TimestampRFC3161)
- Password of certificate as specified in IS GUI
As of now, I don't know why the last two items are empty. Maybe the result from input I did not give in the IS GUI.
So, I hope this may be helpful to someone. And thanks again to jchittock for raising this topic!
Deduction with some confirmation from Revenera:
Arg0: The usual path and file of the program that is running.
Arg1: The file to sign (this actually has a full path but ISCmdBld.exe removes the path when it relays the output which confused the heck out of me at first).
Arg2: <Legacy, ignore>
Arg3: The certificate configured in the ISM file.
Arg4: The description of the signed content (file).
Arg5: The certificate URL for information about the supplier of the file.
Arg6: The timestamping URL configured in Settings.xml.
Arg7: The RFC3161 timestamping URL configured in Settings.xml.
Arg8: The certificate password configured in the ISM file.