Endurecer automáticamente tus comprobaciones de licencia

Cada flag de función, cada rama «¿esto está licenciado?», cada comprobación de puesto acaba canalizándose a través de una pequeña cantidad de código: el método que verifica la licencia y devuelve un sí o un no. Ese método es el objetivo de mayor valor de toda tu aplicación. Un atacante no necesita entender tu lógica de negocio — necesita encontrar ese único método y hacer que siempre devuelva true. Endurece todo lo demás y deja la puerta legible, y habrás cerrado todas las puertas menos la principal.

Así que la comprobación de licencia es precisamente el código que merece tu protección más fuerte. El problema es acordarse de aplicarla ahí — por nombre, según refactorizas, en cada método que toca el licenciamiento. El autoProtectLicensing de Nebula.NET hace ese direccionamiento por ti.

Actívalo

Es un solo flag:

{
  "rename": true,
  "controlFlowObfuscation": true,
  "autoProtectLicensing": true
}

Con eso puesto, Nebula encuentra los métodos de tu ensamblado que llaman a tu SDK de licenciamiento y los añade automáticamente a la protección más fuerte que permita tu edición —ofuscación del flujo de control agresiva y, en Enterprise, virtualización de métodos— sin que enumeres un solo nombre de método.

Cómo encuentra el código de licenciamiento

El direccionamiento es análisis de sitios de llamada, no adivinanza sobre nombres. Antes de que se ejecuten las pasadas de protección, Nebula recorre cada cuerpo de método e inspecciona cada call, callvirt y newobj. Si el miembro invocado pertenece a uno de los espacios de nombres de licenciamiento configurados —Keyright por defecto— ese método se marca como código de licenciamiento:

// Este método llama a Keyright, así que la auto-protección lo marca:
public bool CanExport()
{
    var lease = Keyright.License.Current;          // ← llamada al espacio de nombres Keyright
    return lease.IsValid && lease.Entitlements.Has("export");
}

Nebula registra la identidad totalmente cualificada del método y lo incorpora al conjunto de inclusión de la ofuscación del flujo de control (y de la virtualización, donde esté licenciada) junto a lo que hayas listado explícitamente. El resultado es que CanExport —y cualquier otro método que alcance el licenciamiento— se aplana en una máquina de estados con despachador (o se compila a bytecode de VM en Enterprise), mientras que el resto de tu app conserva la protección por defecto más ligera.

Si tu licenciamiento vive tras tu propio envoltorio fino, apunta el detector también a ese espacio de nombres:

{
  "autoProtectLicensing": true,
  "licensingNamespaces": ["Keyright", "MyApp.Licensing"]
}

Ahora un método que llama a MyApp.Licensing.Gate.Check() se detecta aunque nunca nombre a Keyright directamente — así una única capa de licenciamiento interna queda totalmente cubierta, y no tienes que volver a enumerar métodos según los añades.

Por qué dirigir en vez de proteger todo

La pregunta natural es: ¿por qué no virtualizar toda la app? Porque las transformaciones pesadas cuestan algo. El aplanado agresivo del flujo de control y la virtualización añaden tamaño y se ejecutan más lento que el IL original — insignificante en un método que se ejecuta una vez al inicio, pero no algo que quieras multiplicado por cada método caliente de una base de código grande. Así que la estrategia realista es siempre dirigir la protección fuerte, y la comprobación de licencia es el caso de libro al que apuntar:

• Es pequeña — un puñado de métodos, así que el coste es trivial.
• Se ejecuta rara vez — al inicio o en una frontera de función, no en un bucle apretado.
• Es decisiva — vencerla desbloquea el producto entero, así que es donde un atacante invierte su tiempo.

autoProtectLicensing hace que «gastar el presupuesto de protección en el código de licenciamiento» sea automático y a prueba de refactorizaciones. Nunca envías una compilación donde un método de comprobación de licencia recién añadido se coló porque nadie actualizó la lista de inclusión.

Se combina con las demás capas

La auto-protección decide qué proteger; se apila con las transformaciones que deciden cómo. La comprobación de licencia se beneficia más cuando varias capas aterrizan a la vez:

• La ofuscación del flujo de control / virtualización (lo que aplica la auto-protección) oculta la lógica de la comprobación — las ramas, la comparación que devuelve el veredicto.
• La ofuscación de referencias oculta el grafo de llamadas, de modo que ni siquiera el hecho de que este método llama a una API de licenciamiento es legible en el sitio de llamada.
• El cifrado de cadenas oculta los nombres de derechos y los mensajes que consume la comprobación.
• El anti-manipulación hace que parchear el veredicto después active una comprobación de integridad.

Cada una cierra un atajo distinto. El renombrado por sí solo dejaría legible la lógica de la puerta; la auto-protección garantiza que la puerta esté en el conjunto de protección fuerte; las demás capas eliminan los indicios de alrededor. Juntas convierten «encuentra el método y voltea el booleano» en trabajo real, lento y manual — que es todo el objetivo.

Una licencia es solo tan fuerte como el código que la comprueba. Para el trasfondo de por qué es así y los enfoques comunes en .NET, consulta proteger tus comprobaciones de licencia; la auto-protección es cómo Nebula se asegura de que esa protección aterrice de verdad en los métodos correctos, en cada compilación, sin una lista mantenida a mano. Si estás eligiendo un sistema de licenciamiento con el que combinarla, Keyright es el que Nebula reconoce de serie.