analyzing-dotnet-assemblies

Analyzing .NET Assemblies

.NET compiles to IL with full metadata, so an unobfuscated assembly decompiles to near-original C#. That makes the interesting question not "how do I read this" but "what is in the way" — a packer, an obfuscator, a runtime loader, or a publish mode that hides the managed code inside a native host.

When to Use

• file reports a PE and the binary contains a CLR header or mscoree.dll
• ILSpy or dnSpy opens the assembly but names are mangled or bodies are empty
• Analyzing .NET malware, loaders, or red-team tooling
• Reviewing a Windows desktop or service application without source
• Recovering logic from a PowerShell or C# in-memory loader

When NOT to Use

• Unity IL2CPP — use reversing-unity-il2cpp; the C# is compiled to native
• Xamarin/MAUI mobile — use reversing-xamarin-maui for the container extraction, then come back here for the DLLs
• Suspected malware, before containment — use analyzing-malware first
• Go or Rust binaries — use the matching skill

Confirm It Is Managed

# Linux
file target.exe                                 # "Mono/.Net assembly"
rg -a -o 'BSJB|mscoree\.dll|System\.Private\.CoreLib' target.exe | head

# Windows
dotnet-tool: ildasm /text target.exe | head
# CLR header presence in the optional header data directory 14 is the real test

What you find	Publish mode	Approach
Managed PE, references mscorlib/System.Private.CoreLib	Framework-dependent	Decompile directly
Native PE containing an embedded managed bundle	Single-file publish	Extract the bundle first
Native PE, no IL metadata at all	NativeAOT	Not .NET RE — use analyzing-binaries
.dll with no entry point	Library	Decompile; find callers elsewhere

# Single-file publish: the managed assemblies are appended as a bundle
# Extract with a bundle extractor, or carve on the manifest header
ilspycmd --list-bundle target.exe 2>/dev/null || binwalk -Me target.exe