Xenoblade Chronicles-ゲームデータの解析

みなさんこんにちは！ 私の名前はArtyomです。タイロンでは、ばかげたニックネームTTEMMAでよく知られていますが、ポイントではありません。 私は、アマチュアグループの翻訳者であるRussian Studio Video 7の創設者の1人であり、このチームで唯一のromhacker-programmerです。



私のチームと私は、 任天堂ゲームキューブの2つの象徴的なゲーム、 バイオハザードリメイクとバイオハザードゼロの翻訳をバイオハザードファンに初めて提供しました。いつか私たちがどのようにそれをしたかについてお話しますが、このトピックでは、 任天堂Wiiの Xenoblade Chroniclesのような豪華なゲームと、このゲームのロムハックがどのように続いたか。 このゲームでは、すべてが日本のスタイルで行われ、奇妙であり、いくつかの点で「なぜ？」という質問を自問するだけです。しかし、あなたは日本人の奇妙な人々の数を覚えています。 さあ、始めましょうか？

まえがき

Xenoblade Chroniclesは、その価値があるゲームです。いや、 任天堂Wiiを購入する必要さえあります。 大規模なオープンワールドであるJRPG、多数の補助クエスト、そして数週間ではなく数ヶ月間ゲームの進行を遅らせるエキサイティングなストーリー。 任天堂Wiiに精通している人なら誰でも、コンソールはスーパーマリオなどの弱いカラフルなファミリーゲーム向けに設計されていることを知っていますが、 Monolith Softが作成したものは賞賛に値します。XenobladeChroniclesは、コンソールの技術的な制限（ Resident Evil RemakeとResident Evil Zeroのみがグラフィックに関して競合できます）。







チームでゲームを見て、私たちはそれを私たちの偉大で力強いものに翻訳する必要があると決めました。 しかし、ご存知のように、ゲームの技術的な要素を理解していなければ、翻訳を行う価値はありません。 次に、技術コンポーネントについて説明します。

技術的な詳細

Wii自体と、このトピックで何ができないかについて少しお話しします。



Nintendo GameCube 、 Nintendo WiiがPowerPCアーキテクチャーを備えたIBMプロセッサー上で実行されること。 このプロセッサはビッグエンディアンモードで動作します。これは覚えておくことが重要です（私にとっては、ビッグエンディアンファイルのハッキングはバイトオーダーのためにリトルエンディアンよりもはるかに便利です）。



幸いなことに、 任天堂はゲーム開発者を大事にし、SDKであらゆる目的のために膨大な数のフォーマットを提供しましたが、このトピックについて議論するのは彼らではありません。 後で詳しく説明するかもしれませんが、私の怠inessはそれを許しそうにありません。 私は任天堂のフォーマットから1つだけを選びたい-BRFNA（Binary Revolution Font）、これについてはさらに議論する。

フォント

Xenoblade Chronicles （以降XC）のフォントは標準で保存されますが、BRFNA拡張機能を備えたゲーム形式ではほとんど使用されません。



Wiiには 2つの標準フォント形式しかありません。

1. BRFNT（より一般的）
2. BRFNA（ほとんど使用されない）

それらの構造については詳しく説明しませんが、違いについてのみ説明します。

• エンコード情報（ansi、漢字、ヨーロッパなど）を格納する新しいブロックがBRFNAに追加されました
• BRFNAでは、シンボルを含むテクスチャは私には未知の形式で圧縮されますが、BRFNTでは、それらはクリアであり、簡単に編集できます。

BRFNAは多くの問題を引き起こしました。1つ目は未知のタイプの圧縮、もう1つはエンコーディングのわずかに奇妙な分離です。 奇妙なことに、 ニンテンドー 3DS SDKの公式フォントコンバーターがこの状況から私たちを救い出しました。 しかし、それにも問題がありました.XC自体で使用されているエンコーディングを調べ、テクスチャコンバーター用に個別の構成ファイルを作成し、コンバーター自体の設定を再生して、フォントが元のフォントと同じになるようにしなければなりませんでした。 ああ、数日苦しんだ後、UTF8のロシア文字コードを使ってロシア文字を推測することができました。







確かに、新しいフォントのサイズが原因でゲームが長時間停止し、ゲームのダウンロードの開始時にクラッシュしました。 最初は、曲がった手が何か間違ったことをしている疑いがありましたが、フォントからウムラウトを削除した後、ゲームは静かに始まりました。 しかし、私はウムラウトを明確に削除したくなかったので、反対側からアプローチしました.IA4（色ごとに4ビット、透明度に4ビット）からちょうどI4（色ごとに4ビット、透明度なし）に変更し、XCはダーリン。



テクスチャ形式を変更することにしたのはなぜですか？ できるから！ 正直なところ、これはキャラクターの品質を低下させることはありませんでした。 このゲームのキャラクター出力は、メインチャンネルをまったく使用せずにアルファチャンネルのみを出力するように機能しますが、透明度のないフォント形式を使用する場合、メインチャンネル以外に使用するものはありません。 不名誉、私は考え、そして場所を散らかさないように透明性なしですることにした。



この時点で、フォントを使用した作業が完了し、タスクのリストから削除されました。

PKB \ PKH-ファイルコンテナー

私はそれでまったく話を始めませんでした。 多くのメインファイルを取得するには、何らかの方法でそれらをPKBコンテナから抽出する必要があります。



PKBは単なるポインターであり、ポインター、サイズ、ファイル名はありません。 気付くのは、2048バイトに揃えられたファイルの束だけです。





最も興味深いのはPKHファイルに格納されていますが、それらにアクセスする必要があります。 すべてのPKHファイルは、static.arcと呼ばれる各U8言語の個別のアーカイブにあります。





PKHは、ファイルのサイズ、ポインター、およびインデックスを格納するPKBの非常に奇妙なマークアップです。 インデックスから、ゲーム自体が何らかの形で完全なファイル名を取得しますが、私はそれを処理しませんでした。 それはあまりにも退屈で無意味です。



このコンテナの構造を最後まで分解することはできませんでしたが、ファイルを抽出してパックするのに十分な勉強をしました。



PKHは、ヘッダーとエントリーという2つのブロックに分割できます。

public class pkhModuleEntry { public uint ID; public uint unk; public ushort sizeFile; public uint offsetFile; public pkhModuleEntry() { ID = unk = offsetFile = sizeFile = 0; } } public class pkhModule { uint Magic; uint version; uint tableOffset; uint pkhSize; uint countFiles; pkhModuleEntry[] entry; string[] extensions; ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

エントリーは、tableOffsetポインターから始まります。 ここでのみ問題は、エントリがいくつかのブロックに分割されていることです。ファイルに関するすべての情報のロードは次のように行われます。

 for (int i = 0; i < countFiles; i++) { entry[i] = new pkhModuleEntry(); entry[i].ID = mainPkhSfa.ReadUInt32(); entry[i].unk = mainPkhSfa.ReadUInt32(); } for (int i = 0; i < countFiles; i++) entry[i].sizeFile = mainPkhSfa.ReadUInt16(); for (int i = 0; i < countFiles; i++) entry[i].offsetFile = mainPkhSfa.ReadUInt32();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

上記のコードから、ファイルに関するすべての情報が3つのブロックに分割されていることがわかります。

1. ファイルインデックスと不明な値
2. ファイルサイズ
3. ファイルポインタ

特定のファイルへのポインターはuint32、つまり4バイト変数に格納されていますが、サイズは何らかの理由で2バイトになっていることがわかります。 上記のように、PKBファイルは2048バイトに揃えられているため、この欠陥について説明しますが、これには理由があります。 ファイルサイズはバイト単位ではなく、データブロックの量で示されます。 たとえば、ファイルサイズは0xCであるため、PKBのサイズは0xC * 0x800 = 0x6000になります。





この構造を研究した後、アンパッカー/パッカーはすぐにリベットで留められ、私はテキストを保存するコンテナの研究を始めました。

テキストコンテナ

いつものように、日本人は彼らのゲームで奇妙なことをしました。 ゲームコンテナの長い研究の後、ゲームテキストを含む3つの面が強調表示されました。

1. コンテナBDAT-いくつかのデータと行、優先度システム（メニュー、取引、設定）自体を保存します。
2. SBコンテナ-居住者との会話を含むスクリプトと行を保存します。
3. コンテナREV-カットシーンで使用されるデータとラインを保存します。

日本人は彼らの線に非常によく近づきましたが、私たちはこの事実をまったく好まなかった。

各コンテナで暗号化されるのは文字列のみです。暗号化アルゴリズムが1つだけ使用されている場合、これは問題になりません。 しかし、残念ながら、日本人は各コンテナで独自の暗号化アルゴリズムを開発することを決定しました。これにより、多くの問題が発生しました。



このトピックでは、BDATコンテナーとその暗号化アルゴリズムについてのみ説明します。SBコンテナーの暗号化については何も言いませんが、REVコンテナーの暗号化については何も言えません。 彼がハッキング中です。

BDATコンテナー

私をハッキングした最初のコンテナはBDATでした。 一見すると、彼がテキストを自分の中に保存していることを理解することは困難でした。 しかし、私たちは指でそれをしなかったので、すぐにこの形式についてグーグルに行きました。 このコンテナの構造に関するいくつかの情報が外国のフォーラムで見つかり、テキストがそこに保存されているという証拠が提供されました。 それを抽出するソフトウェアも見つかりましたが、何らかの理由で彼は私のファイルを食べませんでした。 外国のフォーラムを検索したところ、ゲームのバージョンにはオープンテキストが含まれていることがわかりましたが、ファイルには表示されません。 情報の流れとさまざまな仮定がすぐに私の頭に流れ込みましたが、1つだけが真実でした-日本人は暗号化され、暗号化されていました。 方法を理解するために残っていることが1つだけあります。



いくつかの操作の後、暗号化されたBDATと元のBDATを含むメモリダンプを手に入れ、これらのファイルを分析するプロセスが開始されました。 ファイルの比較に多くの時間を費やした後、暗号化を理解できませんでした。 私はパターンを見ませんでした、そして、デビューする唯一の方法がありました！



残念ながら、Dolphinにはくだらないデバッガがあります（または、うんざりして、デバッグに使用できるすべての機能があるPCSXデバッガに慣れました）。 私はメモリBDATのどの領域を復号化し、そこにbricを置くかを見つけなければなりませんでしたが、Dolphinはアドレスのコマンドにのみ、しかしoprからの読み取り/書き込みにブレークを置くことができました。 RAMはどのように認識していないか、これが問題になっています。 デバッグ用の追加機能を備えたDolphinの検索が始まり、1つが見つかりました-バージョン4に基づくDolphin DebugFastは、1つの機能のみを追加しました-RAM RAMの読み取り/書き込み、必要なものを考え、さらにハックに進みました。



私の記憶の中に必要なデータのセクションを見つけたので、私はレンガをセットアップし、ゲームがそのBDATを解読する方法を研究し始めました。 すべてがシンプルであると同時に興味深いものであることが判明しました。 BDATには2バイトのキーがあり、最初のバイトはR5レジスタにロードされ、2番目のバイトはR0にそれぞれロードされます。また、復号化の開始時に1（true）に設定されるブール変数もあります。



ブール変数が1に設定されている場合、レジスタR5を使用して復号化が行われ、0の場合、レジスタR0を使用して復号化が行われます。



暗号化は単純なXORに基づいており、復号化の順序は次のとおりです。

1. 暗号化されたバイト=暗号化されたバイト^ R（5または0）
2. R（5または0）=（暗号化されたバイト+ R（5または0））＆0xFF
3. ブール値を反対の値に変更します

C＃コード：

 public static void BDAT_DecryptPart(int offset, int size, ushort key, MemoryStream data) { data.Position = offset; int endOffset = offset + size; if (endOffset > data.Length) endOffset = (int)data.Length; bool reg = true; byte _r0 = (byte)(0xFF - (key & 0xFF)); byte _r5 = (byte)(0xFF - (key >> 8 & 0xFF)); byte inByte = 0; while (offset < endOffset) { inByte = data.GetBuffer()[offset]; if (reg) { data.GetBuffer()[offset] = (byte)(inByte ^ _r5); _r5 = (byte)((_r5 + inByte) & 0xFF); reg = false; } else { data.GetBuffer()[offset] = (byte)(inByte ^ _r0); _r0 = (byte)((_r0 + inByte) & 0xFF); reg = true; } offset += 1; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

暗号化は非常に興味深いように設計されており、次の各バイトは過去に依存しています。 さらに、復号化のためのリソースはほとんど消費されますが、デバッグなしではアルゴリズムの本質を理解することはできません。



暗号化が終了すると、BDAT自体の構造を理解し始めました。 文字列データを解読した後、ファイルの先頭で、いくつかのブロックの名前のように、いくつかの名前が認識されました。





しかし、私はこのブロックの分析を延期し、一般的な構造を扱うことにしました。 困難な分析により、ヘッダーが0x20バイトしか使用しないことが明らかになりました。その構造を以下に説明します。



これをすべて定義したので、深くは述べませんが、これらの各バイトの意味を簡単に説明します。

 class header { public uint magic; public byte mode; public byte unk; public ushort offsetToNameBlock; public ushort sizeTableStruct; public ushort unkTableOffset; public ushort unk2; public ushort offsetToMainData; public ushort countEntryMain; public ushort unk3; public ushort unk4; public ushort cryptKey; public uint offsetToStringBlock; public uint sizeStringBlock; ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

• マジックは一定であり、常にBDAT（ansi）と等しい
• モード-1：暗号化なし、3：暗号化
• unk-ご存知のように、不明ですが、このバイトは常にゼロです
• offsetToNameBlock-ブロック名を持つ暗号化されたブロックへのポインター
• sizeTableStruct-すべてのデータを含む1ブロックのサイズ
• unkTableOffset-最後まで解析できなかったテーブルへのポインタ
• unk2-不明ですが、常に0x3D
• offsetToMainData-すべてのデータを含むブロックへのポインター
• countEntryMain-offsetToMainDataポインターによるブロック数（MainDataブロックのサイズは次のように計算できます：sizeTableStruct * countEntryMain）
• unk3-不明、常に0x01
• unk4-不明、常に0x02
• cryptKey-2バイトの復号化キー
• offsetToStringBlock-テキストを含むブロックへのポインター
• sizeStringBlock-テキスト付きのブロックサイズ（テキストがない場合は0に等しい）

ヘッダーの後、不明なデータはoffsetToNameBlockに送られます。これは、MainDataのブロックに関するこの情報が次の構造を持っていることが判明したためです。

 class typeStruct { public byte unk; public byte type; public ushort idx; ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

• unk-不明
• type-データ型
• idx-MainDataのポインター（正確なポインターは、offsetToMainData +（IndexStructure * sizeTableStruct）+ idxのように計算されます

そして、最後のブロックは残りました-offsetToNameBlock、それは次の構造を持っています：

 class nameBlock { public string bdatName; public nameBlockEntry[] nameEntry; public nameBlock(StreamFunctionAdd sfa, int countName) { bdatName = sfa.ReadAnsiStringStopByte(); sfa.SeekValue(2); nameEntry = new nameBlockEntry[countName]; for (int i = 0; i < countName; i++) { nameEntry[i] = new nameBlockEntry(sfa); } } } class nameBlockEntry { public ushort offsetToStructType; public ushort unk; public string name; public typeStruct type; public nameBlockEntry(StreamFunctionAdd sfa) { offsetToStructType = sfa.ReadUInt16(); unk = sfa.ReadUInt16(); name = sfa.ReadAnsiStringStopByte(); type = new typeStruct(sfa, offsetToStructType); sfa.SeekValue(2); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私はヘッダーのどこにも見つからない変数countNameのみを選択したいのですが、NameBlock 0x20へのポインターを取得し、この数値を4で割ることで計算できます。理由は次のとおりです。ヘッダーは、構造ごとに4バイトかかるMainDataのブロックの構造に関する情報を受け取ります。 したがって、そのような構造の数を調べるには、構造に関する情報のみのサイズを知り、そのサイズで割る必要があります。つまり、4です。



一見複雑な構造に見えますが、別の方法で説明しようと思います。



すべてのデータが保存されるブロック-MainDataがあります。 このブロックはいくつかのブロックに分割され、その数は変数countEntryMainによって記述され、そのようなブロックのサイズは変数sizeTableStructによって記述されます。 ただし、そのような1つのブロックに格納されるデータは、typeStructクラスを使用して既に説明されています。typeStructクラスの数は1から複数までです。 typeStructごとに、nameBlockEntryに保存される名前があります。



それだけです、BDATは分解され、ソフトウェアはリッピングされて、正常に耕すテキストを抽出/置換しました。

おわりに

このトピックでは、伝説のWiiゲームの1つをハックして、ファイルをスカウトしないように日本人があらゆることをし続ける方法を紹介しました。



おそらく、このゲームではフォーマットの分析が継続されるでしょうが、これは正確ではありません。 私の記事が気に入ったら、 バイオハザードリメイクとバイオハザードゼロの翻訳についてお話します。



お時間をいただきありがとうございます！



PSこれはそのようなトピックに関する私の最初の記事です。スリッパを投げないでください。ただちにエラーを指摘する方が良いです。 彼は必要なものを完全に明らかにしなかったか、説明しなかったかもしれません。そのようなエラーが二度と起こらないように、これを示してください。