Ayuda para encontrar el cifrado de un conjunto de archivos.

[silenthill]

Este es el último paso que queda para completar un trabajo de traducción para la PSP. El resto, gráficos, escenario, animaciones, vídeos y menús... está traducido reinsertado y funcionando. Faltan unos detalles, correcciones y beta, pero más o menos todo bajo control. Resulta que a parte del texto del escenario hay más texto oculto dentro de unos archivos. Tengo una versión descifrada de uno de ellos o luego está la cifrada. El archivo cuyo nombre acaba en "original" es el cifrado el que no pone nada es el que está descifrado.

La pega es que no dispongo de la versión descifrada de todos los archivos de este tipo y claro hay que descifrarlos para completar la traducción.

Al tema.
Si miramos los archivos con un editor HEX tenemos que la parte cifrada empieza en 0x0040 y va hasta 0x05ef. Justo lo que viene después del POF0 vuelve a estar sin cifrar. En 0x002e hay un byte que cambia de la versión cifrada a la descifrada. Supongo que ese byte indica al motor del juego si el texto está descifrado o cifrado.
A partir del 0x04a0 empieza el texto en sí. Lo primero que encontramos son rutas de archivos que terminan en 0x0565. A partir de 0x0566 está el texto que sale en el juego y que llega hasta 0x05ef (en japones SJIS en el archivo original).

Muchas gracias de antemano.

[CUE]

Así a ojo poco se puede hacer. Parece un enmascaramiento porque no hay cambio de tamaño.

[silenthill]

Efectivamente, en ningún archivo cambia el tamaño, ni siquiera en los traducidos. ¿Alguna idea para averiguar qué enmascamamiento es? Es el último ladrillo que le falta al edificio.

[silenthill]

Trasteando con un volcado de memoria he localizado la parte del archivo ya descifrada. Coincide en tamaño con el archivo enmascarado. El problema es que a la hora de insertarlo ya desemascarado (por si sonaba la flauta), juego le vuelve a aplicar el desemascaramiento dando como resultado un cuelgue. En alguna parte está el patter o algún bit que le indica al juego que el archivo ya está desemascarado. Con los que ya tengo traducidos traga tal cual. Estoy comparado ambaos archivos y hay difencias entre ambos archivos. Vamso que por eso no traga.

[silenthill]

Bueno. He descifrado el archivo y descubierto más o menos como funciona todo.

[CUE]

Pues explica, yo estaba mirando poco a poco pero no veía nada. A simple vista parecía sumar un valor con otro correlativo, pero luego no se cumplía, así que debe ser una casualidad, y como no tenía más ficheros para ver el inicio, poco más se puede ver:
- AC + 55 - 00 = 01
- AD + 55 - 01 = 01
- 2D + 55 - 02 = 80

Me llamó la atenció porque el 55, con su complementario, el AA, son 2 valores muy usados en cifrados, consistentes en unos seguidos de ceros, sin que se repita ninguno:
- 55 = 01010101
- AA = 10101010

[silenthill]

Pues explica, yo estaba mirando poco a poco pero no veía nada. A simple vista parecía sumar un valor con otro correlativo, pero luego no se cumplía, así que debe ser una casualidad, y como no tenía más ficheros para ver el inicio, poco más se puede ver:
- AC + 55 - 00 = 01
- AD + 55 - 01 = 01
- 2D + 55 - 02 = 80

Me llamó la atenció porque el 55, con su complementario, el AA, son 2 valores muy usados en cifrados, consistentes en unos seguidos de ceros, sin que se repita ninguno:
- 55 = 01010101
- AA = 10101010

Explico, Xor con el valor anterior menos con el primero que hace xor con el siguiente. Lo que confirma, en parte, mis sospechas iniciales.
Vamos que cogen el valor 0x000040 y le aplican un Xor con el valor de 0x000041, luego cogen 0x000041 (con su valor original se entiende) y le aplican un Xor con el valor 0x000040 ahora cogen 0x000042 y hace xor con el valor original de 0x000041 y así hasta completar la cadena. El tema ahora es saber dónde está el valor del contador, el tamaño de la cadena, supongo que almacenado en uno de los EOF (end of file) del final. Y la otra cosa es como hacen para que no se ejecute el bucle si el archivo está descifrado.
Mirando al rutina antes de la entrada hay un beq que compara dos registros y si coinciden devuelve la rutina a donde fue invocada sin entrar en el bucle. Pero esos valores (que no son más que el tamaño de la cadena a desemascarar) deberían ser distintos en los dos archivos que subí antes (el original y el traducido) y no lo són, el traducido no entra en el bucle mientras que el original sí lo hace. Vamos que la única diferencia es el 08, 0c de 0x00002e. En el peor de los casos tocará volver a enmascarar el archivo.
El valor inical para el registro del contador es 09913AC2 cuando alcanza 09914040 sale del bucle.

[CUE]

Joer, es de lo más simple. El tamaño ya lo tienes indicado en la cabecera, en 0x0034.

[silenthill]

Joer, es de lo más simple. El tamaño ya lo tienes indicado en la cabecera, en 0x0034.

Cierto Little Endian, poniendo las cosas del revés... Como los odio. Acostumbrado al Big.
Muchas gracias. También muchas gracias por el UMD-Replace. Una pena que sólo cambie un archivo por vez, pero para lo que estoy haciendo es todo un lujo disponer de una herramienta como esta. Con un simple script reinserto todas la veces que lo necesito sin mucho engorro.

[CUE]

Es que el UMD-Replace está basado en la versión de PC, que está basada en la versión de PSX, que solo la hice para comprobar que se puede mantener la posición de los ficheros aumentando o disminuyendo el tamaña de uno, sin cambiar el orden en que están grabados. Siempre he tenido ganas de seguir con ello para poder meter varios ficheros de golpe, pero ni he tenido tiempo ni ganas, que si cambio una de esas utilidades tendría que ponerme con las otras, y eso ya no me convence tanto

[silenthill]

Es que el UMD-Replace está basado en la versión de PC, que está basada en la versión de PSX, que solo la hice para comprobar que se puede mantener la posición de los ficheros aumentando o disminuyendo el tamaña de uno, sin cambiar el orden en que están grabados. Siempre he tenido ganas de seguir con ello para poder meter varios ficheros de golpe, pero ni he tenido tiempo ni ganas, que si cambio una de esas utilidades tendría que ponerme con las otras, y eso ya no me convence tanto

Para lo que estoy haciendo ahora sólo necesito reinsertar un cpk por vez. Así que script para crear el cpk y luego, en el mismo script llamo al umd-replace y reinserto el cpk. Para otro proyecto, si que vendría de lujo reinsertar varios.

[silenthill]

Ahora sólo necesito desompolvar mis viejos conocimientos de programación y hacer una pequeña aplicación para descifrar esos archivos... De verdad que estoy muy oxidado. Una ayudida no vendría mal.

[CUE]

Pero es que faltan más datos. No se sabe si todos los ficheros tienen la misma estructura, se desconoce si el primer XOR se hace siempre con el mismo valor, ...

[silenthill]

Pero es que faltan más datos. No se sabe si todos los ficheros tienen la misma estructura, se desconoce si el primer XOR se hace siempre con el mismo valor, ...

Hay básicamente dos archivos de este tipo. El de las misiones y el que contiene objetos y otros.
El de las misiones son todos iguales. Tienen la misma estructura. El de los objetos tengo que mirarlo más a fondo.
El archivo de misiones siempre es igual, cabecera MXE... Segunda cabecera MXE y a partir del 0x000040 es donde está la parte codificada con los XOR hasta que llega al final que es justo antes del POF. Vamos lo que sería el tamaño marcado en 0x000034.
El algoritmo de decodificación es el siguiente (en ensamblador del MIPS):

beq a0,a1,0x08BA920C
andi a2,a2,0xFF
lbu a3,0x0(a0)
xor a2,a3,a2
sb a2,0x0(a0)
addiu a0,a0,0x1
bne a0,a1,0x08BA91F4
move a2,a3
jr ra
nop

El registro A2 entra con el valor de 0x000041 en el bucle. Se carga con ese valor en una porción de código que está antes de ser invocada esta rutina.
beq compara valores, si son iguales sale del bucle sin ejecutarlo.
andi a2,a2,0xff rellena con ceros el tamaño del registro para ocupar los 32bits.
lbu a3,0xc(a0) carga el registro a3 con el valor que está en la dirección de memoria a la que apunta el registro a0. En el momento de entrar en el bucle estaría en la posición 0x000040 del archivo ejemplo. (La posición de memoria de la consola sería otra, claro).
xor a2,a3,a2 Esto está claro hacer el Xor y guarda el resultado en el registro a2.
sb a2,0x0(a0) guarda el contenido del registro a2 (en este momento guarda el valor del xor) en la posición de memoria a la que apunta a0, sobreescribiendo el valor original.
addiu a0,a0,0x1 incrementa en uno el valor del registro a0, que hace las veces de contador y de apuntador, y apunta a la siguiente posición de memoria.
bne a0,a1,0x08BA91F4 compara el valor de los registros a0 y a1. Si son iguales es que se ha alcanzado el final de la cadena y se sale del bucle (siguiría con jr ra) . Si son distintos se ejecuta un nuevo ciclo del bucle que se inciaría en lbu a3,0x0(a0).
Pero antes del salto a lbu se ejecuta:
move a2,a3 que guarda el valor de a3 (registro que contiene el valor de 0x000040 al inicio) en el registro a2. Y de este modo hace lo que explicaba más arriba:
Cogen el valor 0x000040 y le aplican un Xor con el valor de 0x000041, luego cogen 0x000041 (con su valor original se entiende) y le aplican un Xor con el valor 0x000040 ahora cogen 0x000042 y hace xor con el valor original de 0x000041 y así hasta completar la cadena. Todo esto ya que en la cadena se entra con el valor de 0x000041 en el registro a2.

Y ahora si que se salta al lbu. Iniciando un bucle más.
Para codificar es lo mismo pero al revés. Empezando por el final con el valor e8 para el registro a2. Cuando se llega al final se hace un xor con 0x000041 cogiendo el valor de 0x000040 al que ya ha sido aplicado el xor. Vamos en el caso del ejemplo 0x000041 vale 01 antes de ser aplicado el xor y 0x000040 vale cd pues 01 xor cd = cc que es el valor original de 0x000041 antes de ser descifrado.

Acabo de mirar el resto de archivos de este tipo y son iguales. Todos tienen la misma estructura. En caso de necesitar más tengo muchos...

[CUE]

Entiendo que la cabecera es siempre igual, comenzando el rollo en 0x40. Aunque no es correcto, veo varias, la "MXEN", que debe ser la cabecera principal, la "MXEC", donde está todo el rollo, pero parece que su longitud siempre está en el tercer valor de 32 bits, 0x20 bytes cada una, así que no habría problema en buscar dónde comienza todo el asunto. Tú puedes saber que siempre empieza en 0x40, pero los demás, con un único fichero, lo tenemos claro

Lo del XOR inicial no me cuadra. Para desencriptar el fichero posteado sería:
- 0x40 -> AC xor ??? = 01
- 0x41 -> AD xor AC = 01
- 0x42 -> 2D xor AD = 80
- 0x43 -> 2D xor 2D = 00
- 0x44 -> 4D xor 2D = 60

El proceso no es como tú lo indicas, que haces "trampa" para calcular el primer valor. Es, usando el código que has posteado pasado a C:

Código: Seleccionar todo

a2 = ??? <--- valor inicial para el XOR, que es lo que falta

a2 &= 0xFF <--- solo nos interesa el byte inferior
for &#40; ; a0 < a1; a0++&#41; a0 es la posición actual de los datos, a1 es la final
  a3 = tabla&#91;a0&#93; <--- en estas 3 líneas se ve que siempre se calcula haciendo un XOR con el valor almacenado y el siguiente
  a2 ^= a3
  tabla&#91;a0&#93; = a2
  a2 = a3 <--- toma el byte original codificado como valor para el siguiente XOR
&#125;

El primer valor, para que resulte 01, tenemos que hacerle un XOR con AD, ¿pero de dónde viene ese valor? No es el valor del segundo byte, pues ese se emplearía en el cáculo del tercer valor, aunque en este caso coincide.