Reverse engineer .NET assemblies and deobfuscate C# binaries

.NET Assembly Analysis provides a structured workflow for understanding compiled C# and managed PE files. It covers identification, obfuscator detection, deobfuscation, static analysis, controlled debugging, and validation of modified copies. Evidence includes analysis artifacts, extracted configuration, and patch differences saved for reproducibility.

Identification comes first. The workflow checks CLR indicators, metadata streams, and managed runtime references before selecting a .NET toolchain. NativeAOT is an exception: it can retain runtime-related strings while lacking a CLR header. IL2CPP builds and pure native C, C++, Go, or Rust binaries are routed to native reverse-engineering workflows.

For critical decisions, the skill prioritizes IL over decompiled C#. Decompiled views can distort compiler-generated state machines, asynchronous code, and iterators. C# remains useful for navigating types and methods, while IL inspection verifies important branches and transformations.

Use it for educational work or explicitly authorized assessments of .NET assemblies, obfuscated C# products, and managed layers of Mono or Unity software. Only authorized samples are in scope. Target-affecting operations require confirmation of the exact resource, written authorization, permitted scope, proposed commands, and expected effects. Without that confirmation, the workflow remains read-only and defensive.

Unknown assemblies, dependencies, and deobfuscators may execute code. The isolation guidance calls for a rollback-capable virtual machine without real credentials or shared directories, with outbound connectivity blocked by default. Static metadata inspection comes first; dynamic execution needs its own scope confirmation. Extracted keys and network configuration are sensitive evidence, not material to reconnect to or reuse.

The starting input is an authorized binary and its assessment scope. A managed-assembly identification example is:

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

Analysis proceeds through obfuscator detection, supported deobfuscation, entry-point and reference inspection, and controlled runtime observation where authorized. Original samples remain intact for comparison. Any modification is saved separately and checked for stack, branch, exception-handling, and signature effects rather than assumed correct because an editor saved it.

The tool map includes dnSpyEx for decompilation, debugging, and IL editing; ILSpy and ilspycmd for command-line inspection; Detect It Easy for identification; dnlib for programmatic IL work; and de4dot where the selected implementation supports the relevant obfuscator. The original de4dot is archived, so fork-specific support and arguments require checking instead of relying on older compatibility tables.

An existing dnSpy MCP registration can expose decompilation and IL inspection tools. Its mention does not mean those capabilities ship with the skill. Supporting references address obfuscators, the common workflow, installation choices, and related analysis tools.