/dotnet-reversing

name: dotnet-reversing
description: |
  Activate this skill when the user mentions ".NET", "CLR", "managed code",
  "C# binary", "C# decompile", "decompile C#", "VB.NET", "F# binary",
  "ILSpy", "dnSpy", "de4dot", "dotPeek", ".NET Reflector", "monodis", "ilspycmd",
  "ilasm", "ildasm", "Cecil", "Mono.Cecil", "dnlib",
  ".NET Reactor", "ConfuserEx", "Dotfuscator", "SmartAssembly", "Eazfuscator",
  "Babel obfuscator", "Crypto Obfuscator", "Agile.NET", "Themida .NET",
  "deobfuscate", "deobfuscation", ".NET obfuscation", "unpack .NET",
  "mscoree", "mscorlib", "System.Reflection", "System.Runtime",
  "assembly metadata", "IL code", "MSIL", "CIL", "OpCodes",
  "Common Language Runtime", "CLR hosting", "JIT compilation",
  "NuGet", "Mono", ".NET assembly", ".NET executable", "managed executable",
  ".NET malware", "C# malware", "C# RAT", "C# loader", "C# dropper",
  "C# stager", "C# implant", "C# beacon", "C# payload",
  "BinaryFormatter", "ObjectStateFormatter", "ViewState deserialization",
  "JSON.NET TypeNameHandling", "DataContractSerializer",
  ".NET serialization", "ysoserial.net", "TypeConfuseDelegate",
  "P/Invoke", "DllImport", "Marshal", "unsafe code", "fixed pointer",
  ".NET patching", "IL patching", "Harmony", "runtime hooking",
  "Assembly.Load", "AppDomain", "Reflection.Emit",
  ".NET config extraction", "C2 extraction", "beacon config",
  "Costura.Fody", "ILMerge", "embedded assembly",
  ".NET RE", ".NET reverse engineering", "managed binary analysis",
  or discusses analyzing, decompiling, deobfuscating, patching, or exploiting .NET assemblies.
version: 2.0.0

.NET Reverse Engineering

Why .NET Is Different

.NET binaries ship IL (Intermediate Language) code with full metadata — type names, method signatures, string literals, inheritance hierarchies. This makes decompilation far more effective than with native code. A clean .NET binary decompiles to near-source-quality C#. Obfuscation raises the bar but never eliminates the metadata entirely because the CLR needs it to execute.

This matters for offensive work: .NET malware leaks intent through its metadata. Even heavily obfuscated samples expose type references to `System.Net.Sockets`, `System.Security.Cryptography`, or `System.Runtime.InteropServices` — revealing capability before you touch the IL.

Detection — Is This .NET?

Confirm a binary is .NET before choosing your toolchain. Wrong tools waste time.

# Quick check — file magic
file <binary>
# Look for: "Mono/.Net assembly" or "PE32 executable ... Mono/.Net"

# Confirm via PE imports — .NET binaries import mscoree.dll
r2 -qc 'ii~mscoree' <binary>
# _CorExeMain = .NET EXE, _CorDllMain = .NET DLL

# CLI header presence — Data Directory entry 14
r2 -qc 'iH~CLR' <binary>

# monodis sanity check
monodis --assembly <binary>

If the binary is mixed-mode (C++/CLI), it has both native and managed code. Use `monodis` for the managed portion and radare2/Ghidra for native.

Core Workflow

Follow this sequence for any .NET target. Skip steps that do not apply, but never skip triage.

Phase 1 — Triage and Metadata Extraction

Goal: understand what you have before deep analysis.

# Assembly identity
monodis --assembly <binary>

# Type inventory — namespaces reveal purpose
monodis --typedef <binary>

# External dependencies — what frameworks/libraries does it use?
monodis --assemblyref <binary>
monodis --typeref <binary>

# Entry point identification
monodis --method <binary> | grep -A5 "\.entrypoint"

# Embedded resources — configs, encrypted payloads, embedded DLLs
monodis --manifest <binary>

# String extraction — URLs, IPs, registry keys, crypto constants
strings -el <binary>   # Unicode strings (common in .NET)
strings -a <binary>    # ASCII strings
floss <binary>         # FLARE obfuscated string solver

Key questions to answer during triage:

• What namespaces exist? (`System.Net` = networking, `System.Security.Cryptography` = crypto)
• Are names readable or garbled? (obfuscation indicator)
• What external assemblies does it reference?
• Are there embedded resources? (common payload delivery vector)
• Does it reference `DllImport`/`P/Invoke`? (native API access)

Phase 2 — Obfuscation Assessment

Determine if and how the binary is obfuscated. This dictates your next steps.

# de4dot auto-detection (does not modify — just reports)
de4dot --detect <binary>

# Manual checks
monodis --typedef <binary>    # Garbled names = obfuscation
monodis --customattr <binary> # Obfuscator watermark attributes

**Obfuscator Fingerprints:**

| Obfuscator | Indicators | |------------|------------| | **ConfuserEx** | Unicode-garbled names, `ConfuserEx` in attributes, proxy delegates, `<Module>.cctor()` initialization | | **Dotfuscator** | `DotfuscatorAttribute`, PreEmptive watermarks, renamed but structurally intact | | **.NET Reactor** | `.reacto` section, `__EncryptedAssembly__` resource, native stub loader | | **SmartAssembly** | `SmartAssembly.Attributes`, `{SmartAssembly}` strings, embedded error reporting | | **Eazfuscator** | `EazAttribute`, virtualized method bodies, custom opcode interpreter | | **Babel** | `BabelAttribute`, `BabelObfuscator` strings, resource encryption | | **Crypto Obfuscator** | `CryptoObfuscator` strings, heavy resource encryption | | **Agile.NET** | `CliSecure` references, native mode option | | **Themida/.NET** | Themida-style VM wrapping managed code, very heavy | | **Costura.Fody** | Not obfuscation — embeds DLL dependencies as resources. `costura.` prefixed resources |

If obfuscated → Phase 2a (deobfuscate first). If clean → skip to Phase 3.

Phase 2a — Deobfuscation

# Automatic deobfuscation
de4dot <binary> -o <clean.exe>

# ConfuserEx specifically (use the cex fork)
de4dot-cex <binary> -o <clean.exe>

# Force a specific deobfuscator engine
de4dot <binary> -p <code> -o <clean.exe>
# Codes: an=Agile.NET, ba=Babel, co=CryptoObfuscator, cx=ConfuserEx,
#         df=Dotfuscator, dr=.NETReactor