¿La ofuscación del código .NET realmente lo vale?

Question

Por lo que he leído, la ofuscación de código no es tan difícil de "descifrar", y solo retrasará lo inevitable. En ese caso, ¿cuál es su propósito?

Si alguien realmente quiere robar su fuente, puede.

Si alguien necesita ver su código fuente para fines inofensivos/útiles, no pueden hacerlo.

Probablemente no deba almacenar nada sensible en el código, por lo que no debería ser un problema.

Si no se ofusca, aún no proporciona el código fuente completo, por lo que podría vender una "licencia de código fuente".

Lo curioso es que el único código que he visto ofuscado es el código terrible que tiene errores. La única razón por la que necesito ver el código es descubrir cuál es el problema y qué puedo hacer para solucionarlo.

Por ejemplo, necesito reemplazar algunas de las imágenes en ASPDotNetStoreFront. Cuando busqué la ubicación de las etiquetas, descubrí que estaban contenidas dentro del código compilado. MIERDA. Así que pensé que descompilaría el código, para descubrir qué etiquetas de img reemplazar a través de Regex. Traté de ver el código fuente para ver qué imágenes podrían provenir del método compilado, y el reflector no puede manejarlo, supongo que por ofuscación. Realmente no tengo tiempo para ir a buscar de-comilers/de-ofuscadores.

Answer 1

Creo que vale la pena. El costo para usted es virtualmente nada, y hace que la vida del pirata informático sea mucho más difícil. Incluso si lo descifran, tiene la satisfacción de saber que perdió en varias horas o varias semanas de su vida. El hecho de que un candado no sea perfecto no significa que no bloquee sus puertas.

Answer 2

No sé si vale la pena ofuscar, pero puedo decir que hay otras formas de ofuscación que son más seguras.

XHEO, por ejemplo, proporciona una herramienta (CodeVeil) para cifrar realmente ensamblados .NET, en lugar de simplemente ofuscarlos.

Answer 3

Solo si su proyecto es de larga duración y le tomaría a alguien una gran cantidad de tiempo implementarlo, vale la pena. Esta es, por supuesto, una opinión aquí, pero no he encontrado una .Net DLL ofuscada, pero no pude entender qué está pasando usando solo Reflector.

Es un disuasivo, nada más. Si el costo de una ingeniería inversa de su código es mayor que el costo de implementarlo por sí mismo, ese es el único caso legítimo que veo para él, pero si alguien quiere ver cómo funciona su código, no es muy bueno para evitarlo.

Un caso común que veo mucho es cómo se produce y/o descifra una clave de licencia. Cualquiera que esté motivado para resolver esto y cavar en un reflector para sus métodos de sal/desencriptación no va a ser detenido por la ofuscación, me atrevería a decir que tampoco los ralentizará mucho.

Answer 4

En mi opinión, no. He visto chicos hackear programas escritos en diferentes idiomas. Con herramientas profesionales como IDA (funciona para código no administrado), nada es 100% seguro. Las asambleas ofuscadas son aún más fáciles de hackear debido a los metadatos que aún están presentes.

Answer 5

Para aplicaciones .Net, NO ofuscar equivale a hacer que su producto sea de código abierto, ya que es muy fácil de ver y analizar el código fuente utilizando Reflector. Puede tener un acuerdo de licencia, pero solo unas pocas compañías tienen el tiempo y el dinero para defender el acuerdo de licencia ante el tribunal. Para tales compañías, la ofuscación es la mejor opción. Claro, debe probar los ensamblajes ofuscados, pero luego, ya está probando su producto, entonces, ¿por qué no probar las asambleas ofuscadas finales?

También depende de qué tan útil sea el ofuscador.Considere nuestro Crypto Obfuscator - admite una fácil integración con Visual Studio para que siempre esté ejecutando ensamblajes ofuscados. También tiene muchas exclusiones automáticas por lo que no ofuscará las clases/miembros, lo que provocará que el ensamblaje ofuscado se ejecute incorrectamente. También mostrará advertencias (incluido el número de línea) para el código que puede provocar que el ensamblaje ofuscado se ejecute incorrectamente. Este es un gran ahorro de tiempo.

Answer 6

Por supuesto, nada está 100% protegido. Pero no ofuscar por esa razón es como no cerrar la puerta de su casa porque "cualquier ladrón determinado puede abrirlo de todos modos". ¡Usted cierra la puerta de todos modos!

Creo que la principal amenaza es que algún tipo descompile su aplicación usando ildasm, detectando oraciones de SQL, manipulándolas y luego compilándolas nuevamente. De esta manera, él/ella puede eliminar restricciones y obtener una lista completa de clientes, como ejemplo, o simplemente hacer un daño simple.

Usted, como el proveedor de la aplicación, será responsable en el primer lugar ...

tipos de BitHelmet lo explican bastante bien en http://www.bithelmet.com/Overview.html.

Trabajé en una compañía de tarjetas de crédito de tamaño mediano hace algunos años. Hubo tres robos (grandes cantidades de dinero) involucrando empleados que sabíamos, y todos ellos no fueron realizados por un pirata informático ruso o chino de clase mundial, sino por empleados que simplemente crecieron lo suficiente de la programación que hicieron solo un poco giros al software de cajeros.

Yo era un junior entonces :), mi jefe tuvo que lidiar con eso. Siempre me pregunto cuántos de estos robos nunca se descubrieron ;-). Podría haberlo hecho, ¡pero nunca lo hice!

De hecho, debe pensar en algún nivel de protección, y debe considerar en el ataque interno. Y hará la vida más difícil para el enginner inverso determinado también.