¿Desconstruyendo problemas técnicos de Pokémon?
(Pido disculpas si este es el lugar equivocado para preguntar esto. Creo que definitivamente está relacionado con la programación, aunque si esto pertenece a algún otro sitio, hágamelo saber)
recí jugando Pokémon Rojo y Azul, juegos que fueron muy divertidos pero que son notorios por tener numerosos problemas técnicos explotables (por ejemplo, ver este ridículo speedrun del juego que usa daños en la memoria para convertir la pantalla del elemento en un editor hexadecimal).
Recientemente, encontré una carrera rápida interesante del juego que usa un error llamado "error ZZAZZ" para corromper las ubicaciones importantes de la memoria y permitir que el jugador gane el juego casi de inmediato. De acuerdo a la descripción del autor de la speedrun, la falla ZZAZZ funciona de la siguiente manera:
Para comenzar una batalla de Entrenador, el juego necesita cargar muchos datos, como [...] el dinero que concederá si es derrotado. Cuando se carga el dinero es donde las cosas pueden ponerse realmente feas. Por razones que están más allá de mí, el dinero se almacena de una manera completamente diferente, el juego utiliza una estructura de datos de tres bytes y, en lugar de convertir el valor en binario, lo almacena en representación "humana". Por ejemplo, $ 123456 se almacenaría como 0x123456 en lugar de 0x01E240, la conversión adecuada.
[Algunas entradas no válidas en la tabla del Entrenador] apuntan a una ubicación con datos de dinero no válidos. Cuando el juego intenta realizar operaciones aritméticas con estos datos en dicha estructura, se vuelve loco y comienza a sobrescribir grandes porciones de RAM. Más específicamente, por cada bloque de tres bytes, dos de ellos contendrán 0x9999 (la cantidad máxima de dinero que un entrenador podría dar). Este patrón se repite muchas veces a través de la RAM. Para ver esto mejor, recomiendo pausar el video en el emulador después de que el entrenador ZZAZZ se enfrente y configure el visor de memoria de VBA en 0xD070.
Este análisis tiene sentido, pero como programador no puedo evitar preguntarme cómo demonios los programadores escribieron el código que lo haría posible. Ningún enfoque que se me ocurra para escribir una función que convierta un número decimal codificado en hexadecimal en decimal comenzaría a llenar bloques de memoria aleatorios con 0x9999 si la entrada no fuera un número decimal codificado en hexadecimal válido.
Mi pregunta es: sin diseñar específicamente el algoritmo para que falle de esta manera,Existe una implementación sencilla de una conversión de decimal codificado hexadecimal a decimal que podría provocar este tipo de corrupción de memoria cuando se introduce un valor no válido?
De nuevo, si esto está fuera de tema, mis disculpas. Creo que otros programadores en este sitio también pueden haber crecido jugando a este juego, y suena como un ejercicio interesante en ingeniería inversa para tratar de descubrir cómo podría ser posible un error como este.