ベストアンサー

デコンパイル？について

2007/05/30 22:23

noocyteの回答

noocyte
ベストアンサー率58% (171/291)

2007/06/01 01:17 回答No.5

面白そうな話題ですね．：）自称・リバースエンジニアリング技術のホビー研究家 (笑) としては，逆コンパイラについて書きたいことがたくさんありますが，キリがないので少しだけ…．世界中どこでも，「逆コンパイルは可能か？」という質問をする人がいて，それに対しては「不可能」というのがお決まりの反応のようです．そしてその理由もだいたい判で押したように「コメントやローカル変数名は復元できないから．」 (まあ，誰でもすぐ思いつく理由だからでしょうが．) 「100％元通りのソース」なんてないものねだりをしても「不可能」の一言で片付けられるのがオチなので，ここではどこまで元の構造を復元できる (可能性がある) かについて考えてみます．といっても，復元不可能とわかっている情報 (コメントやローカル変数名など) についてはスッパリあきらめて，復元可能な情報をいかに読みやすい形で表示するか (元通りでなくても読みやすければよい) という目標にすり替えます．以下，その前提でＣ逆コンパイルについて，かなり私の推測・主観入りの難易度判定です． (今思いついたものもいくつかあるので，正確さは全く保証しません．) ・完全に復元不可能な情報の例　・コメント　・外部リンケージを持たない変数名・関数名　　(auto 変数名，static 変数名/関数名など) 　・構造体や共用体のメンバ名　・構造体や共用体の，全く使用されていないメンバのデータ型．　・マクロ定義・復元超容易　・外部リンケージを持つ変数名・関数名．　　(extern "C" 宣言されていない C++ の識別子であれば，型名も復元可能．) ・復元わりと容易　・基本データ型の変数．　・式，関数呼び出し．・復元やや難　・構造体定義　　一ヶ所で一つの構造体のすべてのメンバにアクセスしているコードがあれば　　復元は楽だが，一般にはプログラムのあちこちで異なるメンバにアクセスする　　ことになるので，プログラム全体でそれを調べて情報を総合する必要がある．・復元難　・制御構造．下手をすると goto 文だらけのソースになる．逆にうまくいけば，　　元のプログラムの制御構造にもよるが，スパゲッティ化していたものが　　整理される場合もありうる．制御フローグラフ解析アルゴリズムの出来次第 (たぶん)．・復元超困難　・共用体 (またはキャストしたポインタでアクセスされる変数) 　　コードのどの範囲でどのデータ型としてアクセスしているのか判別が必要．　　データフロー解析，制御フロー解析両面からのアプローチが必要 (たぶん)．・復元不可能？ (決定不可能問題？) 　・ポインタ演算を使うポインタによるアクセス　　ポインタが参照するメモリ領域の１次元的構造を復元する必要があるが，　　動的に変化する可能性もあるので一般には決定不可能？　・関数ポインタ「だけ」を使って呼び出される static 関数　　関数ポインタの値を解析時に決定できなければ，static 関数のエントリ　　ポイントが見つけられない (したがってその関数は逆コンパイル対象にさえ　　ならない) … かも．・復元可能であっても，ソースの表現方法が一義的に定まらないもの．　・例：あるメモリ領域が複数の異なるデータ型としてアクセスされている場合，　　それを共用体として表現するか，それともポインタのキャストで表現するか．Ｃに比べて Java ははるかに逆コンパイルが容易で，1996 年に (たぶん) 初の Java 逆コンパイラ Mocha が公開されて以来，多数の Java 逆コンパイラが公開されています． Java Decompilers http://www.program-transformation.org/Transform/JavaDecompilers Javaコードを守る方法 (あるいは他人のJavaコードを参照する方法) 　Javaコードの逆コンパイルおよび曖昧化の完全ガイド http://www-06.ibm.com/jp/developerworks/java/011026/j_j-obfus.html Java 逆コンパイラはかなり元のソースを復元できるので，これを脅威に感じた Java 業界はさまざまな逆コンパイラ対策ツールを有償・無償で提供しています． Java が逆コンパイルされやすい原因として，CPU 独立なバイトコードを採用しているからだとか，オブジェクト指向だから (失笑) だとか説明しているサイトを見かけたことがあります．しかしこれらはまったく的外れで，私は次のような Java の言語仕様に原因があると思っています． (と偉そうに書くほど Java を熟知しているわけではないので，違っていたら指摘してください．) ・共用体が存在しない．・ポインタ演算が禁止されている．・ポインタのキャストがかなり制限されている．(アップキャストとダウンキャストだけ？) (以上３つを上に書いたＣの場合と比較してください．) それと，・クラスファイルの中に，クラス (構造体) 定義情報が含まれている．じゃ，クラスファイルからそれを削除すればいいじゃん，と思うかもしれませんが， (多分) そうはいきません．(それができるなら上記の対策ツールがやっているはず．) その理由は，・構造体 (インスタンス) のどの位置にどういう型のポインタ (クラス型変数) が　あるかわからないと，ガーベージコレクタが困る … つまり，オブジェクト間の　トラバースができなくなる (はず)．・クラス定義情報がないと，Java のリフレクション機能が使えなくなる (はず)．以上書いたように，Ｃの逆コンパイラは Java に比べて遙かに実現困難で，実用レベルのものは存在しないはずですが，研究レベルとしては多分 dcc が有名 … かな？ (Mocha の作者も dcc の論文を参考にしたらしい．) Dcc Decompiler http://www.program-transformation.org/Transform/DccDecompiler それから，マルウェア解析のために dcc を改造して Win32 PE 実行形式を解析可能にした ndcc というのもあるようです． History Of Decompilation 3 　ndcc decompiler, 2002. http://www.program-transformation.org/Transform/HistoryOfDecompilation3 Machine Code Decompilers http://www.program-transformation.org/Transform/MachineCodeDecompilers The Decompilation Wiki http://www.program-transformation.org/Transform/DeCompilation あぁ，少しだけのつもりだったのに…．orz