.NET / C# Reverse-Engineering – Arbeitsrichtlinie
ACTION REQUIRED (sofort nach Lesen ausführen)
NOW: Mit DIE/file/CLR-Header prüfen, ob das Ziel eine .NET Managed Assembly ist (ansonsten zuida-reverse//reverse-engineering/wechseln)NOW: Bei Obfuskationsverdacht → zuerstde4dotzum Entschleiern verwenden, Ausgabe*-clean.exe, Originalprobe behaltenNEXT: dnSpyEx (oder dnSpy MCP /ilspycmd) statisch: C#-Durchsuchen + IL-Ansicht für kritische EntscheidungenACT: Bei Bedarf nach Klartext/C2 dynamisch debuggen; bei Logikänderungen IL-Patch vor C#-Neukompilierung bevorzugen- Am Ende dem Benutzer 3–6 nächste Schritte als Menü anbieten (inkl. Berichtsexport)
Anwendungsbereich
Dieses Skill wird vorrangig in folgenden Szenarien eingesetzt:
- Erkennen und Reverse-Engineering von .NET / C#-Kompilaten (Managed PE / .exe / .dll)
- Analyse von Red-Team-Sharp*-Werkzeugen (Rubeus, SharpHound, SharpShell usw.)
- Entschleiern von ConfuserEx / SmartAssembly / Babel / Eazfuscator / .NET Reactor und ähnlichen Schützern
- Reverse-Engineering der Entschlüsselung und C2-Logik von .NET-Loadern, Info-Stealern und RATs
- Patchen von C#-Programmen (Ändern von Bedingungen, Konstanten, Keygen)
- Analyse der Mono/Unity-Managed-Schicht vor IL2CPP (Hinweis: IL2CPP-kompilierte Dateien sind nativ →
reverse-engineering/+seed-014)
Wenn das Ziel eine reine native Binärdatei (C/C++/Go/Rust, kein CLR) ist, verwenden Sie stattdessen reverse-engineering/, ida-reverse/ oder radare2/.
Kernprinzipien
- Erst identifizieren, dann loslegen: Zuerst bestätigen, dass es sich um ein .NET Managed Programm handelt (PE-Header CLR +
#~/#Strings-Streams + mscoree_CorExeMain), dann mit dnSpy arbeiten statt IDA - IL vor C#: Der C#-Decompiler von dnSpyEx kann Informationen verlieren oder verfälschen (Compiler-generierte Zustandsautomaten, async/await, yield). Kritische Prüfungen und Patches müssen im IL-Editor durchgeführt werden; die C#-Ansicht dient nur zum schnellen Überblick
- de4dot zuerst: Bei Obfuskationsverdacht zuerst
de4dotanwenden, bevor die statische Analyse beginnt – sonst sind Zeichenketten und Kontrollflüsse unlesbar - MCP-Kopplung: Wenn im System ein dnSpy MCP registriert ist (
dnspy_*-Tools), bevorzugt über die MCP-Oberfläche decompilieren/IL inspizieren, um GUI-Wechsel zu vermeiden - Belegbare Ausgabe: Entschleierte Dateien, extrahierte Konfiguration/C2/Keys und Patch-Diffs müssen auf der Festplatte gespeichert werden
Werkzeugzuordnung
| Fähigkeit | Bevorzugt | Hinweise |
|---|---|---|
| Decompilieren + Debuggen + Patchen | dnSpyEx | Das Aushängeschild, einzige GUI mit IL-Editor; älteres dnSpy wird nicht mehr gepflegt – Ex-Zweig verwenden |
| Leichtgewichtiges CLI / Headless-Decompilieren | ILSpy (ilspycmd) | Geeignet für Batch-, Skript- und Linux/macOS-Umgebungen |
| Entschleiern | de4dot | Standardlösung für ConfuserEx-Familie, SmartAssembly u. a. gängige Schützer |
| Erkennung von Obfuskation | Detect It Easy (DIE) / file | Zuerst den Schützertyp bestimmen, dann de4dot-Parameter wählen |
| Programmatische IL-Bearbeitung | dnlib | C#-Skripte für Massenänderungen an Metadaten / Zeichenkettenentschlüsselung |
| KI-Direktzugriff | dnSpy MCP | Über Werkzeugflächen wie dnspy_decompile / dnspy_inspect_il |
Voraussetzung: Windows-Rechner mit installiertem dnSpyEx + de4dot (per choco oder als Release); Linux/macOS verwenden
ilspycmd+dotnet runtime. Details zur Installationsmatrix finden Sie inreferences/sharp-tools.md.
Sechs-Phasen-Arbeitsablauf
1. Identifizieren (.NET erkennen)
Sicherstellen, dass das Ziel ein Managed Programm ist – keine native PE als .NET analysieren:
# Windows
file target.exe # „PE32 executable ... for MS Windows" reicht nicht
# Entscheidend: Prüfen auf CLR
powershell -c "[System.Reflection.AssemblyName]::GetAssemblyName('target.exe')"
# oder
dnSpyEx direkt ziehen – wenn es sich öffnet, ist es Managed
# Allgemein
strings target.exe | grep -iE "mscoree|_CorExeMain|mscorlib|System\."
.NET-Erkennungsmerkmale:
- PE-Header
Data Directory[14](CLR Runtime Header) ungleich Null - Import von
mscoree.dll/ Einstiegspunkt_CorExeMain - Metadatenströme
#~,#Strings,#US,#GUID,#Blob - Zeichenketten wie
mscorlib/System.Private.CoreLib
NativeAOT-Ausnahme: Wird in nativem Code kompiliert, kein CLR-Header, aber enthält System.Private.CoreLib-Zeichenketten und umstrukturierte Typmetadaten – solche Dateien fallen unter reverse-engineering/ (IDA/r2); dieses Skill dient hier nur als Erkennungshinweis.
2. Erkennen (Obfuskator erkennen)
# DIE-Schnellerkennung
diec target.exe # Detect It Easy CLI
# oder in dnSpyEx ziehen und nach vielen verstümmelten Klassennamen / Kontrollflussverformungen suchen
Häufige Obfuskatoren → Entschleierungsstrategie (Details in references/obfuscators.md):
| Obfuskator | Merkmale | de4dot-Behandlung |
|---|---|---|
| ConfuserEx (1.0.0 / 2.x) | <module> Anti-Tamper, Kontrollflussverformung, Zeichenkettenverschlüsselung | de4dot target.exe (automatische Erkennung) |
| SmartAssembly | circular/string encoding, Ressourcenkomprimierung | de4dot target.exe |
| Babel.NET | Methodenkörperverschlüsselung, Kontrollfluss | de4dot target.exe |
| Eazfuscator.NET | Zeichenketten-/Ressourcenverschlüsselung | de4dot; einige Versionen erfordern manuelle Eingriffe |
| .NET Reactor | Anti-Tamper + Necrobit | de4dot; neuere Versionen können fehlschlagen – dann manuell |
3. Entschleiern (Deobfuskatieren)
# de4dot erkennt die meisten gängigen Schützer automatisch
de4dot target.exe -o target-clean.exe
# Typ explizit angeben (bei fehlgeschlagener automatischer Erkennung)
de4dot --type cfze target.exe # ConfuserEx
de4dot --type sa target.exe # SmartAssembly
# Mehrschichtige Obfuskation / de4dot meldet „unknown"
de4dot --detect target.exe # Zeigt an, was erkannt wurde
# Eventuell muss zuerst Anti-Tamper gepatcht werden, bevor de4dot läuft (siehe references/obfuscators.md)
Ausgabe: target-clean.exe – für die weitere Analyse verwenden. Originalprobe zum Vergleich aufbewahren.
4. Statische Analyse
dnSpyEx lädt die entschleierte Probe:
- C#-Ansicht: Schneller Überblick über Klassenstrukturen, Methodensignaturen, Zeichenketten (zur Orientierung)
- IL-Ansicht: Kritische Prüfungen, Verschlüsselungslogik, Zustandsautomaten – immer in IL ansehen (Rechtsklick → Edit IL oder IL-Ansicht)
- Einstiegspunkte suchen:
Main/Startup/ Modulinitialisierer (Module .cctor) - Nach Schlüssellogik suchen:
flag,password,verify,check,encrypt,http,Config
Zeichenkette lokalisieren → Rückverfolgung → Methode mit ihrer Verwendung finden → IL-Ansicht für Prüflogik
5. Dynamisches Debuggen
dnSpyEx-Debugger: Prozess anhängen / Debugging starten, Haltepunkte in kritischen Methoden setzen, Laufzeit beobachten:
- Entschlüsselte Klartext-Zeichenketten (viele Obfuskatoren entschlüsseln Zeichenketten erst zur Laufzeit)
- C2-Adressen, Konfigurationsentschlüsselungsergebnisse
- Ausnahmegesteuerte Kontrollflüsse (Anti-Debug verwendet oft
try/catch, um den wahren Pfad zu verbergen)
.NET-Dynamisches Debugging ist viel benutzerfreundlicher als natives – Objektwerte und Zeichenketteninhalte sind direkt sichtbar. Dynamisches Debugging vor dem Verbeißen in statischer Analyse bevorzugen.
6. Patchen (nach Bedarf)
dnSpyEx → Rechtsklick auf Methode → Edit Method (C#) oder Edit IL
- Prüfung ändern: ldc.i4.0 → ldc.i4.1 (false → true)
- Konstanten ändern: Zeichenketten/Zahlen direkt bearbeiten
- Prüfung entfernen: gesamten Block mit nop überschreiben
File → Save Module → Originaldatei ersetzen
IL-Patch zuverlässiger als C#-Patch: C#-Neukompilierung kann fehlschlagen (fehlende Referenzen, Syntaxfehler); IL-Edit verzerrt fast nie. Details in references/common-workflow.md.
Auslöser-Routing
Wenn der Benutzer Folgendes erwähnt, wird dieses Skill aktiviert:
- ".NET / C#-Binäres Reverse Engineering" / „C#-Programm decompilieren"
- "dnSpy-Analyse" / „dnSpyEx-Patch"
- "ConfuserEx / SmartAssembly / Babel entschleiern / entpacken"
- „Sharp*-Tool-Analyse" (Rubeus / SharpHound / SharpShell)
- ".NET-Malware / Loader / Info-Stealer reverse-engineeren"
- "C#-Programm patchen / Keygen / Prüfung ändern"
Wann ausgestiegen wird
- IL2CPP-kompilierte Unity-Spiele →
reverse-engineering/+seed-014_unity-il2cpp-reverse.md(IL2CPP ist nativ, kein dnSpy) - NativeAOT-Produkte →
reverse-engineering/(ebenfalls nativ) - Reine native PE (kein CLR) →
reverse-engineering//ida-reverse/ - Symbole/Funktionen massenweise in andere Versionen portieren →
binary-diff/ - Angriffspfade / Aufrufketten grafisch darstellen →
diagram-generator/
Routing-Kontext
Eingang: skills/SKILL.md (Hauptsteuerung), routing.md
Ausgänge:
- IL2CPP / NativeAOT (nativ) →
reverse-engineering/ - Tiefgehende native .so/.dll-Segmentanalyse →
ida-reverse//radare2/ - KI-Direktzugriff auf dnSpy → dnSpy MCP registrieren und anbinden (siehe
references/sharp-tools.md)
Verwandte Module auf gleicher Ebene:
reverse-engineering/languages-compiled.md(.NET-Übersicht verweist auf dieses Modul)apk-reverse/(Xamarin/MAUI Android Reverse-Engineering kann für die C#-Schicht auf dieses Modul zurückgreifen)
Referenzdokumente
- references/obfuscators.md – Detaillierte Entschleierung von ConfuserEx / SmartAssembly / Babel / Eazfuscator / .NET Reactor inkl. Anti-Tamper-Umgehung
- references/common-workflow.md – Vollständiger Arbeitsablauf, Zuverlässigkeit von IL-Patches, Extraktion von Zeichenkettenentschlüsselungsroutinen, Erkennung von Zustandsautomaten
- references/sharp-tools.md – Analyse von Red-Team-Sharp*-Tools, Werkzeug-Installationsmatrix, dnSpy-MCP-Integration, Index der Community-Ressourcen
Aufgabenabschluss-Checkliste
- Wurde die CLR-/Managed-Identität bestätigt (oder wurde bereits in ein anderes Skill gewechselt)?
- Wurde eine verdächtige Obfuskation vor der Tiefenanalyse mit de4dot / einer gleichwertigen Methode entschleiert?
- Wurde die kritische Logik in der IL-Ansicht verifiziert (nicht nur C#-Pseudocode)?
- Wurden die Artefakte (Clean-Probe / Konfiguration / Patch-Diff) gespeichert und sind reproduzierbar?
- Wurde ein Menü mit nächsten Schritten oder ein Berichtsausgang angeboten?