Ship Blazor WebAssembly without shipping your C#.
Publish ahead of time, and TrustSig Protect obfuscates and virtualizes the WebAssembly that comes out.
LicenseService.Validatevm.0x3f1aBilling.ApplyDiscountvm.0x8c47TokenStore.Unsealvm.0x21d9Entitlements.Loadvm.0xb6e2
App.dllBilling.dllLicensing.dll
Decompiles back to C#
Your C# arrives in the browser as a download.
A Blazor app publishes into a folder the browser fetches like any other.
A default publish sends .NET assemblies to every visitor, and they sit in the browser cache.
Free decompilers read those assemblies back into something close to the C# you wrote.
Class names, method names and the logic behind every licence check come back with them.
Publish ahead of time, then protect the output.
AOT compiles your C# into WebAssembly before it ever reaches a browser.
Turn AOT compilation on in your publish profile and your methods are compiled into WebAssembly.
That WebAssembly is what Protect works on, and it is where your compiled logic now lives.
A default interpreted build stays out of scope, so run the AOT publish first.
Publishing your app stops meaning publishing your code.
A normal Blazor publish hands a decompiler something close to your source in seconds. After an AOT publish and a protected build, there are no method names to search and no order to follow.
Nothing is named, and nothing runs in order.
The names go, and the path through your code stops making sense.
Every meaningful function, import and export name is stripped or randomised.
Control flow is flattened, so the order your code runs in is no longer visible in the file.
Fake decision points sit next to the real ones and survive the clean-up passes tools run.
Instructions only our engine runs
The methods that matter stop being WebAssembly at all.
Obfuscation hides how your code reads. Virtualization changes what it is.
You pick the methods worth hiding: licence checks, pricing rules, key handling.
Protect compiles them into bytecode for an instruction set that exists only in your build.
A small engine ships with your app and runs that bytecode, and every build gets a different instruction set.
What a protected publish carries.
- Virtualization
- The methods you pick run as bytecode on an engine that only your build has.
- Control-flow flattening
- The order your code runs in stops being visible in the file.
- Symbol scrubbing
- Function, import and export names are stripped or randomised.
- Polymorphic builds
- Every publish differs byte for byte, down to the layout of the bytecode.
- String vault
- Sensitive values stay encrypted and are decrypted only for the instant they are used.
- Anti-debugging
- Breakpoints and single-stepping are detected while your app runs.
Blazor WebAssembly, answered
Protect works on the WebAssembly an AOT publish produces, so turn AOT compilation on before you protect a build.
Yes, the runtime still needs them. Protect covers the WebAssembly your AOT publish produces, which is where your compiled methods live.
Yes. Protect ships an engine for JavaScript as well, so interop code and anything else you choose gets the same treatment.
Only the methods you choose run inside the engine, so the rest of your app runs at the speed AOT gave it.
Get in touch.
Tell us what your Blazor app does, what needs protecting, or whatever you want to ask.