Décompiler une application Blazor WebAssembly : lire les DLL .NET que le navigateur a téléchargées

La première fois qu’on ouvre les outils de développement sur une application Blazor WebAssembly et qu’on voit un dossier _framework plein de fichiers .wasm, cela paraît rassurément opaque — comme le blob WebAssembly compilé qu’on ne peut pas lire. Il n’en est rien. Blazor WebAssembly ne compile pas votre C# en WebAssembly ; il envoie un runtime .NET (en WASM) plus vos assemblies .NET ordinaires, et les exécute dans le navigateur. Ces assemblies sont téléchargées chez chaque visiteur, métadonnées et IL intacts, ce qui signifie que votre C# côté client se décompile aussi proprement que n’importe quelle DLL sur votre disque. Comprendre comment les lire est aussi le moyen le plus rapide de comprendre ce qu’il ne faut pas y mettre.

Ce qui est envoyé au navigateur

Au chargement d’une application Blazor WebAssembly, elle récupère un manifeste — _framework/blazor.boot.json — qui liste chaque assembly dont l’application a besoin, chacune avec un nom de fichier et un hachage d’intégrité. Le navigateur télécharge alors ces fichiers depuis _framework/. Dans le .NET actuel ils arrivent en webcil : votre assembly PE enveloppée dans un conteneur compatible WebAssembly. Webcil existe pour une raison banale — certains proxys, CDN et pare-feu d’entreprise altèrent ou bloquent les téléchargements de .dll bruts — donc le .dll est réempaqueté sous une forme qui passe comme une ressource de style .wasm. Et l’essentiel : webcil est une enveloppe, pas un chiffrement : les métadonnées ECMA-335 et l’IL d’origine sont à l’intérieur, octet pour octet.

La chaîne de « application déployée » à « votre code source » est donc courte : blazor.boot.json nomme les assemblies, _framework/ les sert, webcil contient le vrai PE, et un décompilateur relève l’IL en C#.

Les lire dans Glass

Le flux est le même que pour n’importe quelle assembly, avec une petite étape préalable pour webcil :

1. Ouvrez le _framework/blazor.boot.json de l’application en cours (outils de dev → Réseau, ou récupérez-le directement) et notez les assemblies qui vous intéressent — généralement votre assembly d’application et vos propres bibliothèques, pas celles du framework.
2. Téléchargez ces fichiers depuis _framework/.
3. Ouvrez-les dans Glass. Glass lit l’assembly .NET à l’intérieur du conteneur webcil et reconstruit le C# — vos composants, vos services, vos modèles — exactement comme pour une DLL de bureau. (Pour les versions antérieures de Blazor, les fichiers sont des .dll normaux et s’ouvrent directement.)

À partir de là, c’est de la décompilation ordinaire : parcourez les types, lisez les corps de méthode, suivez les références — comme pour décompiler n’importe quelle DLL en C#.

La vraie leçon : le côté client est public

C’est moins un tutoriel de décompilation qu’un rappel de sécurité accompagné d’une démonstration. Le code Blazor WebAssembly s’exécute sur la machine de l’utilisateur, il est donc aussi exposé que du JavaScript. Tout ce que vous y intégrez — une clé d’API, une chaîne de connexion, un contournement de licence, une logique de tarification propriétaire — peut être relu en quelques minutes avec les étapes ci-dessus. Les conclusions défensives :

• Gardez les secrets et la logique sensible côté serveur (une API backend, ou Blazor Server où le C# reste sur le serveur et où seuls les diffs du DOM traversent le réseau).
• Si vous devez livrer de la logique sensible au client, obfusquez-la — les assemblies Blazor WASM peuvent être renommées et voir leurs chaînes chiffrées comme toute assembly (voir protéger Blazor WebAssembly de la décompilation) — en gardant à l’esprit que la protection côté client relève le niveau, elle ne rend pas le code secret.

Pouvoir lire votre propre application comme le ferait un attaquant est précisément l’objectif : faites-le une fois, et vous saurez exactement ce qu’il ne faut pas mettre dans le navigateur.

Le faire avec Glass

Glass ouvre les assemblies derrière une application Blazor WebAssembly — en lisant directement à travers l’enveloppe webcil jusqu’à l’IL et en reconstruisant le C# — pour que vous puissiez auditer précisément ce que votre client déployé expose. Il est gratuit, et c’est le même outil que vous utiliseriez pour comprendre n’importe quel code .NET inconnu.

Récupérez-le sur la page Glass et ouvrez le _framework de votre propre application pour voir ce qui est livré.