NESゲーム「Jackal」のレベルマップの形式の調査

この記事では、NESゲームのレベルでデータを検索する非標準的な方法について説明します。画像内のすべてのデータを順次変更し、その結果（romhackersの「破損」）を調べます。 例として、NESのJackalゲームでレベルデータを検索し、そのレベルの1つをCadEditorエディターに追加する方法を示します。 この方法を使用すると、X8502アセンブラーの知識がなくても、 ブロックレベル構造 （NESのほぼすべてのゲーム）のゲームを探索できます。スクリプト言語（ LuaおよびPython ）を操作するための初期スキルのみが必要です。

理論

このメソッドのアイデアは、ゲーム内のすべてのバイトを一度に1つずつ変更し、それらのいずれかが外部的にレベルを変更したかどうかを確認することです。 これを自分の手で行うには非常に長い時間がかかるため、補助ツール、つまりFCEUXエミュレータに組み込まれたLuaスクリプト言語を使用する必要があります。その機能と制限については以下で説明します。



さらに、結果を確認するプロセスには多少の困難が伴います。変更されたROMイメージをエミュレーターにロードしてから、ゲームを最初のレベルの起動ポイントに移動する必要があります。 さらに、レベルの開始直後に元のイメージで作成された既製のエミュレーター保存を単にロードすることは不可能です-イメージのデータはすでにビデオメモリとRAMに移動し、最初のレベルの画面は変更されないままであり、元のイメージと視覚的に区別することはできません。 したがって、FCEUXエミュレーターですべてのキーストロークの繰り返しを記録する必要があります。FCEUXエミュレーターは、ゲームを開始画面からレベルの開始まで導きます（これは、[ ファイル ]- > [ムービー ]- > [ムービーを記録... ]メニューを使用して行われます）。瞬間負荷レベル。 レベルの開始前に、ゲームのメインメニューの[開始 ]ボタンを押した後、画面上の画像が数秒間暗くなり、その時点でレベルの最初のゲーム画面が作成されます。



適切な時間に保存するには、時間を数回遅くすることができます（メニューNES->エミュレーション速度->速度ダウン ）、 Config-> Map Hotkeysメニューでホットキーを設定して、キーボードからゲームを簡単に加速/減速することをお勧めします 画面が暗くなるのを待ち、この時点で（ゲーム画面が表示されるまで）、ゲームを保存します（たとえば、 Shift + F1キーの組み合わせを使用して、スロット1に）。 さらに作業を進めるには、保存が行われたフレームとゲーム画面が表示されたフレームを検出する必要があります（メニュー項目Config-> Display-> Frame Counterを使用して、画面上の現在のフレームフレームの表示を有効にできます）。 これは、以前に黒い画面を削除しないように、既に作成されているレベル画面のスクリーンショットを撮るために必要になります。



スクリーンショットでは、フレーム454と560の間の瞬間にレベルデータが画像からメモリにロードされます。



したがって、レベルデータを検索するアルゴリズムは次のようになります。

1. エミュレータで変更されたROMを実行します
2. 事前に準備されたストレージを元のROMイメージにロードします（イメージのデータをビデオメモリにロードして、画面のレベルを変更するとき）。
3. 測定されたフレーム数を待っています（これにより、画面に画像が表示された瞬間にフレームカウンターの値を見つけました）。
4. スクリーンショットを撮ります。
5. 変更されたROMイメージの次のバージョンに対してプロセスを繰り返します。
6. 撮影されたスクリーンショットを分析します（撮影されたスクリーンショットの名前では、変更されたバイトのアドレスを示す必要があるため、どの変更がスクリーン上のデータが変更されたという事実につながったかが明確です）。

ほとんどの場合、画面上の画像は変更されず、まったく変更されないこともあります。ROM画像の一部のバージョンでは、ゲームコードが必然的に壊れ、画面にタイルの奇妙な混乱が生じることがあるため、最終的な目標は画面が変更されるバージョンを見つけることですマクロブロックは1つだけです（NESのレベル画面はマクロブロックで構成されています）。 このようなスクリーンショットが見つかると、画面を説明するブロック番号の配列が保存されているアドレスが明確になります。



エミュレータに組み込まれたLua言語を使用すると、プロセッサのメモリとレジスタを操作できますが、既にロードされているROMカートリッジイメージで動作するように設計されているため、ROMイメージの変更バージョンをロードしたり、ロード後にイメージ自体を変更したりすることはできませんが、使用することはできますアルゴリズムのステップ2、3、4を実装します。



自動腐敗の最初のバージョンの残りの部分は、Python言語を使用することにしました。 ただし、そのバージョンにはいくつかの重大な欠点がありました-生成された数千のROMイメージは多くのスペースを占有し、エミュレータはコマンドラインから別のアプリケーションとして常に起動され、閉じられていたため、それにフォーカスが切り替えられたため、実行中のスクリプトでマシンで作業するのは不便でしたが、作業中に閉じます。 そのため、この記事では、エミュレータから直接ROMイメージ内のバイトを変更するために、必要な機能をLuaモジュールに追加することにしました。

工具製作

幸いなことに、FCEUXエミュレーターのソースコードが利用できるため、ソースをダウンロードして変更を追加できます。



ROMイメージからバイトを読み取る関数（ fceu.cpp 、関数FCEU_ReadRomByte ）を見つけ、書き込み用に同じバージョンを追加します。

//新しい

void FCEU_WriteRomByte （ uint32 i、 uint8 value ）

{

if （ i < 16 + PRGsize [ 0 ] ） PRGptr [ 0 ] [ i - 16 ] = value ;

else if （ i < 16 + PRGsize [ 0 ] + CHRsize [ 0 ] ） CHRptr [ 0 ] [ i - 16 - PRGsize [ 0 ] ] = value ;

}

次に、この関数をLua（ファイルlua_engine.cpp ）から呼び出す機能を「転送」します。

static int rom_writebyte （ lua_State * L ）

{

FCEU_WriteRomByte （ luaL_checkinteger （ L、 1 ） 、luaL_checkinteger （ L、 2 ） ）

1を 返し ます。

}



static const struct luaL_reg romlib [ ] = {

{ "readbyte" 、rom_readbyte } 、

{ "readbytesigned" 、rom_readbytesigned } 、

//署名なしの代替命名スキーム

{ "readbyteunsigned" 、rom_readbyte } 、

{ "writebyte" 、rom_writebyte } 、 //新しい関数

{ "gethash" 、rom_gethash } 、

{ NULL 、 NULL }

} ;

したがって、スクリプトからデータのバイトを変更する機会を得て、数千の異なるバージョンのROMイメージを作成してロードする必要性を取り除きました。



次のステップは、スクリーンショットを保存する前に分析するようLuaに教えることです。 これを行うには、 gui.savescreenshot（）関数を使用してスクリーンショットを標準ファイルに保存する代わりに、 gui.gdscreenshot（）関数を使用してメモリに残し、同じスクリーンショットが既に取得されているかどうかを確認します（これには、すでに取得されたすべてのスクリーンショットのハッシュを保存する必要があります）、一意のディスクのみに保存します。 これにより、1バイトを変更してもゲームの最初の画面に影響を与えなかった何千もの同一のスクリーンショットを保存できなくなります。

スクリーンショットを保存するために、 gdライブラリを使用しました（ ここでコンパイル済みバージョンを入手するか、ソースから自分でコンパイルできます）。解凍されたファイルは、エミュレーターがビルドされたフォルダーに入れる必要があります。 ハッシュを計算するために、ちょっとしたトリックを使用しました-エミュレーター自体から計算関数を投げました（ROMイメージのチェックサムの計算に使用されました）：

// lua_engine.cppファイル

static int calchash （ lua_State * L ） {

const char * buffer = luaL_checkstring （ L、 1 ） ;

intサイズ= luaL_checkinteger （ L、 2 ） ;

int hash = CalcCRC32 （ 0 、 （ uint8 * ）バッファー、サイズ） ;

lua_pushinteger （ L、ハッシュ） ;

1を 返し ます。

}



static const struct luaL_reg emulib [ ] = {

//コードの一部が欠落しています

// ...

{ "readonly" 、movie_getreadonly } 、

{ "setreadonly" 、movie_setreadonly } 、

{ "print" 、print } 、 //確かに、なぜ

{ "calchash" 、calchash } 、

{ NULL 、 NULL }

} ;

破損したスクリプトとその使用

これで準備作業がようやく完了し、イメージ破損のLuaスクリプトを作成できます（行末のコメントが完全に表示されない場合は、githubでコメント付きスクリプトを確認できます。記事の最後にリンクがあります）。

-gdライブラリをダウンロードします

「gd」が 必要



-破損の初期アドレス（ROMイメージヘッダーから直接）

START_ADDR = 0x10

-破損の終了アドレス（カートリッジが作成されたマッパーに応じて、ファイルサイズを簡単に設定できます）

END_ADDR = 0x20010

CUR_ADDR = START_ADDR

-最終的なフレーム番号。その後、スクリーンショットを撮る必要があります（プレーヤーのゲーム画面が既に表示されている場合、作成されたセーブの数が測定されます）

FRAME_FOR_SCREEN = 7035

-ゲームバイトの代わりに書き込まれるテスト値

WRITE_VALUE = 0x33

-検索時間を節約するための修正が実行されるステップ

-（画面上の各バイトを変更する必要はありません。多数のマクロブロックを画面に表示できます。少なくとも1つを検出すれば十分です）。

ステップ= 8



-すべての一意のスクリーンショットのハッシュを保存するためのテーブル

shas = { }



-後で復元するために、破損によって破損する値をリモート

lastValue = rom 。 readbyte （ START_ADDR ）

-事前に準備されたストレージを最初のスロットからロードします（エミュレーターのスロットの番号は0から始まり、Luaでは1から始まります）。

s = savestate 。 作成（ 2 ）

savestate 。 負荷（ s ）



while （ true ） do

-画面がロードされ、すでに表示されている場合

if （ emu。framecount （ ） > FRAME_FOR_SCREEN ） then

-スクリーンショットをメモリに保存

ローカル gdStr = gui 。 gdscreenshot （ ） ;

-ハッシュを計算する

ローカルハッシュ= emu calchash （ gdStr 、 string.len （ gdStr ） ） ;

-スクリーンショットがまだない場合

if （ shas [ hash ] ）で は ない 場合

print （ "Found new screen" .. tostring （ hash ） ） ;

local fname = string.format （ "％05X" 、 CUR_ADDR ） .. ".png" ;

ローカル gdImg = gd createFromGdStr （ gdStr ） ;

-変更されたバイトの名前にアドレスを付けてスクリーンショットをディスクに保存します

gdImg ： png （ fname ）

shas [ハッシュ] = true ;

終わり ;

-前のバイト値を復元する

rom 。 writebyte （ CUR_ADDR 、 lastValue ） ;

CUR_ADDR = CUR_ADDR + STEP ;

-次のバイトの破損

lastValue = rom 。 readbyte （ CUR_ADDR ） ;

rom 。 writebyte （ CUR_ADDR 、 WRITE_VALUE ） ;

-再びセーブをロードして、ゲームが新しいイメージからメモリにデータをロードできるようにします

s = savestate 。 作成（ 2 ）

-進行状況の表示

savestate 。 負荷（ s ）

gui 。 text （ 20、20 、 string.format （ "％05X" 、 CUR_ADDR ） ） ;

-すべてのアドレスが処理されたら、エミュレーターを停止します

if （ CUR_ADDR > END_ADDR ） then

エミュー 一時停止（ ） ;

終わり

終わり ;

-次のフレームまでエミュレーションをラップする

エミュー frameadvance （ ） ;

終わり ;

スクリプトでエミュレータを実行するには、次のコンテンツのバッチファイルを使用できます。

fceux -turbo 1 -lua破損.lua「ジャッカル（U）[！]。nes」

（ ターボキーを使用すると、エミュレータを最も高速なモードで起動できます）。



私のマシンのスクリプトは、すべてのデータを8分で処理します。 動作時間が長すぎる場合は、 STEPステップを画面ごとに最大64まで大きくして、ゲームをより正確にすることができます。この場合、起動フレームとスクリーンショットを撮りたいフレームの間の時間は最小限になります。

さまざまなゲーム用のスクリプトを設定するためのいくつかの推奨事項：画面上のデータは、多くの場合、銀行の先頭（ 0x2000または0x4000の倍数のアドレス）から始まるため、これらのゾーンを詳細に調べることができます。 ROMイメージにビデオバンク（ CHR-ROM ）がある場合、ビデオメモリのみを保存するため、調査することはできません。 ビデオバンクは常にROMイメージの最後にあり、その番号はヘッダー（ROMイメージの最初の16バイト）でも確認できます。



ゲーム "Jackal"の場合、スクリプトは235のユニークなスクリーンショットを見つけます。これらのスクリーンショットは、さまざまなグラフィックの不具合を幅広く示しています。 ただし、アドレス0x105C8、0x105D8、0x105E8で変更されたバイトを持つ画像から取得したスクリーンショットは興味深いものです。



それらから、それは明らかです：

• ゲームは2x2ブロックサイズのマクロブロックシステム（4x4タイル）を使用します。
• 画面は、16マクロブロック幅の行（2つの隣接するアドレスの違い）で記述されます。
• 行は、下から上の順にROMイメージに保存されます。

受信したデータで何ができますか？ たとえば、レベルのすべてのマクロブロックの写真を準備し、 CadEditorブロックエディターでそれらを使用してレベルマップエディターを作成します。



これを行うには、スクリプトスクリプトを少し書き直して、可能性のあるすべてのバイト値をアドレスに書き込みます。これにより、画面上のブロック（たとえば、 0x105C8 ）が変更され、すべてのブロックのスクリーンショットが撮られます。 スクリプトの全文は提供しません。記事の最後にあるサンプルアーカイブ（ corrupt_byte.lu a ）にあります。 残念ながら、 gdライブラリは画像の一部を便利に処理することを目的としていないため、スクリーンショットからマクロブロック画像を「噛んで」、1つの長い「テープ」にまとめるために、別のPythonスクリプトを作成する必要がありました（ PILライブラリを画像処理用にインストールします）：

＃-*-コーディング：utf-8-*-

インポート画像

def cutBlock （ pp ） ：

im =イメージ。 オープン （ pp ）

＃任意の画像エディターにスクリーンショットをアップロードして、ブロックの先頭の座標を確認します

X = 96

Y = 96

＃スクリーンショットから指定された座標でブロックを切り取ります

imCut = im。 crop （ （ X 、 Y 、 X + 32 、 Y + 32 ） ）

imCut。 保存 （ "_" + pp ）



xrange 内の x （ 256 ） ：

cutBlock （ r "％03d.png" ％x ）



BLOCK_COUNT = 102

MAX_BLOCK_COUNT = 256

imBig =イメージ。 新規 （ "RGB" 、 （ 32 * MAX_BLOCK_COUNT 、 32 ） ）

xrange 内の x （ BLOCK_COUNT ） ：

im =イメージ。 オープン （ "_％03d.png" ％x ）

imBig。 貼り付け （ im 、 （ 32 * x 、 0、32 * x + 32、32 ） ）

＃CadEditorで使用するための要件であるマクロブロックサイズを64x64に増加

imBig64 = imBig。 サイズ変更 （ （ MAX_BLOCK_COUNT * 64、64 ） ）

imBig64。 保存 （ "outStrip.png" ）

レベルエディターにゲームを追加する

最後の部分は残ります-CadEditorエディターの構成ファイルを作成する必要があります。これは、結果のイメージを使用します。 C＃をスクリプト言語として使用します（ CSScriptライブラリを使用）。

スクリーンショットによれば、マクロブロックマップの行の先頭を計算します。アドレス0x105C8が行の4番目のマクロブロックを変更する場合、アドレス0x105C5が最初のを担当します。 次に、テンプレート構成を作成します。

CadEditor を使用し ます 。

System を使用し ます 。

System.Collections.Generic を使用し ます。

System.Drawing を使用し ます。



パブリック クラスデータ

{

/ *行の境界を上下に交互にシフトして、正しいアドレスを計算します

「ウィンドウ」に正しい「レベルマップ」が表示されるまで。

開始アドレス0x10625から、96行上に後退します。

1-レベルごとのゲーム画面の数、

16 * 96-1ゲーム画面のバイト単位のサイズ

* /

public OffsetRec getScreensOffset （ ） { 新しい OffsetRec （ 0x10625-16 * 96、1、16 * 96 ）を 返し ます。 }

public int getScreenWidth （ ） { 16を 返す ; } //画面の幅を設定する

public int getScreenHeight （ ） { return 96 ; } //画面の高さを設定する

public int getBigBlocksCount （ ） { 256を 返す ; }

//ストリップをマクロブロック画像に接続します

public string getBlocksFilename （ ） { return "jackal_1.png" ; }



//このゲームに実装されていないマクロブロックと敵のサブエディターをオフにします

public bool isBigBlockEditorEnabled （ ） { falseを返す ; }

public bool isBlockEditorEnabled （ ） { falseを返す ; }

public bool isEnemyEditorEnabled （ ） { falseを返す ; }

}

このような構成でエディターにロードされたレベルマップは奇妙に見えますが、実際のレベルマップに似ています。





結果を調べた後、16x8マクロブロックのサイズの画面の行は下から上に順番に格納されますが、画面自体は上から下に格納されます。つまり、画面の8行ごとに再配置されます。 幸いなことに、エディターには、イメージからROMレベルをロードする方法を指定できる多数のメソッドがあります。 この場合、マクロブロック番号がカードから正確に読み取られる方法と、それに応じてエディターによって書き戻される方法を制御する2つの特別な機能を設定する必要があります。

//特別な関数を使用してマクロブロック番号を取得するようエディターに指示します

//マップして記録します

public GetBigTileNoFromScreenFunc getBigTileNoFromScreenFunc （ ） { return getBigTileNoFromScreen ; }

public SetBigTileToScreenFunc setBigTileToScreenFunc （ ） { setBigTileToScreenを返す; }



public int getBigTileNoFromScreen （ int [ ] screenData、 int index ）

{

int w = getScreenWidth （ ） ;

int noY = index / w ;

noY = （ noY / 8 ） * 8 + 7- （ noY ％ 8 ） ; //マクロブロックのY座標の変換

int noX =インデックス％ w ;

return screenData [ noY * w + noX ] ;

}



public void setBigTileToScreen （ int [ ] screenData、 int index、 int value ）

{

int w = getScreenWidth （ ） ;

int noY = index / w ;

noY = （ noY / 8 ） * 8 + 7- （ noY ％ 8 ） ; //マクロブロックのY座標の変換

int noX =インデックス％ w ;

screenData [ noY * w + noX ] = value ;

}

これでマップが正しく表示され、レベルジオメトリを再描画できます。





検索方法は、ほぼすべてのNESゲームに適用できます。アーカイブのスクリプトを使用して、お気に入りのゲームを学習することができます。



さらに、いくつかの変更を加えると、この方法は「Sega Mega Drive」および「SNES」プラットフォームにも適用できます（変更する必要があるのはROMイメージ自体ではなく、コンソールのRAM、多くの場合、展開されていないレベルカードが格納されることです）



次の記事では、ゲームの例として、ゲームロジックデバイスと、ゲームオブジェクトを検索してマップ上に表示および配置する方法を示します。



参照：

例付きのアーカイブ

コメント付きスクリプト