#
Antivirus False Positives
False positives can occur with protected or obfuscated applications. This is not specific to .NET Reactor: products that do more than simple name obfuscation can change the structure or runtime behavior of an application in ways that heuristic antivirus engines may consider suspicious.
.NET Reactor does not inject virus or malware code into your application. If your original application is clean and an antivirus product starts detecting the protected output, the detection is usually a false positive caused by the protection pattern or by the reputation of the newly generated binary.
Before reporting the detection, make sure that the affected file really comes from your official build and has not been modified after release.
#
Recommended solution: sign your application
The most reliable way to reduce false-positive detections is to sign your software with a commercial code-signing certificate.
Digitally signed applications have a verifiable publisher identity and normally build a much better reputation with antivirus and reputation systems than unsigned binaries. This is especially important for protected applications, because every protected build may otherwise look like a new and previously unknown executable.
If you already own a code-signing certificate, you can configure it directly in .NET Reactor. .NET Reactor can then automatically sign your application after protection, so the final protected output is the file that carries your signature.
See the code-signing guide for the available signing options and setup instructions.
A digital signature does not guarantee that a file will never be detected, but in practice it can significantly reduce reputation-based and heuristic false positives.
#
Submit a false-positive report to the antivirus vendor
If a signed build is still detected, or if you do not currently use a code-signing certificate, submit the file as a false positive to the antivirus vendor that reports it.
Most antivirus vendors provide a dedicated false-positive or software-developer submission channel. After review, the vendor can correct its detection or reputation data. In many cases this happens within one or two business days, although the exact turnaround depends on the vendor.
For Microsoft Defender, use Microsoft's official file-submission portal. For other products, use the official false-positive submission page of the corresponding vendor.
When submitting a sample, include:
- the exact detected file,
- the detection name,
- the product/version of your application,
- a short explanation that the application is protected with .NET Reactor,
- and, if available, the SHA-256 hash of the affected file.
You can calculate the SHA-256 hash in PowerShell with:
Get-FileHash 'C:\Release\MyApp.exe' -Algorithm SHA256
Do not upload private signing keys, .NET Reactor license data, customer licenses, or other confidential material together with the sample.
#
A few useful checks
If a customer reports a detection, first confirm that the file is the same file you shipped. Compare its hash with your release artifact and verify that the digital signature is valid if the release is supposed to be signed.
If possible, also compare the unprotected application with the protected output. If only the protected file is detected, that is useful information for the antivirus vendor when reviewing the false-positive report.
Do not ask customers to disable their antivirus permanently or add broad exclusions as a general solution. The better long-term fix is code signing, a corrected antivirus signature/reputation entry, or both.
#
When to contact .NET Reactor support
If several antivirus products detect the same protected build, or if you are unsure whether the detection is related to a particular protection option, contact .NET Reactor support.
Please include:
- your .NET Reactor version,
- the target framework,
- the protection options you use,
- the antivirus product and detection name,
- and, if you already submitted the file to the vendor, the corresponding case/reference number.
Do not post proprietary binaries, master keys, or license files in a public issue tracker. If a sample is required, arrange a suitable private transfer channel with support.
#
Related topics
Code signing · Verify protected output · Choosing protection settings