26

Possible Duplicate:
iPhone/iPad App Code Obfuscation - Is it Possible? Worth it?

I have spent a lot of time on this and I couldn't able to find a perfect answer. That's why I decided to put my question here. I have an iPhone application and want to encrypt the code to prevent from class-dump or otool utilities. (Tools used to dump out the headers from executable). I would like to know is there any way to encrypt the source code or obfuscate the source code?

Community
  • 1
  • 1
Johny_568
  • 365
  • 1
  • 3
  • 9
  • Why? If you tell us what you are really trying to do, there may be a better way. – JeremyP Jun 06 '11 at 08:05
  • I have seen that the class-dump tool can dump out the headers easily and can see the function/method signatures. I want to encrypt the header file (the dumped out header file should be encrypted) or implement code obfuscation in my code. That's what I need to implement. Hope you get more information. – Johny_568 Jun 06 '11 at 08:09
  • @Black Frog : I have tried that method also, but it didn't worked for me. :( – Johny_568 Jun 06 '11 at 08:10
  • The class dump tools do *not* dump the contents of the header files, they dump the compiled interfaces in a human readable form. – JeremyP Jun 06 '11 at 08:22
  • @Jeremy : But anyway it print out the signatures that we declared in header files right? – Johny_568 Jun 06 '11 at 09:01
  • @Johny_568: yes but that can't be avoided if you want dynamic binding. Anyway, the point is moot because applications delivered from the app store are apparently encrypted. – JeremyP Jun 06 '11 at 10:03

3 Answers3

16

It's a lot more complicated than it might seem initially. Any tool that mangles method names has the potential to fudge up:

  1. KVC compliance
  2. The use of dynamically generated selectors
  3. Nib file compatibility
  4. Protocol conformance
  5. Method inheritance

Obfuscation is just another layer to deal with; often obfuscation is easily reversed. It is not really possible to “encrypt” your classes because the Objective-C runtime and Cocoa framework won't know how to decrypt it. Anyone determined enough will eventually figure out how your program works.

dreamlax
  • 93,976
  • 29
  • 161
  • 209
  • 4
    People building copy protection usually get paid. People who remove it usually don't. In the end - if you do it right - you have a good chance a reverser will give up because it just takes too much time too understand or counter your protections. But you are right, this is not the ultimate solution - just the best one. – jimpic Jun 24 '13 at 13:46
8

Actually you can provide some obfuscation and tamper protection with specialist 3rd party tools. There are 2 companies, I know of, that provide tools or services to do this : Arxan and irDato.

Neither are cheap or accessible to small developers but if you are developing for a large corporation then you should consider them.

Obfuscation is done by mangling code paths and adding redundant instructions so as to confuse anybody trying to reverse engineer the code. Tamper protection is done by adding checksums to the code and embedding checksum checks within functions. You can create a network of interdependent checksums that makes it extremely difficult to bypass them. There are a few other things that can be done but you really need to talk to specialists in this area.

Further to the earlier answer, Apple does not encrypt the binaries but just signs them. It is fairly easy to reverse engineer and modify app binaries on a jailbroken device.

Andrew
  • 993
  • 9
  • 11
  • 6
    Apple *does* encrypt binaries that are distributed through the app store. See [Hacking and Securing iOS Applications](http://my.safaribooksonline.com/book/-/9781449325213) pages 156-162. However, the encryption is easily removed. – funroll Jul 18 '12 at 14:34
-2

Apparently, according to this answer Apple encrypts iPhone binaries as a matter of course for all iPhone apps.

I'd stop worrying about it.

Community
  • 1
  • 1
JeremyP
  • 84,577
  • 15
  • 123
  • 161