iPhone/iPad App Code Obfuscation - Is it Possible? Worth it? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on开发者_如何学运维 one problem only by editing this post.

Closed 3 years ago.

Improve this question

I've researched quite a bit, both on SO, as well google-ing all over the place, but I can't seem to find a straight-forward answer in regards to code obfuscation for iPhone/iPad apps written in Objective-C.

My questions are these:

1. Is there a way to do it? If so, how?
2. Is it worth it?
3. Does Apple allow it, or have a problem with it, when the app is submitted to them?

---

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:

@interface MyClass : NSObject {
}

- (void)myMethod;

You could do a cheap obfuscation like this:

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

@interface MyClass : NSObject {
}

- (void)myMethod;

This way you can still use meaningful symbols in your source, but the compiler would turn it into "garbage" when not compiling for debugging.

---

1. Yes, you can take a look at EnsureIT for Apple iOS or Contaxiom Code Protection
2. It depends. Security normally introduce complexity, you have to balance it between usability.
3. Apple should not have any problem with it (correct me if I'm wrong), and I personally have few apps that uses code obfuscator.

---

Further to the earlier answers there are now several 3rd party tools that offer some degree of obfuscation and integrity protection including :-

1. Arxan,
2. Metaforic,
3. Cryptanium

They vary in capabilities and include :-

1. Control flow obfuscation e.g. ARM instruction flows are mangled with redundant instructions to try to hide the original purpose of the code,
2. 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,
3. 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
4. Anti-debug - code is inserted to break the usual debuggers (not always successfully),
5. Anti-tamper - usually builds a network of checksums that protect the binary code from modification,
6. 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.

---

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.