REA 逆向工程：AI Agent 拆解執行檔後，軟體服務商如何提升長期產品價值並維持穩定訂閱收入？

要讀懂一個沒有原始碼的程式，過去得先熟悉反組譯器、處理器指令和一堆分析工具。程式可以執行，功能也看得見，但它到底怎麼做到，往往只有少數人有能力追下去。

REA 把逆向工程工具接進 coding agent，讓 agent 可以針對執行檔提問，再沿著反組譯結果、呼叫關係和程式資料繼續追查。對我來說，重點是 AI 正在降低理解軟體的門檻：過去得先熟悉分析工具才能開始，現在可以先提出問題，再依據工具回傳的證據往下查。[1]

如果分析對象已有原始碼，可以對照我寫過的用 AST 與知識圖譜協助 agent 追蹤 codebase；REA 處理的則是封裝在執行檔裡的行為。

從執行檔一路追到功能

REA 的 DX-Ball 案例展示了這種分析方式。反編譯器一開始把目標函式顯示成沒有參數、只呼叫 __ftol()；往下看原始 x86 指令，才發現它從 stack 讀取輸入。再追 caller、比對常數，才能理解這段程式如何計算音效的左右聲道位置。

REA 案例頁公開了分析過程，重建專案也提供對應的 dxball_screen_pan 實作和調查筆記。專案回報重建版本通過 3,205 個原始 x86 測試案例，並重現該函式的 63 個編譯位元組。[2] [3] [4]

《東方幻想鄉》TH04 的案例也沿著相似路徑，從原版 DOS MAIN.EXE 追查 16 發彈幕環的角度計算，再對照公開重建專案的程式碼。專案的編譯檢查記錄顯示，包含這個 helper 的彈幕程式區段有 2,139 個位元組吻合原始執行檔。這是局部程式碼的重建與比對，不能解讀成整款遊戲都已完整還原；但它讓人看見，執行檔裡的功能可以被逐段理解，並拿重建結果回頭驗證。[5] [6] [7]

這些案例把逆向工程的範圍縮到單一功能：agent 代為操作分析工具，沿著反組譯、呼叫關係與資料線索，逐步追查執行檔裡的程式行為。

當功能更容易重作，軟體還怎麼賣？

如果每個人都能用 agent 問出程式怎麼運作，甚至做出功能相近的版本，人和人之間的資訊落差可能會縮小。過去靠著程式封閉、技術門檻或昂貴工具建立的優勢，可能不像以前那麼穩固。技術上能重作一項功能，和法律上能不能重作仍是兩回事；但重作成本下降，本身就會改變使用者和軟體商之間的議價關係。

這也讓我想問：如果一套服務的價值只剩幾個可以被快速模仿的功能，使用者為什麼要一直付訂閱費？服務商又要靠什麼留下客戶？軟體的價值或許會更集中在持續交付的部分：可靠度、更新、資料管理、團隊協作、技術支援、與其他系統整合，以及讓使用者放心把工作交給它的信任。

我也還沒有答案。要打造大型、精緻、需要多年投入的軟體，團隊得相信自己有機會回收成本。如果 agent 讓成果更容易被拆解和複製，誰還願意投入這麼多心力做出下一個大作？使用者願意為哪些持續價值付錢？又要怎麼讓創作者在功能被模仿後，仍能從自己的投入中得到回報？

REA 展示了 agent 如何降低理解執行檔的門檻，也讓我想到另一個更難的問題：當更多人都能理解並重做功能，哪些軟體仍值得開發？商業模式又要怎麼跟著改變？

參考資料

以下來源支援 REA 與案例的事實描述；文末對資訊落差和商業模式的提問是本文的延伸觀察。

• [1] morluto，〈REA README〉
• [2] REA，〈DX-Ball 音效定位分析案例〉
• [3] N0zoM1z0，〈DX-Ball 重建專案：gameplay.c〉
• [4] N0zoM1z0，〈DX-Ball 調查筆記與證據參照〉
• [5] REA，〈TH04 彈幕模式重建案例〉
• [6] N0zoM1z0，〈TH04 原始碼重建專案〉
• [7] N0zoM1z0，〈TH04 彈幕角度程式碼〉