Programa: NO$MSX v1.

5
Tutorial C019

PROTECCION: KeyFile.

Objetivo: Desempaquetar UPX y emparchar o realizar el KeyFile.

Descripcion: Debugger para PC de programas de computadoras MSX.

Dificultad: Newbie, Facililla, Media, Avanzado, Difícil, Elite.

DOWNLOAD: http://www.work.de/nocash/msx.htm

Herramientas: PEiD, OllyDbg, GuiPEX, Hex Work Shop.

CRACKER: SACCOPHARYNX FECHA: 21/09/2004

INTRODUCCION
No tenía pensado hacer un tutorial acerca de NO$MSX, pero su autor, Martín Korth, realmente se lo ha
ganado. Como podrán ver en mi page, tengo una sección dedicada al cracking de ROMs para MSX, ya
que guardo un cariño especial por esas computadoras.

La cuestión es que hace un tiempo le mandé un e-mail a este tipo, diciéndole que a pesar de que este
es el único debugger de MSX ROMS que hay para PC y que de hecho no lo podía comparar contra otro,
me parecía muy bueno su producto, ya que lo había testeado bastante crackeando los ROMs de MSX.
También le propuse que si algún día pretendía realizar versiones comerciales de él, podría asesorarlo para
protegerlo mejor.

Le dije de protegerlo mejor porque me tomé 5 minutos para investigarlo superficialmente y vi que era algo
muy sencillo de registrar para un cracker. La cuestión es que este tipo me contestó de muy mala forma,
insultándome, y diciendo que yo no sabía nada y que era nada, como si yo fuese una cosa. También dijo
que gracias a crackers como yo, el está tratando de sobrevivir porque crackean sus productos y no
embolsa dinero.

Querido Martin, voy a contestar con hechos a tus acusaciones de que soy "NADA", y con palabras al
resto de las cosas. Los hechos serán el tutorial en sí, y las palabras las siguientes:

Por qué eres tan ignorante en pretender dinero a cambio de tus programas llamados
NO$EL_NOMBRE_QUE_SEA? Por si no lo sabes, "NO$" significa "NO DINERO", "NO CASH", ok? Cámbiales el
nombre.

Los crackers tenemos la culpa de que no ganes dinero? Viejo, me tomé la molestia de buscar cracks de
tus productos y no hay uno en toda la red, excepto este tutorial que te has ganado, jejeje. Seamos
realistas Martin, los únicos que deben conocer tu NO$MSX debemos ser algunos gurues del MSX y yo, asi
que si no ganas dinero es porque tus programas nos los conoce casi nadie, ni Magoya. Debes besar mi
culo ya que gracias a este tutorial tu software será un poco más conocido.

Pero supongamos que tu programa es el más conocido del mundo y todos buscan crackearlo, por qué te
enojas cuando alguien te ofrece una mano desinteresadamente para protegerlo mejor? Creo que eso se
debe a que te crees un maldito ser superior, entonces te dio por las bolas que te hayan dicho que tu
programa es muy fácil de registrar.
 En cuanto a que soy "NADA", además de contestarte con mi página, lo haré con este tutorial, el cual no
me deja volcar todos mis conocimientos gracias a tu PAUPERRIMA protección. Pero prometo hacer el
mayor esfuerzo posible para deleitar a los crackers. Vamos a los hechos...vamos al cracking...

AL ATAKE
Intro
Lo que haremos será registrarnos de dos formas:

A) El camino bruto: desempaquetar y emparchar.

B) El camino fino: realizar el Keyflie de registración.

Pesentando a la victima
Como ya mencioné, NO$MSX es un debugger para plataforma PC, que permite debuggear juegos o programas de
computadoras MSX, gracias a su sistema de emulación. Es el único programa que encontré y que cumpla con
dichas características. Si alguien conoce de otro, por favor hágamelo saber.

Manos a la obra
En primer lugar comenzaremos por el camino bruto. Pasamos NO$MSX por PeiD y vemos que está empaquetado
con UPX:

Figura 01

Pero que siginifica Overlay? Eso lo veremos dentro de poco.

Em primer lugar realizamos una copia del EXE original y la dejamos a mano. Ahora ejecutemos GuiPEX y
arrastremos y soltemos desde el explorador de archivos hacia GuiPEX el archivo NO$MSX.EXE:
 Figura 02

Seleccionamos el commando Decompress y luego damos RUN. En la UPX OUTPUT veremos:

Ultimate Packer for eXecutables

Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002
UPX 1.24w Markus F.X.J. Oberhumer & Laszlo Molnar Nov 7th 2002

File size Ratio Format Name

-------------------- ------ ----------- -----------

526810 <- 229850 43.63% win32/pe NO$MSX.EXE

Unpacked 1 file.

E:\PracticasDeCracking\No$MSX\NO$MSX.EXE
00:00:080 min:sec:msec

***************************************************************************
Ya tenemos el archivo desempaquetado. Lo ejecutamos y...

Figura 03

Cuando le mandé el e-mail al cretino de Martin, no me detuve a ver porque razón tiraba este error, ya que solo
estaba viendo la protección superficialmente, pero suponía que se trataba de algún tipo de control
antiunpacking por alguna razón, asi que solo me limité a evitar el MessageBox.

Entocnes, cargamos el programa en Olly y en la línea de comandos ponemos Bp MessageBoxA, damos F9, y Olly
se detiene dentro de la API. Traceamos hasta el código del programa, y llegamos hasta aquí:
 Figura 04

Ahora debemos identificar donde se produce el problema que nos lleva al MessageBox. Hay varias formas de
llegar hasta él. Una sería la siguiente:

En la figura 04 vemos que el código que ejecuta este MessageBox comienza en 421E46, entonces nos
posicionamos en esa dirección y presionamos CTRL+R para ver las referencias a 421E46:

Figura 05

Nos posicionamos sobre cualquiera de estas líneas, damos un click derecho, y seleccionamos "Set Breakpoint on
every command" y cada referencia contendrá un BP. Ahora reiniciamos presionando CTRL+F2 y damos RUN (F9)
nuevamente para llegar hasta aquí:

Figura 06

Aún no vemos el código que genera el error, asi que realizamos los mismos pasos que antes utilizando CTRL+R,
pero esta vez posicionados en 40A0F5, ya que si lo hacemos en 40A0F0 no nos llevarán a ningún lado las
referencias que aparezcan. AL presionar CTRL+R vemos:

Figura 07

nuevamente click derecho sobre alguna de las referencias y seleccionamos "Set Breakpoint on every command".
Reiniciamos una vez más con CTRL+F2 y damos RUN (F9) lo cual nos llevará a 40D31E:

Figura 08
 Figura 08

Pues aquí estamos frente al niño malo: En 40D319 se carga el mensaje de error al cual llegamos a través de un
salto condicional (40D2F1 o 40D2FC). Todo el código del chico malo comienza en 40D2B3, ya que en 40D2B2
tenemos un RETN.

La otra forma de hallar el chico malo era más fácil: Por lo tanto lo que debemos hacer es eliminar todos los BPs
que pusimos anteriormente y reiniciar con CTRL+F2, presionar ALT+M para que aparezca el mapa de la memoria,
clickear con el botón derecho, seleccionar "Search", y escribir como dacena ASCII la palabra "Damage" que la
obtuvimos del MessageBox. Al dar "Ok" llegaremos hasta la dirección 40D323:

Figura 09

Ahora damos un click sobre la letra "D" de Damage o sobre el "0x44" y presionamos CTRL+R lo cual nos mostrará
las referencias:

Figura 10

Damos un click derecho sobre la única referencia que apareció y seleccionamos "Follow in Disassembler". De esa
manera llegaremos al chico malo. Llegar hasta él como más les agrade.

Como ya dijimos, el chico malo comienza en 40D2B3, asique reiniciamos Olly y ponemos un BP Hardware On
Execution en dicha dirección, damos F9, y Olly se detiene en ella:

Figura 11

Apartir de aquí pueden tracear con F7 para entrar a los CALLs y ver que ocurre o lo leen del tute. La llamada de
40D2B3 obtiene el nombre del módulo que estamos ejecutando, o sea NO$MSX.EXE (incluido el path), a través
de una llamada a la API GetModuleFileNameA. Luego llama a CreateFile para abrir este archivo para lectura
obteninedo un handle a él, a través del cual invoca a la API SetFilePointer para posicionarse 16 bytes antes del
final del archivo, para luego por último llamar a ReadFile y leer estos 16 bytes finales a un buffer que queda en
la posición 4286E6 (al menos en mi PC):

Figura 12

si abren el archivo con un edito Hexa y van al final del mismo, verán que los últimos 16 bytes concuerdan con
los de la Figura 12. Una vez que regresamos de la llamada 40D2B3 al código del chico malo, veremos que en
40D2B8 se carga en EDX la dirección 428600 lo cual no son ni más ni menos que los últimos 4 bytes del archivo
con la base incluida.

Al entrar en el CALL de 40D2D4 vemos que se llama nuevamente a la API SetFilePointer para posicionar el
puntero en el offset 26800 del archivo. Retornamos al chico malo nuevamente y seguimos traceando. Cuando
entramos al CALL de la dirección 40D2E3 este leerá 24 bytes a partir del offset 26800 y los almacenará en un
buffer cuya dirección en memoria es 42EE8E. Luego de que se ejecute la llamada a ReadFile que lee dichos
bytes, vamos a 42EE8E y vemos la siguiente cadena:

Figura 13

Si vemos la Figura 11, en 40D2E8 y 40D2F3 se comparan 000A contra 6D24 (cadena ASCII "$m") y 0000 contra
3076 (cadena ASCII "v0") respectivamente. Como habrán notado, tanto 000A como 0000 son parte de los
últimos 24 bytes leidos de NO$MSX.EXE, pero obviamente, como el archivo está desempaquetado, las
comparaciones serán desiguales y eso es lo que nos expulsa.

Hay 2 formas de solucionar esto: Una es interceptar la llamada a CreateFile y cambiar el nombre del archivo a
leer, para que leea el EXE original en lugar del desempaquetado. Si lo prueban verán que el programa arranca.
Pero la forma fina dentro del cracking bruto (unpacking+patching) es la siguiente:

Abrimos el EXE original sin desempaquetar (recuerden que dije hacer una copia) y nos dirigimos al offset 26800
para ver que contienen los 24 bytes que se leerán:

Figura 14

Dicha string, en nuestro archivo desempaquetado ya no se encuentra en el offset 26800, por lo tanto abrimos el
archivo desempaquetado con un editor hexa y buscamos la cadena No$msxRomPakRev0, para ver en que offset
se encuentra:

Figura 15

la cual vemos que está en el offset 6F000. Si prestan atención, en 6F002 y 6F00E están los bytes de las
respectivas comparaciones 40D2E8 y 40D2F3. Si hacemos un poquito de memoria observando la Figura 12,
vemos que el offset 26800 se obtiene leyendo los últimos 4 bytes del archivo, entonces si abrimos el archivo
desempaquetado y cambiamos estos útimos 4 bytes "00 68 02 00" (0026800) por estos otros: "00 F0 06 00"
(0006F000) guardando los cambios, ya hemos resuelto el problema y NO$MSX se ejecuta a la perfección:

Figura 16

A alguno se le habrá ocurrido invertir los saltos luego de las comparaciones en lugar de hacer esto. Si hacen eso
verán que el programa se ejecuta también, pero hay diferencias:

Figura 17

Notan las diferencias entre las Figuras 16 y 17? Claramente se observa que en la 16 están las instrucciones del
BIOS ROM del MSX, mientras que en la 17 no, lo cual a la hora de cargar un ROM de estas computadoras en el
debugger/emulador, este no se ejecutará si hemos solamente invertido los saltos.

Por lo tanto el razonamiento es el siguiente: Las dos comparaciones, más que para detectar el unpacking, están
para asegurarse que el BIOS ROMS del MSX ha sido leido con éxito para que el debugger funcione
correctamente, lo cual guarda lógica con el mensaje de error: "Damaged ROM Package".

De hecho para asegurarme que así sea, reinicié Olly y puse un BP en ReadFile luego de que el EXE fue abierto
para lectura, y además de leer de este los últimos 16 bytes y los 24 del string de chequeo, se leen del mismo
dos tandas más de 0x8000 bytes cada una, las cuales no son ni más ni menos que los BIOSes ROMs del MSX2 y
del MSX1, ya que este debugger permite emular ambos sistemas, además de que 0x8000 bytes = 32678 bytes y
ese es justamente el tamaño de los BIOSes ROMs de estos sitemas.

Por consiguiente, supongo que una vez que nuestro amigo Martin compiló y linkeó NO$MSX, introdujo en forma
de DATA OVERLAY los BIOSes ROMs del sistema MSX dentro del EXE, para no distribuirlos fuera de él por
separado conjuntamente con su aplicación, para de esa forma evitar algún tipo de problema legal.

Ese es el porqué en la Figura 01 vemos que dice [overlay]: En el momento en que el archivo va a ser
empaquetado, UPX detecta la DATA OVERLAY, entonces lo que realiza primero es el empaquetado del archivo y
luego copiar a él estos bytes que conforman la DATA OVERLAY al archivo empaquetado. Luego nuestro querido
amigo Martin se dirigió a los últimos 4 bytes del archivo empaquetado y editó a mano la dirección a partir de la
cual la DATA OVERLAY comenzaba, para asegurarse que los BIOSes ROMs se carguen correctamente.

Ya hemos develado todo el misterio. Solo queda registrarnos. Si vamos a Help->About veremos:

Figura 18

Como ya tenemos el archivo desempaquetado, solo debemos abrirlo con un edito Hexa y buscar la cadena
[could see your......]. La encontraremos en el offset 0x23004 y podremos cambiarla por la que queramos,
terminando la nueva cadena con un "00" que indique su final, guardamos los cambios y listo: Programa
registrado.
Pero como a este Martin le voy a contestar como se merece, también le crackearé el programa encontrando el
KeyFile correcto.

Cargamos en Olly el EXE empaquetado o el que no fue emparchado en la cadena [could...]. Ponemos en la línea
de comandos "BP CreateFileA" y damos F9 cada vez que Olly se detenga, siempre observando en el STACK el
nombre del archivo que se le pasó como parámetro a la API en la que pusimos el BP.

Luego de dar aproximadamente 7 veces F9, vemos que el contenido del STACK es el siguiente:

Figura 19

lo cual quiere decir que se intentará abrir el archivo NO$MSX.KEY para lectura. Como no está ese archivo, lo
creamos en la carpeta donde instalamos la aplicación, por ahora sin importarnos el contenido. Luego de creearlo
seguimos traceando con F8 para abrirlo y llegar hasta el código del programa (lo cual es en 40A3E9) y observar
el handle que retornó la API en el registro EAX. En mi caso este es 7C:

Figura 20

Quitamos el BP anterior escribiendo BC CreateFileA seguido de Enter y ponemos BP ReadFile. Damos F9 y

prestamos atención en el STACK cuando se detiene, para corroborrar que se van a intentar leer bytes del
archivo que tiene el handle 0x7C, el cual es NO$MSX.KEY. Con una vez que demos F9 se detiene para leerlo:

Figura 21

Vemos que del mismo se intentarán leer 319 bytes que se almacenarán en el buffer de la dirección 46BFEC.
Editamos el archivo NO$MSX.KEY cargando en él lo que más nos guste, guardamos los cambios, y volvemos a
Olly. En el Dump nos vamos a la dirección del buffer y seguimos traceando hasta salir de la API y llegar al código
del programa, donde alcanzaremos la dirección 40A4D7. A partir de aquí seguimos traceando con F8 hasta pasar
el primer RETN que encontremos y llegamos a 407DE1:

Figura 22
Aquí está todo el código que manipula a los bytes del nuestro KeyFile. El CALL de 407DE2 solamente cierra el
handle a 0x7C. En 407DEA ESI queda apuntando al final del contenido del archivo leido, y luego se carga el
caracter 0x1A. En 407DEF se hace que ESI apunte al comienzo de lo que se leyó, y en 407DF1 se desplaza el
puntero 0x13 bytes. Mientras que las CALLs de las direcciones 407DF4, 407DF9, 407DFE, y 407E03, siempre
llaman a la misma función:

Figura 23

En definitiva, el código de la Figura 22 conjuntamente con el de la 23, lo que realiza es desplazarse 0x13 bytes
desde el comienzo del buffer quedando el puntero apuntando al byte 0x14, para luego leer 4 bytes más con los
cuales dependiendo de sus valores se realizan unos cálculos acumulativos en el registro EBX.

Al terminar de ejecutarse estas 4 llamadas ESI queda apuntando a la posición 0x18 del buffer. En 407E08 se
almacena el valor de dicho puntero en la pila, y luego comienza un ciclo entre 407E09 y 407E16 que se repite
hasta encontrar el caracter 0x1A (o cualquiera ASCII menor a 0x20 que hayamos ingresado en nuestro archivo).
Durante ese ciclo se siguen realizando cálculos y rotaciones con EBX y EAX en base a los valores de los bytes
leidos en el ciclo usando el puntero ESI.

Pero si prestamos atención, al final del ciclo se carga nuevamente en ESI el valor almacenado previamente en la
pila (dirección 407E18), por lo que ESI apunta nuevamente al comienzo del byte 0x18 del buffer. Luego en
407E19 se le suma 0x13 al puntero dando como resultado 0x2B.

Por último en la dirección 407E21 se carga en EDI la cadena [could see your name here if registered], la cual es
reemplazada con los bytes a los que apunta ESI a través del ciclo que hay entre 407E26 y 407E2C, agregando
por último un 0 al final de EDI una vez que ESI fue copiada para indicar el final de la cadena.

Conclusión: Los cálculos y rotaciones que se realizan con los registros EBX y EAX al leer los valores de ESI, no
sirven más que para despistar, ya que no se utilizan en ningún momento debido a que siempre se cargará en EDI
el contenido que hay en el buffer a partir del byte 0x2B inclusive, independientemente de los valores que EBX y
EAX obtengan. Y como 0x2B = 43 lo que debemos realizar es escribir en NO$MSX.KEY el nombre con el que
queremos registrarnos a partir de la posición 42 (ya que el primer byte está en la posición 0), sin tener en
cuenta los bytes anteriores.

Por tal razón, como dedicatoria a mi buen amigo Martin, he creado un archivo NO$MSX.KEY que contiene lo
siguiente:

Up to now, NO$MSX v_1.5, is registered to The BIG Master SACCOPHARYNX

^
|--- offset 42 en el archivo.

para que cuando vaya a Help->About pueda ver:

Figura 24

Querido amigo Martin, te prometo una cosa: CRACKEARÉ TODAS LAS VERSIONES QUE REALICES DE AHORA EN
MÁS, NOTIFICÁNDOTE DE TAL HECHO, HASTA QUE ME PIDAS DISCULPAS, JEJEJE. Sigues creyendo que soy
"NADA"?
 Saludos
Pero por favor, alguien duda a quién le mando saludos? por supuesto que a mi buen y querido amigo Martin
Korth, jajajajaja.............

Desde las profundidades del abismo...

http://www.sleepersbrains.com/
saccopharynx@yahoo.com