很多关于资源盗用的讨论，容易回到源码层，但在实际场景中，问题更多出现在靠后的阶段。
一个 iOS 应用已经生成 IPA，只要被解包，以下内容就已经是明文状态：
- 图片资源
- 音频、视频文件
- JSON、HTML、配置文件
- H5 页面与本地 JS
这些文件不需要理解代码逻辑，只要复制出来就可以被再次使用。
资源盗用发生时，攻击者并不在意实现方式
从被解包的 IPA 来看，资源是否好用，取决于几个客观条件：
- 文件是否能直接识别用途
- 文件是否能被单独替换或复用
- 是否存在完整性校验
- 替换后 App 是否还能正常运行
如果答案偏向“可以”，那资源本身就处在一个容易被搬走的位置。
只限制访问，并不能解决成品包内的资源问题
在服务端校验、接口鉴权这些机制之外，本地资源的特点是：
- 已经随包分发
- 不依赖网络
- 可以脱离 App 运行环境
这意味着，防止资源盗用的工作，必须落在资源本身的可复用性上。
从成品包视角看，资源能被“直接使用”的原因
在一次实际拆包中，可以清楚看到：
- 图片文件名直接反映业务含义
- JSON 配置结构清晰
- H5 页面可以单独在浏览器打开
- 资源校验值保持稳定
这些特征并不影响运行，但降低了复用门槛。
防止资源被直接复用，需要改变哪些具体点
在不改源码的前提下，可操作的维度主要集中在三类：
- 名称层
- 内容层
- 校验层
每一层的处理目标都不同。
一条资源防盗处理流程
加载 IPA，筛选资源类型
将 IPA 加载到 Ipa Guard 本地处理工具后，先定位：
- 图片、音频、视频
- JSON、HTML、JS
- 是否存在独立资源 bundle
这一步用于区分哪些资源存在被直接复用的风险。
对资源文件执行批量重命名
在工具中对选中的资源进行名称处理后，可以观察到：
- 原始文件名消失
- 资源引用路径同步更新
解包后，资源用途不再通过名称暴露。
对资源内容进行非功能性调整
仅重命名不足以阻断复制。
在内容层执行处理后，可以通过以下方式验证结果：
- 图片内容增加不可见水印或元数据
- JSON 结构发生非语义级变化
- 文件二进制发生变化，但加载结果一致
计算 MD5 时，可以确认校验值已经不同。
校验资源在 App 内的加载行为
将处理后的 IPA 安装到测试设备，重点检查：
- 图片是否正常显示
- 配置是否可被正确解析
- H5 页面是否能被加载
运行行为一致，说明资源处理未破坏功能。
重新签名，固定处理结果
完成资源处理后，对 IPA 重新签名。
此时再解包，资源结构已经无法回退到原始状态。
Ipa Guard 在资源防盗流程中的作用
在上述流程中，使用的是 Ipa Guard 这一类本地 IPA 处理工具。
它在资源防盗中的具体行为包括：
- 批量重命名图片、配置、H5 等资源
- 对资源内容执行不可见调整
- 修改资源校验值
- 保持资源加载路径与运行逻辑不变
- 集成重签名与安装测试流程
所有结果都可以通过解包或真机运行验证。
资源防盗往往和其他处理一起出现
在工程实践中，资源防盗很少单独存在。
它常与以下操作同时进行：
- 代码符号混淆
- 调试信息清理
- 成品包结构调整
原因并不复杂：资源与代码之间本就存在引用关系。
哪些场景下值得对资源做额外处理
从成品包条件来看，以下情况更适合引入资源防盗流程：
- 素材成本较高
- 资源被频繁复用
- App 被多渠道分发
- 构建流程不可调整
在这些条件下，资源处理属于结构级防护。
防止资源盗用，并不是让资源“消失”，而是让资源失去被直接复用的价值。
通过在成品包阶段调整资源名称、内容和校验结果，可以显著改变资源在解包后的可用性。
参考链接:https://ipaguard.com/tutorial/zh/1/1.html