Almacenamiento en los recibos de compra de la aplicación en el llavero de la aplicación

Question

Nunca he implementado en la compra de la aplicación antes, así que usé la envoltura Mkstorekit y tengo una implementación de trabajo. MkStorekit mantiene todos los recibos en el uso de userdefaults .plist como BOOL, por lo que es muy simple que los piratas distribuyan las compras de la aplicación en un estado "agrietado". Una vez que se realiza la primera compra, se puede distribuir el paquete y el .plist puede ser recreado para habilitar los desbloqueos de IAP.

Me gustaría extender MKStorekit para crear los datos de validación de la compra de la aplicación en el llavero IOS. ¿Hay algún inconveniente o una posible razón para que esto falla por pagar a los usuarios, no sea confiable, o cualquier otra razón por la que sea una mala idea en general para hacer esto? Entiendo que la piratería es inevitable, y definitivamente no quiero alienar a los usuarios que pagan, pero siento que el uso de usuarios .plist es demasiado fácil de pasar por alto.

En mi escenario, se colocaría una cadena simple en el llavero cuando se realice la compra. De esa manera, si se distribuye el binario, los desbloqueables no están habilitados. Claro, sería posible presentarse con una solución, pero tomaría un poco más de esfuerzo y sabría cómo encontrar la bandera verdadera / falsa y hacer que siempre devuelva el valor correcto. A través de la ofuscación, incluso podría hacerlo un poco más difícil de rastrearlo.

Gracias por todas sus ideas y aprecio las respuestas evitando las respuestas obligatorias inevitables, de la piratería. Estoy más interesado en las viajabilidad técnica de esta solución.

Answer 1

Hacemos exactamente eso en nuestras aplicaciones y funciona great.it es una aplicación gratuita que puede actualizar a una versión completa y almacenamos el indicador de actualización en el llavero. El indicador de actualización es una cadena arbitraria que elija, pero a los efectos del llavero se trata como una contraseña, es decir, el valor para KsecvalueData está encriptado en el llavero. Una bonificación agradable sobre este enfoque es que si el usuario elimina la aplicación y luego la reinstala, todo se vuelve a habilitar como MAGIC porque los elementos del llavero se almacenan por separado de la aplicación. Y es tan poco trabajo adicional sobre el almacenamiento de algo en los valores predeterminados del usuario que decidimos que valió la pena.

Aquí es cómo crear el artículo de seguridad:

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

Aquí es cómo encontrar el artículo de seguridad para verificar su valor:

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 actualiceItemdata es nula, entonces la tecla no existe, por lo que puede asumir que la actualización no está allí o, lo que hacemos, se pone en un valor que significa no actualizado.

actualización

agregado KsecreturnData (gracias @luis por señalarlo)

código en GitHub (variante de arco)