iOS App Security and Analysis: Part 2/2

Defending Against Reverse Engineering

So how do you defend against reverse engineering of a binary? Remember when I said nothing is truly secure? Yep, that applies to this as well. Reversing an application through assembly can be incredibly complicated and tedious, yet there is little you can do to stop someone if they are determined. Your best hope of defense is to confuse the attacker so much that they will give up and turn their attention to other apps.

One way to do this is to apply name changes to important classes and methods via the preprocessor. Open Xcode and locate Meme Collector-Prefix.pch. Add the following code to the file:

#define MoneyManager DS_UIColor_Theme

This replaces all instances of MoneyManager with the more boring name DS_UIColor_Theme, hopefully one which attackers would find less interesting to inspect.

Great care should be taken with this approach. This is a "hacky" solution at best and you need to be absolutely certain that your replacement name is unique to your app, or else some really weird bugs will start cropping up.

Normally, the app binary has a symbol table that maps addresses to human-readable function and method names. Another solution to make code harder to find is to strip the symbol table after you have built the project. This is mostly useful for hiding C/C++ functions since Objective-C messages are dispatched with objc_msgSend.

In Xcode, open MoneyManager.m and add the following C function at the top:

BOOL aSecretFunction(void) {
    return YES;
}

After you add this function, recompile the app. In Terminal, check for the existence of this function in the symbol table:

> nm Meme\ Collector | grep aSecretFunction
000193ad t _aSecretFunction

The nm command displays information regarding the symbol table. An easy way to strip the symbol table of C/C++ function information is by going into Xcode and changing around the Deployment Postprocessing and Strip Linked Product flags to YES.

Go to the Meme Collector project and click on Meme Collection target, then the Build Settings tab and type post into the search bar.

The two options Deployment Postprocessing and Strip Linked Product will come up. Change both of those to Yes. Make sure you clean and then recompile the app.

To test that the symbols were stripped, go to Terminal and rerun the previous command:

> nm Meme\ Collector | grep aSecretFunction
>

Excellent. You’ve successfully stripped the symbol linking to aSecretFunction. This will result in the attacker having to do more work to hunt down a critical section of code.

Where to Go from Here?

As you’ve seen, an attacker can:

• easily view the Objective-C selectors;
• manipulate the files associated with your binary;
• manipulate the network interactions;
• manipulate the runtime;
• and even change your app’s binary.

When building an application, it’s important to remember these points. Although security is crucial, you also need to consider the additional effort required to make an app more secure. Security is always a balance between your time and resources, the amount of trouble for your users, and the likelihood of attack.

iOS app security is a big topic; there's a lot to learn and you've only just scratched the surface of what the debugger and analysis tools can do! If you found this topic interesting, you should:

• Consider jailbreaking your iOS device: You can learn SO MUCH from exploring the filesystem.
• Check out Hacking and Securing iOS Applications: Although it is a smidge dated (you will need to look to Google for updates as to how Apple handles app encryption), this book is one of my favorites for iOS and security.

As always, feel free to join in the forum discussion below if you have any questions or comments.