open - Ofuscación de ASP.Net dll rompe la aplicación web

dotfuscator

Question

No solía molestarme en ofuscar una DLL de aplicación web, pero ahora tengo que compartir algo de espacio en el servidor con alguien que pueda tener un conflicto de intereses y podría estar tentado de robar el trato y descompilarlo. No es una solución ideal, lo sé, pero oye.

Así que estoy usando VS 2005, un proyecto de implementación web (que se compila en una sola DLL) y la edición comunitaria Dotfuscator. Cuando ofusco el DLL la aplicación web se rompe y recibo un mensaje como

Could not load type ''Browse'' from assembly MyAssembly

Así que busqué y descubrí que si desactivo el cambio de nombre, entonces debería arreglarlo. Lo que hace Pero ahora, cuando miro la DLL con el reflector .Net, puedo ver todo de nuevo. Así que esto parece algo sin sentido.

¿Hay alguna manera de hacer que esto funcione? ¿Hay alguna forma mejor de proteger mi DLL de alguien con quien tengo que compartir un servidor?

ACTUALIZAR:

Resolví mi problema. Todos los nombres de las clases han cambiado pero ahora todo mi

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="mycode.aspx.cs" Inherits="mycode" %>

es incorrecto porque mycode ya no existe. Ahora es aef o algo. ¿Hay alguna herramienta que también cambie los nombres de las etiquetas Codefile e Inherits?

Answer 1

Estás cerca de la solución. En su situación, no sé en qué contexto se usa ''Examinar'', pero ¿lo está refiriendo a alguna parte como una cadena?

Hay algunas cosas que simplemente no se pueden ofuscar cuando se usa de cierta manera.

Por ejemplo, cuando tiene objetos personalizados que están vinculados a un control. Aquellas propiedades que haya especificado como miembro de la pantalla de valor de miembro no se pueden confundir. Esto se debe a que las propiedades se definen como una cadena. Por lo tanto, al momento del diseño no hay conexión entre el control y la propiedad real, pero en el tiempo de ejecución sí lo hay. No sé cómo explicarlo mejor; pero aquí hay un código:

// custom object
Public Class MyObject
{
string Test() { get; set; }
}
// here the object is bound to a combobox
MyCombo.ValueMember = "Test"; // The Test property cannot be obfuscated because of this ''indirect'' reference.
MyCombo.DisplayMember = "Test";
MyCombo.DataSource = lstListOfMyObjects;

Espero que aborde su problema. Si no, házmelo saber.

Answer 2

Necesitábamos algo así y probamos BitHelmet . Proporciona exclusiones predefinidas para ciertos objetos a los que se sabe que el marco accedió por su nombre, por ejemplo Web.UI.Page Descendants. Funciona perfectamente con aplicaciones web.

Answer 3

Nunca he usado la edición de la comunidad Dotfuscator, pero trato de ver si puedes cambiar el nombre solo de los tipos privados, variables. Eso debería hacer que sea más difícil de ver. La mayoría de los ofuscadores de la OMI tienen problemas, y cuando encuentras un error, quieren que envíes tu código para que puedan solucionar el problema. He encontrado problemas con la mayoría de las versiones comerciales, pero tal vez han mejorado en los últimos años ...

Answer 4

Para asp.net no sé de una salida rápida. La forma más rápida que he encontrado es la funcionalidad de protección de código del Equipo Seguro . Sale de la interfaz, pero encripta todo el il y hace que sea difícil para alguien revertirlo.

Asp.net es complicado debido a toda la resolución dinámica y la reflexión utilizada una vez que comienzas a cambiar los nombres de las cosas, se vuelve frágil y en la necesidad de una ronda completa de pruebas para asegurarte de que todo se carga y nada se rompe.