There doesn't seem to a code obfuscator for Objective-C. But let's assume for a moment that one does exist.
Apple will probably not reject an obfuscated app as long as it doesn't crash. The main question is: what is the point of obfuscation ? Normally, you want to obfuscate code to protect your knowledge, for example if your program uses a copy protection you want to make it harder for a potential cracker or if you're using some advanced algorithm you don't want the business competitors to be able to decompile it.
The copy protection is already been taken care of on iOS. Although through jailbreaking a normal app can be copied and run, I'd say the actual number of users who do this is fairly low (at least a lot lower than on "regular" computers like PC and Mac). Do you expect piracy such a big problem that you need to obfuscate ?
If you do have important knowledge to protect then obfuscation might be worthwhile. Obfuscation has its downsides: you can't debug your obfuscated app any more. Crash reports will be useless.
Further to the earlier answers there are now several 3rd party tools that offer some degree of obfuscation and integrity protection including :-
Arxan,
Metaforic,
Cryptanium
They vary in capabilities and include :-
Control flow obfuscation e.g. ARM instruction flows are mangled with redundant instructions to try to hide the original purpose of the code,
Class and Method renaming - renames your methods and classes to meaningless names although you have to be careful where this is used as you can easily break your app because the Objective-C runtime is expecting to find certain names,
String encryption - all static strings in the app are encrypted and code is inserted to decrypt the strings just before use in order to make static analysis harder
Anti-debug - code is inserted to break the usual debuggers (not always successfully),
Anti-tamper - usually builds a network of checksums that protect the binary code from modification,
Objective-C runtime protection - usually checks obj-c registered method implementations to make sure that they are in the app and haven't been 'swizzled'.
All of these tools are very expensive and not without their problems so you really need an application that requires a high degree of integrity in order to consider them e.g. banking or where DRM is very important.
For these types of app you will also need skilled penetration testers to ensure that your app is not exposed in other ways as these tools are often only as good as the people using them and there are still other OS vulnerabilities that will need mitigating that the tools don't address.
应用程序的可执行文件已经被Apple加密，并且应用程序沙箱的可执行代码段是不可写的，因此您无法进行需要运行时arm代码修改的额外加密。 Objective C/C 编译器的优化器通道已经创建了与原始源代码非常不同的东西。使用更多的 C 和更少的 Objective C 将显示更少的函数名称，因为方法名称嵌入在可见的纯文本中，但 C 函数名称则不然。因此，任何商业秘密类型代码都应该使用纯 C 语言进行编码，并使用优化器进行编译。您可以混淆应用程序包中嵌入的任何 webKit Javascript，或任何其他嵌入的 VM 代码（只要不下载解释的代码）。
The executable of an app is already encrypted by Apple, and the executable code segment of the app sandbox isn't writeable, so you can't do additional encryption that requires runtime arm code modification. And the optimizer pass of the Objective C/C compiler already creates something very different from the original source code. Using more C and less Objective C will reveal less of your function names, as method names are embedded in visible plain text, but C function names are not. So any trade secret type code should probably be coded in plain C, and compiled with the optimizer turned all the way up. You could obfuscate any webKit Javascript embedded within the app bundle, or any other embedded VM code (as long as interpreted code isn't downloaded).
Probably not because Objective-C compiles out to processor instructions rather than being interpreted or compiling to byte code, so decompiling the code will already produce pretty obscure results. Obfuscation is something you usually only needed when you have to distribute the source of your code, like in interpreted languages like JavaScript, in order for it to run even when you want the code to remain secret.
发布评论
评论（5）
Objective-C 似乎没有代码混淆器。但让我们暂时假设一个确实存在。
只要不崩溃，苹果可能不会拒绝混淆的应用程序。主要问题是：混淆的意义是什么？通常，您希望混淆代码以保护您的知识，例如，如果您的程序使用复制保护，您希望让潜在的破解者变得更难，或者如果您正在使用某些高级算法，您不希望商业竞争对手成为您的竞争对手。能够反编译它。
iOS 上已经实现了复制保护。尽管通过越狱可以复制并运行普通应用程序，但我想说，执行此操作的实际用户数量相当低（至少比 PC 和 Mac 等“常规”计算机上的用户少很多）。您是否认为盗版是一个需要混淆的大问题？
如果您确实有重要的知识需要保护，那么混淆可能是值得的。混淆有其缺点：您无法再调试混淆的应用程序。崩溃报告将毫无用处。
您可能还想阅读文章混淆 Cocoa。
回到事实，似乎没有混淆器：你可以做的是这个技巧：假设你有一个像这样的标题：
你可以像这样做一个廉价的混淆：
这样你就可以仍然在源代码中使用有意义的符号，但是编译器在不编译进行调试时会将其变成“垃圾”。
There doesn't seem to a code obfuscator for Objective-C. But let's assume for a moment that one does exist.
Apple will probably not reject an obfuscated app as long as it doesn't crash. The main question is: what is the point of obfuscation ? Normally, you want to obfuscate code to protect your knowledge, for example if your program uses a copy protection you want to make it harder for a potential cracker or if you're using some advanced algorithm you don't want the business competitors to be able to decompile it.
The copy protection is already been taken care of on iOS. Although through jailbreaking a normal app can be copied and run, I'd say the actual number of users who do this is fairly low (at least a lot lower than on "regular" computers like PC and Mac). Do you expect piracy such a big problem that you need to obfuscate ?
If you do have important knowledge to protect then obfuscation might be worthwhile. Obfuscation has its downsides: you can't debug your obfuscated app any more. Crash reports will be useless.
You might also want to read the article Obfuscating Cocoa.
Back to the fact there doesn't seem to be an obfuscator: What you can do is this trick: say you have a header like this:
You could do a cheap obfuscation like this:
This way you can still use meaningful symbols in your source, but the compiler would turn it into "garbage" when not compiling for debugging.
除了早期的答案之外，现在有几种第三方工具提供一定程度的混淆和完整性保护，包括：-
它们的功能各不相同，包括：-
所有这些工具都非常昂贵，而且并非没有问题，因此您确实需要一个需要高度完整性的应用程序才能考虑它们，例如银行或 DRM 非常重要的地方。
对于这些类型的应用程序，您还需要熟练的渗透测试人员来确保您的应用程序不会以其他方式暴露，因为这些工具通常只与使用它们的人一样好，并且仍然存在其他操作系统漏洞需要缓解这些工具不要寻址。
Further to the earlier answers there are now several 3rd party tools that offer some degree of obfuscation and integrity protection including :-
They vary in capabilities and include :-
All of these tools are very expensive and not without their problems so you really need an application that requires a high degree of integrity in order to consider them e.g. banking or where DRM is very important.
For these types of app you will also need skilled penetration testers to ensure that your app is not exposed in other ways as these tools are often only as good as the people using them and there are still other OS vulnerabilities that will need mitigating that the tools don't address.
应用程序的可执行文件已经被Apple加密，并且应用程序沙箱的可执行代码段是不可写的，因此您无法进行需要运行时arm代码修改的额外加密。 Objective C/C 编译器的优化器通道已经创建了与原始源代码非常不同的东西。使用更多的 C 和更少的 Objective C 将显示更少的函数名称，因为方法名称嵌入在可见的纯文本中，但 C 函数名称则不然。因此，任何商业秘密类型代码都应该使用纯 C 语言进行编码，并使用优化器进行编译。您可以混淆应用程序包中嵌入的任何 webKit Javascript，或任何其他嵌入的 VM 代码（只要不下载解释的代码）。
The executable of an app is already encrypted by Apple, and the executable code segment of the app sandbox isn't writeable, so you can't do additional encryption that requires runtime arm code modification. And the optimizer pass of the Objective C/C compiler already creates something very different from the original source code. Using more C and less Objective C will reveal less of your function names, as method names are embedded in visible plain text, but C function names are not. So any trade secret type code should probably be coded in plain C, and compiled with the optimizer turned all the way up. You could obfuscate any webKit Javascript embedded within the app bundle, or any other embedded VM code (as long as interpreted code isn't downloaded).
可能不是，因为 Objective-C 编译为处理器指令，而不是被解释或编译为字节代码，因此反编译代码已经会产生相当模糊的结果。通常只有当您必须分发代码源（例如 JavaScript 等解释性语言）时才需要进行混淆，以便即使您希望代码保密也能让代码运行。
Probably not because Objective-C compiles out to processor instructions rather than being interpreted or compiling to byte code, so decompiling the code will already produce pretty obscure results. Obfuscation is something you usually only needed when you have to distribute the source of your code, like in interpreted languages like JavaScript, in order for it to run even when you want the code to remain secret.