I've been using SSE Setup to distribute a pre-packaged Access application.
It's one of the few installers on the market that includes special support for the needs of Microsoft Access deployments. In particular, it includes support for deploying both 32-bit and 64-bit versions of .accde files within a single setup file.
It's been working great for several months, but today I got the following error when building an installer for a new project:
Digital Signature could not be added to the Uninstaller. The digital signature could not be added or was not added correctly. (Error Code: -2147024671)
Which raised the obvious question, "What the heck is error code -2147024671?"
Breaking Down Windows Error Codes
Luckily, I know this website that published an article about how to break down Windows error codes. Hey, look at that, it's this website:
Here are the basic steps:
- Open the built-in Windows Calculator
- Switch to "Programmer" mode
- Select "Dec" (for decimal) and enter the error code
- Switch to "DWORD" to show 32-bit values (click to toggle through the options: QWORD | DWORD | WORD | BYTE)
- Enter the error code
- Verify the fourth HEX character is a "7" (this is the "Facility" code; 7 means that the error code is a Win32 error code)
- Identify the last 4 HEX characters (the hexadecimal representation of the decimal error code)
- Find the matching error code in the list of Win32 error codes (NOTE: this only applies to error codes with a "7" as the facility code)
As the screenshot below shows, the error code in the message from SSE Setup traces back to a Windows error code named ERROR_VIRUS_INFECTED. The corresponding description is, "Operation did not complete successfully because the file contains a virus."
Checking the Virus Protection History
Based on the error code, I opened the Protection History in Windows Security.
- Settings > Virus & threat protection > Protection history
Sure enough, there were a bunch of threats detected that all perfectly coincided with the times that I was trying to build a new installer in SSE Setup:
Machine Learning False Positives
The world of cybersecurity is a constant game of cat and mouse.
As the mice (the attackers) get trickier, the cats (the defenders) need to get more creative to identify and stop them. In an effort to avoid the cats, the mice start wearing disguises so they look like otherwise innocent things: dust bunnies, clumps of mud, bare human feet, etc.
Eventually, the cats catch on. They decide that anything that moves like a mouse, might be a mouse. And mice cannot be allowed to exist. If that means a few actual dust bunnies, clumps of mud, or bare human feet get misidentified and become the victims of vicious, clawed swipes...so be it.
This is the price we pay for security.
Anti-virus programs used to depend heavily on large databases of malware definition files. To decide if something was a threat, the AV software would compare it to a list of known bad files. Over time, the malware creators got better at circumventing this approach in a variety of ways.
To keep pace, the AV developers began using artificial intelligence (specifically, machine learning algorithms) to identify as-yet-unclassified programs as malware based solely on how they behaved.
As with the cats and mice, a few innocent victims would need to be sacrificed in the name of security.
This has become something of a problem in general, as anti-virus programs use the following two heuristics that are notorious for generating false positives:
- Behavioral analysis: Does the code execute arbitrary commands via the command line? If so, it MUST be a virus. No normal program would ever need to do that. [sarcasm]
- Popularity: This brand new application you are trying to introduce into the world has not been downloaded by thousands of people yet, so it MUST be a virus. [more sarcasm]
If you look closely at the details of the Protection history screenshot, you'll see that the detected threat was
Trojan:Win32/Sabsik.FL.A!ml. Based on some brief Googling, "Sabsik" is the name applied to a family of similar Trojan horse viruses. The "!ml" subscript at the end of the threat identifier stands for, "machine learning."
In other words, Windows is telling us that it doesn't know for sure that this thing is a threat, but it acts like it might be, and so Windows is going to obliterate it just to be on the safe side.
Avoiding the Error: Emperor Version
One way to avoid the error was to turn off Real-time protection in the Virus & threat protection area of the Windows Settings app.
This avoids ALL POSSIBLE FALSE POSITIVES...
...in much the same way that you can avoid staining your clothes by eating spaghetti in the nude: it's 100% effective but leaves you completely exposed.
The other downside to this approach is that you have to take the time to undress yourself before you eat and remember to dress yourself after. Otherwise, you end up walking around nude all the time. And that level of exposure opens you up to all sorts of attacks.
But, if that's your thing, there are colonies for that.
Who am I to judge? ¯\_(ツ)_/¯
Avoiding the Error: Civilized Human Version
A more circumspect approach is to grant limited exclusions to the files or processes that are generating the false positives:
This leads into an obvious followup question. What do we exclude?
Windows Event Viewer: Identify What to Exclude
The best way to determine that is to use the Windows Event Viewer (trust me, I tried lots of other less effective methods).
The key is to filter the event viewer to show only events from the Windows Defender source:
- Open Event Viewer
- Click to expand "Applications and Services Logs"
- Click to expand "Microsoft"
- Click to expand "Windows"
- Click to expand "Windows Defender"
- Click "Operational"
- Look for "Warning" items, especially those with Event ID 1116
- Click on each "Warning" item to show its details
- In the "General" tab, look for "Process Name"
The screenshots below include the full paths to the two processes that we need to exclude:
Creating the Exclusions
Here are the steps to create the required exclusions:
- Open the Windows Security app
- Click on "Virus & threat protection"
- Click on "Add or remove exclusions"
- Click "Add an exclusion" then click process
- Copy/paste the full paths of the process names into the "Add an exclusion" dialog window
According to Microsoft, we can add the full path or just the process name when creating exclusions:
Tip: It's recommended that you use the full path and file name to exclude a specific process. This makes it less likely that malware could use the same filename as a trusted and excluded process and evade detection.
After making the above changes, I re-ran the process to generate an installer using SSE Setup. The setup file was created without generating any error messages.
In the words of legendary screenwriter Kevin Smith, "Let it never be said that [my] anal-retentive attention to detail never yielded positive results."
Cover image created with Microsoft Designer