¿Proteger el ejecutable de la ingeniería inversa?

210

He estado contemplando cómo proteger mi código C / C ++ del desmontaje y la ingeniería inversa. Normalmente nunca aprobaría este comportamiento en mi código; sin embargo, el protocolo actual en el que he estado trabajando nunca debe ser inspeccionado o comprensible, para la seguridad de varias personas.

Ahora, este es un tema nuevo para mí, e Internet no es realmente ingenioso para la prevención contra la ingeniería inversa, sino que representa toneladas de información sobre cómo realizar ingeniería inversa.

Algunas de las cosas que he pensado hasta ahora son:

  • Inyección de código (llamar a funciones ficticias antes y después de llamadas a funciones reales)
  • Obfusticación de código (destruye el desmontaje del binario)
  • Escribir mis propias rutinas de inicio (más difícil para que los depuradores se unan)

    void startup();  
    int _start()   
    {  
        startup( );  
        exit   (0)   
    }  
    void startup()  
    {  
        /* code here */  
    }
  • Verificación de tiempo de ejecución para depuradores (y forzar la salida si se detecta)

  • Función trampolines

     void trampoline(void (*fnptr)(), bool ping = false)  
     {  
       if(ping)  
         fnptr();  
       else  
         trampoline(fnptr, true);  
     }
  • Asignaciones y desasignaciones sin sentido (la pila cambia mucho)

  • Llamadas ficticias y trampolines sin sentido (toneladas de saltos en la salida de desmontaje)
  • Toneladas de fundición (para desmontaje ofuscado)

Quiero decir, estas son algunas de las cosas en las que he pensado, pero todos pueden ser resueltos o resueltos por analistas de código con el plazo adecuado. ¿Hay alguna otra alternativa que tenga?

grafito maestro
fuente
172
"Sin embargo, el protocolo actual en el que he estado trabajando nunca debe ser inspeccionado o comprensible, para la seguridad de varias personas". -- buena suerte con eso.
Ámbar
62
Puede hacer que su aplicación sea difícil de realizar ingeniería inversa. No puedes hacerlo imposible, siempre y cuando el otro tipo tenga una parte sustancial de tus bits en sus manos. Tenga cuidado de garantizar la seguridad total, especialmente si hay vidas en juego: no puede cumplir.
Michael Petrotta
127
Si su computadora puede entender el código, también lo puede hacer una persona.
Carreras de ligereza en órbita
78
Haga que el código sea de código abierto, y nadie realizará ingeniería inversa.
usuario desconocido
28
"La seguridad por oscuridad nunca funcionó".
bot47

Respuestas:

151

Lo que Amber dijo es exactamente correcto. Puede dificultar la ingeniería inversa, pero nunca puede evitarla. Nunca debe confiar en la "seguridad" que se basa en la prevención de la ingeniería inversa .

Dicho esto, las mejores técnicas contra la ingeniería inversa que he visto se centraron no en ofuscar el código, sino en romper las herramientas que la gente suele usar para comprender cómo funciona el código. Encontrar formas creativas para romper desensambladores, depuradores, etc. es probable que sea más efectivo y también más satisfactorio intelectualmente que solo generar resmas de horrible código de espagueti. Esto no hace nada para bloquear a un atacante determinado, pero aumenta la probabilidad de que J Random Cracker se aleje y trabaje en algo más fácil.

Stephen Canon
fuente
14
Entiendo esto, y he leído algunos documentos sobre la seguridad de Skype y he estado contemplando las mismas ideas que Skype ya ha probado como método para no prevenir sino proteger mi protocolo. Algo que ha demostrado ser lo suficientemente valioso dadas las obvias circunstancias de Skype.
Graphitemaster
8
Skype es en realidad el primer ejemplo que se me ocurrió, así que me alegro de que ya estés buscando emular sus métodos.
Ricket
176

pero todos pueden ser resueltos y / o resueltos por analistas de código dado el marco de tiempo correcto.

Si le das a las personas un programa que pueden ejecutar, también podrán realizar ingeniería inversa en él con el tiempo suficiente. Esa es la naturaleza de los programas. Tan pronto como el binario esté disponible para alguien que quiera descifrarlo, no puede evitar la ingeniería inversa eventual. Después de todo, la computadora tiene que poder descifrarlo para poder ejecutarlo, y un humano es simplemente una computadora más lenta.

Ámbar
fuente
113
+1. Lea sobre los días de gloria de la protección de copia en el Apple II, la guerra cada vez mayor entre los ofuscadores y los crackers, los trucos locos con el motor paso a paso del disquete y las instrucciones indocumentadas 6502 y así sucesivamente ... Y luego llore a sí mismo duerme, porque no vas a implementar nada tan elaborado y todos finalmente se resquebrajaron.
Nemo
2
Es más fácil usar un simulador y obtener una mejor visibilidad que intentar realizar ingeniería inversa visualmente o con un desensamblador. Si la seguridad no está integrada en el hardware que está utilizando, creo que el mundo tiene un promedio de dos días a dos semanas para realizar ingeniería inversa y derrotar prácticamente todo lo que sale. Si le lleva más de dos días crear e implementar esto, ha pasado demasiado tiempo.
old_timer
55
El único DRM que funciona razonablemente hoy es la combinación de una clave y un servidor de Internet que verifica que solo una instancia de la clave esté activa a la vez.
Thorbjørn Ravn Andersen
2
@Rotsor: La computadora no puede entenderlo porque no hemos podido reducir este tipo de inteligencia a un algoritmo (todavía), no porque haya algún tipo de barrera física o tecnológica. El humano puede entenderlo porque puede hacer cualquier cosa que la computadora pueda (aunque sea más lento) así como razonar .
Adam Robinson
3
En ese momento, alguien intentará realizar ingeniería inversa en la computadora, a menos que solo esté disponible en un entorno que usted controle.
ámbar
41

Safe Net Sentinel (anteriormente Aladdin). Sin embargo, las advertencias: su API apesta, la documentación apesta, y ambas son excelentes en comparación con sus herramientas SDK.

He usado su método de protección de hardware ( Sentinel HASP HL ) durante muchos años. Requiere un llavero USB patentado que actúa como la 'licencia' para el software. Su SDK encripta y ofusca su archivo ejecutable y sus bibliotecas, y le permite vincular diferentes funciones de su aplicación con las funciones grabadas en la clave. Sin una llave USB provista y activada por el licenciante, el software no puede descifrar y, por lo tanto, no se ejecutará. The Key incluso utiliza un protocolo de comunicación USB personalizado (fuera de mi ámbito de conocimiento, no soy un controlador de dispositivo) para dificultar la creación de una clave virtual o alterar la comunicación entre la envoltura de tiempo de ejecución y la clave. Su SDK no es muy amigable para el desarrollador y es bastante doloroso integrar la adición de protección con un proceso de compilación automatizado (pero posible).

Antes de implementar la protección HASP HL, había 7 piratas conocidos que habían eliminado las 'protecciones' de dotfuscator del producto. Agregamos la protección HASP al mismo tiempo que una actualización importante del software, que realiza algunos cálculos pesados ​​en video en tiempo real. Lo mejor que puedo decir del perfil y la evaluación comparativa, la protección HASP HL ​​solo disminuyó los cálculos intensivos en aproximadamente un 3%. Desde que se lanzó ese software hace unos 5 años, no se ha encontrado un nuevo pirata del producto. El software que protege tiene una gran demanda en su segmento de mercado, y el cliente es consciente de que varios competidores están tratando activamente de realizar ingeniería inversa (hasta ahora sin éxito). Sabemos que han intentado solicitar ayuda de algunos grupos en Rusia que anuncian un servicio para romper la protección del software,

Recientemente probamos su solución de licencia de software (HASP SL) en un proyecto más pequeño, que era lo suficientemente sencillo como para funcionar si ya está familiarizado con el producto HL. Parece funcionar; no se han reportado incidentes de piratería, pero este producto tiene una demanda mucho menor.

Por supuesto, ninguna protección puede ser perfecta. Si alguien está suficientemente motivado y tiene mucho dinero para gastar, estoy seguro de que las protecciones que ofrece HASP podrían eludirse.

RyanR
fuente
19
Nota para el moderador: Los comentarios de esta respuesta se han eliminado debido a la desviación del ruido antagónico.
Tim Post
2
+1 por experiencia, pero me gustaría repetir que no es perfecto. Maya (suite 3D) usó un dongle de hardware (no estoy seguro si era HASP), lo que no disuadió a los piratas por mucho tiempo. Cuando hay voluntad hay un camino.
Robert Fraser
1
AutoCAD utiliza un sistema similar, que ha sido descifrado en numerosas ocasiones. HASP y otros similares mantendrán a la gente honesta honesta y evitarán la piratería casual. Si está creando el próximo producto de diseño de miles de millones de dólares, siempre tendrá galletas con las que lidiar. Se trata de rendimientos decrecientes: cuántas horas de esfuerzo vale la pena romper su protección de software en lugar de solo pagarla.
RyanR
66
También quiero intervenir desde la perspectiva de alguien que ha utilizado el software seguro HASP. Los HASP son un dolor real para el usuario final . He tratado con un Dallas iButton y un Aladdin HASP, y ambos estaban realmente defectuosos, y causaron que el software dejara de funcionar aleatoriamente, lo que requería desconectar y volver a conectar el HASP.
Nombre falso
44
Además, vale la pena señalar que las medidas de seguridad de HASP no son necesariamente más seguras que la ofuscación de código: seguro que requieren una metodología diferente para realizar ingeniería inversa, pero es muy posible revertirlas. Consulte: flylogic.net/blog/?p=14 flylogic.net/blog/?p=16 flylogic.net/blog/?p=11
Nombre falso
22

Los mejores trucos contra el desensamblador, en particular en conjuntos de instrucciones de longitud de palabra variable, están en código ensamblador / máquina, no C. Por ejemplo

CLC
BCC over
.byte 0x09
over:

El desensamblador tiene que resolver el problema de que un destino de sucursal es el segundo byte en una instrucción de varios bytes. Sin embargo, un simulador de conjunto de instrucciones no tendrá ningún problema. La ramificación a direcciones calculadas, que puede causar desde C, también hace que el desmontaje sea difícil o imposible. El simulador de conjunto de instrucciones no tendrá ningún problema. El uso de un simulador para ordenar los destinos de las sucursales puede ayudarlo en el proceso de desmontaje. El código compilado es relativamente limpio y fácil para un desensamblador. Así que creo que se requiere un poco de montaje.

Creo que fue cerca del comienzo del Zen of Assembly Language de Michael Abrash, donde mostró un simple truco anti desensamblador y anti-depurador. El 8088/6 tenía una cola de captación previa, lo que hizo fue tener una instrucción que modificó la siguiente instrucción o un par más adelante. Si realizó un solo paso, ejecutó la instrucción modificada, si su simulador de conjunto de instrucciones no simuló completamente el hardware, ejecutó la instrucción modificada. En el hardware real que se ejecuta normalmente, la instrucción real ya estaría en la cola y la ubicación de la memoria modificada no causaría ningún daño siempre que no ejecute esa cadena de instrucciones nuevamente. Probablemente aún podría usar un truco como este hoy, ya que los procesadores canalizados obtienen la siguiente instrucción. O bien, si sabe que el hardware tiene una memoria caché de instrucciones y datos separada, puede modificar una cantidad de bytes por delante si alinea este código en la línea de la memoria caché correctamente, el byte modificado no se escribirá a través de la memoria caché de instrucciones sino de la memoria caché de datos, y un simulador de conjunto de instrucciones que no tenía simuladores de caché adecuados no se ejecutaría correctamente. Creo que las soluciones de solo software no te llevarán muy lejos.

Los anteriores son antiguos y bien conocidos, no sé lo suficiente sobre las herramientas actuales para saber si ya funcionan alrededor de esas cosas. El código de auto modificación puede / disparará el depurador, pero el humano puede / reducirá el problema y luego verá el código de auto modificación y lo solucionará.

Solía ​​ser que los piratas informáticos tardarían unos 18 meses en resolver algo, por ejemplo, DVD. Ahora tienen un promedio de alrededor de 2 días a 2 semanas (si está motivado) (blue ray, iphones, etc.). Para mí, eso significa que si paso más de unos días en seguridad, probablemente pierda mi tiempo. La única seguridad real que obtendrá es a través del hardware (por ejemplo, sus instrucciones están encriptadas y solo el núcleo del procesador dentro del chip se descifra justo antes de la ejecución, de manera que no pueda exponer las instrucciones descifradas). Eso podría comprarte meses en lugar de días.

Además, lea el libro de Kevin Mitnick El arte del engaño. Una persona así podría levantar un teléfono y hacer que usted o un compañero de trabajo entreguen los secretos al sistema pensando que es un gerente u otro compañero de trabajo o ingeniero de hardware en otra parte de la empresa. Y su seguridad está en peligro. La seguridad no se trata solo de administrar la tecnología, también debe administrar a los humanos.

viejo contador de tiempo
fuente
1
Además, no tiene que tener acceso al código fuente (o incluso al código fuente desmontado) para encontrar un agujero de seguridad. Podría ser por accidente o al usar el hecho de que la mayoría de los agujeros provienen de los mismos problemas en el código (como desbordamientos del búfer).
Asmeurer
2
Hay grandes problemas con el código auto modificable. La mayoría de los sistemas operativos / hardware modernos no le permitirán hacerlo sin un privilegio muy alto, puede haber problemas de caché y el código no es seguro para subprocesos.
Martin James
1
Con los procesadores x86 modernos, los trucos como estos a menudo son malos para el rendimiento. Usar la misma ubicación de memoria como parte de más de una instrucción probablemente tenga un efecto similar a una rama mal predicha. El código de auto modificación hace que el procesador descarte las líneas de caché para mantener la coherencia entre la instrucción y los cachés de datos (si ejecuta el código modificado con mucha más frecuencia de la que lo modifica, aún puede ser una ganancia).
jilles
2
Me encontré con esto hace 20 años. Nos llevó casi media hora descubrir qué pasó. No muy bueno si necesita protección más larga.
Bo Persson
1
"la instrucción real ya estaría en la cola y la ubicación de la memoria modificada no causaría ningún daño" Hasta que se produzca una interrupción en el medio, vaciando la canalización de instrucciones y haciendo que el nuevo código sea visible. Ahora su ofuscación ha causado un error para sus usuarios legítimos.
Ben Voigt
21

Tomemos, por ejemplo, el algoritmo AES . Es un algoritmo muy, muy público, y es MUY seguro. ¿Por qué? Dos razones: ha sido revisado por muchas personas inteligentes, y la parte "secreta" no es el algoritmo en sí mismo; la parte secreta es la clave, que es una de las entradas al algoritmo. Es un enfoque mucho mejor para diseñar su protocolo con un "secreto" generado que está fuera de su código, en lugar de hacer que el código sea secreto. El código siempre se puede interpretar sin importar lo que haga, y (idealmente) el secreto generado solo se puede poner en peligro por un enfoque de fuerza bruta masivo o por robo.

Creo que una pregunta interesante es " ¿Por qué quieres ofuscar tu código?" ¿Quieres dificultar a los atacantes descifrar tus algoritmos? ¿Para que sea más difícil para ellos encontrar errores explotables en su código? No necesitaría ofuscar el código si el código fuera indescifrable en primer lugar. La raíz del problema es el software descifrable. Arregle la raíz de su problema, no lo ofusque.

Además, cuanto más confuso sea su código, más difícil será para USTED encontrar errores de seguridad. Sí, será difícil para los piratas informáticos, pero también debes encontrar errores. El código debería ser fácil de mantener dentro de años, e incluso un código claro bien escrito puede ser difícil de mantener. No lo empeores.

Phil
fuente
3
+1 para el sentido común: ¿por qué hacerlo más difícil para usted cuando podría diseñar un sistema mejor?
Necrolis
1
Como siempre digo, si se mantiene todo del lado del servidor, es más seguro
liamzebedee
20

Hacer que el código sea difícil de realizar ingeniería inversa se denomina ofuscación de código.

La mayoría de las técnicas que menciona son bastante fáciles de solucionar. Se centran en agregar un código inútil. Pero el código inútil es fácil de detectar y eliminar, dejándolo con un programa limpio.

Para una ofuscación efectiva, debe hacer que el comportamiento de su programa dependa de los bits inútiles que se ejecutan. Por ejemplo, en lugar de hacer esto:

a = useless_computation();
a = 42;

hacer esto:

a = complicated_computation_that_uses_many_inputs_but_always_returns_42();

O en lugar de hacer esto:

if (running_under_a_debugger()) abort();
a = 42;

Haga esto (donde running_under_a_debuggerno debería ser fácilmente identificable como una función que prueba si el código se está ejecutando bajo un depurador; debería mezclar cálculos útiles con la detección del depurador):

a = 42 - running_under_a_debugger();

La ofuscación efectiva no es algo que pueda hacer únicamente en la etapa de compilación. Cualquier cosa que el compilador pueda hacer, un descompilador puede hacerlo. Claro, puede aumentar la carga sobre los descompiladores, pero no va a llegar muy lejos. Las técnicas efectivas de ofuscación, en la medida en que existan, implican escribir una fuente ofuscada desde el día 1. Haga que su código se auto modifique. Cubra su código con saltos calculados, derivados de una gran cantidad de entradas. Por ejemplo, en lugar de una simple llamada

some_function();

haga esto, donde conoce el diseño exacto esperado de los bits en some_data_structure:

goto (md5sum(&some_data_structure, 42) & 0xffffffff) + MAGIC_CONSTANT;

Si se toma en serio la ofuscación, agregue varios meses a su planificación; La ofuscación no es barata. Y considere que, con mucho, la mejor manera de evitar que las personas realicen ingeniería inversa de su código es hacerlo inútil para que no se molesten. Es una simple consideración económica: realizarán ingeniería inversa si el valor para ellos es mayor que el costo; pero aumentar su costo también aumenta mucho su costo, así que intente reducir el valor para ellos.

Ahora que te dije que la ofuscación es difícil y costosa, te diré que no es para ti de todos modos . Usted escribe

El protocolo actual en el que he estado trabajando nunca debe ser inspeccionado o comprensible, para la seguridad de varias personas

Eso levanta una bandera roja. Es seguridad por oscuridad , que tiene un historial muy pobre. Si la seguridad del protocolo depende de que las personas no lo conozcan, ya ha perdido .

Lectura recomendada:

Gilles 'SO- deja de ser malvado'
fuente
1
@Gilles, esa es su declaración, que es muy fuerte, por lo que la carga de la prueba recae en usted. Sin embargo, proporcionaré un ejemplo simple: 2+2puede ser simplificado por el compilador a 4, pero el descompilador no puede devolverlo a 2+2(¿y si en realidad lo fuera 1+3?
Rotsor
77
@Rotsor 4y 2+2son observacionalmente equivalentes, por lo que son los mismos para este propósito, es decir, para descubrir qué está haciendo el programa. Sí, por supuesto, el descompilador no puede reconstruir el código fuente, pero eso es irrelevante. Este Q&A se trata de reconstruir el comportamiento (es decir, el algoritmo y, más precisamente, un protocolo).
Gilles 'SO- deja de ser malvado'
1
No tiene que hacer nada para reconstruir el comportamiento. Ya tienes el programa! Lo que generalmente necesita es comprender el protocolo y cambiar algo en él (como reemplazar un 2 in 2+2con 3, o reemplazar el +con a *).
Rotsor
1
Si considera que todos los programas de comportamiento equivalente son iguales, entonces sí, el compilador no puede hacer nada porque solo realiza una transformación de identidad. El descompilador también es inútil, ya que es una transformación de identidad nuevamente. Sin embargo, si no lo hace, entonces 2+2-> 4es un ejemplo válido de transformación irreversible realizada por el compilador. Si hace que la comprensión sea más fácil o más difícil es un argumento separado.
Rotsor
2
@Gilles No puedo extender tu analogía con la manzana porque no puedo imaginar una manzana estructuralmente diferente, pero con un comportamiento equivalente. :)
Rotsor
13

Muchas veces, el miedo a que su producto sea diseñado de forma inversa está fuera de lugar. Sí, se puede realizar ingeniería inversa; pero se volverá tan famoso en un corto período de tiempo, que los hackers encontrarán que vale la pena revertir la ingeniería eso ? (este trabajo no es una actividad de poco tiempo, para líneas de código sustanciales).

Si realmente se convierte en un generador de dinero, entonces debería haber reunido suficiente dinero para protegerlo utilizando las formas legales, como patentes y / o derechos de autor .

En mi humilde opinión, tome las precauciones básicas que va a tomar y suéltelo. Si se convierte en un punto de ingeniería inversa que significa que ha hecho un trabajo realmente bueno, usted mismo encontrará mejores formas de superarlo. Buena suerte.

iammilind
fuente
1
Quiero decir, esta es una respuesta viable y aplicable, pero la línea que trazas entre la protección y el ingreso de un par de millones para que otros protejan tu producto por ti es una línea muy larga.
Graphitemaster
12

Lea http://en.wikipedia.org/wiki/Security_by_obscurity#Arguments_against . Estoy seguro de que otros probablemente también podrían dar una mejor fuente de por qué la seguridad por oscuridad es algo malo.

Debería ser completamente posible, utilizando técnicas criptográficas modernas, tener su sistema abierto (no estoy diciendo que debería estar abierto, solo que podría estarlo), y todavía tener seguridad total, siempre que el algoritmo criptográfico no lo haga. tiene un agujero (no es probable si elige uno bueno), sus claves / contraseñas privadas permanecen privadas y no tiene agujeros de seguridad en su código ( esto es de lo que debería preocuparse).

asmeurer
fuente
2
Estoy de acuerdo con esto Creo que puede tener un problema conceptual o de diseño. ¿Existe un análogo con una solución de par de claves pública-privada? Nunca divulga la clave privada, se queda con el propietario cuyo cliente seguro la procesa. ¿Puede mantener el código seguro fuera de su computadora y solo transmitir los resultados al usuario?
Dizzley
8

Desde julio de 2013, existe un renovado interés en la ofuscación criptográficamente robusta (en forma de ofuscación indistinguible ) que parece haber surgido de la investigación original de Amit Sahai .

Puede encontrar información destilada en este artículo de Quanta Magazine y en ese artículo de IEEE Spectrum .

Actualmente, la cantidad de recursos necesarios para hacer uso de esta técnica la hace poco práctica, pero AFAICT el consenso es bastante optimista sobre el futuro.

Digo esto muy casualmente, pero para todos los que están acostumbrados a descartar instintivamente la tecnología de ofuscación, esto es diferente. Si se demuestra que realmente funciona y se hace práctico, esto es realmente importante, y no solo por ofuscación.

tne
fuente
7

Para informarse, lea la literatura académica sobre la ofuscación del código . Christian Collberg de la Universidad de Arizona es un erudito de buena reputación en este campo; Salil Vadhan de la Universidad de Harvard también ha hecho un buen trabajo.

Estoy atrasado en esta literatura, pero la idea esencial que conozco es que no puede evitar que un atacante vea el código que ejecutará, pero puede rodearlo con código que no se ejecuta, y cuesta un tiempo exponencial del atacante (utilizando las técnicas más conocidas) para descubrir qué fragmentos de su código se ejecutan y cuáles no.

Norman Ramsey
fuente
7

Hay un artículo reciente llamado " Ofuscación de programas y programas únicos ". Si realmente quiere proteger su aplicación. El documento en general trata los resultados de imposibilidad teórica mediante el uso de hardware simple y universal.

Si no puede permitirse el lujo de requerir hardware adicional, también hay otro documento que ofrece la mejor ofuscación teóricamente " En la mejor ofuscación posible ", entre todos los programas con la misma funcionalidad y el mismo tamaño. Sin embargo, el artículo muestra que la información teórica mejor posible implica un colapso de la jerarquía polinómica.

Esos documentos deberían al menos darle suficientes referencias bibliográficas para caminar en la literatura relacionada si estos resultados no funcionan para sus necesidades.

Actualización: una nueva noción de ofuscación, llamada ofuscación indistinguible, puede mitigar el resultado de imposibilidad (papel)

Mohammad Alaggan
fuente
6

Si alguien quiere pasar el tiempo para revertir su binario, entonces no hay absolutamente nada que pueda hacer para detenerlo. Puede hacer que sea moderadamente más difícil, pero eso es todo. Si realmente quiere aprender sobre esto, obtenga una copia de http://www.hex-rays.com/idapro/ y desarme algunos binarios.

El hecho de que la CPU necesite ejecutar el código es su ruina. La CPU solo ejecuta código de máquina ... y los programadores pueden leer el código de máquina.

Dicho esto ... es probable que tenga un problema diferente que se puede resolver de otra manera. ¿Qué intentas proteger? Dependiendo de su problema, es probable que pueda usar el cifrado para proteger su producto.

Brian Makin
fuente
6

Para poder seleccionar la opción correcta, debe pensar en los siguientes aspectos:

  1. ¿Es probable que los "nuevos usuarios" no quieran pagar pero usen su software?
  2. ¿Es probable que los clientes existentes necesiten más licencias de las que tienen?
  3. ¿Cuánto están dispuestos a pagar los usuarios potenciales?
  4. ¿Desea otorgar licencias por usuario / usuarios concurrentes / estación de trabajo / empresa?
  5. ¿Su software necesita capacitación / personalización para ser útil?

Si la respuesta a la pregunta 5 es "sí", no se preocupe por las copias ilegales. No serían útiles de todos modos.

Si la respuesta a la pregunta 1 es "sí", primero piense en los precios (vea la pregunta 3).

Si responde las preguntas 2 "sí", entonces un modelo de "pago por uso" podría ser apropiado para usted.

Desde mi experiencia, el pago por uso + personalización y capacitación es la mejor protección para su software, porque:

  • Los nuevos usuarios se sienten atraídos por el modelo de precios (poco uso -> poco pago)
  • Casi no hay "usuarios anónimos", porque necesitan capacitación y personalización.
  • Ninguna restricción de software asusta a los clientes potenciales.
  • Hay un flujo continuo de dinero de los clientes existentes.
  • Obtiene comentarios valiosos para el desarrollo de sus clientes, debido a una relación comercial a largo plazo.

Antes de pensar en introducir DRM u ofuscación, puede pensar en estos puntos y si son aplicables a su software.

Negro
fuente
Muy buen consejo (y lo voté), pero en realidad no aborda esta pregunta en particular
Mawg dice que reinstale a Monica el
5

Al principio, el código protegido en una máquina virtual parecía imposible realizar ingeniería inversa. Themida Packer

Pero ya no es tan seguro ... Y no importa cómo empaques tu código, siempre puedes volcar la memoria de cualquier ejecutable cargado y desarmarlo con cualquier desensamblador como IDA Pro.

IDA Pro también viene con un ingenioso código de ensamblaje para el transformador de código fuente C, aunque el código generado se verá más como un desorden matemático de puntero / dirección ... si lo compara con el original, puede corregir todos los errores y eliminar cualquier cosa.

SSpoke
fuente
5

Sin dados, no puede proteger su código de desmontaje. Lo que puede hacer es configurar el servidor para la lógica de negocios y usar el servicio web para proporcionarlo para su aplicación. Por supuesto, este escenario no siempre es posible.

Lukasz Madon
fuente
8
Bien dicho, la única forma de evitar que las personas desarmen su código es nunca permitirles tener acceso físico a él, lo que significa ofrecer su aplicación exclusivamente como SAAS, aceptar solicitudes de clientes remotos y devolver los datos procesados. Coloque el servidor en una habitación cerrada con llave en un búnker subterráneo rodeado por una zanja de cocodrilo y un alambre de afeitar electrificado de 5 m de altura al que arroje la llave antes de cubrirlo con 10 m de hormigón armado, y luego espero que no se olvide de instalar toneladas de sistemas de software para evitar intrusiones en la red.
Jwenting
66
Espero nunca consigo el contrato para el mantenimiento de sus servidores
Colin Pickard
5

Para evitar la ingeniería inversa, no debe dar el código a los usuarios. Dicho esto, recomiendo usar una aplicación en línea ... sin embargo (ya que no dio contexto) que podría no tener sentido para usted.

Nitruro de galio
fuente
esta es la solución real ... es decir, poner sus joyas de la corona en su propio servidor en su propia máquina VPS y solo exponer llamadas API a este servidor desde el cliente (navegador o cliente de API)
Scott Stensland
5

Posiblemente, su mejor alternativa sigue utilizando la virtualización, que introduce otro nivel de indirección / ofuscación que se debe evitar, pero como dijo SSpoke en su respuesta , esta técnica tampoco es 100% segura.


El punto es que no obtendrás la máxima protección, porque no existe tal cosa, y si alguna vez lo será, no durará mucho, lo que significa que no fue la máxima protección en primer lugar.

Cualquier cosa que el hombre monte, se puede desmontar.

Por lo general, es cierto que el desmontaje (adecuado) es a menudo (un poco o más) una tarea más difícil, por lo que su oponente debe ser más hábil , pero puede suponer que siempre hay alguien de esa calidad, y es una apuesta segura.

Si desea proteger algo contra los RE, debe conocer al menos las técnicas comunes utilizadas por los RE.

Así palabras

Internet no es realmente ingenioso para la prevención contra la ingeniería inversa, sino que representa toneladas de información sobre cómo realizar ingeniería inversa

Muestra mala actitud tuya. No estoy diciendo que para usar o incrustar protección debe saber cómo romperlo, pero para usarlo sabiamente debe conocer sus debilidades y dificultades. Deberías entenderlo .

(Hay ejemplos de software que usa la protección de manera incorrecta, haciendo que tal protección sea prácticamente inexistente. Para evitar hablar vagamente, le daré un ejemplo brevemente descrito en Internet: Oxford English Dictionary Second Edition en CD-ROM v4. Puede leer sobre su uso fallido de SecuROM en la siguiente página: Oxford English Dictionary (OED) en CD-ROM en un entorno de Windows de 16, 32 o 64 bits: instalación de disco duro, errores, macros de procesamiento de textos, redes, fuentes y etc. )

Todo lleva tiempo.

Si eres nuevo en el tema y no tienes meses o más bien años para entrar correctamente en las cosas RE, entonces ve con las soluciones disponibles hechas por otros. El problema aquí es obvio, ya están allí, así que ya sabes que no son 100% seguros, pero crear tu propia nueva protección solo te daría una falsa sensación de estar protegido, a menos que conozcas muy bien el estado del arte en ingeniería inversa y protección (pero no lo hace, al menos en este momento).

El objetivo de la protección del software es asustar a los novatos, detener los ER comunes y poner una sonrisa en la cara de los RE experimentados después de su viaje (con suerte interesante) al centro de su aplicación.

En las conversaciones de negocios, puede decir que se trata de retrasar la competencia, tanto como sea posible.

(Eche un vistazo a la bonita presentación Silver Needle en Skype de Philippe Biondi y Fabrice Desclaux en Black Hat 2006).


Eres consciente de que hay muchas cosas sobre RE, así que comienza a leerlo. :)

Dije acerca de la virtualización, así que te daré un enlace a un hilo ejemplar del FORO DE EXETOOLS : El mejor protector de software: ¿Themida o Enigma Protector? . Puede ayudarte un poco en futuras búsquedas.

przemoc
fuente
4

No creo que ningún código sea inquebrantable, pero las recompensas deben ser excelentes para que alguien quiera intentarlo.

Dicho esto, hay cosas que debe hacer, como:

  • Utilice el nivel de optimización más alto posible (la ingeniería inversa no se trata solo de obtener la secuencia de ensamblaje, también se trata de comprender el código y portarlo a un lenguaje de nivel superior como C). El código altamente optimizado puede ser un b --- h a seguir.
  • Haga densas las estructuras al no tener tipos de datos más grandes de lo necesario. Reorganizar los miembros de la estructura entre lanzamientos de códigos oficiales. Los campos de bits reorganizados en las estructuras también son algo que puede usar.
  • Puede verificar la presencia de ciertos valores que no deben cambiarse (un mensaje de copyright es un ejemplo). Si un vector de bytes contiene "vwxyz", puede tener otro vector de bytes que contenga "abcde" y comparar las diferencias. La función que lo hace no debe pasar punteros a los vectores, sino usar punteros externos definidos en otros módulos como (código pseudo-C) "char * p1 = & string1 [539];" y "char p2 = & string2 [-11731];". De esa manera no habrá ningún puntero que apunte exactamente a las dos cadenas. En el código de comparación, se compara para " (p1-539 + i) - * (p2 + 11731 + i) == algún valor". El cracker pensará que es seguro cambiar string1 porque nadie parece hacer referencia a él. Enterrar la prueba en un lugar inesperado.

Intenta hackear el código de ensamblaje para ver qué es fácil y qué es difícil de hacer. Deben aparecer ideas con las que pueda experimentar para hacer que el código sea más difícil de realizar ingeniería inversa y para que la depuración sea más difícil.

Olof Forshell
fuente
2
su primer punto no tiene sentido, el código optimizado corta el rudo, esto hace que sea más fácil revertirlo (hablo por experiencia). su tercer punto también es una pérdida de tiempo, y el ingeniero de reversa que vale la pena sabe cómo hacer que el acceso a la memoria sea innovador. esta es la razón por la que probablemente sea mejor no diseñar un sistema usted mismo, sino nosotros, las bibliotecas de terceros que aún no se han `` descifrado '', porque es probable que dure un poco más de lo que un `` novato '' podría crear ...
Necrolis
Como parece que no sé nada sobre el tema, tal vez debería recurrir a un profesional como usted para mis necesidades de desarrollo de software en lugar de escribir cualquier código yo mismo.
Olof Forshell
4

Como muchos ya dijeron: en una CPU normal no puedes evitar que lo hagan, solo puedes retrasarlos. Como me dijo mi antiguo maestro de cifrado: no necesita un cifrado perfecto, romper el código debe ser más costoso que la ganancia. Lo mismo vale para su ofuscación.

Pero 3 notas adicionales:

  1. Es posible hacer que la ingeniería inversa sea imposible, PERO (y esto es muy, pero muy grande), no puede hacerlo en una CPU convencional. También hice mucho desarrollo de hardware, y a menudo se usan FPGA. Por ejemplo, Virtex 5 FX tiene una CPU PowerPC y puede usar la APU para implementar sus propios códigos de operación de CPU en su hardware. Puede utilizar esta función para descifrar realmente las incrustaciones para el PowerPC, que no es accesible desde el exterior u otro software, o incluso ejecutar el comando en el hardware. Como el FPGA tiene encriptación AES incorporada para su flujo de bits de configuración, no puede realizar ingeniería inversa (excepto que alguien logra romper AES, pero supongo que tenemos otros problemas ...). De esta manera, los proveedores de hardware IP también protegen su trabajo.

  2. Hablas desde el protocolo. No dice qué tipo de protocolo es, pero cuando se trata de un protocolo de red, al menos debe protegerlo contra la detección de redes. De hecho, esto se puede hacer mediante cifrado. Pero si desea proteger el en / descifrado de un propietario del software, ha vuelto a la ofuscación.

  3. Haga que su programa no pueda ser borrado / no pueda ejecutarse. Intente utilizar algún tipo de detección de depuración y aplíquelo, por ejemplo, en alguna fórmula o agregue un contenido de registro de depuración a una constante mágica. Es mucho más difícil si su programa se ve en modo de depuración si funciona normalmente, pero realiza un cálculo, operación u otro incorrecto completo. Por ejemplo, conozco algunos juegos ecológicos, que tenían una protección anticopia realmente desagradable (sé que no quieres protección anticopia, pero es similar): la versión robada alteró los recursos extraídos después de 30 minutos de juego, y de repente obtuviste solo uno recurso. El pirata acaba de descifrarlo (es decir, ingeniería inversa), verificó si funciona y volia lo liberó. Tales ligeros cambios de comportamiento son muy difíciles de detectar, especialmente. si no aparecen al instante a la detección, sino que solo se retrasan.

Así que finalmente sugeriría: Estime cuál es el beneficio de las personas que realizan ingeniería inversa de su software, traduzca esto en algún momento (por ejemplo, utilizando el salario indio más barato) y haga que la ingeniería inversa sea tan costosa que sea más grande.

flolo
fuente
3

Contrariamente a lo que dice la mayoría de la gente, en base a su intuición y experiencia personal, no creo que la ofuscación de programas criptográficamente segura sea imposible en general.

Este es un ejemplo de una declaración de programa perfectamente ofuscada para demostrar mi punto:

printf("1677741794\n");

Uno nunca puede adivinar que lo que realmente hace es

printf("%d\n", 0xBAADF00D ^ 0xDEADBEEF);

Hay un documento interesante sobre este tema, que demuestra algunos resultados imposibles. Se llama "Sobre la (Im) posibilidad de Ofuscar Programas" .

Aunque el documento prueba que la ofuscación que hace que el programa no sea distinguible de la función que implementa es imposible, ¡la ofuscación definida de alguna manera más débil aún puede ser posible!

Rotsor
fuente
77
1. Su ejemplo no es relevante aquí; los dos programas que muestra son conductualmente equivalentes, y esta pregunta se trata de descubrir el comportamiento de un programa, no de reconstruir su código fuente (que, obviamente, es imposible). 2. Este artículo es un trabajo teórico; es imposible escribir el ofuscador perfecto, pero también es imposible escribir el descompilador perfecto (por las mismas razones que es imposible escribir el analizador de programa perfecto). En la práctica, es una carrera armamentista: quién puede escribir el mejor (de) ofuscador.
Gilles 'SO- deja de ser malvado'
1
@Gilles, el resultado de la desofuscación (correcta) siempre será conductualmente equivalente al código ofuscado. No veo cómo eso socava la importancia del problema.
Rotsor
Además, sobre la carrera armamentista: no se trata de quién invierte más en la investigación, sino de quién tiene razón. Las pruebas matemáticas correctas no salen mal solo porque alguien quiere que lo hagan realmente mal.
Rotsor
1
De acuerdo, tal vez tengas razón sobre la carrera armamentista en la práctica. Creo que entendí mal este. :) Espero que sea posible algún tipo de ofuscación criptográficamente segura.
Rotsor
Para un caso interesante de ofuscación, pruebe con tarjetas inteligentes, donde el problema es que el atacante tiene acceso físico (ofuscación de caja blanca). Parte de la respuesta es limitar el acceso por medios físicos (el atacante no puede leer las claves secretas directamente); pero la ofuscación de software también juega un papel, principalmente para hacer que ataques como DPA no den resultados útiles. No tengo una buena referencia para ofrecer, lo siento. Los ejemplos en mi respuesta están vagamente inspirados en las técnicas utilizadas en ese dominio.
Gilles 'SO- deja de ser malvado'
3

La seguridad a través de la oscuridad no funciona como lo han demostrado personas mucho más inteligentes que nosotros dos. Si debe proteger el protocolo de comunicación de sus clientes, está moralmente obligado a utilizar el mejor código que esté abierto y que los expertos analicen por completo.

Esto es para la situación en la que las personas pueden inspeccionar el código. Si su aplicación se ejecuta en un microprocesador incorporado, puede elegir uno que tenga una función de sellado, lo que hace que sea imposible inspeccionar el código u observar más que parámetros triviales como el uso actual mientras se ejecuta. (Es, excepto por técnicas de invasión de hardware, donde desmantela cuidadosamente el chip y usa equipos avanzados para inspeccionar las corrientes en los transistores individuales).

Soy el autor de un ensamblador de ingeniería inversa para el x86. Si está listo para una sorpresa fría, envíeme el resultado de sus mejores esfuerzos. (Contácteme a través de mis sitios web). Pocos de los que he visto en las respuestas me presentarían un obstáculo sustancial. Si desea ver cómo funciona el sofisticado código de ingeniería inversa, realmente debería estudiar sitios web con desafíos de ingeniería inversa.

Su pregunta podría usar alguna aclaración. ¿Cómo espera mantener un protocolo secreto si el código de la computadora es susceptible de ingeniería inversa? Si mi protocolo fuera enviar un mensaje cifrado RSA (incluso clave pública), ¿qué gana al mantener el protocolo en secreto? A todos los efectos prácticos, un inspector se enfrentaría a una secuencia de bits aleatorios.

Groetjes Albert

Albert van der Horst
fuente
3

Las técnicas tradicionales de ingeniería inversa dependen de la capacidad de un agente inteligente que utiliza un desensamblador para responder preguntas sobre el código. Si desea una seguridad sólida, debe hacer cosas que eviten que el agente obtenga tales respuestas.

Puede hacerlo confiando en el Programa de detención ("¿se detiene el programa X?") Que en general no se puede resolver. Agregar programas que son difíciles de razonar a su programa, hace que su programa sea difícil de razonar. Es más fácil construir tales programas que separarlos. También puede agregar código al programa que tenga diversos grados de dificultad para razonar; Un gran candidato es el programa de razonamiento sobre alias ("punteros").

Collberg et al tienen un documento ("Fabricación de construcciones opacas baratas, resistentes y sigilosas") que analiza estos temas y define una variedad de predicados "opacos" que pueden hacer que sea muy difícil razonar sobre el código:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.39.1946&rep=rep1&type=pdf

No he visto los métodos específicos de Collberg aplicados al código de producción, especialmente no el código fuente C o C ++.

El ofuscador DashO Java parece usar ideas similares. http://www.cs.arizona.edu/~collberg/Teaching/620/2008/Assignments/tools/DashO/

Ira Baxter
fuente
2

PRIMERA COSA QUE RECUERDA SOBRE OCULTAR SU CÓDIGO : No todo su código debe estar oculto.

EL OBJETIVO FINAL : Mi objetivo final para la mayoría de los programas de software es la capacidad de vender diferentes licencias que activarán y desactivarán funciones específicas dentro de mis programas.

MEJOR TÉCNICA : Creo que construir un sistema de ganchos y filtros como las ofertas de WordPress es el mejor método absoluto cuando se trata de confundir a tus oponentes. Esto le permite cifrar ciertas asociaciones de desencadenadores sin cifrar realmente el código.

La razón por la que hace esto es porque querrá cifrar la menor cantidad de código posible.

CONOZCA SUS CRACKERS : sepa esto: la razón principal para descifrar el código no se debe a la distribución maliciosa de las licencias, sino a la NECESIDAD de cambiar su código y realmente NO NECESITAN distribuir copias gratuitas.

PARA EMPEZAR : Deje a un lado la pequeña cantidad de código que va a cifrar, el resto del código debe intentar agruparse en UN archivo para aumentar la complejidad y la comprensión.

PREPARACIÓN PARA ENCRIPTAR : vas a encriptar en capas con mi sistema, también será un procedimiento muy complejo, así que crea otro programa que será responsable del proceso de encriptación.

PASO UNO : Ofuscarse usando nombres de base64 para todo. Una vez hecho esto, base64 el código ofuscado y guárdelo en un archivo temporal que luego se utilizará para descifrar y ejecutar este código. ¿Tener sentido?

Lo repetiré ya que lo harás una y otra vez. Vas a crear una cadena base64 y guardarla en otro archivo como una variable que será descifrada y renderizada.

PASO DOS : leerás este archivo temporal como una cadena y lo ofuscarás, luego lo basarás en 64 y lo guardarás en un segundo archivo temporal que se usará para descifrarlo y representarlo para el usuario final.

PASO TRES : Repita el paso dos tantas veces como desee. Una vez que tenga esto funcionando correctamente sin errores de descifrado, entonces querrá comenzar a construir minas terrestres para sus oponentes.

LAND MINE ONE : querrá mantener el hecho de que se le notifica un secreto absoluto. Por lo tanto, cree un sistema de correo de advertencia de seguridad de intento de craqueo para la capa 2. Esto se activará para permitirle conocer los detalles sobre su oponente si algo sale mal.

TIERRA MINA DOS : Dependencias. No quieres que tu oponente pueda ejecutar la capa uno, sin la capa 3 o 4 o 5, o incluso el programa real para el que fue diseñado. Así que asegúrese de que dentro de la capa uno incluya algún tipo de secuencia de comandos kill que se active si el programa no está presente, o las otras capas.

Estoy seguro de que puedes crear tus propias minas terrestres, diviértete con ellas.

COSA PARA RECORDAR : en realidad puede cifrar su código en lugar de hacerlo en base64. De esa manera, una base64 simple no descifrará el programa.

PREMIO : Tenga en cuenta que esto puede ser una relación simbiótica entre usted y su oponente. Siempre coloco un comentario dentro de la capa uno, el comentario felicita al cracker y les da un código promocional para que lo usen para recibir una recompensa en efectivo de usted.

Haga que la recompensa en efectivo sea significativa sin prejuicios involucrados. Normalmente digo algo así como $ 500. Si tu chico es el primero en descifrar el código, entonces paga su dinero y conviértete en su amigo. Si es amigo tuyo, no va a distribuir tu software. ¡Pregúntale cómo lo hizo y cómo puedes mejorar!

¡BUENA SUERTE!

Arquitecto Empresarial
fuente
44
¿Leíste la pregunta? Nunca pedí métodos sobre cómo protegerse de la piratería. La aplicación será gratuita, es el protocolo subyacente que se debe proteger debido a la naturaleza de la seguridad.
Graphitemaster