现实里，很多团队都会遇到这样一种场景：
外包公司只交付了 IPA 文件；历史项目源码丢失或不再维护；第三方组件只提供成品包，无法修改源码。
这时问题来了：iOS 没有源码怎么加固？ 其实，答案并不是“没救”，而是换一种思路，把加固放在成品 IPA 层面来做。下面以“收到一个 IPA 文件”为起点，逐步给出操作步骤与注意事项。
一、第一步：做安全体检
在动手加固之前，先对 IPA 做一次“体检”，找出潜在风险。
MobSF 静态扫描：快速识别明文 API、秘钥、证书、配置文件。class-dump：提取符号表，查看类名、方法名是否过于直白（如 PaymentManager、EncryptHelper）。解压 IPA：确认是否存在未加密的资源文件（JSON、视频、题库、配置等）。
这样就能确定：是需要重点保护符号，还是要先解决资源泄露问题。
二、第二步：成品混淆（IPA 层保护）
没有源码时，最常用的方法就是对 IPA 直接混淆。
Ipa Guard 就是一个常见的解决方案。它可以：对类名、方法名、变量名等进行随机化混淆；对资源文件名（图片、JSON、音频）进行扰动；修改文件 MD5，增加对比难度。注意事项：Ipa Guard 是 GUI 工具，也推出了命令行模式。混淆后要重签 IPA，否则无法安装。
这种方式能有效提高逆向成本，让反编译出来的符号变成无意义的乱码。
三、第三步：资源加密与伪装
除了符号，资源同样是重点保护对象。
文件名混淆：把 payment_config.json 改成随机名，如 a8f3x1.json。轻量加密：对 JSON、题库、配置文件做 AES 加密，运行时解密后加载。水印或哈希扰动：对视频、音频加入不可见水印，方便追溯泄露来源。
实际操作中，建议用脚本批处理资源文件，在 CI 或本地构建阶段执行。
四、第四步：重签与测试
混淆完成后，IPA 需要重签才能安装：
使用企业签名或开发者账号重签；在真机上安装测试，跑通核心流程（登录、支付、推送、第三方 SDK）。验证 Storyboard、xib、反射调用是否受影响。
这一阶段很容易发现白名单配置不足的问题，比如 storyboard 绑定类名被混淆导致白屏。解决方案是：在混淆规则里加白名单。
五、第五步：动态验证与灰度
混淆不是“一次性动作”，还需要测试效果：
Frida：尝试 Hook 关键函数，看是否还能轻易绕过。越狱环境：测试是否能注入 dylib 修改逻辑。灰度发布：先给小部分用户安装，观察崩溃率、性能变化，再逐步放量。
六、持续运维：映射表与审计
每次混淆都要生成映射表，用来符号化崩溃日志。映射表必须加密存储（KMS/HSM），访问要审批并保留审计日志。制品库中同时保存：未混淆 IPA、混淆 IPA、混淆配置、测试报告。
这样即使未来出现问题，也能快速定位与回滚。
七、总结：没有源码依然能加固
当我们拿到一个“裸 IPA”时，步骤应该是：
先做静态分析，找出风险；用成品混淆工具（如 Ipa Guard）对符号和资源加固；对高价值资源做加密与扰动；重签、真机测试，确保功能正常；动态验证、灰度发布，避免线上翻车；映射表与日志加密归档，形成可追溯链路。
即使没有源码，依然可以通过工程化手段把 IPA 加固到可接受的安全水准。
柬埔寨RBA认证