# Reverse-Skill .NET Binary Analysis: A Complete Toolkit for Reverse Engineering Managed Assemblies

> Explore reverse-skill, a powerful toolkit for .NET binary analysis. Master identification, deobfuscation, static & dynamic analysis, and IL patching for .NET assemblies.

- Repository: [ZhaoXu/reverse-skill](https://github.com/zhaoxuya520/reverse-skill)
- Tags: how-to-guide
- Published: 2026-08-11

---

**Reverse-skill offers a six-stage workflow for .NET binary analysis—identification, obfuscation detection, deobfuscation, static analysis, dynamic debugging, and IL-level patching—specifically designed for .NET and .NET Core assemblies as first-class reverse-engineering targets.**

The `zhaoxuya520/reverse-skill` repository treats managed .NET binaries differently from native code, routing all ".NET binary analysis" requests through its dedicated **dotnet-reverse** skill module. This article breaks down the complete capabilities, tooling choices, and practical commands for analyzing .NET assemblies from initial identification through final patching.

## How the Dotnet-Reverse Skill Routes Requests

When you initiate a .NET analysis task, the routing matrix in [`skills/config/routing.json`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/config/routing.json) directs your request to [`skills/dotnet-reverse/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/dotnet-reverse/SKILL.md). This skill file implements a strict gate: **only .NET managed binaries qualify**. If the identification phase detects a pure native PE (no CLR header), control switches to `ida-reverse` instead.

The routing decision happens through the **RULES.md** validation layer, which ensures proper case initialization (authentication + network profile) before execution.

## Six-Stage .NET Analysis Workflow

### Identify: Confirming a Managed .NET Binary

The identification phase prevents wasted effort on native binaries. It checks for PE format plus CLR header signatures, `mscoree.dll` imports, and valid metadata streams.

Run these exact PowerShell commands from the skill definition:

```powershell

# Generic PE information

file target.exe

# PowerShell managed assembly check

powershell -c "[System.Reflection.AssemblyName]::GetAssemblyName('target.exe')"

# Fallback string search for CLR indicators

strings target.exe | Select-String -Pattern "mscoree|_CorExeMain|System."

```

Success here triggers full dotnet-reverse engagement. Failure routes to native analysis tools.

### Detect: Spotting Obfuscators Before Deobfuscation

.NET binaries frequently carry commercial obfuscators. The skill mandates **Detect It Easy (DIE)** scanning before any decompilation attempt:

```powershell

# Quick obfuscator fingerprinting

diec target.exe

```

This scan drives the deobfuscation strategy. Common detections include ConfuserEx, SmartAssembly, Babel, Dotfuscator, and Eazfuscator.NET—each mapped to specific `de4dot` flags in [`skills/dotnet-reverse/references/obfuscators.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/dotnet-reverse/references/obfuscators.md).

### Deobfuscate: Stripping Protection with de4dot

Clean IL is prerequisite for reliable analysis. The skill calls **de4dot** with auto-detection or explicit type specification:

```powershell

# Auto-detect obfuscator type

de4dot target.exe -o target-clean.exe

# Manual type specification when auto-detect fails

de4dot --type cfze target.exe    # ConfuserEx

de4dot --type sa target.exe      # SmartAssembly

```

Explicit types are documented in [`skills/dotnet-reverse/references/obfuscators.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/dotnet-reverse/references/obfuscators.md) for cases where heuristic detection fails.

### Static Analyse: Exploring IL and C# Structures

The skill emphasizes **IL-first analysis**—C# decompilation is for browsing only, while IL remains the source of truth. This is critical for async state machines, yield return constructs, and compiler-generated code that decompilers misrepresent.

Two primary tools handle this phase:

| Tool | Mode | Use Case |
|------|------|----------|
| **dnSpyEx** | GUI with IL editor | Interactive exploration, visual IL editing |
| **ilspycmd** | Headless CLI | Scripted extraction, Linux/macOS workflows |

Recommended workflow commands:

```powershell

# GUI analysis with full IL visualization

dnSpyEx target-clean.exe

# Headless decompilation for offline review

ilspycmd -p target-clean.exe > Decompiled.cs

```

When searching code, prioritize keywords like `flag`, `password`, `encrypt`, `decrypt`, and `loader`—these surface protection logic and cryptographic implementations quickly.

### Dynamic Debug: Runtime Observation

Static analysis hits limits with runtime decryption, dynamic C2 endpoint resolution, and anti-debug tricks. The skill recommends **dnSpyEx debugger attachment**:

```powershell

# Launch with debugging enabled

dnSpyEx -debug target-clean.exe

```

Set breakpoints on methods identified during static analysis. Live value inspection reveals decrypted strings, computed hashes, and network endpoint URLs that remain obfuscated on disk.

### Patch: IL-Level Modification Without Recompilation

The final stage modifies logic, constants, or removes checks directly. Two approaches are supported:

**Interactive Patching via dnSpyEx GUI:**
- Right-click target method → **Edit Method** → **Edit IL**
- Modify instructions, save module, write patched binary to disk

**Scripted Patching via dnlib:**

```powershell

# Initialize .NET project for dnlib scripting

dotnet new console -o ILPatch
cd ILPatch
dotnet add package dnlib

# Write C# script that:

# 1. Loads target-clean.exe via ModuleDefMD.Load()

# 2. Locates target method by metadata token or name

# 3. Modifies IL instructions

# 4. Writes modified module back to disk

```

The skill also supports **AI-driven patching** when a dnSpy MCP server is registered. Commands like `dnspy_decompile` and `dnspy_patch` bypass GUI hand-offs entirely.

## MCP Integration: AI-Driven .NET Analysis

The dotnet-reverse skill exposes **Model Context Protocol (MCP)** endpoints for automation. When `dnspy-mcp` is registered in the environment, the AI assistant can:

- Issue `dnspy_decompile` commands for headless IL extraction
- Request `dnspy_patch` for programmatic modifications
- Retrieve runtime values via debug adapter protocol

This integration eliminates manual GUI navigation for repetitive analysis tasks.

## Artifact Handling and Evidence Preservation

Each workflow stage produces reproducible artifacts:

| Phase | Output Artifact | Purpose |
|-------|-----------------|---------|
| Identify | `identify.log` | PE/CLR validation record |
| Detect | [`diec-output.txt`](https://github.com/zhaoxuya520/reverse-skill/blob/main/diec-output.txt) | Obfuscator fingerprint evidence |
| Deobfuscate | `target-clean.exe` | Clean binary for downstream tools |
| Static | [`Decompiled.cs`](https://github.com/zhaoxuya520/reverse-skill/blob/main/Decompiled.cs), IL dumps | Source-level documentation |
| Dynamic | Breakpoint hits, memory dumps | Runtime behavior evidence |
| Patch | `.diff` files, patched binaries | Modification audit trail |

All outputs follow the evidence standards defined in [`skills/dotnet-reverse/references/common-workflow.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/dotnet-reverse/references/common-workflow.md).

## Installation Requirements

Required tools are cataloged in [`skills/dotnet-reverse/references/sharp-tools.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/dotnet-reverse/references/sharp-tools.md):

- **dnSpyEx** (active fork of dnSpy with .NET 6/7/8 support)
- **de4dot** (community builds for modern obfuscators)
- **Detect It Easy** (DIE) for obfuscator identification
- **ilspycmd** for headless decompilation
- **dnlib** for programmatic IL manipulation

Platform-specific installation paths cover Windows (PowerShell/choco), Linux (dotnet global tools), and macOS (Homebrew).

## Summary

- Reverse-skill routes .NET analysis through [`skills/dotnet-reverse/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/dotnet-reverse/SKILL.md), a dedicated module with six sequential phases
- **Identify** confirms managed binaries via CLR header checks before tool selection
- **Detect** uses DIE scans to fingerprint obfuscators and select deobfuscation strategies
- **Deobfuscate** strips protections with `de4dot`, supporting explicit type overrides
- **Static Analyse** prioritizes IL over C# decompilation, using dnSpyEx GUI or `ilspycmd` CLI

- **Dynamic Debug** attaches dnSpyEx debugger to observe runtime behavior and decryption
- **Patch** modifies logic at IL level through dnSpyEx editor or `dnlib` scripts, with optional MCP automation
- MCP integration enables AI-driven command issuance for headless workflows
- All phases produce auditable artifacts for reproducible analysis

## Frequently Asked Questions

### What makes reverse-skill's .NET analysis different from generic reverse engineering tools?

Reverse-skill treats .NET as a **first-class target** with specialized routing, rather than forcing managed assemblies through native analysis pipelines. The dotnet-reverse skill understands CLR metadata, IL structure, and common .NET obfuscators—capabilities that IDA Pro or Ghidra handle poorly without extensive scripting. The IL-first strategy specifically addresses async state machines and compiler-generated code that decompilers routinely misrepresent.

### Can reverse-skill handle .NET Core and .NET 5+ single-file executables?

Yes. The identification phase detects modern .NET host policies and single-file bundles through `mscoree.dll` fallback checks and hostfxr signature patterns. For bundled applications, the skill extracts the embedded assembly before deobfuscation. Tool versions in [`sharp-tools.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/sharp-tools.md) specify dnSpyEx builds with .NET 6/7/8 support required for current runtimes.

### When should I use scripted dnlib patches versus interactive dnSpyEx editing?

**Interactive editing** suits one-off modifications, exploratory patches, and visual verification of IL changes. **Scripted dnlib patches** are required for batch processing, CI/CD integration, or when patching must be reproducible across multiple samples. The skill's [`common-workflow.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/common-workflow.md) reference provides template scripts for common patterns like nop-ing checks or replacing string comparisons.

### Does reverse-skill support automated deobfuscation for commercial protectors not covered by de4dot?

The skill framework supports **extensible detection** through DIE signature updates and manual `--type` specification. For protectors beyond de4dot's coverage (like certain VM-based obfuscators), the workflow pivots to **dynamic analysis**—using dnSpyEx debugger to extract decrypted IL from memory. The [`obfuscators.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/obfuscators.md) reference documents fallback strategies for known commercial protectors.