Decompilation Possibilities in iOS and How to Prevent Them

Decompilation possibilities in iOS and how to prevent them

This is a problem that people have been chasing for years, and any sufficiently-motivated person with skills will be able to find ways to find out whatever information you don't want them to find out, if that information is ever stored on a device.

Without jailbreaking, it's possible to disassemble apps by using the purchased or downloaded binary. This is static inspection and is facilitated with standard disassembly tools. Although you need to have a tool which is good enough to add symbols from the linker and understand method calls sufficiently to be able to tease out what's going on. If you want to get a feel for how this works, check out hopper, it's a really good disassembly/reverse-engineering tool.

Specifically to your secure log in question, you have a bigger problem if you have a motivated attacker: system-based man-in-the-middle attacks. In this case, the attacker can shim out the networking code used by your system and see anything which is sent via standard networking. Therefore, you can't depend on being able to send any form of unencrypted data into a "secure" pipe at the OS or library level and expect it not to be seen. At a minimum you'll need to encrypt before getting the data into the pipe (i.e. you can't depend on sending any plain text to standard SSL libraries). You can compile your own set of SSL libraries and link them directly in to your App, which means you don't get any system performance and security enhancements over time, but you can manually upgrade your SSL libraries as necessary. You could also create your own encryption, but that's fraught with potential issues, since motivated hackers might find it easier to attack your wire protocol at that point (publicly-tested protocols like SSL are usually more secure than what you can throw together yourself, unless you are a particularly gifted developer with years of security/encryption experience).

However, all of this assumes that your attacker is sufficiently motivated. If you remove the low-hanging fruit, you may be able to prevent a casual hacker from making a simple attempt at figuring out your system. Some things to avoid:

• storing plain-text encryption keys for either side of the encryption
• storing keys in specifically named resources (a file named serverkey.text or a key stored in a plist with a name which contains key are both classics)
• avoid simple passwords wherever possible

But, most important is creating systems where the keys (if any) stored in the application themselves are useless without information the user has to enter themselves (directly, or indirectly through systems such as OAUTH). The server should not trust the client for any important operation without having had some interaction with a user who can be trusted.

Apple's Keychain provides a good place to store authentication tokens, such as the ones retrieved during an OAUTH sequence. The API is a bit hard to work with, but the system is solid.

In the end, the problem is that no matter what you do, you're just upping the ante on the amount of work that it takes to defeat your measures. The attacker gets to control all of the important parts of the equation, so they will eventually defeat anything on the device. You are going to need to decide how much effort to put into securing the client, vs securing the server and monitoring for abuse. Since the attacker holds all of the cards on the device, your better approach is going to be methods that can be implemented on the server to enhance your goals.

decompile an app binary to get back to source code

You can disassemble a binary and get back assembly source, but there is no way to get back your original Objective-C structured source code.

---

EDIT:
You may want to give Hopper a try. I didn't try it personally yet but Mike Ash says it's good.

Decompiling iOS Objective-C binaries]

The binary of all apps from the iOS App store, and on the filesystems of stock OS devices, is encrypted.

Try writing the authors of the app very politely, and see if they'll give or offer to sell you source code for the parser in which you're interested.

Is it possible for an app to be decompiled?

Yes, it is possible. Assume that if you have anything compiled into your app, it can [and will] be discovered by someone somewhere. Even if it isn't possible today, you are creating a frozen record of such information that will be vulnerable to any future attacks, known or unknown.

You really need the user to perform some task that authenticates them. There are a million and one ways to do that, and for every one of those, a million and two ways to do it wrong. :)

Without knowing more about your specific requirements, it is impossible to really say much more outside of "keep it simple and don't store or send anything in clear-text".

How to protect app IPA from hacks if reverse engineering is possible

There's always a risk involved. Even if you don't introduce vulnerabilities yourself, the platform may allow for exploits which in the end may offer an entry point for a malicious attacker.

As to your question: It is not safe to assume that a hardcoded URL, even if obfuscated beyond belief, can't be peeled out of your product. Always design your apps such that safety of user data is guaranteed (as far as possible) even if built in ressources get compromised. If the knowledge of that URL alone poses a security threat, then your whole approach and your clients API is inherently insecure. Remember that such information could possibly be captured by a man-in-the-middle attack (and other modes of attack) as well.

Avoid security by obscurity. Store sensitive data only on disk if it is necessary. As a rule don't allow PIN / TAN storage.

Some thoughts which may (or may not) convince your client that your app is as safe as it can be:

• As long as the app runs on a non-jailbroken device, it is unlikely that an attacker, even with knowledge of your apps internals is able to get to any user data, because the iPhone normally doesn't offer opportunities to interfer with your app
• If the attacker is able to get to your users data, and provided you have been protecting that data with all means available under iOS (-> keychain -> crypto chip ->...), then it's not your fault. It means the device is either jailbroken or there are vulnerabilities to the system itself which have been exploited, you just can't do anything about either possibility.
• It is impossible to prevent reverse engineering of your app. Even if you had put more effort into obfuscation, an attacker with strong motivation would still be able to get what he wants. Your client needs to get used to this as it's a fact.
• Other platforms suffer from similar vulnerabilities, yet on the iPhone at least you have a somewhat closed environment and a reduced risk of being attacked with trojans and the like.
• The governments and security firms get hacked on a regular basis, although they should now how to protect themselves. This means life is inherently insecure, cope with it.

MonoTouch: How to protect my application

Foremost you need to remember that iOS does not allow JIT (just in time) compiling. This means everything needs to go thru the AOT (ahead of time) compiler.

This results that all the IL code from your assemblies is being converted into native ARM (v6, v7 and/or thumb) instructions and that the IL is not required anymore.

This means that, when you're building for Release|iPhone, the IL code will be removed from your assemblies. Since it's strip'ed away it won't be present (to be decompiled) in the application you publish.

NOTES

• the assemblies will still be inside the application because the metadata is still required (e.g. System.Reflection needs it). So symbols names and resources files won't be mangled/encrypted like obfuscators generally do;

• You can disassemble ARM assembly (that would be true even if you obfuscated the assemblies before the AOT compilation) but it's much harder to understand (and get back to C#) than IL is.

• Extracting the assemblies from the IPA and procesing them will break at least the application's signature (you can re-sign it). It will also likely break a lot of other things (since the code will refer to names/structures that might have changed). I do not think this will work (but it depends on the options you would use from your obfuscator).

---

Related Topics