COMO CRAKEAR POR ESTADO+PORCINO


CAPÍTULO III. CORTA HISTORIA DEL TIEMPO
Norton CrashGuard Deluxe 3.0

Mayo 1998

Indice
INTRODUCCIÓN

TIPOS DE PROTECCIONES TEMPORALES

UN POCO DE TEOR═A

EN BUSCA DE LA FRASE Mâ”´GICA

EL REGISTRO DEL SISTEMA

COMO CRACKEAR Norton CrashGuard Deluxe 3.0:

- PRIMERA EXPLORACIâ•™N.
- PRIMERA SORPRESA.
- SEGUNDA SORPRESA.

- LA APROXIMACI╙N DIF═CIL:
  • AL ATAQUEEEEEEEEEEEEEE
  • LA FECHA DE CADUCIDAD
  • CHECKSUMS PARAINOCOS
  • CHECKSUMS HASTA EN LA SOPA
  • LA MISMA PROTECCIâ•™N EN TODOS SITIOS
- LA APROXIMACIâ•™N Fâ”´CIL:
  • REUNIENDO LAS PIEZAS
  • LA COMPRA VIRTUAL
  • MODIFICANDO EL REGISTRO
  • MODIFICACIâ•™N DE LA VARIABLE DEL REGISTRO DEL SISTEMA
MORALEJA


INTRODUCCIÓN

íSaludos Familia!

Bastante tiempo desde mi ·ltimo artφculo, lo sΘ, pero ya estamos de vuelta. Nos ocuparemos ahora de las protecciones temporales, veremos un poco de teorφa y lo aprendido lo aplicaremos al programa Norton CrashGuard Deluxe 3.0 desde dos puntos de vista, el temporal y el de la password pa registrarse.



TIPOS DE PROTECCIONES TEMPORALES.

Demos un peque repaso a los diferentes esquemas de protecci≤n temporal que nos podemos encontrar (recomiendo la lectura del Capφtulo 4.1 de +ORC )

- CINDERELLA. El programa funciona durante una cierto periodo de dφas (digamos 15 dφas) comenzando desde la fecha de instalaci≤n.

- BEST_BEFORE. El programa funciona durante una cierto perφodo de tiempo independientemente de la fecha de instalaci≤n. El programa caduca el 30/12/97.

- COUNTDOWN. El programa funciona s≤lo durante unos minutos o unos segundos.

- QUIVER. El programa funciona s≤lo durante un n·mero determinado de ejecuciones. Realmente no es una protecci≤n temporal, pero su esquema de protecci≤n se parece mucho al de los otros tres tipos.


UN POCO DE TEOR═A

Analizemos como funciona una protecci≤n temporal.

Los "inteligentes programadores" ofertan sus productos completos al p·blico con ridφculas protecciones.
Le colocan una fecha de caducidad, pasada la cual, el programa no funciona. Esta idea la utilizan sobretodo las grandes compa±φas como Micro$oft, Corel, o Symantec.

La idea es distribuir masivamenete sus productos aprovechando los estupendos canales de distribuci≤n que ofrecen las revistas de Soft. Una vez inundado el mercado, el usuario disfrutarß del producto, se acostumbrarß a Θl, hasta que le sea indispensable y tenga que comprarlo a un precio desorbitado . Esta tßctica no es nueva, sino preguntad a alg·n camello, o como la CIA distribuyo la heroφna entre el Black Power.

Pensemos un poco. ┐C≤mo conoce el programa que ya ha caducado el perφodo de evaluaci≤n?.
Supongamos que tenemos una evaluaci≤n e 15 dφas e instalamos nuestro programa el 1 de febrero.
Sumando la fecha de instalaci≤n (1 Febrero) mßs el perφodo de prueba se obtiene la fecha de caducidad:15 febrero (El dφa en el que lo instalas cuenta como dφa hßbil).
El programa, lo primero que calcula es si la fecha actual es menor o igual que la fecha de caducidad, y en tal caso, se ejecuta normalmente.
Si es mayor, darß un bonito mensaje "El perφodo de evaluaci≤n ha expirado".

Una cosa estß clara, el programa debe guardar alguna de las dos fechas siguientes (o las dos):

A - Fecha de Instalaci≤n y el perφodo de evaluaci≤n.

B - Fecha de caducidad.

Lo normal es la opci≤n B. Al instalarse el programa, se calcula la fecha de caducidad y se guarda en alg·n sitio. Normalmente se guarda en el registro del sistema bajo alg·n nombre est·pido, aunque se puede guardar en el win.ini, system.ini, fichero oculto, o alg·n fichero que parezca inofensivo. Lo cierto es que debe guardarlo.

Existe una variante, y es que la fecha de caducidad estΘ dentro del ejecutable. Un ejemplo lo tenemos en la evaluaci≤n del Hotmetal 4.0., del tipo BEST_BEFORE, que dentro de su ejecutable aparecφa 31/12/97. Madre de Mitra, quΘ est·pidos pueden llegar a ser los zombi-programadores. Dependiendo de la pericia del programador la fecha de caducidad puede estar o no encriptada para ocultarla de la vista del usuario y para que sea difφcil modificarla. Resumiendo, el programa debe guardar la fecha de caducidad y comprobarla al inicio del programa con la fecha actual.

Ya sabemos de donde saca la fecha de cadudidad, pero, ┐de d≤nde saca la fecha actual?. Normalmente (el 99% de las veces) se extrae con una llamada a la funci≤n getlocaltimeo o getsystemtime. Pero se puede extraer viendo la fecha de alg·n fichero que se modifique peri≤dicamente como el system.dat o el bootlog.txt.

Los puntos de ataque a este esquema son claros:

- Atacar en el cßlculo de la fecha de caducidad.
En vez de sumar 15 dφas sumamos 15 siglos. Esta aproximaci≤n es difφcil por que el cßlculo se realiza una ·nica vez, generalmente en la instalaci≤n.

- Modificar la fecha de caducidad.
Si la fecha estß encriptada, necesitarφamos construir un algoritmo de encriptaci≤n para la nueva fecha que deseemos introducir. Por lo que en general, puede ser complicado.

- Forzar la caducidad del programa. Se analizan los mensajes que da el programa y a partir de ellos se le sigue la pista hacia atrßs. Es una tßctica muy utilizada.

- Atacar en la comprobaci≤n de la fecha actual y la fecha de caducidad. Simplemente modifica la comprobaci≤n para que siempre estemos en el perφodo de evaluaci≤n. Esta es una opci≤n elegante.

Alguien podrφa pensar que si se echa pa trßs el reloj de W95, la protecci≤n temporal se elimina. Para evitar esta "trampilla", los programadores colocan c≤digo como el siguiente:

SI estß activada la marca de caducidad ENTONCES el programa ha caducado y se finaliza el programa
DE LO CONTRARIO SI fechaActual>fechaCAducidad ENTONCES activar marca de caducidad

Como veis si os pasais de la fecha de caducidad, se activa una marca que impedirß que se ejecute el programa aunque modifiquΘis el reloj. Esta marca se guarda en los mismos sitios donde se guarda la fecha de caducidad.

A veces, la protecci≤n temporal queda eliminada introduciendo una palabra clave, por lo que a veces es mßs rßpido atacar por la password.

Para averiguar el fichero que contiene la protecci≤n temporal, se puede usar el SoftIce y poner un bpx getlocaltime, o bien una nueva tΘcnica, muy ·til no s≤lo para protecciones temporales.
Veßmosla.

EN BUSCA DE LA FRASE Mâ”´GICA

Todos los mensajes de un programa, los de error, los de felicitaci≤n, los de aviso, no son mßs que cadenas de caracteres que deben de residir en un fichero. Para protecciones temporales es ·til buscar mensajes como 'expire', 'demo', 'evaluation'. Si localizamos estos mensajes habremos localizado, generalmente, el fichero que contiene la protecci≤n y podemos desensamblarlo o pasarle el Softice. Extendiendo esta idea, basta con buscar los mensajes 'unregistered', 'register' para localizar el programa con la protecci≤n en esquemas por palabra clave. Recomiendo una herramienta excelente para buscar cadenas, es el programa sr32.exe, Search & Replace for Win 3x 95/NT, Funduc Software, Inc. (www.funduc.com). Bajßoslo y crackearlo, tiene una bonita y sencillota protecci≤n del tipo CINDERELLA.

EL REGISTRO DEL SISTEMA

El Registro del Sistema no es mß que un fichero gigante (system.dat) donde W95 y el esto de los programas dejan sus miserias, osea, sus variables, sus parßmetros de configuraci≤n, su fecha de caducidad, sus marcas de caducidad. Muchos cracks s≤lo necesitan modificar adecuadamente el system.dat Es muy conveniente que le echΘis un vistazo, aprenderΘis mucho y podrΘis modificar muchos de los parßmetros del Windoze. Para editar el registro, se utiliza normalmente el programa regedit.exe que encontrareis en vuestro directorio de Windows. Recomiendo que lo ejecutΘis con el parßmetro /v ,osease, c:\windows\regedit /v


CÓMO CRACKEAR Norton CrashGuard Deluxe 3.0

Objetivo: Norton CrashGuard Deluxe 3.0.
Versión: 3.0
Nombre del ejecutable: ncgd3w95.exe
Website: http://www.symantec.com
Tamaño del ejecutable: 11.964.671 bytes.
Tipo de protección: Cinderella.
Dificultad: Medio.
Tiempo de crackeo: 2 horas.
Herramientas: W32dasm8.X, SoftIce.

En esta ocasi≤n, nuestro objetivo es una gran y abominable compa±ia, la Symantec y uno de sus muchos y abominables producto: Norton CrashGuard Deluxe 3.0 Bßsicamente, el programa consigue, en algunas ocasiones, que las aplicaciones que se cuelgan no bloqueen al Windoze. Cosa de agradecer dado el alto φndice de siniestralidad de las aplicaciones y del propio Windoze. Ademßs de tener una B.D de informaci≤n sobre el PC, una antivirus ... Se protege con protecci≤n temporal CINDERELLA de 30 dφas.

PRIMERA EXPLORACIâ•™N

Instalamos el programa y antes de finalizar la instalaci≤n ya nos pide que nos registremos, mal asunto, quieren cobrar antes de que probemos su producto, su codicia de palpa ante incluso de ver el programa.

Una vez instalado, nos ha metido a escondidas varias cosas:

- Una Dll con un extra±o nombre: 30vfv6vn.sys situada en el raiz de la unidad c: El nombre varφa en cada instalaci≤n, s≤lo permanece fijo *fv6vn.sys, los 3 primeros caracteres son variables. Sospecho que s≤lo es un indicador para ver si el programa ya ha sido instalado.

- Una aplicaci≤n en el arranque del Windoze Norton CrashGuard Deluxe Autocheck. Si pulsais CRTL+ALT+SUPR podreis ver la aplicaci≤n por dos veces con el nombre de checkup Su misi≤n es detectar cualquier cambio en el reloj del sistema para bloquear inmediatamente la aplicaci≤n si nos pasamos de la fecha de caducidad.

Ademßs se crean dos directorios Norton CrashGuard y Norton CrashGuard Deluxe y nos aparece un bonito icono en el escritorio del Windoze con forma de escudo y con el original nombre de Norton CrashGuard Deluxe. Y si por si fuera poco, dos iconos en la barra de tareas, la aplicaci≤n propiamemte dicha (escudo gris con una N en azul) y una historia de los cuelges de los programas (un reondel con una marca de verificaci≤n).

Si pulsamos en el icono del escritorio nos aparece una ventana donde nos dice que nos compremos INMEDIATAMENTE la aplicaci≤n a un precio fabuloso, $45.95, (unas 7.000 pelas) En la parte inferior aparecen el n·mero de dφas que restan para el programa deje de funcionar. Ademßs aparecen unos bonitos botones en los que nos podemos registrar por Internet, probar el producto o cancelar. Si probamos el producto, aparece la ventana principal con todas pas opciones. Si elegimos la opci≤n de registro, aparece una pantalla donde introducimos nuestros datos y nuestra tarjeta de crΘdito.

PRIMERA SORPRESA

El sistema de pago no es de la propia Symantec, sino de la empresa Release Software Corporation:http://www.releasesoft.com) y su programa SalesAgen. Es la primera vez y veo que Symantec no controle todos los aspectos de una aplicaci≤n.

SEGUNDA SORPRESA

El fichero a estudiar es el Norton CrashGuard\cgmain.exe (229.376 bytes) por una simple raz≤n, tiene el ·nico fichero que tiene el icono que el del programa principal que aparece en la barra de tareas. Pero, en el mismo directorio aparece un extra±o fichero llamado cgmain.dl_ (743.936 bytes). Mu raro, una librerφa aparentemente comprimida (y por tanto no utilizada) con un tama±o mßs grande que el ejecutable. Por que no estß descomprimida la librerφa, ┐quizßs por que no estamos registrados? :-) Ademßs aparece un ejecutable llamado cgmaipop.exe , cuyo nombre es mu parecido al fichero del programa que estamos analizando cgmain.exe y tiene un icono que tiene las letras RS, que curioso, justo las Iniciales del la empresa que dedica a comercializar el producto: Release Software. Si intentamos ejecutar cgmaipop.exe aparece que estß preparando el Software. PREPARANDO?, ┐es que hay que precalentar los programas antes de instalarlos?. Luego aparece un mensaje de error indicando que no podemos ejecutar la aplicaci≤n, ┐quizßs por que no estamos registrados? :-)

Por si fuera poco, aparece otro fichero cgmaitky.dll (257.977) con un nombre muy parecido al de la aplicaci≤n que queremos estudiar y aproximadamente con el mismo tama±o. Y el colmo, en el otro directorio, donde reside el men· de la aplicaci≤n Norton CrashGuard Deluxe\CGDeluxe.exe aparecen los ficheros CGDelpop.exe con el logo RS y CGDeltky.dll. Anßlogamente para Norton CrashGuard Deluxe\checkup.exe (el programa de testeo de la fecha del sistema) CheckUp.dl_,Checktky.dll

Todo esto huele a chamusquina, seguro que estos ficheros tienen algo que ver a la hora de registrar el programa, y como veremos en la segunda pate del artφculo, tienen que ver y MUCHO.
LA APROXIMACI╙N DIF═CIL

AL ATAQUEEEEEEEEEEEEEE

Podrφamos analizar esos extra±os ficheros que han aparecido, y lo haremos en la segunda parte del artφculo. Ahora atacaremos formalmente a Norton CrashGuard\cgmain.exe para analizar su esquema CINDERELLA de 30 dφas.

Desensamblamos el programa con el w32dsam y obtenmos 3.5 MB de fichero. En las funciones importadas encontramos Addr:00045CC8 hint(00F5) Name: GetLocalTime . Bien, bien, asi que, aparentemente, estß usando la tipica rutina para obtener la fecha del sistema. Si vemos quien la utiliza, estaremos en plena rutina de comprobaci≤n de fecha: fechaActual>fecha de caducidad?

Solamente aparece la funci≤n getlocaltime que es utilizada una vez en el programa(┐por quΘ lo ponen tan fßcil?)
* Referenced by a CALL at Addresses:
|:0040D5B4   , :0040DA44   , :0040DD3F;   La rutina es llamada 3 veces

:0041E200 81ECCC000000            sub esp, 000000CC
:0041E206 8D442410                lea eax, dword ptr [esp+10]
:0041E20A 50                      push eax

* Reference To: KERNEL32.GetLocalTime, Ord:00F5h
|
:0041E20B FF15BC544400            Call dword ptr [004454BC]
:0041E211 8D4C2400                lea ecx, dword ptr [esp]
:0041E215 51                      push ecx

* Reference To: KERNEL32.GetSystemTime, Ord:0135h
|
:0041E216 FF15B8544400            Call dword ptr [004454B8]
.....

Ademßs aparece la llamada tambien a  GetSystemTime.



Tras la llamada a GetSystemTime los valores de a±o, mes, dφa,.... son extraφdos de la pila y guardados en los registros :0041E21 mov dx, word ptr [esp+0A] De los registros pasan a unas variables globales :0041E2AA mov dword ptr [0042F7F0], edx

Recordad, cualquier posici≤n de memoria fija como [0042F7F0], es utilizada como variable global por el programa. Despues se reintroducen en la pila el a±o, el mes, el dφa,.... y se llama a la rutina :0041E310 call 00423420.

En esta rutina es donde se realiza la encriptaci≤n de la fecha,al finalizar, devuelve en eax la fecha encriptada y ademßs de guardarse en :0041E323 mov dword ptr [ecx], eax

Es mßs, las tres llamadas a :0041E200 obtendrßn en eax la fecha encriptada de vuelta por call 00423420. Nos os voy a aburrir con diciendo como es la rutina de encriptaci≤n. Simplemente decir que utiliza la siguiente f≤rmula :

t=seconds+(secondsMinute*minutes)+(secondsHour*hour)+(secondsDay*day)+
(secondsDay*daysMonth[month])+(secondsYear*(year-1900))+(secondsDay*(((year-1900)-1)/4)); fin=(t+fixValue);

Siempre es mßs fßcil comparar un n·mero que comparar a±os, dφas, meses,... por eso la fecha se transforma en un n·mero. He construido un peque±o programa NORTON.EXE en C que realiza todo el proceso de encriptaci≤n de la fecha. Este programa esta incluido con la version en formato *.doc de este texto. Los fuentes de estos programas puedes bajarlos aqui.

Bien, lo l≤gico, es que una vez encriptada la fecha se compruebe con la fecha de caducidad que debe estar encriptada. Si analizamos las tres llamadas a :0041E200 tenemos:

* La llamada desde :0040D5B4, se limita a guardar la fecha encriptada :0040D641 mov dword ptr [esi+000002AC], eax

* La llamada desde :0040DA44, :0040DD3F hacen prßcticamente lo mismo, mueven la fecha encriptada que estaba en eax a un registro, hacen una llamada a call 40DC40 y despues comprueban la fecha encriptada con [edi+00000284]

En concreto para la llamada desde :0040DD3F

:0040DD4B mov ebx, eax
:0040DD62 push ebx
:0040DD63 call 0040DC40
:0040DD7B cmp dword ptr [edi+00000284], ebx
:0040DDBF ja 0040DDE4

En concreto para la llamada desde :0040DA44

:0040DA54 mov edi, eax
:0040DA5F push edi
:0040DA60 call 0040DC40
:0040DAB2 cmp dword ptr [ebx+00000284], edi
:0040DAB8 ja 0040DACE

Esto suena a una doble comprobaci≤n temporal, serßn desconfiados estos chicos.

┐Pero que hace la llamada a call 0040DC40?, para ello cerramos el cgmain.exe: bot≤n derecho sobre el icono de la N y el escudo y exit. Abrimos el loader del Softice y seleccionamos Norton CrashGuard\cgmain.exe y ponemos un bpx 40DC40 y lanzamos el programa. Aparecemos en el Softice, pulsamos F10 y vemos que ha sido llamada desde :40DD63. Cerramos el cgmain.exe otra vez, ponemos el softice un bpx 40DD63 y lanzamos el programa y prestamos atenci≤n a ebx que es el que contiene la fecha encriptada.

La llamada a call 0040DC40 simplemente realiza la siguiente comprobaci≤n

:0040DC56 cmp edx, eax; compara fechaAnterior,fechaActual
:0040DC58 ja 0040DC64; Salta si eres un mal chico.

fechaAnterior es la fecha encriptada el la que se arranc≤ por ·ltima vez el programa, fechaActual es la fecha encriptada obtenida de :0041E200. Es una simple comprobaci≤n para ver si hemos echado para atrßs el reloj.

La comprobaci≤n

cmp dword ptr [ebx+00000284], edi; Anßlogamente cmp dword ptr [edi+00000284], ebx
ja 0040DACE; Anßlogamente ja 0040DDE4 Comprueba fechaCaducidad > fechaActual Si es mayor estamos en el perφodo de prueba.

LA FECHA DE CADUCIDAD

La pregunta es, ┐de donde se guarda la fecha de caducidad encriptada? .Poniendo un bpr ebx+00000284 ebx+00000284+5 descubrimos que la fecha de encriptaci≤n se guarda en el registro del sistema y es recuperada por la llamada a la funci≤n :40BD89 RegqueryValueEXA. En concreto, se guarda en HKEY_CLASSES_ROOT\Ultxfile\Format\MSHAEZDOC\write

En mi caso, el valor de write es:
01 02 03 04 05 06 07 08

01	00 00 00 05 B7 FF FF F8
02	00 00 00 00 00 00 10 00
03	08 00 00 00 08 00 00 00
04	00 00 00 06 B3 36 71 A1
05	FB 0F 81 A5 20 80 00 06
06    B7 9F A9 A0 00 00 00 00
07    00 00 00 06 B3 36 71 A0
08    C3 28 00 00 18 00 00 00
09    00 00 00 00 00
La fecha de caducidad estß en write(5,7) hasta write(6,5) ambos inclusive. Lo curioso, es que la fecha estß codificada, por ejemplo si la fecha de caducidad es 0034F5F3D6 se guarda en write 0006B79FA9A000. La rutina de encriptaci≤n estß en :40C0D6 y se basa en la operaci≤n or
:0040C0D6 8A18                    mov bl, byte ptr [eax]
:0040C0D8 8A11                    mov dl, byte ptr [ecx]
:0040C0DA C0E305                  shl bl, 05
:0040C0DD 48                      dec eax
:0040C0DE C0EA03                  shr dl, 03
:0040C0E1 49                      dec ecx
:0040C0E2 0ADA                    or bl, dl
:0040C0E4 4E                      dec esi
:0040C0E5 885101                  mov byte ptr [ecx+01], dl
:0040C0E8 885901                  mov byte ptr [ecx+01], bl

He creado dos programas DECODE que decodifica el valor de write y CODE que codifica un valor de fecha para introducirlo en write.

CHECKSUMS PARAINOCOS

Los puntos de ataque son claros

1.- Parchear las comprobaciones en el ejecutable.
2.- Introducir una fecha caducidad en el a±o 30000.

1.- Si parcheamos el programa, se produce un error tan gordo que se casca windows. Esto se puede deber a que hemos crackeado mal obien exite un checksum. Para salir de dudas, basta con modificar alguna cadena de caracteres del ejecutable original Por ejemplo "not be run in DOS mode" lo pasamos a "not be RUN in DOS mode", si se casca es que hay un checksum, como en este caso.

Un checksum es una comprobaci≤n para ver si el ejecutable se ha modificado, normalmente se realiza sumando (XOR) los bytes del ejecutable y guardando este valor alg·n sitio (ejecutable, registro del sistema). El programa al arrancar suma (XOR) los bytes del ejecutable actual y comprueba la suma con el valor que tenφa guardado. Si hay alg·n problema es que un virus o un cracker ha modificado el programa y esto nunca es bueno para el programador.

En el caso del Norton CrashGuard Deluxe 3.0, el checksum se realiza de otra forma. Os acordais del fichero cgmaitky.dll, si hombre ese que nos parecφa tan sospechoso. Pos bien, guarda todos los bytes del cgmain.exe encriptados (de ahφ que tuvieran un tama±o tan parecido ambos ficheros). La rutina de checksum,simplemente consiste en coger de 16 en 16 los bytes del cgmain.exe encriptarlos y ver si son iguales a 16 bytes del fichero cgmaitky.dll. Si existe alguna diferencia se produce un error de protecci≤n general y se casca todo.

Para complicarlo todo, las rutinas de comprobaci≤n (ver si los 16 bytes del ejecutable son iguales a los 16 bytes del cgmaitky.dll) no estßn metidas en un bucle, sino que estan a lo extenso. Es decir, hay una rutina de comprobaci≤n para los 16 primeros bytes, otra disinta para los 16 siguientes. Si queremos parchear el checksum, habrß que modificar unas 30 comprobaciones. Es curioso, pero existe un flag que desactiva la llamada al checksum :0040862D jne 00408695 si obligamos a saltar siempre, evitamos el checksum. PERO, ┐POR QUE EXISTE UN FLAG PARA EVITAR EL CHECKSUM?, ┐es que el programa cgmain.exe va a modificarse? Como veremos mßs tarde, asφ ocurrirß.

2.- Con el programa NORTON se crea la fecha de caducidad que queremos, con el programa CODE se encripta y ya s≤lo hay que introducir el resultado en HKEY_CLASSES_ROOT\Ultxfile\Format\MSHAEZDOC\write en las posiciones write(5,7),write(6,5)


CHECKSUMS HASTA EN LA SOPA

Cuando la fecha de caducidad ha vencido, el programa deja de funcionar parcialmente, si analizamos el porquΘ descubrimos que el byte [esi+00000568] controla todo el meollo. En concreto,

Si [esi+00000568] = 02 You cannot Run this Application
Si [esi+00000568] = 20 Your computer application source has changed
Si [esi+00000568] = 08 Your free trial period is over
Si [esi+00000568] = 04 OK

Pero, ┐c≤mo se rellena este byte?. Siguiendo la pista hacia atrßs descubrimos que se carga a partir de HKEY_CLASSES_ROOT\Ultxfile\Format\MSHAEZDOC\open

00 01 02 03 04 05 06 07 1 00 00 00 00 30 00 00 00 2 00 00 00 00 00 00 10 00 3 08 08 00 00 20 00 00 00 4 00 00 00 00 00 00 00 00
En concreto de write(3,4). Hay que tener cuidado por que estß encriptado, asφ que hay que utilizar el programa DECODE. Osea , si en write(3,4)=20 indica que al desencriptarlo [esi+00000568]=4. Si write(3,4)=40 la fecha de caducidad ha vencido.

Si ha pasado la fecha de caducidad y asignamos write(3,4)=20, el programa replica diciendo que hemos trampeado los recursos. ┐QUE PASA AQU═?.

Mu facil, HAY UN CHECKSUM en la secci≤n HKEY_CLASSES_ROOT\Ultxfile\Format\MSHAEZDOC\open. Estos es paranoico, un checksum en el propio registro del sistema. En concreto, el checksum estß en write(1,4). Se deja como ejercicio localizar y destruir este checksum.

LA MISMA PROTECCIâ•™N EN TODOS SITIOS

Aunque parezca increφble, los ficheros CGDeluxe.exe y CheckUp.exe tienen exactamente la misma protecci≤n que cgmain.exe y ademßs en los mismos offset, osea en las mismas direcciones de memoria. Esto es extremadamente extra±o, asφ que adoptaremos otra vφa de ataque.

LA APROXIMACIâ•™N Fâ”´CIL

Veamos lo que tenemos:

- Unos ficheros extra±os asociados a los ficheros importantes. Sabemos la funci≤n de uno de ellos los *tky.dll sirven de checksum, pero y el resto para que sirven?

- Un flag que desactiva el checksum del ejecutable.

- Unos misteriosos fichero ejecutables con el logo RS que dicen que tiene que prepara el Sotware.

Nos centraremos en los ejecutables con los logos RS.

REUNIENDO LAS PIEZAS

Para cada utilidad , p.e. CGDeluxe.EXE existe un fichero, CGDeltky.dll, que realiza funciones de checksum (como ya vimos), una librerφa de un gran tama±o , CGDeluxe.dl_ ,y un ejecutable CGDelpop.exe que "prepara el Software".

No hay que ser un lince para darse cuenta que CGDelpop.exe "prepara" de alguna forma CGDeluxe.dl_ para aportar toda la funcionalidad a CGDeluxe.EXE. Esta "preparaci≤n" s≤lo se realiza cuando estamos registrados.

Por tanto, se parte de un archivo ejecutable de un tama±o inferior a la versi≤n completa del programa. Una vez realizado el proceso de compra se activa otro ejecutable que convierte la versi≤n de prueba en versi≤n completa .

Todas las demßs utilidades que acompa±an al Norton CrashGuard Deluxe tienen el mismo proceso (CheckUP.exe ->Checkpop.exe, Checkup.dl_, Checktky.dll) (Cgmaipop.exe ->cgmain.exe, cgmaitky.dll)

LA COMPRA VIRTUAL

Nos centraremos en el asistente (CGDeluxe.EXE) de compra que vimos en nuestra "Primera Aproximaci≤n" : Doble click en el escudo con la N que hay en el escritorio y al pulsar el bot≤n Buy Now (comprar ahora) aparece el asistente de compra.

Este serß nuestro punto de entrada. Si pensamos un poco observaremos que la aplicaci≤n que lanza el proceso de compra debe saber si la compra ha tenido Θxito o no. Por tanto, serß por aquφ por donde centremos nuestros esfuerzos . Ademßs debe de anunciar de alguna forma al resto de utilidades que la compra ha tenido Θxito para que ellas tambiΘn se "preparen" Analizaremos el ejecutable CGDeluxe.exe (que el que se lanza al pulsar el icono del escritorio) y observaremos como "compra".

Nada mejor que usar un desensamblador para investigar el programa CGDeluxe.exe (224 Kb). Una vez aparece el listado observamos que hace uso de la librerφa comercial RSAGNT32.DLL (encargada de realizar la compra virtual) y que existen un referencias a funciones tales como SAInitialize, startSalesAgent. Estas van a ser nuestras funciones de aproximaci≤n.

Pulsamos en el bot≤n de Imported Functions (Imp Fn) y hacemos doble click en la lφnea de rsagnt32.startSalesAgent.

Aparecerß en el listado lo siguiente:
* Reference To: rsagnt32.startSalesAgent, Ord:000Eh

:00407834 E807F30000		Call 00416B40	â–€ Llamada al asistente
:00407839 83C408		add esp, 00000008
:0040783C 66833D0425430000	cmp word ptr [00432504], 0000
:00407844 742B			je 00407871


Echamos un vistazo hacia arriba y hacia abajo del listado y vemos que nos encontramos en un bloque de c≤digo que se encarga de cargar, iniciar, ejecutar, terminar el asistente de compra Buscamos donde puede empezar el bloque. Y un poco mas arriba encontramos:

///////////// INICIO DE BLOQUE ////////////////
* Referenced by a CALL at Address:
:00406752   			▀desde aquφ es llamado el bloque del asistente de compra

:004077B0 A1B07B4300		mov eax, dword ptr [00437BB0]
:004077B5 53			push ebx
:				:
:				:
* Reference To: rsagnt32.startSalesAgent, Ord:000Eh	▀ Aquφ hemos comenzado la busqueda

:00407834 E807F30000		Call 00416B40		â–€ Llamada al asistente
:00407839 83C408		add esp, 00000008
:0040783C 66833D0425430000	cmp word ptr [00432504], 0000
:00407844 742B			je 00407871
:00407846 BFE0A54300		mov edi, 0043A5E0
:				:
:				:
:00407878 5F			pop edi
:00407879 5E			pop esi
:0040787A 5B			pop ebx
:0040787B C3			ret

///////////// FIN DE BLOQUE ////////////////


Ahora una vez que conocemos desde donde hemos llamado al bloque, usamos el menu Goto α Goto Code Location y escribimos el desplazamiento 406752. Aquφ observamos lo siguiente:

* Possible Reference to String Resource ID=00001: "Turnkexe"

:00406748 C705C826430001000000	mov dword ptr [004326C8], 00000001
:00406752 E859100000			call 004077B0	â–€ Entrada en el bloque anterior
:00406757 66392D04254300		cmp word ptr [00432504], bp
:0040675E 0F84F4010000			je 00406958
:00406764 BF34254300			mov edi, 00432534


Ummmmà. Aquφ ya tenemos una bonita direcci≤n de memoria (variable global) para usar con Softice.Pero antes a±adamos la librerφa RSAGNT32.DLL. al la lista de dll que sabe manejar el Softice.

Abrimos el Symbol Loader de Softice y en el menu Editα Softice Initialization SettingsαExports a±adimos RSAGNT32.DLL. Abrimos el Symbol Loader y cargamos (Load) el programa CGDeluxe.exe. Ya en el SoftIce:

Bpx 406752
Bpx startSalesAgent

Pulsamos F5 y cuando aparezca la ventana de "Welcome to Symantec Trialware" pulsamos sobre el bot≤n "Buy Now". Aparecer en el Softice en el primer breakpoint Bpx 406752

Seguimos ejecutando, paramos en la funci≤n startSalesAgent

cs:00407834 E807F30000		Call rsagnt32!startSalesAgent	â–€ Asistente de compra
cs:00407839 83C408		add esp, 00000008
cs:0040783C 66833D0425430000	cmp word ptr [00432504], 0000	
cs:00407844 742B		je 00407871		â–€ si salta, has comprado


Nopeamos el asistente de compra. Esto es, sustituimos la llamada por instrucciones inonfesivas. En : 00407834 90 90 90 90 90

Si estudiamos je 00407871 y hacemos que no vaya a la direcci≤n 407871 aparece una ventana contßndonos que se ha grabado un archivo llamado Rslicens.txt pero esto no hace que se active el proceso de compra, este nos es el camino.

Otra comparaci≤n interesante se encuentra despuΘs de la rutina de entrada al bloque

cs:00406752 E859100000 call 004077B0 ▀ Bloque anterior cs:00406757 66392D04254300 cmp [00432504], bp ▀Comparaci≤n Interesante cs:0040675E 0F84F4010000 je 00406958 cs:00406764 BF34254300 mov edi, 00432534

Cuando nos encontremos sobre la direcci≤n cs:0040675E cambiamos el flag de cero que estarß activada (Z) y la colocamos a desactivada (z). Ahora el programa seguirß en cs:00406764. Pulsemos F5 y veamos que ocurre.

Ha aparecido una ventana que nos dice que esperemos mientras nuestro programa esta siendo preparado (Please wait while your software is being prepared). Al fin, se "PREPARA EL SOFTWARE"

Nota: Si el proceso anterior se repite muchas veces conviene que cerremos todos los programas que tengamos activo e incluso el mismo Norton Crashguard que tengamos en la barra de tareas.

Una vez completado este proceso habremos comprado virtualmente el Norton crashguard Deluxe.

Observaremos que han desaparecido los ficheros CGDeluxe.dl_ y CGDeltky.dll y han aparecido dos archivos de licencia RSLICENS.txt y LICENSE.xxxxxx (n·meros de licencia) Este proceso realizado en tiempo real con el Softice no trae ning·n problemaà pero a la hora de hacer los parches no encontraremos problemas con los checksum .Pero..TRANQUILOS QUE TODO TIENE SOLUCION.

MODIFICANDO EL REGISTRO

Usaremos una herramienta muy ·til para los crackers el programa Regmonitor (si no lo tienes consφguelo) .Observamos unas variables que lee el programa (no registrado) al principio y tenemos:

HKCR\ultxfile\Format\MSHAEZDC\write /* Esta nos suena */
HKCR\ultxfile\Format\MSHAEZDC\xlate
HKCR\ultxfile\Format\MSHAEZDC\open /* Esta nos suena*/

Bien, basta comparar los valores antes y despuΘs de "preparar" el software, para darse cuenta que la ·nica modificaci≤n la realiza en open. Cuando estß registrado su valor es:

HKEY_CLASSES_ROOT \ultxfile\Format\MSHAEZDC\open
00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 10 00
08 08 00 00 10 00 00 00 - 00 00 00 00 00 00 00 00

Esta es la forma en que se comunica al resto de utilidades que la compra ya ha tenido Θxito.
Y YA ESTâ”´, basta con introducir este valor en el registro para que quede registrado el Norton CrashGuard Deluxe 3.0

MSHAEZDC corresponde al programa en cuesti≤n a comprar. Usando el regmonitor vemos que clave busca el programa a desproteger y anotamos el c≤digo (MSHAEZDC).

Esta tßctica se ha probado con Θxito con las siguientes aplicaciones protegidas por la compa±φa Release Software Corporation : Norton utilities, Norton Uninstaller, Norton Antivirus, Xing MPEG Encoder,

Creando un archivo de registro ya tenemos hecho un crack no destructivo ya que no modifica ning·n ejecutable.
----------------------------------- Cortar por aquφ ---------------------------------------------------
REGEDIT4
; (c) ESTADO+PORCINO 1998
; Modificaci≤n de registro para Norton Crash Guard Deluxe
; Mr.Red & otras hierbas
;
[HKEY_CLASSES_ROOT\ultxfile\Format\MSHAEZDC]
"open"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,10,00,08,08,00,00,10,00,00,00,00,00,00,00,00,00,00,00

----------------------------------- Cortar por aquφ ---------------------------------------------------

Para los demßs programas que usan esta protecci≤n tenemos:

Xing MPEG Encoder c≤digoα MSHVEMAV
Norton Utilities c≤digoα MSHVEM0E
Norton Unisntaller c≤digoα MSHW2EHL
Bueno ha sido largo pero ha merecido la pena.

MORALEJA: Si quieres poner una puerta, procura que no sea de papel.

Es el colmo de la incompetencia. Confφas la venta de tu producto a un empresa que proporciona una protecci≤n ridφcula que no vende tu producto si no que prßcticamente lo regala. Por que no invertir la millonada que Symantec habrß pagado a Release Software Corporation encontrar a unos buenos programadores en ensamblador que hicieran una protecci≤n decente.Ademßs, esta compa±φa protege y vende productos de mßs empresas a parte de Symantec.
Basta pasarse por su web http://www.releasesoft.com y comprobar lo orgullosos que estßn de sus clientes.
Realmente, no creo que esta compa±φa dure mucho.

La importancia de este artφculo radica en que se ha conseguido solventar con Θxito la protecci≤n de una casa de Software dedicada a proteger y vender. Quedan a nuestros pies cientos de programas , con una protecci≤n de papel, gracias a la incompetencia de una avariciosa compa±φa. Mejor serφa que diera los programas gratis, y de dejara de hacer el ridφculo.

Mr.PinK & WKT ( WHISKEY KON TEKILA )


Esperamos vuestras opiniones, sugerencias y ensayos en estadoporcino@hotmail.com
En breve analizaremos tipos de protecciones mucho más interesantes.

Recordad bebed de la fuente, buscad a +ORC en la red.



[ Entrada | Documentoz GenΘricoz | WKT TEAM Main Site ]
[ Todo el ECD | x Tipo de Protecci≤n | x Fecha de Publicaci≤n | x orden AlfabΘtico ]