Problemas de ASP.NET MVC Dotfuscator

Question

Estoy tratando de usar Dotfuscator (CE) para ayudar a proteger nuestro ASP.NET MVC .ddl. Es una aplicación web que se distribuirá a los clientes y necesitamos una forma de proteger nuestra IP.

El problema es que parece romper la aplicación una vez completada. Hasta ahora, he conseguido deshabilitar el cambio de nombre en el espacio de nombres de los Controladores, pero ahora obtengo excepciones de referencia nulas.

¿Alguien ha conseguido que Dotfuscator trabaje con ASP.NET MVC DLL? Google no proporciona publicaciones ni publicaciones de blogs posibles.

Gracias.

Otros detalles:

Visual Studio 2008 Professional,

Windows Vista Business x64,

registrado mi Dotfuscator pero no tenía un correo electrónico con un enlace para descargar la edición CE actualizado.

¿O alguien puede sugerir una herramienta relativamente barata que funcionaría correctamente?

Answer 1

No creo que funcione porque ASP.NET MVC se basa tanto en la reflexión.

He ocultado con éxito una aplicación ASP.NET MVC utilizando SmartAssembly y la opción de control-flujo-ofuscación que tiene. Eso no cambia el nombre de los miembros de tu clase, sino que cambia el código de tus métodos en código de espagueti.

Answer 2

Es cierto que ASP. NET MVC depende en gran medida de la reflexión y, por lo tanto, no puede ocultar el tipo o las propiedades que se reflejarán. Sin embargo, yo diría que no hay necesidad de ofuscar la mayoría de estas cosas de todos modos. Sus nombres de controlador y acción ya son públicos, ya que aparecen en URI. Sus modelos de presentación también son esencialmente públicos, ya que deben diseñarse como su vista, y dado que los usuarios finales pueden ver su vista.

Sus controladores deben ser muy livianos y simplemente unir objetos de un repositorio a sus modelos de presentación. Entonces, hay poca propiedad intelectual para esconderse aquí.

El código que en realidad desearía ofuscar sería presumiblemente la lógica de su negocio, que puede vivir fácilmente en un ensamblaje por separado. Así que mi sugerencia sería que en lugar de probar el ofuscador después de ofuscador, y tratando de encontrar uno que parezca funcione (excepto por los errores que se pierden, pero los usuarios lo descubrirán más adelante), en su lugar se divide el código que es importante para ofuscar y su no tan dependiente de la reflexión.