Hola
@Lewtial,
En general, para hackear y traducir un juego, es necesario entender (al menos en parte!) cómo está programado. De lo contrario, estarás limitado a lo que puedas ver "a simple vista" (en este caso, con un editor hexadecimal) y siempre respetando los límites originales, ya que de lo contrario no podrás predecir cómo reaccionará el juego al sobrepasarlos.
En el caso de estos textos, puedes ver dónde empieza cada entrada, y puedes observar que siempre terminan en 0x00. Si incrementas a ciegas la cantidad de caracteres de una entrada, descolocarás los inicios de todas las entradas siguientes! Además, en un fichero empaquetado, descolocarás las direcciones de memoria de los sucesivos.
Nunca he jugado a Black Rock Shooter, pero afortunadamente tus imágenes son suficiente para ver que es precisamente esto lo que está sucediendo. Fíjate en los datos, puedes ver:
- 4 bytes -> Identificador del tipo de fichero. "LPK", quizás signifique algo así como "Log Package"?.
- 8 bytes -> Número de ficheros empaquetatos. 0x0C (12) "subficheros".
- Array de 32 bits: Offsets de los ficheros empaquetados. En este caso, y como acabamos de ver, hay 12 (0x0C). El primero está localizado en 0x70. Si vas a dicha dirección de memoria, verás que efectivamente se trata del comienzo de un fichero "XTC".
- Array de 32 bits: Tamaños de los ficheros empaquetados. Aunque no es parte de tu imagen, esto me hace saber que el primer fichero empaquetado tiene 0xC0 bytes de tamaño.
Esta información es suficiente para programar una herramienta que desempaquete (y reempaquete!) ficheros LPK como éste. Esto es necesario ya que de incremementar el tamaño de uno (por ejemplo, añadiendo más texto al primero, como has hecho), se descolocarán los datos en memoria de todos los ficheros empaquetados siguientes y el juego fallará al intentar cargarlos. Para que el juego siguiera funcionando, habría que actualizar los offsets y tamaños del paquete, manteniéndolo así en un estado consistente con su estructura en memoria.
Sin embargo, esta consistenta es necesaria también a nivel de "subfichero". Si te fijas en los datos del primero, puede ver:
- 4 bytes -> Identificador del tipo de fichero. "XTC", quizás signifique algo así como "Text Container"?.
- 4 bytes -> Tamaño del fichero. Como ya vimos a nivel de paquete, son 0xC0 bytes.
- 4 bytes -> Número de entradas de texto. En este caso, 0x0A (10) textos.
- 4 bytes -> Tamaño de cada puntero de texto. En este caso, cada puntero serán 4 bytes (32 bits).
- Array de punteros -> Lista de punteros a textos. En este caso, un array de 32 bits. Aquí puedes ver que el primer texto empieza en el offset 0x38. Ten en cuenta que este offset es relativo al comienzo del fichero empaquetado. Es decir, 0x38 bytes desde la cabecera "XTC". Si haces la suma, verás que efectivamente es donde comienza el primer texto ("View").
- Datos de los textos. Aparentemente siguen un lenguaje de marcas para definir formato.
Al igual que en el caso anterior, teniendo todo esto en cuenta, es posible programar una herramienta que extraiga los los textos (por ejemplo, a TXT), y que los reconvierta a formato "XTC" (una vez traducidos), actualizando los punteros que definen dónde empieza cada entrada, así como el número de entradas y tamaño total de los datos.
Como puedes ver, si bien es posible hacer todo esto manualmente con el editor hexadecimal, sería extremadamente laborioso, muy fácil de hacer mal y muy difícil de detectar cualquier fallo. Es por ello por lo que el RomHacking suele ir de la mano con conocimientos de programación e ingeniería inversa
.
Un saludo,
~Sky
