Categoría: Windows

Pocas cosas hay más útiles que un diccionario en la PC, siempre listo y a mano para sacarnos las dudas sobre el uso de tal o cual palabra. Por eso, saber que existe una versión del fabuloso Diccionario de uso del español de María Moliner para Windows me llenó de alegría.

Sin embargo, su interfaz no está libre de problemas. Una falla en particular hace que cada cierto tiempo se encapriche y nos pida que insertemos el CD de instalación, sin otra razón aparente que hacernos levantar para buscar el bendito disco y echar por la borda la comodidad de tenerlo instalado.

Montando una simple imagen del disco se resuelve el problema, pero molesto por lo chapucero de esa solución me decidí a ir al grano y darle masa al problema.

«Para nosotros, para nuestra posteridad…»

El diccionario (me refiero a la versión 2.14.1, que abunda en las redes P2P) fue escrito en Visual Basic 6.0, y aparentemente registra información sobre los accesos en archivos cifrados (00.SIG, 01.SIG y 10.SIG) que conservan su fecha del año 2001, para que no nos percatemos a simple vista cuando son actualizados. Todo muy lindo, pero es bastante fácil de pasar la protección por alto, como veremos a continuación. A pesar de todo, al día de hoy no hay un solo crack disponible; se ve que los diccionarios no son tan populares como el Call of Duty…

Vamos a aprovechar esta ocasión para probar el VB Decompiler en su versión «Lite», que si bien carece de algunas características útiles de la versión «Pro» (como la posibilidad de aplicar parches), es gratuita y cubre ampliamente nuestras necesidades. Ni bien abrimos la herramienta, vamos a ‘Tools/Options’ y ahí tildamos la opción ‘Add HEX dump’ para que incluya las secuencias de bytes correspondientes a las instrucciones desensambladas, cosa que nos permitirá compensar la mencionada falencia de la versión «Lite». Vayamos a ‘File/Open program’ y seleccionemos DUE.EXE (el ejecutable principal del diccionario). Nos preguntará si queremos descompilar el programa ahora; cliqueamos en ‘No’ y nos vamos a tomar unos mates.

Un par de cebadas después, repetimos los pasos anteriores pero esta vez contestamos que sí a la pregunta del millón. Después de trabajar un ratito (el VB Decompiler; nosotros seguimos con el mate) nos avisará con el mensaje «Decompiled OK» que ha terminado. Tenemos a la vista un panorama general de la estructura del programa. Aquí nos conviene echar un vistazo para ver si algo nos resulta llamativo. Entre los módulos aparece uno llamado DUEProtection que parecía prometedor, pero sólo me hizo perder tiempo. Hagamos doble-clic sobre Sub_Main. Unas pocas líneas después del comienzo aparece la primera cosa realmente interesante: una llamada (call), una comprobación (test) y un salto condicional (jnz) que en caso de no producirse termina en una llamada a la rutina «End».

¿A dónde se dirige la llamada? La rutina 601DD0h se encuentra en el módulo WindowsModule, que ¡oh sorpresa! hace referencia a la cadena «Inserte el CD-ROM del DUE en el lector». Mi primer impulso fue cambiar el jnz (saltar si no es cero) por un jmp (saltar «sin peros»), remplazando el 75h por EBh en la instrucción 75C0 (ver pantalla). Para ubicar este segmento de código en el archivo DUE.EXE se necesita -además de un editor como WinHex o similar- encontrar una secuencia de bytes característica (que no se repita). Probando con la mismísima llamada a la rutina donde suponemos reside la protección (E8D9F40300) lo encontramos al toque. Es fundamental verificar que sólo aparezca una vez, para confirmar que estamos en el lugar indicado. Hacemos el cambio y probamos. La misma ventana de siempre: «Inserte el CD-ROM del DUE en el lector». Pero al darle ‘Cancelar’ en vez de cerrarse… ¡abre el diccionario!

Toque, gol y fiesta

Evidentemente estamos en el área chica. Sólo hay que afinar un poco la puntería y clavarla en el ángulo. ¿Qué es lo que está pasando? El salto que encontramos es el que lleva a la protección, y cuando vuelve le dice al programa principal si pusimos el bendito CD en la unidad o no. Entonces, hagamos al revés y eliminemos la llamada por completo. Volvemos a buscar la misma secuencia de antes y esta vez la «tachamos» con cinco 90h (que en ensamblador de intel significa ‘nop’, i.e. NoOPeration). Probamos nuevamente y… ¡entró como piña!

Antes de cantar la victoria total y definitiva, tenemos que ocuparnos de dos pequeños ayudantes: Conjugador.exe y Definidor.exe, que son invocados desde el acceso rápido del DUE. Si tratamos de utilizarlos, se repite la misma historia que con el diccionario. Si los desensamblamos, comprobaremos con disgusto que ambos tienen una serie de saltos que buscan claves en el registro y mil cosas más. Además, los módulos parecen tener los nombres desordenados; WindowsModule no es lo que esperábamos y el mensaje «Inserte el CD-ROM del DUE en el lector» aparece ahora en uno llamado DueServerPathModule. Pensemos un poco y apliquemos la Ley del menor esfuerzo.

La protección del programa principal hacía un salto a una rutina propia (call xxxxxxxxh), una comprobación (test) y un salto condicional (jnz). Busquemos «test» en el módulo Sub_Main de los ayudantes. Encontraremos tres o cuatro bloques con la siguiente estructura:

call MSVBVM60.DLL.__vbaFreeObj  ;llamada rutina VB
movsx ecx, word ptr var_C4
test ecx, ecx
jz 4077DBh

Pero uno solo de la forma:

call 0040F180h  ;llamada rutina propia
movsx ecx, ax
test ecx, ecx
jnz 407BD7h

De más está decir que este último es el salto a la rutina maldita, que dejaremos sin efecto tachándolo en ambos ayudantes con cinco 90h, como en el programa principal. ¡Ahora sí! Nuestro diccionario ha quedado completamente corregido y no volverá a obligarnos a levantar de la silla.