ランサムウェア被害やディスク故障などで「Visual Basic（VB）で作ったアプリのソースコードが消え、手元にはEXEだけ残った」という状況は珍しくありません。本記事では、VB（VB.NET）製EXEを逆コンパイルして中身を把握し、旧ソース（例：v4.0.3）と差分比較しながらv4.0.5相当の変更点を特定するための、現実的な手順と注意点をまとめます。
結論：VB.NETのEXEなら「dotPeek」と「ILSpy」で中身の把握と差分調査はできる
まず押さえておきたいのは、ここで扱う「逆コンパイル（デコンパイル）」は、主にVB.NET（.NETアセンブリ）として作られたEXEを対象にした話だという点です。VBで作ったアプリでも、VB6（ネイティブ）なのかVB.NET（.NET）なのかで、できることが大きく変わります。
今回のように「v4.0.5のEXEだけが残り、v4.0.3のソースはある」というケースでは、最新EXEを逆コンパイルしてロジックを読み取り、差分ツールで変更点を洗い出して手作業でv4.0.3へ反映するのが、最も確実で現場向きの進め方です。
| やりたいこと | 現実的な到達点 | おすすめツール |
|---|---|---|
| EXEからVBのソースコードへ完全復元 | 完全一致は困難（近似コードになる） | dotPeek / ILSpy（＋必要なら手作業） |
| EXEの中の処理を把握する | クラス構造・メソッド・分岐・例外処理などは高精度で読める | dotPeek（読みやすさ重視） |
| 旧ソースと「VB同士」で差分比較したい | VB出力できる環境だと効率が上がる | ILSpy（特に旧版でVB出力が選べるケース） |
| バグ修正を反映した新EXEを作りたい | 逆コンパイル結果をプロジェクト化→整備→再コンパイルが必要 | Visual Studio（＋dotPeek/ILSpy） |
最初に確認：そのEXEは「VB.NET（.NET）」か？
dotPeekやILSpyが真価を発揮するのは、EXEが.NETアセンブリとして作られている場合です。まずは「.NETとして開けるか」を確認してください。もっとも簡単なのは、ILSpyやdotPeekにEXEをドラッグ＆ドロップして読み込めるかです。
| 確認方法 | 結果 | 判断 |
|---|---|---|
| ILSpy/dotPeekでEXEを開ける | 名前空間・クラス・メソッドが表示される | VB.NET（.NET）の可能性が高い |
| ILSpy/dotPeekで開けない | 解析できない・例外が出る | VB6（ネイティブ）や特殊な保護/難読化の可能性 |
| ファイルの性質 | 「.NET」関連の情報が見える（環境により表示は異なる） | .NETの可能性を補強 |
もしVB6（ネイティブ）だった場合、.NET向け逆コンパイラではソース相当まで戻すのが難しく、専用の解析ツールでも「完全復元」は期待しにくいのが実情です。この記事では、VB.NET（.NET）として逆コンパイルできるケースを中心に解説します。
逆コンパイルで「戻るもの」と「戻らないもの」
逆コンパイルは魔法ではなく、EXE内の中間言語（IL）やメタデータから、ソースコード風の形に再構成する作業です。そのため、復元できる情報と、失われやすい情報があります。
| 項目 | 期待できる度合い | 補足 |
|---|---|---|
| クラス/メソッド構造 | 高い | 追加・削除・呼び出し関係の把握に強い |
| 条件分岐・ループ・例外処理 | 高い | 最適化状況により読みにくくなることはある |
| 変数名 | 中〜低 | PDB（デバッグシンボル）が無いと失われがち |
| コメント | ほぼ戻らない | ソース特有の意図説明は復元不可 |
| フォームデザイナ（WinForms） | 中 | リソースやDesignerコード再構成が必要になりやすい |
| 設定ファイルやリソース | 中 | 埋め込み/外部ファイル/生成タイミングで難易度が変わる |
重要なのは、「完全に元どおり」ではなくても、差分調査やロジック把握には十分役立つという点です。実務では「どこがどう変わったか」を特定できれば目的達成になることが多く、逆コンパイルはそのための強力な手段になります。
dotPeekでVB.NETのEXEを解析する手順（採用されやすい現場解）
JetBrainsのdotPeekは、.NETアセンブリを読みやすい形で確認するのに向いた逆コンパイラです。VBで作られたEXEでも読み込み可能で、最新EXEの中身（クラス構造や処理の流れ）を把握する用途に適しています。
dotPeekが向いているケース
- まずはv4.0.5のEXEの中身を素早く把握したい
- クラスやメソッドの一覧から、変更が入りそうな箇所を絞り込みたい
- 逆コンパイル結果をそのまま「正」として使うのではなく、差分調査・移植作業の材料にしたい
基本手順
- dotPeekを起動し、対象のEXE（v4.0.5）を読み込む
- 左ペインのツリー（名前空間/クラス）から、機能ごとの塊を探す
- メソッド単位で処理を読み、旧ソース（v4.0.3）側で該当する処理を突き当てる
- 必要に応じて、参照アセンブリ（DLL）も一緒に読み込み、呼び出し関係を追う
dotPeekは「見通しの良さ」「追跡のしやすさ」が強みです。“VBの文法で出力されるか”よりも、“変更点の把握ができるか”が重要な局面では、最初の選択肢として非常に優秀です。
作業効率を上げるコツ
- 検索機能で、ボタン名・メニュー名・メッセージ文言などの“手がかり文字列”から該当処理へ飛ぶ
- 例外処理（Try/Catch）や条件分岐の周りに、バージョン差分が出やすい
- 「設定値」「フラグ」「機能ON/OFF」系のロジックは、差分の影響範囲が大きいので優先して確認する
ILSpyで「VBとして書き出して差分比較」を狙う（旧ソースがVBなら強い）
ILSpyは無料で使える.NET逆コンパイラで、環境や版によっては出力言語としてVisual Basicを選択できることがあります。旧ソース（v4.0.3）がVBで残っている場合、逆コンパイル結果もVBで揃えられると、差分比較が一気に楽になります。
ILSpyが向いているケース
- 旧ソース（v4.0.3）がVBで、差分ツールで「VB同士」を比較したい
- dotPeekの表示（C#寄りの表現になることが多い）よりも、VBの文法に近い形で読みたい
- 「ソース復元」ではなく、差分特定を最速で進めたい
注意：逆コンパイル結果は“そのままビルドできる”とは限らない
実際の現場では、ILSpyで逆コンパイルしたVBコードは、Visual Studioでそのままビルドできないことが珍しくありません。理由は主に次のとおりです。
- 逆コンパイル結果は、元ソースの再現ではなく近似コードである
- 最適化の痕跡や、コンパイラが生成した補助コードが混ざる
- 参照DLLの不足、設定、リソース、フォーム周りの情報が欠けやすい
ただし、目的が「旧ソースとの差分比較」なら話は別です。Notepad++、VS Code、WinMerge、Beyond Compareなどの差分ツールで比較する用途では、十分に役立つことが多いです。
旧版を使う場合のセキュリティ注意
ランサムウェア被害直後ほど、復旧の焦りから「どこかのサイトに置かれている古い実行ファイル」を拾いがちです。古い版が必要な場合でも、入手元はできる限り信頼できる配布元に限定し、ハッシュ照合やウイルススキャンなど基本の安全策を取ってください（復旧のつもりが二次感染、が最悪です）。
差分比較の実務フロー：v4.0.3のソースにv4.0.5相当を反映する手順
「逆コンパイルしたコードをそのまま“最新ソース”として採用」するより、差分を材料にしてv4.0.3へ必要な変更だけを移植するほうが、成功率が高く、リスクも下がります。おすすめの流れは次のとおりです。
おすすめ手順（王道）
- v4.0.3のソースをローカルでビルド可能な状態に戻す（参照DLL、設定、ビルド構成を確認）
- v4.0.5のEXEをdotPeek/ILSpyで開き、大きな変更が入った箇所を洗い出す
- 逆コンパイル結果をエクスポート（可能ならプロジェクト化、難しければファイル単位で保存）
- 差分ツールで「旧ソース」と「逆コンパイル結果」を比較し、変更点をタスク化する
- タスク単位でv4.0.3へ反映し、小さくビルド＆動作確認を繰り返す
差分を見るときの“コツ”：比較対象を分けて迷子にならない
逆コンパイル結果は、見た目が元ソースと一致しない部分が必ず出ます。そこで、比較の観点を分けると作業が楽になります。
| 比較対象 | 見るべきポイント | 差分の重要度 |
|---|---|---|
| ビジネスロジック（計算/判定/DB処理） | 条件分岐、例外処理、計算式、SQL、トランザクション | 高 |
| UIイベント（ボタン/メニュー） | クリック時に呼ぶ処理、入力チェック、活性/非活性制御 | 高 |
| フォームDesigner/自動生成コード | コントロール構造、初期化、リソース参照 | 中（差分は出やすいが本質ではない） |
| バージョン情報/属性/メタデータ | AssemblyInfo、FileVersion、ProductVersion、署名 | 中 |
| ログ/メッセージ文言 | 文言変更、出力箇所、ログレベル | 低〜中（運用に影響するなら上げる） |
差分の“見つけ方”：文字列から辿るのが最短
逆コンパイル作業で最も時間を節約できるのは、画面に出る文字列（ボタン名、エラーメッセージ、帳票タイトル）から検索して処理へ辿る方法です。機能単位で最短距離で到達できます。
例：
- 「保存に失敗しました」「入力が不正です」など、ユーザーが見る文言を検索する
- メニュー名や画面タイトルを検索して、画面遷移の起点を掴む
- テーブル名・カラム名・ストアド名が残っているなら、DB処理へ直行できる
重要：ツール内でコードを消しても、元のEXEは書き換わらない
逆コンパイルの画面で表示されるコードは、EXE内のIL（中間言語）を解析して「ソースコードっぽく見せている」だけです。表示されたプロシージャを削除しても、元のEXEの動作は変わりません。
「バグのある箇所を見つけて消したのに、これで直ったのか分からない」という疑問は、ここを理解すると解消します。ツール内で編集したものは、基本的に閲覧用メモです（例外的に、別機能としてIL書き換えを提供するツールもありますが、復旧・保守の観点では推奨しません）。
バグ修正をEXEに反映する正しい手順：プロジェクトを再構成して再コンパイルする
逆コンパイル結果を使って修正を反映したい場合は、次の流れが必要です。
- dotPeek/ILSpyで得たコードを、Visual Studioで新規プロジェクトとして取り込む
- 参照設定、リソース、フォーム、設定ファイルなどを整備して、ビルドできる状態に持っていく
- バグ箇所を修正する
- 再コンパイルして新しいEXEを作成し、動作確認する
つまり、元のEXEは“そのまま残り”、修正した新EXEを別物として作ります。運用上は、ファイル名やバージョン（例：4.0.6など）を明確にして、混同しないようにするのがおすすめです。
再ビルドが通らない典型パターンと対処の考え方
逆コンパイルからプロジェクト化して再ビルドを狙うと、ほぼ確実に「エラーだらけ」になります。これは異常ではなく、逆コンパイルが近似コードである以上、ある程度は避けられません。よくある詰まりポイントと、現実的な対処方針を表にまとめます。
| よくある問題 | 症状 | 対処の方針 |
|---|---|---|
| 参照DLLが足りない | 型が見つからない、名前空間が無い | EXEと同じフォルダのDLL回収、NuGetの再追加、バージョン合わせ |
| ターゲットCPU/プラットフォーム違い | x86依存で落ちる、COM連携が失敗する | 元EXEに合わせてx86/x64/Any CPUを合わせる |
| WinFormsのDesigner/リソース周り | フォームが開かない、InitializeComponent関連エラー | Designerコードと.resxを再構成、フォームは最悪作り直して配線し直す |
| アプリ設定（Settings） | My.Settings参照でエラー | プロジェクト側に設定を復元、app.configの再作成 |
| 署名/強名付け | 署名が一致しない、参照が壊れる | まずは署名無しでビルド→後で必要なら署名戦略を検討 |
| 難読化/保護 | 読めない名前、制御フローが崩れる | 可能なら“難読化前”の成果物を探す。復旧コストが跳ね上がる前提で計画 |
再ビルドを狙うより、差分移植の方が早いケース
逆コンパイルしたコードから「完全なプロジェクトを復元して、そこで保守を続ける」ことは可能性としてはありますが、次の条件が揃うと工数が膨れやすいです。
- フォームが多い（WinFormsで画面数が多い）
- 外部ライブラリが多い（独自DLL、古いCOM、特殊なドライバ連携など）
- 設定/リソース/帳票/画像など“コード以外”が多い
この場合、v4.0.3のソースを基点にして、v4.0.5の差分だけ移植したほうが、品質もスピードも出ます。「逆コンパイル結果を新しい正本にする」より、「差分の設計図として使う」発想に切り替えると失敗しにくくなります。
差分移植を成功させるためのチェックリスト
「どこが変わったか」を見つけても、移植後に動かない・別の場所が壊れる、が起きがちです。移植の精度を上げるために、確認項目をチェックリスト化しておくと再発防止にもなります。
| チェック項目 | 見る場所 | 確認の狙い |
|---|---|---|
| 新規メソッド/クラスの有無 | 逆コンパイル側の追加ファイル、名前空間 | 機能追加の取りこぼし防止 |
| 分岐条件の変更 | If/Select Case、例外処理の分岐 | 不具合修正や仕様変更の核心になりやすい |
| 入出力（UI/DB/ファイル）の差分 | SQL、ファイルパス、シリアライズ、API呼び出し | 互換性や運用影響を見落とさない |
| 設定値・定数・列挙 | Const、Enum、設定クラス | 微差が致命傷になりやすい |
| 例外メッセージ/ログ | Try/Catch、ログ出力 | 障害解析のしやすさを回復させる |
逆コンパイルを使うときの法的・倫理的な注意
自作アプリや、権利的に問題のない範囲での調査・復旧目的であれば、逆コンパイルは現実的な復旧策になりえます。一方で、他者のソフトウェアを無断で解析してライセンス回避や複製に使う行為は、契約違反や法的問題になり得ます。対象が自分の開発物であること、または権利上の許諾があることを前提に進めてください。
復旧できたら必ずやる：二度と「EXEしか残らない」を起こさない仕組み
今回のような状況は、技術的には“戻せることもある”一方で、復旧コストが高く、品質リスクもあります。復旧と同時に、再発防止の仕組みを作るのが最も重要です。
最小構成で効く対策
- Gitなどのバージョン管理を導入し、変更履歴を必ず残す
- 3-2-1バックアップ（媒体を分ける・オフラインを混ぜる・世代を持つ）を徹底する
- クラウドストレージを使う場合は、バージョン履歴（世代管理）が有効なものを選ぶ
- 開発PCとは別の場所へ、自動で定期バックアップする
ランサムウェア対策として現場で効く観点
| 対策 | 狙い | 現場のポイント |
|---|---|---|
| OS・開発ツールの更新 | 侵入経路の封鎖 | 「更新を止めない」運用にする |
| 権限の見直し | 感染時の被害範囲を縮小 | 普段は標準ユーザー、必要時だけ昇格 |
| バックアップのオフライン保管 | 暗号化巻き込みを回避 | NASだけに頼らず、世代管理＋隔離を必ず入れる |
| 重要フォルダの保護 | ソースを守る | ソースコード、鍵、証明書、設定を優先保護 |
よくある質問
逆コンパイルしたコードは、元のソースと同じになりますか？
同じにはなりません。コメント、変数名、構造の一部は失われている可能性が高く、最適化の影響で読みづらい形になることもあります。ただし、メソッドの追加・削除や分岐の変更など、仕様差分を特定する用途には十分です。
ツールでコードを編集したら、EXEの動作も変わりますか？
基本的に変わりません。ILSpyやdotPeekの表示は解析結果であり、表示上の編集は元EXEに反映されないのが普通です。動作を変えるには、プロジェクト化して再コンパイルし、新しいEXEとして作り直す必要があります。
差分比較を最短でやる方法は？
v4.0.3のソースを基点に、v4.0.5のEXEを逆コンパイルして、差分ツールで比較しながら変更点だけ移植する方法が最短になりやすいです。特に、画面に出る文言や設定キーなど検索できる手がかりから辿ると効率が上がります。
フォーム（WinForms）が多い場合はどうするのが現実的？
フォーム周りは復旧難易度が上がりやすいので、まずはロジック（処理部分）を優先して差分移植するのがおすすめです。画面の見た目や配置は最悪作り直せますが、業務ロジックの取りこぼしは致命傷になりやすいからです。
「VBで出力された逆コンパイル結果」が欲しいのですが？
環境や版によってはILSpyでVB出力が選べることがあります。VB同士で比較できると移植作業が楽になりますが、逆コンパイル結果はビルド用途よりも差分調査の材料として使うのが安全です。
コメント