.net - ofuscar - persona ofuscada
¿Qué tan efectiva es la ofuscación? (9)
La mayoría de la gente tiende a escribir lo que parece ser un código ofuscado y eso no ha detenido a las galletas, ¿cuál es la diferencia?
EDITAR:
Ok, es un momento serio. Si realmente quieres hacer algo que sea difícil de romper, investiga la codificación polimórfica (que no debe confundirse con el polimorfismo). Haga un código que se mute por sí mismo, y es un dolor grave romperlo y los mantendrá adivinando.
http://en.wikipedia.org/wiki/Polymorphic_code
Al final, nada es imposible de aplicar ingeniería inversa.
Una pregunta diferente, es decir, las mejores herramientas / estrategias de ofuscación de .NET , pregunta si la ofuscación es fácil de implementar usando herramientas.
Mi pregunta es, ¿ es efectiva la ofuscación? En un comentario que respondía a esta respuesta , alguien dijo que " si te preocupa el robo de la fuente ... la ofuscación es casi trivial para una verdadera galleta ".
He visto el resultado de Community Edition of Dotfuscator: ¡y me parece ofuscado! ¡No me gustaría mantener eso!
Entiendo que el software oculto ''crackeando'' puede ser relativamente fácil: porque solo necesita encontrar la ubicación del software que implemente lo que sea que quiera descifrar (generalmente la protección de la licencia) y agregar un salto para omitir eso.
Si la preocupación es más que un simple crackeo de un usuario final o un "pirata": si la preocupación es "robo de origen", es decir, si usted es un vendedor de software y su preocupación es que otro proveedor (un competidor potencial) reverso ingeniería de su fuente, que luego podrían usar o agregar a su propio producto ... ¿en qué medida la simple ofuscación es una protección adecuada o inadecuada contra ese riesgo?
1ra edición:
El código en cuestión es de aproximadamente 20 KLOC que se ejecuta en máquinas de usuario final (un control de usuario, no un servicio remoto).
Si la ofuscación realmente es " casi trivial para un cracker real ", me gustaría obtener una idea de por qué es ineficaz (y no solo "cuánto" no es efectivo).
2da edición:
No me preocupa que alguien revierte el algoritmo: está más preocupado por el hecho de que reutilicen la implementación real del algoritmo (es decir, el código fuente) en su propio producto.
Suponiendo que 20 KLOC es un trabajo de varios meses para desarrollar, ¿tomaría más o menos de esto (varios meses) desofuscarlo todo?
¿Es necesario desofuscar algo para ''robarlo''? ¿O un competidor sensato simplemente lo incorpora al por mayor en su producto mientras aún está ofuscado, lo acepta como una pesadilla de mantenimiento y espera que necesite poco mantenimiento? Si este escenario es una posibilidad, ¿está ofuscado el código .Net más vulnerable a esto que el código máquina compilado?
¿La mayor parte de la ofuscación "carrera armamentista" está dirigida principalmente a impedir que las personas incluso "rompan" algo (por ejemplo, encontrar y borrar el fragmento de código que implementa la protección / aplicación de licencias), más que prevenir el "robo de fuentes"?
La ofuscación es una forma de seguridad a través de la oscuridad , y si bien proporciona cierta protección, la seguridad es obviamente bastante limitada.
Para los fines que describe, la oscuridad puede ayudar, y en muchos casos, es una protección adecuada contra el riesgo de robo de código. Sin embargo, aún existe el riesgo de que el código "no se difunda" con suficiente tiempo y esfuerzo. Descomponer la base del código completo 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, solo usted puede determinar si el riesgo vale la pena para usted o su negocio. Sin embargo, en muchos casos, esta es la única opción que tiene si desea vender su producto a los clientes para usarlo en sus propios entornos.
En cuanto al "por qué es ineficaz", la razón es porque un cracker puede usar un depurador para ver dónde se ejecuta el código, independientemente de la técnica de ofuscación que se use. A continuación, pueden usar esto para evitar cualquier mecanismo de protección que haya implementado, como un número de serie o un sistema de "teléfono a domicilio".
No creo que el comentario se refiriera realmente al "robo de código" en el sentido de que su código será robado y utilizado en otro proyecto. Debido a que usaron la palabra "cracker", creo que estaban hablando de "robo" en términos de piratería de software. Los crackers se especializan en trabajar en torno a los mecanismos de protección; no están interesados en usar su código fuente para otro propósito.
La respuesta corta es sí y no; depende completamente de lo que estás tratando de prevenir. La sección doce del libro de cocina de programación segura contiene algunos comentarios interesantes sobre esto en la página 653 (que convenientemente no está disponible en la vista previa de libros de google). Clasifica antimanipulación en cuatro categorías: día cero (ralentizar a un atacante, por lo que tarda mucho tiempo en lograr lo que quiere), protección de un algoritmo patentado para evitar la ingeniería inversa, "porque puedo" y "puedo". Recuerdo el 4to. Tienes que preguntarte qué estoy tratando de evitar, y si realmente te preocupa que una persona vea tu código fuente, la ofuscación tiene algún valor. Si se usa solo, suele ser una molestia para alguien que intenta meterse con su aplicación y, como cualquier medida de seguridad, funciona mejor cuando se usa en combinación con otras técnicas antimanipulación.
Míralo de esta manera; el editor de WMD en el que escribió su pregunta fue sometido a ingeniería inversa por parte del equipo de SO para corregir algunos errores y hacer algunas mejoras. Ese código estaba ofuscado. Nunca evitará que personas motivadas e inteligentes pirateen su código, lo mejor que puede esperar es mantener a la gente honesta honesta y hacer que sea algo difícil de romper.
Si alguna vez ha visto la salida de un desensamblador, se daría cuenta de por qué la ofuscación siempre fallará.
Si tiene un código IP que debe protegerse a toda costa, debe hacer que la funcionalidad de su software esté disponible como servicio en un servidor remoto seguro.
Una buena ofuscación lo protegerá hasta cierto punto, pero se trata de la cantidad de esfuerzo requerido para romperlo frente a la "recompensa" de tener el código. Si está hablando de detener a un usuario comercial promedio, entonces un ofuscador comercial debería ser suficiente.
Tiendo a pensar que la ofuscación realmente no es muy efectiva si quieres proteger tu fuente. Para el verdadero experto en el campo (no me refiero a un experto en software aquí o un cracker, me refiero al experto en el campo de la funcionalidad del código), generalmente no necesita ver el código, solo ver cómo reacciona frente a entradas especiales, casos límite, etc., para tener una idea de cómo implementar una copia o un código que sea equivalente a esa funcionalidad protegida. Por lo tanto, no es muy útil para proteger sus conocimientos.
Le preocupa que las personas roben los algoritmos específicos utilizados en su producto. O eres Fair Isaac o necesitas diferenciarte utilizando más de la forma en que x ++ ;. Si resolvió algún problema en el código que no puede ser resuelto por otra persona desconcertante durante unas horas, debe tener un doctorado en ciencias de la computación y / o patentes para proteger su invención. El 99% de los productos de software no son exitosos o especiales debido a los algoritmos. Tienen éxito porque sus autores hicieron un gran trabajo para juntar conceptos bien conocidos y de fácil comprensión en un producto que hace lo que sus clientes necesitan y lo venden por un precio más bajo de lo que costaría pagar a otros para volver a hacer lo mismo.
He discutido por qué no creo que la Ofuscación sea un medio efectivo de protección contra el agrietamiento aquí:
Protege el código .NET de la ingeniería inversa
Sin embargo, su pregunta es específicamente sobre el robo de fuente , que es un tema interesante. En el libro de Eldad Eiliams, " Inversión: secretos de la ingeniería inversa ", el autor analiza el robo de fuentes como una de las razones detrás de la ingeniería inversa en los dos primeros capítulos.
Básicamente, a lo que se reduce es a la única posibilidad que tiene de ser blanco de robo de fuente si tiene algún algoritmo muy específico y difícil de diseñar relacionado con su dominio que le brinde ventaja sobre su competencia. Esta es casi la única vez que sería rentable intentar realizar ingeniería inversa en una pequeña parte de su aplicación.
Entonces, a menos que tenga algún algoritmo de alto secreto que no quiera que tenga su competencia, no necesita preocuparse por el robo de la fuente. El costo de revertir cualquier cantidad significativa de código fuente de su aplicación excede rápidamente el costo de volver a escribirlo desde cero.
Incluso si tiene algún algoritmo que no desea que tengan, no hay mucho que pueda hacer para evitar que personas determinadas y capacitadas lo obtengan de todos modos (si la aplicación se está ejecutando en su máquina).
Algunas medidas antirreversión comunes son:
- Ofuscación: no hace mucho en términos de proteger su fuente o evitar que se rompa. Pero también podríamos no hacerlo totalmente fácil, ¿verdad?
- Empacadores de terceros : Themida es uno de los mejores. Empaqueta un ejecutable en una aplicación win32 cifrada. Evita la reflexión si la aplicación también es una aplicación .NET.
- Custom Packers: a veces escribir su propio empacador si tiene la habilidad para hacerlo es efectivo porque hay muy poca información en la escena de cracking sobre cómo desempaquetar su aplicación. Esto puede detener las RE sin experiencia. Este tutorial brinda buena información sobre cómo escribir su propio empacador.
- Mantenga los algoritmos secretos de la industria fuera de la máquina de los usuarios. Ejecútelos como un servicio de eliminación para que las instrucciones nunca se ejecuten localmente. El único método de protección "infalible".
Sin embargo, los empacadores se pueden desempaquetar, y la ofuscación en realidad no obstaculiza a aquellos que quieren ver lo que su aplicación está haciendo. Si el programa se ejecuta en la máquina de los usuarios, entonces es vulnerable.
Eventualmente, su código debe ejecutarse como código máquina y normalmente se trata de activar el depurador, establecer algunos puntos de interrupción y monitorear las instrucciones que se ejecutan durante la acción relevante y algún tiempo dedicado a estudiar detenidamente estos datos.
Mencionaste que te tomó varios meses escribir ~ 20kLOC para tu aplicación. Tomaría casi un orden de magnitud más para revertir esos 20kLOC equivalentes de su aplicación a una fuente viable si tomara las mínimas precauciones.
Esta es la razón por la cual es rentable invertir los pequeños algoritmos específicos de la industria de su aplicación. Cualquier otra cosa y no vale la pena.
Tomemos el siguiente ejemplo de ficción: digamos que acabo de desarrollar una nueva aplicación de la competencia para iTunes que tenía un montón de campanas y silbatos. Digamos que tomó varios 100k LOC y 2 años para desarrollarse. Una característica clave que tengo es una nueva forma de ofrecerle música en función de su gusto por escuchar música.
Apple (siendo los piratas que son) se entera de esto y decide que realmente les gusta su característica de música sugerida por lo que deciden revertirla. A continuación, perfeccionarán solo ese algoritmo y los ingenieros inversos eventualmente obtendrán un algoritmo viable que sirva las sugerencias equivalentes con los mismos datos. Luego implementan dicho algoritmo en su propia aplicación, lo llaman "Genius" y obtienen sus próximos 10 billones de dólares.
Así es como el robo de fuentes disminuye.
Nadie se sentaría allí y revertiría todos los 100k LOC para robar fragmentos significativos de su aplicación compilada. Simplemente sería demasiado costoso y consumiría demasiado tiempo. Alrededor del 90% del tiempo invertirían un código aburrido, no secreto por la industria, que simplemente manejaba presiones de botones o manejaba la entrada del usuario. En cambio, podrían contratar desarrolladores propios para volver a escribir la mayor parte desde cero por menos dinero y simplemente invertir los algoritmos importantes que son difíciles de diseñar y que le dan una ventaja (es decir, la función de sugerencia de música).