フォーマットの解析：ハッシュ化されたリソースのパック

最後の2つの 記事では、現代のゲームのサウンドサブシステムのデータ形式の機能について説明しました。 読者を飽きさせないために、少し異なるトピックを取り上げます。 ゲームが使用するエンジンが何であれ、リソースをどこかに保存し、適切なタイミングでそこからリソースを抽出する必要があります。 アーカイブ内のリソースには、識別子と読み取り可能なファイル名の両方がある場合があります。 しかし、ファイルに名前がないエンジンはかなりありますが、ハッシュだけがあります。 それでは、リソースで何かを整理する方法を教えてください。



例として、かなり珍しいbitsquidエンジンでこれを検討してください。 シンプルでコンパクトですが、それにもかかわらず、現代のゲームに必要なすべての機能を備えています。 昨年、bitsquidとその開発者はオートデスクに買収されましたが、現在はMayaと連携して独自のゲームエンジンを作成する予定です。



誰でも自分でプロセスを見ることができるように、デモ版のShowdown Effectを使用します。これも非常に小さい（約250MB）です。 明らかにすべてのリソースを含むコンテンツフォルダーに入った後、このような素晴らしい名前のファイルが数十個見つかりました。

  038bbacc4ce89296
 0d42c15e8f2b473f
 171e8b0d2241eb79
 406c3644bd95237a
 44bcc04093e5c506
 680514e023d37cd5
 71eec7a172194fe5
 9229959b09a3b4be
 9e13b2414b41b842
 a6db0de7cf227dfe
 a9956e471d528263
 ac5c2f0670e5d674
 b5af853949550001 

これらはリソースパッケージ/アーカイブファイルである必要があります。 それらの1つを開いて、中身を見てみましょう。 そしてそこには、ファイル全体を通して、テーブルもテキストも意味のある数字も見えません-連続したバイトのハッシュ：







これは通常、すべてのデータが暗号化および/または圧縮されていることを意味します。 この場合、ほとんど最初に、バイト78 9Cの組み合わせ（緑色で強調表示）は、データがzlib圧縮されていることを明確に示しています。 最初にファイルを「手動で」解凍してみましょう。 これを行うには、ファイル内のバイト数やファイルのシーケンスに関係なく、zipまたはzlibでパックされているかのように、ファイル内のバイトシーケンスをアンパックするユーティリティであるoffzipを使用します。



次のコマンドを実行します： offzip -a 9e13b2414b41b842 unp 0



ここの-aオプションは、ファイル内のすべてのzlib圧縮セグメントを見つけようとし、ファイルを唯一の圧縮ブロックと見なさないことを意味します。 「Unp」は解凍用のフォルダーです（最初に作成する必要があります）。 「0」は初期オフセットです。つまり、ファイルの先頭から検索します。



次のものが得られます。

  + ------------ + ----- + ---------------------------- +- --------------------- +
 |  hex_offset |  ... |  zip->解凍サイズ/オフセット| 前のスペース| 情報|
 + ------------ + ----- + ---------------------------- +- --------------------- +
   0x00000010 24803-> 65536 / 0x000060f3 _ 16 8：7：28：0：1：441d52d8
   0x000060f7 21186-> 65536 / 0x0000b3b9 _ 4 8：7：28：0：1：74fe0bf1
   0x0000b3bd 16694-> 65536 / 0x0000f4f3 _ 4 8：7：28：0：1：4bdbbd7f
   0x0000f4f7 17028-> 65536 / 0x0001377b _ 4 8：7：28：0：1：4cae9920
   0x0001377f 16200-> 65536 / 0x000176c7 _ 4 8：7：28：0：1：aa6b718e
   0x000176cb 14445-> 65536 / 0x0001af38 _ 4 8：7：28：0：1：e190c104
 [欠けた...]
   0x04ec0fb4 17108-> 65536 / 0x04ec5288 _ 4 8：7：28：0：1：952f8201
   0x04ec528c 17139-> 65536 / 0x04ec957f _ 4 8：7：28：0：1：373c403f
   0x04ec9583 22442-> 65536 / 0x04eced2d _ 4 8：7：28：0：1：8e95fe5c
   0x04eced31 4215-> 65536 / 0x04ecfda8 _ 4 8：7：28：0：1：93e0ac5a

 -1483個の有効な圧縮ストリームが見つかりました
 -0x04d7e61c->ファイルの98％をカバーする0x05cb0000バイト 

ご覧のとおり、ファイルの内容の98％が、それぞれ64 kBの一連のセグメントに展開されました。 それらの内容を分析すると、それらが単一の全体であることがわかります。1つの大きなファイルは、単純に64 kBの断片に切り分けられ、その後zlibによって個別に圧縮されました。 原則として、逆の場合もあります。各ソースリソースは個別に圧縮され、それらはすべて1つの大きなファイルにまとめられます。 ただし、この場合、ファイルは1つしかないため、次のコマンドで展開できます。



offzip -a -1 9e13b2414b41b842 unp 0



-1オプションは、検出されたすべてのアンパックセグメントを結合する必要があることを意味します。 その結果、解凍されたファイルを取得しますが、これも再度調査する必要があります。 前後にスイープすることで、内部にはluaスクリプト、サウンド、テクスチャがあり、現在は圧縮されていないが、すべて一緒になっていることがわかります。







私たちのタスクは、ファイルを個別のリソースに分割することです。さらに、何らかの方法でその名前を見つけることをお勧めします。 ファイルの先頭に戻ります。 ここでは、理解できないものがあり、その後多くのゼロがあり、明らかにテーブルが始まります。 行内の行の長さは16バイトのように見えますが、興味深いことに、右半分は常に異なり、左半分には繰り返し番号があります（緑色で強調表示されています）。 また、ファイル自体の名前は、その行のいずれかでファイル内で繰り返されることもあります。







さらに、何らかの理由で、テーブルの最後の行が最初の行と同じであることがわかりました。 また、複数のファイルを見ると、それらの最初の数字はテーブル内の行の数だけであるようです（true、-1）。 このすべてのデータを比較した結果、これはリソースの名前がハッシュの形式で記述されたテーブルであり、リソースの名前とそのタイプは別個であると結論付けることができます。 そして最後の行はテーブルではなく、最初のハッシュに関する情報の最初のリソースに関する情報であり、サイズ、その他のパラメーター、およびファイル自体があるはずです。 これを確認するために、ファイル内の残りの番号を検索します。また、もちろん、それらは表に記載されているとおりの正確な順序で配置されています。



さて、今ではエントリの形式を解析し、ハッシュされた名前を推測しようとしています。 原則として、ゲームは既にハッシュによってリソースにアクセスしており、元の名前が残っていない可能性があります。その場合、名前は見つかりません。 しかし幸いなことに、ほとんどの場合、それらはコードまたはスクリプトによって検出、推測、または計算できます。 ところで、スクリプトについては、ここで既にluaが使用されていることを確認しました。つまり、そのようなファイルの拡張子は「lua」になる可能性が高いということです。 使用されるハッシュのタイプは、コード内の既知の定数の存在によって決定できます。 たとえば、 FNVは番号0x811C9DC5を使用します。 独自のアルゴリズムを使用する場合、シフト付きの加算など、通常は単純ですが、コード内でそれを見つけるのはそれほど簡単ではありません。



私は0x811C9DC5を検索しようとしていましたが、最初にそれをグーグルで検索することに決め、私のブログの開発者bitsquidがmurmur64ハッシュの利点について語っていたことがわかりました。 ハッシュと同様に、murmurにはさまざまなバージョンがありますが、表のように64ビットはわずか8バイトです。 ソースコードはここで見つかりました 。 それをコンパイルし、文字列「lua」のハッシュを計算してみてください。 確かに、私たちは種が何であるかを知らないので、今のところは、ゼロを取ろうとします。



「lua」= A14E8DFA2CD117E2からmurmur64を取得します



多くの場合、この番号はファイルにあります！ おめでとうございます、ゲームがハッシュをどのように考慮するかがわかりました。 シードがゼロではない場合は、コードを確認またはデバッグして確認する必要があります。 定数またはテキスト文字列の長さを指定できますが、一般的には何でもかまいません。 たとえば、文字列の長さに接着された最初の文字。



さて、拡張機能の1つを知っています。他のすべての拡張機能を1つずつ推測することが本当に必要なのでしょうか。 おそらくこれが起こります。 しかし、オープンな形式で、いわば彼らのリストをどこかで検索してみましょう。 この場合のように、luaスクリプトのいずれか、または実行可能ファイルに直接含めることができます。







中央では、まさにリソースタイプである行を強調表示しました。 しかし、このリストはどこから始まり、どこで終わりますか？ これは実験的に決定できます。



たとえば、「unit」= E0A48D0BE9A7453Fのmurmur64を試してみましょう



実際、そのようなコードがあります。 当たり前の名前のようですが、初めて推測するのはそれほど簡単ではありません。 サウンドバンクは一般に「timpani_bank」と呼ばれるので、私は想像もしていませんでした。



それで、今ではすべての種類のリソース（ファイル拡張子）を知っていますが、それらの名前を見つける方法は？ リソースまたはコード内にあります。 アーカイブの横にある.iniファイルを見てみましょう。

boot_package = "resource_packages/boot" boot_script = "scripts/boot/boot" pdxigs = { game_name = "Showdown" game_version = "1.0.0" server_url = "http://xxxxxxxx.xxxxxxxxxxxxx.com/xxxx" } steam = { notification_position = "bottom-left" } timpani = "content/sounds/shoot"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これが最初の手がかりです-ダウンロードパッケージは「resourse_packages / boot」と呼ばれます。 この行のハッシュを計算してみましょう-9E13B2414B41B842、これはリストにあります。 他のファイルとともに、ブートスクリプトが含まれています



「スクリプト/ブート/ブート」= BBF3D6DD1B2AC672。



その中には、「scripts / boot / boot_common」などの他のスクリプトへのリンクがあります。 この共通には、次のような多くの行があります。



「リソースパッケージ/ base_game_resources」= 0D42C15E8F2B473F



どうやらこれはゲームの主なリソースを含むパッケージの名前です。 チェック-本当にあります。 だから徐々に理論的にすべての数字を見つけることができます。 当然、これは手動では行われませんが、平均的なゲームでは数万または数十万ものリソースがあるため、プログラムまたはスクリプトが作成されます。 推測プロセスは、長時間続くことがありますが、すべて同じで、多くの場合、最終的には一定量の名前のないファイルが残ります。 ただし、ほとんどの名前は通常見つけることができます。その後、リストがコンパイルされ、リソースを展開してゲームを変更するときに使用されます。



そのため、すべての名前が見つかったため、リソースに意味のある名前と拡張子が付けられたとします。 ファイル形式に戻ります。







テーブルの後に-ハッシュのリスト（黄色で強調表示）、すべてのリソースの個々のエントリが始まります。 すでにわかったように、最初の行（緑色で強調表示）はリソースの名前とタイプです。 ここで82645835E6B73232 = "config"、まだ正しい部分（名前）がわかりません。 次に来るものを推測してみましょう。 どうやら、ここにはいくつかの32ビットの数値があります。 最初に1つ、次に2つのゼロ、次にサイズが似ている別の数字（ピンク色で強調表示）、もう1つのゼロ。 それが何であるかはわかりませんが、すべてのファイルでこれらの数値はまったく同じです。 次に、リソース自体のコンテンツが開始されます。 長さを確認してください。 記録を開始するオフセット0518にサイズ045を追加すると、0974が得られます。







はい、確かに、次のハッシュがあります。 9EFE0A916AAE7880 =これは「フォント」であり、すべてが最初のレコードと同じであり、フォントの長さは1838です。次に、フォント自体が来ます。これは、大きな一連の浮動数で始まり、通常は肉眼でも簡単に見ることができます。 たとえば、42000000は32、4180000は25、そしてもちろん3F800000はゲームファイルで最も頻繁に使用される浮動小数点数です-1です。



整理したのは、アーカイブ内のレコードの形式のようです。 各リソースについて私たちが持っている唯一のものは、そのサイズのようです。 バイアスがないのは奇妙なことです。 残りの数字はゼロです。おそらく何か意味がありますが、わかりません。 念のため、最後のリソースの長さを先頭のアドレスに追加して、最後のレコードを確認してください。 4ECFDA0を取得します-これは単なるファイルの合計長です。 結局、これ以上何もないので、解凍プログラムの作成を開始できます。 彼女はパッケージファイルを読み取り、リソースに共有します。 ハッシュがリストにある場合は、正しい名前でファイルを保存します;そうでない場合は、ハッシュ自体が名前として使用されます。



プログラムを開始します。パッケージから多数のファイルを正常にアンパックします。 内容を確認してください。 テクスチャは本当に正しいDDSファイルであることが判明し、サウンドは通常のOGGのように再生されますが、残りのファイル（ユニットモデルなど）は特別な形式を持っていますが、信じられないほど見えます。



成功に勇気付けられ、他のすべてのファイルの解凍が開始されます。 そして、ここでは未処理の例外が待っています。 いくつかを除いて、ほぼすべてのファイルが解凍されました。 これは通常起こります。 数千のファイルの中には、確実に1つまたは2つあり、何らかの形で非標準であるか、追加のパラメーターが含まれています。 これらのファイルの何が問題なのか見てみましょう。 ハッシュの後のものは偶然ではなかったことがわかります。 このファイルには、1つではなく7つがあります。 さらに、同じエンジンで作られた他のゲームを展開すると、そこにあるゼロも常にゼロではないことが判明しました。 しかし、それだけではありません。 構造が完全に変更されていると思われるファイルが1つあります。 その中に別のリソースを見つけようとすると、ファイルの残りの部分ではこの長さのリソースには不十分であることがわかります。



この特定のリソースに関するレコードを見てみましょう。 すべてが正しいようです：ハッシュ、その後ろに1つ、2つのゼロ、そしてサイズ。 どうして？ ファイルが誤って解凍された可能性がありますか？ さて、もう一度やり直してください。 おそらく、出力offzipの数百行のちらつきで、私たちは何かに気づきませんでしたか？

  0x0286c4e2 65196-> 65536 / 0x0287c38e _ 4 8：7：28：0：1：340433a1
   0x0287c392 65242-> 65536 / 0x0288c26c_ 4 8：7：28：0：1：27 dce3e7
   0x0288c270 65415-> 65536 / 0x0289c1f7 _ 4 8：7：28：0：1：b9bd6cd0
 。  0x028cac59 ....................
 -zlib Z_DATA_ERROR、ファイル内のデータはzip形式ではありません
  または、異なるwindowBits値（-z）を使用します。  -z -15を使用してみてください
   0x028cc207 65533-> 65536 / 0x028dc204 _ 196624 8：7：28：0：1：54aa0921
   0x028dc208 65513-> 65536 / 0x028ec1f1 _ 4 8：7：28：0：1：c4b3abd4
   0x028fc1f9 65533-> 65536 / 0x0290c1f6 _ 65544 8：7：28：0：1：890356ae
   0x0290c1fa 65534-> 65536 / 0x0291c1f8 _ 4 8：7：28：0：1：934a442c
   0x0292c200 65496-> 65536 / 0x0293c1d8 _ 65544 8：7：28：0：1：c21356fb
   0x0293c1dc 65521-> 65536 / 0x0294c1cd _ 4 8：7：28：0：1：5bf3ea59
   0x0294c1d1 65514-> 65536 / 0x0295c1bb _ 4 8：7：28：0：1：d7c697a0 

はい、確かに、ある種の問題。 このファイルには、展開されていないセグメントがあります。 ところで、これはどのようなリソースですか？ オフセット0x028cac59またはそれより少し前のファイルの内容を見てみましょう。







そして、これは単なる「timpani_bank」です。 もちろんです！ 結局のところ、oggストリームには、zlibが単純に圧縮できないビットのカオスストリームを含めることができます。92MBファイルの結果、圧縮後のいくつかの64 KBセグメントが64 kを超えることが判明しました。 どうやら、開発者は、この場合、それらを圧縮しても意味がないと合理的に判断し、それをそのままアーカイブに配置しました。 そのため、offzipは78 9Cの切望されたバイトをそこに見つけることができず、最終的には展開時にそれらを逃しました。



ファイル構造には圧縮セグメントと非圧縮セグメントを区別するフラグ/機能がないため、ゲームはそれを行います。セグメントがb4kより小さい場合はパックされますが、正確に64kである場合はありません。 ただし、それほど単純ではありません。 （別のゲームでは、別のエンジンで）セグメントをパックした後、その長さが正確に64kのままである場合がありました。 ここでは、圧縮されているかどうかを判断する方法はありません。 このような偶然の可能性は非常に小さいですが、これも考慮に入れる必要があります。



そのため、ファイルを徐々に比較および分析することで、ほとんどの場合、コードをデバッグしなくてもデータ形式を解析できます。 1つの例を使用して形式のすべての機能を解決することはできないため、それらがどのような種類の7で、どのような種類のゼロであるかを判断する方法については詳しく説明しません。 そして、それらを使用する他のゲームがある場合、それを把握します。