visual studio source open obfuscator net dotfuscator confuserex .net security obfuscation

studio - Herramientas/estrategia de ofuscación.NET



dotfuscator visual studio 2017 (30)

Mi producto tiene varios componentes: ASP.NET, la aplicación de formularios Windows Forms y el servicio de Windows. El 95% del código está escrito en VB.NET.

Por razones de propiedad intelectual, necesito ofuscar el código, y hasta ahora he estado usando una versión de dotfuscator que ahora tiene más de 5 años. Estoy pensando que es hora de pasar a una herramienta de nueva generación. Lo que estoy buscando es una lista de requisitos que debo considerar al buscar un nuevo ofuscador.

Lo que sé que debería buscar hasta ahora:

  • Serialización / Deserialización . En mi solución actual, simplemente le digo a la herramienta que no ofusque a ningún miembro de datos de la clase porque el dolor de no poder cargar datos que se serializaron anteriormente es simplemente demasiado grande.
  • Integración con el proceso de construcción
  • Trabajando con ASP.NET . En el pasado, he encontrado este problema debido al cambio de nombres .dll (a menudo tiene uno por página), que no todas las herramientas manejan bien.

Debe usar lo que sea más barato y mejor conocido para su plataforma y llamarlo por día. La ofuscación de lenguajes de alto nivel es un problema difícil, porque los flujos de código de operación de VM no sufren los dos problemas más grandes que tienen los flujos de código de operación nativos: identificación de función / método y alias de registro.

Lo que debe saber sobre la inversión de bytecode es que ya es una práctica estándar para los probadores de seguridad revisar el código X86 directo y encontrar vulnerabilidades en él. En X86 sin formato, no necesariamente puede encontrar funciones válidas, y mucho menos rastrear una variable local a lo largo de una llamada de función. En casi ninguna circunstancia, los inversores de código nativo tienen acceso a nombres de funciones y variables, a menos que estén revisando el código de Microsoft, para lo cual MSFT proporciona útilmente esa información al público.

"Dotfuscation" funciona principalmente codificando funciones y nombres de variables. Probablemente sea mejor hacer esto que publicar código con información de nivel de depuración, donde Reflector está literalmente renunciando a su código fuente. Pero cualquier cosa que haga más allá de esto es probable que obtenga rendimientos decrecientes.

Durante los últimos dos días he estado experimentando con Dotfuscator Community Edition Advanced (una descarga gratuita después de registrar el CE básico que viene incluido con Visual Studio).

Creo que la razón por la que más personas no usan la ofuscación como opción predeterminada es porque es una molestia grave en comparación con el riesgo. En proyectos de prueba más pequeños, podría ejecutar el código ofuscado con mucho esfuerzo. Implementar un proyecto simple a través de ClickOnce fue problemático, pero se logró después de firmar manualmente los manifiestos con mage. El único problema fue que, en caso de error, el seguimiento de la pila volvió ofuscado y el CE no tiene un desobuscador o clarificador empaquetado.

Traté de ofuscar un proyecto real basado en VSTO en Excel, con integración de Virtual Earth, muchas llamadas de servicio web y un contenedor IOC y mucha reflexión. Fue imposible.

Si la ofuscación es realmente un requisito crítico, debe diseñar su aplicación teniendo esto en cuenta desde el principio, probando las compilaciones ofuscadas a medida que avanza. De lo contrario, si se trata de un proyecto bastante complejo, terminarás con una gran cantidad de dolor.

Estamos utilizando SmartAssembly en nuestro cliente de Windows. Funciona bien

Agrega algunos problemas adicionales también. La impresión de los nombres de sus clases en archivos de registro / excepciones tiene que ser ofuscada. Y, por supuesto, no puede crear una clase a partir de su nombre. Por lo tanto, es una buena idea echar un vistazo a su cliente y ver qué problemas puede obtener al ofuscarse.

Estoy ''Rodilla Profunda'' en esto ahora, tratando de encontrar una buena solución. Aquí están mis impresiones hasta ahora.

Xenocode : tengo una licencia anterior para Xenocode2005 que solía usar para ofuscar mis ensamblados .net 2.0. Funcionó bien en XP y fue una solución decente. Mi proyecto actual es .net 3.5 y estoy en Vista, el soporte me dijo que lo intentara, pero la versión 2005 ni siquiera funciona en Vista (falla), así que ahora tengo que comprar ''PostBuild2008'' a un precio increíble. de $ 1900. Esta podría ser una buena herramienta, pero no voy a averiguarlo. Muy caro.

Reactor.Net : este es un precio mucho más atractivo y funcionó bien en mi Ejecutable independiente. El módulo de licencias también fue agradable y me habría ahorrado mucho esfuerzo. Desafortunadamente, le falta una característica clave y es la capacidad de excluir cosas de la ofuscación. Esto hace que sea imposible lograr el resultado que necesitaba (Fusionar múltiples ensamblajes, ofuscar algunos, no ofuscar otros).

SmartAssembly : descargué el Eval para esto y funcionó a la perfección. Pude lograr todo lo que quería y la interfaz era de primera clase. El precio sigue siendo un poco elevado.

Dotfuscator Pro : no se pudo encontrar el precio en el sitio web. Actualmente en conversaciones para obtener una cotización. Suena siniestro

Confuser : un proyecto de código abierto que funciona bastante bien (para confundir a ppl, tal como su nombre lo indica). https://confuser.codeplex.com/
(añadido por jgauffin)

Nota: ConfuserEx está "roto" según el número 498 en su repositorio de GitHub.

Evitar Reactor. Es completamente inútil (y sí, pagué una licencia). Xenocode fue el mejor con el que me encontré y también compré una licencia. El soporte fue muy bueno, pero no lo necesitaba mucho, ya que simplemente funcionó. Probé todos los ofuscadores que pude encontrar y mi conclusión es que xenocode fue de lejos el más robusto e hizo el mejor trabajo (también la posibilidad de publicar el proceso de tu .NET exe en un exe nativo que no vi en ningún otro lugar).

Hay dos diferencias principales entre el reactor y el xenocode. El primero es que Xenocode realmente funciona. El segundo es que la velocidad de ejecución de sus ensamblajes no es diferente. Con el reactor fue aproximadamente 6 millones de veces más lento. También tuve la impresión de que el reactor era una operación de un solo hombre.

He estado ofuscando código en la misma aplicación desde .Net 1, y ha sido un gran dolor de cabeza desde la perspectiva del mantenimiento. Como mencionó, se puede evitar el problema de serialización, pero es realmente fácil cometer un error y ofuscar algo que no desea ofuscar. Es fácil romper la compilación o cambiar el patrón de ofuscación y no poder abrir archivos antiguos. Además, puede ser difícil descubrir qué salió mal y dónde.

Nuestra elección fue Xenocode, y si hiciera la elección nuevamente hoy preferiría no ofuscar el código o usar Dotfuscator.

He estado usando smartassembly. Básicamente, eliges un dll y lo devuelve ofuscado. Parece funcionar bien y hasta ahora no he tenido problemas. Muy, muy fácil de usar.

He probado casi todos los ofuscadores en el mercado y SmartAssembly es el mejor en mi opinión.

He probado un producto llamado Rummage y hace un buen trabajo al darle algo de control ... Aunque carece de muchas cosas que ofrece Eziriz, pero el precio de Rummage es demasiado bueno ...

Hemos probado varios ofuscadores. Ninguno de ellos funciona en una gran aplicación cliente / servidor que utiliza comunicación remota. El problema es que el cliente y el servidor comparten algunos dlls, y no hemos encontrado ningún ofuscador que pueda manejarlo.

Hemos probado DotFuscator Pro, SmartAssembly, XenoCode, Salamander y varias aplicaciones pequeñas cuyos nombres se me escapan.

Francamente, estoy convencido de que la ofuscación es un gran truco.

Incluso los problemas que aborda no son del todo un problema real. Lo único que realmente necesita proteger es cadenas de conexión, códigos de activación, cosas sensibles a la seguridad como esas. Esta tontería de que otra compañía va a aplicar ingeniería inversa a toda su base de código y crear un producto de la competencia es algo de la pesadilla de un gerente paranoico, no la realidad.

La respuesta corta es que no puedes.

Existen varias herramientas que dificultarán que alguien lea su código, algunas de las cuales han sido señaladas por otras respuestas.

Sin embargo, todo esto hace que sea más difícil de leer: aumentan la cantidad de esfuerzo requerido, eso es todo. A menudo, esto es suficiente para disuadir a los lectores ocasionales, pero alguien que esté decidido a profundizar en su código siempre podrá hacerlo.

No he tenido problemas con Smartassembly.

Ofuscarse no es una protección real.

Si tiene un archivo .NET Exe, hay una solución MUCHO mejor .

Yo uso Themida y puedo decir que funciona muy bien.

El único inconveniente de Themida es que no puede proteger .NET Dlls. (También protege el código C ++ en Exe y DLL)

Themida es mucho más barato que los ofuscadores mencionados aquí y es el mejor en protección contra la piratería en el mercado. Crea una máquina virtual donde se ejecutan partes críticas de su código y ejecuta varios subprocesos que detectan la manipulación o los puntos de interrupción establecidos por un cracker. Convierte .NET Exe en algo que Reflector ya ni siquiera reconoce como ensamblado .NET.

Lea la descripción detallada en su sitio web: http://www.oreans.com/themida_features.php

Probé la versión demo de Eziriz ... Me gustó. Pero nunca trajo el software.

Puede usar "Dotfuscator Community Edition"; viene de forma predeterminada en Visual Studio 2008 Professional. Puedes leer sobre esto en:

http://msdn.microsoft.com/en-us/library/ms227240%28VS.80%29.aspx
http://www.preemptive.com/dotfuscator.html

La versión "profesional" del producto cuesta dinero pero es mejor.

¿Realmente necesitas ofuscar tu código? Por lo general, hay muy poco error con la descompilación de su aplicación, a menos que se utilice con fines de seguridad. Si le preocupa que las personas "roben" su código, no se preocupe; La gran mayoría de las personas que busquen su código serán con fines de aprendizaje. De todos modos, no existe una estrategia de ofuscación totalmente efectiva para .NET: alguien con suficiente habilidad siempre podrá descompilar / cambiar su aplicación.

Recientemente he intentado conectar la salida de un ofuscador libre a otro ofuscador libre, a saber, Dotfuscator CE y el nuevo ofuscador Babel en CodePlex. Más detalles en mi blog .

En cuanto a la serialización, moví ese código a una DLL diferente y lo incluí en el proyecto. Razoné que no había secretos allí que no estén en el XML de todos modos, por lo que no necesitaba ofuscación. Si hay algún código serio en esas clases, el uso de clases parciales en el ensamblaje principal debería cubrirlo.

Si está buscando uno gratuito, puede probar DotObfuscator Community Edition que viene con Visual Studio o Eazfuscator.NET .

Desde el 29 de junio de 2012 , Eazfuscator.NET ahora es comercial. La última versión gratuita disponible es la 3.3.

SmartAssembly es genial, fui utilizado en la mayoría de mis proyectos

También es posible que desee ver las nuevas tecnologías de protección de código como Metaforic y V.i.Labs y las nuevas tecnologías de protección de copia de software como ByteShield . Divulgación: trabajo para ByteShield.

También he estado usando SmartAssembly. Encontré que Ezrinz .Net Reactor es mucho mejor para mí en aplicaciones .net. Se ofusca, admite Mono, combina conjuntos y también tiene un módulo de licencia muy agradable para crear una versión de prueba o vincular la licencia a una máquina en particular (muy fácil de implementar). El precio también es muy competitivo y cuando necesitaba ayuda eran rápidos. Eziriz

Para que quede claro, solo soy un cliente al que le gusta el producto y no está relacionado de ninguna manera con la empresa.

También uso smartassembly. Sin embargo, no sé cómo funciona para una aplicación web. Sin embargo, me gustaría señalar que si su aplicación usa protección de tipo shareware, asegúrese de que no verifique una licencia con un retorno booleano. es muy fácil byte crack. http://blogs.compdj.com/post/Binary-hack-a-NET-executable.aspx

Tenemos una aplicación de varios niveles con una interfaz asp.net y winform que también admite la comunicación remota. No he tenido problemas con el uso de ningún ofuscador con la excepción del tipo de cifrado que genera un cargador que puede ser problemático en todo tipo de formas inesperadas y, en mi opinión, simplemente no vale la pena. En realidad, mi consejo sería más similar a "Evitar cifrar ofuscadores de tipo cargador como la peste". :)

En mi experiencia, cualquier ofuscador funcionará bien con cualquier aspecto de .net, incluyendo asp.net y control remoto, solo tiene que intimar con la configuración y aprender hasta dónde puede empujarlo en qué áreas de su código. Y tómese el tiempo para intentar realizar ingeniería inversa en lo que obtiene y ver cómo funciona con las diversas configuraciones.

Usamos varios a lo largo de los años en nuestras aplicaciones comerciales y nos decidimos por el ofuscador Spices de 9rays.net porque el precio es correcto, hace el trabajo y tienen un buen soporte, aunque realmente no lo hemos necesitado en años, pero para ser honesto. No creo que realmente importe qué ofuscador use, los problemas y la curva de aprendizaje son todos los mismos si desea que funcione correctamente con control remoto y asp.net.

Como otros han mencionado, todo lo que realmente está haciendo es el equivalente a un candado, mantener alejadas a las personas honestas o hacer que sea más difícil recompilar una aplicación.

La concesión de licencias suele ser el área clave para la mayoría de las personas y, de todos modos, definitivamente debería utilizar algún tipo de sistema de certificado firmado digitalmente. Su mayor pérdida vendrá del intercambio casual de licencias si no tiene un sistema inteligente, las personas que rompen el sistema de licencias nunca comprarían en primer lugar.

Es realmente fácil llevar esto demasiado lejos y tener un impacto negativo en sus clientes y su negocio, haga lo que sea simple y razonable y luego no se preocupe por eso.

Todo depende del lenguaje de programación que uses. Lea el artículo: Código ofuscado

Tuve que usar una protección de ofuscación / recurso en mi último proyecto y encontré Crypto Obfuscator como una herramienta agradable y fácil de usar. El problema de la serialización es solo una cuestión de configuración en esta herramienta.

Volver con la ofuscación de .Net 1.1 era esencial: descompilar el código era fácil, y se podía pasar del ensamblado, a IL, al código C # y volver a compilarlo con muy poco esfuerzo.

Ahora con .Net 3.5 no estoy del todo seguro. Intente descompilar un ensamblado 3.5; lo que obtienes está muy lejos de compilar.

Agregue las optimizaciones de 3.5 (mucho mejor que 1.1) y la forma en que los tipos anónimos, los delegados, etc., se manejan por reflexión (son una pesadilla recompilar). Agregue expresiones lambda, compiladores ''mágicos'' como linq-syntax y var , y C # 2 funciona como yield (que da como resultado nuevas clases con nombres ilegibles). Su código descompilado termina muy lejos de ser compilable.

Un equipo profesional con mucho tiempo aún podría realizar ingeniería inversa de nuevo, pero lo mismo es cierto para cualquier código ofuscado. El código que obtuvieron de eso sería imposible de mantener y es muy probable que tenga muchos errores.

Recomendaría firmar con clave sus ensamblados (lo que significa que si los piratas informáticos pueden recompilar uno, tienen que recompilarlos todos), pero no creo que la ofuscación valga la pena.

Crypto Obfuscator aborda todas sus preocupaciones y escenarios. Eso :

  1. Excluye automáticamente los tipos / miembros de la ofuscación según las reglas. Los tipos / campos serializados son uno de ellos.
  2. Se puede integrar en el proceso de compilación utilizando MSBUild.
  3. Soporta proyectos ASP.Net.