【ITニュース解説】I tried REA, the #1 trending repo on GitHub — can AI really reverse-engineer a .NET app?

GitHubで最近、「REA（Reverse Engineer Anything）」というツールが大きな注目を集めた。これは、AIを活用してソースコードがないアプリケーションを解析し、場合によっては機械語から元の読みやすいコードに逆アセンブル（機械語をアセンブリ言語に変換すること）できると主張している。特に、.NET開発者の間では、難読化（プログラムの解析を困難にする技術）やNative AOT（プログラムを事前に機械語にコンパイルする技術）によって自分たちのコードや秘密が守られていると考える人も多いため、この主張は大きな波紋を呼んだ。そこで、このREAが本当に効果があるのかを検証するため、筆者は実際にテストを行った。

まず、REAがどのようなツールなのかを理解することが重要である。REAは、それ自体がプログラムをデコンパイル（機械語や中間コードから、元のプログラムに近い高級言語のコードを生成すること）するわけではない。これは、AIエージェントと連携して動作する「調整役」のような存在である。AIエージェントからの質問に対し、REAはGhidra（アメリカ国家安全保障局が開発した無料の逆アセンブラおよびデコンパイラ）などの既存の強力な解析ツールを動かし、その結果をAIエージェントに渡す。そして、AIエージェントがその解析結果を読み解き、元のプログラムの意図を推測して、クリーンで読みやすいコードに再構築するのである。つまり、REAは「デコンパイラに賢いAIの推測能力を組み合わせたもの」であり、コンパイラが行った処理を「元に戻すボタン」ではないことに注意が必要である。

テストのために用意されたアプリは、「Naze Pixel」という約105行のC#コードで書かれたシンプルなものだった。このアプリは、24ビットのBMP画像をASCIIアートに変換する機能を持つ。具体的には、画像を読み込み、グレースケール化し、サイズを縮小し、ディザリング（限られた色数で画像を表現する技術）を適用し、最終的にピクセルを文字にマッピングしてASCIIアートを生成する。このアプリには、実際の多くのアプリと同様に、画像をアップロードするためのAPIキーがコード内に直接埋め込まれているという特徴があった。このAPIキーが、テストにおいて保護されるべき「秘密」として扱われた。

このアプリを、三つの異なる方法でコンパイルし、それぞれのビルドに対してREAの効果を検証した。コンパイル時の設定として、デバッグ情報を含まず、毎回同じバイナリが生成されるようにしている。

最初のテストは、通常の.NETビルドで行われた。NazePixel.dllというファイルが対象である。REAの.NETリーダーは、このDLLファイルを解析し、わずか1.5秒でメソッドのシグネチャ、バイトコードの概要、そして全ての文字列リテラル（プログラム内で直接記述されたテキストデータ）を含む約114KBのJSONデータを出力した。このJSONデータには、APIキーも平文で含まれていた。このJSONデータをAIエージェントに与えたところ、85秒後にはアプリの全アルゴリズムを正確に再構築することができた。AIが再構築したコードを再度コンパイルし、元のアプリと同じ画像で実行した結果、両者の出力のSHA-256ハッシュ（ファイルの「指紋」のようなもので、わずかでも内容が異なると全く別のハッシュ値になる）が完全に一致した。これは、AIがバイト単位で全く同じ出力を再現したことを意味する。一方で、REAを使わず、AIが自力でILSpy（無料の.NETデコンパイラ）を使って解析させた場合、わずか41秒で元のC#コードを回復できた。

二番目のテストは、アプリを難読化したビルドに対して行われた。Obfuscarというオープンソースの難読化ツールを使用して、クラス名やメソッド名を判読不可能なUnicodeスペース文字に変更し、全ての文字列を暗号化した。この難読化されたDLLをREAで解析した結果、文字列リストは空だった。しかし、AIエージェントはREAの出力から約3分でアプリのアルゴリズム全体を再構築し、文字列の暗号化方式（バイトと位置と固定値のXOR）までも解読した。ただし、暗号化された文字列自体は長さから推測する程度で、正確な内容を読み取ることはできなかった。しかし、APIキーは定数としてコード内に存在するため、難読化されたファイル内にも平文で残っていることがAIによって予測され、実際に発見された。難読化は、文字列の暗号化によって一部の情報を隠したが、本当に隠したいAPIキーは守られていなかったのである。REAを使わない場合でも、AIは56秒でデコンパイルし、暗号化を解読してAPIキーを含む全ての文字列を回復できた。

三番目のテストは、Native AOTでコンパイルされた、純粋なx64機械語の実行可能ファイル（.exe）に対して行われた。これは、CIL（共通中間言語）バイトコードを全く含まない、最も解析が困難とされるケースである。REAは、このexeファイルをGhidraに読み込ませ、アプリの文字列を検索し、それらを使用しているコードを追跡することで、関数を一つずつデコンパイルしていった。約18分後、AIエージェントはアプリ全体を再構築し、元のアプリと全く同じロジックとAPIキー、さらには各関数のexeファイル内でのアドレスまでも特定した。この機械語から再構築されたアプリの出力も、元のアプリとSHA-256ハッシュが一致した。この点においては、REAの主張は真実だったと言える。しかし、ここでもREAを使わない場合、AIは自力でPythonスクリプトを書いてディスアセンブル（機械語をアセンブリ言語に変換すること）し、4分足らずで同じ定数、キー、さらには元のクラス名（.NETはスタックトレースのためにこれらをexe内に残すことがある）を回復した。ただし、この際にAIは未知のexeファイルを実行して挙動を確認しており、これはセキュリティ上のリスクがある行為である。

これらのテスト結果からわかることは、REAは確かに有効なツールであり、特に純粋な機械語のアプリケーション解析においては、AIが正確にアプリを再構築するのを助けることができるということだ。しかし、今回のテストで扱ったような小規模なC#アプリケーションの場合、REAを使わないAIの方が常に高速に同じ結果を得ていた。AIは、REAの有無にかかわらず、逆アセンブルやデコンパイルといった逆工学的な作業を自力で行う能力を持っていたのである。REAが真価を発揮するのは、今回テストしなかったような、大規模なネイティブアプリケーションにおいて、AIがPythonスクリプトで即興的に解析するのではなく、信頼性の高いデコンパイラによる詳細な解析と、その根拠となる証拠が必要な場合だと言える。105行程度のC#アプリには、REAはむしろ「やりすぎ」だったという結論である。

この一連の検証から、.NET開発者が学ぶべき最も重要な教訓は、単に特定のツールに関するものではない。それは、難読化もNative AOTも、解析を遅らせることはできるが、コード内に埋め込まれた秘密を完全に保護することはできないという事実である。ユーザーのデバイスに配布されるアプリケーションは、どのような形であれ、その中にある文字列、APIキー、エンドポイントなどの全ての情報が読み取られる可能性がある。アプリケーションのコードに直接埋め込まれた秘密情報は、郵便番号が書かれたパスワードのようなものであり、いつか必ずその秘密が知られるリスクをはらんでいる。したがって、本当に保護すべき重要な秘密情報は、アプリケーション内に直接埋め込むのではなく、開発者が管理するサーバー上のAPIを通じて安全にやり取りするべきである。これが、セキュリティを確保するための最も確実な方法なのである。