デコンパイル可能性を診断
5つの質問で診断します（所要時間：約1分）
ex4ファイルをGhidraで開いてみようと思った時点で、あなたはもう初心者ではない。
一般的なデコンパイルツールは試した。 コードらしきものも見た。 でも、そこから先に進めなかった。
だから、Ghidraに辿り着いた。
私はEX4デコンパイルを専門に扱うエンジニアとして、「Ghidraを使ってみたけど、結局どうすればいいのか分からない」という相談を何度も受けてきた。
結論から言うと、 Ghidraは確かに強力だが、それでもex4解析には固有の壁がある。
そして、それは技術力の問題ではない。 構造上の問題だ。
Ghidraでex4を開こうとしたときに起きること
まず前提として、Ghidraは汎用的なリバースエンジニアリングツールだ。
ELF、PE、Mach-O… さまざまなバイナリ形式に対応している。
だが、MT4のex4は、その「さまざま」の中に含まれていない。
ex4は独自フォーマット
ex4ファイルは、MetaQuotes社が独自に設計したバイトコード形式で構成されている。
つまり、
標準的なバイナリとは構造が違う。 命令セットも異なる。 セクション分割の概念も独自だ。
Ghidraにex4をそのまま放り込んでも、 「Unknown Format」と言われるか、 誤った形式として読み込まれるだけだ。
カスタムローダーが必要になる
Ghidraでex4を解析するには、カスタムローダーを用意する必要がある。
これは、
ex4のヘッダ構造を解釈し、 バイトコードをGhidraが理解できる形に変換し、 セクションやシンボルを適切に配置する。
そういう役割を持つスクリプトだ。
問題は、このローダーを書くには、 ex4の内部仕様を理解している必要があるということ。
公式には公開されていない情報を、 逆算して組み立てることになる。
ローダーを用意しても、次の壁がある
仮にカスタムローダーを用意できたとする。
Ghidraにex4が読み込まれた。 逆アセンブル結果が表示された。
ここで、次の現実が待っている。
シンボル情報は失われている
元のソースコードにあった、
変数名 関数名 コメント 引数の意味
これらは、コンパイル時に消えている。
残っているのは、
メモリアドレス 命令列 制御フロー
それだけだ。
だから、Ghidraの画面には、 FUN_00401234とかDAT_00405abcとか、 そんな無機質な名前ばかりが並ぶ。
逆コンパイル結果は「推測の塊」
Ghidraには逆コンパイル機能がある。 アセンブリコードを、C言語風の擬似コードに変換してくれる。
でもこれ、実際に見ると分かるんだけど、 元のコードとは全然違う姿になってる。
たとえば、元のMQL4コードが、
if (OrdersTotal() > 0) {
CloseAllOrders();
}こんな感じだったとする。
でも、Ghidraで逆コンパイルすると、
if (iVar1 > 0) {
FUN_00401678();
}こうなる。
意味は何となく推測できる。 でも、iVar1が何なのか、FUN_00401678()が何をしてるのか、 それは文脈から推測するしかない。
元のロジックを正確に再現できるわけではない。
MT4特有の構造が、話をさらにややこしくする
ex4ファイルには、MT4特有の構造がある。 これが、Ghidraでの解析をさらに難しくする。
外部関数呼び出しが「見えない」
MT4では、OrderSend()とかiMA()とかAccountBalance()みたいな関数、 これ全部、MT4ランタイムが提供する外部関数なんだよね。
で、ex4の中には、 その呼び出し部分しか記録されていない。
だからGhidraで見ると、単なるアドレス呼び出しになってる。
どの関数を呼んでいるのか、 引数が何を意味しているのか、 それを推測するには、MT4の内部仕様を知っている必要がある。
しかもこの仕様、公式には公開されてない。
インジケーター呼び出しも同じ
カスタムインジケーターを使っている場合、 そのロジックはex4の中には含まれていない。
別のex4ファイルとして存在している。
Ghidraで解析できるのは、 「インジケーターを呼び出している」という事実だけ。
どんな計算をしているかは、 別途そのインジケーターも解析しないと分からない。
つまり、一つのEAを理解するために、複数のファイルを解析する必要がある。
難読化が入ると、もう別次元になる
最近のEAには、難読化処理が施されていることが多い。
制御フロー難読化
無意味な分岐を大量に挿入し、 実際の処理の流れを見えにくくする。
Ghidraで制御フローグラフを表示しても、 迷路のような図が出てくるだけ。
どれが本当の処理で、 どれがダミーなのか、 判別するのに膨大な時間がかかる。
データ難読化
定数や文字列を暗号化し、 実行時に復号する。
Ghidraの静的解析では、 暗号化された状態のデータしか見えない。
動的解析を組み合わせないと、 実際の値は分からない。
アンチデバッグ
デバッガの存在を検知して、 動作を変える仕組み。
Ghidraで解析しながら動かそうとすると、 EAが異常終了したり、 意図的に誤った動作をする。
こうなると、もう静的解析だけでは限界だ。
Ghidraでできることと、できないこと
ここまでの話を整理すると、
Ghidraでできること
構造を把握する 制御フローを可視化する 処理の大まかな流れを理解する 特定の関数の挙動を推測する
これらは可能だ。
特に、
「このEAがどういう設計思想で作られているか」 「どんな処理の順序で動いているか」
こういった全体像を掴むことには向いている。
Ghidraでできないこと
元のソースコードを完全に復元する 変数名や関数名を復元する 難読化を自動で解除する 口座縛りやブローカー制御を取り除く
これらは、Ghidraだけでは無理だ。
解析はできても、解除や再構築はできない。
結局、Ghidraの先に何があるのか
Ghidraを使い切った後に残る道は、実は多くない。
学習として割り切る
「構造が理解できた」 「設計思想が掴めた」
それで十分、という選択。
自分で一からEAを書き直すなら、 得られた知見は価値がある。
完全に諦める
「ここまでやっても無理だった」
その判断も、正しい。
時間とスキルを天秤にかけて、 引き返すのは健全な選択だ。
再構築前提で切り替える
「口座縛りを解除したい」 「自分の環境で動かしたい」 「元の挙動を維持したい」
この目的なら、 解析ではなく再構築が必要になる。
Ghidraで得た情報を元に、 同じ挙動を再現する形でコードを書き直す。
これが、最終的な到達点になることが多い。
このあたりの考え方については、以下の記事も参考になるかもしれない。
・EAデコンパイル解除はバレる？依頼前に知っておくべき点
・EAデコンパイル解除は違法か？依頼前に整理しておく考え方
Ghidraを試した後に気づくこと
Ghidraまで使った人は、 もう一度ツール探しに戻ることはほとんどない。
理由は明確だ。
ツールの限界を理解した ex4解析の本質的な難しさを見た 次に進むしかないと分かった
この状態になると、 選択は自然に決まる。
技術的な興味と、実用目的は別
もしあなたが、
「技術的にどこまでできるか試したい」 「リバースエンジニアリングを学びたい」
そう思っているなら、Ghidraは良い教材になる。
実際、私も最初はそうだった。
時間をかけて、 ex4の構造を調べ、 ローダーを書き、 逆アセンブル結果を眺めた。
それで得られた知見は、確かに価値があった。
だが、
「とにかく動かしたい」 「早く結果が欲しい」
そういう目的なら、 Ghidraに時間を使うのは現実的ではない。
何を優先するかで、道は変わる
技術を学びたいのか。 結果が欲しいのか。
それによって、選ぶべき道は違う。
Ghidraは強力だが、万能ではない。
ex4解析においては、 構造を理解するためのツールとして使うのが、最も現実的だ。
その先に進むかどうかは、 あなたが何を求めているかによる。
最終的に残る課題
Ghidraでex4を解析しても、 最終的に残る課題がある。
MT4特有の構造 EA固有の設計思想 再構築前提の作り
これらは、 ツールだけでは解決しない。
人間が判断し、 設計を読み替え、 同じ挙動を再現する。
そういう作業が必要になる。
これは、力技ではない。 一番丁寧で、再現性の高いやり方だ。
まとめ｜Ghidraの先にあるもの
Ghidraを使ったex4解析は、技術的には可能だが、完全な復元には至らない。
それは、
失敗ではない。 遠回りでもない。 現実的な到達点だ。
だからこそ、
解析を学習で終えるか。 再構築へ進むか。
この判断だけが残る。
静かに、 必要な人だけが次に進めばいい。
