Hola a todos, tras algunos años de ausencia he decidido volver al foro (https://foro.elhacker.net/foro_libre/presentacion-t521505.0.html;msg2278764#msg2278764), y qué mejor manera de hacerlo que ensuciándonos un poco las manos destripando cartuchos de Game Boy.

En este thread voy a compartirles un proyecto didáctico en el que estuve trabajando para explicar las bases de Game Hacking a usuarios que se acercaban al tema por primera vez.


Introducción

Seguramente muchos de ustedes ya han experimentado en su época con Cheat Engine, o incluso habrán llegado a conocer los llamados "game enhancers" como Game Genie o Game Shark. Algunos venían en formato CD (Game Shark para PSX) y otros eran un dispositivo de hardware dedicado que interconectaba la consola con el cartucho que quisieramos "mejorar" (Game Shark para Game Boy).

Estos "mejoradores" de juegos nos permitían activar "cheats" o "trucos" de una forma simple y efectiva: modificando los valores almacenados en memoria (ya sea una sola vez, por ejemplo para agregarnos dinero o items; o permanentemente evitando su modificación, por ejemplo para evitar perder puntos de salud y ser inmortales).

Acá les dejo una foto del mío, un GameShark para Game Boy que apareció en Uruguay sellado y con sus plásticos originales.







Hoy en día los propios emuladores traen plugins para cumplir la función de un GameShark (o Game Genie), por lo que decidí programar un cartucho de pruebas para - como mencioné al principio - poder explicar de forma virtual y simple los conceptos básicos de game hacking para cualquier interesado, y evitar que se pierda esta hermosa costumbre de destripar cosas para aprender cómo funcionan.


Game hacking en Game Boy

Como este proyecto apunta mayormente a la manipulación de registros de memoria (el "qué" - contenido - y el "dónde" - posición de memoria) no vi una necesidad imperiosa de incursionar en frameworks de desarrollo como gbdk o GBASM (el "cómo", en este caso), por lo que decidí utilizar GBStudio para ahorrar tiempo (y salud mental). Llamé a este proyecto "DVHR" (Damn Vulnerable Hack Rom), y decidí agregarle varios sprites para que sea tan didáctico como fuese posible. La emulación fue hecha con VisualBoyAdvance, el cual trae integrado un emulador de Game Shark.

El cartucho representa el viaje de un personaje desconocido por tres escenarios (desafíos) hasta llegar a reunirse con otros personajes desconocidos. La idea de esta premisa tan genérica es poder adaptar la narrativa a cualquier público que esté siguiendo el tutorial.



El primer escenario representa un problema clásico para toda aventura: la necesidad de fondos para emprenderla. Si miramos los indicadores superiores en la siguiente captura, veremos que nuestra bolsa está vacía (valor "0") y de no solucionar este inconveniente, no podemos avanzar al siguiente escenario.



En la esquina inferior izquierda el cartucho nos sopla la solución: 0101 98CB ¿pero qué significa esta cadena?

Este es un código Game Shark, a grandes rasgos:

0101 representa un valor.

98CB representa una posición de memoria.

Este código colocará los valores "0101" en la posición "98CB". Si espiaramos esa posición de la memoria en el cartucho en ese preciso momento, veríamos que el valor es "0". Esa posición está guardando el valor de nuestro dinero, por lo cual modificarla nos permitirá "mejorar" nuestra experiencia de juego.



Utilizando el plugin de Game Shark de VisualBoyAdvance podemos ingresar este "cheat" e incluso guardarlo con un nombre amigable (como en los Game Shark originales).

Al colocar este código el juego dará por concluído el desafío y nos llevará al siguiente escenario, donde un Goblin nos cortará el paso.



Para resolver este escenario deberemos modificar dos registros, uno donde se almacena el "Escudo" (y colocarlo en 1) y otro donde se almacenan los puntos de Salud del Goblin (colocándolos en 0 para... "mejorar" nuestra experiencia de juego).

Nuevamente el juego nos sopla dos cadenas, que nos ayudarán a entender mejor la estructura de los códigos Game Shark:

0101 9ACB: Colocar el valor "0101" en la posición "9ACB".

0100 9CCB: Colocar el valor "0100" en la posición "9CCB".

De acá podemos inducir dos cosas importantes (de nuevo, a muy grandes rasgos):

- Del primer sector de la cadena (los primeros 4 dígitos), los últimos dos son los que modifican el valor de las variables. En el primer caso vamos a colocar el valor en "01" (Escudo) y en el segundo en "00" (HP del Goblin), a pesar que ambos empiezan por "01".

- Hasta ahora, todas las posiciones de memoria que estamos modificando terminan en "CB", por lo que si bien no son contiguas, comparten un espacio acotado y relativamente cercano. Esto también podemos saberlo leyendo los documentos técnicos sobre manejo de memoria de la consola y la documentación de los MBC (Memory Bank Controllers). Pero un recién interesado en el tema claramente no disfrutará haciéndolo.

Agregando estos dos códigos nos haremos con un nuevo escudo, una piel de Goblin y un nuevo desafío. O mejor dicho... dos.



Esta vez tenemos dos enemigos que nos cortan el paso: una Serpiente y un Murciélago, pero ya no hay soluciones disponibles. Al parecer, los puntos de Salud (HP) de la Serpiente oscilan entre 2 y 4 (y tenemos que bajarlos a 0) y los del Murciélago oscilan entre 6 y 8 (y claramente, también hay que bajarlos a 0).

Tenemos la siguiente estructura de códigos:

0100 ??CB: Colocar el valor "0100" en la posición "??CB".

0100 ??CB: Colocar el valor "0100" en la posición "??CB".

Sabemos que hay que colocar en "00" dos valores ubicados en la misma "vecindad" (espacio) de memoria donde vinimos trabajando hasta el momento. Parece que se nos ha agotado la suerte pero no, es hora de aprender a buscar cheats como en la vieja escuela... rompiendo.

Un feature que tenían los Game Sharks (no todos, sino algunas versiones) es la capacidad de "buscar" trucos... ¿cómo funciona? buscando un valor específico a lo largo de la memoria y siguiendo eventuales cambios para aislar e identificar posibles posiciones de memoria de interés.

En palabras más simples, supongamos que nuestro personaje tiene un valor específico de "Oro", por ejemplo, 151. Mapeamos el valor 151 y nuestro "mejorador" de juegos va a darle seguimiento, dándonos una lista de todas las posiciones de memoria del juego que estén guardando ese valor (que podrían ser muchísimas). Gastamos 1 de Oro y el valor ya no es 151, sino 150. Ahora no buscamos "qué posición tiene en este momento el valor 150", sino "qué posición tiene en este momento el valor 150 y anteriormente tenía el valor 151". Esto desencadena un proceso de eliminación que nos irá arrojando cada vez menos candidatos hasta identificar la posición específica que queremos manipular. Una suerte de "Adivina quién" pero con un depurador.

El "Game Shark" integrado en la mayoría de los emuladores permite este comportamiento, así que vamos a buscar valores de interés. Comencemos por el valor "techo" del HP de la Serpiente: 4.



Aparentemente, ninguna posición de memoria está guardando ese valor, por lo que sabemos que no es el que estamos buscando. Repitamos el proceso para el valor "techo" del HP del Murciélago: 8.



Bingo, encontramos varios candidatos y uno está en la vecindad que buscamos ("CB").

Acá es donde varios habrán notado algo extraño: la notación de la dirección de memoria está "al revés" ("CB" está primero que "A0"). Esta diferencia en la notación es común, a veces ciertas instrucciones o direcciones se representarán "al revés" según el programa (o plug-in) que estmos utilizando. Los que en algún momento de sus carreras hayan usado debug.exe en Windows para programar en ASM sabrán a lo que me refiero.

Vamos a colocar ese valor en "0", y continuamos repitiendo el proceso con los demás valores (2 y 3 para la Serpiente) hasta aislar las posiciones de memoria sospechosas.



Acá es donde viene útil una advertencia amistosa: cuando estén buscando cheats o manipulando la memoria de un programa en general, es muy común que a veces identifiquemos mal una dirección, alteremos su valor y suframos consecuencias inesperadas. En los cartuchos de Game Boy el peor escenario posible es un Kernel Panic, nada que no se resuelva reiniciando la consola o el emulador. Pero es ideal tener sumo cuidado cuando se manipula la memoria de algún otro proceso "más serio" que no esté aislado por un emulador ni sea un simple juego didáctico.

Ejemplo de un Kernel Panic en Game Boy:



Una vez que aislamos las posiciones de memoria sospechosas y cambiamos los valores necesarios, lograremos resolver el desafío.



Si prestan atención verán debajo la solución del mismo. Si prestan aún más atención, verán que el cheat resaltado en el Game Shark no se corresponde a esas soluciones, sino que fue un error de mi parte al intentar aislar e identificar la posición de memoria (y afortunadamente, no causó un Panic).



Finalmente nuestro personaje llegó al final de su aventura (sea cual sea su objetivo) y pudimos explicar de forma didáctica una introducción básica a cómo funciona el Game Hacking de la vieja escuela.


Outro

Espero que el hilo no se haya hecho tedioso ni extenso. Desde ya es un gusto estar de vuelta con ustedes, y cualquier crítica constructiva siempre es bien recibida.

Espero que les haya gustado, nos vemos en la próxima.


Referencias y links de interés
- Tweet con las fotos originales: https://twitter.com/MauroEldritch/status/1591444536152449024
- Una historia de cartuchos piratas: https://twitter.com/MauroEldritch/status/1740129623814414704
- Descargar una copia de DVHR: https://mega.nz/file/Jc0kTITD#v8PQbbZojCN1yuoPhtFqoQ9HxLyHb6CH4IyUjuUEO9I
- GBStudio: https://www.gbstudio.dev/es/
- VisualBoy: https://visualboyadvance.org/

Ningún Goblin fue lastimado durante la producción de este artículo.

¿Cómo estás Tachikomaia? Gracias por comentar!

El filtro de "old value" es justo el que doy como ejemplo acá cuando digo "busquemos una posición de memoria que tenga el valor 150 pero antes tenía valor 151" (ahí está el old value, 151). Los demás filtros aplican distintas lógicas para ayudarte a aislar esa posición.

Yo hacía eso mismo que mencionas en Final Fantasy Tactics y Resident Evil 2 (PSX), había situaciones donde muchos cheats "chocaban" entre sí y rompían todo, y entonces desactivaba gradualmente hasta que funcione  

Buenísimo análisis de Mario Tennis, recuerdo haberlo jugado (pero no hackeado) para Game Boy, así que era una versión ultra básica aunque sí contaba con medidores de fuerza y un doble como tú dices. Lo del bloc de notas lo hacía también con algunos Sharks como el de PSX (que venía en CD) porque no tenía más espacio en la Memory Card (y era una época de crisis como para ir a comprar una extra   ).

En los juegos "más complicados" pasa eso que mencionas, a veces se require más de un código y hay varios motivos:

- Hay varios sectores de memoria que componen el valor que queremos modificar.

- Hay un sector "testigo" - como un token canario - que guarda una copia de un valor específico y se va modificando a la par que el original. Si hay una diferencia inesperada entre los valores, se considera el del canario como válido y se "arregla" la diferencia reestableciendo el valor desde ahí. Esto lo puedes ver en juegos donde modificas por ejemplo el dinero, y este hace un "flash update" (lo ves actualizarse y de golpe volver al valor anterior en menos de un segundo).

- Existen barreras lógicas que monitorean que el valor esté en un rango esperado. Aunque la posición de memoria soporte el valor que estás expresando, una rutina de control podría decir "momento, no está bien que tengas este item/dinero/stat en este punto (o no está bien que lo tengas en ningún momento)" y le aplica una corrección.

- Podría ser que el juego en cuestión utilice alguna aleatorización de direcciones/espacio de memoria y por eso a veces los códigos funcionen y otras veces no (en las consolas sobre las que hago esto que son viejitas nunca lo he visto, pero quizás alguien pueda darnos más contexto en máquinas más modernas).

Para la consulta de Tsubasa no lo he visto en detalle pero es una buena pregunta, si funciona como un stat oculto suele ser bastante engorroso aislarlo (porque muchas veces también lo calculas a ciegas). Me pasaba en ciertos RPG con stats ocultas como "lealtad" / "amistad" (que no te avisaban tampoco cuando un personaje subía o bajaba el stat, ni te mostraba el valor exacto). Encontrarlo era difícil incluso usando los filtros: "debe ser un stat que subió porque la pelea salió bien"... si, pero la EXP y otros stats subieron también... y había 8 personajes en el tablero... si hacemos algunas multiplicaciones de stats * personajes...   (como decís, es un misterio a veces).

Lo de las fórmulas de Mario Tennis de momento te la debo, no lo sé honestamente   pero me lo llevo de tarea, porque está dentro de las consolas donde suelo destripar cartuchos   .

Esa última pregunta es buenísima porque es algo muy común de encontrar y te obliga a ejercitar mucho la lógica. En términos de programación para que una condición se cumpla pueden haber escenarios tan simples como complejos. Vamos a tomar el caso que me dices sobre los cristales que se rompieron (no jugué ese juego pero para el caso sirve):

Puede ser algo tan sencillo como que el programador haya hecho algo así:


O también


Y esto se traduciría en nuestro depurador como un cambio en una variable que pasó de "00" (0 o "falso") a "01" (1 o "verdadero"). Este es el tipo de caso sencillo que exploto en el cartucho del thread, una simple variable fácil de aislar. Cambiar este valor marcaría el evento como hecho.

Pero también existe la posibilidad que el programador haga algo como esto:

(recuerda que no jugué ese juego y estoy inventando condiciones para este ejemplo)


Puede ser que este cambio de escenario sea disparado tras monitorear varios aspectos (variables) y no sea fácil aislarlo. Quizás el evento nunca sea realmente marcado en la memoria como que "ocurrió", por ejemplo en GameBoy se puede usar el cambio de escena que inicia como el nombre indica un nuevo escenario. En el cartucho de ejemplo nunca marco "se dispara el escenario 3", sino "se cumplieron ambas condiciones del escenario 2, ejecuta un cambio de escena" (como en el último ejemplo que invocamos la función evento_romper_cristales()). Esa función puede no retornar ni escribir un valor, y su paso por la máquina no nos deja un registro claro, más allá de que el escenario avance.

Exactamente esto me pasó con The Dark Eye (https://en.wikipedia.org/wiki/The_Dark_Eye_(video_game)) donde logré dar por completados algunos escenarios pero olvidé marcar otras condiciones que ocurren a medio camino, quedándome soft-locked, y es común que te suceda en juegos que requieren muchos items y condiciones para progresar como las sagas Resident Evil, quizás logres bypassear una puerta molesta, pero en el trayecto para descubrir lo que la abre levantarías un item que te serviría más adelante (y que ahora no tienes por haber bypasseado).

Es mucho prueba y error. Ojalá te haya dado algunas ideas para intentar destripar esos juegos un poco más. Te dejo un abrazo y gracias por comentar.

Hola!

Claro, cuando cargas una partida tienes dos posibilidades:

- Si lo haces desde el emulador (cargando el savefile como un quicksave) estás cargando un "state" (estado general) del cartucho en un momento dado, incluyendo los valores de la memoria. Esto claramente sobreescribe cualquier código que tengas activado. Lo interesante es que si activas un truco y haces un quicksave, como este es en realidad una modificación de la memoria queda almacenado cuando vuelvas a cargarlo.

- Si lo haces desde el juego (con el menú correspondiente) podrías disparar una rutina que "normalice" (limpie) todos los valores primero y luego coloque los de tu partida. Eso explicaría por qué no funciona.

En tu caso estás cargando dos partidas diferentes, dudo que funcione. Intenta cazar trucos en una misma partida ya sea nueva o cargada desde el menú contextual del juego y no con save-states, quicksaves u otras opciones del emulador.

Saludos!