4

I read (almost) all the answers on verifying in-app purchase, and actually I already implement it in a server-side fashion. But managing a server sometimes could be too much expensive, and in theory you could do the verify from your app: basically is just sending a json to Apple and get the answer back. Of course I know that on jailbroken devices the receipts may be fake (that's why you verify them) but (I beg pardon my ignorance) why I can't trust an https connection to the Apple server? I mean if the user hack my app, there's no real way to be sure of anything, but if the hack is a general method to provide fake receipts testing with Apple could be enough right?

To be clear, what is the security level of an in-app verify of recipts? Can it add some degree of protection os is useless?

il Malvagio Dottor Prosciutto
  • 1,332
  • 18
  • 27
  • I'm not looking for the CODE to do that (I know how to send a json, even if there's always something to learn of course) but I'm not a security expert and don't want to suggest to customers solutions that are plain wrong or even just useless... – il Malvagio Dottor Prosciutto Nov 16 '11 at 13:03

2 Answers2

4

This answer explains quite well why you must use server side checking to limit the effect of some "general purpose" crackers, like "IAP cracker"; besides chaining the iTunes json request in your content delivery API is quite convenient and the answer is fast.

Of course if your aim is to provide some content already in the app but locked, you may feel it is not convenient to setup a server specifically for this, but I will ask you to do this experiment:

  1. make an app with some good content and this content already locked in the app (so no content server need)
  2. add some analytics just to track the usage of this locked feature
  3. after some month, compare the number of purchases with the number of new users using the paid feature.
  4. at this point it will be clear for you that adding a server script just for receipt validation is a good investment; besides there are some services, which are very cheap (e.g.: urban airship) we already do this for you, so you don't need to setup an hardware for this.
Community
  • 1
  • 1
viggio24
  • 12,316
  • 5
  • 41
  • 34
  • I already read that, but it just state "better do this way", without any real explainations! I mean, the suggested solution works and is quite robust and probaly lots more secure than a verification from client, but again, for the purpose of unlocking some already built-in feature why I can't verify directly from my app via https with Apple store? – il Malvagio Dottor Prosciutto Nov 18 '11 at 07:56
  • IAP cracker claims to provide IAP unlocking if there is no external server receipt check. What it probably does is to fake the connection to the buy.itunes.apple.com by returning you a valid receipt json ("status"="0"); and if it doesn't do it, it is easy in any case for a user to setup its local DNS to point to a fake buy.itunes server that always returns a valid receipt result. Clearly using an external validation server a general purpose tool like IAP cracker or the DNS trick has no effect on the verification stage (so your app is more robust to general purpose IAP cracks) – viggio24 Nov 18 '11 at 08:29
  • sorry me been soo much tedious, but you know for sure that iAD implements the local DNS hack or is just a supposition? 'Cause I red it "just" hack the in-app calls, not the whole https layer... – il Malvagio Dottor Prosciutto Nov 20 '11 at 15:17
  • I don't think IAP cracker implements the DNS hack, this is beyond its scope, it simply hacks the in-app calls. Anyway it would be quite easy for it to change the DNS settings in the jailbroken device, so I would consider this possibility realistic. – viggio24 Nov 23 '11 at 08:32
  • I get it. Anyway I'll suggest my customers service like Urban Airship (by the way, you know others reliable?) if they don't want to manage a dedicated server. – il Malvagio Dottor Prosciutto Nov 23 '11 at 08:54
  • I think UA is the only valid choice at the moment, but with drawbacks: cost per download and the need to upload each product twice (App Store + UA) – viggio24 Nov 23 '11 at 10:06
  • You right, but people that sell contents maybe still prefer owning and managing the content server. I see it useful for unlock-the-features low budget apps, where you don't have anything else to download. – il Malvagio Dottor Prosciutto Nov 23 '11 at 11:21
0

I hack inapp cracker and discover a way to block it client side: the receipts and transaction IDs it creates have a predictable scheme that's easy to spot. I put all the details here: spot fake receipts client side update

hope this helps

il Malvagio Dottor Prosciutto
  • 1,332
  • 18
  • 27