FreeObfuscator.NET protection

.NET · C# · DLL · EXE

Strong names and obfuscation: plan the signing step before release

Avoid broken assembly identities and misplaced signing keys when protecting a signed .NET DLL or EXE.

Open the obfuscator

The upload, account and checkout interface is in English.

Strong naming is identity, not secrecy

A strong name includes the assembly name, version, culture and public key information. It does not encrypt IL or stop decompilation, and Microsoft explicitly warns against treating strong names as a security boundary. Authenticode publisher signing is a separate mechanism. Record which kind of signing your distribution actually requires; do not assume that retaining an .exe extension preserves either signature.

Use an unsigned input for this service

FreeObfuscator rejects strong-name signed or delay-signed input. Prepare a separate unsigned Release build for the protection step, keeping the original signed distribution intact. A project-level build override can help with simple SDK projects, but imported targets, reference identities and multi-assembly signing policies may need a dedicated configuration. Do not remove signature metadata from an arbitrary released file and assume the resulting package is equivalent. Never upload an .snk, .pfx or certificate password.

Re-signing needs the right build pipeline

Before committing to this route, confirm that your chosen signing tool can correctly sign the transformed assembly. An unsigned file may not contain the strong-name signature reservation needed by a simple re-sign command; a sn -R command is not a universal recipe. Signing a dependency may also change the identity expected by its callers. Treat signing, reference updates and package assembly as one release operation in a trusted local environment.

Test the final consumers

Inspect the assembly identity before and after the complete process. A public key token being present is not proof that a signature is valid. Verify signatures with the tooling appropriate to your runtime and distribution, then run an existing consumer, plugin loader and installer against the final package. Keep a rollback package. If your signing contract cannot be maintained, do not ship an unsigned substitute merely because the test application loads.

dotnet build MyLibrary.csproj -c Release -p:SignAssembly=false -p:DelaySign=false -o ./unsigned-check
# Inspect identity only; this is NOT signature validation:
[System.Reflection.AssemblyName]::GetAssemblyName((Resolve-Path './unsigned-check/MyLibrary.dll')).FullName

Protection guides