How .NET decompilers read your code

Developers are often surprised by how completely a .NET decompiler reconstructs their code. It is not a flaw in the tools or in .NET — it follows directly from how managed assemblies are designed. Understanding why explains precisely what obfuscation changes.

What is actually inside a .NET assembly

When a C++ compiler produces an executable, it emits machine code for a specific processor. Names, types and structure are consumed during compilation and largely discarded. Reconstructing readable source from the result is genuinely hard.

.NET works differently, and deliberately so. Your assembly contains:

• IL — a compact, stack-based instruction set that is much closer to your source than machine code is, and which was designed to be JIT-compiled later rather than executed directly.
• Metadata tables — a structured description of every type, method, field, property, parameter and attribute in the assembly, including their names and full signatures.

Both are mandatory. The runtime needs metadata to lay out objects, resolve calls, perform reflection, marshal interop and enforce type safety. It cannot be stripped, because without it your code will not run.

Why that makes decompilation straightforward

A decompiler starts from a far better position than a native disassembler. It does not have to infer that a block of memory is a class with three fields — the metadata says so explicitly, by name. It does not have to guess a function signature — the signature is recorded.

The reconstruction is roughly:

1. Read the metadata to rebuild the exact type hierarchy, with original names.
2. For each method, read its IL instruction stream.
3. Convert the stack-based IL back into expressions and statements.
4. Recognise compiler patterns and restore the high-level constructs behind them.

That last step is where modern tools genuinely impress. Constructs the C# compiler lowers into state machines and hidden classes — async/await, iterators, lambda closures, foreach, LINQ query syntax, pattern matching — are recognised and reversed. ILSpy will typically hand you back something close to idiomatic C#, not a mess of gotos.

The tools

• ILSpy — free, open source, actively maintained, cross-platform.
• dnSpy — a decompiler with an integrated debugger. Its notable capability is editing methods and saving a modified assembly, which is why it features heavily in discussions of licence bypassing.
• dotPeek — JetBrains' free decompiler, which can act as a symbol server.
• ILDASM — ships with the SDK; shows raw IL rather than reconstructed C#.

None of these are exotic. ILSpy is a few seconds' download, and it works on any assembly you can obtain — which, for shipped desktop software, means anyone who installed it.

What obfuscation changes

Since names come from the metadata tables, and those tables are what a decompiler reads, rewriting the names changes exactly what the reader sees. The IL is untouched, so behaviour is identical, but the reconstruction loses its most valuable input.

Before:

public bool ValidateLicenseKey(string key)
{
    if (string.IsNullOrEmpty(key)) return false;
    var decoded = _cryptoProvider.Decrypt(key);
    return decoded.ExpiryDate > DateTime.UtcNow;
}

After:

public bool a(string b)
{
    if (string.IsNullOrEmpty(b)) return false;
    var c = this.d.e(b);
    return c.f > DateTime.UtcNow;
}

The logic is intact and a patient reader can still follow it. What has gone is the ability to find this method among hundreds of others, and the instant comprehension that came free with the original names. At scale, across a real codebase, that difference is substantial.

What survives

Note carefully what is still legible in the obfuscated version:

• string.IsNullOrEmpty and DateTime.UtcNow — framework calls must keep their real names to resolve against the BCL.
• Control flow — the shape of the logic is unchanged.
• String literals, which name obfuscation does not touch. Searching for user-visible text remains one of the most effective ways to locate interesting code.

This is why obfuscation is a cost-raising measure rather than a barrier. What obfuscation actually protects against works through the implications properly.

Try it on your own build

The exercise worth doing: open your most recent release binary in ILSpy and read it as an outsider would. Most developers find the experience clarifying — the code is more legible than they assumed. Then obfuscate the same file and open it again.