An unsigned Windows installer was flagged, but its executable was not

While preparing an early release of my Rust and Slint Windows music player, Auricle, I ran into an antivirus discrepancy: the installer was flagged, but the application inside it was not.

Here is what the investigation established, and what it did not. This is a snapshot from September 15, 2026, not a claim that the software is safe.

Compare the actual artifacts

A fresh VirusTotal analysis reported:

• Inno Setup installer: 3/70 detections.
• Application extracted from that installer: 0/69 detections.
• Application extracted from the portable ZIP: 0/70 detections.

The installer detections were Microsoft Trojan:Win32/Wacatac.B!ml, SecureAge Malicious, and Skyhigh BehavesLike.Win32.ObfuscatedPoly.vc. All three executable artifacts were unsigned.

The two application binaries were not interchangeable test samples. The portable build enabled self-update, while the installer build used --no-default-features. Scanning the portable binary alone would not have tested the actual installed payload.

Inspect without executing the installer

The installer was extracted with innounp after checking the extractor archive against its published SHA-256. It identified Inno Setup 6.7.0 and one application executable. The recovered installation script copied that executable, created shortcuts, and optionally launched the application. No custom Inno [Code] section was found.

The original installer hash also matched the digest in the GitHub release metadata. That establishes which published artifact was inspected, not that the binary is reproducibly built or free of malicious behavior.

Read the event behind a sandbox label

One sandbox result included an 'Unsigned Image Loaded Into LSASS Process' rule. The matching event named a DLL outside the application directory, not a file bundled in the installer. Its origin remains unverified.

That matters in both directions: the label alone did not establish that the application caused it, but absence from the installer did not establish that the event was harmless either. A targeted source search is useful evidence, not an exhaustive audit of a compiled program and its dependencies.

Ask the detecting vendors

Review requests were submitted to Microsoft, SecureAge, and Skyhigh with the unchanged installer or its public download link, exact hashes, and the separate scan results. At the time of writing, no final vendor clearance has been confirmed.

I did not rebuild repeatedly to change hashes or disable antivirus protection. A low detection count is not proof of a false positive; zero detections is not proof of safety.

Signing is a separate step

Code signing is still pending for this project. It can establish publisher identity and artifact integrity, but it does not guarantee antivirus clearance. For a future signed release, the application needs signing before packaging, followed by signing the installer and computing distribution hashes from the final artifacts.

The useful outcome so far is a narrower, reproducible question for the vendors: why is this exact installer classified differently from its extracted payload?

AI disclosure: GitHub Copilot assisted with the investigation and drafting this write-up. The reported observations come from the release artifacts and scan reports; unresolved findings are explicitly identified.