ACTION REQUIRED (execute immediately after reading)
NOW: Use DIE/file/CLR header to confirm the target is .NET managed (otherwise SWITCH toida-reverse//reverse-engineering/)NOW: If obfuscation is suspected → firstde4dotunpack, produce*-clean.exe, keep the original sampleNEXT: dnSpyEx (or dnSpy MCP /ilspycmd) static: C# browsing + IL viewto see key decisionsACT: Dynamic debugging when plaintext/C2 is needed; when logic needs to be changed, IL patch takes priority over C# recompilation- 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 +
#~/#Stringsstream + 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
de4dotunpack 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. Seereferences/sharp-tools.mdfor 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.dllimport /_CorExeMainentry#~、#Strings、#US、#GUID、#Blobmetadata streammscorlib/System.Private.CoreLibstring
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/catchto 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?