DEV Community

Zero Heartbeat
Zero Heartbeat

Posted on Edited on Originally published at delta1labs.com

Decompiling a Blazor WebAssembly App: Reading the .NET DLLs the Browser Downloaded

The first time someone opens the browser dev tools on a Blazor WebAssembly app and sees a _framework folder full of .wasm files, it looks reassuringly opaque — like the compiled WebAssembly blob you cannot read. It is not. Blazor WebAssembly does not compile your C# to WebAssembly; it ships a .NET runtime (as WASM) plus your ordinary .NET assemblies, and runs them in the browser. Those assemblies are downloaded to every visitor, metadata and IL intact, which means your client-side C# decompiles as cleanly as any DLL on your disk. Understanding how to read them is also the fastest way to understand what you must not put in them.

What ships to the browser

When a Blazor WebAssembly app loads, it fetches a manifest — _framework/blazor.boot.json — that lists every assembly the app needs, each with a filename and an integrity hash. The browser then downloads those files from _framework/. In current .NET they arrive as webcil: your PE assembly wrapped in a WebAssembly-compatible container. Webcil exists for a mundane reason — some proxies, CDNs, and corporate firewalls mangle or block raw .dll downloads — so the .dll is repackaged in a form that sails through as a .wasm-style asset. Crucially, webcil is a wrapper, not encryption: the original ECMA-335 metadata and IL are inside, byte-for-byte.

So the chain from "deployed app" to "your source" is short: blazor.boot.json names the assemblies, _framework/ serves them, webcil holds the real PE, and a decompiler lifts the IL back to C#.


From a Blazor WASM deployment to decompiled C#
.b{fill:none;stroke:#64748b;stroke-width:1.5}.t{fill:currentColor;font-size:12.5px}.s{fill:#64748b;font-size:11px}.hl{stroke:#6366f1;stroke-width:2}.ar{stroke:#64748b;stroke-width:1.5;marker-end:url(#z)}

blazor.boot.jsonlists assemblies

_framework/*.wasmwebcil wrapper

PE: metadata+IL(unchanged inside)

Glass → C#readable source
Webcil is packaging, not protection — the IL inside decompiles exactly like any .NET assembly.

Reading them in Glass

The workflow is the same one you would use on any assembly, with one small front step for webcil:

  1. Open the running app's _framework/blazor.boot.json (dev tools → Network, or fetch it directly) and note the assemblies you care about — typically your app assembly and any of your own libraries, not the framework ones.
  2. Download those files from _framework/.
  3. Open them in Glass. Glass reads the .NET assembly inside the webcil container and reconstructs C# — your components, your services, your models — exactly as it does for a desktop DLL. (For older Blazor versions the files are plain .dll and open directly.)

From there it is ordinary decompilation: navigate types, read method bodies, follow references — the same as decompiling any DLL to C#.

The real lesson: client-side is public

This is less a decompilation tutorial than a security reminder with a demonstration attached. Blazor WebAssembly code runs on the user's machine, so it is as exposed as JavaScript. Anything you embed in it — an API key, a connection string, a licensing bypass, proprietary pricing logic — can be read back in minutes with the steps above. The defensive conclusions:

  • Keep secrets and sensitive logic server-side (a backend API, or Blazor Server where the C# stays on the server and only DOM diffs cross the wire).
  • If you must ship sensitive logic to the client, obfuscate it — Blazor WASM assemblies can be renamed and string-encrypted like any assembly (see protecting Blazor WebAssembly from decompilation) — while remembering that client-side protection raises the bar, it does not make the code secret.

Being able to read your own app the way an attacker would is the point: do it once, and you will know exactly what not to put in the browser.

Doing this with Glass

Glass opens the assemblies behind a Blazor WebAssembly app — reading straight through the webcil wrapper to the IL and reconstructing C# — so you can audit precisely what your deployed client exposes. It is free, and it is the same tool you would use to understand any unfamiliar .NET code.

Grab it from the Glass page and open your own app's _framework to see what ships.

Top comments (0)