.NET / C# Reverse Engineering Operation Specification

ACTION REQUIRED (Execute immediately after reading)

```
NOW
```
: Confirm the target is .NET managed using DIE/
```
file
```
/CLR header (SWITCH to
```
ida-reverse/
```
/
```
reverse-engineering/
```
if not)
```
NOW
```
: If obfuscation is suspected → First use
```
de4dot
```
to unpack, output
```
*-clean.exe
```
, and keep the original sample
```
NEXT
```
: Static analysis with dnSpyEx (or dnSpy MCP /
```
ilspycmd
```
): Browse C# + check key judgments via IL View
```
ACT
```
: Dynamic debugging when plaintext/C2 is needed; prioritize IL patch over C# recompilation when logic modification is required
At the end of the phase, provide users with 3–6 next-step options (including report export)

Scope of Application

Prioritize using this skill for the following scenarios:

Identify and reverse-engineer .NET / C# compiled products (managed PE / .exe / .dll)
Analyze red team Sharp* toolchains (Rubeus, SharpHound, SharpShell, etc.)
Unpack shells from ConfuserEx / SmartAssembly / Babel / Eazfuscator / .NET Reactor, etc.
Reverse-engineer decryption and C2 logic of .NET loader / info-stealer / RAT
Patch C# programs (modify judgments, constants, keygen)
Analyze Mono/Unity managed layer before IL2CPP (Note: IL2CPP-compiled products are native, use
```
reverse-engineering/
```
+ seed-014)

If the target is a pure native binary (compiled with C/C++/Go/Rust, no CLR), please use

reverse-engineering/

ida-reverse/

radare2/

instead.

Core Principles

Identify first, act later: Confirm it's a .NET managed program (CLR in PE header +
```
#~
```
/
```
#Strings
```
streams + mscoree
```
_CorExeMain
```
) before deciding to use dnSpy instead of IDA
IL takes precedence over C#: dnSpyEx's C# decompiler may lose/distort information (compiler-generated state machines, async/await, yield), key judgments and patches must switch to IL Editor, C# view is only for quick browsing
de4dot first: Use
```
de4dot
```
to unpack before static analysis when encountering obfuscators, otherwise strings/control flow will be garbled
MCP linkage: If dnSpy MCP (
```
dnspy_*
```
tools) is registered in the environment, prioritize decompile / IL inspection via MCP interface to avoid switching GUI back and forth
Evidence-based output: Unpacked products, extracted configurations/C2/keys, and patch diffs must be saved to disk

Toolchain Mapping

Capability	Preferred Tool	Remarks
Decompilation + Debugging + Patching	dnSpyEx	Ace tool, the only GUI with IL Editor; old dnSpy is no longer maintained, use the Ex branch
Lightweight CLI / headless decompilation	ILSpy ( `ilspycmd` )	Suitable for batch processing, scripting, Linux/macOS
Deobfuscation	de4dot	Default solution for mainstream shells like ConfuserEx family, SmartAssembly, etc.
Obfuscator detection	Detect It Easy (DIE) / file	Determine the shell type first before deciding de4dot parameters
Programmatic IL operation	dnlib	Write C# scripts to batch modify metadata / string decrypters
Direct AI operation	dnSpy MCP	Tools like `dnspy_decompile` / `dnspy_inspect_il`

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

Six-Phase Workflow

1. Identify (.NET Recognition)

Confirm the target is a managed program, don't treat native PE as .NET:

powershell

# Windows
file target.exe                       # "PE32 executable ... for MS Windows" is not sufficient
# Key: Check if CLR exists
powershell -c "[System.Reflection.AssemblyName]::GetAssemblyName('target.exe')"
# Or
drag directly into dnSpyEx —— if it can be opened, it's managed

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

.NET Identification Marks:

Non-zero
```
Data Directory[14]
```
(CLR Runtime Header) in PE header
Import of
```
mscoree.dll
```
/
```
_CorExeMain
```
entry point
```
#~
```
,
```
#Strings
```
,
```
#US
```
,
```
#GUID
```
,
```
#Blob
```
metadata streams
```
mscorlib
```
/
```
System.Private.CoreLib
```
strings

NativeAOT Exception: Compiled to native, no CLR header, but has

System.Private.CoreLib

strings and reconstructed type metadata —— use

reverse-engineering/

(IDA/r2) for this type, this skill only provides identification prompts.

2. Detect (Obfuscator Detection)

powershell

# Quick identification with DIE
diec target.exe                        # Detect It Easy CLI
# Or drag into dnSpyEx to check if there are a large number of garbled class names / control flow deformations

Common obfuscators → Unpacking strategies (see

references/obfuscators.md

for details):

Obfuscator	Features	de4dot Processing
ConfuserEx (1.0.0 / 2.x)	`<module>` anti-tamper, control flow deformation, string encryption	`de4dot target.exe` usually identifies automatically
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` , manual operation required for some versions
.NET Reactor	anti-tamper + necrobit	`de4dot` , manual operation may be needed if new versions fail

3. Deobfuscate (Unpacking)

powershell

# de4dot automatically identifies most shells by default
de4dot target.exe -o target-clean.exe

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

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

Output:

target-clean.exe

, use this for subsequent analysis. Keep the original sample for comparison.

4. Static Analyze (Static Analysis)

Load the unpacked sample into dnSpyEx:

C# View: Quickly browse class structure, method signatures, strings (for positioning)
IL View: Key judgments, 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

text

Locate strings → Reverse reference → Find methods using them → Check judgment logic in IL View

5. Dynamic (Dynamic Debugging)

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

Decrypted plaintext strings (many obfuscators decrypt strings only at runtime)
C2 addresses, configuration decryption results
Exception-driven control flow (anti-debug commonly uses
```
try/catch
```
to hide real paths)

.NET dynamic debugging is much more user-friendly than native —— you can directly see object values and string content. Prioritize dynamic debugging over struggling with static analysis.

6. Patch (On-Demand Modification)

text

dnSpyEx → Right-click method → Edit Method (C#) or Edit IL
  - Modify judgment: ldc.i4.0 → ldc.i4.1 (false→true)
  - Modify constants: Directly edit strings/numbers
  - Remove verification: Nop out the entire segment
File → Save Module → Replace original file

IL patch reliability > C# patch: C# recompilation may fail (missing references, syntax errors), while IL editing almost never distorts the original code. See

references/common-workflow.md

for details.

Trigger Scenario Routing

Enter this skill when users mention:

".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 / judgment modification"

When to Switch Out

Unity games compiled with IL2CPP →
```
reverse-engineering/
```
+
```
seed-014_unity-il2cpp-reverse.md
```
(IL2CPP is native, do not use dnSpy)
NativeAOT products →
```
reverse-engineering/
```
(same as above, native)
Pure native PE (no CLR) →
```
reverse-engineering/
```
/
```
ida-reverse/
```
Need to batch migrate symbols/functions to other versions →
```
binary-diff/
```
Need to draw attack path / call chain diagrams →
```
diagram-generator/
```

Routing Context

Upstream Entries:

skills/SKILL.md

(master control),

routing.md

Downstream Exports:

IL2CPP / NativeAOT (native) →
```
reverse-engineering/
```
In-depth native .so/.dll segment analysis →
```
ida-reverse/
```
/
```
radare2/
```
Need AI to operate dnSpy directly → Register and link with dnSpy MCP (see
```
references/sharp-tools.md
```
)

Peer Associated Modules:

reverse-engineering/languages-compiled.md

(.NET introduction points to this module)

```
apk-reverse/
```
(Xamarin/MAUI Android reverse engineering can switch back to this module to view C# layer)

Reference Documents

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

Task Completion Self-Check

Have you confirmed the CLR / managed identity (or switched out of this skill)?
Did you first use de4dot / equivalent unpacking for obfuscated samples before in-depth analysis?
Did you verify key logic using IL View (instead of only relying on C# pseudocode)?
Have products (clean samples / configurations / patch diffs) been saved to disk and are reproducible?
Did you provide next-step options or report export channels?

dotnet-reverse

NPX Install

Tags

SKILL.md Content (Chinese)

.NET / C# Reverse Engineering Operation Specification

ACTION REQUIRED (Execute immediately after reading)

Scope of Application

Core Principles

Toolchain Mapping

Six-Phase Workflow

1. Identify (.NET Recognition)

2. Detect (Obfuscator Detection)

3. Deobfuscate (Unpacking)

4. Static Analyze (Static Analysis)

5. Dynamic (Dynamic Debugging)

6. Patch (On-Demand Modification)

Trigger Scenario Routing

When to Switch Out

Routing Context

Reference Documents

Task Completion Self-Check