摘要
iOS 的代码签名、沙箱和权限控制为应用提供了较强的系统级安全边界，但这些机制不会主动隐藏游戏自身的代码语义，也不能替代资源保护、内存数据保护和运行时检测。本文从 iOS 游戏客户端可见的攻击面出发，梳理代码、资源、内存与运行时四个层面的保护重点，并补充 Unity IL2CPP、metadata、AssetBundle以及重打包、二次签名等常见问题。
关键词： iOS游戏加固、iOS代码混淆、Unity IL2CPP、metadata保护、资源加密、重签名检测
1. iOS 系统安全不等于客户端内容安全
iOS 使用代码签名确认应用身份和代码完整性，通过沙箱限制应用能够访问的文件与系统资源。这些机制主要保护系统和应用之间的边界，并不负责隐藏某个 App 内部的业务结构。
游戏安装包中仍可能保留类名、方法名、字符串、配置文件和资源目录。以 RewardManager、verifyPurchase 为例，这类名称已经暴露了奖励和支付逻辑的大致位置。分析者可以继续查看字符串的交叉引用和函数调用关系，把目标缩小到少量关键函数。
因此，iOS 游戏加固需要处理的是另一组问题：如何减少静态分析线索，防止资源被直接提取或替换，提高内存数据的修改成本，并在程序运行后识别异常环境和篡改版本。
2. 代码保护要覆盖不同语言留下的线索
Objective-C 依赖运行时机制，类名、方法名和 Selector 往往保留较强的业务语义。Swift 编译后也可能留下模块和类型信息。C/C++ Native 代码虽然看不到原始源码，字符串、常量、控制流和函数关系仍能用于判断代码用途。
只改类名的效果比较有限。分析者还可以搜索 addDiamond、isVip 或 purchaseSuccess 之类的明文字符串，再沿着调用关系寻找货币、会员和支付校验逻辑。
代码保护通常需要同时处理名称和符号、敏感字符串、关键常量以及控制流。支付校验、战斗结算、虚拟资产和安全检测等高价值模块，可以单独提高保护强度。这里的目标并非让二进制"不可分析"，而是让单一线索无法快速对应到真实业务。
Unity iOS：IL2CPP 代码与 metadata 要关联保护
Unity 使用 IL2CPP 时，会把 C# 中间语言转换为 C++，最终生成平台对应的 Native 二进制。与此同时，运行时仍需要 metadata 来描述类型、方法和字段等信息。分析者可以把 Native 代码与 metadata 对照起来，恢复部分类型关系和调用语义。
所以，Unity iOS 项目不能只处理生成后的 Native 代码，也不能只加密 metadata。两者之间的对应关系，以及 AssetBundle 中暴露的配置和资源线索，都应纳入同一套保护策略。
3. 资源加密还要考虑密钥、加载与热更新
游戏资源不只是美术和音视频素材。本地配置、Lua 或 JavaScript 脚本、关卡数据、活动内容和热更新文件，也可能位于安装包或应用沙箱中。
未上线的角色、皮肤和剧情资源被提前导出，会造成内容泄露；配置或脚本遭到替换，则可能改变客户端中的活动和关卡表现。给文件加密只能解决其中一部分问题，密钥的存放方式、运行时解密路径以及加载前的完整性校验同样重要。
对支持热更新的项目，加密方案还要兼容资源下载、版本管理和加载流程。Unity 为 AssetBundle 提供 CRC 校验，可用于发现下载损坏或内容变化，但下载校验不等于资源加密，也不能替代面向恶意篡改设计的完整性策略。
4. 文件加密后，内存数据仍可能被定位
代码和资源最终都要在运行时使用。金币数量、角色坐标、技能冷却、伤害值、资源密钥以及解密后的脚本，都可能在内存中出现。
修改器常用的思路是搜索已知数值，再通过状态变化缩小结果范围。例如金币从 1000 变成 950，两次筛选后就可能找到对应地址。定位成功后，攻击者既可以直接改值，也可能继续追踪读写该地址的函数。
客户端可以对关键数值使用加密或混淆表示，减少敏感明文的存留时间，并对状态变化做一致性检查。不过，虚拟资产和结算结果不应只由客户端决定。内存保护提高修改成本，服务端校验才是重要结果的最终边界。
5. 运行时保护要覆盖动态修改与二次签名
静态保护生效后，游戏运行过程中仍可能被调试器附加、Frida Hook 或异常动态库注入。关键函数的返回值和内存数据也可能被直接修改。越狱及 rootless 环境会为这类操作提供更多条件，但越狱检测只是运行时保护的一部分。
iOS 上还要特别关注重打包和二次签名。常见路径是解开原始 IPA，替换资源、修改代码或加入额外动态库，再使用其他证书重新签名，通过侧载等渠道安装。篡改包可能正常启动，但签名主体和包内内容已经发生变化。
运行时可以从以下几个方向交叉判断：
- 核对签名身份和 Team ID 是否符合预期，Bundle ID 只作为辅助信息；
- 校验主可执行文件、动态库和关键资源的完整性；
- 检查调试器附加、异常动态库加载和关键函数 Hook；
- 识别越狱或 rootless 环境，同时避免依赖单一特征；
- 把客户端信号与账号、设备及业务行为放到服务端综合判断。
发现异常后，可以按风险等级采取不同措施。高风险状态可阻止登录、交易或支付；证据不足时先上报并限制敏感功能，通常比单点检测后直接退出更稳妥。
6. 加固策略应从威胁模型出发
不同项目的保护重点并不相同。纯 Native 游戏、Objective-C 或 Swift 混合项目，以及 Unity IL2CPP 项目，暴露的代码与资源结构都有差异。实际配置前至少要确认三件事：哪些逻辑被修改后会直接影响业务，哪些资源具有泄露或替换价值，哪些结果必须由服务端复核。
在此基础上，再决定混淆强度、资源加密范围、内存保护对象和运行时检测策略。保护范围越大并不一定越好，还需要评估启动速度、运行性能、崩溃率、热更新流程以及不同 iOS 版本的兼容性。
7. FairGuard iOS 游戏加固的覆盖方式
FairGuard 会根据项目使用的语言、引擎、资源结构和关键模块配置保护策略。代码层覆盖 Objective-C、Swift、Native 及 Unity IL2CPP；资源层处理配置、脚本、AssetBundle和热更新内容；运行阶段对敏感内存数据、越狱与 rootless 环境、调试、注入、Hook、重打包和二次签名进行检测。
几层能力解决的是不同阶段的问题。代码、资源和内存保护负责提高分析与修改成本，运行时保护继续判断启动后的动态风险。对于交易、虚拟资产和结算等关键业务，还需要与服务端校验和风控策略配合。