CRACKSLATINOS

Software: Scada Data Gateway

Jelb_sv

Proteccion: Crypkey, antivm,antidebugger.

Continuamos ahora con la parte 2 del crypkey.

Esta parte al parecer será mas extensa, el crypkey de este programa no se parece al viejo

crypkey descrito en tutoriales viejos que halle por ahí.

Como veremos, meternos con sus tejes y manejes será un dolor de cabeza, no se lo que nos

espera en esta travesia, pero espero tener este programa funcionando al final.

Como vimos en la primera entrega, el soft trae sus propias protecciones no muy complicadas,

pero el crypkey si que lo es.Veamos donde nos quedamos:

Pues en el botón continue corremos el demo, en el Request Activation podemos comprar el

soft por módicos $1500 de precio base y en Install/Update esta lo que nos interesa:

Pues allí la pantalla de registro, un ComputerID que de seguro será generado por crypkey al

muy estilo armadillo, un serial number y muchas opciones que en el modo demo aparecen

activadas en azul, si dejamos vencer el programa pues aparecen en rojo.

Ademas hay otra opción para remover la licencia instalada, si lo hacemos elprograma no

vuleve a correr ni a patadas. Gracias al uso de la vm he podido retroceder a snapshots donde el

programa esta en modo demo, sino, pues a reinstalar Windows.

Estando aquí ponemos cualquier cosa en el Activation Key y aparece esto:

De nuevo el famoso truquillo del pause, alt+f9, aceptar en el messagebox y caemos aquí:

Y el call stack nos dice:

Pues vemos que estamos en la misma API de la WinGUILib.dll encargada de los messagebox,

además vemos el key que le puse y una API de la misma dll muy sospechosa:

SaveActivationKey.

La API del messagebox fue llamada desde 40035b3d, demos doble click y veamos que hay allí:

Esta zona da mucha información de cómo opera este engendro:

1- Antes de abrir un api del crypkey obtiene comunicación con el por medio de algún tipo

de conexión o interface.

2- Manda al crypkey a guardar el activation key quien sabe donde, de seguro es entonces

cuando el pobre key es manipulado, transformado,encriptado y quien sabe que cosas

mas.

3- Luego le pregunta al crypkey que le pareció la clave, con la API getlicensemode, es

decir que el manejo de la licencia reside solo y solo en el crypkey.

4- Una vez obtiene el license mode, pues por ser pobres le pregunta al crypkey que fue lo

que paso con la explainerror y nos lo restriega en la cara con la messagebox.

Asi de simple, como cualquier protección.

Gracias a los programadores tan comodos que no esconden los nombres de las Apis , pues

intentaremos ver de donde obtiene el tal licencemode al inicio, veamos las intermodulars calls:

Vean esas Apis. Hablan por si mismas.

BP a todas:

Y reiniciamos.

Es de suponer que en la comunicación con crypkey se utilicen direcciones de memoria como

buffer, podría ser el stack, archivos con acceso compartido o areas con los suficientes

permisos.

Uno de las mejores formas de encontrarlas será fijarnos a salir de cada api de donde obtiene

los valores a comparar:

Con los bp le damos run y aparecemos aquí:

Y mas arriba:

Y si vemos las Apis nos cuentan la historia que queríamos escuchar.

Pues parchando por aquí y alla el programa trabajara full para siempre. Las Apis a parchar

serian islicensed? Getlicensemode? Y alguno que otro salto. Los programadores cometieron un

gran error al dejar todo habilitado en modo demo puesto que asi es posible tener el programa

completo parchando sin meterse con el crypkey.

No me detendré allí puesto que lo que nos interesa es una y solo una cosa: Como diablos

platican el programa y crypkey. Si hallamos las llamadas a la api o la forma de pasarse datos,

pues el trabajo estará finalizado.

Como lo hacen?

Pues esta fue la parte mas difícil, aunque hay tutoriales en internet, pues nada podía hacer

para encontrar la dichosa interface esa, traceando llegaba a ningún lado, los valores ya estaban

cargados siempre.

Pues lo siguiente era ver si existían archivos compartidos, algo asi como un buffer en disco

duro, esto lo sospeche desde que vi que existía un servicio crypserv.exe que vimos en la

primera parte.

Pues tendremos que poner bp CreatFileA, como sea debe comunicarse con el maldito crypkey

al inicio para comprobar la licencia, reiniciamos, ponemos el bp y no esperamos mucho para

aterrizar aqui:

Y luego

Pues esta verificando que discos existen, llega hasta el disco 15, equivalente a buscar 16 discos

duros, esto lo hace 4 veces, además veamos los registros en cada bp:

Ck? Pues que significa?

Sigamos viendo que mas hace:

Esta leyendo el .ini

Aja, aquí hay algo. Ese archivo tiene nombre muy sospechoso.

Pero que vemos en el call stack:

Esta inicializando el license manager.

Vean esas hermosas cadenas de caracteres, definitivamente esto huele mal, criptografía a la

vista.

Si se fijan, en las funciones es pasado como argumento el path al exe, posiblemente esto se

debe a que esas cadenas corresponden a claves de encripcion contenidas en el exe según lei

por ahí.

Pues lo que debemos ver es que hara con ese archivo CRP32001.ngn

Vamos a ver el retorno a 10046eb4

Pues traceando vemos que lee bloques de 512 bytes , el archivo mide 339978 asi que hara

varios loops hasta llegar al eof.

Durante eso al parecer desencripta lo que lee y lo escribe en otra localidad, vean esto al salir

del primer _read en la pila:

Un PE header, en el dump lo veremos mejor

Pues parece que estamos frente a otro exe o una dll.

Pongamos bp en LoadLibraryA y continuamos, luego de un rato:

Pues es una dll.

En este momento podemos ver el código de esa dll puesto que deberia estar desencriptada.

Veamos al retornar de la API

Alli vemos que llamara la función a1 de la dll, pero antes vuelve a la carga con la encripcion lo

que podría significar que aun esta encriptada, demos F9 y ahora vemos que empieza a generar

archivos extraños:

Vemos que es la dll creada la que se esta ejecutando.

Intentemos copiarla a otro directorio y veamos con otra instancia de olly las strings que pueda

tener:

Drivers?

Y mas abajo:

USB dongles?

Pues esto esta muy preocupante.

Regresamos al olly anterior y damos F9:

El maldito crea un piping para hablar con un driver, de seguro el .sys que vimos anteriormente.

Asi es como platican, el servicio en conjunto con el driver manejan las licencias, la dll creada en

tiempo de ejecución es la encargada de la interface entre el programa y estos dos malditos.

Pero como envía y recibe la dll datos?

Demos de nuevo F9:

¿???

Creo un archivo nuevo con acceso de escritura:

Damos F9 de nuevo y vemos algo muy interesante:

Y en el directorio:

Vean como en la llamada ultima al createfilea el modo es OpenExisting, el programa sabe que

el archivo ya debe de existir, sin embargo no es el quien lo crea puesto que no paro en el bp

del createfilea, debe ser otra entidad. Adivinaron, asi es como se comunican:

1-El programa a través de la dll escribe un archivo de nombre xxxxx con la solicitud de algo.

2- El crypkey lee este archivo y luego toma las decisiones correspondientes

3- La respuesta del crypkey es enviada a la dll mediante el archivo xxxxx._an

Traceando vemos que el proceso se repite una y otra vez.

Ahora esperamos que la dll intente generar una solicitud y ponemos bp en writefile y

ejecutamos:

Ahí escribe 128 bytes en el archivo, vamos a ver al buffer:

Pues esta encriptado, lo mismo es al leer la respuesta. Ahora esperamos a que accese a la

respuesta y ponemos bp en readfile:

Alli lo lee.

Vamos al buffer en el dump:

Encriptado.

Con esto logramos saber como se comunican, pero ahora veamos la interaccion del programa

con la dll.

Parados en un readfile veamos el call stack:

Pues no nos dice nada.

Sabemos que la winguilib es la que tiene las APIs del programa que llaman al crypkey,

borramos los bp y al llegar al entry point bp en getprocaddress, después de un rato llegamos

aquí:

Aquí ya estuvimos, pero ahora veamos donde estamos:

Esta es la API que nos crea la interface al crypkey.

Luego llama a la función a1.

La cadena larga es pasada como argumento a la dll.

Pues esas cadenas no son mas que parte de la encripcion RSA que crypkey utiliza para generar

las licencias. Adjunto un estudio completo de exefoliator, excelente whitepaper en ingles que

explica esto para una versión diferente de crypkey.

Del call stack vemos que esos 3 parametros a enviar corresponden a una función de encripcion

de un stream, ese que empieza con 3620…, la otr string tiene cara de exponente y el exe al

parecer es o contiene la base. La otra cadena ya es el resultado que es enviado al crypkey

para su desencripcion y procesamiento.

Si alguien quiere meterse con eso, pues con esa información no seria difícil hacer un keygen.

Existen en internet keygen para crypkey, pero es necesario hallar estos parámetros y luego ya

es posible generar el activation key.

Pues la cadena a encriptar es la solicitud, el crypkey lo tomara y la respuesta, encriptada, viene

en el archivo de respuesta, este es tomado por la dll y debe desncriptarlo en alguna parte.

Ponemos el bp en readfile antes de que se ejecute la función a1 esa y vemos que la función se

ejecuta una vez sin llamar readfile, asi que de seguro es cuando pone la solicitud, la segunda

vez si para en el bp:

Vamos al buffer:

Y luego le damos ALT+F9 y vemos que escribió:

Ahora veremos cuando lo accesa para desencriptar, bp en memory Access al primer dword y

caemos aquí:

Pues hace algo como un crc al archivo, esto es repetido con muchos archivos para ver si han

sido modificados.

Un análisis de la pila en este punto muestra como se va llenando con las respuestas del

crypkey:

Pues ahí esta la versión: Crypkey 6.1, bastante nueva. Ademas confirmamos el driver y el

servicio están operativos para este programa.

Para cuando aparece la nag, la pila muestra esto:

Dejemoslo ahí y vamos a install key, pasaremos por una inicialización de la interface, con

strings que le dicen al crypkey que algo se le enviara, luego aparece el mensaje de error y si

buscamos en la pila:

Pues ahí están las respuestas desencriptadas en texto llano.

Asi trabaja esto, pasando strings que encripta y desencriptando las respuestas.

Hasta aquí la parte 2 de este análisis.

Saludos a la lista CLS.

12-05-2007