¿Binarios autovalidantes?

Question

Mi pregunta es bastante sencilla:Eres un archivo ejecutable que muestra "Acceso concedido" o "Acceso denegado" y personas malvadas intentan comprender tu algoritmo o parchear tus entrañas para hacerte decir "Acceso concedido" todo el tiempo.

Después de esta introducción, es posible que se pregunte qué estoy haciendo.¿Va a descifrar Diablo3 una vez que salga?Puedo apaciguar tus preocupaciones, no soy uno de esos crackers.Mi objetivo son los crackmes.

Crackmes se puede encontrar, por ejemplo, en www.crackmes.de.Un Crackme es un pequeño ejecutable que (la mayoría de las veces) contiene un pequeño algoritmo para verificar una serie y genera "Acceso concedido" o "Acceso denegado" dependiendo de la serie.El objetivo es hacer que este resultado ejecutable tenga "Acceso concedido" todo el tiempo.Los métodos que puede usar pueden estar restringidos por el autor (sin parches, sin desensamblaje) o involucrar cualquier cosa que pueda hacer con un binario, objdump y un editor hexadecimal.Definitivamente, crackear crackmes es una parte de la diversión, sin embargo, como programador, me pregunto cómo se pueden crear crackmes que sean difíciles.

Básicamente, creo que el crackme consta de dos partes principales:una determinada verificación de serie y el código circundante.

Es muy posible hacer que la verificación del número de serie sea difícil de rastrear simplemente usando el ensamblaje; por ejemplo, tengo la idea de tomar el número de serie como entrada para un microprocesador simulado que debe terminar en un estado determinado para que se acepte el número de serie.Por otro lado, uno podría volverse barato y aprender más sobre formas criptográficamente sólidas de asegurar esta parte.Por lo tanto, hacer esto lo suficientemente difícil como para que el atacante intente parchear al ejecutable no debería ser difícil.

Sin embargo, la parte más difícil es asegurar el binario.Supongamos una verificación en serie perfectamente segura que no se puede revertir de alguna manera (por supuesto, sé que se puede revertir; en caso de duda, arrancas partes del binario que intentas descifrar y le arrojas números de serie aleatorios hasta que acepte).¿Cómo podemos evitar que un atacante simplemente anule los saltos en el binario para que nuestro binario acepte algo?

He estado buscando un poco sobre este tema, pero la mayoría de los resultados sobre seguridad binaria, binarios de autoverificación y cosas así terminan en artículos que intentan prevenir ataques a un sistema operativo que utiliza binarios comprometidos.firmando ciertos binarios y validando esas firmas con el kernel.

Mis pensamientos actualmente consisten en:

• comprobando ubicaciones explícitas en el binario para que sean saltos.
• Sumar partes del binario y comparar las sumas de verificación calculadas en tiempo de ejecución con aquellas.
• tenga comprobaciones de tiempo de ejecución positivas y negativas para sus funciones en el código.Con efectos secundarios en la verificación en serie.:)

¿Se te ocurren más formas de molestar por más tiempo a un posible atacante?(por supuesto, no puedes mantenerlo alejado para siempre, en algún momento, todos los controles se romperán, a menos que hayas logrado romper un generador de suma de control al poder incrustar la suma de control correcta para un programa en el programa mismo, jeje)

Answer 1

Te estás metiendo en "Técnicas anti-reversión".Y es un arte básicamente.Lo peor es que incluso si pisoteas a los novatos, existen "complementos anti-anti inversión" para olly e IDA Pro que pueden descargar y evitar muchas de tus contramedidas.

Las contramedidas incluyen la detección del depurador mediante las API del depurador de captura o la detección de "pasos únicos".Puede insertar código que, después de detectar una interrupción del depurador, continúe funcionando, pero comience a funcionar en momentos aleatorios mucho más adelante en el programa.Es realmente un juego del gato y el ratón y las galletas tienen una ventaja significativa.

Verificar...http://www.openrce.org/reference_library/anti_reversing - Algo de lo que hay por ahí.

http://www.amazon.com/Reversing-Secrets-Engineering-Eldad-Eilam/dp/0764574817/ - Este libro tiene muy buena información anti-reversa y explica las técnicas.Excelente lugar para comenzar si desea invertir en marcha atrás en general.

Answer 2

Creo que estas cosas generalmente causan más problemas de lo que valen.

Dedicas mucho esfuerzo a escribir código para proteger tu binario.Los malos dedican menos esfuerzo a descifrarlo (generalmente tienen más experiencia que tú) y luego liberan el crack para que todos puedan eludir tu protección.Las únicas personas a las que molestarás son aquellas personas honestas que se sienten incómodas con tu protección.

Simplemente considere la piratería como un costo de negocio: el costo incremental del software pirateado es cero si garantiza que todo el soporte se brinda únicamente a los clientes que pagan.

Answer 3

Existe la tecnología TPM: tpm en wikipedia

Le permite almacenar las sumas de verificación criptográficas de un binario en un chip especial, que podría actuar como verificación unidireccional.

Nota:TPM tiene mala reputación porque podría usarse para DRM.Pero para los expertos en el campo, eso es algo injusto, e incluso existe una TPM abierto grupo que permite a los usuarios de Linux controlar exactamente cómo se utiliza su chip TPM.

Answer 4

Una de las soluciones más sólidas a este problema es Computación confiable.Básicamente, cifraría la aplicación y transmitiría la clave de descifrado a un chip especial (el Modulo de plataforma confiable), el chip sólo descifrará la aplicación una vez que haya verificado que la computadora se encuentra en un estado "confiable":sin visores/editores de memoria, sin depuradores, etc.Básicamente, necesitarías un hardware especial para poder ver el código del programa descifrado.

Answer 5

Entonces, desea escribir un programa que acepte una clave al principio y la almacene en la memoria, recuperándola posteriormente del disco.Si es la clave correcta, el software funciona.Si es la clave incorrecta, el software falla.El objetivo es que a los piratas les resulte difícil generar una clave que funcione y que sea difícil parchear el programa para que funcione con una clave sin licencia.

En realidad, esto se puede lograr sin hardware especial.Consideremos nuestro código genético.Funciona basándose en la física de este universo.Intentamos hackearlo, crear drogas, etc., y fracasamos estrepitosamente, generalmente creando toneladas de efectos secundarios indeseables, porque todavía no hemos realizado ingeniería inversa por completo al complejo "mundo" en el que el "código" genético evolucionó para operar. .Básicamente, si estás ejecutando todo en un procesador común (un "mundo" común), al que todos tienen acceso, entonces es prácticamente imposible escribir un código tan seguro, como lo demuestra el software actual que se puede descifrar con tanta facilidad.

Para lograr seguridad en el software, esencialmente tendría que escribir su propia plataforma suficientemente compleja, que otros tendrían que realizar ingeniería inversa completa y exhaustiva para modificar el comportamiento de su código sin efectos secundarios impredecibles.Sin embargo, una vez que su plataforma tenga ingeniería inversa, volverá al punto de partida.

El problema es que su plataforma probablemente se ejecutará en hardware común, lo que hace que su plataforma sea más fácil de realizar ingeniería inversa, lo que a su vez hace que su código sea un poco más fácil de realizar ingeniería inversa.Por supuesto, eso puede significar que el listón se ha elevado un poco para que el nivel de complejidad requerido de su plataforma sea lo suficientemente difícil de realizar ingeniería inversa.

¿Cómo sería una plataforma de software suficientemente compleja?Por ejemplo, quizás después de cada 6 operaciones de suma, la séptima suma devuelve el resultado multiplicado por PI dividido por la raíz cuadrada del log del módulo 5 de la diferencia del número total de operaciones de resta y multiplicación realizadas desde la inicialización del sistema.La plataforma tendría que realizar un seguimiento de esos números de forma independiente, al igual que el propio código, para poder decodificar los resultados correctos.Por lo tanto, su código se escribiría basándose en el conocimiento del complejo comportamiento subyacente de una plataforma que usted diseñó.Sí, consumiría ciclos de procesador, pero alguien tendría que aplicar ingeniería inversa a ese pequeño comportamiento sorpresa y rediseñarlo en cualquier código nuevo para que se comportara correctamente.Además, su propio código sería difícil de cambiar una vez escrito, porque colapsaría en una complejidad irreducible, y cada línea dependería de todo lo que sucedió antes.Por supuesto, habría mucha más complejidad en una plataforma suficientemente segura, pero el punto es que alguien habría realizado ingeniería inversa en su plataforma antes de poder realizar ingeniería inversa y modificar su código, sin efectos secundarios debilitantes.

Answer 6

Gran artículo sobre protección de copia y protección de la protección. Manteniendo a los piratas a raya:Implementación de protección contra crack para Spyro:Año del dragón

La idea más interesante mencionada allí que aún no se ha mencionado son las fallas en cascada: tiene sumas de verificación que modifican un solo byte y provoca que otra suma de verificación falle.Finalmente, una de las sumas de verificación hace que el sistema falle o haga algo extraño.Esto hace que los intentos de piratear su programa parezcan inestables y hace que la causa se produzca muy lejos del fallo.