| ESTUDIO COLECTIVO DE DESPROTECCIONES Última Actualizacion: 25/10/2001 |
Programa | FrontPage 2000 & PhotoDraw 2000. (I) | W95 / W98 / NT
Descripción | Aplicaciones de la familia Office 2000.
Tipo | Trial de 30 dias
Tipo de Tutorial | [X]Original, []Adaptación, []Aplicación, []Traducción
Url | http://www.microsoft.com
Protección | Nag Screen. Time Limit 30 Dias
Dificultad | 1) Principiante, 2) Amateur, 3) Aficionado, 4) Profesional, 5) Especialista
Herramientas | RegMon.
Objetivo | Extender el periodo de evaluación... ;-)
Cracker | Mr.Blue
Grupo | WkT!
Fecha | 29 de Julio de 2.000
INTRODUCCION
La familia Office 2000 de Microsoft está constituída por una serie de aplicaciones con un alto grado de compatibilidad entre ellas. Ejemplos de la "suite" del Office 2000 son las dos aplicaciones que nos ocupan. FrontPage 2000, mas que un editor de páginas HTML aisladas, es un completo editor de sitios web completos. Por su parte, PhotoDraw 2000 incluye todo lo necesario para el retoque de imágenes o incluso el retoque fotográfico. En el presente tutorial nos encargaremos de las versiones castellanas de ambos, la versión v4.0.1.2629 del FrontPage 2000 y la v2.0.0.0915 del PhotoDraw 2000. Para el desarrollo del tutorial nos limitaremos al FrontPage 2000, indicando las diferencias que pudieran existir con el PhotoDraw 2000. Que nadie espere grandes cosas de este tutorial, ya que el esquema de protección de ambas aplicaciones no introduce nada nuevo desde el punto de vista de la ingeniería inversa. Este tutorial puede ser más útil para los que empiezan en este mundo ya que muestra como grandes y complejas aplicaciones del tamaño del FrontPage y del PhotoDraw pueden venir con esquemas de protección a nivel de parvulario. Se ha dividido en dos partes para facilitar su lectura y descarga. Esta primera parte está especialmente indicada para los muy novatos, los verdaderos principiantes en la ingeniería inversa. Tras la lectura de este tutorial muchos se darán cuenta de lo sencillo que puede resultar "tumbar" las versiones de evaluación de pesos pesados en el mundo del software como Microsoft. En la segunda parte se profundizará un poco más con ayuda del SoftIce, para lo que se supone que el lector ya se encuentra habituado a este debugger o algún otro similar como el TRW2000. Aparte de a los novatos de la ingeniería inversa este tutorial está dedicado a los chicos de Microsoft, de los que sabemos que viven pendientes de lo que hacemos en WkT!. Quizás la lectura de este tutorial les permita mejorar la protección de futuras versiones de evaluación de sus aplicaciones dificultando en lo posible la aparición de esos ¿dañinos? cracks.
AL ATAQUE
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]
[ Entrada | Documentos Genéricos | WkT! Web Site ]
[ Todo el ECD | x Tipo de Protección | x Fecha de Publicación | x Orden Alfabético ]
(c) Whiskey Kon Tekila [WkT!] - The Original Spanish Reversers. Si necesitas contactar con nosotros, leeestoantes e infórmate de cómo puedes ayudarnos