Crackme 03 by _Enko Actualizado winxpsp3 compatible

[Flamer]

orale ya esta porque yo buscaba otra instruccion de mensage.
Lo que tenemos que hacer es buscar la instruccion de comparacion cual nosmanda al error y cual no

[_Enko]

Las comprobaciones estan para protegerte y dar pistas.... si te las salteas, 99% seguro que el programa crashee.

[Flamer]

mi objetivo no es invertir el salto si no que encontrando esa instruccion de comparacion mas arriba debe benir el algoritmo que nos crea el serial correcto

[_Enko]

Mh...este no es un crackme de tipo visual basic, no vas a encontrar esto:

Código [Seleccionar] Expandir


lpszValidSerial = GenerateSerial(lpszUser);
if(strcmp(lpszValidSerial, lpszSerial) {
         GoodBoy();
} else {
         BadBoy();
}


La regla numero 1 de las protecciones:
Nunca, bajo ninguna circunstancia, NUNCA se coloca la rutina que genera serials validos dentro del programa.


Eso solamente lo hacen programadores inexpertos o perezosos que no son capaces de crear la rutina inversa de la generacion de serials. Es decir, la rutina de comprobacion.

Saludos

[Tinkipinki]

Hola _Enko:

La regla numero 1 de las protecciones:
Nunca, bajo ninguna circunstancia, NUNCA se coloca la rutina que genera serials validos dentro del programa.

Referente tu comentario quieres decir que las generaciones i comparaciones de serials se suelen hacer pasando parametros a una dll que a su vez retorna algun dato que luego interpreta el ejecutable..?

Haber si los que vais siguiendo el tema os animais un poco y decis la vuestra, ....es que esta feo que haya de ser el autor el que nos vaya guiando hacia la posible solucion.

Por mi modesta parte voy tirando y llego aqui. Creo que no es gran cosa, pero bueno por animar un poco:

Entre 004028D8 y 00402917 creo que hay un bucle que analiza el serial que hemos entrado  pero no logro saber que hace.
Antes en 004028C7 hay un SSCANF formateado con %08X pero lo que no tengo claro es lo que devuelve si la longitud del serial entrado o comprueba que no hayan espacios.
Creo que el valor devuelto es en octal por %X pero no se que pinta el 08.
¿Cómo lo veis vosotros.....?

Saludos

[Flamer]

pero aclarame una cosa dependiendo el usuario que le pongas es el serial que te genera que no

[_Enko]

No, no tiene nada que ver con DLL. Es matematica o  matematica booleana/logica pura.


Suponte esta pseudo rutina de generacion:
(usuario 4 letras)
(serial 4 letras)

usuario xor llave = serial.


de ahi se puede deducir:
serial xor usuario = llave
serial xor llave = usuario




la rutina de comprobacion NUNCA DEBE SER
serial valido = usuario xor llave
comparar (serial valido, serial introducido)

Porque no? porque le estas dando la respuesta al cracker.

Lo que si puede hacerse, es:
llave prueba = serial xor  usuario
comprar(llave prueba, llave maestre)


obviamente XOR es solamente simbolico, la rutinas de generacion/validacion suelen ser mas complicadas, mas rebuscadas, etc... Pero el principio basico es el mismo.
NUNCA, NUNCA colocar la rutina de generacion dentro del programa. Si obviamente de comprobacion.

y la regla basica del reverser/cracker:  La rutina de generacion es la inversa de la rutina de comprobacion.
En estos casos, toca pensar un poquito. Si el programa tuviera la rutina de generacion, es ya asunto resuelto.

Espero haberte aclarado la duda y no haberte confundido mas.



Flamer:
En mi crackme, existe solamente un serial valido para cada usuario. Si le cambias 1 letra al usuario, minimo 8 bytes del serial van a cambiar.

Tinki

Creo que el valor devuelto es en octal por %X pero no se que pinta el 08.

fijate documentacion sobre alguna de estas funciones: sscanf/wsprintf/sprintf/printf etc...
%X o %iX indica un numero hexadecimal.
8 indica la cantidad de caracteres a devolver
0 antepuesto al 8, indica que si faltan caracteres, en vez de poner espacios, coloca 0 al principio.
es decir 1234 se convierte en '00001234'

[Flamer]

Referente tu comentario quieres
decir que las generaciones i
comparaciones de serials se
suelen hacer pasando
parametros a una dll que a su vez
retorna algun dato que luego
interpreta el ejecutable..?

no es asi no utilisa una dll el codigo que genera los seriales esta dentro de un call

[MCKSys Argentina]

El reto esta en descifrar el codigo (Call de 402689): hallar el inicio y el fin (los cuales estan en el serial) y despues usar herramientas criptograficas (Cryptool) para descifrar el codigo, ya que a cada byte hay que XORearlo con cada 1 de los 32 bytes de la llave.

De los 32 bytes, los 8 primeros los brinda el proggie: 1B1C1D1F (en chars)

Los restantes son los que salen del resultado de la funcion 4028B5 (esta es la que habria que reversear), aplicados a los chars restantes del serial.

Por lo pronto, haciendo un reg.txt que comience con 000000000000F1E1FD9 , permite pasar el primer checkeo (al menos eso me da a mi). El resto deberian ser 25 chars (hexa?).

Esto lo he sacado analizando el EXE que no funcionaba, asumo que el que funciona deberia ser identico (todavia no lo pude mirar  )

Eso es todo por ahora...

[_Enko]

El exe que "no funcionaba" si es identico, pero la 2da y la 3ra llave maestra (inicio/fin) varian porque obviamente la ejecutable varia.

Al principio creia que la ejecutable era muy dificil de parchear, pero ahora que lo estoy viendo, sabiendo la info que tienes, es perfectamente factible  realizar un self uncrypt al principio de la ejecutable y llamar la rutina de registro ya decifrada.


para hayar el inicio y el fin no es tan complicado como parece, la ejecutable tiene tan solo unos 8-9 bloques que parecen encryptados.

Como pequeña ayuda, añado que los bloques cifrados son enteros, es decir, desde el ret del procedimiento anterior hasta el comienzo del proximo procedimiento.
Esta hecho asi a proposito para facilitar el decifrado.

Sobre cryptool, no hara falta, dentro del bloque encryptado hay cadenas de texto... y sabiendo que son caracteres hexa... las posibilidades son muy pocas, manaualmente con un poco de tiempo se pueden deducir.