2

Possible Duplicate:
Protecting executable from reverse engineering?

As primary goal, I would like to encrypt information about used header files and libraries

For the most part my application is writen in C++, using only standard I/O methods from the iOS SDK

Community
  • 1
  • 1
rraallvv
  • 2,875
  • 6
  • 30
  • 67
  • I like the approach proposed on the answer to that question, trying to dissuade the attacker to get an easier target, but... given enough (I quote the asker) "time frame" there will be no effective method, though... so I guess it's not possible to defeat reverse enginerring at all – rraallvv Nov 13 '12 at 05:54

2 Answers2

4

The app store already encrypts your application's executable file (or most of it) before sending it to a user's device. The iOS kernel decrypts the encrypted part of the file, in memory, when it launches your app.

Since Objective-C looks up classes by name when loading dynamic libraries (like UIKit and Foundation), and looks up method selectors by name at runtime, those class and selector strings must appear in your executable, but they are in the encrypted part of the file.

Jailbreakers can already defeat the iOS encryption system by examining your app's memory after the kernel has decrypted it.

Spending more time trying to hide these strings is almost certainly a waste of time.

UPDATE

If your target market is in a part of the world where jailbreaking is common, you might want to look for an application idea that uses a server back-end, and use in-app purchase to sell server access as a consumable item. Your server can verify that users have paid for server access, and you can ban accounts that try to steal access.

rob mayoff
  • 375,296
  • 67
  • 796
  • 848
2

Obfuscation is essentially flawed in that - by definition - it must always come with the code used to restore the application to its original form.

A skilled attacker (which is what you will be dealing with if anyone tries to reverse engineer at all) will not be hindered much by any obfuscation scheme.

0x90
  • 6,079
  • 2
  • 36
  • 55
  • In that case, obfuscation would be redundant if using another encryption methods, doesn't it? – rraallvv Nov 13 '12 at 05:31
  • Since you have to somehow deliver the key to decrypt the application for it to actually run on the device, either approach will trigger the same result. – 0x90 Nov 13 '12 at 05:42
  • 1
    hmm, I think I'll have to trust Apple encryption methods, and start to accept that my application will be in fact decrypted and reverse engineered at some point – rraallvv Nov 13 '12 at 06:06