Descompilar una app Blazor WebAssembly: leer las DLL .NET que descargó el navegador
Una app Blazor WebAssembly envía tus ensamblados .NET al navegador — empaquetados como webcil, pero con el IL completo. Esto es cómo sacarlos de _framework, leerlos en un descompilador y por qué tu C# del lado cliente está tan expuesto como JavaScript.
La primera vez que alguien abre las herramientas de desarrollador en una app Blazor WebAssembly y ve una carpeta _framework llena de archivos .wasm, parece tranquilizadoramente opaca — como el blob WebAssembly compilado que no puedes leer. No lo es. Blazor WebAssembly no compila tu C# a WebAssembly; envía un runtime de .NET (como WASM) más tus ensamblados .NET corrientes, y los ejecuta en el navegador. Esos ensamblados se descargan a cada visitante, con metadatos e IL intactos, lo que significa que tu C# del lado cliente se descompila tan limpiamente como cualquier DLL de tu disco. Entender cómo leerlos es también la forma más rápida de entender qué no debes poner en ellos.
Qué se envía al navegador
Cuando se carga una app Blazor WebAssembly, obtiene un manifiesto — _framework/blazor.boot.json — que lista cada ensamblado que la app necesita, cada uno con un nombre de archivo y un hash de integridad. El navegador descarga entonces esos archivos de _framework/. En el .NET actual llegan como webcil: tu ensamblado PE envuelto en un contenedor compatible con WebAssembly. Webcil existe por una razón mundana — algunos proxies, CDN y firewalls corporativos estropean o bloquean las descargas de .dll en crudo — así que el .dll se reempaqueta en una forma que pasa como un recurso estilo .wasm. Y lo esencial: webcil es una envoltura, no cifrado: los metadatos ECMA-335 y el IL originales están dentro, byte a byte.
Así que la cadena de “app desplegada” a “tu código fuente” es corta: blazor.boot.json nombra los ensamblados, _framework/ los sirve, webcil contiene el PE real, y un descompilador eleva el IL de vuelta a C#.
Leerlos en Glass
El flujo es el mismo que usarías con cualquier ensamblado, con un pequeño paso previo para webcil:
- Abre el
_framework/blazor.boot.jsonde la app en ejecución (herramientas de desarrollador → Red, u obtenlo directamente) y anota los ensamblados que te interesan — normalmente tu ensamblado de app y tus propias bibliotecas, no los del framework. - Descarga esos archivos de
_framework/. - Ábrelos en Glass. Glass lee el ensamblado .NET dentro del contenedor webcil y reconstruye C# — tus componentes, tus servicios, tus modelos — exactamente como lo hace con una DLL de escritorio. (En versiones anteriores de Blazor los archivos son
.dllnormales y se abren directamente.)
A partir de ahí es descompilación corriente: navega por tipos, lee cuerpos de método, sigue referencias — igual que descompilar cualquier DLL a C#.
La lección real: el lado cliente es público
Esto es menos un tutorial de descompilación que un recordatorio de seguridad con una demostración adjunta. El código Blazor WebAssembly se ejecuta en la máquina del usuario, así que está tan expuesto como JavaScript. Cualquier cosa que incrustes en él — una clave de API, una cadena de conexión, un bypass de licencias, lógica de precios propietaria — puede leerse en minutos con los pasos anteriores. Las conclusiones defensivas:
- Mantén los secretos y la lógica sensible del lado servidor (una API de backend, o Blazor Server donde el C# se queda en el servidor y solo cruzan el cable los diffs del DOM).
- Si debes enviar lógica sensible al cliente, ofúscala — los ensamblados Blazor WASM pueden renombrarse y cifrar sus cadenas como cualquier ensamblado (véase proteger Blazor WebAssembly de la descompilación) — recordando que la protección del lado cliente sube el listón, no vuelve secreto el código.
Poder leer tu propia app como lo haría un atacante es justo el punto: hazlo una vez y sabrás exactamente qué no poner en el navegador.
Cómo hacerlo con Glass
Glass abre los ensamblados que hay detrás de una app Blazor WebAssembly — leyendo directamente a través de la envoltura webcil hasta el IL y reconstruyendo C# — para que puedas auditar con precisión qué expone tu cliente desplegado. Es gratuito, y es la misma herramienta que usarías para entender cualquier código .NET desconocido.
Consíguelo en la página de Glass y abre el _framework de tu propia app para ver qué se envía.
Prueba Nebula.NET
Endurece tu código .NET en minutos — empieza con la edición gratuita.