IPhone/iPad 应用程序代码混淆——可能吗? 值得吗？

我做了很多研究，不管是在 SO 上，还是在谷歌上，但是我似乎找不到一个直接的答案，关于用 Objective-C 编写的 iPhone/iPad 应用程序的代码混淆。

我的问题是:

  1. 有办法吗? 如果有，怎么做？
  2. 值得吗？
  3. 当应用程序被提交给苹果公司时，苹果公司是否允许这样做，或者有什么问题？
45379 次浏览
小开

可能不是因为 Objective-C 编译成处理器指令，而不是被解释或编译成字节码，所以反编译代码将已经产生相当模糊的结果。模糊处理通常只有在必须分发代码源(比如在 JavaScript 等解释语言中)时才需要，以便即使在希望代码保密的情况下也能运行代码。

小开
最佳答案

这里似乎没有 Objective-C 的代码混淆器，但是让我们假设一下确实存在这样的代码混淆器。

苹果可能不会拒绝一个模糊的应用程序，只要它不崩溃。主要的问题是: 模糊的重点是什么？通常情况下，你想要混淆代码来保护你的知识，例如，如果你的程序使用了复制保护，你想让潜在的破解者难以破解，或者如果你使用了一些先进的算法，你不希望商业竞争对手能够反编译它。

在 iOS 系统上，拷贝保护已经得到了很好的保护。虽然通过越狱，一个普通的应用程序可以被复制和运行，但我认为这样做的实际用户数量相当低(至少比“普通”电脑如 PC 和 Mac 要低得多)。你认为盗版是一个需要混淆视听的大问题吗？

如果你确实有重要的知识要保护，那么混淆可能是值得的。模糊化有它的缺点: 你不能调试你的模糊化应用程序了。坠机报告就没用了。

您可能还想阅读 混淆视听的可可文章。

回到事实上，似乎没有一个混淆器: 你 可以做的是这个技巧: 假设你有一个像这样的头:

@interface MyClass : NSObject {
}


- (void)myMethod;

你可以这样做:

#ifndef DEBUG
#define MyClass aqwe
#define myMethod oikl
#endif


@interface MyClass : NSObject {
}


- (void)myMethod;

这样，您仍然可以在源代码中使用有意义的符号，但编译器在不进行编译以进行调试时会将其转换为“垃圾”。

小开

应用程序的可执行文件已经被苹果加密，并且应用程序沙箱的可执行代码段是不可写的，所以你不能进行额外的加密，需要修改运行时手臂代码。而且 Objective C/C 编译器的优化器传递已经创建了一些与原始源代码非常不同的东西。使用更多的 C 和更少的 Objective C 将显示更少的函数名，因为方法名嵌入在可见的纯文本中，而 C 函数名不嵌入。因此，任何商业秘密类型代码都应该用纯 C 编码，并且在编译时一直开启优化器。您可以混淆嵌入在 app bundle 中的任何 webKit Javascript，或任何其他嵌入式 VM 代码(只要不下载解释代码)。

小开
  1. 是的，你可以看看 为苹果 iOS 确保 IT或者 接触密码保护
  2. 视情况而定。安全性通常会引入复杂性，你必须在可用性之间进行平衡。
  3. 苹果应该没有任何问题(如果我错了请纠正我) ，我个人有几个应用程序使用代码混淆器。
小开

继前面的答案之后，现在有一些第三方工具提供某种程度的混淆和完整性保护，包括:-

  1. 阿克桑,
  2. 变形金刚,
  3. 隐匿金属

它们的能力各不相同，包括:-

  1. 控制流混淆，例如 ARM 指令流被冗余指令混淆，以试图隐藏代码的原始用途,
  2. 类和方法重命名-将你的方法和类重命名为无意义的名称，但是你必须小心这个名称的使用，因为你很容易破坏你的应用程序，因为 Objective-C 运行时期望找到某些名称,
  3. 字符串加密-应用程序中的所有静态字符串都被加密，并且在使用之前插入代码来解密字符串，以使静态分析更加困难
  4. 插入反调试代码以中断通常的调试器(并不总是成功) ,
  5. 防篡改-通常建立一个校验和网络，以保护二进制代码不被修改,
  6. Objective-C 运行时保护——通常检查 obj-c 注册的方法实现，以确保它们在应用程序中，并且没有被“调整”。

所有这些工具都非常昂贵，并不是没有问题，所以你真的需要一个需要高度完整性的应用程序来考虑它们，例如银行或者 DRM 非常重要的地方。

对于这些类型的应用程序，你还需要有经验的渗透测试人员来确保你的应用程序不会以其他方式暴露，因为这些工具往往只能和使用它们的人一样好，而且还有其他操作系统的漏洞需要缓解，而这些工具并没有解决这些问题。


提交答案