デコンパイル？について

質問

この前、ネットでゲームをダウンロードしたのですが、遊ぶ目的ではなくソースファイルが見たかっただけだったのですがコンパイルされていたせいか削除されたせいか見れませんでした。
そこで、デコンパイル？というのを知りました。

コンパイルされたファイルをコンパイル前の状態に戻せるというのですが、本当でしょうか。

また、そのゲームファイルがどのように作られたのか知りませんので恐くてできません。
C(もしくはC++)言語で生成されたファイルなのか、Javaで生成されたファイルなのか分かりませんが そのどちらも通用するデコンパイルって知りませんか？

そのゲームのフォルダではありませんが、別のゲームのファイルにはmakeという名前のファイルがありました。

ご存知の方、教えてください。
よろしくお願いいたします。

回答No.8

noocyte · ベストアンサー

> 構造体情報は実行時、基本的に唯のアドレスのオフセットにしか展開されないわけで、
> (中略)
> # と、またここでもコンパイラを特定することが前提に。

色々な実行ファイル形式やコンパイラの出力を調べたわけではないので
かなり推測混じりですが…

構造体がポインタを使わずにアクセスされている場合には，複数の基本型変数が
構造体メンバなのか，それともバラ売りのスカラ型なのかの判別は困難だと思います．
ただ，処理内容が変わるわけではないので，これは #5 に書いたソースの表現方法の
曖昧さの問題ですね．だから実用上はデフォルトでバラ売りを選んでおいて，ユーザ
の指示があれば構造体にまとめる，という方法がいいのではないかと思います．

他方，構造体がポインタでアクセスされている場合には復元しやすいと思います．
それは必ずしも (ベースアドレス＋オフセット) のようなアドレシングモード
のメモリアクセス命令でなくてもかまいません．
メモリアクセス命令があれば，その参照アドレスのデータフローを逆にたどり，
(ベースアドレス＋オフセット) という演算がなされていれば構造体メンバ
アクセスだと見なしてメモリマップに書き込みます．これをプログラム全体
について行えば構造体が復元できると思います．
(その過程で共用体やポインタのキャストが発見される場合もありますが．
あ，それと，構造体配列の可能性を考えるともっと厄介になりそう…．orz)

> 関数ポインタ経由であろうが、static関数であろうが、
> (最適化で削除されずに)コード領域に残っているなら、
> コード領域を舐めれば対象にできますし。(読み取るのは解析者の仕事では)

はい，既存の逆アセンブラではそうやっているものもありますよね．
それだと，その関数単独 (およびその関数が呼び出している関数群) の
解析はできるので，#5 で書いたような見逃しはなくなります．
それでも次のような問題が残ります．(今，気がつきました．)

実行ファイルのエントリポイント (≒main() … 本当はスタートアップルーチン
だけど) を出発点とする制御フロー／データフロー解析を行うに当たり，
そのような関数 (とりあえず，ここでは孤児と呼ぶことにします) については
関数間の呼び出し関係をたどるグローバルなフロー解析ができません．
したがって構造体や共用体の復元に支障が出る場合があります．一例を挙げると，
孤児とその呼び出し元の間で同じ構造体や共用体にアクセスしていながら，
一方のみが使用しているメンバがある場合です．例えば，

元のソース -----------------------------------------------------------------

struct A {
　　double a1; // size＝alignment＝8，offset＝0 とする．
　　char a2; // size＝alignment＝1，offset＝8 とする．
}; // sizeof(struct A)＝16

static void bar(struct A *pA);

// フロー解析の対象になっている関数
// (逆アセンブラは，これが main() から直接間接に呼び出されること，
// そしてその呼び出し方 (引数の型など) を知っている．)
void foo(…)
{
　　struct A a;
　　void (*f)(struct A*);

　　// ここで色々演算して，最終的な f の値は bar になるが，
　　// 逆コンパイラにはそれがわからないものとする．
　　// また，この関数内では a.a2 には一切アクセスしないものとする．

　　(*f)(&a); // 逆コンパイラには，これが bar を呼んでいることがわからない．
　　:
　　:
}

// フロー解析の対象外の関数 (孤児)
// (逆コンパイラは，これがどこからどのように呼ばれているのかわからない．)
static void bar(struct A *pA)
{
　　// この関数 (およびそれが呼び出す関数) では，
　　// pA->a1 には一切アクセスしないものとする．
　　:
　　:
　　pA->a2 = 'A';
　　:
　　:
}

逆コンパイルされたソース (最大限の可能性を想定した場合) --------------------

// main() を始点とするグローバルフロー解析により復元された struct A．
struct Struct1 {
　　double Struct1_Member1; // (struct A)::a1
　　char Struct1_Unused1[8]; // ８バイトの未使用領域と誤認された．
};

// bar() を始点とするグローバルフロー解析により復元された struct A．
// 逆コンパイラには Struct1 と同一であることがわからない．
struct Struct2 {
　　char Struct2_Unused1[8]; // ８バイトの未使用領域と誤認された．
　　char Struct2_Member1; // (struct A)::a2
　　char Struct2_Unused2[7]; // struct A 末尾のパディング (７バイト)
};

void foo(…)
{
　　struct Struct1 var1; // a
　　void (*var2)(struct Struct1 *); // f

　　:
　　:
　　(*var2)(&var1);
　　:
　　:
}

// bar
static void StaticOrphanFunc1(struct Struct2 *arg1)
{
　　:
　　:
　　arg1->Struct2_Member1 = 'A';
　　:
　　:
}

----------------------------------------------------------------------------

このように，(*var2)(&var1) の呼び出し先がわからなければ，元の struct A に
対して Struct1 と Struct2 の２つの構造体定義ができてしまいます．

もし逆コンパイラのユーザが (*var2)(&var1) が StaticOrphanFunc1 を呼び出して
いることを教えてやれば，(*var2)(&var1) と StaticOrphanFunc1 の引数を照合
することによって Struct1 と Struct2 が同一であることがわかるため，両者を
マージして

struct Struct3 {
　　double Struct3_Member1; // (struct A)::a1
　　char Struct3_Member2; // (struct A)::a2
　　char Struct3_Unused1[7]; // struct A 末尾のパディング (７バイト)
};

のように復元できるはずです．ただしマージ中に衝突 (同じアドレスが異なる
データ型としてアクセスされている) が発見された場合，共用体またはポインタ
のキャストということになるので，#5 で書いたように厄介なことになります．