Capcom Kabuki CPU - Part 3

Welcome to the fourth post in the Capcom Kabuki reverse engineering series, if you missed any of the previous readings you can find them here:

• Intro
• Part 1
• Part 2

A Better Pang Desuicide

Are you familiar with this mess?

If you do then it means that at some point you have desuicided some sort of arcade game, most probably a Capcom title.

To me this is actually how this journey started the day I got hold of a dead Capcom/Mitchell Pang game motherboard. Like many of you went straight to the usual arcade forum and asked the community for advice, and this is when you most probably got introduced to the Dead Battery Society website.

Yup, you have a look and it seems like you can get you game to work by doing X, Y and Z, hack your board, add new pieces, cables and even cut physical tracks and a few other tricks.

The Dead Battery Society web page

The result? You have a working game but not the original thing anymore, you required tools, skills, and the whole process isn't exempt of the risk of damaging your game. To some people this is ok but I don't think anyone can deny the appeal of having truly original hardware in our hands and the pain involved in having to hack our boards, we are passionate collectors after all.

Refusing the idea of having to do this with my own suicided Pang board I went on and researched for better ways of reviving Kabuki powered game titles.

As your know from the previous post I explored the effort of trying to take control of Kabuki via software, something that successfully allowed me to identify what happens inside Kabuki when the battery runs out, but also led me to the discovery that something else than just the encryption keys prevents us from reviving the games with software alone.

The next logical frontier was planning a hardware attack, a lengthy, skillful and complicated process that requires plenty of education and preparation. But in the meantime and with the help of some of the tools created for the software attack on Kabuki I went on and decided to make a simpler Pang desuicide method.

Pang playing in the Barcelona stage, my hometown. And no, there isn't such river in front of the Sagrada Familia ;)

The Existing Desuicide Method

The current popular desuicide method described by the Arcade Battery Society requires an important amount of tools, installing new double size roms as well as wiring, soldering, and forcing Kabuki in Z80 mode, etc... This existing hack exploits the fact that game unencrypted code can be obtained thanks the efforts of Icer Addis and the driver incorporated by the Mame team. 

The requirement for double size roms comes from how Kabuki's encryption operates, if you remember from previous posts, Kabuki features different encryption for Opcodes, than Opcode parameters and Data.

I won't get into much detail but knowing where exactly each byte goes into is a very difficult task and the only way of knowing so is by following the program execution byte by byte as it gets interpreted by the cpu. 

For this reason existing hacks require two unencrypted sets of the same data, one that has been processed with the decryption for Opcodes, and another set that has been processed with the decryption for Data and Opcode arguments.

The way this is put together is by using half of the double size rom for the first unencrypted data set and the second half for the data second set, all is then wired together to the higher address pin of the double size roms and the M1 signal of the Kabuki in Z80 mode or any other Z80 replacement compatible cpu.

The M1 pin of Z80 compatible cpus signals when the cpu is reading an Opcode, or an Opcode parameter or Data. This signal is the key to the hack as it allows us to know with digital precision what data to serve the cpu as M1 goes high or low.

A typical Pang desuicide

A way of simplifying this process both in the resources and skills required is to obtain a valid unified unencrypted set that fits into the original roms. Let's look into it.

Hands on

Using a similar approach to what I explained on my previous post with the software attack, we need a Pang mask file that can help us produce the definitive rom set. Think of a mask file as a map that tells us where Opcodes and Opcode arguments and Data should be places on a rom

Pang program roms consist of two roms labeled as Rom 6 and Rom 7. Number 6 is a 32k byte (256k bit) rom, and number 7 is the larger rom with 128k (1024k bit) worth of code.  In total combined they feature 160k bytes. 

Trying to trace 160k bytes worth of program code can be almost mission impossible if we tried to do this manually, so we must get an ally on our side that helps us speed up the process as much as possible, and this where once again Mame becomes a god sent. 

Mame features a collection of CPU drivers that emulate a variety of platforms, and among them the Z80 cpu, we can use these drivers to help us achieve our goal by modifying them to get the data we need as is processed by the emulated cpu.

Mame source code files - the Z80 driver

In my case what I wanted is to simply be able to modify the Z80 driver to fast track the identification of all opcodes and data bytes within the Pang code, and the best of all, you get this data by playing the game!

The way this is done, is by hacking the existing Z80 driver code and incorporate new code parts needed for dumping the mask information we seek. For example the different read types performed by the cpu:

case 1: byte8[0] = 0xFF; break; /* op code */   <--- Writes an 0xFF when the cpu reads an opcode

case 2: byte8[0] = 0xAA; break; /* op code argument */  <--- Writes 0xAA when data is read 

case 7: byte16[0] = 0xAAAA; break; /* op code argument16 bits */ <--- Etc...

case 3: byte8[0] = 0x22; break; /* memory read */

case 4: byte8[0] = 0x55; break; /* memory write */

case 5: byte16[0] = 0x2222;  break; /* memory read16 bits */

case 6: byte16[0] = 0x5555;  break; /* memory write16 bits  */

Or also assembling the rom bank structure used by the game, a fundamental part of the Kabuki encryption scheme:

case 0: PC = PC - banked_region[0]; break; /* 00000-03fff */

case 1: PC = PC - (banked_region[0] /2); break; /* 04000-0bfff */

case 2: ; break; /* 8000 - bfff */

case 3: PC = PC + (banked_region[0] /2); break; /* 0c000-0ffff */

case 4: PC = PC + (banked_region[0]); break; /* 10000-13fff */

case 5: PC = PC + (banked_region[0] *1.5); break; /* 14000-17fff */

case 6: PC = PC + (banked_region[0] *2);  break; /* 18000-1bfff */

case 7: PC = PC + (banked_region[0] *2.5);; break; /* 1c000-1ffff */

In summary, what we do with this modified driver is tap on all the interesting cpu operations, and the most tricky part is making sure we trap all opcode arguments correctly as they can get a bit complex (remember, opcodes and arguments and encrypted differently).

In order to use the driver we must recompile Mame and execute it with our favorite z80 powered game. While you play the game the driver saves to disk all the byte information on two separate files, z80.log (the main code region 0x0000-0x7FFF) and z80-banks.log (a dynamic region consisting in 8 banks in the 0x8000 to 0xBFFF region).

Portion of Pang's rom 6 mask file produced with Mame

Here's a copy of the modified Z80 driver, feel free to hack it and reuse it as much as you want and sorry for the lack of programing "etiquette", i'm just an amateur not a pro coder. Remember that it probably requires modification if to be used with games different than Pang or Buster Bros. It should compile fine as part of Mame 0.153.

Once we have played the game extensively, all screens, both single and two player.... and used all options available we should have a very consistent set of mask files that should be ready to put to test by using Masker, the program I shared on my previous post. Using Masker we can input both unencrypted (opcode and data) files together with the mask files produced by our Mame driver and get a final single romset that fits the original roms and requires not motherboard hacking.

Truth is this isn't as easy as playing and having all the work done, extensive testing and manual finishing of rom areas never accessed by the game program is necessary and this requires understanding of the byte-code, dedication and a considerable time investment. Consider this process mostly a handcraft.

Pang - The Unencrypted set

And here's the result, a complete functional unencrypted romset of Pang, click to download. 

What this means is you can get back to life your suicided Pang games by simply burning new code on the existing roms and not having to use new eprom pieces, wiring or hacking your board. 

The only requirement besides burning the new code is that you leave Kabuki's pin 28 hanging outside of the cpu socket unconnected (ignore this if your board is already desuicided and no power is being supplied to pin 28).

Pin 28 overhangs the cpu socket so it doesn't make contact

Next week

Thanks for reading and stay tuned for what's coming next week: A hardware attack on Kabuki. At this point in time i'm not entirely sure how many more posts  I will dedicate to Kabuki but expect at least one more fully dedicated to a journey under the microscope and exposing its reprograming secrets.

Until that time comes here's nice teaser of what's coming, enjoy and thanks again for following.

Kabuki under the microscope