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


70

我已经对SO以及整个Google进行了相当多的研究,但是对于用Objective-C编写的iPhone / iPad应用的代码混淆,我似乎找不到直接的答案。

我的问题是:

  1. 有办法吗?如果是这样,怎么办?
  2. 这值得么?
  3. 将应用程序提交给他们时,Apple是否允许或存在问题?

Answers:


62

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

只要不崩溃,苹果可能就不会拒绝混淆的应用程序。主要问题是:混淆的目的是什么?通常,您希望对代码进行混淆处理,以保护您的知识,例如,如果您的程序使用了复制保护,那么您可能会更难发现潜在的破解者;或者,如果您使用的是某些高级算法,则您不希望业务竞争对手能够反编译它。

复制保护已在iOS上得到解决。尽管可以通过越狱来复制和运行普通应用程序,但我要说的是,执行此操作的实际用户数量非常少(至少比“常规”计算机(例如PC和Mac)要低得多)。您是否期望盗版这样一个大问题需要掩饰?

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

您可能还想阅读文章“混淆可可”

回到事实似乎没有混淆器:您可以做的是这个技巧:说您有一个像这样的标题:

@interface MyClass : NSObject {
}

- (void)myMethod;

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

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

@interface MyClass : NSObject {
}

- (void)myMethod;

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


@DarkDust此方法可以防止反编译回原始方法名称吗?
ewok

17
这种方法有一些主要缺点。很难用它来维护KVC或处理动态方法分派(为“仅发行”崩溃提供了很多机会)。对于采用多个参数的方法,效果不佳。如果myMethod存在于多个类中,则可能会产生一些真正有趣的编译错误。这是一个聪明的主意,我喜欢简单性,但是我无法想象它在任何实际系统中都值得花费。
罗布·纳皮尔2012年

@ewok:是的,原始名称仅存在于您的源中。在已编译的二进制文件中,您将具有“混合的”名称。
DarkDust 2012年

@Rob Napier:虽然这是一个hack,但不是一个很好的解决方案,但我看不到它如何产生编译错误或崩溃。
DarkDust 2012年

5
setValueForKey:将崩溃,除非您碰巧拥有一个没有被混淆的相同名称的ivar(在这种情况下,如果您拥有非平凡的访问者,它可能会产生令人惊讶的副作用)。这意味着笔尖文件将易于导致崩溃。出于同样的原因,任何从字符串(NSSelectorFromString())构造选择器的事物都将崩溃。如果A和B中的方法相同,但每个.m中的混淆方式不同,则如果A调用[B方法],则将发生编译失败。因此,您需要一种跟踪所有这些方法的方法。我不确定@selector()如何对此作出反应;可能有用。
罗布·纳皮尔

34
  1. 是的,您可以查看用于Apple iOSContaxiom代码保护的EnsureIT
  2. 这取决于。安全通常会引入复杂性,您必须在可用性之间取得平衡。
  3. Apple应该不会有任何问题(如果我错了,请纠正我),而且我个人很少有使用代码混淆器的应用程序。

@Andy您使用了哪个工具来混淆代码?您建议的工具是否支持最新的Swift版本?
Ashok '18

@Ashok我已经很长时间没有混淆我的代码了。
安迪

14

除了先前的答案,现在还有一些第三方工具可提供一定程度的混淆和完整性保护,其中包括:

  1. 阿尔山
  2. Metaforic,
  3. ry

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

  1. 控制流混淆,例如ARM指令流与冗余指令混在一起,以试图隐藏代码的原始目的,
  2. 类和方法的重命名-将您的方法和类重命名为无意义的名称,尽管您必须注意在何处使用该名称,因为由于Objective-C运行时希望找到某些名称,因此很容易破坏应用程序,
  3. 字符串加密-应用程序中的所有静态字符串均已加密,并且在使用前插入了代码以对字符串进行解密,以使静态分析更加困难
  4. 反调试-插入代码破坏常规调试器(并非总是成功),
  5. 防篡改-通常会建立一个校验和网络,以保护二进制代码不被修改,
  6. Objective-C运行时保护-通常检查obj-c注册方法的实现,以确保它们在应用程序中并且未被“困扰”。

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

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


我需要你的帮忙。您知道吗,是否有要与应用程序代码集成的SDK /库,或者是否执行了其他任何操作?B'c正在浏览网站,未反映任何此类信息。您成功地用您的代码实现了吗?
Ajay Sharma 2014年

这些工具会挂接到构建过程中,并且几乎对应用程序透明地运行。通常,您必须创建一个配置文件,告诉该工具您想要哪种保护类型以及需要在什么位置插入保护,这些文件可能会变得很复杂。通常,通常没有运行时SDK。
Andrew

3

Apple已对应用程序的可执行文件进行了加密,并且应用程序沙箱的可执行代码段不可写,因此您无法进行需要修改运行时分支代码的其他加密。而且,Objective C / C编译器的优化器过程已经创建了与原始源代码非常不同的东西。使用更多的C而更少的目标C将显示较少的函数名,因为方法名嵌入在可见的纯文本中,而C函数名则不是。因此,任何商业机密类型代码都可能应使用纯C编码,并在优化器完全打开的情况下进行编译。您可以混淆应用程序捆绑包中嵌入的任何webKit Javascript或任何其他嵌入式VM代码(只要不下载解释代码)。


1
它真的加密了吗?AFAIK仅签名。
DarkDust

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

4
解密很容易,然后得到所有普通选择器名称-因此这不是解决方案。
jimpic

2
我们能否获得包含“可执行文件已被Apple加密”和“很容易解密,然后获得所有普通选择器名称”详细信息的链接?谢谢!
奥利2015年

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

-9

可能不是因为Objective-C可以编译为处理器指令,而不是被解释或编译为字节码,所以对代码进行反编译已经产生了相当模糊的结果。混淆是通常仅在必须分发代码源时才需要的东西,例如在JavaScript之类的解释性语言中,以使其运行,即使您希望代码保持秘密。


9
实际上,由于Objective-C的动态特性,二进制文件充满了类和方法的名称。仅这些字符串就已经可以使您对程序的工作方式有所了解。
DarkDust 2011年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.