(WIP) NMK004 sound CPU.... - 模擬器

2014.09.07

搞定了！！！

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.

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.


來源：http://daifukkat.su/blog/

--
另外，滿貫財神的聲音修復也有明顯進展：
http://player.youku.com/player.php/sid/XNzc3MTQ2MDA0/v.swf　（優酷連結）

--
ポーラステーション
http://perry0517a.blogspot.tw/

--