dotnet-reverse

.NET / C# Reverse Engineering Workflow Specification

ACTION REQUIRED (Execute Immediately After Reading)

1. NOW: Use DIE/file/CLR header to confirm the target is a .NET managed binary (otherwise SWITCH to ida-reverse/ / reverse-engineering/)
2. NOW: If suspected of obfuscation → run de4dot first to unpack, produce *-clean.exe, and keep the original sample
3. NEXT: dnSpyEx (or dnSpy MCP / ilspycmd) static: C# browse + IL view for key logic
4. ACT: Dynamic debug when plaintext/C2 is needed; IL patch is preferred over C# recompilation when logic modification is required
5. At the end, provide the user with a 3-6 item next-steps menu (including export report)

Scope

Use this skill when the task falls under one of the following scenarios:

• Identify and reverse engineer .NET / C# compiled output (managed PE / .exe / .dll)
• Analyze red team Sharp* toolchains (Rubeus, SharpHound, SharpShell, etc.)
• Deobfuscate ConfuserEx / SmartAssembly / Babel / Eazfuscator / .NET Reactor and other protectors
• Reverse engineer .NET loaders / info-stealers / RAT decryption and C2 logic
• Patch C# programs (change conditions, constants, keygen)
• Analyze the managed Mono/Unity layer before IL2CPP (note: after IL2CPP compilation it is native, go to reverse-engineering/ + seed-014)

If the target is a pure native binary (C/C++/Go/Rust compiled, no CLR), use reverse-engineering/, ida-reverse/, or radare2/ instead.

Core Principles

• Identify first, then act: First confirm the binary is a .NET managed program (PE header CLR + #~ / #Strings streams + mscoree _CorExeMain), then decide to use dnSpy instead of IDA
• IL over C#: dnSpyEx's C# decompiler can lose/distort information (compiler-generated state machines, async/await, yield). Key logic and patches must be examined in the IL Editor; C# view is for quick browsing only
• de4dot first: When encountering an obfuscator, run de4dot first before static analysis, otherwise strings and control flow will be mangled
• MCP integration: If the environment has registered dnSpy MCP (dnspy_* tools), prefer those tools for decompile / IL inspection to avoid switching back to the GUI
• Evidence-based output: Save deobfuscated results, extracted config/C2/key, and patch diffs to disk

Toolchain Mapping

Capability	Primary Tool	Notes
Decompilation + Debugging + Patch	dnSpyEx	The go-to tool, the only one with an IL editor GUI; legacy dnSpy is no longer maintained, use the Ex fork
Lightweight CLI / headless decompilation	ILSpy (ilspycmd)	Suitable for batch processing, scripting, Linux/macOS
Deobfuscation	de4dot	Default unpacker for ConfuserEx family, SmartAssembly, and other mainstream protectors
Obfuscator Detection	Detect It Easy (DIE) / file	Identify the protector type first, then choose de4dot parameters
Programmatic IL manipulation	dnlib	Write C# scripts to batch modify metadata / string decryptors
AI Direct Operation	dnSpy MCP	Tools like dnspy_decompile / dnspy_inspect_il for automated analysis

Prerequisites: Windows host with dnSpyEx + de4dot installed (via choco or release); Linux/macOS use ilspycmd + dotnet runtime. See references/sharp-tools.md for the installation matrix.

Six-Phase Workflow

1. Identify (.NET)

Confirm the target is a managed program. Do not analyze a native PE as .NET:

# Windows
file target.exe                       # "PE32 executable ... for MS Windows" is insufficient
# Key: check for CLR
powershell -c "[System.Reflection.AssemblyName]::GetAssemblyName('target.exe')"
# Or
drop target.exe into dnSpyEx — if it opens, it's managed

# Universal
strings target.exe | grep -iE "mscoree|_CorExeMain|mscorlib|System\\."

.NET Identification Signs:

• PE header Data Directory[14] (CLR Runtime Header) is non-zero
• mscoree.dll import / _CorExeMain entry point
• #~, #Strings, #US, #GUID, #Blob metadata streams
• mscorlib / System.Private.CoreLib strings

NativeAOT Exception: Compiled to native, no CLR header, but contains System.Private.CoreLib strings and restructured type metadata — use reverse-engineering/ (IDA/r2) for these; this skill only provides identification hints.

2. Detect (Obfuscator Detection)

# DIE quick detection
diec target.exe                        # Detect It Easy CLI
# Or drop into dnSpyEx and look for large amounts of garbled class names / control flow obfuscation

Common obfuscators → unpacking strategy (see references/obfuscators.md):

Obfuscator	Characteristics	de4dot Handling
ConfuserEx (1.0.0 / 2.x)	<module> anti-tamper, control flow obfuscation, string encryption	de4dot target.exe usually auto-detects
SmartAssembly	circular/string encoding, resource compression	de4dot target.exe
Babel.NET	Method body encryption, control flow	de4dot target.exe
Eazfuscator.NET	String/resource encryption	de4dot, some versions may need manual handling
.NET Reactor	anti-tamper + necrobit	de4dot, newer versions may fail and require manual steps

3. Deobfuscate (Deobfuscation)

# de4dot automatically detects most protectors by default
de4dot target.exe -o target-clean.exe

# Specify type (when auto-detect fails)
de4dot --type cfze target.exe          # ConfuserEx
de4dot --type sa target.exe            # SmartAssembly

# Multi-layer obfuscation / de4dot reports unknown
de4dot --detect target.exe             # See what it identifies
# May need to patch anti-tamper first, then de4dot (see references/obfuscators.md)

Output: target-clean.exe. Use it for subsequent analysis. Keep the original sample for comparison.

4. Static Analyze (Static Analysis)

Load the deobfuscated sample in dnSpyEx:

• C# view: Quickly browse class structure, method signatures, strings (for locating)
• IL view: Key decisions, encryption logic, state machines must be viewed in IL (right-click → Edit IL or IL view)
• Find entry points: Main / Startup / Module initializer (Module .cctor)
• Find key logic: search for flag, password, verify, check, encrypt, http, Config

Locate string → cross-reference → find the method that uses it → IL view to see the decision logic

5. Dynamic (Dynamic Debugging)

dnSpyEx debugger: Attach to process / start debugging, set breakpoints in key methods, observe runtime:

• Decrypted plaintext strings (many obfuscators decrypt strings only at runtime)
• C2 addresses, configuration decryption results
• Exception-driven control flow (commonly used by anti-debug to hide the real path using try/catch)

.NET dynamic debugging is much friendlier than native — you can directly see object values and string contents. Prioritize dynamic over static analysis.

6. Patch (Modify as Needed)

dnSpyEx → right-click method → Edit Method (C#) or Edit IL
  - Change condition: ldc.i4.0 → ldc.i4.1 (false→true)
  - Change constant: directly edit string/number
  - Remove check: NOP the entire block
File → Save Module → Replace original file

IL patch reliability > C# patch: C# recompilation may fail (missing references, syntax issues); IL editing almost never introduces distortion. See references/common-workflow.md for details.

Trigger Scenario Routing

Enter this skill when the user says:

• ".NET / C# binary reverse engineering" / "C# program decompilation"
• "dnSpy analysis" / "dnSpyEx patch"
• "ConfuserEx / SmartAssembly / Babel deobfuscation / unpacking"
• "Sharp* tool analysis" (Rubeus / SharpHound / SharpShell)
• ".NET malware / loader / info-stealer reverse engineering"
• "C# program patch / keygen / condition modification"

When to Switch Out

• IL2CPP-compiled Unity games → reverse-engineering/ + seed-014_unity-il2cpp-reverse.md (IL2CPP is native, do not use dnSpy)
• NativeAOT output → reverse-engineering/ (same, native)
• Pure native PE (no CLR) → reverse-engineering/ / ida-reverse/
• Need symbol/function bulk migration to another version → binary-diff/
• Need to draw attack path / call chain diagram → diagram-generator/

Routing Context

Upstream entry: skills/SKILL.md (master), routing.md Downstream exits:

• IL2CPP / NativeAOT (native) → reverse-engineering/
• Deep native .so/.dll segment analysis → ida-reverse/ / radare2/
• Need AI to directly operate dnSpy → register and integrate with dnSpy MCP (see references/sharp-tools.md)

Sibling related modules:

• reverse-engineering/languages-compiled.md (.NET overview references this module)
• apk-reverse/ (Xamarin/MAUI Android reverse engineering can switch back to this module for C# layer)

Reference Documents

• references/obfuscators.md — Detailed deobfuscation guide for ConfuserEx / SmartAssembly / Babel / Eazfuscator / .NET Reactor, including anti-tamper bypass
• references/common-workflow.md — Complete workflow, IL patch reliability, string decryptor extraction, state machine identification
• references/sharp-tools.md — Red team Sharp* tool analysis, tool installation matrix, dnSpy MCP integration, community resource index

Task Completion Checklist

• Have you confirmed the CLR / managed identity (or already SWITCHED out of this skill)?
• Did you run de4dot / equivalent deobfuscation on the obfuscated sample before deep analysis?
• Have you verified key logic using the IL view (not just C# pseudo-code)?
• Are the outputs (clean sample / config / patch diff) saved to disk and reproducible?
• Did you provide a next-steps menu or report export?