security - bot - Binarios de autovalidación?
binary token (6)
Mi pregunta es bastante simple: usted es un archivo ejecutable que emite "Acceso otorgado" o "Acceso denegado" y las personas malvadas intentan comprender su algoritmo o parchear sus entrañas para 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.
Crackmes se puede encontrar 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 que la verificación en serie sea 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 un cierto estado para poder aceptar la serie. Por otro lado, uno puede crecer barato y aprender más acerca de las formas criptográficas fuertes para asegurar esta parte. Por lo tanto, hacer esto lo suficientemente duro como para hacer que el atacante intente parchear el ejecutable no debería ser tan 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 aleatorios hasta que acepte). ¿Cómo podemos evitar que un atacante anule saltos en el binario para que nuestro binario acepte algo?
He estado buscando un poco sobre este tema, pero la mayoría da como resultado seguridad binaria, binarios de autoverificación y cosas así terminan en artículos que intentan evitar ataques en un sistema operativo utilizando binarios comprometidos. al firmar ciertos binarios y validar esas firmas con el kernel.
Mis pensamientos actualmente consisten de:
- verificando ubicaciones explícitas en el binario para ser saltos.
- Se suman las partes del binario y se comparan las sumas de comprobación calculadas en tiempo de ejecución con esas.
- tener 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 puedes mantenerlo alejado para siempre, cuando se corten todos los controles, a menos que hayas logrado romper un generador de suma de comprobación al poder insertar la suma de comprobación correcta para un programa en el programa mismo, jeje)
Creo que estas cosas generalmente son más problemas de lo que valen.
Gastas 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.
Hay tecnología TPM: tpm en wikipedia
Le permite almacenar las sumas de verificación criptográfica de un binario en un chip especial, que podría actuar como verificación de un solo sentido.
Nota : TPM tiene una 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 TPM abierto que permite a los usuarios de Linux controlar exactamente cómo se usa su chip TPM.
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 de contador incluyen la detección del 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 ... http://www.openrce.org/reference_library/anti_reversing - Algo de lo que hay por ahí.
http://www.amazon.com/Reversing-Secrets-Ingeniería-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.
Una de las soluciones más fuertes 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 Módulo de plataforma confiable ). El chip solo descifraría la aplicación una vez que haya verificado que la computadora está en un estado de "confianza": no hay visualizadores / editores de memoria. sin depuradores, etc. Básicamente, necesitaría hardware especial para poder ver el código del programa descifrado.
Entonces, 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 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 truco es que su plataforma probablemente se ejecutará en un hardware común, lo que hace que su plataforma sea más fácil de aplicar 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.
Gran artículo sobre protección contra copias y protección de la protección Mantener a raya a los piratas: implementación de Crack Protection para Spyro: el 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 que causa que falle otra suma de comprobación. 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.