CPU Kabuki

[ArcadeHacker]

Buenas,

Hoy he mirando una Pang original que compré hace un tiempo sabiendo que no funcionaba. La placa está claramente suicidada, tiene el nivel de batería a 0.8v. 

Este sistema usa una cpu variante del z80 llamada Kabuki, y por lo que he visto tiene una ram interna con los datos necesarios para desencriptar el código de las roms. Al caer el nivel de batería por debajo de un umbral determinado los datos de la ram interna se pierden y con ello el juego deja de funcionar.



He visto aquí una solución para revivirla que no parece nada complicada, trata de modificar la placa para que el Kabuki se comporte como un z80 normal, tocar varios jumpers y un par de roms nuevas con codigo desprotegido.

http://www.arcadecollecting.com/dead/pre-cps.html

Lo que más me ha llamado la atención es la falta de información que existe sobre la CPU, su funcionamiento, pinout, o si es posible volver a cargarle los datos necesarios para desencriptar el codigo de las roms...

El cifrado que se usa es conocido, entiendo que se ha sacado por medio de bruteforcing al codigo de las roms, y las rutinas para descifrar los datos las incorpora un driver del mame. Ojo, este driver no emula la cpu, simplemente desencripta el codigo rom y luego usan un driver de z80 normal para ejecutarlo.

http://mamedev.org/source/src/mame/machine/kabuki.c.html

Alguien sabe algo más sobre la CPU Kabuki o donde encontrar información? Me gustaría poder revivir esta placa dejandola como estaba sin tener que recurrir a desuicidarla.

Un saludo.

[Marcos75]

Hola edcross. No voy a resolver tu duda, porque no conozco a fondo (EDITO: no la conozco, a secas ) esta CPU. Pero como el sistema de encriptación sea similar al del FD1094 de las System 16, eso que comentas es imposible.

En ese sistema FD1094 la llave de encriptación está en una RAM interna alimentada por la batería. A los pads de la batería tienes acceso, pero no así a la RAM (no puedes "enchufarle" de nuevo los datos que se han borrado, no hay forma "física" de hacerlo.

Como bien dices, revivir ese Pang te resultará muy sencillo. Yo lo he hecho ya en varias ocasiones con Pang y Super Pang.

Un saludo.

EDITO: Igual que he visto bastantes Segas system 16 que han llegado a nuestros días vivas, no he visto NINGÚN Pang o Super Pang que no haya muerto suicidado.

[ArcadeHacker]

Pregunta inocente: Pero en algún momento alguien o algo ha de cargar en la ram la información necesaria? Esto no se puede volver a hacer? En el de Sega que ocurre? Hay un fusible de seguridad?

Y aunque haya un fusible o similar, cuando la ram se ha borrado, que ocurre con los bytes? Se van a 00? a FF??

En ese caso, no sería posible modificar las rom desencriptadas para encryptarlas con un cifrado que funcione con esos datos de la ram a cero?

[Marcos75]

Bueno, no quiero hablar mucho del tema porque realmente lo desconozco. Pero entiendo que durante el proceso de fabricación es relativamente sencillo cargar la RAM. Reproducir eso a nivel "amateur" dudo que sea posible. En SEGA no hay fusible de seguridad ni nada por el estilo. Simplemente la RAM es un trocito de silicio minúsculo únicamente con conexiones internas.

Cuando una RAM se borra no sé si va a 00 ó a FF. Puede incluso que dependa de la tecnología. En cualquier caso, no estoy seguro de que sea posible hacer lo que dices. Además, no sé si podemos estar 100% seguros de a qué valores va a quedar la RAM. En este caso, puestos a modificar el juego, creo que es preferible desencriptar y poner un 68K normal que reencriptar.

Además en el caso del Pang incluso puedes reutilizar el Kabuki...

Cuando desencriptas las ROMs de Sega System 16 lo haces de manera más limpia que en el caso de los Pangs: En el Pang tú grabas en una misma ROM dos versiones del código, la encriptada y la desencriptada. El motivo es que el procesador espera que las instrucciones estén encriptadas, y el área de datos esté desencriptada. De esa forma cuando la CPU va a buscar un dato, fuerzas a que lo haga en la parte alta de la ROM, y cuando va a buscar una instrucción, fuerzas a que lo haga en la parte baja.

Eso funciona bien, pero es más elegante entrelazar en una única ROM, del tamaño de la ROM original, el código y los datos. Eso, evidentemente, lleva muchísimo más trabajo.

Entiendo que si en el Pang nadie lo ha hecho es porque será imposible. En Sega System 16 se puede hacer más o menos de forma sencilla.

Un saludo.

[Pofo]

En el pang yo nuncs lo vi marcos, en las system16 como sabes es ir mirando donde estan los datos y donde las instrucciones e ir entrelazando, creo aue tu te curraste un programin para "semi automatizarlo".

Lo de meter una eprom doblads de tamaño y hacerle la ñapa es poco elegante, la verdad es que repele, pero funciona.

[ArcadeHacker]

Gracias de nuevo Marcos.  Investigare un poco mas este tema.

[ArcadeHacker]

Bueno.... conociéndome y como era de esperar, el "investigaré un poco más el tema" se ha convertido en "misión a muerte".

Avances:

A partir del código de descifrado del mame he construido un programa para encriptar código compatible con el cifrado del Kabuki.

Tambien he programado un "Hello World" que funciona en la plataforma del pang y he conseguido satisfactoriamente correrlo en el Mame cifrandolo con las llaves originales.

Siguientes pasos:

Rezar a que me llegue el borrador de eproms desde china -pronto-.
Crear multiples versiones cifradas del Hello World para comprobar mi teoría de lo que le pasa al Kabuki al perder la batería. (las llaves de cifrado se van a cadenas formadas por bytes 00 o FF o algo similar).

Si esto sale bien todos tendremos un Pang rescatable sin modificar hardware. Más noticias en 1 o 2 semanas.

[ricky2001]

Impresionante edcross, me quito el sombrero, ojalá lo consigas.

Saludos

[Pofo]

Jo*** macho, eres la caña.

Pon un tuto de como lo has conseguido para dummies si no te importa.

[ArcadeHacker]

Prometo ir a fondo con los detalles me de o no con el muro. A las malas intentaré mejorar lo que hay hoy con el tema de tener que grabar eproms de doble tamaño, pudiendo usar las que lleva de fabrica.

[Marcos75]

Hola edcross.

Buen trabajo, la cosa marcha. Una cosa, ¿no podrías emular todo en MAME, sin necesidad de recurrir a la placa físicamente? Por ejemplo, cuando me lie con la encriptación de Sega System 16 me compilé una versión de MAME anulando la rutina de desencriptación, así podía probar las EPROMs desencriptadas. ¿No podrías hacer tú algo parecido, tocando el fuente de MAME, para que la llave de encriptación sea 00 00 00 ... 00 ó FF FF FF ... FF, o lo que sea? Así te ahorraras mucho jaleo borrando EPROMs y demás (ahora entiendo tu otro post ).

Un saludo.

[ArcadeHacker]

Hola edcross.

Buen trabajo, la cosa marcha. Una cosa, ¿no podrías emular todo en MAME, sin necesidad de recurrir a la placa físicamente? Por ejemplo, cuando me lie con la encriptación de Sega System 16 me compilé una versión de MAME anulando la rutina de desencriptación, así podía probar las EPROMs desencriptadas. ¿No podrías hacer tú algo parecido, tocando el fuente de MAME, para que la llave de encriptación sea 00 00 00 ... 00 ó FF FF FF ... FF, o lo que sea? Así te ahorraras mucho jaleo borrando EPROMs y demás (ahora entiendo tu otro post ).

Un saludo.

Buenas Marcos, eso es justamente lo que he hecho con el Hello World, ya puedo descifrar y cifrar con cualquier juego de llaves que yo quiera. El siguiente paso ya es el hardware real y la incognita de que hay en la memoría del kabuki cuando pierde la batt.

[Marcos75]

Entonces supongo que para averiguar qué hay en la memoria del Kabuki vas a liarte con prueba y error, y lo harás vía "MAME", ¿no?

Con lo cual, si no te he entendido mal:

- Tu idea es desencriptar el código del juego
- Averiguar la llave que queda en el Kabuki cuando muere
- Reencriptar el código con esa nueva llave.

¿Es así?

Un saludo.

[Pofo]

Edcross, cual es la rutina de cifrado?, es sencillamente una algoritmo que pilla llave y datos o es dinamica?

Si no te importa explicar un poco como lo has echo...

[ArcadeHacker]

Entonces supongo que para averiguar qué hay en la memoria del Kabuki vas a liarte con prueba y error, y lo harás vía "MAME", ¿no?

Con lo cual, si no te he entendido mal:

- Tu idea es desencriptar el código del juego
- Averiguar la llave que queda en el Kabuki cuando muere
- Reencriptar el código con esa nueva llave.

¿Es así?

Un saludo.

Con Mame ya he terminado. Soy capaz de desencriptar codigo con las llaves conocidas, y tambien encriptarlo con cualquier juego llaves que yo defina.

Las pruebas reales con el Kabuki son basicamente como tu dices, prueba y error. Ni idea de lo que tiene dentro o de si hay más elementos afectados en la perdida de batería más allá de las llaves de cifrado (17bytes).

Estas son las claves originales: 0x01234567,0x76543210,0x6548,0x24

Mi plan es cifrar mi codigo de Hello World con varias combinaciones de llaves diferentes: eg: 0000000.. 010101001..... FEFEFEFE..... FFFFFFF.... y ver si suena la flauta.

[Pofo]

Edcros, el algoritmo para cifrar lo has echo tu basandote en el cifrado y el deco, o lo viste por algun lado.

Puedes comentar algo de esto?

[Marcos75]

Entonces, ¿has sido capaz de desencriptar ya el Pang y que corra con un Z80 normal? ¿Teniendo en cuenta que los opcodes se encriptan de una manera y los datos de otra?

Si es así, entonces ya tenemos el primer problema resuelto, el de no tener que usar EPROMs del doble de tamaño del original. ¿Lo has probado en MAME?

Un saludo.

[ArcadeHacker]

Edcross, cual es la rutina de cifrado?, es sencillamente una algoritmo que pilla llave y datos o es dinamica?

Si no te importa explicar un poco como lo has echo...

El cifrado tiene mas ingredientes que un caldo.... para no liarme lo resumiré en esto:

-Para los opcodes: Un calculo en base a la posición en memoria de cada byte + una de las llaves de cifrado. Para los datos:  lo anterior + un XOR
-Para opcodes y datos: Unas 7 operaciones de desplazamiento de bits [Editado: Son bits no bytes] utilizando dos de las llaves de cifrado y un XOR utilizando otra de las llaves de cifrado

Ademas de esto existe el retorcimiento de que con lo de arriba acabas con dos cifrados diferentes, uno para opcodes y otro para los datos usados por los opcodes... Entonces tienes que mezclar todo milimetricamente en un solo fichero para que luego pueda ser ejecutado correctamente en un entorno real (MAME o Hardware)

Partiendo de las rutinas de descifrado no se puede hacer una rutina de cifrado revertiendo el proceso ya que existe perdida de información en lo descrito arriba. Por lo tanto el cifrado se basa en el descifrado + calculo de tablas calculando todas las combinaciones posibles por cada byte.

Siento el rollo, pero no se como resumirlo mejor.

[Marcos75]

Ademas de esto existe el retorcimiento de que con lo de arriba acabas con dos cifrados diferentes, uno para opcodes y otro para los datos usados por los opcodes... Entonces tienes que mezclar todo milimetricamente en un solo fichero para que luego pueda ser ejecutado correctamente en un entorno real (MAME o Hardware)

Hola de nuevo, edcross. Este punto me interesa mucho, porque es el punto débil que yo veía en el proceso. De hecho, cuando estuve liado con System 16, Ricky se acordará, mi principal problema era, una vez que tenía desencriptado código por un lado y datos por otro, como entrelazarlo. Veo que tú ya lo tienes resuelto. Cuando tengas un hueco te agradecería mucho que me dieses alguna pista de cómo hacerlo para trasladarlo a system 16

Muchas gracias.

Un saludo.

[ArcadeHacker]

Entonces, ¿has sido capaz de desencriptar ya el Pang y que corra con un Z80 normal? ¿Teniendo en cuenta que los opcodes se encriptan de una manera y los datos de otra?

Si es así, entonces ya tenemos el primer problema resuelto, el de no tener que usar EPROMs del doble de tamaño del original. ¿Lo has probado en MAME?

Un saludo.

Descifrado si, mapa de opcodes y datos del juego original no. Es por esto que hice mi Hello World, para olvidarme de ese problema hasta que sepa si he acertado con el estado del Kabuki.

Despues acierte o no tengo pensado meterme a construir ese mapa para fusionar el codigo de Pang ejecutado en un solo archivo. Seguramente comenzaré modificando el mame para que me ayude a construir ese mapa, me esperan unas cuantas horas de juego 

[ArcadeHacker]

Ademas de esto existe el retorcimiento de que con lo de arriba acabas con dos cifrados diferentes, uno para opcodes y otro para los datos usados por los opcodes... Entonces tienes que mezclar todo milimetricamente en un solo fichero para que luego pueda ser ejecutado correctamente en un entorno real (MAME o Hardware)

Hola de nuevo, edcross. Este punto me interesa mucho, porque es el punto débil que yo veía en el proceso. De hecho, cuando estuve liado con System 16, Ricky se acordará, mi principal problema era, una vez que tenía desencriptado código por un lado y datos por otro, como entrelazarlo. Veo que tú ya lo tienes resuelto. Cuando tengas un hueco te agradecería mucho que me dieses alguna pista de cómo hacerlo para trasladarlo a system 16

Muchas gracias.

Un saludo.

Creo que mi última respuesta contesta el tema, te pasaré lo que acabe haciendo en el mame para dibujar el mapa de relaciones. Seguramente el mapa nunca será 100% (no creo que sea posible hacer que el juego pase por absolutamente todas sus rutinas). Para completar cualquier rom habrá que meter trabajo manual si o si.

[Pofo]

Edcross, cual es la rutina de cifrado?, es sencillamente una algoritmo que pilla llave y datos o es dinamica?

Si no te importa explicar un poco como lo has echo...

El cifrado tiene mas ingredientes que un caldo.... para no liarme lo resumiré en esto:

-Para los opcodes: Un calculo en base a la posición en memoria de cada byte + una de las llaves de cifrado. Para los datos:  lo anterior + un XOR
-Para opcodes y datos: Unas 7 operaciones de desplazamiento de bytes utilizando dos de las llaves de cifrado y un XOR utilizando otra de las llaves de cifrado

Ademas de esto existe el retorcimiento de que con lo de arriba acabas con dos cifrados diferentes, uno para opcodes y otro para los datos usados por los opcodes... Entonces tienes que mezclar todo milimetricamente en un solo fichero para que luego pueda ser ejecutado correctamente en un entorno real (MAME o Hardware)

Partiendo de las rutinas de descifrado no se puede hacer una rutina de cifrado revertiendo el proceso ya que existe perdida de información en lo descrito arriba. Por lo tanto el cifrado se basa en el descifrado + calculo de tablas calculando todas las combinaciones posibles por cada byte.

Siento el rollo, pero no se como resumirlo mejor.

Gracias edcross.

[Marcos75]

Ok, ahora te entiendo. Prepárate, porque ahora viene el trabajo duro

Aquí es donde yo te decía que si alguien no había hecho ya esa labor de entrelazado, es porque será realmente complicada. Por ejemplo en System 16 los dos o tres juegos que he conseguido descifrar ha sido con inspección manual, y relativamente sencilla (digamos 4 ó 5 horas). Pero con el Enduro Racer no pude, porque el grado de entrelazado era brutal. Ahí harán falta esas ayudas de las que hablas (mapas de memoria).

Mucha suerte, estaremos pendientes.

Un saludo.

[Andreas Naive]

Hola de nuevo, edcross. Este punto me interesa mucho, porque es el punto débil que yo veía en el proceso. De hecho, cuando estuve liado con System 16, Ricky se acordará, mi principal problema era, una vez que tenía desencriptado código por un lado y datos por otro, como entrelazarlo.

Marcos, llevo varias semanas liado a muerte con el FD1094, así que te puedo dar una pista sobre cómo mejorar el proceso; Chris Hardy me hizo notar que las zonas de datos van marcadas con un identificador especial (no recuerdo si una palabra o dos); él se programó en su momento una utilidad para recuperarlas; tampoco recuerdo si valía para todos los FD1094 o sólo para algunos. Si tienes interés te busco la información.

Yo estoy intentando recuperar las claves completas para los 2 juegos que aún no la tienen; en el proceso, he tenido que crearme herramientas para estimar automáticamente qué es código y qué no. El resultado tiene ruido, pero es bastante potable. Si tienes necesidad, me dices un juego concreto y te genero un mapa para que te ayude. El estimador se basa en el hecho de que sólo el código va cifrado; es por ello que no creo que funcione con Kabuki. Lo siento, edcross.

[Marcos75]

Andreas, te agradezco mucho tu comentario. No sabía que estabas metido en temas de FD1094. ¡Muchos ánimos!

Eso que dices del identificador especial lo he notado en algunos juegos pero, en el caso concreto con el que me atasqué (el Enduro Racer - FD1089), no vi ningún identificador ni patrón que me permitiese ver dónde acaba un área de código y dónde empieza una de datos. Quizá se me pasó por alto. Como te digo, en otros juegos sí lo he visto... Finalmente con el Enduro Racer desistí, aunque he conseguido las ROMs desencriptadas por otra vía.

Muchas gracias por ofrecerme tu ayuda. Estoy seguro de que ese estimador que te has fabricado me hubiera ayudado a no perder tantas horas de sueño en el pasado Ahora mismo no tengo necesidad de desencriptar ningún juiego, porque todos los que tengo en la colección los tengo ya desencriptados.

Eres muy amable ofreciendo tu ayuda desinteresada. Muchas gracias.

Un saludo.

[Andreas Naive]

edcross, me retracto; mi herramienta sí que puede servirte para estimar dónde está cada cosa; bastaría aplicar el descifrado de datos a todo el contenido y después pasar el estimador. ¿Tienes interés?

[ArcadeHacker]

edcross, me retracto; mi herramienta sí que puede servirte para estimar dónde está cada cosa; bastaría aplicar el descifrado de datos a todo el contenido y después pasar el estimador. ¿Tienes interés?

Pues si gracias!, todo lo que ayude a terminar el trabajo es bienvenido. En 1 o 2 semanas podré hacer las pruebas sobre el HW real, y ver que pasa. Te escribo en caso de superar esa fase.

[Marcos75]

Andreas, he estado revisando mis notas. En Passing Shot, que fue el último que desencripté en su día, la separación venía marcada por fedc 9801 (encriptado). En Wonder Boy III y Dynamite Düx no tengo nada apuntado, pero puede ser que ni siquiera me diese cuenta, y sí tengan un separador.

Un saludo.

EDITO: Por cierto, ¿cuáles son los dos juegos sobre los que estás trabajando?

[Andreas Naive]

Sí, eso debía ser.

Los juegos en los que trabajo son las dos variantes que quedan sin clave en system16: aceattac y altbeastj1
También hay un system24 pendiente, pero ese tendrá que esperar, porque system24 hace un mejor uso de los estados de la protección y mis herramientas fallan (aún así creo que se puede hacer, pero necesitaré hacer algo más).

[Rockman]

Aquí hay nivel...... :-)

Enhorabuena edcross con tu pedazo de proyecto! A ver si llega a buen puerto.

PD: A ver si consigo ponerme un poco al dia para poder seguiros.... que llegarán los examenes de Junio y voy a catear assembler del Z80 (ya no digo nada de la encriptación jajajja).

[Marcos75]

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]

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.

[Andreas Naive]

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]

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?

[Andreas Naive]

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.

[Pofo]

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]

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]

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/

[ArcadeHacker]

@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é.

[Rockman]

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.

[Pofo]

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]

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]

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]

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]

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!.

[Andreas Naive]

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

Sí; es bastante común que las BIOS o bootloaders controlen qué se sube. Cuanto más moderna la placa y más serio el fabricante, más probable es que haya algún mecanismo de verificación.

Y lo normal hoy en día es que no sea sólo verificación sino, ante todo, control. Intenta cargar código propio en una consola de Microsoft, ya verás qué risa. Lo normal es utilizar MACs y firmas criptográficas para asegurarte de que
1) Sólo una entidad autorizada puede cargar cosas
2) Nadie ha modificado el código creado por las entidades autorizadas

[ArcadeHacker]

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.

En el Z80 es M1 (pin 27).

[Marcos75]

Gracias edcross. Espero que nos perdones por generalizar el tema de tu hilo, pero el tema que has tratado es tan interesante que estamos todos expectantes...

[ArcadeHacker]

Gracias edcross. Espero que nos perdones por generalizar el tema de tu hilo, pero el tema que has tratado es tan interesante que estamos todos expectantes...

Encantado de seguir la conversación. 

[Pofo]

Yo, dado lo didactico del hilo solo te pido que, si no te importa, expliques los paso poco a poco.

Y si no te importa, y lo ves bien, que expliques un poco como hacer cosas tan sencillas como programar un hola o similar, si ya tienes el detalle de explicsr el programa de codificado y poner algun ejemplo del entrelazamiento y tal...pero es solo si te ves con tiempo y quieres.

Saludos.

[Andreas Naive]

Os veo hablando de desensambladores, y puede que no sepáis que MAME tiene su propio desensamblador, creado por Aaron Giles, que soporta bastantes arquitecturas.

Es una herramienta independiente. En el código fuente está en /src/tools. Ignoro si los binarios oficiales la incluyen o no.

[ArcadeHacker]

Yo, dado lo didactico del hilo solo te pido que, si no te importa, expliques los paso poco a poco.

Lo publicaré todo, pero no esperes muchas cosas reutilizables, cada placa es un mundo. Otro tema diferente es que te enseñe en otro hilo como programar un Hola Mundo en la placa que más rabia te de (que sea z80).

Lo dejo en tus manos.

[Pofo]

Si que estaria bien que explicaras cosas en ensamblador z80 que pudieramos probar en otras placas.

Me resulta muy interesante el tema de la programacion, si no te resulta muy complicado seria muy de apreciar un tutorial de lengusje ensamblador aplicado aunque supongo que seria muy basico porque la arquitectura de video cambia de placa a placa.

Saludos y gracias por compartir esto.

[Rockman]

Yo, dado lo didactico del hilo solo te pido que, si no te importa, expliques los paso poco a poco.

Lo publicaré todo, pero no esperes muchas cosas reutilizables, cada placa es un mundo. Otro tema diferente es que te enseñe en otro hilo como programar un Hola Mundo en la placa que más rabia te de (que sea z80).

Lo dejo en tus manos.

Yo también te estaría muy agradecido edcross con que hicieras un mini tuto para ver que has hecho en el proceso de "resucitación"/desencriptación de Pang. Aunque sea específico a una placa, da una orientación y una manera de enfocar este tipo de problemas.
(Ya he tenido problemas para entender y realizar el salto de protección del Choplifter que hiciste en otro hilo. Me falta entrenamiento)

[Marcos75]

puede que no sepáis que MAME tiene su propio desensamblador, creado por Aaron Giles, que soporta bastantes arquitecturas.

Gracias, Andreas. Quizá sea el mismo desensamblador que utiliza MAME en modo debug, ¿no?

[Andreas Naive]

Pues comparten código, claro. Pero esta herramienta la puedes ejecutar sin lanzar MAME.

[ArcadeHacker]

Actualización

Sigo esperando el borrador de eproms (gracias china, gracias correos), con lo que todavía no he podido probar nada en hardware real.

Por otro lado, ya tengo terminada la parte del proyecto necesaria para tener un juego de roms normales sin tener que recurrir al truco de la doble carga (parte baja/alta de la rom en roms de doble tamaño)

Con esto ultimo, funcione o no el rescate del Kabuki a su estado original, ya se pueden rescatar las Pangs sin tener que usar roms diferentes ni tener que cablear la placa.

De momento sigo probando estas nuevas roms por si se me ha escapado algo, si alguien tiene placa pang original y le apatece ayudar a probarlas que me haga un mensaje y os las paso.

Un saludo.

[Marcos75]

Qué buenas noticias.

¿Lo estás probando en MAME? Es el mejor banco de pruebas antes de pasar a las placa real Editas el código fuente del driver del Pang para que, por ejemplo, la subrutina del Kabuki no haga nada, y sustituyes las ROMs originales por las tuyas.

Un saludo.

[ArcadeHacker]

¿Lo estás probando en MAME? Es el mejor banco de pruebas antes de pasar a las placa real Editas el código fuente del driver del Pang para que, por ejemplo, la subrutina del Kabuki no haga nada, y sustituyes las ROMs originales por las tuyas.

Si, todo en mame de momento. Cuando termine todo esto te paso el hook que hice en el driver del z80 para mapear opcodes, etc.

Un saludo.

[Rockman]

Genial edcross, eres el master del ensamblador. ;-)

Si quieres te dejo mi borrador chino y ya me lo devuelves cuando te llegue el tuyo. Es una jodienda estar parado por culpa que te tiene que llegar algo de oriente. Sobre todo si viene en camello...
Si lo quieres venir a buscar, no problem. Yo lo he usado una vez y ahora no tengo pensado usarlo.

Saludos!

[Marcos75]

Genial. Qué buen trabajo. Y decía yo que si alguien no lo había hecho antes es porque era realmente difícil. Seguramente no me faltara razón, así que ¡ahí tus huevos!

Yo en su momento no tenía los conocimientos para hacer este tipo de mapas de memoria, así que me los tenía que currar a mano y a ojo. En los juegos en los que el entrelazado era no muy fuerte, vale, pero en cuanto la cosa se complicaba el trato manual era imposible.

Lo dicho, buen trabajo. Enhorabuena.

Un saludo.

[ArcadeHacker]

Gracias, realmente una vez hechas las herramientas el resto ha sido un tema de meter horas y mucho Odaweb

[enricnes]

Enhorabuena Edu!! Vaya crack!!
Yo tengo un par de Pangs a las que le iran genial!!!
Tenemos que abrir el wiki pronto para colgar estos tutoriales, si no tienes inconveniente.
Saludos!

[Pofo]

Que tal.

Edcross a mi mas que las eproms me gustaria ver los programas que te curraste para desencriptar y para separar datos y opc.

La ram del kabuki como queda cuando se suicida?

Todo lo que documentes el tema seria genial y si puedes mandarme al mail eso me valdria de mucho.

Lo dicho eres un artista.

[ArcadeHacker]

Buenas Pofo, lo subiré todo cuando termine el proyecto, de momento no he podido probar nada en el kabuki, compré un par de aparatos , un borrador de eproms y un simulador de eprom, pero ninguno me ha llegado de momento....

Saludos

[ricky2001]

Edcross mi más sincera enhorabuena por el logro, si necesitas betatester yo tengo Pang, super pang y 2 Block Block que usan el mismo sistema, además de eproms para probar y todo eso.

Saludos

[ArcadeHacker]

Edcross mi más sincera enhorabuena por el logro, si necesitas betatester yo tengo Pang, super pang y 2 Block Block que usan el mismo sistema, además de eproms para probar y todo eso.

Genial Riciky, gracias.

Os dejo una descarga del set provisional Pang Unencrypted: http://we.tl/XVA5iRn7BO

A falta de sorporte formal en Mame esto solo es de utilidad en un Pang hardware, el pin 28 del Kabuki ha de estar en bajo para que se comporte como un z80 normal.

Ya me contais que tal funciona.

[ricky2001]

Bueno pues tengo que decir que me he echado unas partidazas que no veas al Pang con tus eproms, me ha funcionado a la perfección, aunque yo no soy particularmente bueno al Pang (ni casi a ningún otro ), he llegado hasta el nivel 8 y no he notado ningún fallo, así que tengo que decir edcross que estás hecho un crack, aunque creo que eso ya había quedado claro antes.

Seguiré haciendo el duro esfuerzo de echar unas partidas mas jejeje

Saludos

[ArcadeHacker]

Bueno pues tengo que decir que me he echado unas partidazas que no veas al Pang con tus eproms, me ha funcionado a la perfección,

Gran noticia entonces. Me alegro de que funcionen en la placa real. Una pregunta, entiendo que tu pang ya estaba desuicidado y el kabuki no recibe los 5v en pin 28, como tienes el jumpblock que se ve en esta foto?



Muchas gracias de nuevo.

[Marcos75]

Creo recordar que alguno (o probablemente todos) los jumpers de ese bloque sirven para seleccionar entre EPROMs JEDEC y non-JEDEC.

Un saludo.

[ricky2001]

Si, la placa estaba desuicidada y el pin del Kabuki puesto a masa



Están igual que en tu foto, creo que es como dice Marcos para seleccionar el tipo de eprom, yo he usado una 27256 y una 27C010, las originales suelen ser 27256 y 27c1000 compatible con la 010.

Saludos

[ArcadeHacker]

Actualización

Gracias Rockman por dejarme el borrador de Eproms, otra cerveza cuando te lo devuelva

De momento no hay suerte, el Kabuki en modo encriptado (pin 28 conectado) no responde a roms encriptadas con todas las llaves a 00 o FF. El siguiente paso será entender si el Kabuki llega a leer de las roms, y si es el caso, hacer un ataque de fuerza bruta de una manera más automatizada para averiguar que cifrado entiende.

Para ese ataque estoy esperando un aparato bastante curioso que he encontrado y que es capaz de emular eproms y en el que puedes cambiar el codigo en tiempo real. Tambien permite saber a que zonas de la memoria se están accediendo. Se llama Ostrich 2.0 y lo usan en el mundo de la automoción para cambiar los mapas de motor, frenado etc... os dejo un link abajo por si os interesa saber más.

La semana que viene más.

https://www.moates.net/ostrich-20-the-new-breed-p-169.html

[Marcos75]

Muy interesante. Esperemos que en la RAM del Kabuki no quede un contenido aleatorio, y puedas determinar qué queda ahí. La verdad es que la lógica haría pensar que quedara todo a 00 ó a FF...

Seguiremos muy pendientes.

[Pofo]

Y si cada vez que arranca tiene un codigo distinto...estamos jodidos

[ArcadeHacker]

Y si cada vez que arranca tiene un codigo distinto...estamos jodidos

Jajaja, espero que no.

Por cierto, tambien he podido probar el set unencrypted que os puse, confirmo como Ricky que funciona bien.

[ricky2001]

En ese caso se usan las eproms desencriptadas del mismo tamaño que las originales que edcross ha sacado y vale igual, esto es para rizar el rizo, supongo que en el caso de esta placa el Kabuki pueda ser reprogramado, aunque dudo mucho que averigüemos como, lo digo por que no puede venir programado de fábrica ya que aunque viniera alimentado al pincharlo en la placa se borraría, yo creo que al menos en este caso le programaban "in situ", ahora descubrir como ya es otra cosa.

Saludos

[ArcadeHacker]

yo creo que al menos en este caso le programaban "in situ", ahora descubrir como ya es otra cosa.

Buen punto, mi teoria es que la cpu tiene comandos z80 extra para programar la parte del encriptado, y quizas las programaban pinchando una eprom con el codigo necesario para configurarla antes de poner el set de roms del juego.

Que pensais?

[Rockman]

Un placer habernos conocido edcross. :-) Encantado de poder ayudarte en tus investigaciones edcross aunque sea con un borrador de eproms. Es un proyecto muy interesante.

Pedazo de invento el emulador de Eprom. Estos tuneros se las saben todas... ;-)

Y por lo que comentais, es casi seguro que programaran la cpu directamente en la placa con la bateria puesta. Si la placa pang no tiene algun puerto extra, o lo hicieron como dices con una eprom "especial" de programa o sino, con una pinza de 40 pins encima de la cpu para cargar el contenido de la ram interna con algun equipo especial. Lástima que el datasheet de esta cpu no esté por la red.

Ánimos!

[Pofo]

Es por de ir algo...ya puestos a pedir...que no tenga ni un cable.

[enricnes]

Edu,
el link de descarga ha caducado. Lo puedes poner en otro lado u otra vez? Este fin de semana lo probare en 2 placas (aunque 1 no arranca, debe tener mas problemas ademas del suicidio).
Saludos!

[ArcadeHacker]

Edu,
el link de descarga ha caducado. Lo puedes poner en otro lado u otra vez? Este fin de semana lo probare en 2 placas (aunque 1 no arranca, debe tener mas problemas ademas del suicidio).
Saludos!

Espero no haberme equivocado de ficheros, voy con un cohete en el culo últimamente, a ver si encuentro tiempo para retomar todo esto.

http://we.tl/bnjs8iJ2dY

[ArcadeHacker]

Buenas,

Analizador en mano he jugado un poco más con el Kabuki. Ando algo perdido pq vigilando el direccionamiento de la cpu veo cosas extrañas.

Por ejemplo, si intento encerrar la cpu en un bucle infinto, eg: rst 0 o call 0000, sigo viendo por las patas de direccionamiento llamadas secuenciales que no tocan, todo esto lo hago con el kabuki en modo z80 normal:

Muestra de patas A0 a A7



En cambio esa misma prueba en el mame funciona perfectamente y la cpu no sale de la posición 0000.

Ideas?

[Rockman]

Cuando dices bucle infinito te refieres sin interrupciones ni nada que altere el programa? Y dejando en bucle la carga del valor de la posición 0000h en un registro interno del Z80 y dejarlo en bucle?

Es posible que el ciclo de esa instruccion de lectura deje al bus de direcciones en algun momento en alta impedancia o algo parecido que te falsee las mediciones?. Hablo así un poco al tuntún. No he tenido la oportunidad de hacer un analisis como el que has hecho y no tengo experiencia en ello.

Estas seguro de tu analizador? Yo tengo uno chino y va como el culo, muestra cambios de estado que no son los reales. No lo llegue a probar mucho porque no funcionaba correctamente y, o perdía cambios de estado o los ponía donde no había.
A ver que igual el tuyo es más fiable y funciona como debe. :-)

Haciendo varias adquisiciones siempre te muestra las mismos resultados?

Saludos!

[Marcos75]

Si las pruebas las estás haciendo sobre el hardware real ten en cuenta que puede haber (y de hecho suele haber) más "gente" que mete direcciones en el bus de direcciones.

Un saludo.

[ArcadeHacker]

Buenas, he seguido una recomendación de Rockman de medir CLK junto a cualquier otra cosa y efectivamente no tengo lecturas estables. Voy a ver si pongo esto en otro sistema y consigo que lea bien.

[Marcos75]

¿Quieres decir que el analizador puede estar falseándote las medidas?

[Rockman]

Efectivamente Marcos, a mi analizador chino le ocurre lo mismo. Primero pensé que estaría mal, pero veo que el de edcross le pasa lo mismo.
Creo que están hechos para medir señales a muy muy baja frecuencia y sobre todo para analizar buses de tipo serie de 1 o dos canales. No los veo adecuados para vuestras placas.

Aunque tienes razón Marcos en lo que has dicho, si se hacen medidas directamente en la placa arcade puede que vea señales generadas por otros componentes. Aunque si no estoy equivocado, la mayor parte del tiempo, el bus de direcciones estará controlado por el z80. Aunque recuerdo tu otro hilo donde explicabas el lapso de tiempo en que dejaba de mandarlo la cpu principal.
Y si encima deja a la cpu en bucle, a no ser que se genere una interrupcion, la cpu estara quietecita en el bucle accediendo a una misma posición de memoria.

[Marcos75]

Es cierto, Rockman. El periodo de tiempo en el que el bus de direcciones está controlado por otros elementos es mucho menor que el tiempo en el que la CPU lo controla. De hecho no sé si seríamos capaces ni de verlo en una gráfica del estilo a la que nos ha puesto edcross...

Un saludo.

[ArcadeHacker]

Os comparto un poco más de lo que me he ido encontrando.

Volví a reanudar el experimento de dejar la cpu en un bucle infinito sin avanzar el contador del programa. Para ello le puse un código rom con una única instrucción: C7 (rst 0h). Esto lo que hace es que la cpu vuelva a la posición 0 de la rom una y otra vez.

Abajo podeis ver los resultados de lo que se ve en el bus de datos. Como vereis no tengo ni idea de que son esos periodos intermedios donde hay un pico en todos, o casi todos los bits.

Mi siguiente paso es sacar la cpu de la placa y usar un test board para poder controlar el experimento.

[enricnes]

Edu, otra vez no vuelvo a llegar a tiempo para descargar las roms, las puedes poner en algun lugar mas permanente? Dropbox quizas?
Salut!

[ArcadeHacker]

Edu, otra vez no vuelvo a llegar a tiempo para descargar las roms, las puedes poner en algun lugar mas permanente? Dropbox quizas?
Salut!

mandame un privado con tu email

[Andreas Naive]

Edu, lo que intentas no me parece ni siquiera razonable.

En más o menos cualquier procesador convencional, una instrucción en ensamblador, aunque sea ejecutada de forma funcionalmente atómica, suele ser dividida en varias microinstrucciones (te permite un diseño más compacto, ahorrando hardware/transistores).

MAME no emula la ejecución del hardware a nivel de microinstrucciones, la emulación sólo llega hasta el nivel de las instrucciones; lo que hay por debajo es simplemente simulado. (Como excepción, hace unos meses OG estaba intentando emular un 68000 a nivel de transistores, pero sólo para propósitos de referencia).

Así que, en una instrucción como RTS 0h podrían esperarse varias microinstrucciones. Una división razonable (pero totalmente inventada), podría ser:
1) Exposición del registro de ejecución (PC) en el bus de datos, gestionando las señales que hagan que las líneas de bufferes dejen en alta impedancia el resto de líneas que acceden al bus.
2) Lectura de la RAM y carga en el registro de instrucción del contenido leído. (quizá subdividido en más de un paso)
3) Carga en el registro acumulador del contenido del registro de ejecución (PC)
4) Incremento de la dirección en el acumulador
5) Carga del PC con el contenido del acumulador

Todos los pasos 1)-5) serían comunes para todas las instrucciones. La parte específica de RST 0 podría ser:

6) Cálculo de la dirección de salto (0x0000) usando los bits #3, #4 y #5 del registro de instrucción y lógica discreta (para reusarla en todas las instrucciones RST XX, de semántica similar) en el registro acumulador
7) Carga del registro de ejecución (PC) con el contenido del registro acumulador.
8 ) Activación de señal para marcar el fin de la ejecución de esta instrucción.

A priori, el uso lógico del bus de direcciones sólo estaría en el ciclo de carga de instrucción, pero ten en cuenta que la CPU es soberana, así que puede reusar el bus para lo que le convenga, por ejemplo, el intercambio de información entre dos registros como parte de una microinstrucción.

La división de arriba es, como digo, imaginaria; no conozco el Z80 en suficiente detalle como para atreverme a apostar cómo estará dividida esa instrucción en microinstrucciones. Al final, la moraleja de todo esto es que tienes que tener en cuenta que la ejecución de una CPU es mucho más compleja de lo que pareces esperar. El código ensamblador es una abstracción de muy alto nivel para un diseñador de CPUs.

Si estás interesado en seguir por esta vía, busca información para ver si alguien sabe con detalle cuáles son las microinstrucciones de un Z80. Y ten en cuenta que diferentes fabricantes del Z80 pueden usar diseños distintos con microinstrucciones diferentes.

[Marcos75]

Hola Andreas. Jamás me atrevería a contradecir a alguien que sabe de microprocesadores 1 millón de veces más que yo. Pero, ¿eso que comentas no es a nivel interno?. Es decir, el procesador, cuando va a la ROM a buscar una instrucción, realmente pone 0 en su bus de direcciones, y realmente obtiene C7 de la ROM para esa instrucción. Es decir, en el bus de datos realmente hay un 11000111 para esa instrucción.

Otra cosa es como funcione el procesador internamente, pero entiendo que eso no se refleja en sus pines de salida, que es lo que edcross está mirando.

De hecho, y aunque el analizador lógico de edcross parece que sigue dando lecturas erróneas, sí se ve un esbozo de 11000111 en el bus de datos. Y los espúreos esos pudieran corresponder con la interrupción de 60Hz. He tratado de hacer números, y me sale algo relacionado con 6 para la frecuencia, pero como no entiendo la escala que aparece en la foto no sé si realmente esos picos están separados por 1/60Hz...

Un saludo.

[Andreas Naive]

Me puedes contradecir cuanto quieras, Marcos, faltaría más. Me equivoco continuamente.

Por supuesto que tienes que ver la instrucción en el bus de datos en algún momento del ciclo. A lo que yo iba es que no necesariamente tienes que ver los mismos datos en el bus durante toda la instrucción. La CPU puede tener sus buses internos conectados a los externos mediante líneas de búferes. Si decide que va a usar los internos para sus propios usos y los desconecta eléctricamente de los externos mediante los búferes, sólo verías una señal estable en los pines externos si, digamos, la ROM mantiene el acceso de escritura al bus durante todo el ciclo. Y yo no veo que eso tan seguro; la CPU es, al cabo, quien señaliza a la ROM que ya puede escribir en el bus, por lo que es posible que sólo haga tal cosa durante el ciclo de carga de la instrucción, y durante otras partes del ciclo de ejecución, no me sorprendería que los pines externos estuviesen en alta impedancia.

[Marcos75]

Gracias por la explicación, Andreas. Entiendo lo que quieres decir.

Un saludo.

[Andreas Naive]

Esto me hace pensar en una prueba rápida: Edu, intenta cargar dos bytes C7 y mira si los pines de datos muestran un comportamiento distinto a cuando sólo tienes un C7. La justificación es que, mientras que el segundo C7 no se ejecutará, no es imposible que la CPU esté incrementando la dirección del bus de direcciones a la vez que la ROM aún está escribiendo en el bus de datos, por lo que entre una y otra prueba podría notarse un cambio adicional en el bus de datos.


Edito. Segunda prueba: vigila las líneas de comunicación entre la CPU y la ROM (Enable, Read/Write, lo que sea que estén usando) y mira si los cambios que observes están correlacionados en el tiempo con los que encontrabas en los pines de datos.

[ArcadeHacker]

Buenas, al final decidi sacar el kabuki de la placa y pasar por hacer el experimento en un test board, efectivamente había mucho ruido de otros temas en el bus, a parte de que un z80 emulado ni de broma actua como uno fisico, especialmente lo que se ve en las patas de direccionamiento y otros etc.. que he ido aprendiendo con este proyecto.

Pero finalmente puedo cantar victoria y compartirlo con vosotros!!



El codigo del pantallazo corre en un pang suicidado sin cambiar nada en el hardware en modo cifrado En cuanto acabe con varios detalles publico las roms nuevas y os comparto todos los detalles.

[Marcos75]

¡Enhorabuena! Ansioso estoy por empaparme con esos detalles

[Rockman]

Me alegro que hayas podido hacer avances Edcross!

Yo también tengo curiosidad en como ha ido la cosa.

Por cierto, en la foto, veo que tienes pinchado un cacharro en el zocalo de una de las memorias (de programa supongo). Es el "famoso" emulador de eproms?

Saludos!

[ArcadeHacker]

Correcto, es el trasto para car tunning de moates.net, emula y permite tracear a que direcciones se accede, aunque esto ultimo va fatal, creo que no respeta chip/output enable. Para mi lo mas util es que me deja cambiar el codigo rom en caliente. Igualmente me parece caro para lo que hace, tengo que investigar hacer algo equivalente en arduino.

[Marcos75]

edcross, soy un desastre y tampoco he llegado a tiempo de descargarme las ROMs desencriptadas ninguna de las dos veces que las has colgado... ¿Me las podrías enviar por correo, por favor?

Muchas gracias.

Un saludo.

[ArcadeHacker]

Te las envio con la condicion de que hablemos por skype, necesito consultarte un tema. 

[Marcos75]

Hostia, pues me vas a obligar a refrescar cómo coj**nes se hacía eso, ya que la última (y única) vez que lo usé fue para una reunión de AUMAP, hará ya al menos 2 años

[ArcadeHacker]

Actualización

Parece que el kabuki quiere dar una última pelea. Aunque soy capaz de ejecutar código cifrado creado por mi, por algún motivo las roms del juego no funcionan. Dudo mucho que sea un tema de código o protecciones, ya que las roms desencriptadas funcionan perfectamente en el hardware original del pang, y el codigo cifrado tambien funciona perfectamente en Mame.

Para seguir avanzando no me queda más remedio que tracear las diferencias en la ejecución del código descrifrado vs cifrado, paso a paso. Esta vez lo haré utilizando un arduino para crear un log de la actividad de la cpu, ya que leer los 28 leds (addr+data+controles) del protoboard es altamente perjudicial para la salud 

Mientras monto el nuevo experimento y por curiosidad (y curarme en salud), he montado el Kabuki en un amstrad cpc (tambien es z80) para hacerle pasar un programa bastante tipico en el mundillo de los desarrolladores de emuladores z80, Zexall. Este programa permite comprobar el grado de compatibilidad de una cpu (o entorno emulado) z80,  basicamente ejecuta todos los opcodes posibles en sus diferentes combinaciones y lee los resultados para verificar que cumple lo esperado por un z80 oficial.

No espero sorpresas pero no hay que descartar nada ya que el Kabuki es claramente una implementación exotica del z80.

Pronto os cuento más.

[ArcadeHacker]

Sin sorpresas, despues de varias horas ha pasado todos los tests. Es un z80 100% standard a nivel de código.

[ArcadeHacker]

Actualización

No más leds!. Desde hace unos días ya cuento con un interfaz para testear el z80 en arduino que me permite controlar la cpu programaticamente en todas sus entradas y salidas. He descubierto lo siguiente:

-Arranque en frio en modo cifrado (pin 28 en alto), Kabuki solo ejecuta NOP's le pases lo que le pases.
-Arrancando en frio en modo no-cifrado (pin 28 en bajo) podemos conseguir que el modo cifrado sí ejecute código. Para esto primero hay que ejecutar código no-cifrado y despues pasar a modo cifrado en caliente poniendo el pin 28 en alto.

Huele a que el decoder que lleva interno se queda en algún estado no-inicializado cuando ha perdido la batería, y mucho me temo que este comportamiento no va a permitir recuperar el funcionamiento del chip de manera practica, al menos no sin antes tener más visibilidad sobre lo que ocurre internamente.

Tengo diversas teorias de que puede estar pasando pero he decidido no perder más tiempo a oscuras. Voy decapear el chip para ver como está organizado internamente, y ver tambien si existe forma de reprogramarlo.

Paralelamente a esto hice un poco de investigación y pude averiguar que Kabuki fue desarrollado por VSLI Technologies (aka VTI), un laboratorio de diseño de integrados que ya no existe. Tirando un poco de ingeniería social pude dar con un ex empleado de VTI  encargado de las operaciones en Europa y Asia entre 1988 y 1996, años en los que se fabricó Kabuki.

Esta persona no sabe nada concreto de la implementación o de como funciona el cifrado pero me ha facilitado información critica para la compresión de este procesador y su organización interna.

Quizas sepais esto o no, pero los chips primero se desarrollan en software utilizando programas y plataformas de prototipado al igual que se hace con las pcb. Durante los 80 la industria del integrado hizo avances criticos para la estandarización de las formas logicas que componen un chip, y pasar de diseños especificos (un diseño solamente fabricable por un proveedor), a diseños utilizando librerias y formatos estandard (diseños reutilizables y fabricables por mutliples proveedores). Una parte importante de estas librerías eran los "standard cells".

Podeis imaginaros un "standard cell" como una unidad que contiene la lógica que define un AND, un OR etc... Estas formas se copian y pegan en los softwares de prototipado para conseguir el diseño deseado y beneficiarse de automatismos de autorouting, optimización, etc..

VTI (el desarrollador de Kabuki), siguió dando pasos en la estandarización de la industria introduciendo una linea de productos denominados Megacell. Los Megacell consistian en diseños de integrados completos portados a librería bajo un sistema de bus propio de VTI, para poder ser reutilizados y/o recombinados entre si.

Imaginaos un controlador de CRT, una ram, o cualquier otro integrado siendo totalmente definido en software, combinable y arrastrable dentro de un diseño como una forma lógica.

Uno de estos diseños transformados en Megacell fue el Z80, y así es como nace "Kabuki", un producto hecho por VTI Japon para Capcom. Podeis imaginaros Kabuki como un circuito integrado que contiene al menos 2 o 3 elementos: un z80, un decoder, y una ram (embedida o no en el decoder). Todos ellos definidos como Megacells e interconectados en un bus de VTI.

Y esto es todo de momento, el proximo update vendrá acompañado (espero) de una foto de Kabuki ligero de ropa

[Andreas Naive]

Interesante. Tanto el término "standard cell" como el uso que describes es hoy en día común en el diseño de ASICs. Ignoro los detalles del desarrollo histórico del proceso, no obstante. Si alguno siente interés, este curso es muy bueno, aunque en realidad sólo toca tangenciamente el asunto de las "standard cells":

https://www.coursera.org/course/vlsicad

[ArcadeHacker]

Pedazo de curso, gracias!

[Marcos75]

Muchísimas gracias edcross por toda esta información. Tremenda la labor de investigación que estás realizando alrededor de este pequeñín.

Si no he entendido mal:

- El Kabuki en modo cifrado (pin 28 HIGH) no es capaz de correr código encriptado con clave todo a ceros.
- Pero si arrancas en modo no cifrado (pin 28 LOW), ejecutas código no cifrado, y pasas a modo cifrado (pin 28 HIGH) en caliente, en ese momento el Kabuki sí ejecuta código cifrado (con clave todo a ceros) con normalidad.

¿Es así?

Insisto, muy interesante.

Un saludo.

[ArcadeHacker]

Actualización

Kabuki y los problemas de arranque en frio en modo cifrado
Misterio resuelto, el kabuki (o mi kabuki) no recibe suficiente 5v en el pin 28 de la placa original (4.63v) y por esto hacia cosas raras como ejecutar NOP's. Di con el problema tras seguir probando en Arduino.

Decapado de la cpu
He podido ganar algo de practica con varias z80 defectuosas que tenía guardadas pero no he sido capaz todavía de poder decapar un chip en condiciones. El problema es el acido nitrico al cual tengo acceso, no es lo suficientemente concentrado.

El primero, Acido Nitrico 60%, es una perdida de tiempo, no hace nada. El segundo que pude conseguir, Acido Nitrico 70%, si que consigue penetrar el encapsulado pero tarda demasiado, no consiguiendo una abertura limpia y dañando el chip al tener que elevar la temperatura a unos 120c, en vez de los 80c-90c recomendados.

Para poder decapar con exito es necesario Acido Nitrico 90%. Os dejo un video con la reacción y una foto del resultado...





Como podreis apreciar la abertura no es limpia, el encapsulado tiene signos de haber estado demasiado caliente mucho tiempo y el integrado tiene daños visibles. Si alguien sabe donde conseguir Acido Nitrico 90% ruego me de pistas. Gracias!


Ejecutar código cifrado
He podido dar con el problema del pq mi código de test cifrado (hello world) funciona pero el código de Pang cifrado no. Para llegar a este resultado tuve que hacerme con un analizador logico serio con al menos 30 canales. (gracias Rockman por la recomendación).

La imagen a continuación contiene el mismo bloque de código a la izquierda siendo ejecutado cifrado y a la iderecha descifrado como código z80 normal. Ambos en la placa original de Pang y cpu Kabuki. Parece ser que los datos grabados en el Stack por la cpu aunque leidos correctamente, luego son interpretados como código a descifrar...Esto provoca que la cpu jamás pueda volver al lugar correcto cuando encuentra un Return....



El pq de este comportamiento todavía se me escapa y tengo muchas dudas. Es el comportamiento de la cpu sin programar cuando ha perdido la batería? Mi cpu está defectuosa? etc..etc.. Cualquier idea, pista o sugerencia será más que bienvenida.

Un saludo y gracias por leer.

[Marcos75]

El master chef de los integrados te vamos a llamar

No sé si he entendido bien. En MODO CIFRADO, cuando la CPU trata de recuperar el PC de la pila, ¿lo interpreta como un opcode y lo intenta "descifrar"?

¿Podría ser eso un comportamiento normal, y que programar código para un Kabuki tenga ciertas limitaciones que haya que salvar con "workarounds"?

No sé, por decir algo...

[ArcadeHacker]

No sé si he entendido bien. En MODO CIFRADO, cuando la CPU trata de recuperar el PC de la pila, ¿lo interpreta como un opcode y lo intenta "descifrar"?

Escribe en la pila el PC (normal sin descifrar), pero al leerlo lo interpreta como un dato a descifrar. eg: lee PC 005B y acaba saltando a 00AD (5B decodifica en AD con las llaves a 0).

¿Podría ser eso un comportamiento normal, y que programar código para un Kabuki tenga ciertas limitaciones que haya que salvar con "workarounds"?

Pienso que no pq entonces el codigo descifrado funciona perfectamente. Signo de que en las roms originales cifradas no tienen nada alterado. Igualmente el dato PC no sale de las roms, sale de los registros de la cpu.

[Rockman]

Edcross, yo igual puedo conseguirte acido nitrico como el que quieres, pero tendras que esperar una semana para que pueda averiguarlo. Podrás esperar?

Nunca he decapado un chip pero a veces he leido al respecto y sobre todo hay que ir gota a gota y conseguir una temperatura constante, con una estufa de laboratorio. No se yo si una paella de papas fritas al fuego es un calor demasiado extremo para no dañar el integrado. Aunque Mcguiver lo hizo con tan solo un boli y un chicle. Pero genial el video.

Sobretodo podrías indica que es algo muy peligroso de hacer, no vaya alguien a hacerse daño. No solo el acido es peligroso y muy inestable, los vapores de la reaccion son altamente toxicos.

Por otra parte, veo que ahora tienes un analizador que te permite ver el bus de datos y direcciones a la vez. Que pasote!

Animos con tu PEDAZO de proyecto!

PD: @Marcos: Master Chef. XDDDD

[ArcadeHacker]

Puedo esperar todo lo que haga falta, GRACIAS. Y tienes razón.

OJO con el acido nitrico. Guantes, pipeta y recipientes adecuados (el acido se come el metal).

En cuanto a la "paellera" jajaj, no hay ningun problema, tengo un termometro que me permite controlar el experimento.

MasterIC

[Marcos75]

Hola edcross. No me había explicado bien. Lo que estaba sugiriendo es que ese comportamiento fuese normal en el modo CIFRADO, y que los programadores lo conociesen, y evitansen utilizar instrucciones CALL, y las sustituyesen por un PUSH del PC y un JUMP.

Era una estupidez, pero por decir algo. Acabo de desensamblar un trocito del código del Pang, y está lleno de instrucciones CALL...

Un saludo.

EDITO: Si me lo permites, un par de preguntas (del lado descifrado, que es más fácil de seguir):

- ¿Qué es el "data" FF que aparece por ahí intercalado?
- Cuando estamos en los ciclos del CD, ¿por qué "addr" se va a "7C"?

Gracias.

[ArcadeHacker]

Son estados internos de la cpu, usa el address bus para sus "cosas". Cada linea de la foto es un golpe de reloj.

[ArcadeHacker]

Confirmado con el arduino. La lectura de la pila la trata como un dato a decodificar :/   Actualizo: Tambien lo hace con la lectura de cualquier dato previamente escrito en memoria. Para que el juego original funcionase sospecho de que parte de la programación del cifrado consiste tambien en la posibilidad de instruirle que zonas de memoria solamente ha de decodificar. eg: Sí en 0000-BFFFF (zona roms) pero el resto no...

[ArcadeHacker]

Actualización



Habemos cpu pr0n y el comienzo de un camino largo Os voy contando.

[Rockman]

Actualización



Habemos cpu pr0n y el comienzo de un camino largo Os voy contando.

Se han filtrado fotos pr0n del kabuki!!!

Con todos mis respetos, ERES UN CABRITO EDCROSSS!!!

Al final que has usado lejía con polvos picapica para decaparlo???

:-P

Saludos.

[Marcos75]

Ostras, qué bueno.

A ver si nos pones alguna foto de todo el chip, a ver cómo ha quedado...

Un saludo.

[ArcadeHacker]

Al final que has usado lejía con polvos picapica para decaparlo???

Al final lo mejor fue crema depilatoria portuguesa. Para las fotos un iphone con una lente de estas con aumento de ebay (iphone 5s). 

[enricnes]

Genial Edu!!!
Estoy impaciente por ver tus progresos.
Saludos!

[ArcadeHacker]

Buenas señores, tan solo quiero dejar constancia de donde estoy con este tema.

Tengo muchísimas horas invertidas en dominar la ingeniería inversa de silicona y su simulación, tengo un 90% del protocolo de programación del Kabuki ya resuelto y me quedan unas últimas piedras por resolver.

Contra todo pronostico se trata de un protocolo serie bastante complejo, creo que esta gente de capcom/mitchell tenían bastante tiempo libre y mucha imaginación... Una vez consiga terminar esta parte me toca el duro trabajo de averiguar que hay que grabar exactamente (y en que posición) en los 108 bits de memoria que tiene internamente.

Os dejo una foto del pequeñin a petición de Marcos.



A la izquierda el bloque grande, un z80 cmos. El resto de bloques arriba, abajo y toda la parte derecha son especificos del Kabuki. Cuando acabe con el proyecto me vais a tener que aguantar durante mucho tiempo explicando infinidad de detalles.

Un saludo.

[Marcos75]

Es realmente asombroso el trabajo que estás haciendo.

Curiosamente tenía la idea de que la protección del Kabuki no era "gran cosa", y fíjate qué sorpresa.

Muchas gracias por la foto, es impresionante.

¡Ánimo!

Un saludo.

[Rockman]

Los creadores del Kabuki jamás pensaron que alguien tendría tanta perseverancia como tú edcross para descifrar su CPU hasta el nivel de conocer como funciona internamente.

Deseando estoy que compartas los entresijos de esta curiosidad de CPU. Curioso número el 108.

Te felicito de nuevo por tu tesis doctoral sobre el kabuki. :-)

[ArcadeHacker]

  Muy orgulloso de compartir este momento con vosotros, ya es posible reprogramar Kabuki. Misión cumplida!

[ricky2001]

Que buena noticia edcross, enhorabuena, impresionante trabajo, supongo que hay que programarlo ya puesto en placa para que no se borre al cambiarlo no?

Saludos, Ricky

[ArcadeHacker]

Gracias Ricky. Dentro o fuera de placa es ok mientras mantengas la cpu alimentada, curiosamente creo que la programación la hacían fuera de placa, voy a empezar a escribir una serie de articulos donde tb os explicaré el pq de este razonamiento.

Que buena noticia edcross, enhorabuena, impresionante trabajo, supongo que hay que programarlo ya puesto en placa para que no se borre al cambiarlo no?

Saludos, Ricky

[Marcos75]

Enhorabuena edcross.

Impresionante trabajo. Los resultados al final no podían ser otros, el que la sigue la consigue.

Un saludo.

[Characa]

Me quito el sombrero ante tamaño trabajo.

Enhorabuena!

 

[Pofo]

Sin duda es el mejor trabajo que he visto en foros españoles.

Genial.

[Rockman]

Qué cabr*n Edcross, al final lo has conseguido! Mi enhorabuena. Has conseguido averiguar los 106 bits que daban la llave correcta!!! Aparte de realizar la grabación, las miles de pruebas y tests:

http://www.youtube.com/watch?v=GkfzW5M6wII

Saludos Doctor Kabuki!

A sus piés! ;-)

[ArcadeHacker]

Buenas a todos,

Lo prometido es deuda y aquí os presento el primer post sobre Kabuki. Para la ocasión he aprovechado en usarlo para inagurar mi blog sobre arcade (Arcade Hacker), espero que os guste y os voy informando según vaya publicando nuevas entregas:

arcadehacker.blogspot.com/2014/11/capcom-kabuki-cpu-intro.html

[Rockman]

Pedazo de blog profesional ARCADE HACKER. Tiene muy buena pinta.

Esperaré ver noticios de tu MEGA proyecto derrotando al Kabuki.

Me quito el sombrero!

[ArcadeHacker]

Os comparto link al siguiente articulo de la serie.

http://arcadehacker.blogspot.com.es/2014/11/capcom-kabuki-cpu-part-1.html

[enricnes]

Enhorabuena Edu,
estamos impacientes por la siguiente entrega!!
Saludos!

[Rockman]

Ya he visto el segundo capítulo. A parte del éxito de tu proyecto, consigues crear expectación con tus explicaciones. Muy profesional todo.

Genial Edu!

[ArcadeHacker]

Ya he visto el segundo capítulo. A parte del éxito de tu proyecto, consigues crear expectación con tus explicaciones. Muy profesional todo.

Genial Edu!

Gracias por tus palabras Rockman, supongo que mucho es deformacion profesional 

[ArcadeHacker]

Acabo de publicar el siguiente articulo de la serie. Espero que os guste, un saludo.

arcadehacker.blogspot.com/2014/12/capcom-kabuki-cpu-part-2.html

[Rockman]

Interesante nuevo capitulo de tu trabajo edcross.
En este ya se mete más en profundidad en lo que es realmente la chicha del estudio que has hecho. Está muy bien explicado, aunque deberán abstenerse la gente sin unos conocimientos previos para poder seguir el artículo.

Enhorabuena.

[LeT]

Bueno, bueno, bueno,...te estas haciendo famoso!!!

http://hackaday.com/2014/12/12/reverse-engineering-capcoms-crypto-cpu/

Magnifico trabajo, si señor.

[ArcadeHacker]

Gracias Rockman y Let!

Os dejo el siguiente post de la serie, ya queda menos para el final.

http://arcadehacker.blogspot.com/2014/12/capcom-kabuki-cpu-part-3.html

[ArcadeHacker]

Buenas a todos y felices fiestas. Os dejo el post #4 de la serie, esta vez lleva video:

http://arcadehacker.blogspot.com/2014/12/capcom-kabuki-cpu-part-4.html

[Rockman]

Oooootra enhorabuena más edcross. Siento no poder mirar con detenimiento tus progresos por falta de tiempo pero prometo hacerlo. Of course!

He puesto el video por encima y bueno, parece que nos des una masterclass pr0n del Kabuki desde un laboratorio de Silicon Valley. ;-)

Lastimita mi nivel de english no es tan bueno como el tuyo, tendré que ponerme las pilas para seguirte.

Saludos!

[ArcadeHacker]

Gracias Rockman, si crees que ayuda puedo mirar de trabajar subtitulos, pero solo si realmente va a servir de algo ya que requiere bastante tiempo.

Un saludo

[Characa]

si crees que ayuda puedo mirar de trabajar subtitulos, pero solo si realmente va a servir de algo ya que requiere bastante tiempo.

Un saludo

Disculpa mi atrevimiento, pero... por qué no has hecho el blog y la exposición (fantástica, sin dudar) también en español?

Un saludo.

[ArcadeHacker]

Por tiempo y exposición en cuanto a la cantidad de publico que puede alcanzar.

Es probable que a finales del primer trimestre del 2015 participe en una charlas en madrid sobre estos temas, allí tendré la oportunidad de hacer esto en español, y lo mejor, la organización graba videos.

si crees que ayuda puedo mirar de trabajar subtitulos, pero solo si realmente va a servir de algo ya que requiere bastante tiempo.

Un saludo

Disculpa mi atrevimiento, pero... por qué no has hecho el blog y la exposición (fantástica, sin dudar) también en español?

Un saludo.

[enricnes]

Characa, piensa que lo que ha hecho Edu, tiene repercusion mundial, es normal que lo haya hecho en ingles.
Por cierto Edu, felicidades, tienes un ingles estupendo, no se oye todos los dias uno asi!!

[Rockman]

Gracias Rockman, si crees que ayuda puedo mirar de trabajar subtitulos, pero solo si realmente va a servir de algo ya que requiere bastante tiempo.

Un saludo

Gracias por el ofrecimiento, pero es un trabajazo demasiado tedioso lo de subtitular un video de 25min. Si tuviera alguna duda ya te lo pregunto. (a ver si un dia de estos de fiestas le hecho un vistazo con la tranquilidad necesaria y mas o menos me entero del video).

Saludos jáquer! ;-)

[Characa]

Por tiempo y exposición en cuanto a la cantidad de publico que puede alcanzar.

Es probable que a finales del primer trimestre del 2015 participe en una charlas en madrid sobre estos temas, allí tendré la oportunidad de hacer esto en español, y lo mejor, la organización graba videos.

Gracias, estaremos expectantes; la lengua de Shakespeare se me atraganta un poquitín 

Enricnes, ya quisieran algun@as tener esa pronunciación, con o sin café jejeje...

Un saludo.

[ArcadeHacker]

Buenas a todos, os dejo el último post sobre Kabuki:

http://arcadehacker.blogspot.com.es/2014/12/capcom-kabuki-cpu-part-5.html

Con este video se cierra el tema y poco más queda que contar, espero que lo disfruteis.

Saludos.

[enricnes]

Genial video Edu!

Un par de comentarios:

Quizas un post a modo resumen para que te enlacen desde Dead Battery Society, con las connotaciones practicas del trabajo. Lo digo porque normalmente esa es la pagina en la que acaba todo el mundo por primera vez, y le daria mas repercusion y visibilidad a tu trabajo.

Nos podrias poner por aqui algunos detalles mas del programador que te has fabricado? Quizas unas fotillos mas detalladas tambien?

Un saludo!

[Rockman]

Hola Edcross!

Más que un microscopio, parece que usaste un "escaneador de turbo protones intergaláctico de plutonio" para sacar toda esa información del chip. Aun no salgo de mi asombro de tal "atraco" realizado al Kabuki.
Todo el protocolo de reprogramación, como tu comentas no es trivial. Tu explicas el cómo se hace, pero una parte que a mi siempre me intriga es el como llegas a descubrir ese cómo... y la identificación fisica de todos los componentes.
Incluso limpiando capas de metal de las imágenes....
¿Quizá se me escapan cosas por el idioma y no me he enterado del cómo del cómo?

En fin.... APLAUSOSSSSSSSSS!!!!! Otra gran masterclass Edu! :-)

PD: Y al cacharrito que aparece al final, creo que le van a salir algunos novios. jejejejeje.

[ArcadeHacker]

Gracias a ambos, me alegro de que os haya gustado.

@Enricnes en cuanto vuelva a casa haré un video del programador resucitando una placa.
@Rockman quedaremos y te explico detalles hasta que te canses de mi.

[Rockman]

@edcross. Jajajajaja. Ok!

[ricky2001]

Enhorabuena edcross, realmente es un trabajo excelente.

Saludos

[Characa]

Para "flipar" 

Un trabajo sublime Edcross.

Cómo has conseguido ese nivel de detalle de las pistas del chip?? (si quieres contarlo).

Un saludo y feliz año

[ArcadeHacker]

Gracias Characa/Ricky.

@Characa, las fotos me las hicieron en un laboratorio con un microscopio Olympus BX60M, lleva una bandeja con motor XY que permite automatizar la captura. Despues hay un trabajo de photoshop/gimp para componer todo.

[enricnes]

Hasta donde se, no se decapan mas customs en mame x caro y complicado. Tu haces q parezca barato y facil.
Deberias postularte en mame 😄😄😄😄😜

[Rockman]

Hasta donde se, no se decapan mas customs en mame x caro y complicado. Tu haces q parezca barato y facil.
Deberias postularte en mame 😄😄😄😄😜

Jejejejeje, tu lo has dicho Enric. Edcross hace que PAREZCA barato y fácil. Pero no lo es!

[ArcadeHacker]

Buenas y feliz año, os dejo un video del programador en acción.

[Rockman]

Muy cuco y elegante el aparatito edcross! Y muy curioso lo de usar la pinza, programar "en el aire" e instalar en la placa.
Parece una tonteria ese proceso ahora pero detras están tus enésimas horas de investigación del kabuki.

Estaré atento a tus inventos!