Autor Tema: CPU Kabuki  (Leído 28779 veces)

0 Usuarios y 1 Visitante están viendo este tema.

Marcos75

  • Socio
  • ****
  • Mensajes: 3046
  • Arcadero de los 80s
Re:CPU Kabuki
« Respuesta #30 en: 14 de Mayo de 2014, a las 15:11 horas »
edcross, estoy releyendo el hilo, y no te había entendido. Planeas grabar tu Hola Mundo en la placa real, para determinar, lo primero, qué se queda en la RAM del Kabuki cuando muere...

¡Buena idea!


ArcadeHacker

  • Con experiencia
  • ***
  • Mensajes: 650
  • .
Re:CPU Kabuki
« Respuesta #31 en: 14 de Mayo de 2014, a las 15:43 horas »
edcross, estoy releyendo el hilo, y no te había entendido. Planeas grabar tu Hola Mundo en la placa real, para determinar, lo primero, qué se queda en la RAM del Kabuki cuando muere...

¡Buena idea!

Correcto!

Paso 1. Encontrar si el Kabuki tiene una posición de descifrado por defecto cuando se borra su memoria interna.
Paso 2. Crear un mapa de opcodes/datos con el que poder hacer una nueva rom. y asi evitar andar con roms dobles y cableados.
Busco placa de Taito: Chack'n Pop.

Andreas Naive

  • Recien llegado
  • Mensajes: 49
Re:CPU Kabuki
« Respuesta #32 en: 14 de Mayo de 2014, a las 16:26 horas »
Paso 1. Encontrar si el Kabuki tiene una posición de descifrado por defecto cuando se borra su memoria interna.

Pues puedes tener suerte y que todo vaya a cero o algo así, pero te advierto que las FD1094 malas que están documentadas en el código de MAME quedaron cada una muertas a su modo (los valores cambian de unas a otras, y cambian de byte en byte en una misma)

ArcadeHacker

  • Con experiencia
  • ***
  • Mensajes: 650
  • .
Re:CPU Kabuki
« Respuesta #33 en: 14 de Mayo de 2014, a las 16:29 horas »
Paso 1. Encontrar si el Kabuki tiene una posición de descifrado por defecto cuando se borra su memoria interna.

Pues puedes tener suerte y que todo vaya a cero o algo así, pero te advierto que las FD1094 malas que están documentadas en el código de MAME quedaron cada una muertas a su modo (los valores cambian de unas a otras, y cambian de byte en byte en una misma)

Interesante. Las FD1094 mueren por completo cuando pierden su memoria interna? Es decir, no son reutilizables como cpu normal como si pasa con los Kabukis?
Busco placa de Taito: Chack'n Pop.

Andreas Naive

  • Recien llegado
  • Mensajes: 49
Re:CPU Kabuki
« Respuesta #34 en: 14 de Mayo de 2014, a las 16:37 horas »
Es difícil de decir; por lo que sabemos, las FD1094 normales tienen ciertos bits fijos a 1; es posible que con alguna combinación de esos bits se pueda hacer que funcione como un 68000 normal pero, desde luego, si esos bits están como están en las FD1094 buenas, no hay ninguna combinación del resto que equivalga a "no cifrar". De hecho, esas 4 CPUs malas ayudaron a entender parcialmente el modo en que actúan esos bits fijos y, por lo que veo, no da la sensación de que actúen de forma muy distinta al resto. Pero podría creerme que alguna combinación de los 4 primeros bytes (que tienen significado especial) habilitase un modo sin cifrado.

EDITADO: Ah, y no "mueren" por perder su memoria interna; simplemente cambia el cifrado al cambiar los datos.
« última modificación: 14 de Mayo de 2014, a las 16:40 horas por Andreas Naive »

Pofo

  • Visitante
Re:CPU Kabuki
« Respuesta #35 en: 14 de Mayo de 2014, a las 16:48 horas »
Como cifraste el hello world, existe algun program, te hiciste tu el algoritmo y lo programaste?

Una pregunta de alguien que no tiene ni idea de ensamblador, como editas una eprom en ensamblador?, perdona si digo una burrada es que estoy leyendo un libro ahora mismo y es por experimentar.

Andreas Naive

  • Recien llegado
  • Mensajes: 49
Re:CPU Kabuki
« Respuesta #36 en: 14 de Mayo de 2014, a las 17:00 horas »
Pues hombre, Pofo, no sé cómo lo habrá hecho edcross, pero lo sencillo en estos casos es invertir las rutinas en un lenguaje de alto nivel (teniéndolo en C/C++, lo inviertes en C/C++) y una vez que lo tienes probado en el PC ya te apañas para utilizar un cross-compilador para generar código máquina en la arquitectura que quieras (o código ensamblador para usar después un ensamblador en un segundo paso). Escribir el código directamente en ensamblador suele ser pesado.

Si quieres tocar directamente el código de una ROM, primero tendrás que usar un desensamblador para entender qué tienes y, una vez hayas decidido tus cambios, ver cómo encajas el código máquina nuevo sin cargarte nada. Esto los de http://romhackhispano.org/ lo hacen mucho para crear parches de traducción respetando en lo posible el código original. Ahora bien, si no tienes interés en respetar el código original, pues simplemente compilas tu programa para el código máquina de la arquitectura destino y lo cargas sin más.

Marcos75

  • Socio
  • ****
  • Mensajes: 3046
  • Arcadero de los 80s
Re:CPU Kabuki
« Respuesta #37 en: 14 de Mayo de 2014, a las 17:10 horas »
EDITADO: Ah, y no "mueren" por perder su memoria interna; simplemente cambia el cifrado al cambiar los datos.

Andreas, no he entendido a qué te refieres con esto. ¿Quieres decir que la RAM interna cambia su contenido, pero sigue estando alimentada por la batería, porque esta sigue con carga?

Pofo, por complementar la respuesta que te ha dado Andreas, para juegos con arquitectura de 8 bits simplemente abre la primera ROM de programa con un editor hexadecimal, copia y pega el contenido en la página que os pasé el otro día (es un desensamblador online) asegurándote de que has seleccionado la plataforma correcta (z80, me imagino). A la izquierda obtendrás el código en lenguaje ensamblador.

Un saludo.

EDITO: Este es el ensamblador online al que me refería. Probablemente sea malo, pero un apaño rápido hace :)

http://onlinedisassembler.com/odaweb/

« última modificación: 14 de Mayo de 2014, a las 17:12 horas por Marcos75 »


ArcadeHacker

  • Con experiencia
  • ***
  • Mensajes: 650
  • .
Re:CPU Kabuki
« Respuesta #38 en: 14 de Mayo de 2014, a las 17:14 horas »
@Andreas, gracias por la info, ya he visto en internet que el FD es una paella de componentes embutidos en epoxy :). El kabuki es solamente un chip que alimentando el pin 28 activas su comportamiento cifrado y con ello tb alimentas los datos de su memoria interna. Tengo muchas ganas de hacer las pruebas.

@Pofo - Cifrado:  El descifrado es conocido y existe driver en mame. A partir de eso busqué la manera de hacer la inversa (cifrar en vez de descifrar) al final no era posible directamente (perdida de información en el proceso) y tuve que tirar de bruteforcing usando tablas (un rollo que no te voy a pegar). 

@Pofo - Editar assembler: Basicamente cada byte significa algo, una instrucción o un dato, pero estos bytes por si solos son poco amigables de entender sin la ayuda de los pseudonimos de lo que significa cada instrucción en byte.

Por ejemplo: C3 10 00

Estos 3 bytes en z80 significa en lenguaje humano:  JUMP $0010
(Indica a la CPU a saltar a la posición de memoria 10 y seguir ejecutando)

Yo generalmente hago mis analisis en Ida Pro (un desensamblador), pero hace poco Rockman nos hizo la sugerencia de mirar Odaweb, un interprete online muy util y que ahora voy usando para cosas rápidas:

http://onlinedisassembler.com/odaweb/

Acuerdate de estudiarte el libro que te recomendé.
« última modificación: 15 de Mayo de 2014, a las 22:20 horas por edcross »
Busco placa de Taito: Chack'n Pop.

Rockman

  • Con experiencia
  • ***
  • Mensajes: 1281
Re:CPU Kabuki
« Respuesta #39 en: 14 de Mayo de 2014, a las 17:17 horas »
Ya os digo que no sigo (no por que no quiera) este interesantísimo hilo sobre el kabuki de edcross.
Pero según el source de Mame dice que si se pierde la memoria RAM interna al "suicidarse" la CPU se convierte como si un Z80 "normal" se tratara.

Tratando todo lo que esta encriptado de las roms con las llaves y dejandolo desencriptado no lo coje como tal ese Z80 (Kabuki KO)?

(supongo que es algo obvio lo que he dicho y no funciona asi de fácil)

EDITO: Edcross, el link lo compartio Marcos, no yo.
RESUMEN: Proyecto de incluir versiones españolas de juegos a Mame (Oficial): http://www.aumap.org/foro/index.php?topic=1270.0

Pofo

  • Visitante
Re:CPU Kabuki
« Respuesta #40 en: 14 de Mayo de 2014, a las 17:18 horas »
Osea, vamos, que edcross pillo el algoritmo, se programo el hello, programo el codificador y se lo paso al hello que al ser sencillo puedes separar facilmente las instrucciones y los datos, no?

Otra pregunta, los programas suelen mirar checksums o similares para evitar que se le meta mano? Es frecuente esto?

El entrelazado, te refieres a andar separando instrucciones y datos para codificarlos distinto? O cambian tambien posiciones dentro de la propia rom.


Andreas Naive

  • Recien llegado
  • Mensajes: 49
Re:CPU Kabuki
« Respuesta #41 en: 14 de Mayo de 2014, a las 17:23 horas »
Marcos, cuando esas CPUs se estudiaron yo no estaba en el proyecto, así que no tengo información de primera mano.

Mira http://mamedev.org/source/src/mame/machine/fd1094.c.html , líneas 281 y siguientes. Esos valores fueron recuperados mediante ingeniería inversa de los resultados devueltos por el circuito. Dicho de otra manera: se sabe que esos son los valores porque eso es lo que se dedujo de los resultados producidos por cada una de esas cuatro FD1094. Una de ellas, por los comentarios, directamente no tenía batería (y esa sí tenía los cuatro bytes iguales); de las otras no sé nada; puede que el contenido original se perdiera al estar a punto de morir la batería, o en un cambio de batería, vete tú a saber. Pero las cuatro eran funcionales, y a partir de los resultados se dedujeron esos valores.

Marcos75

  • Socio
  • ****
  • Mensajes: 3046
  • Arcadero de los 80s
Re:CPU Kabuki
« Respuesta #42 en: 14 de Mayo de 2014, a las 17:24 horas »
Rockman, para que el Kabuki funcione como un Z80 hay que asegurarse de que determinado pin (el 28 creo) está a masa. Mejor forzarlo en placa.

Básicamente haciendo eso de arriba, y desencriptando el código, la placa revive. El problema es que los códigos de programa y los datos se encriptan (y por tanto se desencriptan) de forma distinta, con lo cual para dejar todo en una única ROM del tamaño original hay que hacerse un mapa de memoria, saber qué es código, que son datos, tratarlos por separado, y luego volverlos a juntar respetando ese mapa de memoria.

La alternativa existente, que usaban los bootlegers, era coger una ROM del doble de tamaño. Desencriptar todo como si fuese opcodes, y meterlo en la parte baja. Desencriptar luego todo como si fueran datos, y meterlo en la parte alta. Y usar la línea más alta de dirección de esa nueva EPROM como selector entre un banco y el otro (opcodes y datos). La CPU genera una señal de control distinta (en el z80 no sé cual es, en el 68K es una combinación de 3 señales), cuando accede a un opcode o a un dato. Usando esa señal de control, gestionamos esa línea alta.

Es un truco para evitarse hacer el mapa de memoria.

Pofo, has clavado lo que has dicho.

Un saludo.

EDITO: Andreas, acabo de ver tu mensaje. Gracias por la información.


Marcos75

  • Socio
  • ****
  • Mensajes: 3046
  • Arcadero de los 80s
Re:CPU Kabuki
« Respuesta #43 en: 14 de Mayo de 2014, a las 17:30 horas »
Otra pregunta, los programas suelen mirar checksums o similares para evitar que se le meta mano? Es frecuente esto?

Hola Pofo.

Yo lo he visto en los Sega System 16. Wonder Boy III antes de arrancar comprueba el contenido de unas posiciones concretas de memoria. Si has desencriptado la ROM, como has variado esas posiciones de memoria, el juego entra en un bucle infinito. Hay que parchear el código sí os sí. A MAME no le pasa porque no utiliza una versión desencriptada, sino que desencripta "al vuelo". En el Passing Shot creo que pasa algo similar, pero no recuerdo exactamente cómo era.

Un saludo.


Rockman

  • Con experiencia
  • ***
  • Mensajes: 1281
Re:CPU Kabuki
« Respuesta #44 en: 14 de Mayo de 2014, a las 17:32 horas »
Rockman, para que el Kabuki funcione como un Z80 hay que asegurarse de que determinado pin (el 28 creo) está a masa. Mejor forzarlo en placa.

Básicamente haciendo eso de arriba, y desencriptando el código, la placa revive. El problema es que los códigos de programa y los datos se encriptan (y por tanto se desencriptan) de forma distinta, con lo cual para dejar todo en una única ROM del tamaño original hay que hacerse un mapa de memoria, saber qué es código, que son datos, tratarlos por separado, y luego volverlos a juntar respetando ese mapa de memoria.

La alternativa existente, que usaban los bootlegers, era coger una ROM del doble de tamaño. Desencriptar todo como si fuese opcodes, y meterlo en la parte baja. Desencriptar luego todo como si fueran datos, y meterlo en la parte alta. Y usar la línea más alta de dirección de esa nueva EPROM como selector entre un banco y el otro (opcodes y datos). La CPU genera una señal de control distinta (en el z80 no sé cual es, en el 68K es una combinación de 3 señales), cuando accede a un opcode o a un dato. Usando esa señal de control, gestionamos esa línea alta.

Es un truco para evitarse hacer el mapa de memoria.

Un saludo.

EDITO: Andreas, acabo de ver tu mensaje. Gracias por la información.

Ahora entiendo el motivo del hilo de edcross xD (ahora falta que sepa como lo hace. Poco a poco). Muchas gracias Marcos!.
RESUMEN: Proyecto de incluir versiones españolas de juegos a Mame (Oficial): http://www.aumap.org/foro/index.php?topic=1270.0