PE インスペクター: Windows EXE・DLL ビューア

使い方

1. ファイルを枠にドロップします。.exe、.dll、.sys ドライバー、.ocx コントロール、.efi バイナリはどれも同じように解析されます。拡張子で決まるわけではありません。
2. ヘッダーのタイルでアーキテクチャ、PE32 か PE32+ か、EXE か DLL か、サブシステムを確認します。同じプログラムのコンソール版と GUI 版はここだけが違います。
3. 堅牢化のチップを見ます。現行の Windows ツールチェーンは ASLR、DEP、CFG を既定で有効にするため、新しいバイナリで黄色が出たら配布前に理由を説明できるようにしておきます。
4. インポートから必要な機能を探します。WS2_32 はソケット、WININET や WINHTTP はウェブ通信、ADVAPI32 はレジストリやサービス、CRYPT32 は証明書を意味します。
5. セクション表で書き込みと実行が同時に可能なものを、データディレクトリで証明書・デバッグ項目・CLR ランタイムヘッダーを確認します。最後のものは他の読み方そのものを変えます。

よくある質問

署名のチップが出ています。安全なファイルということですか。

いいえ、そこは区別が要ります。このチップは証明書データディレクトリが空でないこと、つまり最後のセクションの後ろに Authenticode のブロブが付いていることだけを示します。そのブロブが前のバイト列と一致するか、署名証明書が Windows の信頼するルートまでつながるか、署名時点で証明書が有効だったか、署名者がファイルの主張どおりの相手かは何も分かりません。自己発行の証明書で署名し直しても、署名後に中身を書き換えてハッシュが合わなくなっても、ディレクトリは埋まったままです。きちんと検証するにはチェーン全体と失効情報、多くの場合は信頼できるタイムスタンプの副署名まで必要で、これはネットワーク処理であり、ファイルを絶対にアップロードしないと約束したブラウザツールの範囲外です。

高エントロピー ASLR は通常の ASLR と何が違うのですか。

通常の ASLR も読み込み時にイメージをランダムなベースへ動かしますが、32 ビット Windows では実際にランダムなビットが 8 ビット程度しかなく、総当たりで抜けてしまいます。HIGH_ENTROPY_VA は 64 ビットのアドレス空間のどこに置いても安全だとローダーに伝えるもので、ランダムなビットが 17 ビット以上になり推測が現実的でなくなります。この旗は DYNAMIC_BASE も立っている PE32+ イメージでのみ意味を持ち、さらにプログラムがポインタを 32 ビットに切り詰めないことが前提です。リンカーが /HIGHENTROPYVA の後ろに置いている理由であり、32 ビット時代のコードを引き継いだ 64 ビットバイナリがあえて外していることがある理由でもあります。

インポートした関数が名前ではなく #12 と表示されるのはなぜですか。

そのファイルが序数でインポートしているからです。サンク配列の各要素は最上位ビットがフラグのマシンワードです。そのビットが立っていれば下位 16 ビットが序数で、インポート側のファイルには名前がどこにも保存されません。ビットが下りていれば残りはヒント/名前ペアを指す RVA で、名前がそのまま入っています。序数インポートは解決がわずかに速く古いコードでよく使われました。どの API を呼んでいるか隠したい場合にも現れます。このツールは推測せずに生の序数を出します。序数と名前の対応はエクスポート側の DLL にあり、インストールされているバージョンによって変わるからです。

書き込みと実行の両方が可能なセクションがあります。どの程度まずいのですか。

目を留める価値はありますが、それだけでは証拠になりません。通常のコンパイラとリンカーは .text を読み取りと実行、.data を読み取りと書き込みにし、両方を重ねません。DEP はまさにその組み合わせを例外にするために存在します。IMAGE_SCN_MEM_WRITE と IMAGE_SCN_MEM_EXECUTE が同時に立つセクションは、たいてい実行時にコードを自分のセクションへ展開してそこへ飛ぶランタイムパッカーによるものです。UPX はそのセクションを UPX1 と名付けます。古いインストーラー、自己書き換え型の保護、イメージ内に確保する JIT も原因になります。どれも想定していないなら、動かす前に理由を理解しておくべきです。

リンク時刻が 1970 年や未来の日付になっています。壊れているのですか。

まず違います。TimeDateStamp はリンカーが埋める 1970 年起点の 32 ビット秒フィールドですが、現代のツールチェーンはこれを日付として扱わなくなりました。再現可能ビルドは同じソースから常に同一のバイト列が出るようにゼロや固定値を入れますし、MSVC の /Brepro は入力のハッシュを書くので、暦の上では任意の、しばしば遠い未来の点に落ちます。ツールチェーンを推し量るなら Rich ヘッダーやデバッグディレクトリのほうが手がかりになりますし、どれもファイルが実際にいつ配布されたかの証拠ではありません。日付の形をしたメタデータだと考えてください。

.NET アセンブリなのに、インポートとエントリポイントがほとんど空に見えます。

マネージドアセンブリでは PE の部分が殻だからです。CLR ランタイムデータディレクトリ(14 番、COM ディスクリプタ)が空でないとき、本体は .NET メタデータの中の IL であり、ネイティブヘッダーは主に Windows ローダーを満足させるために存在します。典型的な C# の実行ファイルはインポートが mscoree.dll の _CorExeMain ひとつだけ、エントリポイントはそこへ飛ぶ二命令、.text セクションは機械語よりメタデータが大半です。そのためアーキテクチャ欄が Intel 386 でも 64 ビットで問題なく動きますし、セクションのサイズはプログラムの規模を表しません。中身を読むには ildasm や ILSpy のような IL 逆アセンブラが必要です。

関連ツール