Daifukkat.su

NMK004 ROM Dumping, Part 2

This is post is a sequel to a previous post: http://daifukkat.su/blog/archives/2014/09/05/nmk004_rom_dumping_progress/

An interstitiary post now. I realize that I absolutely blew right through any background information and as a result that last post was probably gibberish to most people. A bit of explanation is in order then. Before continuing, I'd like to give thanks to all of the people who worked on the NMK004 simulation in MAME. Though this work could have been done without it, it definitely would have taken much much longer. I owe a great amount of gratitude to those contributors, especially Nicola Salmoria.

Title screen of Black Heart

First off, this short project's goal is to dump the internal ROM of a protected sound CPU used on many arcade PCBs made by NMK. This sound CPU is labeled NMK004, and is a TLCS-90 CPU -- essentially a Z80 on 16-bit steroids -- with an internal code ROM, and some other stuff that doesn't matter much. The internal code ROM has never been dumped, and as a result, any attempt to emulate these games has resulted in either poor sound emulation due to incomplete/wrong simulation of the behavior of the NMK004, or none due to not bothering to simulate the chip at all.

A quick list of games that utilize this sound CPU:

• USAAF Mustang
• Uchuu Senkan Gomorrah (Bio-ship Paladin)
• Vandyke
• Black Heart
• Acrobat Mission
• Koutetsu Yousai Strahl
• Thunder Dragon
• Hacha Mecha Fighter
• Choujikuu Yousai Macross
• GunNail

These games all use the same sound setup: two OKI MSM6295s (simple 4 channel ADPCM playback chips) and one Yamaha YM2203 (3 channel FM sound chip with 3 channel PSG built in, first entry in the OPN sound chip family). They also have an external EPROM used to hold the song data for each game. Different games have completely different contents here, because they have different music. An important note, and the very feature that allows my hack to work, is that the ROM's data layout is flexible. There is a header (well, footer) located at 0xEFE0 in the external ROM. This header contains pointers to a bunch of tables, containing information for music playback. These pointers point at direct addresses, so they are not transformed at all before being used.

This alone wouldn't have been enough. It would have been possible to prevent this attack in a few ways, but there didn't seem to be any attempts to secure the MCU's code. The external ROM is on the same address space as the internal ROM. The external ROM is also in an "overlay" configuration, meaning that when it's being accessed, the address is not transformed before being sent to the device. This means that I can set the pointers to point into the internal ROM instead of the external ROM with absolutely no problem. This simple attack could have been defeated if they had merely checked the bounds of the pointer before using it, but they must have felt content with just having locked down internal ROM. Admittedly, their solution worked quite well, since as far as I'm aware, there were no bootlegs of the hardware that didn't just replace the sound section wholesale or weren't just conversions of other games.

I said last post that I'd give a breakdown of the functioning of my hacks in this post, but I don't think it's time for a full breakdown yet. Instead, here's a breakdown of the contents of that external ROM, the vulnerabilities that it affords, and the pros and cons of each table to be used for an attack. Most of this information comes directly from my notes, or has been slightly modified to make it more understandable to an outsider.

Title screen of USAAF Mustang

• Sample tables for the MSM6295s.
  • Not very usable...
• Modulation tables for the OPN's FM.
  • Can dump 8 bits a time (16 bits if careful).
  • Tricky to use.
  • Has a HUGE range of entries each ROM.
  • Can be accidentally interrupted by specific values...
  • Probably not usable...
• Note frequency table for the OPN's FM.
  • Dumps 16 bits at a time.
  • Only has a range of 16 entries each ROM.
• Note frequency table for the OPN's PSG.
  • Dumps 12 bits at a time, needs two passes to get both bytes.
  • Only has a range of 16 entries each ROM.
• Volume envelope tables for the OPN's PSG.
  • Dumps 4bits (volume value) + 8bits (volume length) at a time.
  • Can extract length from the data...
    • Length 0 and 1 are the same, but we can work around this.
  • Has a large range of entries per ROM I think.
  • Might take a bit, but being 8bit lengths, shouldn't be too crazy.
• Shared note length table for the MSM6295s, and OPN's FM and PSG.
  • Dumps 16 bits at a time.
  • Has a range of 128 entries each ROM.
  • Can take FOREVER.
• Two sub-timer tables of mostly unknown usage.
  • Unknown what these really do, so not too helpful.
• Command tables for controlling the actual sequencing.
  • Obviously no good.

I think that should cover everything that I missed, and hopefully explains most of what needs to be explained. The next post should have more in-depth information on the trojan, and maybe the dump. We'll see.