How easy is it to crack a plist file in an app store app?

Question

Don’t worry, I’m not trying to hack someone else’s application if this is what you think =).

I want to have 2 versions of my application, a free version and a deluxe class version. My plan was to use the in-app purchase to enable the deluxe version by setting a boolean value in the plist file.

My question is: is it safe or is it easy to get around? And if it's not safe, can anyone suggest a simple alternative? I do not want to download additional content, I would prefer to save all the functions in the application and somehow enable it.

Edit: I do not mean the application plist file, but something like the user's default file.

Answer 1

You have to keep this in the keychain, here is what I will do. Keychain is much safer than .plist or custom defaults (which are also .plists as far as I know). Take a look at SFHFKeychainUtils , you can use this or just implement the best method just to keep a simple bool.

Answer 2

I would recommend reading an in-app purchase check . It seems to me that you are trying to launch your own in-app purchase verification system, which may be caused by problems that you might not have thought of. You must be careful with user purchases that they will behave the same in your application, as they will in any other so that you do not lose confidence (and future sales!)

Answer 3

Easy to edit com.something.plist without jailbreak. Using the free tool * you can view your device, you can also edit and save these files. If you store your inapp purchase like this:

 [[NSUserDefaults standardUserDefaults] setBool:YES forKey:@"com.example.pack1"]; [[NSUserDefaults standardUserDefaults] synchronize]; 

then this will be written to plist:

 <key>com.example.pack1</key> <true/> 

If you name your packages as follows: pack1, pack2, etc., and someone edits your plist (copy / paste the first key), he can easily use the lock function.

It is not too difficult to implement the method to save the following:

 [[NSUserDefaults standardUserDefaults] setValue:[self sha1ValueForKey:@"com.example.pack1"] forKey:@"com.example.pack1"]; [[NSUserDefaults standardUserDefaults] synchronize]; 

where -sha1ValueForKey: -

 -(NSString *)sha1ValueForKey:(NSString *)key { return [self sha1:[NSString stringWithFormat:@"<SALT>%@", key]]; } 

You need to change <SALT> to something.

Here you can find -sha1: :: http://www.makebetterthings.com/iphone/how-to-get-md5-and-sha1-in-objective-c-ios-sdk/

After that, you can check if the key matches the hashed value.

If someone wants to crack your plist, he / she should know your hash mechanism and salt. This is not the safest way to protect your application, but it is easy to implement.

* IEXPLORER

EDIT:
The proposed method only protects - somewhat - your IAP if the user does not have access to the hashed value. If someone gets it from somewhere, it's easy to copy this data into a plist. If SALT is device-dependent copying, it is useless.

Answer 4

Instead of worrying about the Info.plist file, why not just set the preference? Somewhere in your code this will give you your boolean value:

 [[NSUserDefaults standardUserDefaults] boolForKey:@"someKey"]; 

If the value does not exist, the result will be nil . This code sets the value:

 [[NSUserDefaults standardUserDefaults] setBool:YES forKey:@"someKey"]; 

In addition, these values ​​will be copied to iTunes, so if the user moves his backup to a new iPhone or simply restores the backup, the values ​​will be restored.

Answer 5

I have no answer, but it seems that editing your plist file is dynamically impossible if I trust this topic :

You cannot edit, you info.plist file dynamically. When you submit your application to the App Store, your application package, which includes info.plist, cannot be changed because the signature is created when you compile the application based on bundle.

Answer 6

Any pirate has a broken iPhone in prison. Any device damaged by the prison device provides full access to the file system using tools such as PhoneDisk, etc. Any access to the file system allows people to change values ​​in your applications .plist file

Game over.

Now, this is not trivial for a wrapper that is designed for <details> w370>, but again not so difficult.

Answer 7

Saving the default state is no more or less safe from privacy than having two versions of your application. Pirates are either the pirated version of deluxe or the pirated unified version with the flag set.