cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
jchittock
Level 3

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?

Labels (1)
0 Kudos
(6) Replies
oberwahrenbrock
Level 3

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:

iSign.png

0 Kudos

Many thanks for the suggestion, but no that's not a solution as iSign.exe is not called from within the InstallShield KitBuilder.

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.

John
0 Kudos
oberwahrenbrock
Level 3

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.

0 Kudos

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.

0 Kudos

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):
https://docs.revenera.com/installshield28helplib/helplibrary/ConfiguringPlatformArchitectureforDigitalSigning.htm

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:

  1. Full pathname of the file to sign
  2. 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.
  3. Full path to certificate as specified in the IS GUI, but with added "?auto" at the end
  4. Filename (not full path) of the file to sign, but without file ending
    For example no ".msi" at the end
  5. Certificate URL as specified in the IS GUI
  6. http://timestamp.digicert.com
    Most probably as specified in "Settings.xml" (DigitalSignature Timestamp)
  7. http://timestamp.digicert.com
    Most probably as specified in "Settings.xml" (DigitalSignature TimestampRFC3161)
  8. Password of certificate as specified in IS GUI
  9. Empty
  10. Empty

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!

0 Kudos

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.

Arg9: <Ignore>

Arg10:<Ignore>

0 Kudos