|
La protección.
Tras instalar el FrontPage 2000 (o más bien, tras pasar varios
días instalándolo si tienes un PC anticuado) lo arrancamos,
sin que nos aparecezca ningún signo de que nos encontramos ante
una versión de evaluación que nos caducará dentro
de 45 días, salvo un cartelito de "Versión Preliminar" que
nos aparece en la ventana de presentación de la aplicación.
Hasta aquí debemos agradecer que Microsoft haya prescindido de las
odiosas nag screens que te recuerdan la caducidad de tu aplicación.
Si jugásemos con el reloj del PC adelantándolo veríamos
que la aplicación empieza a mostrar una nag screen (no nos libramos)
cuando quedan 15 o menos días de evalución. Si retrocediéramos
el reloj nos encontraríamos con la grata sorpresa de que la aplicación
nos muestra una ventana anunciando que ha caducado y aborta la ejecución.
Si volvemos a restaurar la fecha y hora del sistema, la aplicación
vuelve a quedar habilitada. De la misma manera, si forzamos a la aplicación
para que caduque, bastará con volver a restaurar la fecha para que
la aplicación vuelva a ser funcional.
Buscando una aguja en un pajar.
Tras las pruebas descritas anteriormente no tenemos que ser muy inteligentes
para poder deducir que el programa "esconde" en algún sitio la fecha
de última ejecución... y que mejor escondite que el colosal
registro de Windows, lleno de claves, recovecos y basurillas variadas en
donde esconder algo tan pequeño como una fecha de ejecución.
Otra opción es guardarla en un fichero, aunque lo más normal
en aplicaciones para WIN95 es el registro.
En este punto entra en acción el RegMon, o cualquier otra herramienta
equivalente que nos liste todos los accesos que realiza una determinada
aplicación al registro de Windows. Alguno de esos accesos será
la fecha de última ejecución.
Tal y como pudimos deducir antes, el FrontPage leerá la fecha-hora
de última ejecución, verificará que no se ha retrasado
la hora del sistema y salvará la nueva hora de instalación.
Puede que esto último lo haga al cerrar el programa... o al principio.
Vamos a buscar primero en los accesos previos al arranque de la aplicación
y si no encontramos nada ya veremos que es lo que hay al cerrar la aplicación.
Suponemos que partimos de una instalación del FrontPage sin caducar.
Configuramos el filtro del RegMon para que solo nos muestre los accesos
al registro del FrontPage. Arrancamos la aplicación y vemos como
el RegMon comienza a registrar actividad. Una vez que el FrontPage ha arrancado,
desactivamos el RegMon para que deje de capturar accesos al registro y
nos concentramos en el listado.
No está mal, el RegMon ha capturado unos 4500-4800 accesos al
registro. Es el problema de estas macroaplicaciones de Microsoft... que
hacen tropezientos mil accesos a disco y al registro para poder arrancar.
Parece que vamos a tener mucho trabajo... o a lo mejor no... La mayor parte
de los accesos son lecturas, pero la entrada de registro que buscamos no
solo debe tener al menos un acceso de lectura, si no que además
debe tener al menos uno de escritura, y los accesos de escritura son mucho
menos numerosos.
El RegMon permite buscar cualquier palabra en el listado de accesos,
vamos a buscar por "SetValueEx". Comenzamos a buscar y lo primero que nos
encontramos son una especie de contadores que se incrementan de uno en
uno, en distintas ramas del registro pero siempre en valores denominados
"Usage".... hummmm... Yo diría que Microsoft está muy interesado
en mantener una estadística de las veces que utilizamos cada uno
de los módulos del FrontPage... espero que esta estadística
no salga del ordenador cuando el FrontPage se conecte a la red para actualizar
algún sitio web... ;-)
Otros valores son demasiado pequeños como para poder ser considerados
un valor de fecha y hora, por muy encriptado que se encuentre el valor
de la fecha hora que guarda el FrontPage. Tras incrementar un montón
de veces los mismos contadores y escribir algunos valores constantes en
el registro, nos encontramos con una parte interesante... en los eventos
3537-3542 se accede al valor HKEY_CLASSES_ROOT\CLSID\{388ed915-7fd2-11d0-a60b-00a0c90a43c9}\InprocServer32\MiscStatus,
primero leyendo el valor (80 bytes) y después sobreescribiéndolo
con otro. Aunque no parece una fecha en claro, en 80 bytes bien puede guardarse
una fecha-hora de última ejecución encriptada, además
de la fecha de instalación necesaria para calcular la fecha de caducidad,
y más cosas...
Vamos a actuar con prudencia. Adelantamos la fecha
del sistema los días necesarios para que nos aparezcan los avisos
de que nos quedan 15 o menos días de evaluación. Salvamos
en un archivo esta entrada del registro (usando el Regedit, menú
Registro->Exportar...). Borramos el valor y probamos a arrancar el FrontPage.
¡¡ Lo encontramos !! Ya no aparece
la nag avisando de que quedan menos de 15 días de evaluación.
Si nos fijamos bien, al arrancar el FrontPage si no se encuentra con este
valor en el registro supone que acaba de instalarse y lo crea con la fecha
actual encriptada, reiniciándose el periodo de evaluación.
Con el PhotoDraw 2000 ocurre lo mismo, con la
diferencia de que en el PhotoDraw el número de accesos al registro
al arrancar es mucho menor. En el caso del PhotoDraw el valor es HKEY_CURRENT_USER\Software\Microsoft\MSPTSTRI\HandleMap.
Si curioseamos un poco más descubriremos
que cuando el programa muestra la ventana de que ha caducado y aborta su
ejecución, el valor de esta clave en el registro no es actualizado
con la fecha-hora actual.
Que nadie se lleve a engaño con este tipo de protecciones. Muchos
pensarán que volviendo a retroceder la fecha en el momento que llegue
el fatídico día de caducidad se solucionará el problema.
Nada más lejos de la realidad. El sistema de protección tal
y como se ha descrito obliga a que cada vez que se arranque la aplicación
la hora del sistema debe ser ligeramente superior a la anterior fecha-hora
en la que se arrancó el programa por última vez (el valor
encriptado en el registro) para permitir que éste funcione. Esto
provoca que, independientemente de los malabarismos que hagamos, llegará
un momento en el que la fecha-hora de la última ejecución
del programa grabada en el registro coincidirá practicamente con
la fecha-hora de caducidad... en ese momento hagamos lo que hagamos con
la fecha-hora del sistema la aplicación no funcionará...
salvo que borremos el valor de registro en el que se almacena esta fecha-hora
de última ejecución y de instalación... ;-)
Conclusiones.
Ya hemos encontrado una forma fácil de prolongar el periodo de
evaluación de dos grandes aplicaciones como son el FrontPage y el
PhotoDraw, y no hemos tenido que meternos con desensambladores, ni código
ensamblador, ni editores hexadecimales... Tan solo hemos usado la lógica
y el RegMon... no está mal para empezar.
La solución hallada permite de manera rápida y más
o menos sencilla reiniciar el periodo de evaluación y resolver el
problema que se produce cuando instalamos un software de evaluación,
por la razones que sea no lo podemos evaluar debidamente (falta de tiempo,
vacaciones,...) y cuando por fin disponemos del tiempo necesario para evaluarla
detenidamente nos encontramos que o bien se encuentra ya caducada o bien
le quedan pocos días...
En otros ambientes, especialmente en PC's dedicados al desarrollo de
software en donde es necesario cambiar continuamente la fecha y hora del
sistema para probar la funcionalidad de programas en desarrollo, acudir
al registro para borrar la clave cada vez que se desea arrancar la aplicación
en periodo de evaluación puede ser bastante engorroso. Con un poco
de trabajo adicional no habría ningún problema en generar
un pequeño programa que podría ejecutarse cada vez que se
arranca el PC, o que sirviera de cargador para el FrontPage o el PhotoDraw
y que permitiera que cuando la aplicación en evaluación arrancase
se encontrara el registro "limpio"... Lógicamente al eliminar la
limitación que incluye Microsoft para obligar al usuario a cumplir
con la licencia de la versión de evaluación, es responsabilidad
del usuario el utilizar el software más allá del vencimiento
de la licencia de evaluación, 45 días después de la
instalación para el FrontPage y 30 para el PhotoDraw... el no respetarlo
supondría el quebrantamiento de la licencia de evaluación
del software instalado, con el consiguiente quebrantamiento de los derechos
de autor... y seguro que no es vuestra intención quebrantar los
beneficios de Microsoft, ¿verdad?... XD
Podemos seguir curioseando utilizando ya el SoftIce para intentar extraer
las rutinas de encriptación y desencriptación de las fechas
de instalación y última ejecución que se almacenan
en el registro de Windows, pero no merece la pena...
Quizá sea más interesante tirar del hilo que hemos descubierto
con el SoftIce a ver hasta donde llegamos... en algún sitio del
código del programa se debe comprobar la diferencia entre la fecha
de instalación y la actual, partiendo de la información cargada
desde el registro de Windows... Encontrando esa porción de código
y modificando los ejecutables del FrontPage y del PhotoDraw podremos eliminar
definitivamente la comprobación de la caducidad de la versión
de evaluación.
Todo eso ya se verá en la segunda parte de este tutorial... ;-)
Mr. Blue / [WkT ! 2000] |
