Desuiciding Capcom Arcade Boards

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.

35 thoughts on “Desuiciding Capcom Arcade Boards

        1. Ah, I see your sarcasm. So you won’t mind if I go swap my hard drive with yours? Who cares, it’s the same computer! Likewise, the Phoenix sets are directly causing people to intentionally kill their boards just to reburn the ROMs with Phoenix sets, which has the potential to destroy (and in practice, *has* destroyed) regions and revisions of CPS-2 games that have not yet had their contents backed up.

    1. Nope, what they have done is reverse engineer the system security chip taking care of encryption and be able to program it at will. What your link contains is the previous available method involving modified game code, essentially hand crafted unencrypted versions of the platform games.

    2. That’s a gnarly hack using a hardware mod and modified ROMs (and it’s not just a simple matter of decrypting them; if I remember correctly code and data accesses use completely different decryption keys but the two are intermingled in the same address space and ROMs, so someone has to go through and manually figure out what’s code and what’s data, and if they get it wrong stuff breaks). This allows you to simply reload the encryption keys and continue using the system with the original ROMs and no hardware mods, using the same programming port that Capcom themselves did. It’s far more elegant and easy to use, and if it’s anything like the Kabuki desuicide probably involved some seriously hardcore hacking.

    3. The use of Phoenix hacks should be discouraged as much as possible. By encouraging the use of Phoenix hacks, you’re engaging of hubris of the highest order, essentially saying “All of the CPS-2 games, ever, that could be and/or need to be dumped, have been dumped,” and that’s factually false.

      The presence of Phoenix sets has led to people destroying undumped revisions and localizations of CPS-2 games. So on behalf of everyone who cares about preserving digital history, your attitude is unwelcome.

  1. indeed, you could find non encrypted roms for other contries on the CPS 1.5 system.. i spent a couple of weeks ressurecting a “warriors of fate” about 10 years ago for those who remember the early gems..
    good to see the Z80S encryption key is finally known… cps3 games ?!

    regards

  2. COMMENT:
    this is really great to see, thank you so much, now i may get to play(edit save up for) these one day instead of visiting defunct units in museum.

    PS: after playing a couple hundred rounds of the game it may be best to include a low-battery warning, so this does not happen again. because battery mAh is not the worry here, it is solely shelf-life, assuming the RAM consumes negliegible current.

    RANT:
    if anyone tells you this is wrong, ask; when (you) agreed to original software license, did it specifically state this software was only legal as long as the battery stays up?

    if they knew of the game’s disability, but chose not to make any mention in the software EULA, then i see replacing the battery as legally identical to replacing the battery after it has gone dead… afterall, they did “forget” to include any legal mention of an expiry on the game’s playability.

    this is in steep contrast to the ill-defined and possibly grey area of using single-use digital cameras for “multiple film rolls”. Personally, i would re-use camera, but it’s worth mentioning that it was kinda intended for single-use, seeing as that’s what’s printed on the camera body (and possibly binary), making this a very bad choice of buisness ideas… selling used single-use cameras that are “reset” to factory-useability. (no mention of the environment, im assuming they get recycled?)

    1. I’m not particularly worried about whether the original EULA disclosed this security “feature”. What bothers me is that this great work may still be considered illegal since it circumvents a copy protection (IANAL: it could be this was built before DMCA so is excluded but I suspect this is still a legal danger zone).

      I think the methods used to build the security device, as well as those to reverse engineer it, need to be shared. This is a fascinating design that we all could never learn about without people spending a lot of time to unlock the secrets. As [Yay] said above, I love reading about this stuff!

    2. These cabs don’t have modern software EULAs, they were never intended to be sold to the end user market. They were intended for operators, AKA businesses, trying to make a living from kids shoving quarters into them. Your average arcade hopping teen isn’t going to give a flying fuck about a EULA and isn’t going to stand there and read it anyways.

      These particular cabinets did NOT have “serviceable” game boards. The game PCBs are encased in huge plastic boxes that are nothing more than glorified cartridges and have security screws and tamper stickers. The pin headers IIRC are triple row monsters. A shit ton of pins to desolder if they bent.

      IIRC the service manuals specifically mentions the security battery in the trouble shooting section. The company offered a service to return the dead boards for battery replacement and encryption key reset. It was not cheap as many unwitting buyers on eBay would later find out.

  3. Very cool! please excuse my lack of knowledge, but wouldn’t it be possible to read out the battery backed ram of an ‘alive’ board and then swap the drm-ram with a eeprom containing the keys?

    (yes, i understand that the achivement to previous hacks for this system is that you don’t have to change out chips/hardware, i am just curious)

    1. The RAM where the encryption keys are stored is actually inside the CPU.

      The CPU is a modified Z80 (Z80s?) that uses the /REFSH pin (normally an OUTPUT) as the supply for a 3.6v backup battery.

      Also the CPU worked as a perfectly normal Z80 if it didn’t have this voltage applied to the /REFSH pin.

      The /REFSH pin was used to indicate that the current address on the address bus could be used to Refresh Dynamic memories (DRAM). Newer technology of this era used static memory (SRAM) and didn’t need the /REFSH pin.

      1. Generally the refresh pin wasn’t needed because the DRAM refresh was done by external hardware, not because there was a switch to SRAM (which has always been far, far more expensive per bit.)

      2. Wrong, the CPU on the CPS-2 (which is what this hack is about) is a modified Motorola M68000. You’re thinking of the encrypted sound CPU on certain CPS-1 boards, Kabuki, which was in fact a modified Z80.

  4. Very cool! please excuse my lack of knowledge, but wouldn’t it be possible to read out the battery backed ram of an ‘alive’ board and then swap the drm-ram with a eeprom containing the keys?

    (yes, i understand that the achivement to previous hacks for this system is that you don’t have to change out chips/hardware, i am just curious)

    (sorry if this comment appears multiple times – i’m not sure if it worked before)

  5. I hate it when companies cut corners like this yes the encryption probably worked during the time these were sold but building a game that dies when the battery dies is not good business practice. I know technology like this was in it’s infancy but come on. This is akin to storing your OS on ram and if you don’t keep your laptop charged you lose all functionality.
    The only defence and a weak one at that is I don’t think the companies making these ever thought people would be using these in 20+ years time.

    1. It wasn’t about cutting corners. It was about reducing pirated games. Arcade cabinets are pricey and unscrupulous arcade operators had no qualms buying cheaper knock offs and clones and installing them on routes.

      Capcom had a program in place where operators were able to ship their dead boards back to them for a “nominal” service charge to replace the battery and reprogram the keys. I don’t recall the exact fees but I do recall it wasn’t necessarily cheap. People who picked up dead or unpopular games were often surprised at the expense.

      Capcom probably figured as long as these games made a profit, then operators would leave them powered on. If they powered them down and it died, operators would send them in for repairs. They didn’t give a rats ass about the home market or collectors, these cabs were never marketed to them.

      You have to remember that arcade cabs are geared towards businesses not your average Wal-Mart shopping schmuck. So the entire pricing structure and repair support is dramatically different.

      1. Cutting corners were probably the wrong words and yes they did have to protect the IP but what I meant was that it wasn’t a great way to secure the Roms because of the inevitable battery failure. I hate products that are designed with a “cut off date” even if it is far in the future. take for example the DS3231 Real time clock chip it is quite accurate counts leap years and dates up to the year 2100. I know this sounds like a distant time but why not make it go further? Sometimes things survive and wouldn’t it be cool if I designed a clock and my great great grand children discovered it in the attic? Only problem is that because the chip has a kill date it would be completely useless.
        This might seem stupid but I am a big fan of future proofing things for as long as possible and battery powered key storage just won’t stand the test of time.

        1. It’s not stupid. I subscribe to similar ideals.

          You just don’t seem to understand that your ideology is at direct odds with the business ideologies at force here. Capcom truly felt that people pirating or hacking their games were causing profit loss (SFII:Rainbow is one such example) so they migrated to using suicide batteries to combat this.

          Again, complaining that technology should last long enough for your grandkids to enjoy them is ignoring the very real market forces in place back then and now.

          Your DS3231 point is largely invalid. I spend enough time keeping just thirty year old technology alive, I doubt there would be too many 84 year old technology kicking around with its original dried out or leaking capacitors in 2100. Much less having any battery, internal or not, lasting that long.

          1. I understand that the DS3231 isn’t the best point but I hate the fact that it has a “death date” Yes the caps will be shot but then again they might not be (unlikely I know) but back to using batteries to store keys, Yes it was a business decision and it seemed to work at the time, but it means future generations have to hack their product to get it to function. Think of it like this you have the choice of buying two cars both the same only the ECU in one will only last 50 years because of a coding decision and the other one yes things could go wrong with it but it might last over 50 years, Would you not be bothered and buy the one with the death date?

          2. Jack, it’s not “seemed” to work. It _did_ work. It was absolutely intentional. Capcom did not use a readily available means to replace the battery. They added security screws and tamper evident tape. The internal hardwire pathways and game code depended on the encryption keys. The entire design was intentional from top to bottom.

            Capcom, Apple, and others like them DO NOT CARE about future generations using obsolete hardware. There is no money in it for them. When Capcom (or any other company) chooses to reissue a specific game, they’ll do it on whatever platform the market is clamoring for. Whether that’s a version on a game console with DLC or on Android with shitty controls. And those versions will receive whatever protections deemed appropriate to adress their concerns on piracy at that time.

            The majority of cars don’t last 50 years from any era. But I understand the point of the commemt. Cars with mega long life expectancies has gone the way of the dodo. A relic of a bygone era when fuel consumption and economics didn’t yet outweigh ease of repair and durability. The demands of the consumer market as a whole simply don’t allow for or even want cars lasting 50+ years on any level. Obama ran a “Cash for Junkers” program a few years back whose to destroy those cars before reaching their EOL and consumers gobbled it up like it was free crack.

            Do I think it’s right? IMHO, no, I dislike it. Is it the reality of our market? Yes. It’s a reality that has to be faced on it’s own merits, not yours. The reality is, whatever tech is around now, be prepared to, not just hack it, but maintain it if you want it around past the EOL.

        2. The battery powered volatile memory is intentional. It was designed so tampering or probing the security key is much harder since you can’t just power it off and back on again to restore to a known good state. It is easier to just add some battery backed RAM internally than to try to add Flash or EEPROM which generally requires special steps during production and you have to deal with the issues of the programming voltages needed. If you need to apply the voltages externally then expect people to hack it by not giving it sufficient Vpp so it can’t erase keys. If you want it internal then you’ll need to add charge pump circuitry to your IC.

    2. While I agree with what you say, I would like to point out that the life expectancy of the battery was far greater then the life expectancy of most of the tech things that people buy today.

    3. There are similar protection mechanism used in things like Satellite receivers and cable boxes. Part of the security of the Digicipher II encryption system works this way. In every Digicipher II satellite receiver is a lithium battery that powers a memory chip. That memory stores critical information like the Unit iD number and perhaps encryption keys also. If it ever dies the satellite receiver will no longer be usable for decryption and cannot even be authorized anymore since it will no longer have a valid ID..

  6. Flash memory retention is only around 50-100 years so all arduino hacks will evaporate even without a battery. Stark contrast to an old family rmuaket that is still safe to shoot with basic tender loving care.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s