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

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

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