Cita:
Empezado por WkaymQ48
|
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.