Romxhacking Romxhacking
- Nasío pa'jakear -
 
 F.A.Q.F.A.Q.   BuscarBuscar   Lista de MiembrosLista de Miembros   Grupos de UsuariosGrupos de Usuarios   RegístreseRegístrese 
 PerfilPerfil   Identifíquese para revisar sus mensajesIdentifíquese para revisar sus mensajes   ConectarseConectarse 


Menú principal
Portal
Foros
F.A.Q.
Buscar
Lista de miembros
Grupos de usuarios
Perfil

Usuario
Nombre de Usuario:

Contraseña:

 Recordarme



He olvidado mi contraseña

¿Aún no tiene su cuenta?
Puede registrarse Aquí, es GRATIS.


Anuncio del administrador
No pretendemos solucionar todos los problemas ni ser referencia de nada, simplemente nos reunimos aquí para charlar de nuestras cosas.
NO SE RESPONDERÁ A NADA POR PRIVADO, QUE EL FORO ESTÁ PARA ALGO

Ayuda para encontrar el cifrado de un conjunto de archivos.
Ir a página 1, 2, 3, 4  Siguiente
 
Publicar Nuevo Tema   Responder al Tema    Romxhacking -> Dudas y Preguntas
Ver tema anterior :: Ver siguiente tema  
Autor Mensaje
salteadorneo



Sexo: Sexo:Hombre
Registrado: 05 Oct 2016
Edad: 42
Mensajes: 43
Estado: Offline
MensajePublicado: Wed Oct 05, 2016 11:55 am    Título del mensaje: Ayuda para encontrar el cifrado de un conjunto de archivos. Responder citando

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.

https://mega.nz/#!Qs5hnLya!UUMrMSYLrPBJWcN2LiKEAS--aetvsEg_tiJ8kQZUmmk

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. Very Happy
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.
Volver arriba
Ver perfil del usuario Enviar mensaje privado  
CUE
Administrador
Administrador



Registrado: 24 Jan 2011
Mensajes: 5377
Estado: Offline
MensajePublicado: Wed Oct 05, 2016 7:27 pm    Título del mensaje: Responder citando

Así a ojo poco se puede hacer. Parece un enmascaramiento porque no hay cambio de tamaño.
Volver arriba
Ver perfil del usuario Enviar mensaje privado  
salteadorneo



Sexo: Sexo:Hombre
Registrado: 05 Oct 2016
Edad: 42
Mensajes: 43
Estado: Offline
MensajePublicado: Wed Oct 05, 2016 8:43 pm    Título del mensaje: Responder citando

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. Very Happy
Volver arriba
Ver perfil del usuario Enviar mensaje privado  
salteadorneo



Sexo: Sexo:Hombre
Registrado: 05 Oct 2016
Edad: 42
Mensajes: 43
Estado: Offline
MensajePublicado: Sun Oct 09, 2016 12:52 pm    Título del mensaje: Responder citando

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.
Volver arriba
Ver perfil del usuario Enviar mensaje privado  
salteadorneo



Sexo: Sexo:Hombre
Registrado: 05 Oct 2016
Edad: 42
Mensajes: 43
Estado: Offline
MensajePublicado: Mon Oct 10, 2016 11:39 pm    Título del mensaje: Responder citando

Bueno. He descifrado el archivo y descubierto más o menos como funciona todo.
Volver arriba
Ver perfil del usuario Enviar mensaje privado  
CUE
Administrador
Administrador



Registrado: 24 Jan 2011
Mensajes: 5377
Estado: Offline
MensajePublicado: Tue Oct 11, 2016 11:30 am    Título del mensaje: Responder citando

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
Volver arriba
Ver perfil del usuario Enviar mensaje privado  
salteadorneo



Sexo: Sexo:Hombre
Registrado: 05 Oct 2016
Edad: 42
Mensajes: 43
Estado: Offline
MensajePublicado: Tue Oct 11, 2016 8:56 pm    Título del mensaje: Responder citando

CUE escribió:
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.


Ultima edición por salteadorneo el Sat Oct 15, 2016 3:13 pm; editado 1 vez
Volver arriba
Ver perfil del usuario Enviar mensaje privado  
CUE
Administrador
Administrador



Registrado: 24 Jan 2011
Mensajes: 5377
Estado: Offline
MensajePublicado: Wed Oct 12, 2016 9:20 am    Título del mensaje: Responder citando

Joer, es de lo más simple. El tamaño ya lo tienes indicado en la cabecera, en 0x0034.
Volver arriba
Ver perfil del usuario Enviar mensaje privado  
salteadorneo



Sexo: Sexo:Hombre
Registrado: 05 Oct 2016
Edad: 42
Mensajes: 43
Estado: Offline
MensajePublicado: Wed Oct 12, 2016 11:12 pm    Título del mensaje: Responder citando

CUE escribió:
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. Rolling Eyes
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.
Volver arriba
Ver perfil del usuario Enviar mensaje privado  
CUE
Administrador
Administrador



Registrado: 24 Jan 2011
Mensajes: 5377
Estado: Offline
MensajePublicado: Thu Oct 13, 2016 10:34 am    Título del mensaje: Responder citando

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 Very Happy
Volver arriba
Ver perfil del usuario Enviar mensaje privado  
salteadorneo



Sexo: Sexo:Hombre
Registrado: 05 Oct 2016
Edad: 42
Mensajes: 43
Estado: Offline
MensajePublicado: Thu Oct 13, 2016 3:25 pm    Título del mensaje: Responder citando

CUE escribió:
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 Very Happy


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.


Ultima edición por salteadorneo el Sun Oct 16, 2016 11:18 am; editado 1 vez
Volver arriba
Ver perfil del usuario Enviar mensaje privado  
salteadorneo



Sexo: Sexo:Hombre
Registrado: 05 Oct 2016
Edad: 42
Mensajes: 43
Estado: Offline
MensajePublicado: Sat Oct 15, 2016 12:36 pm    Título del mensaje: Responder citando

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. Embarassed Una ayudida no vendría mal. Rolling Eyes
Volver arriba
Ver perfil del usuario Enviar mensaje privado  
CUE
Administrador
Administrador



Registrado: 24 Jan 2011
Mensajes: 5377
Estado: Offline
MensajePublicado: Tue Oct 18, 2016 11:17 am    Título del mensaje: Responder citando

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, ...
Volver arriba
Ver perfil del usuario Enviar mensaje privado  
salteadorneo



Sexo: Sexo:Hombre
Registrado: 05 Oct 2016
Edad: 42
Mensajes: 43
Estado: Offline
MensajePublicado: Tue Oct 18, 2016 12:19 pm    Título del mensaje: Responder citando

CUE escribió:
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. Very Happy

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... Very Happy
Volver arriba
Ver perfil del usuario Enviar mensaje privado  
CUE
Administrador
Administrador



Registrado: 24 Jan 2011
Mensajes: 5377
Estado: Offline
MensajePublicado: Tue Oct 18, 2016 1:16 pm    Título del mensaje: Responder citando

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 Smile

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:
a2 = ??? <--- valor inicial para el XOR, que es lo que falta

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

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.
Volver arriba
Ver perfil del usuario Enviar mensaje privado  
Mostrar mensajes anteriores:   
Publicar Nuevo Tema   Responder al Tema    Romxhacking -> Dudas y Preguntas Todas las horas están en GMT + 1 Hora
Ir a página 1, 2, 3, 4  Siguiente
Página 1 de 4

 
Saltar a:  
No puede crear mensajes
No puede responder temas
No puede editar sus mensajes
No puede borrar sus mensajes
No puede votar en encuestas

Temas Relacionados
 Temas   Respuestas   Autor   Lecturas   Último Mensaje 
No hay mensajes nuevos El winamp lo cierran, pero hay otros... 14 gadesx 3680 Sat Aug 12, 2017 9:53 am
mariocanales Ver último mensaje
No hay mensajes nuevos Hay por ahí alguna traducción de XBOX 1? 10 Davoker 3211 Mon Dec 09, 2013 7:04 pm
Davoker Ver último mensaje
No hay mensajes nuevos Las herramientas estas que sirven para todo... xd 1 gadesx 1123 Mon Oct 29, 2012 8:41 am
CUE Ver último mensaje
No hay mensajes nuevos Imagenes que no son TIM y no aparecen en los juegos 1 gadesx 1193 Tue Mar 20, 2012 4:47 pm
CUE Ver último mensaje
No hay mensajes nuevos Monolith Soft, hay que seguir a esta gente 6 gadesx 4265 Fri Oct 14, 2011 7:07 pm
Gryphus-X Ver último mensaje
 


Crear foro gratis - Powered by phpBB © 2001, 2005 phpBB Group
subRebel style by ktauber