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

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 directs your request to 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:

# 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:

# 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.

Deobfuscate: Stripping Protection with de4dot

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

# 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 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:

# 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:

# 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:

# 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	Obfuscator fingerprint evidence
Deobfuscate	target-clean.exe	Clean binary for downstream tools
Static	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.

Installation Requirements

Required tools are cataloged in 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, 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 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 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 reference documents fallback strategies for known commercial protectors.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}