SuperAPI AI Directory

dotnet-reverse

Security & auditing

View repository

Updated 10-16 11:46

About this skill

.NET / C# Reverse Engineering Work Specification

ACTION REQUIRED (execute immediately after reading)

  1. NOW: Use DIE/file/CLR header to confirm the target is .NET managed (otherwise SWITCH to ida-reverse/ / reverse-engineering/)
  2. NOW: If obfuscation is suspected → first de4dot unpack, produce *-clean.exe, keep the original sample
  3. NEXT: dnSpyEx (or dnSpy MCP / ilspycmd) static: C# browsing + IL viewto see key decisions
  4. ACT: Dynamic debugging when plaintext/C2 is needed; when logic needs to be changed, IL patch takes priority over C# recompilation
  5. At the end of the phase, give the user a 3–6 item next-step menu (including export report)

Scope of Application

Use this skill first when the task falls into the following scenarios:

  • Identify and reverse .NET / C# compiled artifacts (managed PE / .exe / .dll)
  • Analyze red team Sharp* toolchains (Rubeus, SharpHound, SharpShell, etc.)
  • Unpack obfuscation such as ConfuserEx / SmartAssembly / Babel / Eazfuscator / .NET Reactor
  • Reverse the decryption and C2 logic of .NET loaders / info-stealers / RATs
  • Patch C# programs (change decisions, change constants, keygen)
  • Analyze the Mono/Unity managed layer before IL2CPP (note: after IL2CPP compilation it is native, use reverse-engineering/ + seed-014)

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

Core Principles

  • Identify first, then proceed: First confirm it is a .NET managed program (PE header CLR + #~ / #Strings stream + mscoree _CorExeMain), then decide to go with dnSpy rather than IDA
  • IL takes priority over C#: dnSpyEx's C# decompiler will lose/distort information (compiler-generated state machines, async/await, yield); key decisions and patches must switch to IL editor, the C# view is only for quick browsing
  • de4dot first: When encountering an obfuscator, first de4dot unpack a round before doing static analysis, otherwise strings/control flow are all messed up
  • MCP integration: If the dnSpy MCP is registered in the environment (dnspy_* tool), prioritize using the MCP side for decompile / IL inspection to avoid switching back and forth between GUIs
  • Evidence-based output: Unpacked artifacts, extracted config/C2/key, and patch diffs must all be written to disk

Toolchain Mapping

Capability Preferred Remarks
Decompilation + debugging + patching dnSpyEx The ace, the only GUI with an IL editor; the old dnSpy is no longer updated, use the Ex branch
Lightweight CLI / headless decompilation ILSpy (ilspycmd) Suitable for batch, scripting, Linux/macOS
Deobfuscation de4dot The default solution for mainstream packers such as the ConfuserEx family and SmartAssembly
Obfuscator identification Detect It Easy (DIE) / file Determine the packer type first, then decide the de4dot parameters
Programmatic IL manipulation dnlib Write C# scripts to batch-modify metadata / string decryptors
Direct AI operation dnSpy MCP dnspy_decompile / dnspy_inspect_il and other tool surfaces

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

Six-Phase Workflow

1. Identify (identify .NET)

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

# Windows
file target.exe                       # "PE32 executable ... for MS Windows" 不够
# 关键:看有没有 CLR
powershell -c "[System.Reflection.AssemblyName]::GetAssemblyName('target.exe')"
# 或
dnSpyEx 直接拖进去 —— 能打开就是托管

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

.NET identification markers:

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

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

2. Detect (detect obfuscator)

# DIE 快速识别
diec target.exe                        # Detect It Easy CLI
# 或拖进 dnSpyEx,看是否大量乱码类名 / 控制流变形

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

Obfuscator Features de4dot handling
ConfuserEx (1.0.0 / 2.x) <module> anti-tamper, control flow obfuscation, string encryption de4dot target.exe usually auto-detected
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 require manual work
.NET Reactor anti-tamper + necrobit de4dot, newer versions may fail and require manual work

3. Deobfuscate

# de4dot 默认自动识别大多数壳
de4dot target.exe -o target-clean.exe

# 指定类型(自动识别失败时)
de4dot --type cfze target.exe          # ConfuserEx
de4dot --type sa target.exe            # SmartAssembly

# 多层混淆 / de4dot 报 unknown
de4dot --detect target.exe             # 看它识别成什么
# 可能要先 patch anti-tamper 再 de4dot(见 references/obfuscators.md)

Output:target-clean.exe, use it for subsequent analysis.Keep the original samplefor comparison.

4. Static Analyze

Load the unpacked sample in dnSpyEx:

  • C# view: quickly browse class structure, method signatures, strings (for locating)
  • IL view: key conditionals, encryption logic, and state machines must be examined in IL (right-click → Edit IL or IL view)
  • Find the entry:Main / Startup / module initializer (Module .cctor)
  • Find key logic: search flag、password、verify、check、encrypt、http、Config
定位字符串 → 反向引用 → 找到使用它的方法 → IL 视图看判断逻辑

5. Dynamic (dynamic debugging)

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

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

.NET dynamic debugging is far friendlier than native — you can directly see object values and string contents. Prefer dynamic over struggling with static.

6. Patch (modify as needed)

dnSpyEx → 右键方法 → Edit Method (C#) 或 Edit IL
  - 改判断:ldc.i4.0 → ldc.i4.1(false→true)
  - 改常量:直接编辑字符串/数字
  - 删除校验:nop 掉整段
File → Save Module → 替换原文件

IL patch reliability > C# patch: C# recompilation may fail (missing references, syntax errors), IL editing almost never distorts. See references/common-workflow.md。

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 / modify conditionals"

When to switch out

  • IL2CPP-compiled Unity games → reverse-engineering/ + seed-014_unity-il2cpp-reverse.md(IL2CPP is native, doesn't go through dnSpy)
  • NativeAOT output → reverse-engineering/(same as above, native)
  • Pure native PE (no CLR) → reverse-engineering/ / ida-reverse/
  • Need to batch-migrate symbols/functions to another version → binary-diff/
  • Need to draw attack paths / call chain diagrams → diagram-generator/

Routing context

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

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

Sibling related 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 inspect the 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 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 self-check

  • Has CLR / managed identity been confirmed (or has this skill already been SWITCHed out)?
  • For obfuscated samples, is de4dot / equivalent unpacking performed before deep analysis?
  • Is key logic verified using the IL view (rather than only looking at C# pseudocode)?
  • Are artifacts (clean sample / config / patch diff) written to disk and reproducible?
  • Has a next-step menu or report exit been provided?