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 botn continue corremos el demo, en el Request Activation podemos comprar el

soft por mdicos $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 opcin 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,
adems 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 informacin de cmo opera este engendro:

1- Antes de abrir un api del crypkey obtiene comunicacin con el por medio de algn tipo
de conexin 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 proteccin.
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 comunicacin con crypkey se utilicen direcciones de memoria como
buffer, podra 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 queramos 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 difcil, aunque hay tutoriales en internet, pues nada poda hacer
para encontrar la dichosa interface esa, traceando llegaba a ningn lado, los valores ya estaban
cargados siempre.
Pues lo siguiente era ver si existan archivos compartidos, algo asi como un buffer en disco
duro, esto lo sospeche desde que vi que exista 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, adems 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, criptografa 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 segn 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 cdigo de esa dll puesto que deberia estar desencriptada.
Veamos al retornar de la API

Alli vemos que llamara la funcin a1 de la dll, pero antes vuelve a la carga con la encripcion lo
que podra significar que aun esta encriptada, demos F9 y ahora vemos que empieza a generar
archivos extraos:

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 ejecucin es la encargada de la interface entre el programa y estos dos malditos.
Pero como enva 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 travs 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, despus 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 funcin 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 versin diferente de crypkey.
Del call stack vemos que esos 3 parametros a enviar corresponden a una funcin 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 informacin no seria difcil hacer un keygen.
Existen en internet keygen para crypkey, pero es necesario hallar estos parmetros 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 funcin a1 esa y vemos que la funcin 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 anlisis de la pila en este punto muestra como se va llenando con las respuestas del
crypkey:

Pues ah esta la versin: Crypkey 6.1, bastante nueva. Ademas confirmamos el driver y el
servicio estn operativos para este programa.

Para cuando aparece la nag, la pila muestra esto:

Dejemoslo ah y vamos a install key, pasaremos por una inicializacin 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 estn las respuestas desencriptadas en texto llano.

Asi trabaja esto, pasando strings que encripta y desencriptando las respuestas.
Hasta aqu la parte 2 de este anlisis.
Saludos a la lista CLS.
12-05-2007