Memorizzazione nelle ricevute di acquisto di app nel portachiavi dell'applicazione

Question

Non ho mai implementato l'acquisto di app prima, quindi ho usato il wrapper Mkstorekit e ho un'implementazione funzionante. Mkstorekit mantiene tutte le ricevute in UserDeFaults .plist come bool, quindi è molto semplice per i pirati distribuire gli acquisti in app in uno stato "incrinato". Una volta effettuato il primo acquisto, il bundle può essere distribuito e il .plist può essere ricreato per abilitare sblocchi IAP.

Mi piacerebbe estendere Mkstorekit per creare i dati di convalida dell'applicazione in app nel portachiavi iOS. C'è qualche svantaggio o possibile ragione per cui questo per fallire per pagare gli utenti, essere inaffidabili o qualsiasi altra ragione per cui sarebbe una cattiva idea generale fare questo? Capisco che la pirateria è inevitabile, e sicuramente non voglio alienare gli utenti pagando, ma ritengo che i userdefaults .plist sia troppo facile per bypassare.

Nel mio scenario, una semplice stringa sarebbe messa nel portachiavi quando viene effettuato l'acquisto. In questo modo, se il binario viene distribuito, i sbloccabili non sono già abilitati. Certo, sarebbe possibile trovare una soluzione alternativa, ma ci vorrebbe un po 'più di sforzi e sapere come trovare la bandiera TRUE / FALSE e causerlo a restituire sempre il valore corretto. Attraverso l'offuscamento potrei persino renderlo leggermente più difficile tracciarlo.

Grazie per tutte le tue intuizioni e apprezzo le risposte evitando l'obbligatorio inevitabile-pirateria, le risposte-con-it. Sono più interessato alle prostitute tecniche di questa soluzione.

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)