Ghidraを使ったEX4解析の実態と、最終的に残る技術的な課題について

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特有の構造が、話をさらにややこしくする

外部関数呼び出しが「見えない」

MT4では、OrderSend()やiMA()やAccountBalance()みたいな関数はすべてMT4ランタイムが提供する外部関数だ。ex4の中には呼び出し部分しか記録されていない。

どの関数を呼んでいるのか、引数が何を意味しているのかを推測するには、MT4の内部仕様を知っている必要がある。しかもこの仕様、公式には公開されてない。

インジケーター呼び出しも同じ

カスタムインジケーターを使っている場合、そのロジックはex4の中には含まれていない。別のex4ファイルとして存在している。つまり、一つのEAを理解するために、複数のファイルを解析する必要がある。

難読化が入ると、もう別次元になる

最近のEAには難読化処理が施されていることが多い。無意味な分岐を大量に挿入する制御フロー難読化、定数や文字列を暗号化するデータ難読化、デバッガの存在を検知して動作を変えるアンチデバッグ——こうなると、もう静的解析だけでは限界だ。

Ghidraでできることと、できないこと

Ghidraでできるのは、構造を把握する、制御フローを可視化する、処理の大まかな流れを理解する——「このEAがどういう設計思想で作られているか」という全体像を掴むことだ。

一方でできないのは、元のソースコードを完全に復元する、難読化を自動で解除する、口座縛りやブローカー制御を取り除く——これらはGhidraだけでは無理だ。解析はできても、解除や再構築はできない。

結局、Ghidraの先に何があるのか

Ghidraを使い切った後に残る道は多くない。

学習として割り切る——「構造が理解できた」「設計思想が掴めた」それで十分という選択。自分で一からEAを書き直すなら、得られた知見は価値がある。

完全に諦める——「ここまでやっても無理だった」その判断も正しい。時間とスキルを天秤にかけて引き返すのは健全な選択だ。

再構築前提で切り替える——口座縛りを解除したい、自分の環境で動かしたい、元の挙動を維持したいという目的なら、解析ではなく再構築が必要になる。これが最終的な到達点になることが多い。

・EAデコンパイル解除はバレる？依頼前に知っておくべき点
・EAデコンパイル解除は違法か？依頼前に整理しておく考え方

まとめ｜Ghidraの先にあるもの

Ghidraを使ったex4解析は、技術的には可能だが、完全な復元には至らない。それは失敗ではない。遠回りでもない。現実的な到達点だ。

だからこそ、解析を学習で終えるか、再構築へ進むか——この判断だけが残る。

静かに、必要な人だけが次に進めばいい。