Registrarse

Introducción a la investigación en NDS

Estado
Cerrado para nuevas respuestas.

Mikelan98

WaH used to be a bigger place...
En esta guía se explicarán, a grandes rasgos, las principales técnicas y estrategias a seguir cuando queremos investigar el contenido de una ROM, o de una parte de ella. Pero, antes de todo, debemos aclarar una pregunta que puede parecer obvia, pero que es importante responder. ¿Qué es la investigación en el ROM Hacking?

¿QUÉ ES LA INVESTIGACIÓN?

Aplicado al ROM Hacking, investigar es todo aquello destinado a obtener, en un plano teórico, los conocimientos suficientes sobre qué y/o cómo modificar en la ROM para conseguir un objetivo concreto no trivial. Esta definición es muy amplia y abarca un grupo muy heterogéneo de actividades, que describiremos a continuación.

Investigar, por tanto, requiere plantear un problema y encontrar una solución. Para ello, es imprescindible tener en mente que cualquier problema en el ROM Hacking tiene solución (aunque es posible que la solución sea demasiado compleja como para poder hallarla o aplicarla). Ante esto, debemos tener en cuenta que toda la información contenida en el juego, por importante o prescindible que sea, está dentro de la ROM, y ahí es donde debemos buscarla. El juego no es capaz de generar contenido de la nada: no es capaz siquiera de generar números genuinamente aleatorios, ¿cómo va a ser capaz de generar datos que no estén en la ROM?

Además de encontrar la localización de nuestros datos, debemos entender cómo son procesados por el juego. Para ello es fundamental entender el formato en el que están almacenados; tanto para obtener conocimiento teórico, como para aplicar nuestros cambios y que estos sean procesados de manera adecuada.

Para esto último, muchas veces nos bastará con analizar y usar la lógica, aunque otras veces tendremos que recurrir a técnicas más sofisticadas, como la ensamblación.

TÉCNICAS DE INVESTIGACIÓN

Existen miles de posibilidades para abordar un problema de investigación, pero muchas veces recurriremos a ciertas técnicas o estrategias muy comunes y útiles para, como mínimo, encontrar algo con lo que empezar a investigar.

  • Reemplazo masivo

El reemplazo masivo es una técnica muy inmediata, si bien es difícil y tediosa de aplicar, por el grave daño que sufre la ROM (daño que muchas veces es catastrófico). Consiste en abrir la ROM, o un archivo de esta, con un editor hexadecimal, y a continuación reemplazar una secuencia de bytes por otra en todas las instancias que se encuentren. La secuencia de bytes original debe tener alguna relación con aquello que queramos investigar (por ejemplo, en muchas investigaciones en ROMs de 4ª Generación, el valor 493 es clave y se reemplaza por otro valor más pequeño).
Una vez hecho el reemplazo, se evalúan los cambios producidos en la ROM, y pueden ocurrir tres cosas:

  • La ROM crashea antes de poder evaluar nuestro objetivo. Hemos modificado un valor crítico en la ROM, cuyo valor original es necesario para que la ROM pueda funcionar. Esto implica tener que restaurar una versión anterior de la ROM y realizar reemplazos nuevamente, pero esta vez, selectivos (ir reemplazando valores en grupos de 5 en 5, 20 en 20, 100 en 100…). Conviene realizar estos “grupos de reemplazo” de mayor a menor, para ir reduciendo la probabilidad de que el valor objetivo caiga en el mismo grupo que el valor crítico.
  • Nuestro objetivo de estudio cambia. Si la ROM no ha crasheado y hemos observado el cambio deseado al reemplazar todas las secuencias, debemos realizar reemplazos selectivos para hallar el valor preciso de entre todos los que han sido reemplazados. Al igual que en el caso anterior, los grupos de reemplazo deben ir de más grandes a más pequeños (si usamos grupos pequeños desde un principio, podemos tirarnos mucho tiempo buscando el valor).
  • No se observan cambios a simple vista. Si no se han efectuado cambios en nuestro objetivo, debemos buscar otra secuencia de bytes a reemplazar que pueda funcionar. También es posible que el valor que busquemos no esté a simple vista en la ROM, sino que se cargue de forma indirecta, lo que hace inútil este procedimiento.



  • Búsqueda de bytes

Cuando la “pista” tras la que vamos es una secuencia de bytes lo suficientemente compleja (más de 4 bytes, por lo general), podemos prescindir de los reemplazos y asumir que lo que hemos encontrado es lo que buscamos, siempre que hayamos encontrado una única instancia. Normalmente, la secuencia que buscamos es la concatenación de dos o más valores distintos pero relacionados (por ejemplo, el valor de una coordenada X seguida del valor de una coordenada Y del mismo elemento), lo que hace suficientemente “rara” la secuencia como para haber encontrado algo al azar.



En esta imagen está resaltada la información correspondiente al cabezal de EVERYWHERE. Basta con buscar 8B 00 8F 01 03 00 (secuencia originada por la unión del número de script, de script de nivel y de texto en el cabezal, tal como se muestra en el SDSME) para hallarla en el arm9 o en la RAM.

Aun así, es recomendable aplicar un reemplazo a lo que encontremos, para no dar por sabido nada y comprobarlo bien.​



  • Nombres de los NARCs y de los archivos

Tanto en las ROMs de Diamante y Perla como en las ROMs de Platino, los directorios y los archivos tienen nombres descriptivos que dan una idea de qué pueden contener. Estos nombres casi nunca están en inglés, y mucho menos en español, pero nos permiten relacionar archivos con otros, con el mismo nombre, cuya función ya conocemos.

Por ejemplo, los archivos de la PokéDex contienen los nombres “application” o “zukan” en la mayoría de los casos, mientras que los sufijos –gra (en pokegra.narc o trainergra.narc) indican contenedores de recursos gráficos.
Muchas veces, el nombre de los archivos también puede indicar si existe algún tipo de compresión (nombres que terminan en .l, .lz o ._) o si estas extensiones van detrás de otra extensión más común.​



  • Proximidad numérica

En las ROMs de HeartGold y SoulSilver, sin embargo, los NARCs no tienen nombres descriptivos en la inmensa mayoría de las veces, sino que están numerados. Sin embargo, los archivos con alguna relación suelen tener números correlativos. Si, por ejemplo, el archivo a/0/0/4.narc contiene los sprites de los Pokémon, el archivo a/0/0/5.narc contiene las coordenadas verticales de esos sprites, el archivo a/0/0/6.narc pertenece a los sprites de entrenadores, y a/0/0/7.narc contiene los fondos de batalla: todos ellos están ligeramente relacionados.

La estrategia de esta técnica radica en predecir la función de los NARCs que aún no tienen una función asignada.​



  • Corrupción de datos

Es una técnica similar al reemplazo masivo, solo que no vamos detrás de una secuencia, sino de una región más o menos delimitada de código. Está técnica desemboca siempre en un crasheo del juego al evaluar nuestro objetivo. Además de código, se puede aplicar a recursos gráficos o de texto, en los que la corrupción puede llegar a ser más evidente, al no haber necesariamente un crasheo de la ROM.


Al igual que el reemplazo masivo, porciones más grandes de datos a corromper permiten identificar con mayor rapidez la zona aproximada que buscamos, mientras que valores más pequeños permiten discriminar con mayor precisión, hasta que podamos separar individualmente lo que nos interesa de lo que no.​



  • Desactivación de NARCs

De una forma análoga pero más precisa que en la corrupción de datos, podemos “desactivar” (es decir, hacer blanquear) la lectura de los NARCs desde la RAM. Alrededor de la dirección de memoria 0x020FED00 en Platino, y de 0x0210E500 en Oro HeartGold y Plata SoulSilver, se encuentra el listado de NARCs que el arm9 es capaz de cargar.



Si en esa región de memoria eliminamos el nombre de un NARC (siempre reemplazando por ceros, nunca cortando la secuencia) el juego será incapaz de leer ese NARC, y crasheará justo cuando lo vaya a cargar. De esa forma, podemos saber el momento preciso en el que el juego recurre a ciertos archivos. Podemos utilizar técnicas de desactivación masiva de NARCs (borrar muchas entradas de NARCs a la vez) y reducir poco a poco los candidatos, como llevamos explicando en las demás técnicas. Cada vez que la ROM crashea, hay que reiniciar el juego y volver a borrar las entradas de los NARCs.​



  • Tracing

Es una técnica muy compleja que involucra la desensamblación. Es útil no para encontrar datos, sino para saber cómo estos se procesan en el juego.

A grandes rasgos, el tracing consiste en localizar en la memoria RAM aquellos datos que queremos investigar, y analizar las lecturas y escrituras que la CPU realiza en ese offset. Esta técnica la ofrecen muchos desensambladores, como IDA Pro (dentro de la ventana de los breakpoints), si bien la dificultad radica más en saber cómo interpretar el código ASM que en realizar la técnica en sí.​



  • Intuición y sentido común

Muchas veces, basta con analizar detenidamente las características de un archivo para intuir qué función tiene. Cuando buscamos en un único archivo binario concreto, es evidente que el archivo debe tener tamaño múltiplo del número de elementos que buscamos (por ejemplo, un archivo binario que asigna el orden de la Pokédex debe tener un tamaño múltiplo de 493 o 494). Así mismo, el formato (gráfico, binario, texto…) de un archivo que queramos investigar tiene que corresponderse a lo que buscamos: no vamos a encontrar modelos 3D en un archivo SDAT.

Además de la extensión que presentan los archivos, la firma del archivo (es decir, los 4 o 5 primeros bytes del archivo) son un vestigio muy importante de su formato y nos puede ayudar en casos en los que el nombre no posea información alguna.​



  • Búsqueda por Internet

Aunque está listado como el último método, cualquier persona con criterio lo primero que hará será buscar por Internet (concretamente en comunidades como WaH, Project o PokeCo) una posible solución a su problema, o bien encontrar diferentes investigaciones similares ya realizadas para tener una idea de cómo puede resolverse el problema.

Ninguna persona es capaz de cargar por sí solo con todo el peso de una plataforma o de una ROM, y siempre vamos a tener que apreciar la ayuda que nos han dado nuestros predecesores en el ROM Hacking.​



DOCUMENTAR EL PROGRESO Y LOS RESULTADOS

Aunque parezca una tontería, es fundamental dejar constancia de todo lo que vayamos descubriendo. No sólo para otros usuarios que quieran conocer los resultados de la investigación (porque muchas veces nuestras investigaciones no se hacen públicas), sino para que nosotros mismos recordemos qué hemos hecho. Esta documentación personal tiene un doble objetivo:

  1. Recordar cómo hemos abordado la investigación, por si en un futuro tenemos que replantear lo que hemos hecho. Muchas veces, podemos descubrir a posteriori que nuestra investigación no era del todo cierta o precisa, y tener una memoria escrita sobre qué hemos hecho será de gran ayuda para reiniciar la investigación.
  2. Tener un modelo de investigación para que, cuando haya que abordar un problema similar, saber por dónde empezar o qué tipo de estrategias pueden funcionar en unos casos u otros.


Y dicho esto, mil gracias a BagBoy por postear este thread en mi ausencia.
 
Última edición:
Estado
Cerrado para nuevas respuestas.
Arriba