Capcom

7 Articles

The Epic Saga Of Hacking Knights Of The Round

June 8, 2021 by 3 Comments

For the uninitiated, Knights of the Round was a hack-and-slash arcade game released by Capcom in 1991 that rather loosely followed the legend of King Arthur and the eponymous Knights of the Round Table. In it, up to three players make their way from stage to stage, vanquishing foes and leveling up their specific character’s weapons and abilities. But [Sebastian Mihai] was looking for a new way to experience this classic title, so he decided to reverse engineer the game and create his own version called Warlock’s Tower.

Those familiar with the original game will no doubt notice some of the differences right away while watching the video below, but for those who don’t have an intimate knowledge of Arthur’s digital adventures, the major changes are listed on the project’s web page. Among the most notable are the removal of cooperative multiplayer and stage time limits. This turns the game from a frantic beat ’em up to a more methodical adventure. Especially since you now have to compete the game in a single life. If we had to guess, we’d say [Sebastian] prefers his games to have a bit of a challenge to them.

Even if you aren’t interested in playing Warlock’s Tower yourself, the story of how [Sebastian] created it is absolutely fascinating. He started with zero knowledge of Motorola 68000 assembly, but by the end of the project, was wrangling multiple debuggers and writing custom tools to help implement the approximately 70 patches that make up the custom build.

The hundreds of hours of work that went into creating these patches is documented as a sort of stream of consciousness on the project page, allowing you to follow along in chronological order. Whether it inspires you to tackle your own reverse engineering project or makes you doubt whether or not you’ve got the patience to see it through, it’s definitely worth a read. If you’re a Knights of the Round fan, you should also take a look at the incredible wealth of information he’s amassed about the original game itself, which honestly serves as an equally impressive project in its own right.

Modified versions of classic games, known colloquially as “ROM hacks” are fairly common among serious fans who want to see their favorite games improved over time. While they aren’t always as ambitious as Warlock’s Tower, they all serve as examples of how a dedicated community can push a product well beyond the scope envisioned by its original creators.

Continue reading “The Epic Saga Of Hacking Knights Of The Round“ →

Cracking The Case Of Capcom’s CPS2 Security

June 6, 2018 by 19 Comments

We love a good deep-dive on a specialized piece of technology, the more obscure the better. You’re getting a sneak peek into a world that, by rights, you were never meant to know even existed. A handful of people developed the system, and as far as they knew, nobody would ever come through to analyze and investigate it to find out how it all went together. But they didn’t anticipate the tenacity of a curious hacker with time on their hands.

[Eduardo Cruz] has done a phenomenal job of documenting one such system, the anti-piracy mechanisms present in the Capcom CPS2 arcade board. He recently wrote in to tell us he’s posted his third and final entry on the system, this time focusing on figuring out what a mysterious six pin header on the CPS2 board did. Hearing from others that fiddling with this header occasionally caused the CPS2 board to automatically delete the game, he knew it must be something important. Hackaday Protip: If there’s a self-destruct mechanism attached to it, that’s probably the cool part.

He followed the traces from the header connector, identified on the silkscreen as C9, back to a custom Capcom IC labeled DL-1827. After decapping the DL-1827 and putting it under the microscope, [Eduardo] made a pretty surprising discovery: it wasn’t actually doing anything with the signals from the header at all. Once the chip is powered up, it simply acts as a pass-through for those signals, which are redirected to another chip: the DL-1525.

[Eduardo] notes that this deliberate attempt at obfuscating which chips are actually connected to different headers on the board is a classic trick that companies like Capcom would use to try to make it harder to hack into their boards. Once he figured out DL-1525 was what he was really after, he was able to use the information he gleaned from his earlier work to piece together the puzzle.

This particular CPS2 hacking journey only started last March, but [Eduardo] has been investigating the copy protection systems on arcade boards since 2014.

[Thanks to Arduino Enigma for the tip.]

In-Band Signaling: Quindar Tones

September 19, 2017 by 29 Comments

So far in this brief series on in-band signaling, we looked at two of the common methods of providing control signals along with the main content of a transmission: DTMF for Touch-Tone dialing, and coded-squelch systems for two-way radio. For this installment, we’ll look at something that far fewer people have ever used, but almost everyone has heard: Quindar tones.

Continue reading “In-Band Signaling: Quindar Tones” →

Revealing Capcom’s Custom Silicon Security

April 3, 2017 by 52 Comments

Ask any security professional and they’ll tell you, when an attacker has hardware access it’s game over. You would think this easily applies to arcade games too — the very nature of placing the hardware in the wild means you’ve let all your secrets out. Capcom is the exception to this scenario. They developed their arcade boards to die with their secrets through a “suicide” system. All these decades later we’re beginning to get a clear look at the custom silicon that went into Capcom’s coin-op security.

Alas, this is a “part 1” article and like petulant children, we want all of our presents right now! But have patience, [Eduardo Cruz] over at ArcadeHacker is the storyteller you want to listen to on this topic. He is part of the team that figured out how to “de-suicide” the CP2 protections on old arcade games. We learned of that process last September when the guide was put out. [Eduardo] is now going through all the amazing things they learned while figuring out that process.

These machines — which had numerous titles like Super Street Fighter II and Marvel vs. Capcom — used battery-backed ram to store an encryption key. If someone tampered with the system the key would be lost and the code stored within undecipherable thanks to “two four-round Feistel ciphers with a 64-bit key”. The other scenario is that battery’s shelf life simply expires and the code is also lost. This was the real motivation behind the desuicide project.

An overview of the hardware shows that Capcom employed at least 11 types of custom silicon. As the board revisions became more eloquent, the number of chips dropped, but they continued to employ the trick of supplying each with battery power, hiding the actual location of the encryption key, and even the 68000 processor core itself. There is a 6-pin header that also suicides the boards; this has been a head-scratcher for those doing the reverse engineering. We assume it’s for an optional case-switch, a digital way to ensure you void the warranty for looking under the hood.

Thanks for walking us through this hardware [Eduardo], we can’t wait for the next installment in the series!

Desuiciding Capcom Arcade Boards

September 15, 2016 by 37 Comments

Capcom’s CPS2 – or CP System II – was the early to mid-90s arcade hardware famous for Super Street Fighter II, Alien vs. Predator, and a few of the Marvel and Capcom crossover arcade games. As you would expect, these boards have become collectors items. Unfortunately for future generations, Capcom took some short-sighted security measures to prevent copying the games, and the boards have been failing over the last two decades.

After months of work, [ArcadeHacker] and several other arcade enthusiasts have reverse engineered the security protocol and devised a method of de-suiciding these arcade boards, allowing for the preservation of this hardware and these games. The code that does the trick is up on GitHub.

Last year, [ArcadeHacker] reverse engineered the on-chip security for Capcom’s Kabuki processor, the CPU used in some of Capcom’s earlier arcade boards. It used a similar protection scheme. In the Kabuki hardware, the on-chip ROM was interspersed with a few XOR gates on the processor’s bus. With a security key kept in battery-backed memory, this was enough to keep the code for the game secret, albeit at the cost of preventing historical preservation.

Over the next few weeks, [ArcadeHacker] will post more detailed information about the copy protection scheme of the CPS2 board, but the proof-of-concept works right now. It’s now possible to revive a CPS2 board that has killed itself due to a dead battery, and the hardware is as simple as an Arduino and a few test clips. You can check out a video of the exploit in action below.

Continue reading “Desuiciding Capcom Arcade Boards” →

Resurrecting Capcom’s Kabuki

January 28, 2015 by 31 Comments

About a dozen old Capcom arcade titles were designed to run on a custom CPU. It was called the Kabuki, and although most of the core was a standard Z80, a significant portion of the die was dedicated to security. The problem back then was arcade board clones, and when the power was removed from a Kabuki CPU, the memory contents of this security setup were lost, the game wouldn’t play, and 20 years later, people writing emulators were tearing their hair out.

Now that these games are decades old, the on-chip security for the Kabuki CPU is a problem for those who have taken up the task of preserving these old games. However, now these CPUs can be decuicided, programming the chip and placing them in an arcade board without losing their memory contents.

Earlier we saw [ArcadeHacker] a.k.a. [Eduardo]’s efforts to resurrect these old CPUs. He was able to run new code on the Kabuki, but to run the original, unmodified ROMs that came in these arcade games required hardware. Now [ArcadeHacker] has it.

The setup consists of a chip clip that clamps over the Kabuki CPU. With a little bit of Arduino code, the security keys for original, unmodified ROMs can be flashed, put into the arcade board (where the contents of the memory are backed up by a battery), and the clip released. [ArcadeHacker] figures this is how each arcade board was programmed in the factory.

If you’re looking for an in-depth technical description of how to program a Kabuki, [ArcadeHacker] has an incredibly detailed PDF right here.

Continue reading “Resurrecting Capcom’s Kabuki” →

Reverse Engineering Capcom’s Crypto CPU

December 12, 2014 by 26 Comments

There are a few old Capcom arcade titles – Pang, Cadillacs and Dinosaurs, and Block Block – that are unlike anything else ever seen in the world of coin-ops. They’re old, yes, but what makes these titles exceptional is the CPU they run on. The brains in the hardware of these games is a Kabuki, a Z80 CPU that had a few extra security features. why would Capcom produce such a thing? To combat bootleggers that would copy and reproduce arcade games without royalties going to the original publisher. It’s an interesting part of arcade history, but also a problem for curators: this security has killed a number of arcade machines, leading [Eduardo] to reverse engineering and document the Kabuki in full detail.

While the normal Z80 CPU had a pin specifically dedicated to refreshing DRAM, the Kabuki repurposed this pin for the security functions on the chip. With this pin low, the Kabuki was a standard Z80. When the pin was pulled high, it served as a power supply input for the security features. The security – just a few bits saved in memory – was battery backed, and once this battery was disconnected, the chip would fail, killing the game.

Plugging Kabuki into an old Amstrad CPC 6128 without the security pin pulled high allowed [Eduardo] to test all the Z80 instructions, and with that no surprises were found; the Kabuki is fully compatible with every other Z80 on the planet. Determining how Kabuki works with that special security pin pulled high is a more difficult task, but the Mame team has it nailed down.

The security system inside Kabuki works through a series of bitswaps, circular shifts, XORs, each translation different if the byte is an opcode or data. The process of encoding and decoding the security in Kabuki is well understood, but [Eduardo] had a few unanswered questions. What happens after Kabuki lost power and the memory contents – especially the bitswap, address, and XOR keys – vanished? How was the Kabuki programmed in the factory? Is it possible to reprogram these security keys, allowing one Kabuki to play games it wasn’t manufactured for?

[Eduardo] figured being able to encrypt new, valid code was the first step to running code encrypted with different keys. To test this theory, he wrote a simple ‘Hello World’ for the Capcom hardware that worked perfectly under Mame. While the demo worked perfectly under Mame, it didn’t work when burned onto a EPROM and put into real Capcom hardware.

That’s where this story ends, at least for the time being. The new, encrypted code is valid, Mame runs the encrypted code, but until [Eduardo] or someone else can figure out any additional configuration settings inside the Kabuki, this project is dead in the track. [Eduardo] will be back some time next week tearing the Kabuki apart again, trying to unravel the mysteries of what makes this processor work.