I develop a desktop application for use on Windows, and was wondering how I can get my executables signed so they stop showing those horrible looking warning messages about being from an unknown publisher. I am somewhat familiar with signing binaries before releasing them. I have a Linux port of the same program which is distributed though it's own signed repository (apt-get).
The process for signing windows executables seems extremely complicated and I can't find a simple tutorial on what to do, rather thousands of webpages describing only parts of the process, or which go into way too much depth.
I just need a quick list of steps which are necessary to sign executables under windows. I believe it's called "authenticode".
Tools see MSFT Introduction to Code Signing
edit: you buy a certificate from a provider - most web registrars sell them.
Then simply sign the executable using the msft tools
see http://www.instantssl.com/code-signing/code-signing-process.html
Related
I cross-compiled a simple software from linux to windows through Fyne.
The software is pretty easy and straightforward, it just creates QR codes from an input given by the user, nothing special.
It works flawlessly but Windows Defender wakes up and alerts me there's a trojan, and it eventually deletes the .exe.
For more context, I didn't sign the software while compiling it. But I don't really need to distribute it, it's just a utility I'm going to use privately.
Any of you guys has experienced this issue before? Could be related to the cross-compiling procedure? Or maybe a sign is mandatory? Can depend by the QR code library I'm using, since it's the unique non-standard library I included?
There have been many reports of Go applications triggering windows virus detection, this is a problem with more than just your cross-compiled app.
As we live in a “default virus” world the defender rules need to understand Go apps, which has not yet happened.
In the meantime the only way to resolve this is to sign your apps I think.
This Stackoverflow question asked how to modify the version information in an existing binary (DLL or EXE). The answer was to use Visual Studio. I tried on a 3rd party DLL our PC supplier gave us to read system metrics (such as battery voltage or motherboard temperature). The supplier had neglected to add any version information to the DLL. This proved disturbingly easy to do and the version information when viewing file properties looks absolutely legitimate.
This Superuser question shows how to use a fantastic utility called Autoruns to see what is starting up and running on your computer. One of the high-rated answers suggested being suspicious of DLLs or EXEs where the Publisher was unknown or blank.
Now I ran Autoruns myself and identified a Java DLL not currently loaded into memory. The DLL was loaded into VS and the "Company Name" modified from "Oracle Corporation" to "HonkyTonks". Reloading Autoruns...and lo and behold, the "Publisher" now shows "HonkyTonks"! Holding the mouse over the DLL in Windows Explorer also shows version information with any modification I care to make.
So my questions are:
1) Is the suggestion to look for Company Name/Publisher useful (in terms of security)?
2) This looks to me like a security loophole because many otherwise competent computer users may see "Microsoft Corporation" or similar in the version information and assume the file is legit. Is this a known loophole and if so does it apply to all versions of Windows and possibly other OS? Am I just behind-the-times and one should never trust this information?
3) Can you programmatically detect whether the version information had been modified in this way?
4) Can you lock down the version information in our own binaries so that it cannot be modified so easily by someone else?
Thanks.
In terms of security, the version information is mostly unuseful. It
provides only the basic information about a publisher and as you
mentioned can be easily forged.
Yes, that's why in Microsoft's .Net Framework you can digitally sign assemblies and executables. In this case, even modification of a version information will lead to denying of execution or loading of a signed binary. And the only way to fake the assembly is to steal the private key used to sign this
assembly.
No. It's only possible if you have signed the executable or DLL. But in classic Windows (not MS .Net) it's almost impossible to do. Because you need to store the public part of the key used for verification in secure place. Otherwise, the hacker can replace public key with his own and your verification program will fail to detect the fake.
You can sign the binary and put the digital signature inside of it or a separate file. And validate the signature against the binary before loading it. And you must secure the public key storage.
I am developing some freeware applications. Mostly they are written in Java to make them run on multiple systems. Meanwhile I have some thousand users and so it makes a lot of fun.
To make the Java apps easier to run under Windows, I also create executable wrappers using launch4j and installer applications using inno setup.
Now I have problem, because of Windows 8. In former Windows versions the OS just showed up a message by trying to start such an executable which was saying that the exe file comes from an "unknown" vendor. In Windows 8 they made it even harder. There is something like "Windows protected you from this dangerous application!".
So I am highly interested in signing my apps. But I am not willing to pay anything for this as I offer my software for free. Using Google I found the "CAcert" project that allows people to create free certificates. But I haven't found detailed information about the following questions:
can I create certificates to sign executables?
can I create certificates using my company name?
Is there anyone familiar with CAcert?
Or has anyone another hint to solve my problem?
thanks a lot...
Well, you can use use a CAcert certificate to sign your code, but it won't help you. That's because the OS doesn't install the CAcert root certificate.
If you want to stop your users seeing these messages you'll need to obtain a commercial certificate.
I work on a vertical-market Mac application that uses a USB dongle to make sure users have paid for it. It's expensive enough, and in enough demand, that "black hats" have tried to crack the dongle scheme, so the app checks the executable and key resource files at runtime, and if something has been tampered with, the program won't run.
With PKI (Public Key Infrastructure) based code signing becoming more commonplace in the Mac world, I'm considering switching to using it to do this runtime verification, which would have the nice side effect of making Gatekeeper happy.
However, Apple's interest is very different from mine. Their focus is on making the user happy, so if an app has an incorrect signature, Mac OS X will simply ask the user if they want to run it anyway. My focus is on thwarting crackers, so if my app has an incorrect signature, I simply don't want it to do anything that's useful to an end-user.
So I want my app to be able to validate its own executable and resources, using Apple's signatures, at runtime.
Also, from what I've read of the libraries offered Mac OS X for doing validation, they simply give a "yes" or "no" answer to requests to validate an executable. It strikes me that this is susceptible to "black hat" attack in a number of ways - for instance, one could simply replace Apple's tools with ones that always say, "yes, this is valid", either in the system directories or by changing the search path for those tools. So I think it might be a good idea to build the complete set of signature validation code into my app.
So I have a few questions:
What PKI libraries/APIs are available to let an app validate its own executable and resources which have been signed using Apple's codesign system?
Do these libraries have source code available?
Are my security concerns about using the PKI libraries Apple ships with Mac OS X valid, or are they safer to use than I think?
Does anybody have experience with this kind of thing they'd be willing to share? Are there other gotchas or tips?
Thanks in advance for any help with this.
To answer #1 and #2 above, Apple has open-sourced its code for creating and verifying digital signatures as libsecurity_codesigning. So a developer could build that into their app to let it validate its own signature.
Alternatively, MacOS's version of this library can be used by an app - but the API is private, so that's a gotcha. There's a brief discussion at this link.
I've been asked to redesign our build/sign/release processes. I'm pretty happy with Windows stuff and I've identified several networked-HSM products that will do what we need. They basically integrate directly with CryptoAPI so the people doing the signing can just use signtool.exe as normal.
We currently have a separate Mac team who do their own build/sign/release. This is all working fine on a couple of Mac Minis in one of our DCs. I'd like to protect our Mac software keys as well and so I'm trying to find out how to integrate a networked-HSM into our Mac signing process.
I can't find any good information about this anywhere! So I'm hoping someone in here has done this already and can lessen my pain.
The actual questions are;
1) Can I use a HSM with the standard Mac code-signing tools?
2) Can anyone recommend a vendor/product for the above?
3) Can anyone point me towards some good documentation on Mac code signing and the inner-workings of the Mac crypto infrastructure?
Cheers
BHB
I don't believe any of the major HSM vendors (nCipher, SafeNet, etc.) have any hooks into the Mac code signing tools, nor do I believe Apple exposes any. Your best bet would be to try and determine what the code signing mechanism looks like when performed by the Mac tools and then try and duplicate it yourself manually. However, off the top of my head, I don't recall seeing that the major vendors support OSX-based HSM clients out of the box. I know that SafeNet supports Java via a custom JCE provider. If there's a PKCS#11 interface you can hook into, then you may be able to leverage OpenSSL or another similar toolkit, but it will result in some work for you.