iphone - solicita - quitar contraseña llavero mac

Almacenamiento de recibos de compra en la aplicación en la aplicación Llavero

Question

Nunca he implementado In App Purchase antes, así que usé el contenedor MKStoreKit y tengo una implementación que funciona. MKStoreKit conserva todos los recibos en UserDefaults .plist como BOOL, por lo que es muy simple para los piratas distribuir las compras en la aplicación en un estado "craqueado". Una vez que se realiza la primera compra, se puede distribuir el paquete y se puede recrear .plist para habilitar los desbloqueos de IAP.

Me gustaría extender MKStoreKit para crear los datos de validación de compra en aplicación en el llavero de iOS. ¿Existe algún inconveniente o una posible razón para que esto falle para los usuarios que pagan, que sea poco confiable o alguna otra razón por la que sería una mala idea general hacer esto? Entiendo que la piratería es inevitable, y definitivamente no quiero alejar a los usuarios que pagan, pero creo que la lista de errores predeterminados por el usuario es demasiado fácil de evitar.

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

Gracias por todas sus ideas y agradezco las respuestas que evitan las inevitables respuestas de piratería, trato con él. Estoy más interesado en las viabilidades técnicas de esta solución.

Answer 1

Hacemos exactamente eso en nuestras aplicaciones y funciona muy bien. 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 usted elige, pero a los efectos del llavero se trata como una contraseña, es decir, el valor de kSecValueData se cifra en el llavero. Una buena ventaja de este enfoque es que si el usuario elimina la aplicación y luego la vuelve a instalar, todo se vuelve a habilitar como magia 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 valía la pena.

Aquí es cómo crear el elemento 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 elemento de seguridad para comprobar 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 upgradeItemData es nil, entonces la clave no existe, por lo que puede suponer que la actualización no está allí o, lo que hacemos, se coloca en un valor que significa que no se actualizó.

Actualizar

Se agregó kSecReturnData (Gracias @Luis por señalarlo)

Código en GitHub (variante ARC)