Crackme 3 by _Enko
Objetivo: Habilitar los menus desactivados registrando el programa. Pueden usar el metodo que desean, patch/crack/keygen
Dificultad:Media
He tardado un par de horas depurando el codigo para que este super-b
Descripcion: Es una aplicacion que al entrar en sus menus, nos dice que la aplicacion no esta registrada y que para que se puedan utilizar esas funciones, primero debemos registrar el programa.
ScreenShot
(http://oi55.tinypic.com/350w3zq.jpg)
Links descarga
Mediafire
http://www.mediafire.com/?94pn1yw33x9wa9r
MegaUpload
http://www.megaupload.com/?d=TSHEX5NK
ATENCION
Si no les abre los menus, usen esta version winxsp3 compatible
http://www.mediafire.com/?x0o8xzexy50tga2
Sobretodo:Diviertanse y no se desesperen.
Saludos.
Hola _Enko:
No se le pasara a alguien mas pero ami solo se me abre la ventana principal del programa y no puedo acceder a ningun menu, se bloquea. :-[
OS: Win Xp SP3
Ah... creo que ya se a que te refieres, es extraño, probé en mi pc en xp y win7 y funciona bien, pero aqui en el trabajo no.
a alguien mas le pasa?
Ya veo el problema, es con el MessageBoxA que no se muestra por alguna extraña razon....
me extraña porque en mi pc funcionaba perfectamente que tambien tiene sp3 y win7. Pero aqui en la pc del curro, no hay forma.
En XP SP3 (VM) no funciona... :P
He probado en 2 portatiles tambien con XP SP3 y sigue sin funcionar.
Igual nos falta alguna libreria.
Saludos
Cita de: MCKSys Argentina en 16 Agosto 2011, 17:44 PM
En XP SP3 (VM) no funciona... :P
A que te refieres con VM? Virtual Machine?
Claro
Aun sin funcionar, lo estoy probando :P
Ahora, pregunto: Hay 1 solo serial que registra el programa o existen varios?
Hola, existen muchisimos serials que lo pueden registrar.
El programa, cuando das click a un menu, tiene que abrir un msgBox, de hecho, en mi casa me lo abre en las dos maquinas, por eso no le puedo quitar ese bug.
En el trabajo, no lo abre extra;amente como le pasa a muchos de ustedes, asi que en unas horas estoy subiendo una correcion.
ami si me corre tengo windows xp sp2
es un keygenme pide nombre y serial
este parece que esta bueno pienso que si lo resuelbo
finalmente
winxp sp3 compatible
http://www.mediafire.com/?x0o8xzexy50tga2
Ok... todo perfecto con la nueva version.
Saludos
Tinki.... fijate que la resubi, los enlaces ahora estan bien.
Ok, ya llevo una hora jugando con el y con el maldito fichero de registro.. :-[
Saludos
Mas que con el fichero, intenta mejor analizar la rutina de verificacion del serial.
No vas a poder resolverlo si no logras generar claves validas.
No obfusque el codigo, ni le hice saltos innecesarios... esto es solamente depurar, analizar, reversear la rutina de generacion, y luego me imagino que algo de suerte^^
y sobretodo recuerda, no hay azar, todo se hace por alguna razón, el código no es aleatorio.. cada comprobación/instrucción es esencial para el correcto funcionamiento de programa.
Si esquivas saltos en la comprobación de la rutina... es probable que termines literalmente en "cualquier lado"
Saludos.
Yo aun espero el tutorial del crackme número 1 creado por ti xD, un tipo no sé cual era su subnick respondió el serial, simplenotepad,comentó que daría la respuesta, pero aun no la ha hecho y es hace meses
Saludos xD
PD:Crea un nuevo thread del segundo crackme que estoy seguro que pasará desapercibido por los ojos de los demás :B
Bueno,....que pasa, se os ha atragantado el crackme.
Sería muy interesante abrir un poco de debate sobre como veis vosotros la posible solución al tema. Que la gente no se corte a la hora de escribir por miedo a estar equivocado, solamente que exprese sus ideas y así abrimos un poco de debate y veréis como lo solucionamos entre todos y de paso aprendemos un montón de los fallos y aciertos de cada uno.
Seguro que _Enko os lo va agradecer si ve que hay mucha gente trabajando en ello y esto será un incentivo para el para generar nuevos crackme's. :rolleyes:
Bueno, os cueto lo que yo creo:
El crackme genera un fichero reg.txt en el que almacena el serial que entramos.
Según _Enko no es un serial estático, hay múltiples serials validos. Esto quiere decir que habrá una rutina que compare caracteres con alguna funcion matemática o con caracteres que estarán entre el codigo por ejemplo:
1B1C1D1F pero pueden ser otros que se generen entre el codigo.
004024CF con fopen abre el fichero de registro
004024E7 con fgets lee el serial
0040250B con strncpy se guarda los ocho primeros caracteres del serial
00402521 con el PUSH mete el serial en la pila
00402521 CALL que nos lleva a una rutina que no se exactamente que hace
y al final la compara con 1B1C1D1F
Bueno, de momento esto es todo, pero y vosotros como lo veis.....?
Saludos
mi pregunta es que pasa cuando ingresas el serial correcto te crea el archivo reg.txt felisitandote o te muestra un mensage
a un que este ultimo lo dudo por que no mas he visto solo una instruccion de mensage y es la que te da el error
Hola flamer, fijate el objetivo del crackme.
Habilitar los menus registrando el programa.
El objetivo no es registrar el programa, sino que habilitar las funciones del menu del programa registrado.
Es decir, si registras, habilitas.
En teoria deberia ser posible registrar parcheando.
Es decir, una vez que te registras, se te van a habilitar los menus. Cuando abras una opcion del menu, en vez de decirte "primero debes registrar" te va a salir un mensaje de felicitaciones. Mas preciso, un MessageBox de felicitaciones.
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
Las comprobaciones estan para protegerte y dar pistas.... si te las salteas, 99% seguro que el programa crashee.
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
Mh...este no es un crackme de tipo visual basic, no vas a encontrar esto:
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
Hola _Enko:
Citar
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
pero aclarame una cosa dependiendo el usuario que le pongas es el serial que te genera que no
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.
TinkiCitarCreo 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'
CitarReferente 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
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 :P)
Eso es todo por ahora...
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.
MCKSys
Argentina le puse un break point ala instruccion 00402683 que es un push que es la que esta antes del call 00402689 para despues presionar f7 y entrar al call pero no se detiene nunca en push
No se detiene en 00402683 porque el serial no cumple los requesitos minimos.
La 2da y 3er llave maestra generada a partir del serial tienen que ser un intervalo (inicial - final) dentro del programa.
La funcion que descifra es alzanzada luego de los chequeos del serial.
Para el analisis anterior, usé IDA (ademas de Olly). Esta herramienta siempre debe estar presente!
Debo admitir que Fasm compila distinto a MASM, por eso se puede complicar un poco a la hora de analizar el inicio/fin de las funciones.
Noté que el compilador usa JMPs, aunque no se porque hace eso...
Cita de: _Enko en 17 Agosto 2011, 18:44 PM
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.
Asi es, el problema es el factor tiempo (o la falta de él :P)
Saludos!
Ni fasm ni masm compilan :silbar: Ensamblan.
Los codigos ensamblados entre masm y fasm son sumamente similares si es el mismo codigo, y es el mismo programador.
Lo que ocurre, es que se notan los estilos que usa un programador ya que la ejecutable es un reflejo del codigo fuente (mas en fasm, por eso se llama flat assembler)
fasm no es el que usa los jmps, los use yo en esta ocacion por pereza.
Normalmente se coloca las variables/constanes/cadenas en la sección .data
Y en este crackme use jmps porque no queria subir en el codigo fuente para volver a bajar a donde estaba antes....
Entonces, hice lo que borland con pascal/delphi viene haciendo hace años
Citar
jmp saltercadena
cadena db 'hola mundo',0
saltearcadena:
push 0
push cadena
push cadena
push 0
call [MessageBoxA]
La unica gran diferencia entre masm y fasm, es como manejan las importaciones.
en masm, normalmente tenes :
CALL <JMP.&KERNEL32.GetModuleHandleA>
mientras que en fasm
CALL [<&kernel32.GetModuleHandleA>]
masm ahora 1 byte por cada llamada. Aunque en fasm se puede hacer de cualquiera de las dos maneras.
Cita de: _Enko en 17 Agosto 2011, 19:54 PM
Ni fasm ni masm compilan :silbar: Ensamblan.
Buehhh... ensamblan. A buen entendedor, pocas palabras.. ;D
Saludos!
Luego pasado unos dias, si se aburren de intentarlo, creo que podria postear un serial valido asi les facilita el analisis. Pero claro, me tendrian que pagar primero u$d 39.99 , que es lo que vale el registro del programa. ;-)
no puedo entrar al call todavía nose cuales son las 2 y 3 condiciones
estoy biendo el call de la linea 004024A0 aber que encuentro sobre el ida aber que lo boy a buscar
Clave desencriptadora: 1B1C1D1F00402BAD00402DB411FFFFFF
Esta clave es la que se le pasa a la funcion que se encarga de descifrar el codigo (402CF1)
Los primeros 8 bytes (1B1C1D1F) los da el proggie (resultado que hay que obtener en EAX luego del CALL a 4028AF)
Los 8 bytes siguientes (00402BAD) son el resultado a obtener en la misma funcion anterior (2do check)
Los 8 bytes siguientes (00402DB4) son el resultado a obtener en la misma funcion (3er check)
Los ultimos 8 bytes (11FFFFFF) son el resultado a obtener en la misma funcion (4to check)
Todo esto sale gracias al analisis criptografico.
Como dije antes, ahora solo es cuestion de reversear la funcion 4028AF (o bruteforcearla) para que de los resultados expuestos (en base al serial de reg.txt).
Saludos!
PD: Las direcciones estan tomadas del EXE corregido. :)
PD2: Ah!! El mensaje que sale es: CONGRATULATIONS!!! YOU COMPLETED THE CRACKME NOW WRITE A TUTORIAL ;)
Jeje, muy buen trabajo. Felicitaciones !!!! ;-)
No me esperaba menos de vos ^^
Para hacer un keygen hay una cosa mas que nadie ha notado creo.... hay un crc32 del programa para la primera semilla de los numeros aleatorios ^^
Sabiendo la clave puedes llamar a la funcion desencryptadora y la funcion del registro del programa ni bien se abre.. hay que inyectar un poco de codigo pero se puede hacer. :laugh:
PD: estaria bueno que explicaras como hiciste para obtener el 2do, 3er y 4to check.
MCKSys
Argentina como lo lograstes esplicalo por que yo quede en 0
si puedes has un tutorial y te felisito
saludos ;-)
Cita de: _Enko en 17 Agosto 2011, 21:35 PM
PD: estaria bueno que explicaras como hiciste para obtener el 2do, 3er y 4to check.
En Olly, seleccionar desde 402BAD hasta 402DAA. Hacer Binary Copy.
En Cryptool, pegar con Hex Decoding. Luego "Analysis"-"Aymmetric Encryption (classic"-"Ciphertext-Only"-"XOR-Vernam".
En la ventana que sale, colocar Derived key length en 32 y Expexted most common character en FF.
Asi, la clave sale sola. De la ventana de resultado, copiar todo como Hex encoding y en Olly hacer Binary Paste.
El codigo se muestra descifrado... :P
Saludos!
Cita de: Flamer en 17 Agosto 2011, 21:55 PM
si puedes has un tutorial y te felisito
No tengo tiempo. Voy posteando a medida que tengo tiempo, pero para un tute no llego... :-\
Citar402BAD hasta 402DAA.
Porque esas dos direcciones?
(las 100% correctas son KEY2 00402BAD KEY3 00402DB4) Te pasaste unos milimetros xD
Fuiste probando varios bloques, o simplemente tomaste primero el que estaba abajo?
Fui hasta el final del codigo (hasta la funcion que empieza en 402DAB).
Tomé desde el primer byte "raro" despues del ret de 402BAA hasta el byte anterior a la funcion anterior (despues de todo, el CALL "final" de 402688 es a 402CF1: dentro de este rango).
Despues, sabiendo lo del XOR byte a byte, le meti todo a Cryptool.
Y listo... :P
Una cosa mas, porqeu el caracter frecuenta FF?
Citarstart_protect:
dd 64 dup 0xFFFFFFFF
coloca 64 ints con el valor 0xFFFFFFFF
todos los demas bloques, tienen numeros aleatorios, solamente este bloque, el cifrado le puse las FF al principio. Suponiendo que en algo ayudaria que no sea totalmente aleatorio.
pero como supiste que son FF?
Haciendo los primeros 8 bytes xor 1B1C1D1F?
Cita de: _Enko en 17 Agosto 2011, 22:12 PM
Haciendo los primeros 8 bytes xor 1B1C1D1F?
Claro. ;D
Aunque admito que hice 2 pruebas: con 0 y con 90 (nops). Es lo que deja normalmente un compilador en funcion y funcion.
^^
Si ponia un bloque de ints aleatorios al principio, el resultado es igual o es mas complicado?
Un ensamblador entre funcion y funcion no deja nada, al menos que el programador lo quiera xD
Por cierto, vamos a ver si alguien sabiendo ya las claves se pone a reversear el algoritmo de generacion que es interesante.
para la otra pongan una mas fácil :silbar:
si se puede
saludos :P
MCKSys ha posteado la llave maestra que es el 90% del crack si se va a crackear.
Pero si vas a hacer un keygen, tan solo es el 50%, ahora puedes analizar mas facil la rutina y generar un serial valido.
O bien, terminar de hacer el crack.
Felicitaciones a todos, asi si que se puede aprender debatiendo y rebatiendo, dando ideas, corregir errores, dialogo y mas dialogo.. ;-)
saludos
Sabiendo ya la llave, alguien está intentando terminar de resolverlo haciendo un patch o keygen?
yo paso :silbar:
ya me dolio la nuca todo el dia de ayer
estoy calando con otros crackmes mas fasiles
saludos :P
Hola _Enko:
Hay unas cuantas cosas que no me quedan claras.
Tenemos el código de la llave en un fichero. El programa la lee pero que descifra en el código nativo, o no descifra nada solo la usa para hacer operaciones matemáticas que dan un resultado que seria la condición de activar los menús.
Parece ser que es una clave de 32 byts según comenta MCKSys Argentina pero esta clave que hace exactamente con el código que va de 00402BAD a 00402DB4.
Porque no podemos ver el algoritmo de descifrado y reversear o parchear porque en algún lado debe comparar algo y si es cierto activar las funciones.
Luego también se habla mucho de los XOR para las comparaciones, pero y los CMP, no se usan?
Saludos
Citaruego también se habla mucho de los XOR para las comparaciones, pero y los CMP, no se usan?
XOR no es una comprobacion.
Es una operacion logica/booleana, tambien se llama 'O' exclusivo.
Devuelve 1 si dos bits son distintos. (es decir, 1 y 0, o 0 y 1) Mejor booscalo en google.
Citar
Porque no podemos ver el algoritmo de descifrado y reversear o parchear porque en algún lado debe comparar algo y si es cierto activar las funciones.
El serial esta compuesto por 4 grupos de 8 caracteres. Llamemole 4 palabras.
Cada palabra se "transforma" usando el nombre de usuario a una "llave maestra".
Hay 4 llaves maestras.
MCKsys las publico.
Lo que hay que hacer analizar la rutina de verificacion de serial y generar la rutina contraria.
O bien, hacer el parche que explico MCKsys, y luego llamar la rutina de activacion del programa al inicio del mismo.
Hay una sola comprobacion, '1B1C1D1F' si esa es valida, se intuye que todo el serial es valido y se continua.
Si se saltea ese salto, o se esta reverseando el codigo y solo eso es valido, el programa igual hace lo qeu tiene que hacer y si el serial no estaba bien, crashea.
A un usuario normal nunca le va crashear porque es casi imposible que el serial le de '1B1C1D1F' al principio.... al menos que este toqueteando el programa con olly, todo ir'a bien.