Reverse engineer .NET assemblies and deobfuscate C# binaries

Runs a six-stage workflow for reverse-engineering .NET/C# compiled binaries. Stage 1 (Identify) confirms a target is actually a managed CLR program rather than native code, by checking for a non-zero CLR Runtime Header in the PE data directory, an mscoree.dll import or _CorExeMain entry point, #~/#Strings/#US/#GUID/#Blob metadata streams, or mscorlib/System.Private.CoreLib strings - a NativeAOT build is a documented exception, since it compiles to native code with no CLR header but still carries System.Private.CoreLib strings, and gets routed to a general native-reverse-engineering skill instead. Stage 2 (Detect) identifies the obfuscator/protector in play with Detect It Easy or de4dot --detect, covering ConfuserEx, SmartAssembly, Babel.NET, Eazfuscator.NET, .NET Reactor, Agile.NET/CliSecure, and Themida .NET (which de4dot cannot handle at all). Stage 3 (Deobfuscate) runs de4dot - auto-detecting in most cases, or with an explicit --type when detection fails - while always preserving the original sample for comparison; when an obfuscator's anti-tamper check blocks de4dot outright, the workflow patches the anti-tamper method to ret in dnSpyEx first, or dumps the decrypted assembly from a running process with a memory dumper before re-running de4dot on the dump. Stage 4 (Static Analyze) uses dnSpyEx's C# view only for quick navigation (class structure, method signatures, string search) and its IL view for anything that actually matters, because the C# decompiler's read-and-recompile approach frequently fails or distorts compiler-generated constructs like async/await state machines and iterator yield methods - the skill's core principle is IL over C# for exactly this reason. Stage 5 (Dynamic) uses dnSpyEx's debugger to break on key methods and read decrypted strings, C2 addresses, or config values directly out of memory at runtime, since most obfuscators only decrypt strings at runtime and .NET's managed runtime makes live object/string inspection far easier than native debugging; it also covers exception-driven control flow, where an obfuscator hides real logic inside a try/catch and dispatches on the caught exception's data, which requires breaking on the specific exception type to see the real path rather than reading the misleading static IL. Stage 6 (Patch) edits IL directly rather than recompiling C# - flipping a boolean check (ldc.i4.0/ldc.i4.1), replacing a constant, or nop-ing out a validation block - and explicitly ranks IL patch reliability above C# patch reliability, since IL editing is instruction-for-instruction and essentially never fails, while C# recompilation can fail on missing references or mis-handled compiler-generated state machines.

A separate section covers analyzing red-team "Sharp*" C# tooling (Rubeus, SharpHound, SharpShell/SharpWS, Seatbelt, SharpRoast, Inveigh/SharpSploit) for understanding detection logic and extracting embedded configuration - locating the command-dispatch entry point, the P/Invoke (Interop.*) layer where native API calls happen, and any encrypted resources or fields holding a C2 address or key, confirmed by breaking at the decryption method's return point at runtime.

Use it to identify and reverse a .NET/C# compiled artifact (managed PE/.exe/.dll), to analyze red-team Sharp* tooling before use or defense, to deobfuscate a ConfuserEx/SmartAssembly/Babel/Eazfuscator/.NET Reactor-protected assembly, to reverse a .NET loader or info-stealer's decryption and C2 logic, to patch a C# program (flip a check, change a constant, build a keygen), or to analyze the pre-IL2CPP Mono/Unity managed layer. Do NOT use it for a purely native binary with no CLR (C/C++/Go/Rust) - use a general reverse-engineering or IDA/radare2 skill instead - and switch away from it for an IL2CPP-compiled Unity game or a NativeAOT build, both of which compile to native code with no CLR metadata to work from.

Input is the target managed binary. Each stage's output should be written to disk for reproducibility: the untouched original sample, the de4dot-cleaned binary, a notes file recording the identified obfuscator, any decryption method token, key method addresses, and extracted config/C2/key values, a patched binary when patching was done, and an IL diff of what changed. Example de4dot invocations: de4dot target.exe -o target-clean.exe for auto-detection, de4dot --type cfze target.exe to force ConfuserEx handling, and de4dot --strtyp delegate --strtok <token> to decrypt only the string-decryption calls at a given method token while leaving control flow untouched.

dnSpyEx is the primary tool - the only GUI with both an IL editor and a debugger, since the original dnSpy project is unmaintained - available on Windows only; Linux/macOS analysis instead uses ilspycmd (ILSpy's CLI) for decompilation plus dnlib scripts for programmatic metadata edits, with no equivalent interactive debugger. de4dot is the default deobfuscator, dnlib is the .NET metadata-manipulation library de4dot itself is built on (used for custom deobfuscation scripts), and Detect It Easy (diec) identifies the protector in play. When a dnSpy MCP server (community projects exposing dnspy_decompile/dnspy_inspect_il as MCP tools) is registered, the skill prefers calling those tools directly over switching to the GUI.

Reverse engineers and security researchers analyzing .NET malware, loaders, info-stealers, commercial software protections, or red-team Sharp* tooling, and anyone patching or keygen-ing a C# application. Community-sourced from zhaoxuya520/reverse-skill under the MIT license, added 2026-08-25.