REA 原生程式分析：什麼觸發了「File too large」？

01. 以錯誤資訊為入口

應用程式拒絕了一個檔案，介面顯示「File too large」。但這個「大」指位元組數、解碼後畫素、壓縮大小，還是服務限制？修改自己的實作前，先還原判斷邏輯。

從目標中選擇一條確切資訊，搜尋原生引擎分析出的字串。沒有結果不代表資訊不存在：它可能已本機化、經過編碼、執行時拼接，或儲存在可執行檔案之外。

npx -y rea-agents@6.4.0 search "/absolute/path/program" --pattern="File too large" --kind strings --provider ghidra --format json

02. 找到使用該字串的函式

取得搜尋結果地址，檢視引用。引用可能指向通用錯誤顯示函式，而非真正的保護條件。繼續追蹤呼叫方，直到找到決定是否報錯的分支。

下方佔位地址必須替換為分析你的二進位檔案時回傳的地址。不同構建的地址不能互換。

npx -y rea-agents@6.4.0 xrefs "/absolute/path/program" --address="RETURNED_STRING_ADDRESS" --provider ghidra --format json
npx -y rea-agents@6.4.0 decompile "/absolute/path/program" --procedure="RETURNED_FUNCTION_ADDRESS" --provider ghidra --format json

03. 還原比較邏輯，確認單位

確定比較兩側的值，追蹤大小值來源、比較前是否做了計算，以及分支使用大於還是大於等於。這些細節決定邊界結果。

把反編譯名稱和型別視為暫定假設。結果不完整時，檢視選定函式的指令和被呼叫函式。即使虛擬碼很簡單，有號或無號、整數寬度和轉換順序也可能改變結果。

使用回傳的函式證據解釋產生此錯誤的分支，把比較值追溯到輸入。確定門檻值、單位、有號或無號和精確比較條件。如果反編譯不完整，檢視指令與相關輔助函式。引用地址，將未確定型別標為未知，不要猜測。

04. 測試邊界，而不只是正常情況

如果還原出的規則門檻值是 L，就按輸入實際單位測試 L−1、L 和 L+1。在應用程式能接收的情況下，也測試零和異常格式輸入。只在你控制的程式副本中執行這些測試。

對於檔案大小保護，紀錄檔案位元組數和實際結果；對於解碼後影象保護，僅改變檔案位元組數未必能觸發相關條件。用相同輸入比較替代實作，並儲存差異。

• L−1：接受還是拒絕？
• L：相等時是否通過？
• L+1：回傳哪個錯誤？
• 異常輸入是否更早在其他分支失敗？

05. 讓結論停留在證據支持的範圍

交付物是一條還原的規則，以及針對它實際執行的測試。本文未對特定目標執行該流程；錯誤文字是範例情境，請替換為你自己的目標。

同樣嚴謹的真實案例，可以看 REA 專案紀錄的 DX-Ball 聲像函式：報告區分了 3,205 組差分輸入驗證和單獨的 63 位元組編譯匹配。兩者都不意味著整款遊戲已重建。請檢視連結中的官方原生分析指南及案例。