¿Qué tan efectiva es la ofuscación?

Question

Una pregunta diferente, es decir. Las mejores herramientas/estrategias de ofuscación de .NET, pregunta si la ofuscación es fácil de implementar utilizando herramientas.

Mi pregunta es, sin embargo, ¿Es efectiva la ofuscación? En un comentario respondiendo a esta respuesta, alguien dijo que "si te preocupa el robo de fuentes...la ofuscación es casi trivial para un cracker real".

He visto el resultado de la edición comunitaria de Dotfuscator:¡Y me parece ofuscado!¡No quisiera mantener eso!

Entiendo que simplemente "descifrar" software ofuscado puede ser relativamente fácil:porque solo necesita encontrar la ubicación en el software que implemente lo que desea descifrar (generalmente la protección de la licencia) y agregar un salto para omitirlo.

Sin embargo, si la preocupación es más que simplemente el crackeo por parte de un usuario final o un "pirata":si la preocupación es el "robo de fuente", es decirsi es un proveedor de software y su preocupación es que otro proveedor (un competidor potencial) realice ingeniería inversa en su fuente, que luego podría usar o agregar a su propio producto...¿Hasta qué punto la simple ofuscación es una protección adecuada o inadecuada contra ese riesgo?

---

1ra edición:

El código en cuestión tiene aproximadamente 20 KLOC y se ejecuta en las máquinas del usuario final (un control de usuario, no un servicio remoto).

Si la ofuscación realmente es "casi trivial para una verdadera galleta", me gustaría tener una idea de por qué es ineficaz (y no sólo "cuánto" no es efectivo).

---

2da edición:

No me preocupa que alguien invierta el algoritmo:más preocupados por su reutilización de lo real implementación del algoritmo (es decirel código fuente) en su propio producto.

Suponiendo que 20 KLOC es un trabajo de varios meses para desarrollarse, ¿se necesitaría más o menos que esto (varios meses) para desofuscarlo todo?

¿Es incluso necesario desofuscar algo para poder "robarlo"?¿O podría un competidor en su sano juicio simplemente incorporarlo al por mayor a su producto mientras aún está ofuscado, aceptar que tal como está es una pesadilla de mantenimiento y esperar que necesite poco mantenimiento?Si este escenario es Entonces, ¿existe la posibilidad de que el código .Net ofuscado sea más vulnerable a esto que el código de máquina compilado?

¿La mayor parte de la "carrera armamentista" de ofuscación está dirigida principalmente a evitar que las personas incluso "descifren" algo (por ejemplo,encontrar y eliminar el fragmento de código que implementa la protección/aplicación de licencias), más que para prevenir el 'robo de fuente'?

Answer 1

He discutido por eso no creo que la ofuscación es un medio eficaz de protección contra el agrietamiento aquí:
proteger el código .NET de la ingeniería inversa

Sin embargo, su pregunta es específicamente acerca de robo de fuente , que es un tema interesante. En el libro de Eldad Eiliams, " de marcha atrás: Secretos de ingeniería inversa ", el autor discute el robo de origen como una de las razones detrás de la ingeniería inversa en los dos primeros capítulos.

Básicamente, lo que se pretende es la única oportunidad que tienen de ser blanco para el robo de fuente es si tiene algún algoritmo muy específica, difícil de diseñar, relacionada con su dominio que le da una ventaja sobre su competencia. Esto es casi el único momento en que sería rentable para intentar aplicar ingeniería inversa a una pequeña porción de su aplicación.

Así que, a menos que tenga algún algoritmo de alto secreto que no quiere que su competencia tenga, usted no tiene que preocuparse por el robo de origen. El costo involucrado con inversión de una cantidad significativa de código fuente de su aplicación excede rápidamente el costo de volver a escribir desde cero.

Incluso si usted tiene algún algoritmo que no queremos que tengan, no hay mucho que se puede hacer para detener determinados individuos cualificados y de conseguir de todos modos (si la aplicación se está ejecutando en su máquina).

Algunas medidas contra-marcha atrás comunes son:

• Ofuscar - No hace mucho en términos de la protección de su origen o evitando que sea agrietada. Pero también podríamos no hacerlo totalmente fácil, ¿verdad?
• 3rd Party - Packers Themida es uno de los mejores. Packs un ejecutable en una aplicación Win32 cifrado. Evita la reflexión si la aplicación es una aplicación de .NET también.
• Packers de encargo - escritura veces su propio empaquetador si usted tiene la habilidad de hacerlo es efectiva porque hay muy poca información en la escena grietas sobre cómo desembalar su aplicación. Esto puede detener sin experiencia de RE. Este tutorial da una buena información sobre la escritura de su propio empaquetador.
• Mantenga algoritmos secretos de la industria de la máquina de los usuarios. Ejecutarlos como un servicio a distancia lo que las instrucciones no se ejecutan localmente. El único método "infalible" de protección.

Sin embargo, los envasadores se pueden desempaquetar, y la ofuscación en realidad no obstaculizan los que quieren ver lo que está haciendo la aplicación. Si el programa se ejecuta en la máquina de los usuarios, entonces es vulnerable.

Con el tiempo su código debe ser ejecutado como código de máquina y es normalmente una cuestión de disparar hasta depurador, el establecimiento de unos puntos de ruptura y el seguimiento de las instrucciones de ser ejecutado durante la acción correspondiente y algún tiempo pasó estudiando detenidamente estos datos.

---

Usted ha mencionado que le tomó varios meses para escribir ~ 20kLOC para su aplicación. Se necesitaría casi un orden de magnitud más largo para revertir los 20kLOC equivalente de la aplicación en la fuente viable si se toma las precauciones mínimo.

Es por esto que sólo es rentable para invertir, algoritmos específicos de la industria pequeños desde su aplicación. Cualquier otra cosa y no vale la pena.

Tome el siguiente ejemplo ficticio: Digamos que acaba de desarrollar una nueva solicitud de concurso para iTunes que tenían un montón de campanas y silbatos. Digamos que tardó varios LOC 100k y 2 años en desarrollarse. Una característica clave que tengo es una nueva manera de servir a la música que se basa fuera de su gusto para escuchar música.

Apple (siendo los piratas que son) se pone wind de esto y decide que realmente les gusta su música característica sugieren por lo que deciden revertirla. A continuación, perfeccionar, en el que sólo se algoritmo y los ingenieros inversa con el tiempo se van a plantear con un algoritmo que funciona y que sirve para arriba las sugerencias dadas equivalentes a los mismos datos. Luego se implementan dicho algoritmo en su propia aplicación, lo llaman "genio" y crea sus próximos 10 billones de dólares.

Así es como robo de fuente deja de funcionar.

Nadie se sentaba allí y revertir todo 100k LOC robar trozos significativos de su aplicación compilada. Simplemente sería demasiado costoso y consume mucho tiempo. Alrededor del 90% de las veces que estarían invirtiendo código aburrido, no la industria secreta que sólo maneja las pulsaciones de botones o entradas de usuario se maneja. En lugar de ello, podrían contratar a los desarrolladores de su propio re-escribir la mayor parte de cero por menos dinero y basta con invertir los algoritmos importantes que son difíciles de diseñar y que le dará una ventaja (es decir, la música característica sugiere).

Answer 2

La ofuscación es una forma de seguridad a través de la oscuridad, y si bien brinda cierta protección, la seguridad es obviamente bastante limitada.

Para los propósitos que usted describe, la oscuridad ciertamente puede ayudar y, en muchos casos, es una protección adecuada contra el riesgo de robo de código.Sin embargo, todavía existe el riesgo de que el código no se confunda si se le dedica suficiente tiempo y esfuerzo.Despejar todo el código base sería efectivamente imposible, pero si una parte interesada solo desea determinar cómo realizó cierta parte de su implementación, los riesgos son mayores.

Al final, sólo usted puede determinar si el riesgo vale la pena para usted o su empresa.Sin embargo, en muchos casos, esta es la única opción que tiene si desea vender su producto a los clientes para que lo utilicen en sus propios entornos.

Con respecto a "por qué es ineficaz", la razón es que un cracker puede usar un depurador para ver dónde se ejecuta su código, independientemente de la técnica de ofuscación que se utilice.Luego pueden usar esto para evitar cualquier mecanismo de protección que haya implementado, como un número de serie o un sistema de "llamada a casa".

No creo que el comentario realmente hiciera referencia al "robo de código" en el sentido de que su código será robado y utilizado en otro proyecto.Como usaron la palabra "cracker", creo que estaban hablando de "robo" en términos de piratería de software.Los crackers se especializan en evitar mecanismos de protección;no están interesados ​​en utilizar su código fuente para ningún otro propósito.

Answer 3

La mayoría de la gente tiende a escribir lo que parece estar ofuscado código y que no ha dejado las galletas así que cuál es la diferencia?

EDIT:

Ok, el tiempo seria. Si realmente quiere hacer algo que es difícil de romper, mira en la codificación polimórfico (que no debe confundirse con el polimorfismo). Hacer que el código que se auto-mutante, y es un grave dolor de romper y los mantendrá adivinando.

http://en.wikipedia.org/wiki/Polymorphic_code

Al final, nada es imposible realizar ingeniería inversa.

Answer 4

Usted está preocupado por la gente que roba los algoritmos específicos utilizados en su producto. O se está href="http://www.fairisaac.com/" Fair Isaac o necesita para diferenciarse utilizando más de la forma en que x ++ ;. Si usted ha resuelto algún problema en el código que no puede ser resuelto por alguien más desconcertante sobre ella durante unas horas, usted debe tener un doctorado en ciencia y / o patentes computadora para proteger su invención. 99% de los productos de software son un no éxito o especial debido a los algoritmos. Ellos tienen éxito debido a que sus autores hicieron el trabajo pesado para armar bien conocido y fácil de entender conceptos en un producto que hace lo que sus clientes necesitan y lo venden más barato de lo que costaría a pagar a otros para volver a hacer lo mismo.

Answer 5

a ver de esta manera; el editor de armas de destrucción masiva que ha escrito en su pregunta fue ingeniería inversa por el equipo de SO con el fin de corregir algunos errores y hacer las mejoras som. Ese código fue ofuscado. Usted nunca va a parar a la gente motivada inteligentes de la piratería de su código, lo mejor que puede esperar es mantener a la gente honesta honesto y hacer que sea un poco difícil de romper.

Answer 6

Si alguna vez has visto la salida de un desensamblador, se daría cuenta por qué la ofuscación siempre fallará.

Answer 7

tiendo a pensar que la ofuscación realmente no es muy eficaz si usted quiere proteger su fuente. Para el experto real en el campo (no me refiero a un experto en software aquí o una galleta, me refiero al experto en el campo de la funcionalidad del código), por lo general él o ella no tiene que ver el código, simplemente ver cómo reacciona contra entradas especiales, casos extremos, etc., para tener una idea de cómo poner en práctica una copia o un código que es equivalente a la funcionalidad protegida. Por lo tanto, no es muy útil en la protección de sus habilidades.

Answer 8

Si usted tiene IP en el código que debe ser protegido a toda costa, entonces usted debe hacer la funcionalidad de su software disponible como un servicio, en un servidor remoto seguro.

Buena ofuscación le protegerá hasta cierto punto, pero es todo acerca de la cantidad de esfuerzo necesario para romperlo en contra de la 'recompensa' de tener el código. Si usted está hablando acerca de detener el usuario empresarial medio, a continuación, un Ofuscador comercial debería ser suficiente.

Answer 9

Respuesta corta es sí y no; que depende enteramente de lo que está tratando de evitar. Sección doce de programación segura Cookbook tiene algunos comentarios interesantes sobre esto en la página 653 (que está convenientemente disponible en google libros de vista previa). Clasifica contra la manipulación en cuatro categorías: Cero días (ralentizando un atacante por lo que los lleva un largo tiempo para lograr lo que quieren), la protección de un algoritmo patentado para evitar la ingeniería inversa, "porque puedo" ataques y lo que pueda' t recordar el cuarto uno. Usted tiene que preguntarse qué estoy tratando de prevenir, y si usted está realmente preocupado por un individuo conseguir un vistazo a su código fuente a continuación, la ofuscación tiene algún valor. Se utiliza por sí mismo por lo general es sólo una molestia a alguien que intenta meterse con su aplicación y, como cualquier buena medida de seguridad que funciona mejor cuando se usa en combinación con otras técnicas contra la manipulación.