Ofuscar una aplicación WinForms sin perder los recursos del diseñador

Si has ofuscado una aplicación WPF, ya conoces la única regla que hay allí: XAML se enlaza a los miembros del modelo de vista por nombre, así que esos nombres tienen que sobrevivir. WinForms parece similar (una aplicación de escritorio, un archivo .Designer.cs, enlace de datos), así que resulta tentador aplicar esa misma regla única y publicar. Eso pasa por alto un segundo peligro que es específico de WinForms y que muerde más fuerte, porque falla sin dejar ni siquiera el rastro de un error de enlace: el diseñador acopla cada formulario a un flujo de recursos incrustado con el nombre del tipo del formulario. Renombra el tipo del formulario y los iconos, las imágenes y las cadenas localizadas simplemente dejan de cargarse.

Esta entrada es el recorrido específico de WinForms: qué emite realmente el diseñador, las dos cosas que la ofuscación no debe renombrar y la configuración de Nebula.NET que endurece el código dejando intacta esa fina superficie del diseñador.

Lo que el diseñador escribe realmente

Abre cualquier Form1.Designer.cs y mira más allá de la creación de controles, hasta las dos líneas que importan para la ofuscación. La primera aparece en cuanto tu formulario lleva un icono, una imagen o cualquier cosa que el diseñador almacene como recurso:

private void InitializeComponent()
{
    System.ComponentModel.ComponentResourceManager resources =
        new System.ComponentModel.ComponentResourceManager(typeof(MainForm));

    this.saveButton = new System.Windows.Forms.Button();
    // ...
    this.saveButton.Image =
        ((System.Drawing.Image)(resources.GetObject("saveButton.Image")));
    resources.ApplyResources(this.saveButton, "saveButton");
    this.Icon = ((System.Drawing.Icon)(resources.GetObject("$this.Icon")));
    // ...
}

Están ocurriendo dos búsquedas por nombre distintas, y se comportan de forma muy diferente bajo ofuscación:

• resources.GetObject("saveButton.Image") y ApplyResources(this.saveButton, "saveButton") se resuelven contra claves de recurso: cadenas simples incorporadas al .resx en tiempo de diseño. El literal "saveButton" es una constante de cadena, y el control se pasa por referencia, así que renombrar el campo saveButton no rompe esto. La cadena de la clave y el nombre del campo son independientes.
• new ComponentResourceManager(typeof(MainForm)) es la peligrosa. El administrador de recursos deriva el nombre del flujo de recursos incrustado del tipo que le pasas.

Por qué el nombre del tipo es estructural

Al compilar, el MainForm.resx del diseñador se compila en un recurso de manifiesto incrustado cuyo nombre es el nombre completo del tipo del formulario más una extensión: MyApp.MainForm.resources. En tiempo de ejecución, new ComponentResourceManager(typeof(MainForm)) lee typeof(MainForm).FullName, le añade .resources y le pide al ensamblado exactamente ese flujo.

Así que el nombre del recurso incrustado y el nombre del tipo son dos copias de la misma cadena que deben coincidir. Puedes ver el nombre incrustado en los metadatos: es una fila ManifestResource que apunta al blob:

// ildasm / metadata view of the assembly's manifest resources
.mresource public 'MyApp.MainForm.resources'
{
  // embedded .resources blob: saveButton.Image, $this.Icon, saveButton.Text, ...
}

Ahora renombra el tipo. Si el ofuscador renombra MyApp.MainForm a MyApp.a pero deja el recurso de manifiesto como MyApp.MainForm.resources, entonces en tiempo de ejecución ComponentResourceManager calcula "MyApp.a.resources", no encuentra tal flujo y cada GetObject devuelve null. Tus botones pierden sus imágenes, el formulario pierde su icono y un formulario localizado aparece con los rótulos en blanco, todo sin una sola excepción en el punto de llamada, porque que GetObject devuelva null es un resultado perfectamente legal ante el que el código del diseñador simplemente se encoge de hombros.

El segundo peligro: enlace y configuración por nombre

El acoplamiento al flujo de recursos es la trampa exclusiva de WinForms, pero WinForms también comparte el enlace de datos por nombre de WPF, y añade la configuración de la aplicación. Ambos se resuelven mediante cadenas con el nombre de la propiedad:

// Binds the control's Text to the Name property of a Customer instance — by string.
nameTextBox.DataBindings.Add("Text", _customer, nameof(Customer.Name));

// Designer-generated settings binding, also by string:
this.nameTextBox.DataBindings.Add(new System.Windows.Forms.Binding(
    "Text", global::MyApp.Properties.Settings.Default, "LastCustomerName", true,
    System.Windows.Forms.DataSourceUpdateMode.OnPropertyChanged));

"Name" y "LastCustomerName" son nombres de propiedades del origen de datos y del objeto de configuración. Renombra Customer.Name a a y el enlace lee de una propiedad que ya no existe: un campo en blanco, sin excepción. Es el mismo modo de fallo que en WPF, con la misma respuesta: conserva los nombres de los miembros enlazados.

La configuración de Nebula.NET

La estrategia es: preservar la fina superficie del diseñador y ofuscar a fondo todo lo que hay detrás. Dos opciones cargan con la mayor parte del peso.

Mantén la API pública con sus nombres, porque las propiedades enlazadas del modelo/modelo de vista y los miembros públicos del formulario suelen ser públicos:

{
  "inputs": ["bin/Release/net8.0-windows/MyApp.dll"],
  "outputDirectory": "protected",
  "preservePublicApi": true,
  "controlFlowObfuscation": true,
  "encryptStrings": true
}

Nebula detecta automáticamente la mayoría de los usos de reflexión, recursos y serialización, así que ComponentResourceManager(typeof(MainForm)) y el flujo .resources incrustado se mantienen sincronizados por ti: cuando se preserva el tipo, su flujo de recursos conserva el nombre correspondiente. Para un formulario con un tipo no público, o una disposición de recursos poco habitual hecha a mano, sé explícito y excluye los tipos de componente a partir de los cuales el diseñador construye un administrador de recursos:

{
  "preservePublicApi": true,
  "exclude": [
    "MyApp.MainForm",
    "MyApp.Controls.CustomerCard"
  ]
}

Excluir un tipo de formulario conserva su nombre (para que el flujo de recursos se resuelva) mientras sigue renombrando sus campos privados, aplanando su flujo de control y cifrando sus cadenas: estás protegiendo el cuerpo del tipo y solo fijando su nombre. Eso es casi gratis: el archivo del diseñador contiene la fontanería del diseño, no la lógica que merece la pena ocultar.

Si una propiedad enlazada no es pública y no quieres ampliar su visibilidad, excluye su tipo declarante en lugar de dejar los nombres expuestos globalmente:

{ "exclude": ["MyApp.Models.Customer"] }

Ofusca los internos a fondo

Con la superficie del diseñador fijada, apuesta por la protección en todo lo demás. Tus servicios, la validación, las comprobaciones de licencia, la capa de acceso a datos y los algoritmos no tienen ninguna restricción de resolución por nombre, así que el aplanado de flujo de control y el cifrado de cadenas se aplican por completo. Con preservePublicApi activado, los miembros privados e internos de todo el ensamblado siguen renombrándose — incluidos los campos privados de los mismos formularios cuyos nombres de tipo has conservado. El resultado: un atacante que abra tu build protegido en un decompilador ve tipos de formulario con nombre (inútiles para él — es solo diseño de pantalla) envolviendo lógica renombrada, aplanada y con cadenas cifradas (la parte que te importaba).

Ejecútalo y recorre cada pantalla — la verdadera prueba de aceptación

Como todos los fallos de WinForms descritos aquí ocurren en tiempo de ejecución, sin error de compilación y a menudo sin excepción, la única prueba honesta es lanzar el build protegido y ejercitarlo:

1. Abre cada formulario. Un formulario cuyo tipo fue renombrado aparece sin iconos/imágenes o con texto localizado en blanco — ese es el fallo del flujo de recursos. Añade el tipo del formulario a exclude.
2. Toca cada campo enlazado a datos. Un campo en blanco o que no guarda es una propiedad enlazada renombrada. Añade su tipo declarante a exclude (o mantén el miembro público).
3. Cambia de cultura si distribuyes recursos localizados — los ensamblados satélite se basan en el mismo nombre derivado del tipo, así que un formulario localizado es el más sensible a un tipo de formulario renombrado.
4. Ejercita el ciclo completo de la configuración — cambia un ajuste, reinicia y confirma que persistió.

Resumen

• WinForms añade una trampa que WPF no tiene: new ComponentResourceManager(typeof(MyForm)) vincula cada formulario a un flujo .resources incrustado con el nombre del tipo del formulario, así que renombrar el tipo del formulario rompe la carga de recursos en tiempo de ejecución.
• El segundo peligro es el conocido: los enlaces de datos y la configuración resuelven propiedades por nombre, así que los miembros enlazados deben sobrevivir.
• Con Nebula, mantén preservePublicApi activado, deja que la detección automática mantenga sincronizados los gestores de recursos, y usa exclude para cualquier tipo de componente a partir del cual el diseñador construya un gestor de recursos si tu diseño es inusual.
• Todo lo que hay detrás de esa superficie — el código que realmente merece protección — se renombra, se aplana y se cifra por completo.
• Lanza el build protegido y recorre cada formulario, enlace, cultura y ajuste, porque estos fallos nunca aparecen en tiempo de compilación.

¿Listo para proteger tu aplicación de escritorio? Descarga Nebula.NET gratis y consulta Protección de distintos tipos de proyecto para la lista de comprobación completa de escritorio.