Skip to content

Nebula.NET

Resistir la desofuscación automatizada

Cómo Nebula.NET resiste a de4dot y otros desofuscadores automatizados — flujo de control que no se puede plegar a constantes, cifrado de cadenas que no se puede eliminar automáticamente, grafos de llamadas ocultos por proxies, y virtualización de código.

Lo primero que hace un atacante experto con un ensamblado protegido es ejecutar un desofuscador automatizado — el más común, de4dot — para retirar la protección con un clic antes de leer nada a mano. Un ofuscador que solo sobrevive a la inspección manual pero se deshace con de4dot file.dll en realidad no te está protegiendo.

Nebula está diseñado para derrotar la pasada automatizada. Cada capa ataca una técnica específica en la que se apoyan estas herramientas.

Flujo de control que no se puede plegar a constantes

Los desofuscadores de flujo de control automatizados deshacen un método aplanado propagando como constante la variable de estado del despachador — calculando estáticamente qué bloque se ejecuta a continuación y reconstruyendo la estructura original. El aplanado de Nebula enmascara el estado de despacho con una clave no plegable, calculada en tiempo de ejecución (switch (state ^ key), donde key lo produce un bucle que la herramienta no puede evaluar). Los valores de estado almacenados no son las etiquetas de los casos, así que no hay nada constante que plegar — el grafo de estados no se puede reconstruir. El nivel agresivo (Enterprise) añade estados señuelo no podables que no se pueden demostrar muertos ni eliminar.

Cifrado de cadenas que no se puede eliminar automáticamente

La victoria clásica de de4dot es el descifrado automático de cadenas: reconoce la rutina canónica string Decrypt(string), la invoca y reemplaza cada llamada con el texto plano. El descifrador de Nebula toma una clave por sitio de llamada (Decrypt(cipher, salt)), con una sal diferente en cada sitio — así que no es la firma que de4dot autodetecta, y ninguna llamada aislada reproduce una cadena sin la sal de su sitio. La pasada automática vuelve vacía.

Un grafo de llamadas oculto

La ofuscación de referencias (llamadas por proxy) enruta las llamadas a través de métodos proxy inyectados y sin marca, de modo que un decompilador y el análisis automatizado del grafo de llamadas no pueden ver qué método externo o de la BCL invoca realmente un sitio. El corrector genérico de llamadas por proxy de de4dot solo revierte los esquemas específicos de los ofuscadores que reconoce; el de Nebula no es uno de ellos.

Nada de IL en absoluto

Para tus métodos más sensibles, la virtualización de código (Enterprise) elimina el IL por completo — la lógica se convierte en bytecode de una VM personalizada. No hay nada que un desofuscador pueda limpiar, porque no hay IL reconocible desde el principio; revertirlo significa aplicar ingeniería inversa a la VM.

El resultado, por edición

CapaFreeProEnterprise
Despacho de flujo de control no plegablelimitado (2 métodos)✅✅
Cifrado de cadenas por sitio de llamadalimitado (2 cadenas)✅ ilimitado✅ ilimitado
Ofuscación de llamadas por proxy (grafo de llamadas)—✅✅
Nivel agresivo (estados señuelo)——✅
Virtualización de código——✅

La salida de Pro ya resiste la desofuscación automática de flujo de control y el descifrado de cadenas de de4dot, y oculta el grafo de llamadas. Enterprise añade el nivel agresivo y la virtualización, de modo que los métodos que más importan no tienen IL recuperable.

Verifícalo tú mismo

Esto no es una afirmación de marketing que tengas que creer a ciegas:

  1. Ofusca una compilación con Nebula.
  2. Pásala por de4dot (o cualquier desofuscador).
  3. Abre el resultado en Glass.NET (nuestro decompilador gratuito) o ILSpy.

Verás el flujo de control aún aplanado, las cadenas aún cifradas y los métodos virtualizados aún como una simple llamada a la VM. Ninguna protección del lado del cliente es jamás irrompible con esfuerzo ilimitado — pero el objetivo es hacer que el despojo automatizado falle y que la reversión manual resulte cara, y eso es exactamente lo que hacen estas capas.