Today I am going to list of various mechanism used by hackers to overcome our in-app purchase utility of one of our top apps in books section called “Story Time for Kids”
As you are aware apple stores each purchase receipts and allows developers an interface to verify each receipt before delivering the purchases (unlocking). Recently many jailbreakers have tried to hack into our system and unlock in-app content for free. I will discuss some very popular mechanisms and how we’ve tried to solve them:
1. Change the DNS of the iPhone. Hackers changed the DNS of the device and instead of redirecting the verification of purchase receipts to Apple servers, they could redirect it to their own custom server and send a custom verification. This way the app would get unlocked and no one would ever come to know. However, the good news is that Apple has patched this and now its kinda safe.
2. Change of DNS of the server side verification. If your in app purchase verifies the receipt via a server, then hackers could change the url via a firewall / middle-ware in between which could return a positive purchase of the unlockable item. There are many apps in Cydia who can do this and you as a owner will never come to know that the purchase was unlocked. Unfortunately there is no out of the box solution except your app keeps checking periodically with an online database if it was purchased or not.
3. Change of Product ID – Spoofing : Many jailbroken iOS devices just change the outgoing purchase receipt to an existing valid purchase receipt. (There are background apps to do this). Our server will then send this to Apple server for verification and guess what, apple will send a confirmation! A sheer good trick. But we’re smarter. Before sending the receipt for verification, unpack it (base64_decode) and extract out the product_id from it. Then check if the product_id is your genuine product or not. If not, just cancel it out. The most famous spoofed product id is :
If you encounter any product ID apart from your own, then simply block them. They are not genuine at all!
Thanks for this article. Our server just received a bunch of those fake receipts and we were wondering where they come from.
Same here, just noticed a bunch of the superpower1 products that our server logged and found your blog via Google. Thanks!
Awesome website you have here but I was wanting to know if you knew of any forums that cover the same topics discussed in this article?
I’d really love to be a part of community where I can get responses from other experienced people that share the same interest. If you have any suggestions, please let me know. Thanks!
Hi there mates, fastidious post and good arguments commented here, I
am genuinely enjoying by these.
Article writing is also a fun, if you know afterward
you can write or else it is difficult to write.
At this moment I am going to do my breakfast, afterward having my breakfast coming again to read further
Whats up! I just would like to give an enormous thumbs
up for the great information you could have right here on this post.
I will be coming back to your blog for extra soon.
I like to disseminate knowledge that I’ve accrued through the year to assist improve group efficiency.
Great article. Thanks.
Indeed, we received unconfirmed in-app purchase requests from some users before. After including additional check with our servers it was solved.
There is no need to make base64 decoding of received from the device message.
Possible to confirmation from Apple on your servers, then compare ‘product id’ item with existing product IDs.
You said that Apple checks whether the receipt’s product_id matches a valid one, but clearly ‘com.zeptolab.ctrbonus.superpower1’ isn’t a valid IAP (for my App at least). Apple verification still says that a receipt with ‘com.zeptolab.ctrbonus.superpower1’ is valid though. This makes me think 2 things:
1) Is apple not checking product_id?
2) Why can’t the hacker just use one of my own valid IAP product_ids instead of the zeptolab one?
Leave a comment