2010-09-18 24 views
6

Mi empleador utiliza Dotfuscator en todo nuestro software de producción .Net. Debido a esto, tenemos absolutamente prohibido utilizar CUALQUIER enlace de datos incorporado o cualquier cosa que refleje los nombres de propiedad/función, ya que dotfuscator los cambia y, por lo tanto, cualquier cosa atada al instante y se rompe irremediablemente.Encuadernación de datos y ofuscación de código

Sigo teniendo esta lógica en mente y está empezando a doler. Hay debe ser ser una forma de evitar este punto muerto, es un problema demasiado amplio y fundamental para no tener una solución obvia que se nos haya escapado.

Entonces, ¿cómo se hace una reflexión con ofuscación? ¿Cuál es el truco? Es de suponer que debe haber ofuscadores comerciales lo suficientemente inteligentes como para evitar el problema. ¿Cuáles son las opciones para nuestra versión (que es bastante estúpida)?

Respuesta

3

Hemos realizado una serie de mejoras en Dotfuscator que deberían ayudar a resolver los problemas relacionados con la vinculación de datos. La funcionalidad de ofuscación inteligente se agregó en la versión 4.3.100 en marzo de 2008 para analizar de forma estática los ensamblados y excluir automáticamente los elementos del cambio de nombre/eliminación que se sabe causan errores de tiempo de ejecución. Hemos expandido y mejorado consistentemente esta funcionalidad y el Dotfuscator de hoy en día funciona alrededor de escenarios de enlace de datos estándar, generalmente con configuraciones extra mínimas o mínimas.

Incluso si Smart Obfuscation no detecta cada uno de sus escenarios, es muy fácil definir reglas personalizadas para excluir propiedades de ciertos tipos o jerarquías de herencia mediante el uso de reglas de exclusión personalizadas (incluidos tipos coincidentes por patrones RegEx). También puede decorar elementos con el atributo System.Reflection.ObfuscationAttribute para asegurarse de que se excluyan del cambio de nombre o de la eliminación cuando se ejecuten a través de Dotfuscator.

Si está vinculando desde el marcado XAML a los tipos de código subyacentes, las últimas versiones admiten el cambio de nombre del XAML/BAML para que coincida con el código que se encuentra detrás. Esto mejora el endurecimiento general y también elimina toda una gama de problemas cuando los símbolos en el marcado no coinciden con las definiciones del código.

Recomendaría trabajar con algunas simples pruebas de concepto de aplicaciones usando databinding similar a lo que quiere usar en sus aplicaciones y ejecutarlas a través de Dotfuscator para ver qué tan bien las maneja. Si encuentra algún escenario donde Smart Obfuscation no excluya automáticamente los objetivos de enlace de datos, envíelos a [email protected] Siempre estamos buscando escenarios bien definidos para mejorar el producto.

+0

Gracias Joe, eso es realmente útil. Ahora me siento un poco tímido por varias razones: i) incluí un deslizamiento menor en Dotfuscator en mi publicación inicial, lo cual lamento; ii) parece que estamos usando una versión muy antigua (se me olvida cuál, pero no hace las cosas que has mencionado) y iii) aunque me quejo, no es mi decisión, y yo ' Hasta ahora he sido incapaz de persuadir a mi colega a cargo de esta área para que adopte algo nuevo o modifique sus tácticas de ninguna manera. –

+0

Como una adición; ¿Puedo suponer que 4.3 Community Edition incluye esta funcionalidad y no es una función de solo pago? Persuadir a la gerencia a que parta con efectivo nunca es sencillo. –

+0

Incluso sin Obfuscación inteligente, puede crear reglas de exclusión personalizadas (incluidas las coincidencias RegEx) desde la versión 1.0 en adelante. Es un poco de trabajo manual, pero ciertamente es posible. La Ofuscación inteligente en la versión gratuita de Dotfuscator está disponible en la versión 5.0 que se envió con Visual Studio 2010. –

0

El ofuscador tiene la tarea de desglosar las relaciones visibles en el código fuente para que ya no aparezcan en el código ejecutable resultante. La reflexión se basa en relaciones tales como "la propiedad solicitada por este fragmento de código es la definida por ese fragmento de código". Por lo tanto, no es sorprendente que la ofuscación y la reflexión no funcionen bien entre sí.

Cambiar el nombre de las propiedades es solo el grado cero de ofuscación. Un ofuscador no trivial también hará cosas como dividir una propiedad en dos, de modo que cuando el código fuente solo mencione una propiedad P, parte del código de tiempo de ejecución use P1, y parte del código de tiempo de ejecución usará P2, y habrá suficiente asignaciones entre ellos para que las propiedades tengan el valor correcto cuando sea necesario, pero también asignaciones parásitas para que no tengan el valor correcto cuando no se necesiten. No es sólo que P ha cambiado de nombre: ya no es una propiedad P.

No sé por qué piensa que la reflexión más ofuscación es “amplio y fundamental”: la reflexión y la ofuscación son bastante raro en el gran esquema de programación, y no existe una correlación entre su uso, así que no creo que muchas personas intenten tener ambos.

La falta de reflexión es solo un elemento en la larga lista de cosas que te cuesta ofuscación. Si la persona que decidió utilizar la ofuscación no es un experto en seguridad, intente convencerle de que la ofuscación tiene un costo muy elevado que seguramente no se habrá evaluado.

+0

Supongo que estoy siendo bastante .Net-céntrico, que funciona para nuestro negocio a medida que desarrollamos en .Net. El desarrollador principal es absolutamente insistente en que debemos ofuscar todo; es difícil persuadirlo en el mejor de los casos y esta opinión en particular es una a la que se apega como una lapa. Tal como lo veo, el enlace es indispensable siempre que quiera usar una arquitectura MVC y esto impide su uso. Siento que nos estamos disparando en el pie, pero reconozco los argumentos para la ofuscación. Se necesitaría un cambio en la cultura empresarial para aceptar la inevitabilidad de que otros descompilen nuestras aplicaciones. –

Cuestiones relacionadas