I haven't looked at this in depth but it sounds like they are pretending to be Apple and are sending a counterfeit response to the device. On the device there is a delegate callback that receives a SKPaymentTransaction object which has a bunch of information. I suspect the apps that are affected are just checking the state of the payment and not taking the transactionReceipt property and checking it with Apple to make sure it is legit.
It seems really strange that the StoreKit framework itself wouldn't perform a signature check (preferably pinned towards whatever built-in Apple CA necessary) before handing it off to the delegate callback, don't you think?
"When Store Kit returns a completed purchase to your payment queue observer, the transaction’s transactionReceipt property contains a signed receipt that records all the critical information for the transaction. Your server can post this receipt to the App Store to verify that the receipt is valid and has not been tampered with."
A double check to be sure nothing is amiss I guess. I do find it strange that they can't guarantee this callback is not trigged by a response from a HTTPS source. Actually maybe they are and this fake cert is what is allowing it so they added this two phase check just in case. But this ability to verify is also kept around if you store these receipts on your server. Before you write them to your DB you can check with Apple to make sure they are legit.
Another curious thing in the video demo is the alert dialog popup box that is triggered during the fake purchase, the one with the "Like" button and "Cancel" in Russian. Perhaps the storekit receipt transmission protocol allows for injecting actions on the device such as opening alert boxes, in addition to just posting a signed JSON receipt?
You have to get the check to a piece of trusted hardware for it to not be permanently bypassable (aka, not the device) by a jailbreak style hack of the storekit libraries.
The check HAS to be done off the phone for the hack to not be global and ever available.
Well, in this case there's no jailbreaks involved, so no code modification or patching. Obviously if you have root access on the device you can do "anything"; the "non-JB-ness" of this hack is what was particularly intriguing.
(also, if the ipa contains all data required for the IAP to work, a jailbroken device stands no chance -- any server checks could simply be NOP'ed out)
You have to NOP each program, as the code to check each program against the server (which is written by the 3rd party developer, which then talks to apple server), which is significantly more effort than if the verification with the apple server occurred on the device.
Here is Apple's docs on how to verify a receipt http://developer.apple.com/library/ios/#documentation/Networ...