como crackear por estado+porcino 3

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.