Kabuki g-Knackt!

[Laschek]

Jemand hat anscheinend den auf Pre-CPS Games von Capcom als Kopierschutz verwendeten Kabuki Chip reverse engineert und verspricht nun entsuiciden ohne Boardmodifikation: http://arcadehacker.blogspot.de/2014/11/capcom-kabuki-cpu-intro.html
Ich bin mal gespannt, klingt jedenfalls interessant.

[mikemcbike]

Ich bin gespannt, ob es eine minimalinvasive Lösung geben wird. Der Kabuki ist schon lange geknackt un im MAME Sourcecode beschrieben:


/************************************************** *************************

"Kabuki" Z80 encryption




The "Kabuki" is a custom Z80 module which runs encrypted code. The encryption
key is stored in some battery-backed RAM, therefore the chip has the annoying
habit of stopping working every few years, when the battery dies.


The suicide battery supplies power to pin 28. When you remove the battery, if
you pull pin 28 low, the Kabuki will behave like a normal Z80.




Check at the bottom of this text to see a list of all the known games which
use this chip.




How it works:
The base operation is a bit swap which affects couples of adjacent bits.
Each of the 4 couples may or may not be swapped, depending on the address of
the byte and on whether it is an opcode or data.
The decryption consists of these steps:
- bitswap
- ROL
- bitswap
- XOR with a key
- ROL
- bitswap
- ROL
- bitswap


To know how to apply the bit swap, take the address of the byte to decode and:
- if the byte is an opcode, add addr_key to the address
- if the byte is data, XOR the address with 1FC0, add 1, and then add addr_key
You'll get a 16-bit word. The first two bitswaps depend on bits 0-7 of that
word, while the second two on bits 8-15. When a bit in the word is 1, swap the
two bits, otherwise don't. The exact couple of bits affected depends on the
game and is identified in this file with two keys: swap_key1 and swap_key2
(which are just permutations of the numbers 0-7, not full 32-bit integers).




Key space size:
- swap_key1 8! = 40320
- swap_key2 8! = 40320
- addr_key 2^16 = 65536
- xor_key 2^8 = 256
- total 2.7274 * 10^16




Weaknesses:
- 0x00 and 0xff, having all the bits set to the same value, are not affected
by bit permutations after the XOR. Therefore, their encryption is the same
regardless of the high 8 bits of the address, and of the value of
swap_key2. If there is a long stream of 0x00 or 0xff in the original data,
this can be used to find by brute force all the candidates for swap_key1,
xor_key, and for the low 8 bits of addr_key. This is a serious weakness
which dramatically reduces the security of the encryption.
- A 0x00 is always encrypted as a byte with as many 1s as xor_key; a 0xff is
always encrypted as a byte with as many 0s as xor_key has 1s. So you just
need to know one 0x00 or 0xff in the unencrypted data to know how many 1s
there are in xor_key.
- Once you have restricted the range for swap_key1 and you know the number of
1s in the xor_key, you can easily use known plaintext attacks and brute
force to find the remaining keys. Long strings like THIS GAME IS FOR USE IN
and ABCDEFGHIJKLMNOPQRSTUVWXYZ can be found by comparing the number of 1s
in the clear and encrypted data, taking xor_key into account. When you have
found where the string is, use brute force to reduce the key space.




Known games:
swap_key1 swap_key2 addr_key xor_key
Mahjong Gakuen 2 Gakuen-chou no Fukushuu 76543210 01234567 aa55 a5
Poker Ladies " " " " "" ""
Dokaben " " " " "" ""
Dokaben 2 unknown
Pang / Buster Bros / Pomping World 01234567 76543210 6548 24
Capcom Baseball " " " " "" ""
Capcom World 04152637 40516273 5751 43
Adventure Quiz 2 Hatena ? no Dai-Bouken 45670123 45670123 5751 43
Super Pang (World) 45670123 45670123 5852 43
Super Pang (Japan) 45123670 67012345 55aa 5a
Super Buster Bros 45670123 45670123 2130 12
Super Marukin-Ban 54321076 54321076 4854 4f
Quiz Tonosama no Yabou 12345670 12345670 1111 11
Ashita Tenki ni Naare unknown
Quiz Sangokushi 23456701 23456701 1828 18
Block Block 02461357 64207531 0002 01


Warriors of Fate 01234567 54163072 5151 51
Cadillacs and Dinosaurs 76543210 24601357 4343 43
Punisher 67452103 75316024 2222 22
Slam Masters 54321076 65432107 3131 19


************************************************** *************************/

[mrdo!]

Mich würde interessieren, wie man den Schlüssel wieder in den Kabuki stopft ...

[BossXxX]

Ist doch ganz eindeutig, du brauchst dafür nen Schlüsselmeister......

[Laschek]

Alter! Lebst du auch noch?! :D:unsure:

[BossXxX]

Kaum, ich vegetier hier so rum... und ab und zu wenn die Krankenschwester das Atemgerät auf maximal stellt, kann ich auch dumme Sprüche rauslassen.... :evil::p:evil:

[Laschek]

Vielleicht kann man dich dann ja auch wiederbeleben, Kabuki-Style :D

[Laschek]

Teil 2:

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

Der macht es echt spannend.
Das nervt :D

Ich frage mich echt ob seine Methode dann auch für den ambitionierten Elektronikstümper machbar ist :unsure:

[mikemcbike]

Ich vermute, er hat selbst noch keine Lösung und ist in der reverse engineering Phase... Ich bin gespannt. Von dem, was er schreibt, macht er einen kompetenten Eindruck.

[mrdo!]

Eigentlich müsste der Typ das hingekriegt haben, weil sonst die Postings nur bereits bekanntes Gelaber wären ... Also ich bin gespannt...

[mikemcbike]

Bis jetzt waren die Postings bekanntes Gelaber...

[Laschek]

and share my research work and findings that successfully allowed me to reverse engineer this cpu and bring any dead Kabuki games back to life unmodified

Liest sich so als wäre er bereits erfolgreich gewesen.

EDIT: grad gesehen: http://forums.arcade-museum.com/showthread.php?t=330338
Er hat es also schon geschafft.
EDIT: Ok, er schreibt nur dass er es geschafft hat den Kabuki rückwärts zu ingenieuren, nix von der Wiederbelebung :D:unsure:

[mrdo!]

Hmm, ja, was hat er denn bis jetzt "rückwärts ingenieurt"? Das der Kabuki sich wie ein normaler z80 verhält,wenn man den pin steuert, war doch bekannt.
Alle decrypted roms für Pang usw. basieren darauf ...

[Laschek]

Es geht weiter und ich verstehe nichts: http://arcadehacker.blogspot.de/2014/12/capcom-kabuki-cpu-part-2.html

[mrdo!]

Das war eine gute Idee: Einfach damit rechnen, daß der Key in der CPU auf 000....0000, oder 111...1111 zurückfällt ... Dann den Code so codieren, daß der Schlüssel passt...
Das es so einfach ist glaube ich nicht: Seit wann fallen neu eingeschaltete CMOS SRAMS auf einen definierten Wert? Hab ich jedenfalls noch nie gesehen.
Bin weiterhin gespannt...

BTW: Falls jemand ein Decrypted Romset für "Block" mit spinner braucht (gibt es nicht auf den einschlägigen Seiten), bitte anfragen.

[Thomas]

Es geht weiter und ich verstehe nichts: http://arcadehacker.blogspot.de/2014/12/capcom-kabuki-cpu-part-2.html
Geht mir ähnlich. Ab dem Punkt hier komm' ich nicht mehr mit :


If Kabuki uses an internal memory for storage then this storage must be of CMOS type, thanks to one of the manufacturer product catalogs (VTI) we already know that the Kabuki Z80 core is a CMOS part.

In theory bits of CMOS memory or registers must default to an specific value after a power loss has occurred. Normally this should be 0, but let's play and get wild by assuming internal inverters are at work and the memory output default value could also be 1.

In either case, and unless the designers of Kabuki randomized ram/register contents as part of a paranoid approach, then we could be in safe grounds when assuming that Kabuki's ram must get back a known state after a power loss has occurred.
Ja, was nützt denn das ? Strom weg, sind auch die Keys weg. Ob die Bits an der Speicherstelle, an der die Keys lagen dann nachdem der Strom wieder da ist nun alle auf Null oder Eins schalten oder gemischt sind nützt doch da nichts ? Ich kann da momentan nicht folgen :confused:

[mrdo!]

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

Anmerkung: In meinen Augen Stuss. :D

[Laschek]

Zumindest funktionierts :D

Grad ausprobiert:

Vorher: pink screen of death

13701

Auf dem Foto unpink... Batterie war sogar noch auf dem Board :eek: Zum Glück nix rausgesuddert.

Danach dann Pang:

13702

Wieso Stuss? :D

[mrdo!]

Was der Typ da macht ist bullshit... Er beobachtet das laufende Spiel in Mame und zeichnet die Opcodes auf, die angesprungen werden. Damit Patched er das encrypted ROM.
Nachteil: Wenn er in einen Teil des Programms nicht "reingespielt hat". Wirds auch nicht entschlüsselt. -> Absturz.

So clever waren viele Leute schon vor 10 Jahren.

Das ist also keine vollständige Entschlüsselung. Kann immer passieren, daß ein unbekanntes Codesegment beim spielen auf die Nase fällt.
Die "alte Methode" ist da sicherer...

[BossXxX]

^^^sag ma laschi... spielst du uffn klo? sieht fast danach aus? spülst den mist dann auch gleich runter?

[Laschek]

Das ist also keine vollständige Entschlüsselung. Kann immer passieren, daß ein unbekanntes Codesegment beim spielen auf die Nase fällt.
Die "alte Methode" ist da sicherer...

Ok.
:(
Alles nur Fake, Kulisse, Potemkinsches Dorf, Luftblase?
:(



^^^sag ma laschi... spielst du uffn klo? sieht fast danach aus? spülst den mist dann auch gleich runter?

Das Klo wäre daran zu erkennen dass da die meisten Fliesen runtergerissen sind. :D
Das hier war mal eine Küche.
Ansonsten: gehe weg!
Du unvollständige Entschlüsselung!

[mrdo!]

Naja, der Typ trägt eben bekannte Sachen zusammen. Er scheint zu glauben, daß es sich um Neuigkeiten handelt.
Das ist aber nicht der Fall.

Wo wir aber gerade beim Pang sind: Wenn man ein bischen mit mame bastelt, kann man sich ein decrypted romset erstellen.
Wenn man das z.B. für PANG macht, sind die entstehenden Roms unter schiedlich zu dem,
was auf der "dead battery society" veröffentlicht wurde!

Mich würde wirklich interessieren woher diese Differenzen kommen, bzw. wie diese Roms gebaut wurden ...

[mikemcbike]

Wie auf meiner Webseite zu lesen ist (http://www.wolfgangrobel.de/arcadereps/pang.htm), hat der Tim von Arcadecollecting einen ganz einfachen Weg gewählt:

weil er sich nicht die Mühe machen wollte, CPU-Befehle (verschlüsselt) von CPU-Daten (unverschlüsselt) zu unterscheiden, hat er einfach alles Bytes entschlüsselt, die EPROMs doppelt so groß gemacht und erst die verschlüsselte, dann die unverschlüsselte Variante darin abgelegt. Der Draht vom Kabuki (Z80-M1-Signal) steuert jetzt über das höchstwertige Adressbit an den Eproms den entsprechenden Datenbereich. Das geht, weil der Z80 bei Zugriff auf Opcodes (CPU-Befehle) das externe M1-Signal automatisch aktiv schaltet.

Das System ist popelig einfach und sicher. Und außerdem hat man ja die entschlüsselten ROMs schon mathematisch unter Verwendung der bekannten Schlüssel und Verschlüsselungsvorschriften erzeugt, siehe MAME-Source Code.

Unser Arcadehacker möchte nun einfach die M1-Steuerung überflüssig machen, indem er die Opcodes selektiv auf Schlüssel 0x00000000 verschlüsselt. Das wird bei Beobachtung eines laufenden Spiels aber immer unvollständig bleiben, weil nicht alle Programmteile abgearbeitet werden.

Ein intelligenter Disassembler könnte das Programm parsen, aber das funktioniert auch nur mit absoluten und relativen Programmsprüngen, wenn man indizierte Programmsprünge hat, also Sprünge auf Adressen, die sich z.B. durch Addition einer Programmadresse mit einem Registerinhalt ergeben, dann funktioniert das so auch nicht. Allerdings weiss ich nicht auswendig, ob der Z80 solche Adressierungen hat...

[mrdo!]

Einfaches Problembeispiel: Eine Tabelle mit Einsprungadressen. Das ist nichts ungewöhnliches. Kann kein "intelligenter Disassembler" jemals finden ...