AI 能把軟體逆向重做嗎？REA 的實際案例、工具與成熟度

REA 讓 AI 接上逆向工程工具，研究一套軟體如何運作，再協助寫出相似功能。這件事已經有具體成果，尤其是追查一個功能、搬移舊程式，以及重建範圍明確的計算。

目前公開證據還不足以支持「給 AI 一套大型商業軟體，就能自動複製整個產品」。理解一個功能、寫出可以展示的版本，以及長期提供可靠服務，仍是三個不同的工程問題。

對非技術使用者來說，值得注意的變化是：我們可以更容易把現成軟體當成研究對象，把「我喜歡這個功能」往前推成「這個功能有哪些規則、我的版本應該怎麼做」。

以下工具與研究資料核對至 2026 年 10 月 12 日。工具功能依官方文件，案例的驗證範圍另行說明。

軟體工程原本往前做，逆向工程從成品往回看

一般開發軟體，先決定要解決什麼問題，再設計規則、寫程式，最後產出可以安裝或開啟的成品。

逆向工程從另一端開始。手上有一個成品，想研究它用了什麼規則、資料如何流動、某個按鈕究竟做了哪些事。

可以把它想成研究一道已經煮好的菜。你可以觀察食材、分析味道、試著重做，但成品不會保留廚師所有的筆記與取捨。

軟體也有類似情況。許多程式在變成可執行檔時，會失去原本的註解、部分名稱與結構。不同的原始碼，也可能產生相同的行為。因此，逆向研究通常在追求可驗證的運作規則，而原作者當年怎麼思考，可能永遠沒有完整答案。

逆向工程已有數十年的歷史。電腦歷史博物館記錄，1980 年代的 Compaq 就曾逆向研究 IBM 的 BIOS，製作相容電腦。軟體相容性、舊系統維護與安全研究，長期都需要這類工作。Compaq 歷史資料

這次的變化，是 AI 開始參與找線索、解釋規則、提出實作與反覆測試。原本高度依賴專家逐步操作的研究流程，多了一個能使用工具的助手。

REA 是什麼？把研究工具交給 AI 使用的一套接口與流程

REA，Reverse Engineer Anything，是一個開源專案。它把原生程式、JavaScript／Electron 應用、.NET 程式與網站等分析入口，接給 AI coding agent 使用，也提供命令列操作。

可以把 AI agent 想成會操作電腦工具的研究助手。REA 提供研究入口；Ghidra、Hopper、IDA 等分析引擎提供底層觀察能力；AI 再根據拿到的資料提出解釋與下一個問題。

其中的 MCP，是讓 AI 呼叫工具的一種接口規格。對讀者來說，只要先理解它的作用：AI 可以要求工具找出函式、查詢文字、追蹤呼叫關係，而不必只靠猜測回答。

REA 本身需要搭配 agent。分析某些程式還要另外準備引擎。它的開源授權，也不代表整個流程沒有模型、運算或工具授權成本。REA 安裝與運作文件

圖中是 REA 專案提供的 Hopper 畫面：中間列出程式指令，右側是檔案資訊，下方是 Hopper 的腳本操作區，顯示程式分析日誌與執行 Python 腳本的紀錄。這能幫助理解「把分析工具接起來」長什麼樣，並不是一鍵複製產品的畫面。圖片來源：morluto／REA，擷取於 2026 年 10 月 12 日。

研究與開發可以串成以下流程，但每一步都需要對照證據與用途：

flowchart TD
  A[選一個具體功能] --> B[觀察原版與查程式證據]
  B --> C[整理規則與未知項目]
  C --> D[寫自己的功能規格]
  D --> E[開發並對照測試]
  E --> F[使用者試用與修正]

例如「研究這個 App 的 CSV 匯出」，就比「幫我複製這個 App」更容易展開。匯出按鈕從哪裡拿資料？含逗號的欄位怎麼處理？遇到空值會輸出什麼？這些問題有機會找到具體答案，也能設計測試。

REA 已經有哪些案例？先看研究範圍與驗收方法

Notion：研究複製貼上如何保留內容結構

Notion 的產品識別 Logo；此圖沒有呈現研究結果。圖片來源：Notion Labs，Wikimedia Commons 收錄，擷取於 2026 年 10 月 12 日。

Notion 裡面複製一段內容，再貼回 Notion，常能保留原本的結構。單純複製幾個字，為什麼可以做到這件事？

REA 的官方案例從桌面版包裝後的 JavaScript 追下去，找到頁面呼叫、跨程序傳遞與系統剪貼簿之間的關係，也解釋了 HTML 裡的標記如何連回本機保存的內容資料。

可以把標記理解成取件號碼。剪貼簿帶著號碼，程式再據此找回更完整的內容積木。

這個案例完成了特定功能的追蹤。整套 Notion 的多人協作、資料同步與雲端服務，並不在這次研究範圍內。Notion 官方案例

DX-Ball：重建一個左右聲道的計算

老遊戲 DX-Ball 打到不同位置的磚塊時，聲音會偏向左邊或右邊。這個案例研究的是「位置如何換算成左右聲道」。

研究者從原版執行檔找到指令與數字常數，重寫成一個小型 C 函式。官方記錄包含 3,205 組原版行為比較，以及該函式編譯後 63 bytes 的一致性比對。

這裡可以看到比較完整的工程循環：找到規則、重建、拿原版檢查。驗證對象是一個小函式，文章不能把它擴大成整款遊戲已完成重建。DX-Ball 官方案例

Aegis：找出驗證碼為什麼每 30 秒換一次

Aegis 是開源的驗證器 App。REA 的案例從發布的 Android APK 定位驗證碼生成規則，再用可調時鐘的網頁示範，呈現時間如何影響結果。

圖中每一列是一個服務的驗證碼，讓讀者先認識研究對象的日常樣貌。這是 Aegis 官方提供的宣傳截圖，帳號與數字為官方示範內容；不是本文操作 REA demo 或執行 133 組比較的證據。圖片來源：Aegis／Beem Development，擷取於 2026 年 10 月 12 日。

官方另記錄了 133 組提取 Java 方法與重建版本的比較。整理本文資料時，實際操作的是網頁 demo：時鐘跨過 60 秒後，驗證碼改變；內建的 12 組參考檢查全部通過。

這次網頁操作沒有重新跑 APK 逆向，也沒有重做官方的 133 組比較。Aegis 本來就開源，這個案例適合教讀者理解「從成品找到規則，再測試」，不能當成突破閉源軟體保護的證明。Aegis 互動案例

舊桌面玩具：從 Windows 成品移植到 Mac 與網頁

Desktop Games Nostalgia 的作者分享，用 REA 研究舊的 Windows 桌面玩具 stress.exe，再製作 Swift 與網頁版本。專案有公開程式碼與下載入口。

作者自述初步移植花了約 30 分鐘，後續包裝與網頁約兩小時。這是個別作者的工時描述，無法直接推成所有軟體的重建速度。作者使用心得

整理資料時，網頁試玩入口兩次只顯示藍色背景，沒有成功操作遊戲。這個案例可以用來介紹移植方法與公開成果，尚不能寫成本文已驗證全部功能正常。

另外，專案沿用原版圖片與音訊，repo 明列沒有授權。工具開源與目標素材的使用權，必須分開看。

其他案例與指南，可以拿來理解不同做法

這些案例分別呈現功能追蹤、重建、教學與檢查。閱讀時先看「究竟完成了哪一部分」，再看「怎麼證明」，就比較不會被專案名稱或成果影片帶著走。

類似工具有哪些？哪些是 App，哪些要接到既有工具

這個領域有四種常見形式：桌面分析軟體、AI 插件、給 agent 使用的接口，以及帶測試流程的重建框架。

有圖形介面，代表可以操作視窗；是否能像一般辦公 App 一樣容易使用，還要看研究目標與設定。以下的「泛用」，指能處理多個不同樣本或問題，並不保證任意格式都能分析。

開源接口、插件與研究框架

GhidraMCP、ReVa、GhidrAssist 這幾列，最適合已經在用 Ghidra 的人。r2ai 與 radare2-mcp 偏向習慣命令列的人。ReAgent 則把「生成候選程式，再交給檢查」放在較核心的位置。

這張 GhidrAssist 官方截圖把分工放在同一個視窗：左側與中間是 Ghidra 的函式、反編譯程式與指令，右側是 AI 的文字解釋。它呈現的是插件協助研究的介面，面板上的分析仍需查證；並非本文獨立測試結果。手機可點圖開大圖查看。圖片來源：Jason Tang／GhidrAssist，擷取於 2026 年 10 月 12 日。

這次查到的部分工具只有文件與示範，沒有足夠資料支持可重做的完整 App 成功案例。表格因此保留這個差別，沒有為每個名字硬配一個成功故事。

桌面產品、原廠 AI 與商業服務

想在視窗裡研究程式，可以先認識 Ghidra、IDA、Binary Ninja、Hopper、JEB 這類分析軟體。AI 接口或插件是加在這些軟體上的一層。

其中 Ghidra 是開源路線；其餘有各自的商業或免費版本邊界。Frida、x64dbg、Rizin 等則提供執行中觀察、除錯或另一套分析能力，常出現在組合式研究環境裡。

對還沒有工具偏好的讀者，最有用的第一步是看案例與互動示範。若準備實作，再請工程師依程式格式、已有工具與驗收需求選一條路線，不必先把表格裡所有套件裝一輪。

現在成熟到哪裡？從「看懂」到「可靠替代」有幾個階段

前三列已有不同程度的實務用途。最後一列需要同時解決研究、開發、品質與營運，要求高得多。這個成熟度分層是根據工具文件、案例與研究整理的判斷，並非業界統一認證。

研究也顯示，成果高度依賴條件。SRE-Bench 的 2026 年 10 月版本用 19 個非公開程式與不同防分析機制測試 agent；一般公開設定仍有許多未解任務，無預算上限的內部設定與多次嘗試則能產生很高的候選成功率。

兩者必須一起看。多試幾次有機會找到正確候選，但使用者還需要辨識哪一份正確。該研究評量的是指定逆向任務，也不能換算成完整商業產品的複製成功率。

ProgramBench則測試另一種情境：只給成品與文件，靠觀察行為重做程式，並且禁止反編譯與上網。它特別區分「大部分測試通過」與「全部測試通過」。這個設計可以提醒我們留意邊界行為；因為工具限制不同，成績無法拿來當 REA 的實測結果。

AI 能生成正確程式，工程師為什麼還要追查

Binary Ninja 發表的 Windows UCPD 案例，很適合說明驗證工作的難度。

研究者讓 Sidekick 重寫一段解密邏輯，又用 Claude Code 接原生 MCP 做第二份。兩份程式產生相同、看起來無法理解的輸出。

研究者繼續查外部實作，發現雜湊算法的差異。用另一種算法，資料才解成可讀內容。原文推測是驅動程式與資料生成端版本不一致，但沒有在運作中的機器確認這個推測。UCPD 原始研究

這個故事包含 AI 對原版邏輯的重建、人對額外線索的追查，以及最後仍保留的未知項目。兩份相同答案，並不足以讓所有工程問題自動結束。

實際替代軟體也會遇到類似事情。日常資料正常，遇到舊檔案或特殊字元卻壞掉；單人使用順利，多人同時操作才出問題。這些差異需要測試與使用者驗收才能逐步發現。

對軟體工程的革新：研究與開發之間多了一條可反覆走的路

這是一個影響可能很大的變化。AI 已能幫忙寫程式，現在又能更深入研究既有成品，兩端開始連起來。

以前接手沒有原始碼的系統，理解行為可能先花掉大量專業工時。現在，部分搜尋、追蹤與整理能交給 agent，工程師再集中處理關鍵判斷與驗收。

具體用途可以分成幾種：

• 舊系統搬家：保留少數重要功能，改在新平台運作。
• 資料與檔案相容：理解某種輸出規則，讓新系統接得上。
• 維護與除錯：追查沒有文件的行為，補出可用的說明與測試。
• 產品研究：把喜歡的功能拆成規則，再依自己的受眾重新設計。
• 遊戲與軟體保存：研究已停止維護的成品，嘗試恢復可使用的部分。

這些是可能的應用方向。實際能完成多少，仍取決於能拿到哪些程式與資料，以及原版能不能用來對照。

工程師需要的能力也會改變。除了寫程式，還要能定義研究問題、辨識證據、整理未知項目，並設計可以發現差異的測試。

AI 降低部分理解與實作成本後，軟體公司的競爭也可能更重視資料、服務、整合與持續維護。這是根據技術能力推導的產業判斷，還不能宣稱 REA 已經造成整個產業改變。

非技術人員要怎麼用？先做一份能驗收的功能規格

假設你有一套舊的報表軟體，只想保留「讀入資料、算三個欄位、匯出 CSV」。這是示意情境，用來說明交辦方法。

先把原版的正常結果與特殊情況整理出來，再讓工程師或 agent 研究規則。看得懂規則後，才能決定哪些行為要保留、哪些要重新設計。

可以這樣交辦：

請研究這套軟體的 CSV 匯出功能。列出輸入、轉換規則與輸出格式，每個結論附證據。請用空值、逗號、引號與中文資料對照原版結果。把尚未確認的規則另外列出，最後整理成我自己的功能規格與驗收案例。

研究之後可以整理 PRD，也就是產品需求文件。但 PRD 還要加入你自己的用途：誰使用、哪些功能必要、如何處理錯誤，以及什麼結果算完成。

這份規格可以交給開發。逆向研究補上既有行為的證據；使用者補上用途與取捨。兩邊都清楚，才有比較可靠的替代目標。

能批量研究嗎？先批量盤點，再逐項驗收

REA 與部分競品提供命令列、無視窗分析或批次清單，所以可以讓腳本依序分析多個檔案，保存結果，再交給 AI 整理。REA 命令列文件、ReAgent 批次流程

批量容易擴大的是「找出有哪些函式、依賴與可疑差異」。批量重建還需要逐項定義輸入輸出與測試，不能只根據摘要寫著成功就算完成。

比較可行的起步方式，是先選一個小功能，記錄花費、未知規則與測試結果。確認這套方法對你的軟體有效，再把同類型的研究排成清單。

廠商會因此把功能搬到雲端嗎

本機成品可以被取得與研究，雲端核心程式通常不在使用者電腦上。這確實會影響可以看到多少內部規則。

研究網站的人，可能看得到前端程式、請求與回應。伺服器內的資料庫、排程、模型與內部管理功能，需要另外的觀察來源，不能從一個登入畫面完整還原。

因此，更多廠商可能考慮把核心能力留在伺服器。但目前本文沒有證據能把特定公司的雲端化決策歸因於 REA，也無法據此推定買斷軟體必然消失。

對使用者來說，替代軟體的評估仍要回到實際工作：能不能匯出資料、能不能離線、遷移成本多少，以及新版出了問題誰維護。省下授權費後，這些成本仍然存在。

如果想開始試，先列出最想保留的三個功能，準備幾份原版的輸入與結果。再從其中一個功能做研究與重建，比直接要求 AI 接手整套軟體更容易知道有沒有完成。

本文介面圖與 Logo 為各專案或產品的素材，來源標在圖旁；素材授權與權利說明。

本文關鍵字：REA、逆向工程、AI Agent、Ghidra、軟體重建、功能規格、PRD、軟體相容性