Problems running a code-signed, protected Xojo executable

Hello everyone. I recently acquired a StartCom code-signing certificate to sign my Xojo apps in Windows. However, after signing the code, I can’t run my program anymore.

For additional context, I’ve been using a program called Enigma Protector to implement my program’s licensing scheme. After compiling my app in Xojo, I use Enigma Protector to encrypt/obfuscate the compiled executable. The Xojo/Enigma Protector combination works well. However, after I code-sign my protected, Xojo-compiled executable (using StartCom’s code-signing tool) I am no longer able to run my program. When I try to open it, I get the following error message:


Runtime Error
Press OK to Continue
Press Cancel to Quit.

Please report what caused this error
along with the information below.

Common\Loaders\LoaderWindows.cpp: 119
Failure Condition: 0
Executable is corrupt!


Has anyone experienced and resolved a similar situation, or have any troubleshooting tips? Thanks in advance!

Code signing validates the content of the executatble to have not been altered… yet your obfuscating software is doing just that

You can one or the other but not both

I would understand that this would be an issue, Dave, if I first code-signed the Xojo executable and the obfuscated it. However, since I’m code-signing the already-obfuscated executable, I wouldn’t think it’d be a problem.

In other words, if my process was this

Xojo executable compilation -> Code-signing -> Obfuscation

I’d expect a problem, but not by doing this

Xojo executable compilation -> Obfuscation -> Code-signing

P.S. I’m also trying to find out which of the program’s layers is sending out that error message, if it’s the obfuscator, the code-signing code, Xojo itself, or code that Xojo is built upon. That might help me find a way to fix the issue.

Well it looks like our windows loader that’s throwing the error, and based on the error I’m guessing that the obfuscation isn’t being reversed before the binary tries to run. Now it may be that the code signing tool is manipulating the header of the application as well and causing some sort of offset problem.

Have you tried signing the xojo app using the starcom signer, just to make sure that part works too?

Just sign the installer, and leave your executable as is. That should suffice to alleviate Smart Screen infamous yellow warning box.

Greg: I haven’t tried signing the Xojo app with the StartCom signer yet, but I’ll try it. I tried signing a different Xojo-compiled executable for a different program I made (one that doesn’t use obfuscation), and it worked fine. But I haven’t tried it with the Enigma Protector-obfuscated program. I’ll give it a try.

Michel: I like your idea. Unfortunately, I not only have to worry about Smart Screen, but about various antivirus and antimalware programs which falsely flag my program as a virus. I’m hoping that code-signing the main executable itself, and not just the installer, will make it quicker to publish each new version of my program, instead of having to submit a lot of false-positive reports to various anti-malware vendors for each new version.

[quote=287893:@Andres Cabezas]

Michel: I like your idea. Unfortunately, I not only have to worry about Smart Screen, but about various antivirus and antimalware programs which falsely flag my program as a virus. I’m hoping that code-signing the main executable itself, and not just the installer, will make it quicker to publish each new version of my program, instead of having to submit a lot of false-positive reports to various anti-malware vendors for each new version.[/quote]

Code-signing will not solve the false-positive problem. Apps protected by Enigma tends to have this problem since many years ago.

I could not say it better myself. Enigma is notorious for triggering false positives. The very way it works is like a red flag for AV. IT looks and acts like a virus. You know the idiom : “If it walks like a duck and walks like a duck…”.

One thing at a time. Sign the installer to mitigate the Smart Screen yellow box of shame, then address the AV issues.

If you are intent on using Enigma, code signing won’t help with AV false positive at all. AV don’t check on code signing anyway AFAIK.

You will indeed have to submit your executable to the major AV publishers. Or abandon Enigma.

I can see why Enigma Protector (and probably other executable packers) would trigger a lot of antivirus false positives. I was hoping that the latest version, which implements the taggant system, would reduce false positives. But maybe I’m just dreaming…

Michel and Cho, you’re probably both right that code signing won’t reduce false positives either. But if it can prevent the installer from triggering the Smart Screen “yellow box of shame”, that’s at least some help. (Thanks for that tip, Michel!)

I wonder what kind of integrity checks Xojo includes in the executables it generates, since this might be where this particular problem lies…

I chose the Enigma Protector several years ago after spending quite a bit of time finding a good, affordable third-party licensing system that would work with REALbasic (as Xojo was called at the time). There were many systems that just didn’t work, as hard as I tried to integrate them. If there are compelling alternatives for Xojo which also allow for code-signing, I’d be interested in considering them. I’ve invested a fair bit of time into integrating Xojo with Enigma Protector, and Enigma Protector with my online payment processor. However, it might be worth it to switch if I’m going to spend significantly more time submitting false positive reports to antivirus vendors.

Thanks Greg, Michel and Cho, for your very helpful comments!

You may want to contact Enigma about what to do with major AV publishers. They may already have approached them, or give you who to call in each company.

As far as licensing, there has been numerous exchanges over the forum. I use my own licensing system which basically takes the name of the user, encrypts it, then formats it into a 5 groups of four alphanumeric characters that is the license key.

When the user enters his license key, the algorithm in the app compares with its own result, and if fine, stores it in an encrypted form in ApplicationData.

The nice thing about it is that I can easily serve the license key from the app that validates payment over the web.

Thanks, Michel. I’ll look for past forum posts regarding licensing options.

So far, I’ve had no trouble (other than the time it takes) submitting false positive reports to antivirus vendors. There’s a handy page which provides instructions on how to submit false positives to each one:

How to Report Malware or False Positives to Multiple Antivirus Vendors

I’ve also been able to find false positive submission instructions for other vendors not on the list, through searches. In some cases they take a few days to remove a false positive. I imagine some users will still run into false positives after that, if they haven’t updated their antivirus signatures recently.

Thanks again!