Más vidas para el Gyroscope en un par de minutos

[nacho]

Buenas...

Buscando juegos que proponer a mis alumnos para la sgunda evaluación, he dedicado un momento al Gyroscope y he recordado lo cortas que se quedaban las vidas que el juego proponía, así que le he puesto unas cuantas más para poder capturar varias pantallas...

El proceso que he seguido es muy sencillo (lleva apenas un par de minutos) y aun así funciona en bastantes juegos, así que me he tomado el rato de teclearlo para copiarlo y pegarlo aquí, por si a alguien más le sirve también para "facilitarse" la vida en algún juego de los que todavía no están "facilitados"... y le sirve este sistema:

---

Creamos un "snapshot" del juego con 5 vidas. Dejamos "perder" una vida y volvemos a crear un "snapshot" del juego con 4 vidas. Cuanto más se parezca el estado general del juego en ambas capturas, menos trabajo nos costará encontrar lo que buscamos, y menos "falsos positivos" podemos tener (lo ideal es que el personaje esté en la misma posición de la pantalla, etc).

Comparamos los dos Snapshots con la orden FC del sistema operativo (MsDos o Windows), usando la opción /B (comparación binaria), redirigiendo el resultado a un fichero para poder analizarlo con comodidad:

FC gyroscope4vidas.sna gyroscope5vidas.sna /B > difGyroscope4y5

(Yo uso Total Commander para pasear con tranquilidad por las carpetas y poder teclear órdenes fácil,ente en cualquiera de ellas). Si analizamos ese fichero resultante, veremos una línea como

599D: 04 05

Es decir, en la posición 599D (en hexadecimal) aparece un 4 en el primer snapshot (la captura con 4 vidas) y en el segundo snapshot aparece un 5. Tiene buena pinta...

Podemos usar un editor hexadecimal (más detalles al final) para cambiar ese 4 por otro valor, volver a guardar el snapshot modificado, En mi caso, lo he cambiado por un 64 (40 en hexadecimal), para ver si obtenía 64 vidas. He vuelto a cargar el snapshot y aparecía en pantalla inicialmente "4 vidas"... pero dejamos que nos maten y ahora tenemos "p vidas"... conseguido...

Con eso hemos aumentado el número de vidas. Pero... ¿y si aún no son suficientes, si preferimos "no morir"? La solución sería "eliminar" la orden que disminuye el número de vidas.

Deberíamos buscar algo como

LD A, (vidas)
DEC A

(cargar en el acumulador la cantidad de viddas, disminuir el contenido del acumulador) y cambiar la segunda orden por un NOP (no operación).

El fichero de snapshot tiene un cabecera de 256 bytes (100 en hexadecimal), por lo que deberemos la dirección "en memoria" en la que se encuentra el número de vidas no es 599D sino 589D. Por tanto, la orden "LD A, (vidas)" equivale a la secuencia de bytes hexadecimales

3A 9D 58

(la dirección de memoria aparece con los bytes invertidos: 9D 58 en vez de 58 9D).

Y el "DEC A" equivale a 3D, que deberíamos reemplazar por un 00 (NOP)... si lo encontramos.

En el caso de Gyroscope, si buscamos la secuencia 3A 9D 58 con el editor hexadecimal, la encontramos sólo en un par de posiciones. Pero... lástima... no hay ningún 3D a continuación. Podríamos analizar el código fuente, a partir de ese punto, usando los depuradores que incluyen algunos emuladores, pero estamos partiendo de la hipótesis de que no queremos aprender ensamblador...

Así que podemos limitarnos a dejar el juego con más vidas, bien sea modificando el Snapshot, o bien, si el juego tiene un cargador en Basic, podríamos modificarlo, añadiendo entre el LOAD que carga el programa binario y el CALL que lo lanza, la orden

POKE &589D, 50

(50 es un número de vidas de ejemplo; se podría poner otro, o preguntar al usuario).


Incluso sin saber ensamblador, siempre nos quedaría la alternativa radical: ver dónde se disminuye el valor del acumulador y se compara con cero, pero eso es una operación demasiado frecuente, y peligrosa de hacer "a ciegas", que puede ser trabajosa y provocar resultados inesperados (recordad experimentar siempre sobre una copia del juego original), así que... no he dicho nada.


Recursos adicionales:

- Editor hexadecimal XVI32:

http://www.chmaas.handshake.de/delphi/f ... /xvi32.htm


- Lista de "opcodes" (códigos de operación) del procesador Z80, para saber a qué orden corresponde cada byte hexadecimal:

http://www.zophar.net/fileuploads/2/108 ... 0opcod.txt

[Mode 2]

El proceso que he seguido es muy sencillo (lleva apenas un par de minutos) y aun así funciona en bastantes juegos, así que me he tomado el rato de teclearlo para copiarlo y pegarlo aquí, por si a alguien más le sirve también para "facilitarse" la vida en algún juego de los que todavía no están "facilitados"... y le sirve este sistema:

A mi me viene de perillas porque estoy ahora metido en temas de cargadores, pokeos, eestructuras de disco/cinta, protecciones, co/ma, etc ....

Muchas gracias Nacho!

Nota:
Nacho, me ha gustado bastante la segunda parte del minitutorial porque la primera parte de usar snapshots y la comparación binaria le ha quitado cierto encanto aunque es efectivo.

A ver si tienes tiempo un día y pones un ejemplo a la hora de solventar uno donde no haya vidas y sí energía.
Saludos!

[nacho]

Nacho, me ha gustado bastante la segunda parte del minitutorial porque la primera parte de usar snapshots y la comparación binaria le ha quitado cierto encanto aunque es efectivo.

Pero es que la segunda parte es "más técnica" y la primera es la magia de los emuladores: capturas el estado de la memoria en dos circunstancias, comparas y en 30 segundos tienes la posición en la que se encuentran las vidas, sin necesidad ni de saber de ensamblador.

Por ejemplo, en un momento lo he hecho para dos juegos sencillos y muy similares entre sí, por si plagiamos alguno de ellos en clase como mini-proyecto conjunto de una semana:

--
En Hunchback:
006336 = posición de las vidas en el snapshot
-> 006236 (dirección de las vidas)

En 5AA7 (del fichero): 3E 04 32 36 62, luego
POKE &59A8, 50 para más vidas iniciales

En 5217 (del fichero): 3A 36 62 3D
POKE &511A, 0 para vidas infinitas

--
En Punchy:
002cd8 = posición de las vidas en el snapshot
-> 002bd8 (dirección de las vidas)

En 21a9:03 (vidas iniciales)
Parte de 3E 03 32 D8 2C

Para poner más vidas:
105 POKE &20a9, 50

A ver si tienes tiempo un día y pones un ejemplo a la hora de solventar uno donde no haya vidas y sí energía.

La idea sería la misma: capturas dos snapshots que se diferencien sólo en la energía del protagonista (o casi) y comparas, para ver en qué dirección está. Apenas hay un par de dificultades añadidas:

- Si la energía no es un número, sino una barra, puede ser difícil saber por qué valor va (no es lo mismo contar 3 "muñequitos" que 80 líneas), y no tendrás tan claro qué valor buscar, aunque capturando 3 o 4 snapshots en vez de 2 puede ser bastante evidente, porque sería un valor que disminuyera en todos ellos (mientras que la posición de los personajes del juego, etc., podría aumentar y disminuir).

- Si la cantidad máxima de energía pasa de 255 (no es lo más frecuente), sería un dato de 2 bytes, que no se guardaría en el registro A, sino en uno de 16 bits, como HL, y las órdenes a buscar serían distintas.

[Mode 2]

- Si la energía no es un número, sino una barra, puede ser difícil saber por qué valor va (no es lo mismo contar 3 "muñequitos" que 80 líneas), y no tendrás tan claro qué valor buscar, aunque capturando 3 o 4 snapshots en vez de 2 puede ser bastante evidente, porque sería un valor que disminuyera en todos ellos (mientras que la posición de los personajes del juego, etc., podría aumentar y disminuir).

Sí, lo que ocurre que ambas capturas de diferencian seguramente en muchos bytes porque aunque estes en la misma posición quietecito existen muchas variables.


No te digo que no tenga sus ventajas el emulador y tal pero lo que te quiero decir y me remito a MSDOS, aunque he visto que esto es igual, que para mi era más apasionante usar Debug para conseguir vidas o quitar protecciones que el Game Wizard (creo que se llamaba así) o cualquier programa hecho a la carta para zumbar protecciones.

Está claro que él que quiera ponerles vidas sin aprender nada de ensamblador le vendrá fenomenal pero creo que esa persona pillará ante los miles de pokes que hay ya definidos ¿no crees?

[nacho]

Sí, lo que ocurre que ambas capturas de diferencian seguramente en muchos bytes porque aunque estes en la misma posición quietecito existen muchas variables.

Esos juegos que he probado salían a diferenciarse en unos 500 bytes (a veces menos de 200, a veces cerca de 800), pero casi ninguno de ellos ha disminuido de 3 a 2 (habitualmente sólo 1, el de las vidas) así que basta con buscar " 03 02" en el fichero de diferencias, y es instantáneo.

No te digo que no tenga sus ventajas el emulador y tal pero lo que te quiero decir y me remito a MSDOS, aunque he visto que esto es igual, que para mi era más apasionante usar Debug para conseguir vidas o quitar protecciones que el Game Wizard (creo que se llamaba así) o cualquier programa hecho a la carta para zumbar protecciones.

Te entiendo. He probado herramientas de los dos estilos en mis tiempos de cracker (porque lo de hacker se queda un poco grande ), tanto en MsDos y Windows: herramientas básicas como Debug, algo más avanzadas como Turbo Debugger, algo más automáticas como GameTools y super versátiles como IdaPro... y alguna más cuyo nombre no recuerdo, y que tendría que buscar en la copia de seguridad. En los tiempos del CPC ya jugaba un poco con el Gena y el Mona para aprender... pero a la hora de la verdad, cuando quería ir rápido y no pretendía entender cómo funcionaba un progama por dentro, sino simplemente poner más vidas a un juego difícil, me limitaba a tirar del Discology y editar pistas del disco a saco, usando las mismas ideas que he puesto en este post, de buscar secuencias de bytes "sospechosas" y modificarlas (sin usar snapshots, con lo cual la primera etapa era más lenta).

Está claro que él que quiera ponerles vidas sin aprender nada de ensamblador le vendrá fenomenal pero creo que esa persona pillará ante los miles de pokes que hay ya definidos ¿no crees?

Sí, pero hay muchos juegos minoritarios para los que no hay pokes (al menos no en la versión que yo tengo, que suele ser la de NVG, tomada del CpcGamesCd), y entonces un par de pinceladas de este estilo pueden ser útiles para intentarlo uno mismo... espero...

[Mode 2]

Te entiendo. He probado herramientas de los dos estilos en mis tiempos de cracker (porque lo de hacker se queda un poco grande ),

Yo también tuve mis tiempos de cracker bajo MSDOS y algo Windows pero este se me quedo un poco diferente y algo grande.

Con lo de hacker, lo estoy intentando y estoy inmerso en un curso bastante bueno con una gente de Suramerica pero ahora parado del todo por problemas con ellos. Vamos, estoy aprendiendo muchas cositas pero de ahí a ser un hacker hay un mundo!

A ti que se te da muy bien la programación y quizás quieras meterte un poco en el tema de Hack te recomiendo un libro que es bastante cañero pero al parecer bastante bueno:



Mil gracias.

Un saludo.

[nacho]

Retomo el tema para comentar que los días antes de vacaciones, intentaré hacer un pequeño remake de un juego sencillito con mis alumnos, como proyecto de grupo. He pensado en Astro Attack, pero como no trae pokes "de serie" (al menos en la versión del CpcGamesCd) es un poco pesado capturar pantallas, porque me mataban y jugando con teclado no pasaba de la tercera... así que he pensado que mejor le buscaba los pokes yo directamente...

Por si a alguien le apetece, ya sea MiguelSky para el Cd, o cualquier otro por experimentar, los dejo aquí (el extra de añadir algún INPUT para que pregunte al usuario ya lo dejo a vuestro criterio):

Para cargar el programita en Basic con la pantalla de carga:

LOAD "ASTRO.BAS"

Para cambiar el número de vidas a 50 (o cualquier otro numero):

545 POKE &7a5d, 50

Para poner vidas infinitas:

547 POKE &86a6,0

Para lanzar el juego facilitado...

RUN

(eso último debería ser fácil )