¿Proteger el ejecutable de la ingeniería inversa?

Pero todos ellos pueden ser trabajados y / o calculados por los analistas de código dado el marco de tiempo adecuado.

Si le das a las personas un programa que puedan ejecutar, entonces también podrán realizar ingeniería inversa 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 eventual ingeniería inversa. Después de todo, el ordenador tiene que ser capaz de descifrarlo con el fin de 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 utilizado su método de protección de hardware ( Sentinel HASP HL) durante muchos años. Requiere un llavero USB propietario que actúa como la' licencia ' para el software. Su SDK encripta y ofusca sus ejecutables y bibliotecas, y le permite vincular diferentes características de su aplicación a las características grabadas en la llave. Sin una llave USB proporcionada y activada por el licenciante, el software no puede descifrar y, por lo tanto, no se ejecutará. La Clave incluso utiliza un protocolo de comunicación USB personalizado (fuera de mi ámbito de conocimiento, no soy un tipo de controlador de dispositivo) para dificultar la construcción de una clave virtual, o manipular la comunicación entre el wrapper de tiempo de ejecución y la clave. Su SDK no es muy amigable para desarrolladores, 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' 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 de la elaboración de perfiles y la evaluación comparativa, la protección HASP HL solo ralentizó los cálculos intensivos en aproximadamente un 3%. Desde que ese software fue lanzado hace unos 5 años, ni uno nuevo pirata del producto ha sido encontrado. El software que protege tiene una gran demanda en su segmento de mercado, y el cliente es consciente de que varios competidores intentan activamente realizar ingeniería inversa (sin éxito hasta ahora). Sabemos que han tratado de solicitar ayuda de algunos grupos en Rusia que anuncian un servicio para romper la protección del software, ya que numerosos mensajes en varios grupos de noticias y foros han incluido las versiones más recientes del producto protegido.

Recientemente probamos su software license solution (HASP SL) en un proyecto más pequeño, que fue lo suficientemente sencillo como para empezar a trabajar 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 quemar, estoy seguro de que las protecciones proporcionadas por HASP podrían ser eludidas.

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 mucha gente inteligente, y la parte "secreta" no es el algoritmo en sí - la parte secreta es la clave que es una de las entradas para el 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 en sí sea secreto. El código siempre se puede interpretar pase lo que pase lo haces, y (idealmente) el secreto generado solo puede ser puesto en peligro por un enfoque de fuerza bruta masiva o a través del robo.

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

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 hackers, pero también necesitas encontrar errores. El código debe 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.

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

CLC
BCC over
.byte 0x09
over:

El desensamblador tiene que resolver el problema de que un destino de rama es el segundo byte en una instrucción multi byte. 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 del conjunto de instrucciones no tendrá problema con eso. El uso de un simulador para ordenar los destinos de las sucursales para usted puede ayudar en el proceso de desmontaje. El código compilado es relativamente limpio y fácil para un desensamblador. Así que creo que se necesita un poco de montaje.

Creo que fue cerca del comienzo del Zen del Lenguaje Ensamblador de Michael Abrash donde mostró un simple truco anti-desensamblador y anti-depurador. El 8088/6 tenía una cola de prefetch lo que hizo fue tener una instrucción que modificaba la siguiente instrucción o un par por delante. Si un solo paso luego ejecutó la instrucción modificada, si su simulador de conjunto de instrucciones no simuló el hardware por completo, 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 mientras no ejecute esa cadena de instrucciones de nuevo. Probablemente todavía podría usar un truco como este hoy en día, ya que los procesadores canalizados obtienen la siguiente instrucción. O si usted sabe que el hardware tiene una caché de instrucciones y datos separada puede modificar un número de bytes por delante si alinea este código en la línea de caché correctamente, el byte modificado no se escribirá a través de la caché de instrucciones sino de la 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 software solo no van a llegar muy lejos.

Los anteriores son viejos y bien conocidos, no sé lo suficiente sobre el herramientas actuales para saber si ya funcionan alrededor de tales cosas. El código de auto modificación puede / hará tropezar al depurador, pero el humano puede / se limitará al problema y luego verá el código de auto modificación y trabajará alrededor de él.

Solía ser que los hackers tomarían unos 18 meses para resolver algo, dvds, por ejemplo. Ahora están promediando alrededor de 2 días a 2 semanas (si están motivados) (blue ray, iphones, etc.). Eso significa para mí que si paso más de unos días en seguridad, es probable que malgastando mi tiempo. La única seguridad real que obtendrá es a través del hardware (por ejemplo, sus instrucciones están cifradas y solo el núcleo del procesador dentro del chip se descifra justo antes de la ejecución, de una manera que no puede exponer las instrucciones descifradas). Eso podría comprarte meses en lugar de días.

También, lea el libro de Kevin Mitnick El Arte del Engaño. Una persona como esa podría coger un teléfono y hacer que usted o un compañero de trabajo repartan 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 tu seguridad está arruinada. La seguridad no es todo acerca de la gestión de la tecnología, hay que gestionar los seres humanos también.

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

La mayoría de las técnicas que mencionas son bastante fáciles de evitar. Se centran en agregar algún código inútil. Pero el código inútil es fácil de detectar y eliminar, dejándote 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;

Haz 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_debugger no debe ser fácilmente identificable como una función que prueba si el código se está ejecutando bajo un depurador - debe mezclar cálculos útiles con detección de depurador):

a = 42 - running_under_a_debugger();

Ofuscación efectiva no es algo que se puede hacer puramente en la etapa de compilación. Cualquier cosa que el compilador puede hacer, un descompilador puede hacer. Claro, puede aumentar la carga en los descompiladores, pero no va a ir muy lejos. Técnicas eficaces de ofuscación, en la medida en que existen, involucrar a la escritura fuente ofuscada desde el día 1. Haga que su código se modifique por sí mismo. Ensucie su código con saltos calculados, derivados de un gran número de entradas. Por ejemplo, en lugar de una simple llamada

some_function();

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

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

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

Ahora que les he dicho que la ofuscación es difícil y costosa, les voy a decir que no es para ustedes de todos modos. Escribe

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

Que 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 has perdido.

Lectura recomendada:

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

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

Si realmente se convierte en una fuente 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 liberarlo. Si se convierte en un punto de ingeniería inversa que significa que ha hecho un muy buen trabajo, usted mismo encontrará mejores maneras de superarlo. Buena suerte.

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

Debería ser completamente posible, usando técnicas criptográficas modernas, tener su sistema abierto (no estoy diciendo que debería estar abierto, solo que podría serlo), y aún así tener seguridad total, siempre y cuando el algoritmo criptográfico no tenga un agujero en él (no es probable que elige una buena), sus claves/contraseñas privadas permanecen privadas, y no tiene agujeros de seguridad en su código (esto es lo que debería preocuparse).

Desde julio de 2013, hay un renovado interés en la ofuscación criptográficamente robusta (en la forma de Ofuscación Indistinguible) que parece haber estimulado 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: Negable Cifrado, y Más.
• Sahai, Barak, Garg, Kalai, Paneth, Protegiendo la Ofuscación Contra 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 lo hacen poco práctico, 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 this esto es diferente. Si se demuestra que realmente funciona y se hace práctico, esto es importante de hecho, y no solo para la ofuscación.

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

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

Ese ser manifestó... 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 informarse, lea la literatura académica sobre ofuscación de código. Christian Collberg de la Universidad de Arizona es un erudito de renombre 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 de la que soy consciente es que no puedes evitar que un atacante vea el código que ejecutarás, pero puedes rodearlo con código que es no ejecutado, y le cuesta a un atacante tiempo exponencial (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 de una sola vez". Si usted es realmente serio acerca de la protección de su aplicación. El artículo en general da la vuelta a los resultados teóricos de imposibilidad por el uso de hardware simple y universal.

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

Esos trabajos deben por lo menos darle suficientes pistas 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 (documento)

No hay dados, no puede proteger su código de desensamblar. Lo que puede hacer es configurar el servidor para la lógica de negocio y usar webservice para proporcionarlo a su aplicación. Por supuesto, este escenario no siempre es posible.

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

1. ¿Es probable que los "nuevos usuarios" no quieran pagar sino usar su software?
2. ¿Es probable que los clientes actuales 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 simultáneos / 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í", entonces 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 a las preguntas 2 "sí", entonces un modelo de "pago por uso" podría sea apropiado para Usted.

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

• Nuevos usuarios son 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, podría pensar en estos puntos y si son aplicables a Su software.

El código protegido en una máquina virtual parecía imposible de realizar ingeniería inversa al principio. Themida Packer

Pero ya no es tan seguro.. Y no importa cómo empaque su código, siempre puede hacer un volcado de memoria de cualquier ejecutable cargado y desensamblarlo con cualquier desensamblador como IDA Pro.

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

Posiblemente su mejor alternativa sigue utilizando la virtualización, lo que introduce otro nivel de indirección/ofuscación necesaria para omitir, 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.

Lo que el hombre ensambla, puede ser desmontar.

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

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

Así palabras

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

(Hay ejemplos de software que usa la protección de una manera incorrecta, haciendo que dicha protección sea prácticamente inexistente. Para evitar hablar vagamente te daré un ejemplo brevemente descrito en internet: Oxford English Dictionary Segunda edición 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 Windows de 16, 32 o 64 bits: Instalación en disco duro, errores, macros de procesamiento de textos, redes, fuentes, etc. )

Todo lleva tiempo.

Si eres nuevo en el tema y no tienes meses o más bien años para meterte correctamente en las cosas de RE, entonces ve con disponible soluciones hechas por otros. El problema aquí es obvio, ya están allí, por lo que ya sabes que no son 100% seguros, pero hacer 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 sabes, al menos en este momento).

El punto de la protección de software es asustar a los novatos, detener common REs y poner una sonrisa en la cara de sazonado RE después de su/su (esperemos interesante) viaje al centro de su aplicación.

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

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

Usted es consciente de que hay un montón de cosas acerca de RE por ahí, así que empezar a leerlo. :)

Dije acerca de la virtualización, así que te daré un enlace a un ejemplar tema de EXETOOLS FORUM: Mejor software protector: Themida o Enigma Protector?. Puede ayudarte un poco en búsquedas posteriores.

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

Habiendo dicho que hay cosas que debes hacer tales como:

• Use el nivel de optimización más alto posible (la ingeniería inversa no solo se trata de obtener la secuencia de ensamblado, 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.
• Hacer estructuras densas por no tener tipos de datos más grandes de lo necesario. Reorganiza los miembros de la estructura entre las versiones oficiales de código. Los campos de bits reordenados 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 ser pasado punteros a los vectores, pero el uso externo punteros 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 apuntando exactamente a las dos cuerdas. 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 algún lugar inesperado.

Intente hackear el código de ensamblaje usted mismo 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 hacer que la depuración sea más difícil.

Como muchos ya han dicho: En una CPU normal no puede evitar que lo hagan, solo puede retrasarlos. Como me dijo mi antiguo profesor de criptografía: No necesitas un cifrado perfecto, romper el código debe ser más caro que la ganancia. Lo mismo vale para tu ofuscación.

Pero 3 notas adicionales:

1. Es posible hacer imposible la ingeniería inversa, PERO (y este es un pero muy, muy grande), no se puede hacer en una cpu convencional. También hice mucho hardware desarrollo, y a menudo se utilizan FPGA. Por ejemplo, el Virtex 5 FX tiene una CPU PowerPC en ellos, y puede usar la APU para implementar sus propios opcodes de CPU en su hardware. Usted podría utilizar esta facilidad para realmente descifrar incstuctions para el PowerPC, que no es accesible por el exterior u otro software, o incluso ejecutar el comando en el hardware. Como la FPGA tiene cifrado AES incorporado para su flujo de bits de configuración, no se puede realizar ingeniería inversa (excepto que alguien se las arregla para romper AES, pero entonces supongo tenemos otros problemas...). De esta manera, los proveedores de IP de hardware también protegen su trabajo.

2. Hablas desde el protocolo. Usted no dice qué tipo de protocolo es, pero cuando se trata de un protocolo de red que al menos debe protegerlo contra la red sniffing. Esto se puede hacer por cifrado. Pero si desea proteger el en / descifrado de un propietario del software, está de vuelta a la ofuscación.

3. Haga su programa undebuggable / unrunnable. Trate de usar algunos tipo de detección de depuración y aplicarlo, por ejemplo, en alguna fórmula o agregar 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 es si donde se ejecuta normal, pero hace un cálculo incorrecto completo, operación, o algún otro. Por ejemplo, conozco algunos juegos ecológicos, que tenían una protección anticopia realmente desagradable( sé que no quieres copyprotection, pero es similar): La versión robada alteró los recursos minados después de 30 minutos de juego, y de repente tienes un solo recurso. El pirata simplemente lo descifró ( es decir, lo hizo ingeniería inversa) - comprobó si se ejecutaba, y volia lo liberó. Estos cambios de comportamiento leves son muy difíciles de detectar, esp. si no aparecen al instante a la detección, pero solo retrasada.

Así que finalmente sugeriría: Estimar cuál es la ganancia de la gente de ingeniería inversa de su software, traducir esto en algún tiempo (por ejemplo, mediante el uso del salario indio más barato) y hacer que la ingeniería inversa tiempo cuesta que sea más grande.

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 ser inútil en el suyo.

Al contrario de lo que la mayoría de la gente dice, basado en su intuición y experiencia personal, no creo que la ofuscación de programas criptográficamente seguros haya demostrado ser imposible en general.

Este es un ejemplo de una declaración de programa perfectamente ofuscado 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 "En el (Im) posibilidad de Ofuscar Programas " .

Aunque el documento demuestra 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 ha sido demostrado por personas mucho más inteligentes que los dos. Si usted debe proteger el protocolo de comunicación de sus clientes entonces usted es moralmente obligado a utilizar el mejor código que está en el abierto y plenamente examinado por los expertos.

Esto es para la situación en la que las personas pueden inspeccionar el código. Si su aplicación va a ejecutarse en un microprocesador integrado, puede elegir uno que tenga una instalación de sellado, lo que hace imposible inspeccione el código u observe más que parámetros triviales como el uso actual mientras se ejecuta. (Es, excepto por técnicas de invasión de hardware, donde se desmonta cuidadosamente el chip y se utiliza equipo avanzado para inspeccionar las corrientes en transistores individuales.)

Soy el autor de un ensamblador de ingeniería inversa para el x86. Si estás listo para un resfriado sorpresa, envíame el resultado de tus mejores esfuerzos. (Contáctame a través de mis sitios web.) Pocos que he visto en las respuestas presentarían una substancial obstáculo para mí. Si quieres ver cómo funciona el sofisticado código de ingeniería inversa, realmente debe estudiar sitios web con desafíos de ingeniería inversa.

Su pregunta podría necesitar alguna aclaración. ¿Cómo espera mantener un protocolo en secreto si el ¿el código informático es susceptible de ingeniería inversa? Si mi protocolo sería enviar un mensaje cifrado RSA (incluso clave pública) ¿qué ganas manteniendo el protocolo en secreto? A todos los efectos prácticos, se enfrentaría a un inspector con 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 fuerte de seguridad, hay que hacer cosas que seguramente prevenir el agente de conseguir respuestas.

Puede hacer eso confiando en el Programa de detención ("does program X halt?") 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 es más fácil construir tales programas que destrozarlos. También puede agregar código al programa que tiene diversos grados de dificultad para razonar; un gran candidato es el programa de razonamiento sobre alias ("punteros").

Collberg et al tienen un documento ("Manufacturing Cheap, Resilient and Stealthy Opaque Constructs") que discute estos temas y define una variedad de predicados" opacos " que pueden hacer que sea muy difícil razonar sobre 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 al código fuente C o C++.

El ofuscador Java de DashO parece usar ideas similares. http://www.cs.arizona.edu / ~collberg / Enseñanza/620/2008/Tareas / herramientas / DashO /

LO PRIMERO QUE DEBE RECORDAR ACERCA DE OCULTAR SU CÓDIGO: No es necesario ocultar todo su código.

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 características específicas dentro de mis programas.

MEJOR TÉCNICA: Me parece que construir en un sistema de ganchos y filtros como WordPress ofrece, es el mejor método absoluto cuando se trata de confundir a sus oponentes. Esto le permite cifrar ciertas asociaciones de activación sin cifrar realmente el código.

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

CONOZCA SUS CRACKERS: Sepa esto: La razón principal para descifrar el código no es debido a la distribución maliciosa de licencias, en realidad es porque necesitan cambiar su código y realmente no NECESITAN distribuir copias gratuitas.

INTRODUCCIÓN : Reserve la pequeña cantidad de código que usted va a cifrar, el resto del código debe tratar de ser hacinados en un archivo para aumentar la complejidad y la comprensión.

PREPARING TO ENCRYPT: Vas a cifrar en capas con mi sistema, también va a ser un procedimiento muy complejo, así que construye otro programa que será responsable del proceso de cifrado.

PASO UNO : Ofusca usando nombres base64 para todo. Una vez hecho esto, base64 el código ofuscado y guardarlo en un temporal archivo que más tarde se utilizará para descifrar y ejecutar este código. Sentido?

Voy a repetir ya que va a estar haciendo esto 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: Vas a leer en este archivo temporal como una cadena y ofuscarlo, luego base64 y guardarlo en un segundo archivo temporal que se utilizará para descifrarlo y renderizarlo para el usuario final.

PASO TRES: Repita el paso dos tantas veces como desee. Una vez que esto funcione correctamente sin errores de descifrado, entonces vas a querer comenzar a construir minas terrestres para tus oponentes.

LAND MINE ONE: Vas a querer mantener el hecho de que estás siendo notificado en absoluto secreto. Así que construya un sistema de correo de advertencia de seguridad de intento de cracker para la capa 2. Esto se disparará para que sepas los detalles de tu oponente si algo va a pasar Equivocada.

LAND MINE TWO: Dependencias. No quieres que tu oponente sea capaz de ejecutar la capa uno, sin la capa 3, 4 o 5, o incluso el programa real para el que fue diseñado. Así que asegúrate de que dentro de la capa uno incluyas algún tipo de script de eliminación que se activará si el programa no está presente, o las otras capas.

Estoy seguro de que usted puede llegar a su propia minas terrestres, divertirse con él.

COSA A RECORDAR: En realidad puede cifrar su código en lugar de base64 ing ella. De esa manera un simple base64 no descifrará el programa.

RECOMPENSA: Ten en cuenta que esto puede ser una relación simbiótica entre tú y tu oponente. Siempre pongo un comentario dentro de la capa uno, el comentario felicita a la galleta y les da un código promocional para usar con el fin de recibir una recompensa en efectivo de usted.

Hacer que la recompensa en efectivo sea significativa sin perjuicio. Normalmente digo algo así como 5 500. Si tu chico es el primero en romperse el código, luego pagarle su dinero y convertirse 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 probado CodeMorth: http://www.sourceformat.com/code-obfuscator.htm ? O Themida: http://www.oreans.com/themida_features.php ?

Más tarde uno parece más promisorio.