.NET Reversing

.NET reversing recovers the source code of a Windows .exe or .dll written in C#/VB.NET. Because those binaries compile to CIL (intermediate bytecode), a decompiler turns them back into near-identical source, with their embedded secrets: passwords, encryption keys, connection strings and the authentication logic.

Why it works. .NET doesn't compile to machine code but to a highly structured intermediate language that keeps method names, types and strings. Decompiling CIL to C# is nearly perfect (unlike C/C++). Developers assume "it's a binary, nobody reads it" and leave hardcoded credentials or homemade algorithms that, once visible, break quickly.

The abuse. You open the assembly in a decompiler and hunt for the good stuff.

# GUI: dnSpy / dnSpyEx (also debugs and hot-edits), ILSpy, dotPeek
# CLI: grep for strings, then decompile the specific method
monodis <file>.exe | less
ilspycmd <file>.dll -o ./src && grep -RniE 'password|connectionstring|aes|key' ./src

Requirements. Have the assembly (.exe/.dll) from disk, a share or an installer. If it is obfuscated (ConfuserEx and friends) you must deobfuscate first, but that rarely stops it entirely.

How to detect it. Since the analysis is offline, the signal is earlier: exfiltration of proprietary binaries or anomalous access to install directories. It is hard to detect once the file leaves; the defensive focus is making sure there is nothing valuable inside.

Defence. Don't embed secrets in the binary (use a secure store), don't roll your own crypto, obfuscate as an extra layer (not the only defence) and protect access to the executables. It is the Windows cousin of JAR decompilation and APK analysis; what it finds feeds credential hunting.