Con este documento espero poder satisfacer la curiosidad de todas esas personas que me han escrito pidiendo información sobre las nuevas protecciones de psx y los sistemas para engañarlas. No es claramente una guía completa del cracking, pero espero pueda serle útil a quien, con los adecuados conocimientos de base, tenga la intención de aventurarse en este tipo de "trabajos."
Premisa.__________
Para empezar necesitarás tener un buen conocimiento del ensamblador del R3000, cpu de la psx: quién ya tenga experiencia con el Amiga no debería encontrar grandes dificultades (basta con adecuarse al funcionamiento de una CPU risc); quién en cambio solo conozca el "académico" ensamblador del x86 tendrá quizás más problemas.
Necesitarás una serie de herramientas esenciales: ensamblador, desensamblador, debugger, etc... así como información del hardware específico del psx. Toda la documentación y herramientas que yo uso están disponibles en la red, (ver el final del documento).
Principio de funcionamiento de LibCrypt. __________
Como cualquier otro tipo de protección LibCrypt está compuesta por dos rutinas separadas: la primera chequea el disco para ver si se trata de una copia; y la segunda, basándose en el resultado de la primera , desencripta un bloque de datos y bloquea la psx en caso de que el resultado sea incorrecto. También basándose en el mismo código, las dos rutinas son alteradas más veces, hasta tal punto que en la última evolución (LibCrypt3) no tienen ningún parecido con el código fuente inicial. Este código está todo escrito en puro ensamblador, y usa directamente los registros hardware de la psx: no hay ninguna llamada al sistema estándar. Además, han tomado la precaución de prevenir que el programa sea trazado.
La rutina que chequea el disco utiliza directamente los registros del hardware del CD-ROM (1F80180X) y memoriza los datos temporalmente en la scratchpad memory (zona de memoria para datos auxiliares, 1F800000-1F8003FF), entonces, con un algoritmo recursivo, calcula un número de 16 bits (Magic Word) usando como parámetros de las subrutinas el valor memorizado en algún registro del COP0 (coprocesador del sistema), dejando a la salida la "palabra mágica" en la parte baja del registro BPC. ¡Obviamente el BPC tendrá un valor diferente en el caso de que el CD no sea original! Este uso peculiar del hardware hace fallar a la rutina en todos los emuladores de psx ya que actualmente ninguno soporta el acceso a bajo nivel del CD-ROM, pero lo más importante, la utilización de los registros del COP0 impide a cualquier Action Replay (A.R.) el trazado paso a paso del programa, además de impedirle también el normal funcionamiento debido a que el A.R. utiliza la scratchpad memory para conservar el estado real de la psx y, por consiguiente, altera los datos contenidos en esta área de memoria. Quien tenga un Pro Action Replay dotado de memoria ram será inmune al problema de compartir la scratchpad memory, por lo que siempre se prevé una rutina que detiene la psx en cuanto el Pro A.R. está activo (esta última rutina era la única que permanecía inalterada hasta ahora). Para complicar aún más las cosas el LC2 introduce un autocheck en la misma rutina que revela si ésta ha sido alterada.
La segunda rutina, la que chequea la presencia de la MagicWord en el BPC, ha sido implementada de diferentes formas en los distintos juegos : algunos realizan el chequeo inmediatamente (FF8 por ejemplo), otros esperan algún nivel (Spyro2), mientras que otros todavía realizan el chequeo cíclicamente durante algunas cargas de datos (SoulReaver) o en momentos específicos (Mulan).
Cómo saltarse LibCrypt.__________
La solución más simple parece buscar la segunda rutina y obligarle a comportarse como si el BPC contuviera la MagicWord. Por supuesto esta rutina esta casi siempre bien visible dentro del programa principal, y es fácilmente localizable porque allí la psx se bloquea. Desgraciadamente no hay solo una de estas rutinas de control sino más, así en el SoulReaver conté 3, ¡y tampoco es seguro que no nos la encontremos en el último nivel! Lo mejor que podemos hacer es alterar la primera rutina para hacerla creer que el CD es original. Por desgracia una copia normal no contiene algunos datos presentes en el CD original, y no he encontrado ningún sistema que fuerce a la rutina para que produzca la MagicWord sin disponer de estos datos. El sistema más fino hasta ahora consiste simplemente en "recoger" la MagicWord de una psx mientras está "girando" un CD en funcionamiento. Se debe tener en cuenta alterar lo menos posible el programa original (basta con sólo insertar él valor correcto en el BPC al finalizar la primera rutina).
Estamos claramente en desventaja: es necesario tener a disposición un CD que funcione (original), y dado que las MagicWords en general son diferentes de una nacionalidad del juego a otra no es posible realizar un crack "universal". Además cada nuevo juego es una historia diferente, en el sentido de que cada vez que sea necesario trazar el programa (con un debugger) a la búsqueda del punto más apropiado para primero leer y después forzar la MagicWord, lo más complicado es el hecho de que ahora (LC3) cada subprograma esta encriptado (xor) y por tanto "invisible" en el programa principal. Por si fuera poco, una vez individualizado un punto apropiado para la lectura de la MagicWord, es necesario forzar la escritura en alguna dirección de memoria en lugar de en el registro BPC, porque obviamente no puede leerse directamente del BPC utilizando el A.R.
Un ejemplo práctico.__________
Tomo como ejemplo la rutina que bloquea la psx en presencia de un A.R. porque su inutilización es necesaria antes de hacer cualquier otra cosa, y porque además es la única que no ha sido alterada hasta ahora (aun estando encriptada). Ésta es la rutina como se nos puede presenta en el ejecutable:
1) 8003a054 lui v0,0x1f00
2) 8003a058 mtc0 v0,BPC ; BPC = BreakPoint on execute address
3) 8003a05c lui v0,0x1ffc
4) 8003a060 mtc0 v0,BPCM ; BPCM = BreakPoint on execute address Mask
5) 8003a064 mtc0 v0,BDA ; BDA = BreakPoint on data access address
6) 8003a068 lui v0,0x8004
7) 8003a06c addiu v0,v0,0xa084
8) 8003a070 mtc0 v0,BDAM ; BDAM = BreakPoint on data access address Mask
9) 8003a074 lui v0,0xe180
10) 8003a078 mtc0 v0,DCIC ; DCIC = BreakPoint on control register
11) 8003a07c jr ra
12) 8003a080 nop
(1)(2) - carga $1f000000 en el BPC, el valor inicial para la MagicWord es cero (la parte baja del BPC)
(3)(4)(5) - carga $1ffc0000 en BPCM y BDA
(6)(7)(8) - carga la dirección $80035f7c en BDAM
(9)(10) - carga $e1800000 en DCIC y finalmente
(11)(12) - provoca la reentrada de la subrutina.
Los valores cargados en BPC y BPCM hacen que se pueda verificar una excepción si se ejecuta cualquier instrucción presente en los primeros 256k de memoria a partir de la dirección $1f000000, donde se posiciona la EEPROM del A.R. Los valores insertados en BDA y BDAM varian, ya que serán usados seguidamente como si se trataran de registros normales, de hecho el valor cargado en DCIC solo activa el "BreakPoint on execute" y no activa el "BreakPoint on data access". Para evitar que el A.R. bloquee la psx, necesitaremos que no esté el BreakPoint activado en su área de memoria: visto que no se pueden alterar los valores insertados en BPC y BPCM porque serán usados seguidamente, la solución más sencilla consiste en borrar (reemplazar por nop) la instrucción (10). De esta manera ningún registro se altera, pero el BreakPoint no se activa (también hubiera bastado con poner $e080 en lugar de $e180, pero un nop
es más simple:)).
Este pequeño "parche" es necesario solamente para poder usar el A.R., así que es mejor no insertarlo en el parche final, porque cuanto menos se altere el código original mejor (nunca se puede saber si una vez llegado al nivel final del juego el programa verifica el valor contenido en el registro DCIC:)).
Links.__________
Esta sección contiene los links a tres sitios repletos de todo tipo de material necesario para el desarrollo de aplicaciones de psx, y a su vez cada uno de ellos tiene links donde poder visitar otros lugares parecidos. Naturalmente no debéis olvidaros tampoco del PsEmuPro que, aún con todas sus limitaciones, es un instrumento utilísimo: gracias al debugger y al simulador de A.R. integrado permite hacer una traza del código hasta donde se puede y, ejecutando paso a paso cualquier programa, permite entender mejor el funcionamiento del R3000 más directamente de lo que podría conseguirse leyendo solo la documentación.
Napalm -
http://napalm.intelinet.com
Hitmen -
http://www.hitmen-console.org
NotYaroze -
http://www.geocities.co.jp/Playtown/2004/psx/ny_e.htm
[center]--------------------------------------------------------------------------------
Este tutorial es obra de BAD:
http://www.bad-hq.com
La traducción ha sido realizada por Murgui en primera instancia y luego revisada y modificada por jiXo.
