REA MCP
☰
JA
● — 人がオンライン ・閲覧 — 回
スポンサー事例を投稿
チュートリアル · 投稿者 edisonZ

この2日間、timelineはREAで溢れており、多くの人が「クローズドソースの商用ソフトウェアはAIに下着まで剥ぎ取られる」と驚嘆している。そのrepo、MCP契約、いくつかのcaseを覗いてみると、底層のロジックは

REA(Reverse Engineer Anything)アーキテクチャを分析したXの長文。そのMCP階層設計、Evidence ID証拠ループ機構を分解し、NotionクリップボードIPC呼び出しチェーンをケースとして取り上げ、最後にその能力境界(バックエンドを貫通できない、ローカルのIDA/Ghidraに依存、VMPパッキングには無効)を議論する。

e
edisonZ@ai_edisonZ

1/

这两天 timeline 上都是 REA,一堆人惊呼“闭源商业软件要被 AI 扒得连底裤都不剩了”。 翻了下它的 repo、MCP 契约和几个 case,底层逻辑其实非常直接,甚至没什么黑魔法。 它没有发明任何新的反编译模型,甚至连一行汇编都没自己解析过。 但为什么它能让 Claude Code 在几分钟内摸清 Notion 的跨进程通信,还能写出 clean-room 复现? 真正的反差和价值在这里。 1. 痛点:为什么以前直接把反编译代码喂给 AI 根本行不通? 大部分人之前都试过把逆向出来的汇编或者混淆 JS 塞给大模型。 结果基本是灾难:几千行剥离了符号名、上下文破碎的代码丢进去,大模型连猜带蒙,80% 的逻辑解释全靠脑补幻觉。 REA 换了个思路:不让大模型在最外层猜,而是做了一个本地运行的 MCP Server,把整个分析链路分层剥离: - 决策层(Claude Code / Codex):理解目标、提假设、定方向,拿到证据后写复现代码。 - 调度层(REA MCP):统一各端逆向接口,输出带 Evidence ID 的结构化证据包。 - 执行引擎(本地工具链):原生程序调 IDA / Ghidra / Hopper 提取汇编与交叉引用;Electron / 前端直接做 AST 静态分析与 Source Map 还原;Android 调 JADX。 2. 核心机制:用 Evidence Loop 压死大模型的幻觉 逆向工程最消耗心力的,从来不是看不懂某段代码,而是在反编译窗口里不断手动追踪交叉引用(Xrefs)、记笔记、拼碎片。 REA 把这个过程变成了 Agent 的“查证循环”: Agent 提出一个假设,工具返回包含精确字节偏移、调用拓扑的证据切片。更关键的是,如果某个静态分析调用图不完整,工具会显式打上“覆盖范围受限”的标记。 这意味着大模型不会把“静态范围内没查到调用”误判为“逻辑上不存在调用”,必须拿着上一轮确凿的 Evidence ID 才能追查下一层,把分析范围逐步收敛。 3. 具体 case:Notion 剪贴板跨进程调用链 看官方追踪 Notion 剪贴板的案例,过程其实非常清晰: 要搞清楚“Notion 网页端点击复制,内容如何写入系统剪贴板”: 1. 扫描前端暴露的 API,定位到 preload 包装函数; 2. 抓取到唯一的 IPC 通道名 notion:clipboard:write; 3. 顺着通道名在主进程代码里定位监听器和权限校验; 4. 最终串出调用 Electron 原生 API 的完整链路。 四步操作,AI 没有猜测任何代码实现,全靠 IPC 通道名这个事实锚点,把跨进程的调用端点严丝合缝拼齐。 4. 别神化它:3 个无法逾越的物理边界 看清它的价值,更要看清它的边界: 1. 零后端穿透力:只能分析本地客户端内的代码。SaaS 产品核心逻辑全在云端服务器,这套工具碰不到分毫。 2. 原生分析高度依赖本地环境:逆向 C/Rust/Go 原生程序,前提是你本机配好了商业版 IDA 或 Hopper / Ghidra,它自己不带反编译能力。 3. 强加固依然是死穴:遇到 VMP 加壳、高强度控制流平坦化混淆,传统工具啃不动,REA 同样抓瞎。 4. 产出的是机制与伪代码,无法凭空还原出 1:1 的原始工程源码。 5. 工程师视角的认知升维 REA 释放出的信号非常明确: 当 AST 静态分析、符号提取和交叉引用追踪被打包成 Agent 的基础工具后,分析客户端的门槛已经从“几天的人力消耗”缩减到“几轮对话的 Token 成本”。 纯靠客户端代码逻辑、前端打包和简单混淆构筑的所谓“技术壁垒”,防守收益正在趋近于零。 客户端代码正在变成全透明的白盒。软件真正的护城河,已经彻底转移到了云端私有数据飞轮、实时业务 Context,以及对用户真实场景的理解深度上。

翻訳済み

この事例について

この2日間、timelineはREAで溢れており、多くの人が「クローズドソースの商用ソフトウェアはAIに下着まで剥ぎ取られる」と驚嘆している。

そのrepo、MCP契約、いくつかのcaseを覗いてみると、底層のロジックは実に非常に直接的で、黒魔術的なものは何もない。 新しい逆コンパイルモデルを発明したわけでもなく、アセンブリを一行たりとも自分で解析していない。

しかし、なぜClaude Codeが数分でNotionのプロセス間通信を把握し、clean-roomでの再現コードまで書けるのか? 本当の対比と価値はここにある。

  1. 痛点:なぜ以前、逆コンパイルコードを直接AIに食わせても全く通用しなかったのか?

ほとんどの人は以前、逆アセンブルしたアセンブリや難読化JSを大規模モデルに投げ込むことを試した。 結果はほぼ災難だった。シンボル名が剥ぎ取られ、コンテキストが断片化した数千行のコードを放り込むと、大規模モデルは当てずっぽうに推測し、ロジック説明の80%は脳内補完の幻覚に頼っていた。

REAは発想を変えた。大規模モデルに最外層で推測させるのではなく、ローカルで動作するMCP Serverを作り、分析チェーン全体を階層ごとに剥離した:

  • 意思決定層(Claude Code / Codex):目標を理解し、仮説を立て、方向性を定め、証拠を得た後に再現コードを書く。
  • スケジューリング層(REA MCP):各端の逆解析インターフェースを統一し、Evidence ID付きの構造化証拠パッケージを出力する。
  • 実行エンジン(ローカルツールチェーン):ネイティブプログラムはIDA / Ghidra / Hopperを呼び出してアセンブリとクロスリファレンスを抽出;Electron / フロントエンドは直接AST静的解析とSource Map復元を行う;AndroidはJADXを呼び出す。
  1. 核心メカニズム:Evidence Loopで大規模モデルの幻覚を押し潰す

リバースエンジニアリングで最も心力を消耗するのは、あるコードが読めないことではなく、逆コンパイルウィンドウで絶えず手動でクロスリファレンス(Xrefs)を追跡し、メモを取り、断片を繋ぎ合わせることだ。

REAはこのプロセスをAgentの「検証ループ」に変えた: Agentが仮説を立てると、ツールは正確なバイトオフセットと呼び出しトポロジーを含む証拠スライスを返す。さらに重要なのは、ある静的解析呼び出しグラフが不完全な場合、ツールは「カバレッジ範囲制限」というマークを明示的に付けることだ。

これは、大規模モデルが「静的範囲内で呼び出しが見つからなかった」ことを「論理的に呼び出しが存在しない」と誤判定しないことを意味する。前ラウンドの確固たるEvidence IDを持って初めて次の層を追跡でき、分析範囲を徐々に収束させる。

  1. 具体的なcase:Notionクリップボードのプロセス間呼び出しチェーン

公式がNotionクリップボードを追跡したケースを見ると、プロセスは実に非常に明確だ: 「Notionウェブ側でコピーをクリックしたとき、内容がどのようにシステムクリップボードに書き込まれるか」を解明するには:

  1. フロントエンドが公開するAPIをスキャンし、preloadラッパー関数を特定する;
  2. 唯一のIPCチャネル名 notion:clipboard:write を取得する;
  3. チャネル名に沿ってメインプロセスコード内のリスナーと権限チェックを特定する;
  4. 最終的にElectronネイティブAPIを呼び出す完全なチェーンを繋ぎ合わせる。

4ステップの操作で、AIはコード実装を一切推測せず、IPCチャネル名という事実のアンカーに全靠して、プロセス間の呼び出しエンドポイントを寸分違わず繋ぎ合わせた。

  1. 神格化するな:3つの越えられない物理的境界

その価値を明確に見るには、その境界をさらに明確に見る必要がある:

  1. ゼロバックエンド貫通力:ローカルクライアント内のコードしか分析できない。SaaS製品のコアロジックはすべてクラウドサーバーにあり、このツールは全く触れられない。

  2. ネイティブ分析はローカル環境に高度に依存する:C/Rust/Goネイティブプログラムを逆解析するには、ローカルに商用版IDAまたはHopper / Ghidraが設定されていることが前提であり、それ自体は逆コンパイル能力を持たない。

  3. 強力な加固は依然として死角:VMPパッキングや高強度の制御フロー平坦化難読化に遭遇すると、従来のツールは歯が立たず、REAも同様にお手上げだ。

  4. 出力されるのはメカニズムと疑似コードであり、1:1の元のエンジニアリングソースコードをゼロから復元することはできない。

  5. エンジニア視点の認知次元上昇

REAが放つシグナルは非常に明確だ: AST静的解析、シンボル抽出、クロスリファレンス追跡がAgentの基本ツールとしてパッケージ化されると、クライアントを分析する敷居は「数日の人的消費」から「数ラウンドの対話のTokenコスト」に縮小した。

純粋にクライアントコードロジック、フロントエンドパッケージング、単純な難読化だけで構築されたいわゆる「技術的障壁」は、防御收益がゼロに近づいている。

クライアントコードは完全に透明なホワイトボックスになりつつある。ソフトウェアの真の堀は、すでに完全にクラウドのプライベートデータフライホイール、リアルタイムビジネスContext、そしてユーザーの真実のシナリオへの理解の深さに移行した。

セットアップ

インストール方法は元のソースをご確認ください。

原文 / README

这两天 timeline 上都是 REA,一堆人惊呼“闭源商业软件要被 AI 扒得连底裤都不剩了”。

翻了下它的 repo、MCP 契约和几个 case,底层逻辑其实非常直接,甚至没什么黑魔法。 它没有发明任何新的反编译模型,甚至连一行汇编都没自己解析过。

但为什么它能让 Claude Code 在几分钟内摸清 Notion 的跨进程通信,还能写出 clean-room 复现? 真正的反差和价值在这里。

  1. 痛点:为什么以前直接把反编译代码喂给 AI 根本行不通?

大部分人之前都试过把逆向出来的汇编或者混淆 JS 塞给大模型。 结果基本是灾难:几千行剥离了符号名、上下文破碎的代码丢进去,大模型连猜带蒙,80% 的逻辑解释全靠脑补幻觉。

REA 换了个思路:不让大模型在最外层猜,而是做了一个本地运行的 MCP Server,把整个分析链路分层剥离:

  • 决策层(Claude Code / Codex):理解目标、提假设、定方向,拿到证据后写复现代码。
  • 调度层(REA MCP):统一各端逆向接口,输出带 Evidence ID 的结构化证据包。
  • 执行引擎(本地工具链):原生程序调 IDA / Ghidra / Hopper 提取汇编与交叉引用;Electron / 前端直接做 AST 静态分析与 Source Map 还原;Android 调 JADX。
  1. 核心机制:用 Evidence Loop 压死大模型的幻觉

逆向工程最消耗心力的,从来不是看不懂某段代码,而是在反编译窗口里不断手动追踪交叉引用(Xrefs)、记笔记、拼碎片。

REA 把这个过程变成了 Agent 的“查证循环”: Agent 提出一个假设,工具返回包含精确字节偏移、调用拓扑的证据切片。更关键的是,如果某个静态分析调用图不完整,工具会显式打上“覆盖范围受限”的标记。

这意味着大模型不会把“静态范围内没查到调用”误判为“逻辑上不存在调用”,必须拿着上一轮确凿的 Evidence ID 才能追查下一层,把分析范围逐步收敛。

  1. 具体 case:Notion 剪贴板跨进程调用链

看官方追踪 Notion 剪贴板的案例,过程其实非常清晰: 要搞清楚“Notion 网页端点击复制,内容如何写入系统剪贴板”:

  1. 扫描前端暴露的 API,定位到 preload 包装函数;
  2. 抓取到唯一的 IPC 通道名 notion:clipboard:write;
  3. 顺着通道名在主进程代码里定位监听器和权限校验;
  4. 最终串出调用 Electron 原生 API 的完整链路。

四步操作,AI 没有猜测任何代码实现,全靠 IPC 通道名这个事实锚点,把跨进程的调用端点严丝合缝拼齐。

  1. 别神化它:3 个无法逾越的物理边界

看清它的价值,更要看清它的边界:

  1. 零后端穿透力:只能分析本地客户端内的代码。SaaS 产品核心逻辑全在云端服务器,这套工具碰不到分毫。

  2. 原生分析高度依赖本地环境:逆向 C/Rust/Go 原生程序,前提是你本机配好了商业版 IDA 或 Hopper / Ghidra,它自己不带反编译能力。

  3. 强加固依然是死穴:遇到 VMP 加壳、高强度控制流平坦化混淆,传统工具啃不动,REA 同样抓瞎。

  4. 产出的是机制与伪代码,无法凭空还原出 1:1 的原始工程源码。

  5. 工程师视角的认知升维

REA 释放出的信号非常明确: 当 AST 静态分析、符号提取和交叉引用追踪被打包成 Agent 的基础工具后,分析客户端的门槛已经从“几天的人力消耗”缩减到“几轮对话的 Token 成本”。

纯靠客户端代码逻辑、前端打包和简单混淆构筑的所谓“技术壁垒”,防守收益正在趋近于零。

客户端代码正在变成全透明的白盒。软件真正的护城河,已经彻底转移到了云端私有数据飞轮、实时业务 Context,以及对用户真实场景的理解深度上。

関連作品