iPhone/iPad应用程序代码混淆 - 可能吗？值得？

Question

我已经研究了很多,无论是在SO还是google-ing到处,但我似乎找不到关于用Objective-C编写的iPhone/iPad应用程序的代码混淆的直接答案.

我的问题是这些:

Answer 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;

这样你仍然可以在源代码中使用有意义的符号,但编译器会在不编译调试时将其变为"垃圾".

这种方法有一些主要缺点.很难用它维护KVC,或处理动态方法调度(为仅发布崩溃开辟了大量机会).对于采用多个参数的方法,它不能很好地工作.如果`myMethod`存在于多个类中,它可能会创建一些真正有趣的编译错误.这是一个聪明的主意,我喜欢简单,但我无法想象它在任何实际系统中都是值得的. (16认同)
setValueForKey:会崩溃,除非你碰巧有一个与你没有混淆的同名的ivar(在这种情况下,如果你有非平凡的访问器,它会产生令人惊讶的副作用).这意味着nib文件往往会导致崩溃.从字符串构造选择器的任何东西(NSSelectorFromString())都会因同样的原因而崩溃.如果你在A和B中有相同的方法,但在每个.m中混淆不同,那么如果A调用[B方法],它将有编译失败.所以你需要一种方法来跟踪所有这些.我不确定@selector()对此有何反应; 可能有用. (4认同)

Answer 2

Answer 3

除了早先的答案,现在有几个第三方工具可以提供某种程度的混淆和完整性保护,包括: -

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

控制流混淆,例如ARM指令流被冗余指令修改,试图隐藏代码的最初目的,
类和方法重命名 - 将您的方法和类重命名为无意义的名称,尽管您必须小心使用它,因为您可以轻松地破坏您的应用程序,因为Objective-C运行时期望找到某些名称,
字符串加密 - 应用程序中的所有静态字符串都经过加密,并且在使用之前插入代码以解密字符串,以便使静态分析更加困难
反调试 - 插入代码以打破常用的调试器(并不总是成功),
防篡改 - 通常构建一个校验和网络,保护二进制代码不被修改,
Objective-C运行时保护 - 通常检查obj-c注册的方法实现,以确保它们在应用程序中并且没有被"调配".

所有这些工具都非常昂贵,并且没有他们的问题所以你真的需要一个需要高度完整性的应用程序,以便考虑它们,例如银行业务或DRM非常重要的地方.

对于这些类型的应用程序,您还需要熟练的渗透测试人员,以确保您的应用程序不会以其他方式暴露,因为这些工具通常只与使用它们的人一样好,并且还有其他操作系统漏洞需要减轻工具不解决.