13

I was discussing this with some friends and we began to wonder about this. Could someone gain access to URLs or other values that are contained in the actual objective-c code after they purchase your app?

Our initial feeling was no, but I wondered if anyone out there had definitive knowledge one way or the other?

I do know that .plist files are readily available.

Examples could be things like:

-URL values kept in a string

-API key and secret values

dredful
  • 4,378
  • 2
  • 35
  • 54
  • 9
    The DRM people have been trying to solve this problem for ages, but what it boils down to is "I just want the device to be able to read it but not people to read it" which is the same as "I want people to be able to read it, I just don't want them to be able to read it". The only thing you can really do is obfuscate the strings by "scrambling" them with some sort of algorithm like rot13, or maybe something more advanced, but if you use encryption then you have to store the key somewhere in the executable. – Nimrod Oct 12 '10 at 23:57

3 Answers3

22

Yes, strings and information are easily extractable from compiled applications using the strings tool (see here), and it's actually even pretty easy to extract class information using class-dump-x (check here).

Just some food for thought.

Edit: one easy, albeit insecure, way of keeping your secret information hidden is obfuscating it, or cutting it up into small pieces.

The following code:

NSString *string = @"Hello, World!";

will produce "Hello, World!" using the strings tool. Writing your code like this:

NSString *string = @"H";
string = [stringByAppendingString:@"el"];
string = [stringByAppendingString:@"lo"];
...

will show the characters typed, but not necessarily in order.

Again: easy to do, but not very secure.

Itai Ferber
  • 28,308
  • 5
  • 77
  • 83
  • 5
    even just suggesting security though obscurity should get you a -1. You should tell people that what they are trying to accomplish is a vulnerability. False hopes get people hacked. – rook Oct 13 '10 at 00:38
  • @Rook: Sometimes obscurity is appropriate, e.g. if you're hiding cheat codes in a game, anything more secure would be overkill. ALSO: If that's how you feel, how come you didn't downvote it? – benzado Oct 13 '10 at 01:09
  • 3
    @Rook, while I definitely think you are allowed to disagree with me, I'm not sure you fully read my post, or considered what I was saying. I made sure to mention that the method was insecure, and got nobody's hopes up. That definitely does not warrant a downvote. And then again, obfuscation might be strong enough, depending on what the obfuscation is used for (as @benzado correctly pointed out). – Itai Ferber Oct 13 '10 at 03:41
  • @itaiferber Yeah but you should ask what he is trying to hide. He might be doing something stupid like hiding a username/password used in an HTTP Auth for a REST service that is exposing nasty functionally. The solution is to write secure REST service, hiding the username/password doesn't do shit when you can just sniff the network. – rook Oct 13 '10 at 04:07
  • @Rook/@itaiferber - Thanks for everyone's participation. I understood the context of @itaiferber's answer. The information I was after was in the first part. – dredful Oct 13 '10 at 16:32
  • @Rook As long as the person understands the level of security that is being gained I see no problem. It may help protect against some snooping. – zaph Dec 30 '13 at 21:58
12

When you purchase an app it is saved on your hard disk as "FooBar.ipa"; that file is actually in Zip format. You can unzip it and inspect the contents, including searching for strings in the executable. Try it! Constant values in your code are not compressed, encrypted, or scrambled in any way.

benzado
  • 82,288
  • 22
  • 110
  • 138
1

I know this has already been answered, but I want to give my own suggestion too.

Again, please remember that all obfuscation techniques are never 100% safe, and thus are not the best, but often they are "good enough" (depending on what you want to obfuscate). This means that a determined cracker will be able to read your strings anyways, but these techniques may stop the "casual cracker".

My other suggestion is to "crypt" the strings with a simple XOR. This is incredibly fast, and does not require any authorization if you are selling the app through the App Store (it does not fall into the categories of algorithms that require authorization for exporting them).

There are many snippets around for doing a XOR in Cocoa, see for example: http://iphonedevsdk.com/forum/iphone-sdk-development/11352-doing-an-xor-on-a-string.html

The key you use could be any string, be it a meaningless sequence of characters/bytes or something meaningful to confuse readers (e.g. use name of methods, such as "stringWithContentsOfFile:usedEncoding:error:").

ItalyPaleAle
  • 7,185
  • 6
  • 42
  • 69