¿Proteger el ejecutable de la ingeniería inversa?

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?

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.

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.

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.

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.

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.

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:

• La biblia de seguridad: Ingeniería de seguridad por Ross Anderson
• La biblia de la ofuscación: software subrepticio de Christian Collberg y Jasvir Nagra

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.

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).

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 .

• Sahai, Garg, Gentry, Halevi, Raykova, Waters, Candidato Indistinguible , Ofuscación y Cifrado Funcional para todos los circuitos (21 de julio de 2013).
• Sahai, Waters, Cómo usar la ofuscación indistinguible: cifrado denegable, y más .
• Sahai, Barak, Garg, Kalai, Paneth, Protección de la ofuscación contra los ataques algebraicos (4 de febrero de 2014).

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.

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.

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)

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.

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.

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.

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.

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.

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.

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.

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.

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!

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

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/

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!

¿Alguien ha intentado CodeMorth: http://www.sourceformat.com/code-obfuscator.htm ? O Themida: http://www.oreans.com/themida_features.php ?

Más tarde se ve más prometedor.