visual proteger inversa ingenieria evitar encriptar ejecutable descompilar codigo c++ c obfuscation assembly

c++ - proteger - evitar ingenieria inversa c#



¿Proteger el ejecutable de la ingeniería inversa? (24)

He estado contemplando cómo proteger mi código C / C ++ del desensamblaje y la ingeniería inversa. Normalmente, yo 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, por 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 muestra 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 (llamadas a funciones ficticias antes y después de llamadas a funciones reales)
  • Obfusticación del código (desordena el desmontaje del binario).

  • Escribir mis propias rutinas de inicio (más difíciles de enlazar para los depuradores)

    void startup(); int _start() { startup( ); exit (0) } void startup() { /* code here */ }

  • Verificación en tiempo de ejecución para los depuradores (y forzar la salida si se detecta)

  • Función de trampolines.

    void trampoline(void (*fnptr)(), bool ping = false) { if(ping) fnptr(); else trampoline(fnptr, true); }

  • Asignaciones inútiles y desasignaciones (la pila cambia mucho)

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

Quiero decir que estas son algunas de las cosas en las que he pensado, pero todas pueden ser resueltas o resueltas por los analistas de códigos, dado el marco de tiempo correcto. ¿Hay alguna otra alternativa que tengo?

pero todos los analistas de código pueden resolverlos y / o resolverlos en el momento adecuado.

Si le das a la gente un programa que pueden ejecutar, también podrán realizar ingeniería inversa si se le da suficiente tiempo. Esa es la naturaleza de los programas. Tan pronto como el binario esté disponible para alguien que quiera descifrarlo, no podrá evitar la ingeniería inversa. Después de todo, la computadora tiene que ser capaz de descifrarla para poder ejecutarla, y un humano es simplemente una computadora más lenta.

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

Puede encontrar información detallada 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 hace que sea poco práctica, pero, de acuerdo con AFAICT, el consenso es bastante optimista sobre el futuro.

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

El código protegido en una máquina virtual parecía imposible invertir la ingeniería 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 de ensamblaje para transformar el código fuente en C, aunque el código generado se parecerá más a un puntero / desorden matemático de la dirección ... si lo comparas con el original, puedes corregir todos los errores y eliminar cualquier cosa.

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 solucionar. Se centran en añadir 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, necesita 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_debugger no debería ser fácilmente identificable como una función que comprueba si el código se está ejecutando bajo un depurador; debería combinar 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 puramente en la etapa de compilación. Lo que el compilador puede hacer, un decompilador puede hacer. Claro, puede aumentar la carga de los descompiladores, pero no va a llegar muy lejos. Las técnicas de ofuscación efectivas, en la medida en que existen, implican escribir fuentes ofuscadas desde el día 1. Haga que su código se modifique automáticamente. Deseche su código con saltos computados, 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 es serio acerca de 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 inutilizarlo para que no se moleste. Es una consideración económica simple: harán ingeniería inversa si el valor para ellos es mayor que el costo; pero elevar su costo también aumenta mucho su costo, así que intente rebajarles el valor.

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 ni comprensible, por la seguridad de varias personas

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

Lectura recomendada:

Hay un artículo reciente llamado " Programa de ofuscación y programas únicos ". Si eres realmente serio en proteger tu aplicación. El documento en general se refiere a los resultados de imposibilidad teórica mediante el uso de hardware simple y universal.

Si no puede permitirse requerir hardware adicional, también hay otro documento que ofrece la mejor ofuscación teóricamente posible " Sobre 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 mejor información posible de la teoría de la información implica un colapso de la jerarquía polinómica.

Esos documentos deben, al menos, proporcionarle suficientes referencias bibliográficas para consultar 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 (artículo)

Lea la página 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 totalmente posible, utilizando técnicas criptográficas modernas, tener el sistema abierto (no estoy diciendo que deba estar abierto, solo que podría serlo), y aún tener total seguridad, siempre que el algoritmo criptográfico no lo haga. tiene un agujero (no es probable que elija una buena), sus claves / contraseñas privadas permanezcan privadas y no tenga agujeros de seguridad en su código ( esto es lo que debería preocuparle).

Lo que Amber dijo es exactamente correcto. Puede hacer que la ingeniería inversa sea más difícil, pero nunca puede evitarlo. Nunca debe confiar en la "seguridad" que se basa en la prevención de la ingeniería inversa .

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

Los mejores trucos contra el desensamblador, en particular en los conjuntos de instrucciones de longitud de palabra variable están en el ensamblador / código de 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 bifurcación es el segundo byte en una instrucción de múltiples bytes. Un simulador de conjunto de instrucciones no tendrá ningún problema sin embargo. La derivación a direcciones computadas, 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 con él. El uso de un simulador para ordenar los destinos de las sucursales puede ayudar al proceso de desensamblaje. El código compilado es relativamente limpio y fácil para un desensamblador. Así que creo que se requiere algo de montaje.

Creo que fue cerca del comienzo del zen de lenguaje ensamblador de Michael Abrash, donde mostró un sencillo truco anti desensamblador y anti-depurador. El 8088/6 tenía una cola de recuperación previa. Lo que hizo fue tener una instrucción que modificó la siguiente instrucción o un par adelante. Si solo paso a 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 y cuando no ejecutara esa cadena de instrucciones nuevamente. Es probable que todavía puedas usar un truco como este hoy, ya que los procesadores segmentados buscan la siguiente instrucción. O si sabe que el hardware tiene una instrucción y una memoria caché de datos separadas, puede modificar una cantidad de bytes adelante 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 la memoria caché de datos, y un simulador de conjunto de instrucciones que no tuviera simuladores de caché adecuados no se ejecutaría correctamente. Creo que las soluciones de software solo no te llevarán muy lejos.

Lo anterior es antiguo y bien conocido, no sé lo suficiente sobre las herramientas actuales para saber si ya funcionan en torno a esas cosas. El código que se modifica a sí mismo puede disparar al depurador, pero el humano puede limitarse al problema y luego ver el código que se modifica a sí mismo y trabajar alrededor de él.

Solía ​​ser que los hackers tardaban unos 18 meses en resolver algo, por ejemplo, en los DVD. Ahora tienen un promedio de alrededor de 2 días a 2 semanas (si están motivados) (rayo azul, iphones, etc.). Eso significa que si paso más de unos pocos días en seguridad, es probable que esté perdiendo el 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 que se encuentra dentro del chip se descifra justo antes de la ejecución, de manera que no puede exponer las instrucciones desencriptadas). Eso podría comprarte meses en lugar de días.

También, lea el libro de Kevin Mitnick, El arte de la decepción. Una persona así podría descolgar un teléfono y hacer que usted o un compañero de trabajo le 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 tu seguridad es volada. La seguridad no se trata solo de administrar la tecnología, sino también de los humanos.

Muchas veces, el miedo a que su producto se invierta por ingeniería inversa está fuera de lugar. Sí, puede conseguir 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 engg. eso ? (este trabajo no es una actividad de poco tiempo, para líneas sustanciales de código).

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 libérelo. 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.

Para informarse, lea la literatura académica sobre ofuscación de códigos . Christian Collberg, de la Universidad de Arizona, es un académico 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 que tengo en cuenta es que no puedes evitar que un atacante vea el código que ejecutarás, pero puedes rodearlo de un código que no se ejecuta y cuesta un tiempo exponencial del atacante (utilizando las mejores técnicas conocidas) para descubrir qué fragmentos de su código se ejecutan y cuáles no.

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

  1. ¿Es probable que los "nuevos usuarios" no quieran pagar pero utilicen 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. ¿Tu software necesita entrenamiento / 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 a las preguntas 2 "sí", entonces un modelo de "pago por uso" podría ser apropiado para usted.

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

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

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

Posiblemente su mejor alternativa sea usar la virtualización, que introduce otro nivel de indirección / ofuscación necesario para el bypass, pero como dijo SSpoke en su answer , 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.

Cualquiera que sea el hombre que se reúna, puede ser desmontado.

Por lo general, es cierto que el desmontaje (correcto) suele ser una tarea (un poco más o más difícil), por lo que su oponente debe ser más hábil , pero puede asumir 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.

Asi palabras

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

Muestra mala actitud tuya. No estoy diciendo que para usar o integrar la protección debes saber cómo romperla, pero para usarla sabiamente debes conocer sus debilidades y dificultades. Deberías entenderlo .

(Hay ejemplos de software que utilizan la protección de forma incorrecta, lo que hace que la protección sea prácticamente inexistente. Para evitar hablar de manera vaga, le daré un ejemplo breve en internet: Oxford English Dictionary Second Edition en CD-ROM v4. Puede leer sobre uso fallido de SecuROM en la página siguiente: 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 palabras, redes, fuentes y así sucesivamente )

Todo lleva tiempo.

Si eres nuevo en el tema y no tienes meses o más bien años para meterte apropiadamente en cosas de ER, entonces elige las soluciones disponibles hechas por otros. El problema aquí es obvio, ya están allí, por lo que ya sabe que no están 100% seguros, pero crear su propia nueva protección solo le daría una falsa sensación de estar protegido, a menos que sepa muy bien lo último en tecnología. 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 a los RE comunes y poner una sonrisa en la cara de los experimentados ER después de su (esperemos que interesante) viaje al centro de su aplicación.

En las conversaciones de negocios puede decir que se trata de retrasar la competencia, en la medida de lo posible.

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

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

Dije sobre la virtualización, así que te daré un enlace a un hilo ejemplar de EXETOOLS FORUM : El mejor protector de software: ¿Themida o Enigma Protector? . Te puede ayudar un poco en futuras búsquedas.

Si alguien quiere pasar el tiempo para revertir su binario, entonces no hay absolutamente nada que pueda hacer para detenerlo. Usted puede hacer que sea 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 desmonte algunos binarios.

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

Dicho esto ... es probable que tengas un problema diferente que se pueda resolver de otra manera. ¿Qué estás tratando de proteger? Dependiendo de su problema, es probable que pueda usar el cifrado para proteger su producto.

Sin dados, no puedes proteger tu código para que no lo desarmes. Lo que puede hacer es configurar el servidor para la lógica empresarial y utilizar el servicio web para proporcionarlo para su aplicación. Por supuesto, este escenario no siempre es posible.

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 del 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 hacerlo en secreto. El código siempre se puede interpretar sin importar lo que haga, y (idealmente) el secreto generado solo puede ponerse en peligro por un enfoque masivo de fuerza bruta o por 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 el código si el código no se pudiera descifrar en primer lugar. La raíz del problema es el software crackable. Arregle la raíz de su problema, no lo ofusque simplemente.

Además, cuanto más confuso haga 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 unos años, e incluso un código claro bien escrito puede ser difícil de mantener. No lo hagas peor.

Safe Net Sentinel (anteriormente Aladdin). Pero hay advertencias: su API apesta, la documentación apesta, y ambas son excelentes en comparación con sus herramientas de 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 ''licencia'' para el software. Su SDK encripta y confunde sus ejecutables y bibliotecas, y le permite vincular diferentes características en su aplicación con características grabadas en la clave. 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 creación de una clave virtual, o la manipulación de la comunicación entre la envoltura del tiempo de ejecución y la clave. Su SDK no es muy amigable para los desarrolladores, y es bastante doloroso integrar la protección agregada con un proceso de compilación automatizado (pero es posible).

Antes de que implementáramos la protección HASP HL, había 7 piratas conocidos que habían despojado las protecciones del 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 ralentizó los cálculos intensivos en aproximadamente un 3%. Desde que se lanzó ese software hace aproximadamente 5 años, no se ha encontrado ningún pirata nuevo del producto. El software que protege tiene una gran demanda en su segmento de mercado, y el cliente es consciente de que varios competidores intentan realizar ingeniería inversa (sin éxito hasta ahora). Sabemos que han intentado solicitar ayuda a algunos grupos en Rusia que anuncian un servicio para romper la protección del software, ya que numerosas publicaciones en varios grupos de noticias y foros han incluido las versiones más recientes del producto protegido.

Recientemente probamos su solución de licencia de software (HASP SL) en un proyecto más pequeño, lo cual fue lo suficientemente sencillo para comenzar a trabajar si ya está familiarizado con el producto HL. Parece que funciona; 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á lo suficientemente motivado y tiene mucho dinero para quemar, estoy seguro de que las protecciones ofrecidas por HASP podrían ser evitadas.

LO PRIMERO QUE RECUERDE ACERCA DE OCULTAR SU CÓDIGO : No es necesario que todo su código esté 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 características específicas dentro de mis programas.

La mejor tecnica : Creo que construir en un sistema de ganchos y filtros como lo ofrece WordPress, es el mejor método al tratar de confundir a tus oponentes. Esto le permite cifrar ciertas asociaciones de activación sin en realidad cifrar 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 lo siguiente: la principal razón para descifrar el código no se debe a la distribución malintencionada de las licencias, en realidad es porque NECESITA cambiar su código y realmente NO NECESITA distribuir copias gratuitas.

CÓMO COMENZAR : reserve 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.

PREPARÁNDOSE PARA CIFRIR : Va a estar encriptando en capas con mi sistema, también será un procedimiento muy complejo, así que cree otro programa que será responsable del proceso de encriptación.

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

Repetiré ya que estarás haciendo esto una y otra vez. Vas a crear una cadena base64 y guardarla en otro archivo como una variable que se descifra y representa.

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

PASO TRES : repite el paso dos tantas veces como quieras. Una vez que funcione correctamente sin descifrar los errores, entonces querrá comenzar a construir minas terrestres para sus oponentes.

LAND MINE ONE : querrá mantener el hecho de que se le está notificando un secreto absoluto. Así que incorpore un sistema de correo de advertencia de seguridad de intento de cracker para la capa 2. Esto se activará para informarle los detalles específicos de su oponente si algo va a salir mal.

MINA DE TIERRA DOS : Dependencias. No quieres que tu oponente pueda correr la capa uno, sin las capas 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 script de eliminación que se activará si el programa no está presente, o las otras capas.

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

LO QUE SE DEBE RECORDAR : realmente puede cifrar su código en lugar de basarlo. De esa manera, una simple base64 no descifra el programa.

RECOMPENSA : tenga en cuenta que esto puede ser realmente 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 de promoción para que pueda 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 hombre es el primero en descifrar el código, entonces págale su dinero y conviértete en su amigo. Si es amigo tuyo, no distribuirá tu software. ¡Pregúntale cómo lo hizo y cómo puedes mejorar!

¡BUENA SUERTE!

Contrariamente a lo que dice la mayoría de las personas, en función de su intuición y experiencia personal, no creo que la ofuscación de un programa criptográficamente seguro resulte imposible en general.

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

printf("1677741794/n");

Nunca se 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 se distinga de la función que implementa es imposible, ¡la ofuscación definida de alguna manera más débil todavía puede ser posible!

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

Habiendo dicho que hay cosas que debes hacer, tales como:

  • Utilice el nivel de optimización más alto posible (la ingeniería inversa no solo se trata de obtener la secuencia de ensamblaje, sino también de comprender el código y de portarlo a un lenguaje de nivel superior como C). El código altamente optimizado puede ser una b --- h para seguir.
  • Haga estructuras densas al no tener tipos de datos más grandes de lo necesario. Reorganizar los miembros de la estructura entre los lanzamientos oficiales de código. Los campos de bits reorganizados en 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 compare las diferencias. La función que lo realiza no debe pasarle punteros a los vectores, sino usar punteros externos definidos en otros módulos como (pseudo-C código) "char * p1 = & string1 [539];" y "char p2 = & string2 [-11731];". De esa manera no habrá punteros apuntando exactamente a las dos cadenas. En el código de comparación, a continuación, compare para " (p1-539 + i) - * (p2 + 11731 + i) == algún valor". El cracker pensará que es seguro cambiar la cadena1 porque nadie parece hacer referencia a ella. Enterrar la prueba en algún lugar inesperado.

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

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

Pero 3 notas adicionales:

  1. Es posible hacer que la ingeniería inversa sea imposible, PERO (y esto es muy grande, pero), no se puede hacer en una CPU convencional. También hice mucho desarrollo de hardware, y con frecuencia se utilizan FPGA. Por ejemplo, el 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 usar esta función para realmente descifrar las incursiones para el PowerPC, que no es accesible por el exterior u otro software, o incluso ejecutar el comando en el hardware. Como el FPGA ha incorporado el cifrado AES para su flujo de bits de configuración, no se pudo aplicar 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 por protocolo. No dice qué tipo de protocolo es, pero cuando se trata de un protocolo de red, al menos debería protegerlo contra la detección de redes. Esto se puede hacer por cifrado. Pero si desea proteger el cifrado / descifrado de un propietario del software, volverá a la ofuscación.

  3. Haga que su programa no sea descargable / ejecutable. Intente utilizar algún tipo de detección de depuración y aplíquelo, por ejemplo, en alguna fórmula o agregando 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 es donde se ejecuta con normalidad, pero realiza un cálculo, operación o cualquier otro error. Por ejemplo, conozco algunos juegos ecológicos que tenían una protección contra copias realmente desagradable (sé que no quieres protección contra copia, pero es similar): la versión robada modificó los recursos extraídos después de 30 minutos de juego, y de repente solo tienes uno recurso. El pirata simplemente lo rompió (es decir, hizo ingeniería inversa) - verificó si corría, y Volia lo soltó. Tales cambios leves de comportamiento son muy difíciles de detectar, esp. Si no aparecen instantáneamente a detección, solo se retrasan.

Por lo tanto, finalmente sugeriría: calcule cuál es el beneficio de la gente al aplicar ingeniería inversa a su software, tradúzcalo en algún tiempo (p. Ej., Utilizando el salario más barato de la India) y haga que la ingeniería inversa cuente con un mayor costo.

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, entonces está moralmente obligado a utilizar el mejor código que esté abierto y totalmente examinado por los expertos.

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 parámetros más triviales, como el uso actual mientras se ejecuta. (Es, excepto por técnicas de invasión de hardware, donde usted desmonta con cuidado el chip y utiliza equipos avanzados 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 una sorpresa fría, envíame el resultado de tus mejores esfuerzos. (Póngase en contacto conmigo a través de mis sitios web). Pocos que he visto en las respuestas me presentan un obstáculo considerable. Si desea ver cómo funciona el sofisticado código de ingeniería inversa, debería estudiar los sitios web con desafíos de ingeniería inversa.

Tu pregunta podría necesitar 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 sería enviar un mensaje cifrado RSA (incluso una clave pública), ¿qué gana al mantener el protocolo en secreto? Para todos los propósitos 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 usa un desensamblador para responder preguntas sobre el código. Si desea una mayor seguridad, debe hacer algo que evite de manera comprobada que el agente obtenga tales respuestas.

Puede hacerlo confiando en el Programa de detención ("¿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 a un programa que tenga diversos grados de dificultad para razonar; un gran candidato es el programa de razonamiento sobre alias ("punteros").

Collberg y otros 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 el código fuente C o C ++.

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

Para evitar la ingeniería inversa, no debe dar el código a los usuarios. Dicho esto, recomiendo el uso de una aplicación en línea ... sin embargo (ya que no proporcionó un contexto) eso podría ser inútil para el suyo.