Code Signing on Windows now requires some attention

Ok, this is weird. I just tried it on a fresh Windows 10x64 install (not running insider preview builds) and this time I got the x64 version of the Windows 10 version of signtool, but the x86 version is missing.

Anyone know what the rules are for 32 vs 64 bit? Can the 64 bit tool sign 32 bit apps and vice-versa?

Short answer: Nope.

Since I am running 64-bit OS on my development machine I have always been running the 64-bit version of the tools. Checking my 8.1 machine I see that both x86 and x64 are full with the same tools, but on Windows 10 only x64 is full, the x86 directory is there but empty. Don’t know why.
My machine is also on the insider program, joined to a domain and my account has admin privs.

Update:

  • I received my new certificate from Tucows (a Comodo reseller) and it is, indeed a SHA256 certificate.
  • I was able to successfully sign my 32 bit Xojo app in Windows 7 (32 bit) using the Windows SDK 7.1 version of signtool (version 6.1.7600.16385) with the new SHA256 certificate.
    However, I ran into some glitches:
  • using the /tr option with Comodo’s new time stamp server http://timestamp.comodoca.com/rfc3161 was failing for unknown reasons.
  • using another provider’s server (e.g. /tr http://timestamp.geotrust.com/tsa ) works fine.

At the moment I’m inclined to think “good enough” but I am curious if there’s any advantage to using a newer version of signTool from the 8.1 or 10 SDK toolkits.

SHA-2 and Code Signing related:
If you are running Trend Micro “Worry-Free” (I put the quotes there as we have found it to be anything but worry-free…) anti-virus in your business, you should check the latest critical security patch fixing scanning issues related to Microsoft’s changes.

I have used kSign so far, I have updated my certificate to sha-256, updated kSign to support this new certificate…etc… I create the installer with Innosetup as usual, test it with my Windows 7 machine, everything is correct and work, the certificate is indeed sha-256… Problem is when a Windows 10 user try to install my software, some have difficulties even with the installer and once done they get as many loader.cpp errors as dlls in the Libs folder, once they passed all the errors windows the software seems to work properly. This problem is new, since I sign the app with hat sha-256 certificate. I then decided to use signtool.exe but here I have a new problem, whatever I do the signature is always sha-1 :frowning: Anybody has ran into those problems?

The commands I use are (XXXXX is the Cert password). The /fd will calculate the signature either as SHA1 or SHA256:

"%SDKPATH%\\signtool.exe" sign /p XXXXX /f tangix_20161026.pfx /fd sha1 /v /t http://timestamp.verisign.com/scripts/timstamp.dll "%DESTPATH%\\Tangix TesterPRO Client\\Tangix TesterPRO.exe" "%SDKPATH%\\signtool.exe" sign /p XXXXX /f tangix_20161026_sha256.pfx /as /fd sha256 /v /tr http://timestamp.geotrust.com/tsa "%DESTPATH%\\Tangix TesterPRO Client\\Tangix TesterPRO.exe"

I now also codesign with the new kSign version and sha256 and have no issue, neither did anyone report this.

The people with Windows 10 are all reporting the same failure. When they double-click on the app they get 16 runtime errors:

Runtime Error
Press OK to Continue
Press Cancel to Quit
Please report what caused this error
along with the information below.
Common\Loaders\Loader.cpp: 121
Failure Condition: funcAddress
Function ‘WindowBitmappForCaching’ was not exported

  • pressing OK gives the same 7 first lanes and then:
    Function ‘WindowsGetScaleFactor’ was not exported
  • pressing OK gives the same 7 first lanes and then:
    Function ‘ApplicationSetSupportHiDPI’ was not exported
  • pressing OK gives the same 7 first lanes and then:
    Function ‘ApplicationSetSupportHiDPI’ was not exported
  • pressing OK gives the same 7 first lanes and then:
    Function ‘GraphicsGetCharacterSpacing’ was not exported
  • pressing OK gives the same 7 first lanes and then:
    Function ‘GraphicsGetCharacterSpacing’ was not exported
  • pressing OK gives the same 7 first lanes and then:
    Function ‘GraphicsGetScaleX’ was not exported
  • pressing OK gives the same 7 first lanes and then:
    Function ‘GraphicsGetScaleX’ was not exported
  • pressing OK gives the same 7 first lanes and then:
    Function ‘GraphicsGetScaleY’ was not exported
  • pressing OK gives the same 7 first lanes and then:
    Function ‘GraphicsGetScaleY’ was not exported
  • pressing OK gives the same 7 first lanes and then:
    Function ‘PictureGetBestRepresentation’ was not exported
  • pressing OK gives the same 7 first lanes and then:
    Function ‘PictureCreateWithBitmaps’ was not exported
  • pressing OK gives the same 7 first lanes and then:
    Function ‘PictureCopyOSHandle2’ was not exported
  • pressing OK gives the same 7 first lanes and then:
    Function ‘PictureOpenFormApp’ was not exported
  • pressing OK gives the same 7 first lanes and then:
    Function ‘PictureGetType’ was not exported
  • pressing OK gives the same 7 first lanes and then:
    Function ‘CanvasScaleFactorGetter’ was not exported

What version of Xojo is this?
Those messages look HDi related, which shouldn’t be part of the release version.
Otherwise it superficially looks like a missing or invalid DLL. Do you have any third party graphics things that should be bundled?

I use Xojo 2015 R4, all DLLs are properly copied thru Innosetup as usual. The funny thing is that it only fails on Windows 10.

Those messages look like old framework DLL with newer app.
Especially ApplicationSetSupportHiDPI sounds like Xojo 2016.

Inno has a parameter that determines whether files are
Always replaced
replaced where date is newer
replaced where version is newer

Is your customer installing over another build of your app and getting a mix of files?

If not, are you copying your recent build into a folder for use with Inno, but not cleaning out the Libs folder first?

I think about using a [InstallDelete] section to clean the target folder previous to installation… It looks like it is the problem.