Question

I’ve never implemented In App Purchase before, so I used the MKStoreKit wrapper and have a working implementation. MKStoreKit keeps all receipts in the UserDefaults .plist as a BOOL, thus it is very simple for pirates to distribute the in app purchases in a “cracked” state. Once the first purchase is made, the bundle can be distributed and the .plist can be recreated to enable IAP unlocks.

I’d like to extend MKStoreKit to create the In App Purchase validation data in the iOS keychain. Is there any drawback or possible reason for this to fail for paying users, be unreliable, or any other reason why it would be an overall bad idea to do this? I understand that piracy is inevitable, and I definitely don’t want to alienate paying users, but I feel that the UserDefaults .plist is too much of an easy way to bypass.

In my scenario, a simple string would be put into the keychain when the purchase is made. That way, if the binary gets distributed, unlockables are not already enabled. Sure, it would be possible to come up with a workaround, but it would take a little more effort and know how to find the TRUE/FALSE flag and cause it to always return the correct value. Through obfuscation I could even make it slightly more difficult to track that down.

Thanks for all of your insights and I appreciate answers avoiding the obligatory inevitable-piracy, deal-with-it replies. I’m more interested in the technical viabilities of this solution.

Answer 1

We do exactly that in our of our apps and it works great.It’s a free app that you can upgrade to a full version and we store the upgrade indicator in the keychain. The upgrade indicator is an arbitrary string that you choose, but for the purposes of the keychain it is treated as a password, i.e. the value for kSecValueData is encrypted in the keychain. A nice bonus about this approach is that if the user deletes the app and then later re-installs it, everything is re-enabled like magic because the keychain items are stored separately from the app. And it’s so little additional work over storing something in the user defaults that we decided it was worth it.

Here’s how to create the security item:

NSMutableDictionary* dict = [NSMutableDictionary dictionary];

[dict setObject: (id) kSecClassGenericPassword  forKey: (id) kSecClass];
[dict setObject: kYourUpgradeStateKey           forKey: (id) kSecAttrService];
[dict setObject: kYourUpgradeStateValue         forKey: (id) kSecValueData];

SecItemAdd ((CFDictionaryRef) dict, NULL);

Here’s how to find the security item to check its value:

NSMutableDictionary* query = [NSMutableDictionary dictionary];

[query setObject: (id) kSecClassGenericPassword forKey: (id) kSecClass];
[query setObject: kYourUpgradeStateKey          forKey: (id) kSecAttrService];
[query setObject: (id) kCFBooleanTrue           forKey: (id) kSecReturnData];

NSData* upgradeItemData = nil;
SecItemCopyMatching ( (CFDictionaryRef) query, (CFTypeRef*) &upgradeItemData );
if ( !upgradeItemData )
{
    // Disable feature
}
else
{
    NSString* s = [[[NSString alloc] 
                        initWithData: upgradeItemData 
                            encoding: NSUTF8StringEncoding] autorelease];

    if ( [s isEqualToString: kYourUpgradeStateValue] )
    {
        // Enable feature
    }
}

If upgradeItemData is nil, then the key doesn’t exist so you can assume the upgrade is not there or, what we do, is put in a value that means not upgraded.

Update

Added kSecReturnData (Thanks @Luis for pointing it out)

Code on GitHub (ARC variant)