dotnet-reverse

.NET / C# — Normes de rétro-ingénierie

ACTION REQUISE (à lire et exécuter immédiatement)

1. MAINTENANT : Utiliser DIE / file / en-tête CLR pour confirmer que la cible est un assembly .NET managé (sinon, BASKULER vers ida-reverse/ / reverse-engineering/)
2. MAINTENANT : Si suspicion d'obfusqueur → exécuter de4dot pour désobfusquer, produire *-clean.exe, conserver l'échantillon original
3. SUIVANT : dnSpyEx (ou dnSpy MCP / ilspycmd) en statique : naviguer dans le code C# + vue IL pour les décisions critiques
4. AGIR : En cas de besoin de texte clair / C2 → déboguer dynamiquement ; si une modification de logique est nécessaire, privilégier le patch IL plutôt que la recompilation C#
5. En fin de phase, proposer à l'utilisateur un menu de 3 à 6 étapes suivantes (incluant l'exportation du rapport)

Périmètre d'application

Ce skill est prioritaire lorsque la tâche correspond aux scénarios suivants :

• Identifier et rétro-ingénierer des produits de compilation .NET / C# (assembly managé PE / .exe / .dll)
• Analyser la chaîne d'outils Sharp* de la red team (Rubeus, SharpHound, SharpShell, etc.)
• Désobfusquer ConfuserEx / SmartAssembly / Babel / Eazfuscator / .NET Reactor et autres packers
• Rétro-ingénierer la logique de déchiffrement et de C2 d'un loader .NET, d'un info-stealer ou d'un RAT
• Patcher un programme C# (modifier des jugements, des constantes, keygen)
• Analyser la couche managée Mono/Unity avant IL2CPP (attention : IL2CPP compile en natif, utiliser reverse-engineering/ + seed-014)

Si la cible est un binaire purement natif (C/C++/Go/Rust, sans CLR), basculer vers reverse-engineering/, ida-reverse/ ou radare2/.

Principes fondamentaux

• Identifier avant d'agir : confirmer d'abord qu'il s'agit d'un assembly .NET managé (en-tête PE CLR + flux #~ / #Strings + point d'entrée _CorExeMain de mscoree), puis choisir dnSpy plutôt qu'IDA
• IL d'abord, C# ensuite : le décompilateur C# de dnSpyEx perd ou déforme certaines informations (machines d'état générées par le compilateur, async/await, yield). Les décisions critiques et les patchs doivent être effectués dans l'éditeur IL ; la vue C# sert uniquement à une navigation rapide
• de4dot en premier : face à un obfusqueur, lancer d'abord de4dot pour désobfusquer avant toute analyse statique, sinon les chaînes et le flux de contrôle seront illisibles
• Couplage avec MCP : si l'environnement dispose de dnSpy MCP (outils dnspy_*), privilégier l'interface MCP pour la décompilation / l'inspection IL, afin d'éviter de basculer entre les interfaces graphiques
• Résultats tangibles : enregistrer systématiquement le produit désobfusqué, les configurations extraites (C2, clés) et les diffs de patch

Correspondance des outils

Capacité	Option prioritaire	Remarques
Décompilation + débogage + patch	dnSpyEx	L'outil de référence, seul à proposer un éditeur IL graphique ; l'ancien dnSpy n'est plus maintenu, utiliser la branche Ex
Décompilation légère en CLI / headless	ILSpy (ilspycmd)	Adapté au traitement par lots, aux scripts, sous Linux/macOS
Désobfuscation	de4dot	Solution par défaut pour ConfuserEx, SmartAssembly et la plupart des packers courants
Identification de l'obfusqueur	Detect It Easy (DIE) / file	Déterminer d'abord le type de packer avant de paramétrer de4dot
Manipulation programmatique d'IL	dnlib	Scripts C# pour modifier en masse les métadonnées / implémenter un déchiffreur de chaînes
Action directe depuis l'IA	dnSpy MCP	Interface via les outils dnspy_decompile / dnspy_inspect_il

Prérequis : disposer de dnSpyEx + de4dot sur Windows (choco ou release) ; sous Linux/macOS, utiliser ilspycmd + dotnet runtime. Voir la matrice d'installation dans references/sharp-tools.md.

Flux de travail en six phases

1. Identifier (reconnaissance .NET)

Confirmer que la cible est un assembly managé, ne pas analyser un PE natif comme du .NET :

# Windows
file target.exe                       # "PE32 executable ... for MS Windows" ne suffit pas
# Décisif : vérifier la présence du CLR
powershell -c "[System.Reflection.AssemblyName]::GetAssemblyName('target.exe')"
# Ou
# Glisser target.exe dans dnSpyEx — s'il s'ouvre, c'est un assembly managé

# Générique
strings target.exe | grep -iE "mscoree|_CorExeMain|mscorlib|System\\."

Indices de reconnaissance .NET :

• L'entrée Data Directory[14] (en-tête Runtime CLR) du PE est non nulle
• Importation de mscoree.dll / point d'entrée _CorExeMain
• Flux de métadonnées #~, #Strings, #US, #GUID, #Blob
• Chaîne mscorlib / System.Private.CoreLib

Exception NativeAOT : compilé en natif, pas d'en-tête CLR, mais présence de la chaîne System.Private.CoreLib et de métadonnées de types restructurées — utiliser reverse-engineering/ (IDA/r2) ; ce skill se limite à fournir une indication de reconnaissance.

2. Détecter (recherche de l'obfusqueur)

# DIE en identification rapide
diec target.exe                        # Detect It Easy CLI
# Ou glisser dans dnSpyEx et vérifier la présence de noms de classes illisibles / flux de contrôle déformé

Obfusqueurs courants → stratégie de désobfuscation (voir references/obfuscators.md) :

Obfusqueur	Caractéristique	Traitement de4dot
ConfuserEx (1.0.0 / 2.x)	anti-tamper <module>, flux de contrôle déformé, chiffrement de chaînes	de4dot target.exe (généralement reconnu automatiquement)
SmartAssembly	circular/string encoding, compression des ressources	de4dot target.exe
Babel.NET	Chiffrement des corps de méthode, flux de contrôle	de4dot target.exe
Eazfuscator.NET	Chiffrement de chaînes/ressources	de4dot, certains versions nécessitent une intervention manuelle
.NET Reactor	anti-tamper + necrobit	de4dot, les nouvelles versions peuvent échouer et nécessiter une approche manuelle

3. Désobfusquer

# de4dot reconnaît automatiquement la plupart des packers par défaut
de4dot target.exe -o target-clean.exe

# Spécifier un type (en cas d'échec de la reconnaissance automatique)
de4dot --type cfze target.exe          # ConfuserEx
de4dot --type sa target.exe            # SmartAssembly

# Obfuscation multiple / de4dot indique "unknown"
de4dot --detect target.exe             # Voir ce qu'il reconnaît
# Il peut être nécessaire de patcher d'abord l'anti-tamper avant de relancer de4dot (voir references/obfuscators.md)

Produit : target-clean.exe — l'analyse ultérieure utilise ce fichier. Conserver l'échantillon original pour comparaison.

4. Analyser statiquement

Charger l'échantillon désobfusqué dans dnSpyEx :

• Vue C# : navigation rapide dans la structure des classes, les signatures de méthodes, les chaînes (pour le repérage)
• Vue IL : les décisions critiques, la logique de chiffrement et les machines d'état doivent être examinées en IL (clic droit → Edit IL ou vue IL)
• Rechercher le point d'entrée : Main / Startup / initialiseur de module (Module .cctor)
• Chercher la logique clé : rechercher flag, password, verify, check, encrypt, http, Config

Localiser une chaîne → remonter aux références → trouver la méthode qui l'utilise → inspecter la logique de décision en vue IL

5. Déboguer dynamiquement

Débogueur dnSpyEx : attacher au processus / lancer le débogage, placer des points d'arrêt sur les méthodes clés, observer l'exécution :

• Chaînes déchiffrées en clair (souvent, les chaînes des obfusqueurs ne sont déchiffrées qu'à l'exécution)
• Adresse C2, résultat du déchiffrement de la configuration
• Flux de contrôle piloté par exceptions (anti-débogage : utilisation courante de try/catch pour masquer le chemin réel)

Le débogage dynamique .NET est bien plus simple que le natif — on peut visualiser directement les valeurs des objets et le contenu des chaînes. Privilégier le dynamique plutôt que de s'acharner en statique.

6. Patcher (modification à la demande)

dnSpyEx → clic droit sur une méthode → Edit Method (C#) ou Edit IL
  - Modifier une condition : ldc.i4.0 → ldc.i4.1 (false→true)
  - Modifier une constante : éditer directement la chaîne/le nombre
  - Supprimer une validation : mettre l'ensemble en NOP
File → Save Module → remplacer le fichier original

Fiabilité du patch IL > patch C# : la recompilation C# peut échouer (références manquantes, erreurs de syntaxe), alors que l'édition IL ne déforme pratiquement jamais le code. Voir references/common-workflow.md.

Aiguillage déclencheur

Ce skill est activé lorsque l'utilisateur dit :

• "rétro-ingénierie de binaire .NET / C#" / "décompilation de programme C#"
• "analyse avec dnSpy" / "patch avec dnSpyEx"
• "désobfuscation / dépacking de ConfuserEx / SmartAssembly / Babel"
• "analyse d'outil Sharp*" (Rubeus / SharpHound / SharpShell)
• "rétro-ingénierie de malware / loader / info-stealer .NET"
• "patch / keygen / modification de condition de programme C#"

Quand basculer

• Jeu Unity compilé en IL2CPP → reverse-engineering/ + seed-014_unity-il2cpp-reverse.md (IL2CPP est natif, ne pas utiliser dnSpy)
• Produit NativeAOT → reverse-engineering/ (idem, natif)
• PE natif pur (sans CLR) → reverse-engineering/ / ida-reverse/
• Besoin de migrer des symboles/fonctions en masse vers une autre version → binary-diff/
• Besoin de dessiner une chaîne d'attaque / un graphe d'appels → diagram-generator/

Contexte d'aiguillage

Entrée amont : skills/SKILL.md (pilote central), routing.md Sortie aval :

• IL2CPP / NativeAOT (natif) → reverse-engineering/
• Analyse approfondie de segments .so/.dll natifs → ida-reverse/ / radare2/
• Besoin d'une action directe de l'IA sur dnSpy → enregistrer et utiliser dnSpy MCP (voir references/sharp-tools.md)

Modules associés au même niveau :

• reverse-engineering/languages-compiled.md (présentation .NET pointant vers ce module)
• apk-reverse/ (rétro-ingénierie Android Xamarin/MAUI pouvant revenir à ce module pour la couche C#)

Documents de référence

• references/obfuscators.md — Détails sur la désobfuscation de ConfuserEx / SmartAssembly / Babel / Eazfuscator / .NET Reactor + contournement anti-tamper
• references/common-workflow.md — Flux de travail complet, fiabilité du patch IL, extraction de déchiffreur de chaînes, reconnaissance de machines d'état
• references/sharp-tools.md — Analyse des outils Sharp* de la red team, matrice d'installation, intégration dnSpy MCP, index des ressources communautaires

Auto-vérification de fin de tâche

• A-t-on confirmé l'identité CLR / managée (ou a-t-on déjà BASCULÉ hors de ce skill) ?
• L'échantillon obfusqué a-t-il d'abord été désobfusqué avec de4dot (ou équivalent) avant analyse approfondie ?
• La logique critique a-t-elle été vérifiée dans la vue IL (et non seulement dans le pseudo-code C#) ?
• Les artéfacts (échantillon clean / configuration / diff de patch) sont-ils enregistrés et reproductibles ?
• Un menu d'étapes suivantes ou un rapport a-t-il été fourni ?