Binarios autovalidantes?

Question

Mi pregunta es bastante simple: usted es un archivo ejecutable que muestra "Acceso otorgado" o "Acceso denegado" y las personas malvadas intentan comprender su algoritmo o parchear sus entrañas para hacer que diga "Acceso otorgado" 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 pacificar tus preocupaciones, no soy una de esas galletas. Mi objetivo es crackmes.

Puede encontrar Crackmes en, por ejemplo, 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 muestra "Acceso otorgado" o "Acceso denegado" según el número de serie. El objetivo es hacer que este resultado ejecutable sea "Acceso otorgado" todo el tiempo. Los métodos que puede usar pueden estar restringidos por el autor (sin parches, sin desmontar) o involucrar todo lo que pueda hacer con un editor binario, objdump y hexadecimal. Cracking crackmes es una parte de la diversión, sin embargo, como programador, me pregunto cómo se pueden crear crackmes que son difíciles.

Básicamente, creo que el crackme consta de dos partes principales: una cierta verificación en serie y el código que lo rodea.

Es muy posible hacer la verificación en serie difícil de rastrear simplemente usando el ensamblaje, por ejemplo, tengo la idea de tomar la serie como entrada para un microprocesador simulado que debe terminar en cierto estado para obtener el serial aceptado. Por otro lado, uno puede crecer barato y aprender más sobre las formas criptográficas fuertes para asegurar esta parte. Por lo tanto, hacer esto lo suficientemente difícil como para hacer que el atacante intente parchear el ejecutable no debe ser el t 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 que sé que se puede revertir, en la duda, se arrancan partes del binario que intentas crackear y se lanzan seriales al azar hasta que acepte). ¿Cómo podemos evitar que un atacante anule saltos en el binario para que nuestro binario acepte algo?

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

Mis pensamientos actualmente consisten en:

• comprobar localizaciones explícitas en el binario para ser saltos.
• suma de comprobación de partes del código binario y compare las sumas de control calculadas en tiempo de ejecución con esas.
• tienen comprobaciones de tiempo de ejecución positivas y negativas para sus funciones en el código. Con efectos secundarios en la verificación serial. :)

¿Puedes pensar en más formas de molestar a un posible atacante por más tiempo? (por supuesto, no puede mantenerlo alejado para siempre, cuando se rompan todos los controles, a menos que logre romper un generador de suma de control al poder insertar la suma de verificación correcta para un programa en el programa mismo, jeje)

Answer 1

Te estás metiendo en "Técnicas antirreversión". Y básicamente es un arte. Peor es que, incluso si pisotea a los novatos, existen "complementos anti-anti-reversibles" para olly e IDA Pro que pueden descargar y eludir muchas de sus contramedidas.

Las medidas del contador incluyen la detección de depurador mediante las API del depurador de trampas, o la detección de 'pasos únicos'. Puede insertar código que después de detectar un error de depuración, continúa funcionando, pero comienza a actuar en momentos aleatorios mucho más tarde en el programa. Es realmente un juego del gato y el ratón y las galletas tienen una ventaja significativa.

Echa un vistazo a ... 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 una muy buena información anti-inversión y pasos a través de las técnicas. Un gran lugar para comenzar si te estás invirtiendo en general.

Answer 2

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

Dedicas mucho esfuerzo escribiendo código para proteger tu binario. Los chicos malos gastan menos esfuerzo en descifrarlo (generalmente son más experimentados que tú) y luego liberan la grieta para que todos puedan eludir tu protección.Las únicas personas a las que molestarás son aquellas personas honestas a las que su protección les haya molestado.

Simplemente considere la piratería como un costo de negocio: el costo incremental del software pirateado es cero si se asegura de que todo el soporte se haga solo para los clientes que pagan.

Answer 3

Hay tecnología TPM: tpm on wikipedia

Se le permite almacenar las sumas de comprobación criptográfica de un binario en el chip especial, que podría actuar como la verificación de una sola vía.

Nota: TPM tiene una especie de mala reputación porque podría usarse para DRM. Pero para los expertos en el tema, eso es algo injusto, e incluso hay un grupo open-TPM que permite a los usuarios de Linux controlar exactamente cómo se usa su chip TPM.

Answer 4

Una de las soluciones más sólidas para este problema es Trusted Computing. Básicamente cifrarías la aplicación y transmitirías la clave de descifrado a un chip especial (el Trusted Platform Module). El chip solo descifraría la aplicación una vez que haya verificado que la computadora está en un estado "de confianza": sin visualizadores/editores de memoria, sin depuradores etc. Básicamente, necesitaría hardware especial para poder ver el código del programa descifrado.

Answer 5

Por lo tanto, desea escribir un programa que acepte una clave al principio y la almacene en la memoria, y luego la recupere del disco. Si es la clave correcta, el software funciona. Si es la clave incorrecta, el software se bloquea. El objetivo es que a los piratas les resulte difícil generar una clave de trabajo, y es difícil parchear el programa para que funcione con una clave sin licencia.

Esto realmente se puede lograr sin hardware especial. Considera nuestro código genético Funciona basado en la física de este universo. Intentamos hackearlo, crear medicamentos, etc., y fracasamos miserablemente, creando usualmente toneladas de efectos secundarios indeseables, porque aún no hemos revertido completamente el complejo "mundo" en el que evolucionó el "código" genético para operar . Básicamente, si está 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 de seguridad, como lo demuestra el software actual que se descifra tan fácilmente.

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

El problema es que su plataforma probablemente se ejecutará en un 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 para la ingeniería inversa. Por supuesto, eso puede significar que la barra se eleva un poco para que el nivel de complejidad requerido de su plataforma sea lo suficientemente difícil como para 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 adición, la séptima adición devuelve el resultado multiplicado por PI dividido por la raíz cuadrada del registro 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 código en sí, a fin de decodificar los resultados correctos. Por lo tanto, su código se escribiría en base al conocimiento del complejo comportamiento subyacente de una plataforma que usted diseñó. Sí, comería ciclos de procesador, pero alguien tendría que aplicar ingeniería inversa al pequeño comportamiento sorpresa y rediseñarlo en cualquier código nuevo para que se comporte correctamente. Además, su propio código sería difícil de modificar una vez escrito, porque colapsaría en una complejidad irreductible, con cada línea dependiendo 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 tendría un ingeniería inversa de su plataforma antes de que pudieran realizar ingeniería inversa y modificar su código, sin efectos secundarios debilitantes.

Answer 6

gran artículo sobre la protección de copia y la protección de la protección Keeping the Pirates at Bay: Implementing Crack Protection for Spyro: Year of the Dragon

La idea más interesante mencionado ahí que aún no se ha mencionado es en cascada fracasos - usted tiene que modifican las sumas de comprobación de un solo byte que causa otra suma de comprobación a fallar . Finalmente, una de las sumas de comprobación hace que el sistema se bloquee o haga algo extraño. Esto hace que los intentos de piratear su programa parezcan inestables y hace que la causa ocurra lejos del accidente.