July 28, 2012 at 15:22Protection against universal in-app shopping hacks
The protection method described below was hacked, read the continuation of this post: Protection against hacking in-app purchases. Part 2 .
Not so long ago, news about the activation of in-app purchases for free and even without jailbreaking was noisy. The idea is simple: ssl certificates are installed in the system and a custom dns server is registered, which will send requests to apple servers to the crackers server. The cracker server will confirm the purchase and it will be successfully activated on the device. After the release of this news, there was a lot of panic and Apple even had to do something and tell developers how to protect their application. In fact, the problem was not new; on jailbroken devices, it was long ago possible to activate in-app purchases for free. The solution to the problem is also not new, it is described in the Apple documentation, but no one bothered with the practical implementation. My version of such protection will be discussed below.
There are two possible scenarios. Simple:
The device activates the purchase through the apple server without additional validation and participation of the developer's server.
Complex:
The developer's server can participate in the purchase process as follows:
We are interested in steps 10-11, because it is on them that we can help the device determine whether the check was written out by the apple server or is it a fake.
We can only validate a purchase receipt on an Apple server. To do this, send JSON with a check encoded in base64, inside the HTTP POST request: To one of the Apple servers:
In response, the server will return the validation status, and if validation is successful, the decoded fields of the check:
Understanding the mechanics described above, it was not difficult to write a proxy application in ruby, which forwards validation requests to one of the Apple servers. I posted the application code on GitHub ready to use . I will be glad to improve and pull-requests. You can also touch it on heroku: https://receiptValidator.heroku.com/validate using the test check from the repository. With the checkbox sandbox you can see the correct answer, and without it, the error code.
In the application, we analyze the response of our server and decide whether to activate the built-in functions, or is it a suspicious check and can be ignored. If interested, in the next article I will write about protection inside the application.
PS A bit of unscrupulous self-PR: this protection was written specifically for Galileo Offline Maps and was successfully tested in version 2.2, which appeared in the AppStore yesterday morning.
Not so long ago, news about the activation of in-app purchases for free and even without jailbreaking was noisy. The idea is simple: ssl certificates are installed in the system and a custom dns server is registered, which will send requests to apple servers to the crackers server. The cracker server will confirm the purchase and it will be successfully activated on the device. After the release of this news, there was a lot of panic and Apple even had to do something and tell developers how to protect their application. In fact, the problem was not new; on jailbroken devices, it was long ago possible to activate in-app purchases for free. The solution to the problem is also not new, it is described in the Apple documentation, but no one bothered with the practical implementation. My version of such protection will be discussed below.
How in-app purchases work
There are two possible scenarios. Simple:
The device activates the purchase through the apple server without additional validation and participation of the developer's server.
Complex:
The developer's server can participate in the purchase process as follows:
- sends a list of possible purchases (step 2),
- validates the pokey check (steps 10-11),
- provides access to some additional content (steps 13-14).
We are interested in steps 10-11, because it is on them that we can help the device determine whether the check was written out by the apple server or is it a fake.
Here it must be added that the sources from the Apple article can help with validating the check directly from the application, but this protection is not reliable, because no one bothers to redirect requests to the validating server to the address of the crackers server, which will return the expected response.
Validation
We can only validate a purchase receipt on an Apple server. To do this, send JSON with a check encoded in base64, inside the HTTP POST request: To one of the Apple servers:
{
"receipt-data" : "(receipt bytes here)"
}
- sandbox.itunes.apple.com/verifyReceipt - for test purchases from sandbox
- buy.itunes.apple.com/verifyReceipt - for purchases from the AppStore.
In response, the server will return the validation status, and if validation is successful, the decoded fields of the check:
{
"status" : 0,
"receipt" : { (receipt here) }
}
From theory to practice
Understanding the mechanics described above, it was not difficult to write a proxy application in ruby, which forwards validation requests to one of the Apple servers. I posted the application code on GitHub ready to use . I will be glad to improve and pull-requests. You can also touch it on heroku: https://receiptValidator.heroku.com/validate using the test check from the repository. With the checkbox sandbox you can see the correct answer, and without it, the error code.
In the application, we analyze the response of our server and decide whether to activate the built-in functions, or is it a suspicious check and can be ignored. If interested, in the next article I will write about protection inside the application.
Dry result
- Validation of purchases through your server makes the application “special” and universal crackers stop working.
- Hacking the application is still possible, but for this it is necessary to break our application.
- If someone spends time and hacks purchases - you can add additional encryption in communication with our server.
- For free on heroku we get convenient ruby hosting and https encryption.
PS A bit of unscrupulous self-PR: this protection was written specifically for Galileo Offline Maps and was successfully tested in version 2.2, which appeared in the AppStore yesterday morning.