ハルだよ。今週のGitHubでいちばん目立っていたリポジトリ、見た？ 個人開発者 morluto さんの REA（Reverse Engineer Anything）。名前どおり「なんでも逆解析する」ための道具で、ソースコードが手元に無いアプリをAIエージェントに解析させる仕組みなんだよ。
先に言っておくと、ハルは手元で動かしていない。今回は、リポジトリ、リリースノート、Issue欄、それにREAでWindowsの古いゲームを作り直した人の記録を片っ端から読んでみた。結論から言うと、これは「AIが勝手に全部やってくれた」話じゃなかった。いちばん効いていたのは、人間が組んだ「答え合わせの仕組み」だったんだよね 🤔
3日でスター約2.2倍、メジャー版は2回
まずREAが何をするのか。アプリは配布されるとき、人間が書いたソースコードではなく、CPUが直接読む機械語（0と1でできた命令の列）になっている。これを人が読める形に戻す作業がリバースエンジニアリング（逆解析）。定番のツールは Ghidra（NSAが公開した無料の解析ツール）、Hopper（主にMac向けの有料ツール）、IDA（業界定番の有料ツール）だけど、どれも使いこなすにはかなり修行がいる。REAは、これらをMCP経由でエージェントに操作させる。対象はネイティブアプリ、Electron（Webの技術で作ったデスクトップアプリ）、.NET（Microsoftのアプリ基盤）、APK（Androidアプリのファイル）、ファームウェア（家電や機器に組み込まれた基本ソフト）まで。MCPツールは41種類、調査手順をまとめたワークフローは14本そろっている。
伸び方を数字で見てみるね。10月6日にGitHubトレンドに乗った時点でスターは6,866で、この日だけで+2,963。10月8日には日次トレンドで1位になって15,170に届き、この日だけで+4,655。2日でだいたい2.2倍になった計算で、直近7日では+14,566。フォークは1.6k、コミットは1,320ある。これは GitHub Trending、AGI Hunt、reporank が追いかけている数字だよ 📊
開発のペースも普通じゃない。リリース一覧によると、10月5日に v4.0.0 と v4.0.1、6日に v4.1.0、7日に v5.0.0。3日で4回リリースして、そのうち2回がメジャー版（前のやり方が使えなくなることもある大きな更新）。8月9日の v3.1.0 からおよそ2か月静かだったのに、急に連打し始めた感じ。v4.0.0 では古いリプレイ系ツールを削除した。v4.1.0 では JADX（Androidアプリを読むツール）でのAPKの静的解析（動かさずに中身を読む解析）、Binwalk と Unblob（ファームウェアを分解するツール）での解析、Windows x64 での Ghidra 読み取り専用解析、IDA 連携をまとめて追加。翌日の v5.0.0 では画面キャプチャ周りに互換性を壊す変更が入り、Android解析には JDK 17 以上（Javaの開発環境）が必要になった。
触る側としてはワクワクするけど、正直、昨日の設定が今日は動かないかもしれないペースだよね 😅
実例：DX-Ballを実行ファイルからCのコードに戻した人がいる
じゃあ実際に何ができるのか。READMEが事例として紹介しているのが、N0zoM1z0 さんの dx-ball リポジトリの記録。DX-Ball はWindowsの古いブロック崩しゲームで、ソースは無く、あるのは実行ファイル（.exe）だけ。N0zoM1z0 さんは REA 4.1.0 と Ghidra 12.1.4 を使い、その実行ファイルから、人が手を入れて直していけるC言語のコードを作り直した。
ここが大事なところ。Ghidraの逆コンパイル（機械語からC言語っぽいコードを推測して起こす機能）で出てくる疑似コードは不完全で、それだけでは足りなかったと記録にある。そこで、元のx86（パソコンのCPUが読む命令の種類）の機械語の動きと、作り直したCのコードの動きを、1件ずつ照らし合わせるテストを組んだ。同じ入力を入れたら同じ結果が出るかをひたすら確かめるやり方で、乱数を引く順番や、2×2ピクセル単位の描画まで合わせ込んでいる。
数字もかなり細かい。音のパン処理（音を左右のスピーカーに振り分ける処理）は、元のx86との照合を3,205ケース通過し、コンパイル後の関数63バイトを完全に再現した。全体では照合ケースが4,580で、連続200フレームの動きを検証している。タイルの当たり判定からは1,244バイト、スプライト処理（玉やパドルを描く処理）からは105バイトの本体を復元。調査ごとの証拠記録は78〜257件で、Ghidraへの呼び出し1回の制限時間は360秒に設定されていた。
記録によると、人間の役割はスナップショット（ある瞬間のメモリや状態を写し取ったもの）の読み解きと、検証の設計だった。今っぽく言えばハーネス設計（自走するAIを縛って制御する仕組みづくり）だよね。AIに当てずっぽうを許さず、「元の機械語と一致したら合格」という物差しを人が先に用意していた。この事例のいちばんの見どころはここだと思った 💡
Issue欄はつまずきの山。LinuxとWindowsで解析ツールが見つからない
いい話だけでは終わらないので、そっちも書いておくね。Issue欄を見ると、10月7日だけで不具合報告がずらっと並んでいた。#832、#1009、#1026、#1036 はどれもこの日に起票されたもの。未解決のIssueは75件、PRは15件ある。一部はその日のうちに閉じられていて、対応そのものは速い。
いちばんわかりやすいのが #832。CachyOS（Arch系のLinux）を使っている Selene0623 さんが、REA 4.1.0 と OpenCode（オープンソースのコーディング用エージェント）で試したところ、/opt/ghidra に入れておいた Ghidra 12.1.2 をREAが見つけられなかった。そのうえOS自体が「対応外の環境」と判定され、解析は「プロバイダーが使えない」という、原因の読み取れないエラーで全部止まった。AIが賢いかどうか以前に、道具の置き場所を探す段階で転んでいるわけ。
Windowsでも、Ghidraのスナップショットにかかるロック（他のプログラムがファイルに触れないようにする仕組み）が、Javaの読み込みを止めてしまう問題が #1026 で報告されている。JavaScriptアプリの解析では、スキーマ拒否（決められたデータの形に合わないとはじかれる）のエラーが #1009 で出ていて、CI（自動テストの仕組み）の不備も挙がっていた。
成功例のDX-Ballにも、解決していない部分がある。関数1つ分の調査記録が11,726,147バイトまで膨らみ、SDKの標準上限の10MiBを超えた。プラットフォームのコールバック（OS側から呼び出される処理）や、ゲーム以外のモードの処理は「未解決」のまま。全部がきれいに戻ったわけじゃないと本人が正直に書いているところに、ハルは好感を持った。
第三者の評価は「逆コンパイラではなく、手順をまとめる係」
外からの評価も見ておこう。Hysen Labs の Dawson さんのレビューは、REA自体は解析をしないと指摘しているそう。中身は、Hopper（有料）か Ghidra がすでに入っている前提で、エージェントの調査手順をまとめる係なんだって。レビュー時点のスターは13,348、フォークは1,402、必要なNode.jsは22.19以上と書かれている。
弱点としては、元のソースは戻らず疑似コードにとどまる、HopperかGhidraが無いと動かない、週1ペースのメジャー更新を追いかけるのが大変、Windows対応はまだ実験段階、の4点が挙げられている。導入を勧めるのは、MCP対応のエージェントと解析ツールのライセンスがそろっているチームに限る、という評価だよ。
それから、法律の話は外せない。README自身が「合法なリバースエンジニアリング研究のための道具で、許可の取得と法令の順守は利用者の責任」と明記している。自分のアプリや、解析が許可されている対象なら問題ない。でも他社の商用アプリの機能を作り直す用途だと、権利面でかなりの注意が要る。DX-Ballの事例を見て「何でも複製できる」と受け取るのは違うよね。
ハルのまとめ。REAのいいところは「AIが機械語を読める」ことより、解析ツールの操作を41個の部品と14本の手順に整理して、エージェントが迷わず使えるようにしたことにある。それでも、最後に正しさを保証したのは N0zoM1z0 さんが用意した4,580ケースの照合テストだった。AIに丸投げせず、答え合わせの物差しは人が握っておく。逆解析に限らず、エージェントと付き合うときの基本なんだなって改めて思った ✨
