.NET Reversing

El reversing de binarios .NET recupera el código fuente de un .exe o .dll de Windows escrito en C#/VB.NET. Como esos binarios compilan a CIL (bytecode intermedio), un descompilador los devuelve a un código casi idéntico al original, con sus secretos incrustados: contraseñas, claves de cifrado, cadenas de conexión y la lógica de autenticación.

Por qué funciona. .NET no compila a código máquina sino a un lenguaje intermedio muy estructurado que conserva nombres de métodos, tipos y cadenas. Descompilar CIL a C# es casi perfecto (a diferencia de C/C++). Los desarrolladores asumen que "es un binario, nadie lo lee" y dejan credenciales hardcodeadas o algoritmos caseros que, una vez a la vista, se rompen enseguida.

El abuso. Se abre el ensamblado en un descompilador y se busca lo interesante.

# GUI: dnSpy / dnSpyEx (tambien depura y edita en caliente), ILSpy, dotPeek
# CLI: buscar cadenas y luego descompilar el metodo concreto
monodis <file>.exe | less
ilspycmd <file>.dll -o ./src && grep -RniE 'password|connectionstring|aes|key' ./src

Requisitos. Tener el ensamblado (.exe/.dll) desde disco, un recurso compartido o un instalador. Si está ofuscado (ConfuserEx y similares) hay que desofuscarlo antes, pero rara vez frena del todo.

Cómo detectarlo. Como el análisis es offline, la señal está antes: exfiltración de binarios propietarios o accesos anómalos a directorios de instalación. Es difícil de detectar una vez el fichero sale; el foco defensivo es evitar que haya nada valioso dentro.

Defensa. No incrustar secretos en el binario (usar un almacén seguro), no inventar criptografía, ofuscar como capa extra (no como única defensa) y proteger el acceso a los ejecutables. Es el primo Windows de la descompilación de JAR y del análisis de APK; lo que encuentra alimenta el rastreo de credenciales.