Capcom Kabuki CPU - Part 1

Welcome to the second post in the Kabuki series of articles analyzing this security cpu in detail. If you haven't you can read the previous post here.

Who made Kabuki?

Kabuki was manufactured by VLSI Technology Inc, also known as VLSI or VTI, a company which designed and manufactured custom and semi-custom ICs. 

I assume their company name originated from the term "Very Large Scale Integration", a term referring to design and fab processes for the integration of hundreds of thousands of transistors into an IC.

According to Wikipedia, VLSI was an important pioneer in the electronic design automation (EDA) industry. It offered a sophisticated package of tools, originally based on the 'lambda-based' design style. VLSI no longer trades as it got acquired in by Philips in 1999.

During my investigation and using social networks I did reach out to several ex-employees, and was lucky to make contact with a person who ran operations within VSLI at the time Kabuki got manufactured (1987/88).

This person confirmed that the company had a Z80 product in their portfolio and remembered the company had designed and manufactured ICs for several Japanese game vendors. He referred to their Z80 as a "megacell" family product.

Cells and Megacells

One of the two popular design processes for semi-custom chips is known as cell technology. Back in the 80s VSLI Technology Inc became one of the early vendors of cell based semi-customs.

Think of cell based design as the way of defining primitive logic functions (AND, OR, XOR....) into a library for reusing and combining as many times as required in different designs via CAD design tools.

A standard cell NAND gate

According to VTI documentation from 1986, "Megacells" consisted in far more complex products than standard cells, just imagine a whole chip or controller design converted into cell format for combined usage with other cells.

The VTI Z80 product was one of those megacells available as part of the VMC10 and VMC100 Series, 2-Micron and 1.5 Micron Advanced Megacell Family:

Portion extracted from a 1988 VTI megacell catalog

Besides Kabuki, VTI did more semi-custom Z80 products for other companies, here's an example of one found inside a music instrument, the SCI Multi-Trak:

VTI Z80 semi-custom. Photos taken from www.tauntek.com/SCIMultitrak.htm

Kabuki CPU vs the standard Z80

Kabuki's main difference to any standard cpu is the lack of Dynamic Memory (DRAM) refresh. Standard Z80 cpus feature DRAM refresh on pin 28 that helps using dynamic memories with the same ease as static memories.

Dynamic memories consist of tiny capacitors requiring constant refreshing in order to preserve memory contents. The Z80 helped overcome this problem by offering an integrated memory refresh facility that simplified designs and reduced overall cost by requiring far less external circuitry.

Instead of featuring a memory refresh service, Kabuki uses pin number 28 as a power supply input directly related to its security features. Losing power on this input causes a loss of internal data inside the chip and bricks your game.

What this also means is that Kabuki cannot be used in systems that feature dynamic memories, at least not without the aid of external circuitry. 

One particular interesting behavior of Kabuki is that leaving pin 28 low or unconnected turns it into a standard Z80 cpu. A clear indication that whoever designed Kabuki wanted it to also be useful as a regular cpu.

Designing and manufacturing your own customized cpu is a very expensive business,  having the option to reuse Kabuki as standard Z80 stock could have made complete financial sense to Capcom back then. 

We now know Kabuki has physical differences, but what about at code level? Is Kabuki a fully compatible Z80 class cpu? 

Z80 Compatibility

Wondering how compatible Kabuki is, I hooked it into my old Amstrad CPC 6128 (uses a z80 too) and turned it on without any surprises. The computer worked and seemed to do its job without any issues.

Next was running Zexall, a powerful application commonly used by developers of Z80 emulators to test for emulation compatibility issues. Zexall is a great program that runs all posible Z80 instructions and reports any issues found. 

No surprises here either, running the Z80 Exerciser for several hours revealed no issues whatsoever. To all effects, at code level Kabuki is a fully compatible Z80 cpu. 

How Kabuki works

Thanks to the great work done by the Icer Addis and later the Mame team, Kabuki's encryption scheme is known and all games successfully emulated. It works by performing a series of bit operations consisting of bit swaps, bit rotations and xors.

The exact method as described by the mame driver:

"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.
bitswap -> ROL -> bitswap -> XOR with a key -> ROL -> bitswap -> ROL -> bitswap
- 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"

The keys involved in the process are as follows and each game has a different key set:

• For example, decode keys used by Pang:
• Bitswap key #1 0x01234567
• Bitswap key #2 0x76543210
• Address key 0x6548
• XOR key 0x24

Putting Kabuki under the logic analyzer revealed that at a physically level Kabuki must see or control at least the following cpu lines:

• All data inputs, D0 through D7
• Needed in order to see and decode data.
• All address lines, A0 through A15.
• Each byte decodes differently depending on the address.
• The RFSH "refresh" line
• Used as power input to maintain internal memory contents. When low makes Kabuki behave as a standard Z80.
• The M1 line
• Necessary in order to know when an op code or data is fetched. Kabuki decodes Op code bytes differently than Data bytes.
• The RD "read" line
• Needed to know when data read operations occur. Kabuki does not interfere with write operations, only decodes, does not encode.
• The IORQ or MEMREQ line
• Kabuki must know when IO operations occur as it does not interfere with IO reads or writes.

Kabuki being analyzed with a multi channel logic analyzer

The important questions

Question #1

What happens after Kabuki has lost power and its memory contents gone? After all memory is memory and it must return to a known state.  Do all decoding keys go back to 00? or perhaps FF? 

Question #2

How did Capcom program Kabuki? It's obvious that someone had to program each cpu during game manufacturing. 

Did they use an external programer attached to each cpu? This approach would require special logic inside the cpu and the manufacturing additional hardware (programming devices).

Did they use a special rom containing programing code?  This approach sounds the easiest from a manufacturing point of view, plug a rom, power the board and done, the cpu has been programmed. 

This last method would also imply a lot of complex custom cpu logic (eg: instruction decoding etc...) and use unused Z80 opcodes, we already know Kabuki is full Z80 compatible.

Question #3

Is it even possible to reprogram it? Some security ICs feature physical protections such as security fuses burned after programing. 

This is all for this week, thanks for reading and stay tuned for the my next post: A software attack on Kabuki.