Unity3D 项目在 iOS 上发布时，有一个很现实的问题：资源和逻辑分离得比较明显。Assembly-CSharp.dll、AssetBundle、配置文件、甚至部分脚本内容，都可以被单独替换。如果有人拿到 IPA 并解包，修改资源再重新签名，就可以生成一个功能正常但逻辑被改动的版本。
在一个包含内购与数值系统的 Unity 项目中，我们遇到过资源被替换的问题：只改了一个配置文件，游戏内货币逻辑就被绕过了。之后我们把防篡改单独拆出来做了一次处理。
下面这套流程，是围绕 Unity3D iOS 应用的特点整理出来的，重点在于如何检测和阻止资源与二进制被修改。
解包 IPA 看 Unity 结构
先看一个 Unity iOS 应用解包后的结构：
Payload/App.app/
├─ Data/
│ ├─ Managed/
│ │ └─ Assembly-CSharp.dll
│ ├─ Raw/
│ ├─ Resources/
│ └─ globalgamemanagers
├─ Frameworks/
└─ AppBinary
几个关键点：
Assembly-CSharp.dll：C# 逻辑Data目录：资源与配置AppBinary：iOS 原生二进制
篡改行为通常集中在：
- 修改 DLL
- 替换资源文件
- 修改配置 JSON
对关键资源做校验
Unity 本身不会校验资源完整性，因此需要在代码中加入校验逻辑。
例如，在应用启动时计算资源哈希：
MD5(file) == expected_hash
实现方式：
- 在构建时生成资源 MD5 列表
- 将列表写入代码或加密存储
- 启动时逐个校验
如果发现不一致，可以：
- 阻止启动
- 或限制部分功能
这一步主要防止资源被直接替换。
处理 Assembly-CSharp.dll
Unity 的 C# 逻辑编译为 DLL，但仍然可以被反编译。
可以使用工具：
- IL2CPP（将 C# 转为 C++）
- 或代码混淆工具
如果项目已经生成 IPA，可以直接在 IPA 层做补充处理。
Ipa Guard 支持对 Unity3D 应用的二进制进行混淆处理，包括：
- 函数名
- 类名
- 方法参数
虽然 DLL 本身不在 Mach-O 中，但 Unity 导出的 iOS 工程中，部分逻辑会被编译进原生层或符号表中，这些内容仍然可以被处理。
隐藏资源文件结构
Unity 的资源目录往往结构清晰，例如：
Data/Resources/config.json
Data/Raw/level1.assetbundle
这些名称直接暴露游戏逻辑。
在 IPA 层可以使用 Ipa Guard 对资源进行处理：
- 修改文件名称
- 同步更新引用路径
例如：
config.json → a82kd.json
level1.assetbundle → k39sd.bundle
处理后再次解包 IPA，资源名称将无法直接理解。
修改资源指纹（防止复用）
如果攻击者直接提取资源并复用到其他应用，文件指纹会成为识别依据。
Ipa Guard 支持修改资源 MD5：
- 文件内容保持一致
- 指纹发生变化
可以验证：
md5 level1.assetbundle
处理前后结果不同。
处理图片与 UI 资源
Unity 项目中的 UI 图片也可能被提取。
可以在资源处理中：
- 修改图片名称
- 添加不可见水印
水印不会影响显示，但可以标记资源来源。
清理调试信息与日志
Unity 构建时可能包含调试信息。
可以检查：
strings AppBinary | grep Unity
如果输出包含调试日志，可以在 IPA 处理阶段清理。
Ipa Guard 支持删除部分调试信息，提高逆向难度。
二进制层防篡改
除了资源校验，还可以在原生层增加简单检测逻辑，例如：
- 校验 AppBinary 的 hash
- 检测关键文件是否被修改
这些逻辑可以写在原生代码中。
配合 Ipa Guard 的符号混淆处理，可以降低这些检测逻辑被绕过的概率。
重新签名与安装测试
所有修改完成后，需要重新签名。
可以使用：
kxsign sign app.ipa \
-c cert.p12 \
-p password \
-m dev.mobileprovision \
-z test.ipa \
-i
或在 Ipa Guard 中直接完成签名。
安装后需要重点测试：
- 资源加载
- 场景切换
- AssetBundle 加载
- 内购流程
Unity3D 应用的篡改风险主要集中在资源和配置层，而不是单纯的代码反编译。通过资源校验、文件改名、MD5 修改、调试信息清理以及二进制混淆，可以显著提高篡改成本。