GameBoy Advanceゲームをエミュレーションから保護する

2004年にリリースされたGame Boy Advanceの注目すべきゲームシリーズを覚えている人もいるかもしれません。 シンプルなラベルが付いたライトグレーのカートリッジは、マルチカラーのラベルが付いた通常のダークグレーのカートリッジとは大きく異なりました。 彼らは、元のニンテンドーエンターテイメントシステムから移植されたゲームを販売しました。 米国ではClassic NES Seriesとして知られているこれらのゲームは、いくつかの理由で興味深いものです。



GBAをエミュレートするという点で特に興味深いものです。 通常、Game Boy Advanceのゲームは非常に問題が多く、プラットフォーム自体にはクラッシュから保護するための多くの手段が含まれています。 したがって、ゲームを実行するには、エミュレーターが元の機器のエラーと互換性がある必要があります。 ただし、クラシックNESシリーズでは、開発者はさらに進んで、エミュレーターでの実行からゲームを保護しようとしました。







古いエミュレータのいずれかでプレイしようとした場合、おそらくゲームパックエラー画面が表示されました。 結局のところ、これらのゲームは、エミュレーションを複雑にするトリックと不定の動作を使用しています。 これは、そのようなゲームのコピーを保護するための意図的な試みであったようです。 正確なエミュレーションのために、これらのゲームで実行されるすべての異常なアクションを綿密に調査、実装、記録しました。

秘1：1：メモリのミラーリング

ゲームで使用される最初のトリックには、Game Boy Advanceのメモリ構造が含まれます。 GBAには「フラットな」（セグメント化されていない）メモリアドレス空間があります。 ただし、デバイスが現在メモリにアクセスする必要があるバスへのアドレス信号の上位8ビット。 00はBIOS、02はメインRAM、03はチップ上のRAMなどです。 ただし、上位8ビットのみがデバイスに信号を送り 、ほとんどのデバイスは非常に限られた（16 メビバイト未満）アドレス空間を持っているため、上位8ビットとデバイス内のアドレスを通知する下位ビットの間のビットには特定の目的はありません。



たとえば、メインRAMは256 KBです。 これは18ビットのアドレス空間に相当します。 したがって、このメモリ領域のアドレスは02000000〜0203FFFFの範囲であり、02040000〜02FFFFFFのすべてはアドレス指定されないままです。 通常のARMデバイスでは、無効なアドレスにアクセスするとデータアボートエラーが発生します。 ただし、GBAはデータダンプをサポートしていないため、この時点で何が起こっているかは特に興味深いものです。 上位8ビットがデバイスの選択に使用され、下位18ビットがデバイスのアドレス指定に使用されるため、中央に6個の未使用ビットがあります。 これらの未使用ビットは実際には無視されます。 つまり、メインRAMの実際のメモリ領域の上のデータにアクセスしようとすると、上位ビットが実際にマスクされ、有効なアドレスを持つ領域のみが残ります。 一部のエミュレータでは、このプロパティは「ミラー化」メモリと呼ばれます。



クラシックNESシリーズは、ミラーメモリでは特別なことは行いません。コードをメインRAMにコピーしてから、これらのミラーアドレスの1つに移動します。 このアクションは一部のエミュレーターを混乱させますが、メモリー領域の実装の特性により、mGBAで問題を引き起こすことはありません。 ただし、これは依然としてClassic NESで使用される最も簡単なトリックです。

トリック2：VRAMのコード

ゲームのさらなる作業は非常に興味深いです：ビデオメモリ（VRAM）にデータのコピーを開始しますが、これはそれ自体は完全に正常ですが、命令の実行はビデオメモリにコピーされたこのデータに転送されます：コードを通常グラフィックス用に予約されているRAM領域にコピーした後、そこで実行されます。 このゲームの動作を初めて見たとき、大きな間違いを犯したと思いました。 無効なアドレスにアクセスすることは、エミュレータの誤動作の典型的な症状です。 これは通常、実行可能アドレスまたはメモリにコピーするときに発生します。 しかし、詳細な調査の結果、ゲームにビデオメモリ内のコードを実行させると、クラッシュは発生せず、作業は比較的安定していることがわかりました。 その他の問題は残っていましたが、これがエミュレーションから保護するための戦術であることは明らかでした。 意図していない操作でビデオメモリを使用することは最初は混乱しましたが、ゲームにこの種の作業を許可すると、他の問題も発生しました。

秘3：3：DMAレジスタのSTM

次のトリックは、STM命令の非常に非標準的な使用です。 STM（「複数格納」、複数ストレージの略）は、中央処理装置の複数のレジスタをシリアルメモリにパックするように設計された命令のクラスです。 STM命令には、後続のデクリメント、予備のデクリメント、後続のインクリメント、予備のインクリメントの4種類があります。 「後続のデクリメント」という説明は、パックされるメモリの構造を指します。値は順番に保存され、各ワードが保存されるたびにアドレスはワードのサイズだけ減少します。 この操作は、メモリに降順で書き込むプロセスに似ています。 A、B、Cの値を保存すると、それらはCBAとしてメモリに書き込まれます。したがって、Aがソースアドレスであるため、Aから始めて、逆の順序で値を処理できます。



ただし、Martin Korthが書いたように、実際にプロセッサは最後のレジスタのアドレスがどこになるかを事前に計算し、デクリメントではなくインクリメントの場合と同じ順序で値を書き込みます。 そのため、結果としてCBAがメモリに格納されるという事実にもかかわらず、最初にCを書き込みます。エミュレータは、格納されるレジスタの数を事前に絶えず計算する必要があるため、作業が遅くなる可能性があります。 一般に、メモリへの書き込み順序は重要ではないように思われます。特に、メモリへの書き込みがアトミックであると見なされるシングルコアプロセッサの場合は重要ではありません。 メインRAMの場合、これは本当かもしれません。 （記録は1つの命令で実行されるため、DMA（ ダイレクトメモリアクセス ）は記録プロセスの途中でCPUを解放できません。）ただし、クラシックNESシリーズのゲームでは、1つの命令でDMAデータを転送するトリックが行われます。



DMAデータ転送は、ある領域から別の領域にメモリを効率的にコピーするために使用されます。多くの場合、ゲームパックからメインRAM、またはメインRAMからFIFOオーディオバッファにコピーされます。 メモリI / Oレジスタのフィールドには、DMAデータ送信を設定するための記録が可能な、DMAチャネルごとに3つの連続したレジスタがあります（合計4つのDMAチャネルがあります）。 通常、ゲームは2つの個別の32ビットエントリで送信元アドレスと宛先アドレスを示し、データ転送を開始して、DMAの数と制御ビットを記録します。または、1つの最後の32ビットエントリ、または制御レジスタの各半分に2つの16ビットエントリがあります。



しかし、クラシックNESシリーズのゲームははるかにスマートです。これら3つのレジスタはメモリに順次格納されるため、STMIAおよびSTMDA命令を使用して3つの値をすべて同時に記録します。 STMIAは最も単純なケースです。1つのレジスタに書き込み、インクリメント、次のレジスタに書き込み、インクリメント、制御レジスタに書き込み、インクリメント。 STMDAは少し異なります。デクリメントを実行するため、これを認識していないエミュレーターは制御ビットをアドレスに書き込むことができ、これが不正なDMAデータ送信につながります。 A、B、およびCはCBAとして書き込まれ、開始アドレスはアドレスAですが、Aは最後に書き込まれる必要があります。 書き込み可能なレジスタにハミングの重みを使用し、順序が正しく機能するようにレコードの開始オフセットを取得する必要がありました。 これらの操作を変更した後、機器の期待に応じて、データ転送が適切に実行され始めました。

秘4：4：保存タイプの非表示

しかし、トリックはそこで終わりませんでした。 次のトリックはそれほど難しくなく、他のゲームでも使用されています。 Game Boy Advanceカートリッジには、1つ以上の保持メカニズムを含めることができます。 一部のゲームは、バイトアドレッシングを備えたNVRAMの保存を使用します。 これらはメモリブロック0Eに存在し、正常に保存できます。 他のカートリッジは、同じ領域のフラッシュメモリを使用し、フラッシュメモリへのバイトの書き込みまたは再プログラミングのための領域の消去に標準プロトコルを使用します。 3番目のタイプはEEPROMで、ゲームパックメモリエリア（0Dエリア）の上部にあります。 DMAデータ転送を使用するビットレベルのプロトコルを使用して、プログラミングのために一連のビットをEEPROMに送信します。 ただし、各ゲームに保存できるのは1種類のみであり、カートリッジのタイトルには使用される種類が示されていません。 mGBAを含む一部のエミュレーターは、ゲームがそれらのいずれかと対話しようとするまで待機して、保存のタイプを判別しようとしています。 しかし、クラシックNESシリーズを含む一部のゲームでは、エミュレータをだまして間違ったタイプに最初にアクセスしようとします。 たとえば、これらのゲームはすべてEEPROMを使用していますが、SRAMを使用しているふりをしています。 SRAMに書き込んだと判断した場合、上記のGame Pak Error画面が表示されます。 このトリックは簡単に回避でき、エミュレータはゲームコードを事前にチェックします。 彼がClassic NESシリーズゲームに関連するコードを発見した場合、彼は強制的に保存タイプをEEPROMに変更します。

トリック5：プリフェッチ違反

これらのゲームの次のトリックは、私にとって見つけにくいものでした。 調査を完了するには数日かかり、その後、ベースエミュレーションサイクルにかなり低レベルの変更を加える必要がありました。 デバイスプロセッサには、パイプラインと呼ばれる命令を実行するためのマルチステッププロセスがあります。 各段階で、CPUの一部がビジネスで忙しく、他の部分が独自の段階を実行するように、個別のタスクが実行されます。 コンベアは、ある段階で命令を実行して次の段階に渡すと、後続の命令がすでに解放された段階をすぐに引き継ぐことができるように設計されています。 Game Boy Advance ARM7TMDIプロセッサには、正確なエミュレーションに必要な3つのステージがあります。サンプリング（命令）、デコード、実行です。 サンプリング段階で、メモリ要求が命令に関連付けられたメモリバスに送信されます。 次に、デコード段階に転送され、プロセッサはそれがどのような命令であるかを見つけます。 最後に、プロセッサが命令を実行します。 素朴な通訳者は、作業をスピードアップするために、または単にプロセッサの原理を知らないために、3つのステージすべてを組み合わせます。 最近まで、mGBAでは、デコードと実行のステップが組み合わされていました。 ただし、クラシックNESシリーズのゲームのコードを調べたときに、重要な発見が行われました。ゲームは実行ステージのすぐ近くで命令を変更しました。 これは、クラシックNESメトロイドビデオメモリから取得したアセンブラコードです。

06000260: E3A01000 mov r1, #0 06000264: E28FE008 add lr, pc, #8 06000268: E51F0010 ldr r0, [$06000260] 0600026C: E58E0000 str r0, [lr, #0] 06000270: E3A010FF mov r1, #255 06000274: E3A010FF mov r1, #255
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コードは非常に簡単です。 0をr1に保存してから、06000260の単語をr0にロードし、06000274に保存します。その後、255をr1に保存し、最後に...まあ、実際、少し嘘をつきました。 このアセンブリブロックの最後の命令は、前の2つの命令で保存されたアドレスと同じであることに注意してください。 このアドレスに格納されている値は、255ではなくr1に値0を格納する命令です。それで、このコードは何をしますか？ 答えは、コンベアの長さに依存します。



このコードブロックを理解する上で最も重要なことは、命令をパイプラインに渡した後、このアドレスを返すメモリの変更は適用できないことを認識することです。 これは、キャッシュの整合性の原則に似ていますが、さらに厳しいケースです。 これは、パイプラインが十分に長い場合、記録プロセス中にパイプラインに到達する命令は255を保存する命令になることを意味します。パイプラインが短すぎる場合、0を保存します。 、通常は255の値から始まります。これに気付いたので、mGBAでエミュレートされたパイプラインを拡張し、実行と選択の間にダミーのステージを挿入する必要がありました。 実際のARM7TDMIパイプラインでは、これら2つの手順の間にデコード手順があります。 しかし、私は仕様を注意深く読みませんでしたが、この段階が個別に実装されたことを理解していませんでした。 パイプラインの別のステージをクラシックNESシリーズインタープリターに追加した後、彼らは突然働き始めました！

秘66：サウンドFIFOバッファの不均一性

ただし、複雑な点が1つあります。ゲームをプレイできますが、音が絶望的に​​甘やかされました。 このソリューションには少しのデバッグが必要でしたが、このトリックはクラシックNESシリーズにも固有のものでした。したがって、仕様が完全に一致しないため、少し間違って実装されていました。 Game Boy Advanceには6つのオーディオチャンネルがあります：手続き的に生成された4つのサウンドチャンネル（元のGame Boyの機能的に拡張されたチャンネル）と2つのPCMオーディオチャンネル。 私が理解するように、クラシックNESシリーズのゲームは、PCMチャンネルの1つである1つのチャンネルのみを使用します。 PCMオーディオチャネルは小さな内部FIFOバッファーによって制御され、特定のポイントに到達するとDMAデータの送信を開始します。 ゲームは、各チャネルに関連付けられたI / Oレジスタに一度に32ビットを書き込むように設定します。 PCMチャンネルは8ビット幅しかないため、32ビット録音は実際には4サンプルです。 ただし、クラシックNESシリーズのゲームは少し異なります。レジスタ全体ではなく、一度に16ビットのみを半分で書き込みます。 ゲームでは一度に32ビットしか記録できないと想定していたため、エミュレータはゲームに必要な2つのサンプルと2つの空のサンプルを同時に記録することになりました。 このありふれた見落としは、ゲームの音を完全に歪めました。 簡単な修正を行った後、ゲームは正常に動作し始めました。

私たちは成功を収めましたが、なぜそのような困難なのですか

任天堂がNESの通常のゲームポートでこれをすべて行った理由はわかりません。 フル機能のNESエミュレーターは長い間存在しており、1997年に良い例が登場しました。 Classic NESシリーズのゲームは初めてポータブルコンソールでプレイできますが、他のポータブルデバイスでのGame Boy Advanceエミュレーションは数年前から使用されています。 さらに、リストした問題により一部のプロジェクトでエミュレーションが妨げられましたが、そのような保護はClassic NESシリーズでのみ使用されていました。 この特定のケースでエミュレーターの開発者に干渉するのになぜ彼らがそんなに努力をしたのかはわかりませんが、私にとっては、事態が本当に悪くなるまで、ゲームコード関数の一貫した分析が何晩も続きました。



ただし、これらの問題をすべて排除すると、ゲームは100％起動して動作します。 最新の修正はバージョン0.1.0で行われましたが、いくつかの大きな変更は後日まで延期されました。 ゲームは、リリース後のバージョン0.2.0で完全にサポートされ、ナイトリーリリースでプレイできるようになりました。