I’m sorry, I don’t have all the info you need.
I only have consumables with IAP, so I don’t have a restore button/function and I don’t have to deal with the complexities linked to non-consumables.
I do believe you want to verify the receipt when a user clicks the restore button for non-consumables. This will prevent the most commonly used crack I believe.
Information on preventing piracy is hard to find, basically no one wants to inform hackers/pirates on their techniques, because they would use this information to circumvent the anti-piracy techniques they have integrated.
I believe there are 2 main cracks used and 1 app specific crack/hack where the targeted app is literally hacked at the code level, but due to the work required is least common, but is the most difficult to deter.
The most common crack is the one used by the Russian Hacker a few months back for the first time with NON jailbroken devices and used in jailbroken devices for quite awhile. It is widely used because it targets all apps for vulnerability, it is not app specific. This is where the store.function call to the AppStore URL’s are intercepted and redirected to a simulated AppStore server either loaded on the device or on a remote server. The simulated server returns a fake and invalid receipt which the IAP callback accepts blindly as valid.
This is where the developer should init the IAP verification routine, send the receipt to your server, your server forwards it to the AppStore for validity, the AppStore will return an invalid status code because the receipt is garbage. I’ve read it is guessed that 99% of all apps do not take the extra step to verify the receipts on an external server, this is why the crack is so successful and widely used.
Verifying a new purchase receipt is fairly straightforward and understandable to me. I have coded and can make this work.
Restoring a purchase is quite a different animal in my view.
If a user clicks on a purchase item button to “restore” it to their device, an already purchased non-consumable, a single receipt will be returned by the AppStore (valid) and the crack (invalid). This would be handled exactly the same as an original purchase and the IAP Verification routine would invalidate a cracked receipt.
The store.restore() called by the restore button is where my eyes glaze over and I’m way out of my league.
I believe there are 2 different methods to pursue here.
I believe when the store.restore() is called, the AppStore returns a copy of all the non-consumable receipts the user has purchased specific to the app. I can understand how to verify a single returned receipt, if the user only made 1 purchase of a non-consumable, but I do not understand how to verify and restore multiple purchases/receipts returned at once. I’m not sure of the timing and mechanics of the restore receipt delivery. I realize the restore callback would fire, just not sure how it handles a rapid sequence delivery of receipts.
The separate receipts would have to be gathered/stored as they are received.
Mehod 1 would be to verify each receipt individually through the IAP verification routine I would think. I am not sure how that would be done exactly, so I can’t give you the code. Then when the receipt is validated, call the function to restore the productIdentifier in the receipt.
Method 2 would be to store each original purchase receipt when first transacted and compare them to each restore receipt received. If they match, call the function to restore the productIdentifier.
Since I have not done a successful restore of multiple purchased products, if would be great if someone that has successfully coded it would share any insights.
I am not addressing the more sophisticated addition to this crack/hack where the crack re-uses/ returns a valid receipt from the AppStore that has been obtained from a valid purchase. I believe Apple has implemented a safegaurd against this. They have added a new identifier to AppStore receipt, it is the “unique_identifier”. No one really knows if this is a hash of the UDID or a new UUID, but it seems Apple is aware of the receipt recycling technique and is comparing it to the AppleID associated to it during the IAP Server Verification process. This is not confirmed, but only makes sense as this was a KEY missing piece of the AppStore receipt/process.
Good Luck,
Nail [import]uid: 106779 topic_id: 30371 reply_id: 124317[/import]
