Stockage dans des reçus d'achat d'applications dans le porte-clés de l'application

Question

Je n'ai jamais implémenté dans App Achat auparavant, j'ai donc utilisé l'emballage Mkstorekit et j'ai une implémentation de travail. MKStorekit conserve tous les reçus dans les pertes d'utilisateur .plist en tant que bool, il est donc très simple que les pirates distribuent les achats de l'application dans un état "fissuré". Une fois le premier achat effectué, le bundle peut être distribué et le .plist peut être recréé pour permettre les déverrouilles IAP.

Je voudrais étendre Mkstorekit pour créer les données de validation d'achat de l'application dans le trousseau iOS. Y a-t-il un inconvénient ou une raison possible à ce que cela échoue pour les utilisateurs payants, ne soit pas fiable, ou toute autre raison pour laquelle ce serait une mauvaise idée globale de le faire? Je comprends que le piratage est inévitable, et je ne veux certainement pas aliéner les utilisateurs payants, mais je pense que le UserDefaults .Plist est trop un moyen facile de contourner.

Dans mon scénario, une simple chaîne serait mise dans le trousseau lorsque l'achat sera effectué. De cette façon, si le binaire est distribué, les déverrouillage ne sont pas déjà activés. Bien sûr, il serait possible de proposer une solution de contournement, mais cela prendrait un peu plus d'efforts et savoir comment trouver le vrai / faux drapeau et le faire renvoyer toujours la bonne valeur. Grâce à l'obscurcissement, je pouvais même rendre un peu plus difficile de retrouver cela.

Merci pour toutes vos idées et j'apprécie les réponses en évitant les réponses obligatoires inévitables à piratage inévitable. Je suis plus intéressé par les victibilités techniques de cette solution.

Answer 1

Nous faisons exactement cela dans nos applications et cela fonctionne très bien. C'est une application gratuite que vous pouvez mettre à niveau vers une version complète et nous stockons l'indicateur de mise à niveau dans le trousseau. L'indicateur de mise à niveau est une chaîne arbitraire que vous choisissez, mais aux fins du porte-clés, elle est traitée comme un mot de passe, c'est-à-dire que la valeur de KsecValuedata est cryptée dans le trousseau. Un bon bonus sur cette approche est que si l'utilisateur supprime l'application, puis le réinstalle plus tard, tout est réactivé comme la magie car les éléments de trousseau sont stockés séparément de l'application. Et c'est si peu de travail supplémentaire sur le stockage de quelque chose dans les paramètres par défaut de l'utilisateur que nous avons décidé que cela en valait la peine.

Voici comment créer l'élément de sécurité:

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);

Voici comment trouver l'élément de sécurité pour vérifier sa valeur:

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
    }
}

Si UpgradeItemData est nulle, alors la clé n'existe pas, vous pouvez donc supposer que la mise à niveau n'est pas là ou, ce que nous faisons, est mis en valeur qui signifie non amélioré.

Mise à jour

Ajout de ksecreturnata (merci @LUis pour l'avoir signalé)

Code sur github (variante d'arc)