Anti-Tamper Enterprise
Without tamper detection, an attacker can patch the obfuscated binary and bypass all static protection. Anti-tamper makes the obfuscated assembly verify itself at startup. If the file has been modified after the build, the application terminates immediately — before any of your code runs.
Usage
| CLI | MSBuild | Default |
|---|---|---|
| (enabled by default at Enterprise) | (enabled by default at Enterprise) | On |
--no-anti-tamper | <DemeanorNoAntiTamper>true</DemeanorNoAntiTamper> | Disable |
What Makes It Effective
- License-keyed: Tamper detection is bound to your license, so an attacker who understands the technique cannot produce a patched build that still passes the check.
- Hidden inside the protections: The check is renamed, its constants are encrypted, and its control flow is obfuscated alongside everything else — making it hard to locate and remove.
- Compatible with strong-name signing: Signing your assembly after Demeanor runs does not break the check.
NativeAOT Compatibility
The injected check uses only NativeAOT-safe APIs — no reflection, no dynamic loading. In AOT deployments where the assembly file isn’t present on disk at runtime, the check is a no-op rather than a failure.
When to Disable
- Post-build tooling: If another tool modifies your assembly after Demeanor (other than strong-name signing), anti-tamper will detect the modification. Run such tools before obfuscation, or disable anti-tamper.
- NativeAOT-only deployment: If your application is published exclusively as NativeAOT (no IL assemblies at runtime), anti-tamper has no effect. You can disable it to avoid the additional code.
Ready to protect your .NET code?