Proteccion de software

[WkaymQ48]

Esto me recuerda este otro hilo:

Juego (buscar Clave)
http://www.delphiaccess.com/forum/an...buscar-clave)/

En el nuestro amigo Caral propone un pequeño juego donde hay que "adivinar" la clave de un ejecutable, para saber como son de efectivos estos métodos de protección.





Spoiler: Al final la adivinan, y ademas publican un crack con código fuente y todo

[Casimiro Notevi]

No había visto ese hilo, interesante.

[Neftali [Germán.Estévez]]

Empezado por WkaymQ48

Juego (buscar Clave)
http://www.delphiaccess.com/forum/an...buscar-clave)/

Tampoco había visto ese hilo... Interesante.

Me he entretenido un rato y al final ha salido.
Para que te hagas una idea, yo que no soy nada del otro mundo en estos temas, he sacado la clave en un rato. Y hace bastante tiempo que ya no lidio con estas herramientas; Alguien que las tenga "por la mano" supongo que sería bastante más rápido.

* Tal como comentan en ese hilo, la clave para el primer intento es: hola289528519
* Tal como explica Caral, la clave es diferente según el intento, así que para el segundo intento y el tercero, funciona: hola289492718

En este caso, el primer ataque (al menos yo lo haría así) se hace para intentar adivinar las claves (OPCION1).

Una de las premisas básicas a la hora de utilizar claves, es intentar no compararlas directamente en memoria, es decir, no comparar directamente la clave que ha puesto en usuario, con la clave correcta del programa, para saber si es correcta. Si se hace así, lo que pasa es que si detienes el programa en memoria en el momento de la comparación, puedes ver en memoria lo siguiente:



El 1111111111 es la clave con la que yo he intentado entrar (1er intento) y la otra es con la que la está comparando (correcta).
Si hacemos lo mismo para el segundo (2222222222) y tercer intento (3333333333) veremos lo siguiente:





Tan fácil como eso. A tener en cuenta si estamos generando una clave para nuestro programa.

Si esta opción no es viable, lo otro que se puede intentar hacer (y que es bastante habitual) es "modificar" el programa para que funcione de una forma diferente (OPCION2).
En este caso, como sabemos que al introducir una clave, el programa la compara con "la buena" y según sea buena o no, hace una cosa u otra, lo que hacemos es cambiar el resultado de la comparación.
Es decir, el programa ahora hace....
(1) Si las claves son iguales, continuo (correcto)
(2) Si las claves no son iguales, paro y saco ventana de aviso.

Lo que intentaremos es que haga lo siguiente (al cambiar la comparación):
(1) Si las claves son iguales, error
(2) Si las claves no son iguales, continúo...

En estos casos se intenta buscar el lugar de la comparación para "atacar" en ese punto.
Si realizamos un dump del programa, podemos encontrar lo siguiente:



Basta ahora con buscar esa referencia y cambiar el JNZ (Jump No Zero) por JZ (Jump Zero); Es decir, realizamos la comparación "al negativo".
Con esto bastará para que si introducimos una clave incorrecta, ahora "salte" al procedimiento correcto y si introducimos la clave correcta nos de error y salga el cuadro de diálogo.

¿Porqué de esta explicación?
Bueno, creo que cualquiera que esté pensando en desarrollar un sistema de protección, debería al menos (como me tocó hacer a mi en su día) dedicar un tiempo a estudiar "mínimamente" los sistemas de "desprotección". Y esta explicación intenta ser la prueba y el "porqué" de ello.
He visto sistemas que calculan números y claves complejas a partir de los indicadores de Hardware del sistema e infinidad de números, y luego una vez realizado eso y con una clave "más larga que un día sin pan", resulta que hacen una comparación en memoria (como la del principio) para ver si es correcta. Lo que significa que has pasado 1 semana programando un sistema de protección que alguen con un poco de práctica se "salta" en 5 minutos.

Al igual que esta, hay una serie de "normas básicas" que cualquier sistema de protección debe evitar. Y a esas llegas a la conclusión cuando has visto cómo funcionan "mínimamente" los sistemas inversos de desprotección; De ahí mi recomendación de estudiarlos (un poquito, al menos), junto con las herramientas que se utilizan (NOTA).

No es mi interés que aquí la gente se dedique y aprenda a hackear/crackear programas y no es para eso para lo que he hecho esta explicación. Pero si somos programadores y realizamos sistemas de protección, más nos vale que aprendamos lo necesario, para que no sean una pérdida de tiempo. Al igual que se aprende lo fácil que es "saltarse" determinadas protecciones, también se aprenden técnicas que dificultan e incomodan muuuuuuuuuucho a la persona que está intentando desproteger el programa. Al menos que si lo van a hacer, lo tengan que "sudar"...

NOTA: Por otro lado, muchas de las herramientas que se utilizan para "desproteger" programas y aplicaciones, son muy potentes y pueden ser de mucha utilidad, si se usan en el día a día para un programador (realizando otras tareas), sobre todo relacionadas con errores, trace, y optimización de aplicaciones.

Un saludo.

[Casimiro Notevi]

[WkaymQ48]

Solo comentar dos consejos muy sencillos para evitar los errores comentados por neftali.

1. Usar un hash para las comparaciones. Es decir nunca guardar la clave en claro, guardar en su lugar un hash de la clave y hacer comparaciones del tipo hash(clave_introducida)=hash_guardado, así si alguien hace un debug no tendrá forma de averiguar la clave original.
2. Usar "inline". Para evitar que alguien no "borre" el "if" podemos utilizar un MONTON de "if", seguira pudiendo hacerlo pero si ponemos los bastantes puede que se aburra, ademas le sera dificil saber si los elimino todos. La forma mas sencilla de hacer esto es crear una función del tipo "function ClaveCorrecta: Boolean; inline;" y llamarla al principio de cada función de nuestro programa Al usar "inline" el código de la función se replicara tantas veces como se use por lo que nuestro "pirata" tendrá que parchear un montón de funciones.

No son la panacea, pero algo si ayudan

[look]

Empezado por Neftali

Tampoco había visto ese hilo... Interesante.


Basta ahora con buscar esa referencia y cambiar el JNZ (Jump No Zero) por JZ (Jump Zero); Es decir, realizamos la comparación "al negativo".
Con esto bastará para que si introducimos una clave incorrecta, ahora "salte" al procedimiento correcto y si introducimos la clave correcta nos de error y salga el cuadro de diálogo.

Hola amigo, esta muy interesante el tema, me gustaria saber cual seria el procedimiento para cambiar esos valores y que herramientas has utilizado para debugear el programa como se ve en las imagenes que muestras, y por las herramientas que mencionas para desproteccion y optimizacion ¿ Podrias mencionarme alguna?

[Neftali [Germán.Estévez]]

La herramienta para debug es OllyDbg; Ya la comentaba Seoane en el hilo original, con en que hemos empezado las pruebas.
Para temas de dependencias y saber qué ficheros se están utilizando, ya hemos hablado aquí alguna vez de Dependency Walker. Te aseguro que más de una vez me ha sacado de algún aprieto con errores "raros" por DLL's de versiones incorrectas.
DLLExp de NirSoft o ADLLExports para ver qué funcionan exportan las DLL's. Muy útil para saber si una determinada DLL trabaja como servidor COM, o conocer las cabeceras que exporta.