O-MVLL 1.9.1：字符串编码支持 ObjC 的 CFString

当天发生了什么

2026-07-06（UTC 10:19），open-obfuscator 项目在 GitHub 发布了 O-MVLL 1.9.1。发布说明列出的兼容性是 Xcode 26.5 和 NDK r29；变更有三项：修复 1.9.0 的发布并更新依赖；StringEncoding（字符串编码）支持 Objective-C 字符串（CFString）；新增 ScopedTrace 计时埋点。作为背景，6 月 23 日发布的 1.9.0 说明只有一项“支持 NDK 29”。O-MVLL 是基于 LLVM 的混淆插件，在编译阶段对 iOS 和 Android 原生代码做变换。需要注意，GitHub 的 Atom 订阅中这条发布的更新时间显示为 7 月 8 日，但发布页显示的发布时间是 7 月 6 日，本文以发布页为准。

对保护应用逻辑意味着什么

在 Objective-C 代码里，@"..." 这样的字面量会以 CFString 常量的形式进入二进制，而不是普通的 C 字符串。对于仍有大量 Objective-C 代码的 iOS 项目，字符串编码能覆盖这类字面量，意味着静态浏览二进制时可读文本会减少。但边界必须讲清：字符串编码只影响静态可读性，程序运行时仍要把字符串还原出来使用，动态观察可以看到它们；它不能用来保护 API 密钥或其他秘密，秘密应当留在服务端。另一个现实问题是版本绑定：这类编译器插件与具体的 Xcode 和 NDK 版本强相关，工具链升级往往需要等待插件跟进，这本身就是维护成本。

可以在自己的构建上做的检查

第一，确认团队实际使用的 Xcode 与 NDK 版本和发布说明列出的兼容版本一致，不一致时先在分支上验证。第二，在启用前后分别对自己的发布构建运行 strings 或 otool，比较 __cstring 与 __cfstring 等段中的可读文本，确认敏感字面量是否减少，而不是假设已经生效。第三，盘点仍然出现在客户端里的秘密，把它们迁移到服务端，不要依靠字符串编码。第四，混淆后完整回归测试，关注启动时间和包含大量字符串的代码路径；ScopedTrace 的用法请先查阅项目文档。第五，变换后重新签名，并在真机上验证安装、启动与关键流程。

行动清单

• 核对 Xcode 26.5 / NDK r29 与自身工具链版本
• 启用前后比较自身构建的 __cstring/__cfstring 可读文本
• 客户端中的秘密迁到服务端，不依赖字符串编码
• 混淆后重新签名并做真机回归