iPhone/iPad 应用程序代码混淆 - 有可能吗？值得？ [关闭]

Posted 2023-03-16

【中文标题】iPhone/iPad 应用程序代码混淆 - 有可能吗？值得？ [关闭]

【英文标题】：iPhone/iPad App Code Obfuscation - Is it Possible? Worth it? [closed]

【发布时间】：2011-07-30 05:38:58

【问题描述】：

我已经研究了很多，包括 SO，以及到处搜索，但我似乎无法找到关于 iPhone/iPad 应用程序代码混淆的直截了当的答案Objective-C。

我的问题是：

有办法吗？如果有，怎么做？ 值得吗？ 当应用程序提交给他们时，Apple 是否允许这样做，或者有问题？

【参考方案1】：

Objective-C 似乎没有代码混淆器。但是让我们暂时假设一个确实存在。

Apple 可能不会拒绝混淆的应用程序，只要它不崩溃。主要问题是：混淆的意义何在？通常，您希望混淆代码以保护您的知识，例如，如果您的程序使用复制保护，您希望让潜在的破解者更难，或者如果您使用一些高级算法，您不希望商业竞争对手成为可以反编译。

已经在 ios 上处理了复制保护。虽然通过越狱可以复制和运行普通应用程序，但我想说这样做的实际用户数量相当低（至少比 PC 和 Mac 等“常规”计算机低很多）。您认为盗版是一个需要混淆的大问题吗？

如果您确实有重要的知识需要保护，那么混淆可能是值得的。混淆有其缺点：您无法再调试您的混淆应用程序。崩溃报告将毫无用处。

您可能还想阅读文章Obfuscating Cocoa。

回到似乎没有混淆器的事实：你可以做的是这个技巧：假设你有这样的标题：

@interface MyClass : NSObject 


- (void)myMethod;

您可以像这样进行廉价的混淆：

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

@interface MyClass : NSObject 


- (void)myMethod;

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

【讨论】：

@DarkDust 这种方法会阻止反编译回原始方法名称吗？

这种方法有一些主要的缺点。很难用它来维护 KVC，或者处理动态方法调度（为 Release-only 崩溃提供了很多机会）。它不适用于采用多个参数的方法。如果myMethod 存在于多个类中，它可能会产生一些真正有趣的编译错误。这是一个聪明的主意，我喜欢它的简单性，但我无法想象它在任何实际系统中都值得。

@ewok：是的，原始名称只会存在于您的源代码中。在已编译的二进制文件中，您将拥有“损坏”的名称。

@Rob Napier：虽然这是一个 hack 而不是一个很好的解决方案，但我看不出这会如何产生编译错误或崩溃。

setValueForKey: 会崩溃，除非你碰巧有一个你没有混淆的同名 ivar（在这种情况下，如果你有非平凡的访问器，它可能会产生令人惊讶的副作用）。这意味着 nib 文件往往会导致崩溃。任何从字符串（NSSelectorFromString()）构造选择器的东西都会因为同样的原因而崩溃。如果你在 A 和 B 中有相同的方法，但在每个 .m 中混淆不同，那么如果 A 调用 [B 方法]，它就会编译失败。所以你需要一种方法来跟踪所有这些。我不确定@selector() 对此有何反应；可能会奏效。

【参考方案2】：

是的，你可以看看EnsureIT for Apple iOS或Contaxiom Code Protection 视情况而定。安全性通常会带来复杂性，您必须在可用性之间取得平衡。 Apple 应该没有任何问题（如果我错了，请纠正我），而且我个人很少有使用代码混淆器的应用程序。

【讨论】：

@Andy 你用什么工具来混淆你的代码？您推荐的工具是否支持最新的 Swift 版本？

@Ashok 我已经很久没有混淆我的代码了。

【参考方案3】：

除了先前的答案之外，现在还有几个 3rd 方工具可以提供一定程度的混淆和完整性保护，包括：-

阿尔山， Metaforic， Cryptanium

它们的功能各不相同，包括：-

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

所有这些工具都非常昂贵，而且并非没有问题，因此您确实需要一个需要高度完整性的应用程序才能考虑它们，例如银行业务或 DRM 非常重要的地方。

对于这些类型的应用，您还需要熟练的渗透测试人员来确保您的应用不会以其他方式暴露出来，因为这些工具通常与使用它们的人一样好，而且还有其他操作系统漏洞需要缓解工具没有解决的问题。

【讨论】：

我需要你的帮助。您知道吗，是否有任何 SDK/库要与应用程序代码集成或执行其他任何操作？ B'c 通过网站，没有反映任何这样的事情。您是否能够在您的代码中成功实现它？

这些工具与构建过程挂钩，并且对应用程序大多透明地操作。您通常必须创建一个配置文件，告诉该工具您想要什么类型的保护以及它需要插入的位置，这些文件可能会变得复杂。但通常没有运行时 SDK。

【参考方案4】：

应用程序的可执行文件已经被 Apple 加密，应用程序沙盒的可执行代码段不可写，因此您无法进行需要修改运行时 arm 代码的额外加密。 Objective C/C 编译器的优化器通道已经创建了与原始源代码非常不同的东西。使用更多的 C 和更少的 Objective C 将显示更少的函数名称，因为方法名称嵌入在可见的纯文本中，但 C 函数名称不是。因此，任何商业机密类型的代码都应该用纯 C 编码，并使用优化器一路向上编译。您可以混淆应用程序包中嵌入的任何 webKit javascript，或任何其他嵌入式 VM 代码（只要未下载解释代码）。

【讨论】：

真的加密了吗？ AFAIK 它只是签名的。

@DarkDust - 在向 Apple 提交应用程序之前查看 ARM 二进制可执行文件，以及从 App Store 下载后 ipa/zip 文件中的内容。

很容易解密，然后你就可以得到所有简单的选择器名称——所以这不是解决方案。

我们能否获得包含“可执行文件已被 Apple 加密”和“很容易解密然后您获得所有纯选择器名称”详细信息的链接？谢谢！

是的，当您将其提交到商店时，它已经被混淆了，当您从商店下载 IPA 时，您将获得带有内存地址的混淆 ipa。 Xcode 在编译时生成机器代码（如果启用了位码，则为中间代码）和匹配符号文件（dSYM）。当我们在商店提交应用程序时，我们会上传这两个文件，但是当有人从商店下载应用程序时，他只会得到包含混淆符号的 .app 机器代码文件。

【参考方案5】：

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

【讨论】：

实际上，由于 Objective-C 的动态特性，二进制文件充满了类和方法名。仅这些字符串就可以让您深入了解程序的工作原理。