Might and Magic IIIでのリソース圧縮の解放

DOSBoxデバッガーになった経緯や、16ビットのアセンブラーでリソースファイルMM3.CCを解凍する機能を復元した理由をよく覚えていませんが、それは素晴らしかったです。 このゲームは謙虚なバンドルの最新の販売の一部に登場し、ネットでMM3.CCの圧縮に関連するゲームの変更に関する問題を説明するJeff Ludwigページに出会いました。 特に、次のことが書かれています。

このアルゴリズムはクラックするのが非常に難しく、これまでのところ、このデータを解凍する方法を学んだ人はいませんでした。

呼び出しは受け入れられました。 彼の記事は、彼がアルゴリズムをどのように処理しようとしたかを説明しています。 自分でそれをどのように行ったかを書き留め、最後に、MM3.CCファイルを展開するだけでなく、パックできるオープンソースユーティリティへのリンクを提供します。

ドスパッカー

MM3.EXEを見ると、それは圧縮されていないオーバーレイのある圧縮されたDOS実行可能ファイルであり、その先頭はFBOVです。 DOSコンプレッサーについては何も知りませんでしたが、Jeff Ludwigが「Universal Program Cracker」v1.11と呼ばれるものを使用していることをスパイしました。 バージョン1.10（1997年6月25日リリース）を見つけて、exeを解凍しました。 そして、オーバーレイデータを正しく処理することさえできました。 それでも、私はパッカーの名前を知りたかった。 彼らは私にDetect It Easyプログラムを使用する必要があると言った、そして実際に-それは発行した：

EXECUTRIX-COMPRESSOR(-)[by Knowledge Dynamics Corp] Borland TLINK(2.0)[-]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

歴史の愛好者には、このソフトウェアに関する古いディスカッションスレッドをお勧めします-1991年と1995年から：



https://groups.google.com/forum/#!topic/comp.os.msdos.programmer/QsjHLY6Kb4s

https://groups.google.com/forum/#!topic/comp.compression/IAj2-VHbtl4

IDA DOSローダー

exeを解凍することは良いことですが、適切に分解することはさらに優れています。 残念ながら、IDAはそれにつまずいた。 彼はオーバーレイを正しく検出しましたが、ロードできませんでした。 コードを確認した後、コードのセクションが明らかにスキップされているため、オーバーレイなしで分析すると頭痛になることがわかりました（解凍手順はexeファイルに保存されていますが）。 GoogleでFBOVを検索しているときに、IDA DOSローダーのソースコードに出会い、IDAが問題なくこのオーバーレイをロードできることを確認しました。 IDA DOSローダーのデバッグバージョンを再コンパイルし、その作業をVisual Studioで追跡して、オーバーレイが読み込まれない理由を理解しました。 これを行うには、FBOV構造のいくつかの内部パラメーターを記述する必要がありました。 タイトルの説明は次のとおりです。

 #define FB_MAGIC 0x4246 #define OV_MAGIC 0x564F struct fbov_t { ushort fb; // = FB_MAGIC ushort ov; // = OV_MAGIC uint32 ovrsize; uint32 exeinfo; int32 segnum; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

exeinfo-オーバーレイに保存されている各セグメントを記述する構造体の配列のオフセット（絶対、MZヘッダーの先頭から）。 segnum-セグメントの数。 それらはそのような構造によって記述されます：

 struct seginfo_t { ushort seg; ushort maxoff; ushort flags; ushort minoff; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは理論上すべてであり、IDA DOSローダーでは、これはすべてLoadCppOverlays（）関数で実装されます。 しかし、理論はこのexeで動作しなくなります-真実は、ほんの数バイトが間違っているだけです。 デバッグ中に、exeinfoが前述のセグメントの配列の直後の位置を指していることに気付きました。 LoadCppOverlays（）に1行追加しました：

  fbov.exeinfo -= fbov.segnum*sizeof(seginfo_t);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そしてそれは働いた。 FBOVに関するドキュメントが見つからなかったため、これらのオーバーレイの実装がいくつかあるかどうかはわかりません。 IDA DOSローダーには正しいバージョンでの作業が実装されていると確信しています。なぜなら、それを書いた人が実例でそれを確認したからです。 たぶん、それは知っているMM3開発者の特別な機能だったかもしれません。

アンパッカーを探しています

検索には、DOSBoxデバッガーとint 21h（DOS APIを操作するための標準割り込み）によるブレークポイントのセットを使用しました。 私は、3Dh（ファイルを開く）、3Fh（ファイルを読む）、42h（ファイルを検索する）の機能に特に興味がありました。 そしてすぐに、探していたものが見つかりました。

アルゴリズム分析

現在、パッカー/アンパッカーのほぼすべてのピッキングはHex-Rays Decompilerを介して行われますが、これはそれほど難しくありません。 ただし、アセンブラー16ビットx86では機能せず、動作する可能性は低いです。 最初の静的アンパッカーを作成した2005年に戻ったと思われます。 IDA 4.9の時代でしたが、2006年3月に登場したフローチャートを表示するためのインタラクティブモードさえありませんでした。 アンパッカーのグラフィカルな表現を提供します。







紫色のブロック-アルゴリズムの初期化、茶色-メインのアンパックサイクル、白色-CCファイルのメモリと構造を操作します。 通常、アセンブラからのアルゴリズムの抽出にはいくつかの手順が必要です。



1.データ収集。 複雑さは、アルゴリズムの複雑さに依存します。 計算で使用できる入力および出力バッファー、一時バッファー、変数（ローカルおよびグローバル）、および定数に関する情報を収集する必要があります。 作業を簡素化するには、変数がレジスタの名前（_ax、_bx、_cxなど）に似ているCPUレジスタに割り当てる必要があります。 変数の型は、レジスタのサイズに対応している必要があります。この例では、uint16_tです。 場合によっては、レジスタの8ビット部分へのアクセスを簡素化するために、レジスタをユニオンとして表す方が適切です。 ローカル変数とグローバル変数の操作は、特に最初はかなり複雑です。これは、これが1.2.4バイトを占有する変数型であるか、それとも配列であるかが常に明確ではないためです。 互いに近くにあるメモリアドレスへのアクセスが非常に多い場合、これは配列であると見なすことができ、後で、配列のようにアクセスされた場合、それらを別々の変数に分けることができます。 これは、ローカル変数を操作する場合に特に便利です。したがって、esp / ebpへのすべてのアクセスは、配列を介して処理する必要があります（簡単にするため、_stackと呼びましょう）。 このフェーズでは、既知のデータをすべて初期化することが非常に重要です。



2.サイクルの検索は、私にとって最も興味深いものです。 IDAのインタラクティブなグラフィカルプレゼンテーションは、これに最適なツールの1つです。 最も単純な内部サイクルから始めて、上に行くのが便利です。 各サイクルは、異なる色でペイントしてグループ化できます。 ループをグループ化すると、グラフィカルな表示が簡単になり、内側のループを非表示にすると、次のレベルへのループを見つけることができます。



3.コードの書き換えは最も退屈な部分です。 ブロックごとに、各オペコードまたはオペコードグループを高レベル言語の式に書き換えます。 すべてのサイクルが正しく検出された場合、これを行うのはそれほど難しくありませんが、退屈な作業のように、この部分はエラーを起こしやすいです。 残りのロジックは、高水準言語に簡単に翻訳できる条件式です。 処理済みのブロックを混同しないように、異なる色でマークすると便利です。



4.検証。 ほとんどの場合、初めて仕事をすることはありません。 最初の3つの段階で行われた間違いは一般的であり、見つけるのは困難です。 通常、これらを修正するには、元のコードとバージョンの2つのデバッガーを同時に起動する必要があります。



5.装飾コード。 すべてが機能したら、コードを調べて、以前は一意に識別されなかったすべての変数、配列、および定数を処理するとよいでしょう。 また、変数に通常の名前を付けて、アセンブラーを模倣するオプションの構成要素を取り除くことも有効です。 理想的には、この後、スタックを模倣するx86レジスタまたは配列にちなんで名付けられた変数はないはずです。 すべてが通常の高レベルコードのように見えるはずです。



Might and Magic IIIの場合、すべての段階を経て、最後に作業用のアンパッカーを受け取りました。 セクション4のエラーを回避するために、元のコードのデバッガーで作業し、書き換えられた各シンプルブロックをチェックして、同一のアセンブラーコードを生成しました。 MM3.CCのすべての圧縮ストリームを調べてみると、アルゴリズムのブランチの1つが関与していないことがわかったため、今のところ空のままにしました。 グラフの赤いブロックは、ゲームファイルで実行されていない部分を示しています。







それからアルゴリズムの名前をグーグルで始めました。 コードにある16進定数と「decompress」という単語を検索しました。



「0x13A」解凍

「0x4E6」解凍

「0x274」解凍

「0x139」解凍

「0xFC4」解凍<-成功



Amigaの古いフォーマットのアンパッカーのソースコードを見つけました。 この定数に加えて、MM3にはテーブル定数も提示されていました。 MM3はLZHUFアルゴリズムを使用することが判明しました。 これを学ぶと、さらに受け取ったコードをコーミングし、 このソースからアルゴリズムの欠落部分（赤いブロック）をコピーしました。 MM3バージョンは、いくつかの例外を除いて元のLZHUF実装と同じです-0x20値を使用して辞書を初期化する代わりに、引数から取得した値を使用します。 ファイルMM3.CC内のすべての圧縮ストリームの8ビット値は異なります。 いずれの場合も、これはデータの最も一般的なバイトだと思いました。

MM3.CCパッカー/アンパッカー

私は、他の誰かが使用できる通常のユーティリティを使用して、タイタニック作業を終了することにしました。 CCファイルの形式はXeen Wikiで説明されていますが、この説明はMight and Magic IVおよびVのCCファイルでのみ機能します。MM3.CCは同様のファイル構造を持ちますが、ファイル名と圧縮をハッシュします。 ファイルヘッダーとコンテンツテーブルは、Xeen Wikiで説明されているものとまったく同じです。

 struct FileEntry; struct FileHeader { uint16_t NumberOfFileEntries FileEntry FileEntries[NumberOfFileEntries]; }; struct FileEntry { uint16_t hash; uint16_t offsetLo; uint8_t offsetHi; uint16_t compressedSize; // includes 4 bytes header uint8_t padding; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

FileEntries配列は、次のアルゴリズムで暗号化されます（Xeen Wikiで指定されているものと同じ）。

 void encryptHeader(uint8_t* buf, size_t size) { uint8_t key = 0xAC; for (size_t i = 0; i < size; i++) { buf[i] = _rotr8(buf[i] - key, 2); key += 0x67; } } void decryptHeader(uint8_t* buf, size_t size) { uint8_t key = 0xAC; for (size_t i = 0; i < size; i++) { buf[i] = _rotl8(buf[i], 2) + key; key += 0x67; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

SSコンテナ内のファイルは、16ビットハッシュ（FileEntry.hash）によって識別されます。

 uint16_t hashFileName(const char* fileName) { uint16_t hash = 0; while (0 != *fileName) { uint8_t c = ((*fileName & 0x7F) < 0x60) ? *fileName : *fileName - 0x20; hash = _rotl16(hash, 9); // xchg bl, bh | rol bx, 1 hash += c; fileName++; } return hash; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初の2つのファイルは特別です。 これらは圧縮されていないテキストであり、そのサイズはexeファイルに直接書き込まれるため、変更しない方が良いでしょう。 残りはすべて圧縮されたデータブロックで、各ブロックの先頭に小さな記述子があります。

 { uint16_t decompressionInitializer; uint16_t decompressedSize; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

decompressionInitializerは常に上位8ビットと下位8ビットに8ビット値を格納するため、uint8_tにすることができます。 なぜそのように保存されるのかわかりません。 decompressedSizeはビッグエンディアン値に格納されますが、これも奇妙です。 もう1つの奇妙な点は、ユーティリティを使用して再圧縮した後、MM3.CCファイルが33 Kb減少したことです。 また、MM3.EXEからコンパイルされたファイル名のリストを用意しました。これにより、解凍時に正しいファイル名が取得されます（リストが不完全です-556個のファイル名のうち15個をスキップしました）。 これでほぼ完了です。MM3.CCファイルパッカー/アンパッカーが存在するgithubリポジトリへのリンクを提供しています



github.com/rwfpl/rewolf-mm3-dumper



圧縮はわずかな変更を加えて標準のLHUFから取得され、解凍は3日間のリバースエンジニアリングの結果です。 スクイーザーとアンローダーはバッファーをチェックしないため、深刻な目的で使用することはお勧めしません。 それらの使用は簡単です：

 x:\mm3>mm3_cc_dumper.exe Might and Magic III CC file packer/unpacker v1.0 Copyrigh (c) 2015 ReWolf http://blog.rewolf.pl Usage: Unpack: mm3_cc_dumper.exe dump input_file.cc Pack: mm3_cc_dumper.exe pack input_directory output_file.cc