Skip to content

Nebula.NET

Protecting Blazor WebAssembly

Obfuscate a published Blazor WebAssembly app and keep it loading — Nebula.NET repairs the boot-manifest integrity hashes and pre-compressed copies so the browser accepts the protected assemblies.

Blazor WebAssembly ships your real .NET assemblies to the browser, where anyone can download and decompile them from _framework. That makes it the highest-exposure .NET target there is — and the one most obfuscators don’t properly handle.

The catch is that you can’t just obfuscate the DLLs in a published app: Blazor verifies every assembly against a SHA-256 integrity manifest (blazor.boot.json) and refuses to load anything whose hash doesn’t match, and it serves pre-compressed .br/.gz copies that must match too. Obfuscate a DLL by hand and the app simply won’t start.

Nebula’s blazor command does the whole thing: it obfuscates the app assemblies and repairs the manifest and the compressed copies, so the protected app loads normally.

Usage

Publish your app as usual, then run Nebula against the published wwwroot/_framework folder:

dotnet publish -c Release -o publish
nebula blazor --framework publish/wwwroot/_framework --config nebula.config.json
  • --framework — the published app’s wwwroot/_framework directory.
  • --config — your obfuscation settings (no inputs needed; Nebula supplies each assembly).
  • --assembly <Name> — protect a specific assembly (repeatable). Default: the app’s entry assembly. Framework/BCL assemblies are never touched.

For each protected assembly Nebula: obfuscates it, recomputes its sha256-… entry in blazor.boot.json, and regenerates its .br and .gz copies — then rewrites the manifest and its own compressed copies. The result passes the browser’s integrity check and runs exactly as before.

What to protect

Your app assemblies — the ones containing your logic — are the target. Business rules, pricing, feature gates and any client-side validation are fully visible in an unprotected Blazor WASM build, so this is exactly where string encryption, control-flow flattening and (Enterprise) code virtualization pay off most.

Requirements & notes

  • Publish assemblies as plain .dll (the default in most setups). If your build uses Webcil (.wasm-wrapped assemblies), disable it for now with <WasmEnableWebcil>false</WasmEnableWebcil> in your project — Webcil unwrap/rewrap support is planned.
  • Run nebula blazor after dotnet publish, on the published output.
  • The command applies your license edition’s feature set, same as any other Nebula run.
  • Reminder: client-side code is inherently reachable — obfuscation raises the cost of reading it substantially, but genuinely secret logic (and secrets) still belongs on the server.