analyzing-dotnet-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

# 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

Decompile

ilspycmd target.dll -o ./decompiled -p       # -p writes a project structure
# GUI: dnSpyEx (maintained fork), ILSpy, dotPeek
# dnSpyEx also debugs and edits assemblies, which is why it is the default choice

rg -n 'https?://|ConnectionString|ApiKey|password|Convert\.FromBase64String' ./decompiled | head -40

Read in this order: the entry point, then any type named for the product, then anything referencing networking, crypto, or process APIs. Skip generated types (<>c__DisplayClass, <Module>) unless following a specific closure.

Identify the Obfuscator Before Fighting It

Deobfuscation is cheap when you name the tool and expensive when you do not.

detect-it-easy target.exe          # or DIE's CLI: diec
# Look for: ConfuserEx, .NET Reactor, SmartAssembly, Eazfuscator, Babel,
#           Dotfuscator, Agile.NET, Obfuscar
rg -a -o 'ConfuserEx|Reactor|SmartAssembly|Eazfuscator|Babel|DotNetPatcher' target.exe

# de4dot handles the classic obfuscators automatically
de4dot target.exe -o cleaned.exe
de4dot -p cr target.exe            # force a specific profile when detection fails
# ConfuserEx specifically: use a maintained unpacker fork, since de4dot's
# built-in support predates later ConfuserEx versions

What each obfuscation layer looks like, and how to handle it:

Dumping from memory is the general escape hatch. Whatever the packer, the CLR must eventually hold real IL to execute it. Let it load, then dump:

# MegaDumper / ExtremeDumper / pe-sieve — dump loaded managed modules from a
# running process, then decompile the dump
pe-sieve /pid <pid> /dmode 3

This is the same "let it unpack itself" pattern as packed native malware; see analyzing-malware for containment before running anything hostile.

Debugging and Patching

# dnSpyEx: set breakpoints in decompiled C#, inspect locals, edit method bodies,
# and save the modified assembly. This is unusually powerful — you can change a
# license check or a validation result and immediately re-run.

Patching workflow: edit the IL or the decompiled C# in dnSpyEx, save the assembly, and re-run. Strong-name signatures break on save — either remove the strong name requirement, or if the app verifies its own hash, hook the check. For a signed assembly the app itself verifies, patching is usually the wrong tool; hook at runtime instead.

.NET Malware Notes

.NET is heavily used for loaders and commodity RATs, and the artifacts are distinctive:

• Assembly.Load(byte[]) — a second stage decrypted in memory. Find the

decryption routine, run it offline, and analyze the resulting assembly. This is the single most common .NET malware pattern.

• Activator.CreateInstance plus reflection to hide the real call graph.
• AmsiScanBuffer / EtwEventWrite patching — search for the byte

patterns or the GetProcAddress calls that precede them.

• P/Invoke declarations ([DllImport]) reveal native capability:

VirtualAlloc, CreateRemoteThread, SetWindowsHookEx.

• Resources and satellite assemblies holding encrypted payloads — always

enumerate the resource section.

rg -n 'DllImport|Assembly\.Load|CreateInstance|FromBase64String|RijndaelManaged|AmsiScanBuffer' ./decompiled | head -30
ilspycmd --list-resources target.dll

Extracted second stages go back through this skill; capability and IOC output goes to analyzing-malware, detection content to engineering-detections.

Rationalizations to Reject

• "The names are meaningless, it's too obfuscated." Name mangling is the

weakest layer. The structure, strings, and P/Invokes are intact.

• "de4dot failed, so it can't be deobfuscated." Identify the obfuscator and

use its specific unpacker, or dump from memory.

• "It's a native EXE, so it isn't .NET." Check for single-file publish and

for native stubs wrapping managed code.

• "The strings are encrypted." The decryptor is in the assembly. Call it.
• "I decompiled the loader, that's the malware." The loader is stage one.

Find the Assembly.Load and recover what it loads.

• "I'll read the flattened control flow manually." Run the cleanup, or debug

it in dnSpyEx and watch the real path.

References

• analyzing-malware — containment, capability model, and IOCs
• analyzing-binaries — NativeAOT and native stub analysis
• reversing-unity-il2cpp, reversing-xamarin-maui — the other .NET containers
• engineering-detections — turning recovered behaviour into rules
• dnSpyEx, ILSpy/ilspycmd, de4dot, Detect It Easy, pe-sieve, OldRod