REA 原生程序分析：什么触发了“File too large”？

01. 以错误信息为入口

应用拒绝了一个文件，界面显示“File too large”。但这个“大”指字节数、解码后像素、压缩大小，还是服务限制？修改自己的实现前，先还原判断逻辑。

从目标中选择一条确切信息，搜索原生引擎分析出的字符串。没有结果不代表信息不存在：它可能已本地化、经过编码、运行时拼接，或存储在可执行文件之外。

npx -y [email protected] search "/absolute/path/program" --pattern="File too large" --kind strings --provider ghidra --format json

02. 找到使用该字符串的函数

获取搜索结果地址，查看引用。引用可能指向通用错误显示函数，而非真正的保护条件。继续追踪调用方，直到找到决定是否报错的分支。

下方占位地址必须替换为分析你的二进制文件时返回的地址。不同构建的地址不能互换。

npx -y [email protected] xrefs "/absolute/path/program" --address="RETURNED_STRING_ADDRESS" --provider ghidra --format json
npx -y [email protected] 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 字节编译匹配。两者都不意味着整款游戏已重建。请查看链接中的官方原生分析指南及案例。