スターウォーズのリバースエンジニアリング：依田物語

[注 レーン：ZachtronicsのZach Bartは、素晴らしいビデオパズルゲーム（SpaceChem、TIS-100、SHENZHEN I / O）を作成し、 電子スクイーカーをアップグレードするだけでなく、古いゲームのリバースエンジニアリングリソースも楽しんでいます。 この記事は、彼の子供時代のお気に入りのゲームをハッキングすることに成功しています。]

まえがき

理由はわかりませんが、コンピューターゲームデータファイルのリバースエンジニアリングに常に惹かれていました。 ゲームコードの逆コンパイルは困難な作業であり、データファイルの分析は多くの場合より簡単です（テキストやスプライトなどの明確に見えるコンテンツが多く含まれているため）。ファイルを十分に理解していれば、ゲームを変更できます。



Star Wars：Empire at Warデモのリリースから数日後の2006年、ゲームデータファイルのダンプと再パックを可能にするいくつかの基本的なツールを公開しました。デモで）。 私は自分の作品の痕跡をネット上で見つけることはほとんどできませんが、ゲームペトログリフの開発者のために無料のTシャツを手に入れることができました。これは何かです。



何年も前に、 Star Wars：Yoda Storiesと呼ばれる別のStar Warsゲームがありました。 彼女はかなり混乱し、悪い評価を受けましたが、それは私を止めませんでした。 初心者プログラマーであり、頑固なスターウォーズのファンとして、私は自分のひどいスターウォーズゲームを作るためのゲームリソースを見つけようとしました。 ただし、デスクトップテーマアイコンとして配布されたサウンドエフェクトと少数のスプライトのみを検出できました。









16年にさかのぼります。1990年代のテーマでコンピューターパーティーでプレイできる古いゲームを探して、CDの古代のコレクションを研究しています。 CDをドライブに挿入すると、サイズが約4メガバイトのデータファイルが見つかったことにすぐに気付き、大学でハッキングのために知識が使用されるのを待っていました。 決して後よりも良い！

ファイル構造（難易度：パダワン）

同様の何かをリバースエンジニアリングするには16進エディタで十分だと思いますが、後でデコンパイラ、計算機、対応するプログラムの知識を使用します。 私はHxDの大ファンなので、このエディターを使用します。



自分で実験したい場合は、ゲームデータファイルへのリンクを以下に示します： YODESK.DTA



このファイルを開く時間です！









したがって、これは間違いなくテキストではなく、人間が読むことを意図したものではありませんが、まったく驚くことではありません。 16年前、同じファイルをメモ帳で開いてすぐに閉じたのは確かでした。



最初に、セクション識別子のように思える4文字のASCII文字が表示されます。 以下に、SNDS、TILE、CHAR、PUZ2などの確認が表示されます。 ファイルはENDFセクションで終了します。これは、ファイルの一般的な構造が、ラベルのあるセクションの階層またはセクションのリストであることを意味します。



VERS識別子は、明らかに「バージョン」セクションで始まり、次の4バイトが含まれます：0x00、0x02、0x00、0x00。 Yoda Storiesは同じエンジンを使用していると思われるIndiana Jonesゲームの後に登場したため、これはファイル形式のバージョン2.0であると思われます。 ただし、このデータにはあまり関心がないため、これは特に重要ではありません。



次に、STUP（セットアップ？）セクションがあります。このセクションには、多くの暗号データ​​が含まれています。









明らかに、ここには何らかのパターンがありますが、ゲームの詳細な知識がなければ、その目的を理解できません。 次の質問は私にとってより重要なようです：それをスキップする方法？ このセクションは固定長であると想定できますが、実際にはそうではありません。



セクションの先頭（前のスクリーンショット）をもう一度見ると、STUP識別子の後に4つの疑わしいバイトが続くことがわかります：0x00、0x44、0x01、0x00。 この4バイトの後にこのセクションに残っているデータを確認すると、それらの長さが正確に0x00014400バイトであることがわかります。 偶然？ そうは思いません！



明らかに、これらの4バイトは、STUPセクションの残りを構成するデータの量を示す符号なし32ビット整数です。 バイトが逆の順序で書き込まれているように思える場合、あなたは正しいです：最下位バイトが最初に格納されている最下位から最も古い（リトルエンディアン）の順に格納されます-x86およびx86-64プロセッサの一般的な方法 長さの値を考慮すると、セクションに格納されているデータについて何も知らなくても、残りのセクションをスキップできます。



わずか4 MBのサイズのバイナリファイルを手動で読み取ることは、あまり生産的な作業方法ではないため、ファイルの解析および/またはデータダンプをエンコードする方法を見つけるプロセスでダンプするプログラムで作業を開始する時が来ました。 私はC＃プログラミング言語を好むので、それを使用します。 ファイル形式が完全に混乱していないと仮定すると、かなり詳細なBinaryReaderクラスを作成して開始できます。 これまでに準備したプログラムは次のとおりです。

static void Main(string[] args) { using (BinaryReader binaryReader = new BinaryReader(File.OpenRead("YODESK.DTA"))) { bool keepReading = true; while (keepReading) { string section = new string(binaryReader.ReadChars(4)); switch (section) { case "VERS": uint version = binaryReader.ReadUInt32(); break; case "STUP": uint length = binaryReader.ReadUInt32(); byte[] data = binaryReader.ReadBytes((int)length); break; default: throw new Exception("Unknown section: " + section); } } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

残念ながら、最初の2つのセクションでのみ機能します。3番目のセクション（SNDS）に到達するとすぐに、ファイル内のすべてのオプションを処理する必要があることが明らかになります。 これは、ファイル形式のリバースエンジニアリング時に非常に頻繁に発生します。これは、多くの種類のいずれかを持つさまざまな値を持っているためです。 そのため、私たちは会うことができるすべてのタイプを理解する必要があります。 幸いなことに、このファイルのほとんどすべてのセクションでは、セクション識別子の後に符号なし32ビット長が続きます。つまり、STUPセクション処理コードを使用してそれらをスキップできます。

 static void Main(string[] args) { using (BinaryReader binaryReader = new BinaryReader(File.OpenRead("YODESK.DTA"))) { bool keepReading = true; while (keepReading) { string section = new string(binaryReader.ReadChars(4)); switch (section) { case "VERS": uint version = binaryReader.ReadUInt32(); break; case "STUP": case "SNDS": case "ZONE": case "TILE": case "PUZ2": case "CHAR": case "CHWP": case "CAUX": case "TNAM": uint sectionLength = binaryReader.ReadUInt32(); byte[] sectionData = binaryReader.ReadBytes((int)sectionLength); break; case "ENDF": keepReading = false; break; } } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ZONEセクションでは、識別子（0x00010292）の直後にその長さが示されているように見えますが、このバイト数を超えると、ボイドになります。つまり、おそらく何か間違ったことをしています。 ただし、開始直後に、IZON、IZAX、IZX2、IZX3、IZX4、およびそれらの後に0からいくつかのIACTの他の識別子があることは明らかです。 この識別子のセットは、以下でもう一度繰り返され、ファイル内で数回出現します。 ここでは、ゲームの仕組みに関する知識が役立ちます。ヨーダストーリーの重要な「機能」の1つは、新しいパッセージごとにランダムカードが生成されることですが、いくつかのゲームの後、カードは実際には小さなカードで構成されていることが明らかになりますサイズ。 IACTセクションにスクリプトのようなテキストが含まれているという事実は、各IZONが実際にマップフラグメントに対応しているという考えを裏付けています。









ZONEセクションを簡単にスキップできない場合は、構造を分析してドキュメントの残りの部分を解析し続けることができるように、その構造についてさらに学習する必要があります。 この部分は以前の部分よりもはるかに洗練されていたにもかかわらず、長さに関係のないデータがセクション識別子の隣に追加されたため、結果として成功しました。



IZONには多くのセクションがあるため、あるデータから別のデータに移動できるデータがあることは明らかです。 ただし、プログラムは単に「IZON」の次の行を見つけるまでデータをスキャンすることができますが、これは非常に信頼性の低いアプローチですが、誰かがNPCダイアログラインに「IZON」を追加するかもしれません。 最初のIZONの先頭から次のIZONまでの長さを測定すると、長さ0x064Cが得られます。これは、識別子ZONE（0x00000646）に続く4バイトの後に4バイトに疑わしいほど近い長さです。 これらの4バイトを長さの識別子として使用し、それらに続く0x646バイトを見ると、パターンに気づき始めます。









4 : "ZONE"

2 : ????

2 : ????

4 : (X)

X : zone

2 : ????

4 : (X)

X : zone

2 : ????

4 : (X)

X : zone

...

2 : ????

4 : (X)

X : zone

4 : "PUZ2" ( )







さらなる研究により、さまざまな程度の実用性の事実が明らかになりました。

• ZONE識別子に続く2バイトは、ゾーンの数を指定する符号なし16ビット整数に対応します。
• 各ゾーンの長さの決定要因の前の2バイトは、値0x0001、0x0002、0x0003、および0x0005のみを持つことができます。
• これらのゾーンの最初の2バイトは、0x0000で始まり、毎回1ずつ増加する何らかのカードID番号です。

この情報に基づいてZONEセクションを読み取るようにプログラムを更新すると、ファイル全体を読み取ることができます。

 static void Main(string[] args) { using (BinaryReader binaryReader = new BinaryReader(File.OpenRead("YODESK.DTA"))) { bool keepReading = true; while (keepReading) { string section = new string(binaryReader.ReadChars(4)); switch (section) { case "VERS": uint version = binaryReader.ReadUInt32(); break; case "STUP": case "SNDS": case "TILE": case "PUZ2": case "CHAR": case "CHWP": case "CAUX": case "TNAM": uint sectionLength = binaryReader.ReadUInt32(); byte[] sectionData = binaryReader.ReadBytes((int)sectionLength); break; case "ZONE": ushort count = binaryReader.ReadUInt16(); for (int i = 0; i < count; i++) { ushort unknown = binaryReader.ReadUInt16(); uint zoneLength = binaryReader.ReadUInt32(); byte[] zoneData = binaryReader.ReadBytes((int)zoneLength); } break; case "ENDF": keepReading = false; break; default: throw new Exception("Unknown section: " + section); } } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードを使用すると、ファイル形式の一般的な構造について誤った仮定を行ったことを示す例外を発生させることなく、ファイル全体を読み取ることができます。 そして、まだ何も抽出していませんが、すでに正しい軌道に乗っています。

タイル（難易度：ジェダイナイト）

ファイル構造全体を解析できるようになったので、さらに深く掘り下げて、ここに来たもの、つまり奇妙で包括的なゲームタイルのセットをダンプします。









TILEセクションの中央まで行けば、ここに何か興味深いことがあることがすぐにわかります。それはビットマップイメージです。 ゲーム画像は32x32ピクセルのスプライトであるため、同様のパターンが32バイトの列に現れ始めると、これはピクセルあたり1バイトの非圧縮ビットマップ形式である可能性が高くなります。









TILEセクションの先頭に移動すると、ASCII文字スペースに対応する1024バイト（32x32）のデータ領域に気付くのは簡単です。おそらく4バイトのプレフィックスを持つスプライトデータです。 データ配列全体でこれら4バイトの値の範囲を調べると、それらは比較的ランダムですが、多くの場合繰り返され、ビットフラグの配列のように見えます。



4 :

1024 :

4 :

1024 :

...

4 :

1024 :







おそらくビットフラグはタイルのプロパティを表しているのでしょうか？ どのような違いがありますか！ 画像の抽出に近づいています！ 疑わしい画像データを画像ファイルにダンプするためにプログラムの機能を拡張することは残ります...

 case "TILE": { Directory.CreateDirectory(@"Tiles"); uint tileSectionLength = binaryReader.ReadUInt32(); for (int i = 0; i < tileSectionLength / 0x404; i++) { uint unknown = binaryReader.ReadUInt32(); Bitmap tile = new Bitmap(32, 32); for (int j = 0; j < 0x400; j++) { byte pixelData = binaryReader.ReadByte(); Color pixelColor = Color.FromArgb(pixelData, pixelData, pixelData); tile.SetPixel(j % 32, j / 32, pixelColor); } tile.Save(string.Format(@"Tiles\{0}.png", i)); } break; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

勝利！ またはそのようなもの...



明らかに、ゲームには色があります。そのため、各RGBコンポーネントにピクセル値を割り当てただけでは問題は解決しません。 グレーのグラデーション以外は取得できません。 ウィキペディアによると、標準の8ビットのトゥルーカラースキームは0bRRRGGGBBなので、試してみましょう。

 case "TILE": { Directory.CreateDirectory(@"Tiles"); uint tileSectionLength = binaryReader.ReadUInt32(); for (int i = 0; i < tileSectionLength / 0x404; i++) { uint unknown = binaryReader.ReadUInt32(); Bitmap tile = new Bitmap(32, 32); for (int j = 0; j < 0x400; j++) { byte pixelData = binaryReader.ReadByte(); byte r = (byte)((pixelData & 0xE0) << 0); byte g = (byte)((pixelData & 0x1C) << 3); byte b = (byte)((pixelData & 0x03) << 6); Color pixelColor = Color.FromArgb(r, g, b); tile.SetPixel(j % 32, j / 32, pixelColor); } tile.Save(string.Format(@"Tiles\{0}.png", i)); } break; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

明らかに、これも間違ったピクセル形式であるため、推測をやめて、数値自体の分析を始めましょう。 ゲームのスクリーンショットを撮り、最終的なスプライトの色に対応する値を比較します。









これらの青の色合いは非常に興味深いです。非常に近いですが、いくつかの異なる色合いがあります。 画像処理プログラムからピクセル値を取得すると、次の値が取得されます。



0x1F 0x00 / 0x00 / 0x00

0x92 0x0B / 0x53 / 0xFB

0x93 0x00 / 0x00 / 0xFB

0x94 0x00 / 0x00 / 0xCB

0x95 0x00 / 0x00 / 0x9F

0x96 0x00 / 0x00 / 0x6F







私は楽観的すぎて、ピクセル値から色成分へのビット変換がいくつかありましたが、0x1Fは何らかの形で黒（すべてゼロ）に一致していて、エラーを示しています。 ピクセル値を0x93から0x92に減らすと、色に2バイトの情報が魔法のように追加される場合、避けられないものを認識する時が来ました。カラーパレットはどこかに格納され、どこにあるかわかりません。



もちろん、たくさんのスクリーンショットを取り、ピクセル値を比較するプロセスを自動化できますが、もっと最適な方法があるはずです。 パレットデータはどこかに保存する必要があります。 このシステムをプログラムした場合、おそらく配列インデックスがピクセルデータの値である色の配列を保持するだけです。 楽しみのために、R2D2スプライトで使用されている色の1つ、つまり0x0B53FBをファイルで見てみましょう...



いや、何もない。



別の人気のあるピクセル形式-BGR、多分0xFB530Bができますか



また空。



ただし、もう1つの場所、つまりゲームの実行可能ファイルでは検索しませんでした。 通常、多くのゲームプレイ情報は定数としてコードに保存されますが、これはおそらくこの場合です。 バイナリファイルで0x0B53FBを検索しても結果は返されませんが、BGRの値を検索すると...









ああ、これはカラーパレットです！ 次の4バイトの値は0xFB000000、つまりBGRAの色0x93であるため、有用な何かに出くわす可能性が高くなります。 逆アセンブラでデータを探すと、もう少し理解できます。









この画像から理解することは困難ですが、これはパレットデータであり、逆コンパイルされたプログラムでコンパイル時定数の配列を見つけることができる場所です。 これが色0x92であることがわかっているので、正しい色で画像をエクスポートするためにプログラムにコピーするために、最後から作業を開始し、パレットの先頭を見つけることができます。

 private static readonly byte[] PaletteData = new byte[] { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x8B, 0x00, 0xC3, 0xCF, 0x4B, 0x00, 0x8B, 0xA3, 0x1B, 0x00, 0x57, 0x77, 0x00, 0x00, 0x8B, 0xA3, 0x1B, 0x00, 0xC3, 0xCF, 0x4B, 0x00, 0xFB, 0xFB, 0xFB, 0x00, 0xEB, 0xE7, 0xE7, 0x00, 0xDB, 0xD3, 0xD3, 0x00, 0xCB, 0xC3, 0xC3, 0x00, 0xBB, 0xB3, 0xB3, 0x00, 0xAB, 0xA3, 0xA3, 0x00, 0x9B, 0x8F, 0x8F, 0x00, 0x8B, 0x7F, 0x7F, 0x00, 0x7B, 0x6F, 0x6F, 0x00, 0x67, 0x5B, 0x5B, 0x00, 0x57, 0x4B, 0x4B, 0x00, 0x47, 0x3B, 0x3B, 0x00, 0x33, 0x2B, 0x2B, 0x00, 0x23, 0x1B, 0x1B, 0x00, 0x13, 0x0F, 0x0F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC7, 0x43, 0x00, 0x00, 0xB7, 0x43, 0x00, 0x00, 0xAB, 0x3F, 0x00, 0x00, 0x9F, 0x3F, 0x00, 0x00, 0x93, 0x3F, 0x00, 0x00, 0x87, 0x3B, 0x00, 0x00, 0x7B, 0x37, 0x00, 0x00, 0x6F, 0x33, 0x00, 0x00, 0x63, 0x33, 0x00, 0x00, 0x53, 0x2B, 0x00, 0x00, 0x47, 0x27, 0x00, 0x00, 0x3B, 0x23, 0x00, 0x00, 0x2F, 0x1B, 0x00, 0x00, 0x23, 0x13, 0x00, 0x00, 0x17, 0x0F, 0x00, 0x00, 0x0B, 0x07, 0x00, 0x4B, 0x7B, 0xBB, 0x00, 0x43, 0x73, 0xB3, 0x00, 0x43, 0x6B, 0xAB, 0x00, 0x3B, 0x63, 0xA3, 0x00, 0x3B, 0x63, 0x9B, 0x00, 0x33, 0x5B, 0x93, 0x00, 0x33, 0x5B, 0x8B, 0x00, 0x2B, 0x53, 0x83, 0x00, 0x2B, 0x4B, 0x73, 0x00, 0x23, 0x4B, 0x6B, 0x00, 0x23, 0x43, 0x5F, 0x00, 0x1B, 0x3B, 0x53, 0x00, 0x1B, 0x37, 0x47, 0x00, 0x1B, 0x33, 0x43, 0x00, 0x13, 0x2B, 0x3B, 0x00, 0x0B, 0x23, 0x2B, 0x00, 0xD7, 0xFF, 0xFF, 0x00, 0xBB, 0xEF, 0xEF, 0x00, 0xA3, 0xDF, 0xDF, 0x00, 0x8B, 0xCF, 0xCF, 0x00, 0x77, 0xC3, 0xC3, 0x00, 0x63, 0xB3, 0xB3, 0x00, 0x53, 0xA3, 0xA3, 0x00, 0x43, 0x93, 0x93, 0x00, 0x33, 0x87, 0x87, 0x00, 0x27, 0x77, 0x77, 0x00, 0x1B, 0x67, 0x67, 0x00, 0x13, 0x5B, 0x5B, 0x00, 0x0B, 0x4B, 0x4B, 0x00, 0x07, 0x3B, 0x3B, 0x00, 0x00, 0x2B, 0x2B, 0x00, 0x00, 0x1F, 0x1F, 0x00, 0xDB, 0xEB, 0xFB, 0x00, 0xD3, 0xE3, 0xFB, 0x00, 0xC3, 0xDB, 0xFB, 0x00, 0xBB, 0xD3, 0xFB, 0x00, 0xB3, 0xCB, 0xFB, 0x00, 0xA3, 0xC3, 0xFB, 0x00, 0x9B, 0xBB, 0xFB, 0x00, 0x8F, 0xB7, 0xFB, 0x00, 0x83, 0xB3, 0xF7, 0x00, 0x73, 0xA7, 0xFB, 0x00, 0x63, 0x9B, 0xFB, 0x00, 0x5B, 0x93, 0xF3, 0x00, 0x5B, 0x8B, 0xEB, 0x00, 0x53, 0x8B, 0xDB, 0x00, 0x53, 0x83, 0xD3, 0x00, 0x4B, 0x7B, 0xCB, 0x00, 0x9B, 0xC7, 0xFF, 0x00, 0x8F, 0xB7, 0xF7, 0x00, 0x87, 0xB3, 0xEF, 0x00, 0x7F, 0xA7, 0xF3, 0x00, 0x73, 0x9F, 0xEF, 0x00, 0x53, 0x83, 0xCF, 0x00, 0x3B, 0x6B, 0xB3, 0x00, 0x2F, 0x5B, 0xA3, 0x00, 0x23, 0x4F, 0x93, 0x00, 0x1B, 0x43, 0x83, 0x00, 0x13, 0x3B, 0x77, 0x00, 0x0B, 0x2F, 0x67, 0x00, 0x07, 0x27, 0x57, 0x00, 0x00, 0x1B, 0x47, 0x00, 0x00, 0x13, 0x37, 0x00, 0x00, 0x0F, 0x2B, 0x00, 0xFB, 0xFB, 0xE7, 0x00, 0xF3, 0xF3, 0xD3, 0x00, 0xEB, 0xE7, 0xC7, 0x00, 0xE3, 0xDF, 0xB7, 0x00, 0xDB, 0xD7, 0xA7, 0x00, 0xD3, 0xCF, 0x97, 0x00, 0xCB, 0xC7, 0x8B, 0x00, 0xC3, 0xBB, 0x7F, 0x00, 0xBB, 0xB3, 0x73, 0x00, 0xAF, 0xA7, 0x63, 0x00, 0x9B, 0x93, 0x47, 0x00, 0x87, 0x7B, 0x33, 0x00, 0x6F, 0x67, 0x1F, 0x00, 0x5B, 0x53, 0x0F, 0x00, 0x47, 0x43, 0x00, 0x00, 0x37, 0x33, 0x00, 0x00, 0xFF, 0xF7, 0xF7, 0x00, 0xEF, 0xDF, 0xDF, 0x00, 0xDF, 0xC7, 0xC7, 0x00, 0xCF, 0xB3, 0xB3, 0x00, 0xBF, 0x9F, 0x9F, 0x00, 0xB3, 0x8B, 0x8B, 0x00, 0xA3, 0x7B, 0x7B, 0x00, 0x93, 0x6B, 0x6B, 0x00, 0x83, 0x57, 0x57, 0x00, 0x73, 0x4B, 0x4B, 0x00, 0x67, 0x3B, 0x3B, 0x00, 0x57, 0x2F, 0x2F, 0x00, 0x47, 0x27, 0x27, 0x00, 0x37, 0x1B, 0x1B, 0x00, 0x27, 0x13, 0x13, 0x00, 0x1B, 0x0B, 0x0B, 0x00, 0xF7, 0xB3, 0x37, 0x00, 0xE7, 0x93, 0x07, 0x00, 0xFB, 0x53, 0x0B, 0x00, 0xFB, 0x00, 0x00, 0x00, 0xCB, 0x00, 0x00, 0x00, 0x9F, 0x00, 0x00, 0x00, 0x6F, 0x00, 0x00, 0x00, 0x43, 0x00, 0x00, 0x00, 0xBF, 0xBB, 0xFB, 0x00, 0x8F, 0x8B, 0xFB, 0x00, 0x5F, 0x5B, 0xFB, 0x00, 0x93, 0xBB, 0xFF, 0x00, 0x5F, 0x97, 0xF7, 0x00, 0x3B, 0x7B, 0xEF, 0x00, 0x23, 0x63, 0xC3, 0x00, 0x13, 0x53, 0xB3, 0x00, 0x00, 0x00, 0xFF, 0x00, 0x00, 0x00, 0xEF, 0x00, 0x00, 0x00, 0xE3, 0x00, 0x00, 0x00, 0xD3, 0x00, 0x00, 0x00, 0xC3, 0x00, 0x00, 0x00, 0xB7, 0x00, 0x00, 0x00, 0xA7, 0x00, 0x00, 0x00, 0x9B, 0x00, 0x00, 0x00, 0x8B, 0x00, 0x00, 0x00, 0x7F, 0x00, 0x00, 0x00, 0x6F, 0x00, 0x00, 0x00, 0x63, 0x00, 0x00, 0x00, 0x53, 0x00, 0x00, 0x00, 0x47, 0x00, 0x00, 0x00, 0x37, 0x00, 0x00, 0x00, 0x2B, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0xE3, 0xF7, 0x00, 0x00, 0xCF, 0xF3, 0x00, 0x00, 0xB7, 0xEF, 0x00, 0x00, 0xA3, 0xEB, 0x00, 0x00, 0x8B, 0xE7, 0x00, 0x00, 0x77, 0xDF, 0x00, 0x00, 0x63, 0xDB, 0x00, 0x00, 0x4F, 0xD7, 0x00, 0x00, 0x3F, 0xD3, 0x00, 0x00, 0x2F, 0xCF, 0x00, 0x97, 0xFF, 0xFF, 0x00, 0x83, 0xDF, 0xEF, 0x00, 0x73, 0xC3, 0xDF, 0x00, 0x5F, 0xA7, 0xCF, 0x00, 0x53, 0x8B, 0xC3, 0x00, 0x2B, 0x2B, 0x00, 0x00, 0x23, 0x23, 0x00, 0x00, 0x1B, 0x1B, 0x00, 0x00, 0x13, 0x13, 0x00, 0x00, 0xFF, 0x0B, 0x00, 0x00, 0xFF, 0x00, 0x4B, 0x00, 0xFF, 0x00, 0xA3, 0x00, 0xFF, 0x00, 0xFF, 0x00, 0x00, 0xFF, 0x00, 0x00, 0x00, 0x4B, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0xFF, 0x33, 0x2F, 0x00, 0x00, 0x00, 0xFF, 0x00, 0x00, 0x1F, 0x97, 0x00, 0xDF, 0x00, 0xFF, 0x00, 0x73, 0x00, 0x77, 0x00, 0x6B, 0x7B, 0xC3, 0x00, 0x57, 0x57, 0xAB, 0x00, 0x57, 0x47, 0x93, 0x00, 0x53, 0x37, 0x7F, 0x00, 0x4F, 0x27, 0x67, 0x00, 0x47, 0x1B, 0x4F, 0x00, 0x3B, 0x13, 0x3B, 0x00, 0x27, 0x77, 0x77, 0x00, 0x23, 0x73, 0x73, 0x00, 0x1F, 0x6F, 0x6F, 0x00, 0x1B, 0x6B, 0x6B, 0x00, 0x1B, 0x67, 0x67, 0x00, 0x1B, 0x6B, 0x6B, 0x00, 0x1F, 0x6F, 0x6F, 0x00, 0x23, 0x73, 0x73, 0x00, 0x27, 0x77, 0x77, 0x00, 0xFF, 0xFF, 0xEF, 0x00, 0xF7, 0xF7, 0xDB, 0x00, 0xF3, 0xEF, 0xCB, 0x00, 0xEF, 0xEB, 0xBB, 0x00, 0xF3, 0xEF, 0xCB, 0x00, 0xE7, 0x93, 0x07, 0x00, 0xE7, 0x97, 0x0F, 0x00, 0xEB, 0x9F, 0x17, 0x00, 0xEF, 0xA3, 0x23, 0x00, 0xF3, 0xAB, 0x2B, 0x00, 0xF7, 0xB3, 0x37, 0x00, 0xEF, 0xA7, 0x27, 0x00, 0xEB, 0x9F, 0x1B, 0x00, 0xE7, 0x97, 0x0F, 0x00, 0x0B, 0xCB, 0xFB, 0x00, 0x0B, 0xA3, 0xFB, 0x00, 0x0B, 0x73, 0xFB, 0x00, 0x0B, 0x4B, 0xFB, 0x00, 0x0B, 0x23, 0xFB, 0x00, 0x0B, 0x73, 0xFB, 0x00, 0x00, 0x13, 0x93, 0x00, 0x00, 0x0B, 0xD3, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0x00, }; case "TILE": { Directory.CreateDirectory(@"Tiles"); uint tileSectionLength = binaryReader.ReadUInt32(); for (int i = 0; i < tileSectionLength / 0x404; i++) { uint unknown = binaryReader.ReadUInt32(); Bitmap tile = new Bitmap(32, 32); for (int j = 0; j < 0x400; j++) { byte pixelData = binaryReader.ReadByte(); byte r = PaletteData[pixelData * 4 + 2]; byte g = PaletteData[pixelData * 4 + 1]; byte b = PaletteData[pixelData * 4 + 0]; Color pixelColor = pixelData == 0 ? Color.Transparent : Color.FromArgb(r, g, b); tile.SetPixel(j % 32, j / 32, pixelColor); } tile.Save(string.Format(@"Tiles\{0}.png", i)); } break; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

うまくいきました！ 私たちは、2,000を超える奇妙で魅力的なスプライトを抽出しました。 0x00の色は実際には透明であることに注意してください。これは、生のピクセルデータを見ると明らかです。



これは画像をダンプするよりも退屈ですが、画像ファイル名の一部としてそれらをエクスポートし、一般的に見てフラグをデコードすることはそれほど難しくありません。 小さな画像とそれに対応する数字の論理と綿密な調査により、次のことがわかります。



:

bit0 =

bit1 = ,

bit2 = ,

bit3 = , /

bit4 = , ( , )

bit5 = -

bit6 =

bit7 =

bit8 =



:

bit16 =

bit17 = (????)

bit18 =

bit19 =



:

bit16 = -

bit17 =

bit18 = (???)

bit19 = ( ???)

bit20 =

bit22 =



:

bit16 =

bit17 =

bit18 =



:

bit16 =



-:

bit17 = - ()

bit18 = - (, )

bit19 = - (, )

bit20 = - (, )

bit21 = - (, )

bit22 = - ( , )

bit23 = - ( , )

bit24 = - ( , )

bit25 = - ( , )

bit26 = - ( , )

bit27 = - ( , )

bit28 = - ( , )

bit29 = - ( , )

bit30 = - ()







ビット0〜8に応じてビット16以上が異なる値で使用され、特定のビットに1つの値のみが含まれると予想される場合、最初は少し混乱することに注意してください。

カード（難易度：ジェダイナイト）

目標を達成しましたが、ゾーンマップは研究の興味深い対象のようにも見えます。 16進エディタでゾーンの記述方法に戻ると、ゾーンエントリにいくつかのサブセクションがあることがわかります。 ゾーンをスキップせずに分析するには、各ゾーンについて詳しく知る必要があります。









自分でファイルを16進エディタにロードしないとこれを確認することは困難ですが、IZONサブセクションの長さはかなり一貫していません。 IZONの後の最初の4バイトの長さは似ていますが、実際に追跡すると、実際にはIZAXサブセクション識別子を超えて、またはIZAXサブセクション識別子を超えてスローされます。









多くの場合、このプロセスは複雑なパズルゲームをプレイするようなものです（信じられますが、私はそれを書いています）が、最終的には私に気づきました：特に、マップのサイズ（9x9または18x18）、次に6バイトを決定する小さな見出しがありますグリッドの正方形ごとに、その後に続く12バイト構造の数を決定する16ビット整数。



他のサブセクションも混乱を招きます。IZAXは、IZX2およびIZX3と同じ長さ+ 6を決定します。 IZX4の長さは一定で、頻繁に発生するIACTはその長さを直接示します。 すべてをまとめて、以下を取得します。



4 : "IZON"

4 :

2 : (W)

2 : (H)

1 : ( )

5 : ( )

1 : (0x01 = , 0x02 = , 0x03 = , 0x05 = )

1 : ( )

W*H*6 :

2 : (X)

X*12 :

4 : "IZAX"

2 : (X)

X-6 : IZAX

4 : "IZX2"

2 : (X)

X-6 : IZX2

4 : "IZX3"

2 : (X)

X-6 : IZX3

4 : "IZX4"

8 : IZX4

4 : "IACT"

4 : (X)

X :

4 : "IACT"

4 : (X)

X :

...

4 : "IACT"

4 : (X)

X :







正方形グリッドごとに6バイトがあること、つまり、マップをロードするときにグリッドの正方形に書き込まれているものに対応する可能性が高いことがわかっています。 最初のカードの最初の正方形（0x00、0x00、0xFF、0xFF、0x01、0x00）を見るだけで、これらは3つの16ビット整数であることがほぼ確実でした。タイルは256をはるかに超えています）。 プログラムの機能を拡張して、この情報に基づいて抽出されたファイルを接続すると、次のようになります。









カード！ 私たちの推測は真実のようです。 ゲームには600枚以上のカードがあり、それぞれに独自のスクリプトとスキームがあります。 この一見シンプルなゲームにどれだけの労力が費やされたかは驚くべきことです。











また興味深いのは、IZONサブセクションの最後にある変数「オブジェクト情報」の長さです。 マップ上にあるタイルの追加プロパティを定義しているようです。 16進エディターで1つの巨大なフラグメントとしてデータを調べることはあまり役に立ちませんが、12バイトのレコードとして表にしてマップ画像と比較すると、いくつかのパターンが現れ始めます。











N/AXYN/A

09 00 00 00 04 00 04 00 01 00 01 00

09 00 00 00 09 00 09 00 01 00 05 00

09 00 00 00 0F 00 09 00 01 00 09 00

0F 00 00 00 09 00 0D 00 01 00 5D 00

06 00 00 00 0A 00 03 00 01 00 AE 04

06 00 00 00 0A 00 04 00 01 00 AE 04







各レコードを6つの16ビット整数として処理する場合、最初のレコードはタイプフラグになり、3番目と4番目はマップ座標になります。 2番目と5番目の値は常に同じ値（0x0000と0x0001）であり、後者は非常に乱雑であるため、引数のように見えます。 これらのレコードが指すタイルを確認し始めると、タイプ0x09の各レコードはドアを示します。引数は、ゲームでドアがつながるカードのIDです。



さまざまなタイプのレコードが対応するものを見つけることは非常に単調なタスクですが、暗号化されていないレコードタイプが見つかったときに対話を一時停止するようにプログラムに教えることにより、データファイル内の各データタイプを体系的に調べることができます。 ちょっとしたロジックと当て推量で、次のものが得られます。

タイプID	説明	引数
0x00	トリガー位置
0x01	スポーンポイント
0x02	フォースに関連する場所
0x03	追加カードへの輸送	トランスポートがプレーヤーを運ぶカード
0x04	メインカードへの輸送	トランスポートがプレーヤーを運ぶカード
0x05	プレーヤーがロケーターに与えるオブジェクト
0x06	アイテムボックス	内部にあるオブジェクト
0x07	パズルNPC	対応する文字のタイルID
0x08	武器箱	中に横たわっている武器
0x09	ドア（入り口）	ドアが接続されているカード
0x0A	ドア（出口）
0x0B	未使用
0x0C	ブロッキング
0x0D	テレポート
0x0E	惑星ダゴバからのXウイング	カードX-Wingはプレイヤーを
0x0F	惑星ダゴバへのXウイング	カードX-Wingはプレイヤーを

スクリプト（難易度：ジェダイマスター）

タイルとカードの形式を扱ったので、特定のカードのゲームプレイロジックを制御するスクリプト言語の取り扱いを始めるのは論理的です。 ASCII文字で満たされ、コマンドに似たフラグメントがあるため、おそらくそれほど難しくないでしょう...









残念ながら、解読が難しいスクリプトでは多くのことが起こります。 タイルとカードを解読した後は視覚的に明らかであるのとは異なり、スクリプトは変数とゲームプレイの状態を使用しますが、それらは見たり確認したりするのがそれほど簡単ではありません。このゲームのリバース開発に非常に興味がある場合は、レベルをロードし、観察されたゲームプレイの動作をスクリプト内のデータと相関させることをお勧めしますが、その準備はできていません。終了する前に、私たちが学んだことで何かを試してみたい...

Modの作成

カード番号95のIZONサブセクションは、データファイルのオフセット0x266512から始まります。20バイトをスキップしてマップデータを取得し、さらに6 *（18 * 9 + 12）バイトをスキップしてポイント（12、11）に移動できます。その後、16進エディターを使用して、1985および1986タイルの値を各グリッドの「平均」二乗値にリセットし、ゲームデータファイルを書き換えると、次のようになります。









ゲームタイルのセットにスポーツカーがある理由はよくわかりませんが、ヨーダは最高の女の子とデートに行くと確信しています。



ATTACHMENT：ユーザーsehuggハッカーのニュースには、映画1978年からという事実に、このマシンを報告した「コルベット」の検索で夏「」、（ルーク・スカイウォーカーを演じた）マーク・ハミルが主演しています。イースターエッグ！

結論として

明らかに、忍耐力があれば、このデータを使用してさらに多くのことができます。ゲームデータファイルのほとんどをリバースエンジニアリングした後、驚くほど簡単にゼロから再作成するか（今では非常に小さなウィンドウで動作します）、ゲームのコンテンツをエクスポート、編集、再パッケージしてmodを作成するツールを作成します。なぜこれが必要なのかわかりませんが、間違いなくそのような機会があります。少なくとも、今では奇妙で見栄えのいいスターウォーズスプライトのクールで包括的なセットにアクセスできます。古いコンピューターゲームのリバースエンジニアリングデータファイル形式について興味深いことを学んだことを願っています。