SuperAPI AI Directory

dotnet-reverse

Security & auditing

View repository

Updated 10-20 02:33

About this skill

.NET / C# Reverse Engineering Work Specification

When to Use

  • Analyzing a .NET assembly, obfuscated C# product, or native-AOT binary.
  • Understanding the internals of Sharp* red-team tools before use or defense.

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 ConfuserEx / SmartAssembly / Babel / Eazfuscator / .NET Reactor and similar packers
  • Reverse the decryption and C2 logic of .NET loaders / info-stealers / RATs
  • Patch C# programs (change conditionals, 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 (compiled from C/C++/Go/Rust, no CLR), use reverse-engineering/、ida-reverse/ or radare2/。

Core Principles

  • Identify before acting: first confirm it is a .NET managed program (PE header CLR + #~ / #Strings stream + mscoree _CorExeMain), then decide to use dnSpy rather than IDA
  • IL takes precedence over C#: dnSpyEx's C# decompiler loses/distorts information (compiler-generated state machines, async/await, yield); key decisions and patches must switch to the IL editor, the C# view is only for quick browsing
  • de4dot first: when encountering an obfuscator, first run de4dot to unpack once before static analysis; otherwise strings/control flow are all scrambled
  • MCP integration: if a dnSpy MCP is registered in the environment (dnspy_* tools), prefer the MCP surface for decompile / IL inspection to avoid switching back and forth in the GUI
  • Evidence-based output: unpacked artifacts, extracted config/C2/key, and patch diffs must all be saved to disk

Toolchain Mapping

Capability Preferred Notes
Decompile + debug + patch dnSpyEx The ace, the only GUI with an IL editor; old dnSpy is no longer maintained, use the Ex branch
Lightweight CLI / headless decompilation ILSpy (ilspycmd) Suitable for batch, scripting, Linux/macOS
Unpacking 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

Prerequisite: 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-Stage Workflow

1. Identify (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" 不够
# 关键:看有没有 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: is compiled to native, has no CLR header, but has System.Private.CoreLib strings and reconstructed type metadata — this type goes to reverse-engineering/(IDA/r2); this skill only provides identification hints.

2. Detect (detect the obfuscator)

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

Common obfuscators → Unpacking strategies (see details in references/obfuscators.md):

Obfuscator Features de4dot handling
ConfuserEx (1.0.0 / 2.x) <module> anti-tamper, control flow deformation, 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
.NET Reactor anti-tamper + necrobit de4dot, newer versions may fail and require manual

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 conditions, encryption logic, and state machines must be examined in IL (right-click → Edit IL or IL view)
  • Find the entry point:Main / Startup / module initializer (Module .cctor)
  • Find key logic: search flag、password、verify、check、encrypt、http、Config
定位字符串 → 反向引用 → 找到使用它的方法 → IL 视图看判断逻辑

5. Dynamic

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

  • Decrypted plaintext strings (strings from many obfuscators are only decrypted 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. Prioritize dynamic over stubbornly grinding through 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, incorrect syntax), while IL editing is almost never distorted. See details in 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 conditions"

When to switch out

  • IL2CPP-compiled Unity games → reverse-engineering/ + seed-014_unity-il2cpp-reverse.md(IL2CPP is native, does not 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 graphs → diagram-generator/

Routing context

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

  • IL2CPP / NativeAOT(native)→ reverse-engineering/
  • Deep native .so/.dll segment analysis → ida-reverse/ / radare2/
  • Need AI to directly operate dnSpy → register and integrate 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 view the C# layer)

Reference documents

  • references/obfuscators.md — Detailed explanation of ConfuserEx / SmartAssembly / Babel / Eazfuscator / .NET Reactor deobfuscation + 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

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

Limitations

  • NativeAOT and trimmed builds lose most metadata; expect native-style RE.
  • Some commercial obfuscators require manual unpacking steps.

Adapted from zhaoxuya520/reverse-skill (MIT).