*Intrinsic Vulnerabilities In ObjC Runtime – and one solution, Obfuscation

From initial MarcWeil comment in CocoaInsecurity: * …there is an inherent insecurity in all Cocoa applications, simply by the nature of the ObjectiveC Runtime and the organization of MachO executables (what with name and symbol tables embedded right into them, which can be accessed easily with programs such as nm, otool, and class-dump)… *

This means that it is easy for an InputManager to be used against your protection scheme

If you are developing an application in Cocoa, and earning money off of it is important to you or your company, then remember these key points when designing your registration model (and keep in mind that these are only the most basic strategies):

• Avoid the use of ObjC methods when writing your core protection scheme functions.
• Avoid the use of blatantly specific names for classes that involving protecting your application, such as RegistrationClass or ProtectionScheme.
• If at all possible, create your reg classes on-the-fly instead of at design time.
• When compiling your final project, be very, very sure that you uncheck the checkboxes for generating debugging symbols, profiling information, etc. in Xcode. Also be sure you don’t compile with -O0 as your optimization level, because even then it would be easy to find out how your functions work by using a debugger or some other kind of application.
• And most importantly: STRIP YOUR FINAL EXECUTABLE OF ALL SYMBOLS BEFORE PACKAGING This is done using the UNIX program called strip which comes with OS X. To view the man page, open the Terminal and type man strip. You can also use ProjectBuilder to view the man page in prettier style. Stripping all non-global and non-external symbols (which include your application’s references to the AppKit and FoundationKit, as well as to any other externally linked frameworks you may use) should keep prying eyes from class-dumping your program’s executable to file to view all of your classes and methods.

MarcWeil closed his discussion of the above observations with this: * However, always keep in mind the grim truth that a determined hacker will almost always find a way to circumvent your licensing and protection scheme, no matter to what lengths you go to protect your program from such break-ins. *