Matthew Stevens, Ruotger Skupin, Apple, Dave Carlton, Fraser Hess, anlumo, yene, David Keegan.
At the end of October 2010 Apple announced the App Store for Mac. The App Store will put a receipt into your app bundle, but won't implement any copy protection scheme. For details see Validating App Store Receipts (Developer membership needed)
Unfortunately this document doesn't tell you how to process this receipt in detail, quote:
The payload of the PKCS7 container is encoded using ASN.1, as described by ITU-T X.690.
This validator parses and validates the payload and the PKCS7 container itself.
Thanks to Matthew Stevens for coming up with the parser code. Thanks to Dave Carlton for polishing it a bit. Thanks to Fraser Hess for more polish and correcting my non-native English. Thanks to anlumo for the certificate checking code.
Missing from this project:
- Apple's example receipt. (I WON'T ADD IT HERE, APPLE WON'T LIKE THAT, SO DON'T ASK!)
- Any measures to make your app cracker proof.
If you have an app that is more or less ready for the App Store, I think you will be able figure it out. Important is that you link with the dependencies listed in validatereceipt.m.
There are two branches to this repository, master and production, these make it easier to use the same repository for developing as well as for sharing the code as a Git submodule.
The master Branch
The master branch contains the class files as well as the Xcode project for developing/testing/demonstrating the code. This is the branch to use to for further development, as well as to see examples of how to use the specific code.
The production Branch
The production branch should be used if you want to add these extensions as a Git submodule in other projects and will only contain the class files themselves without the Xcode project or example classes. This is preferable as it will keep your directories clean of any code which is unnecessary to your working project, of course you can switch branches in the submodule to access the given samples. Do not perform any development on this branch.
Changes made to the master branch will be merged across to production, so it will always remain current with respect to master.
To add the production branch rather than master, simply use the -b flag as shown below.
git submodule add -b production https://Abizern@github.com/Abizern/ValidateStoreReceipt.git
To keep up to date with the latest changes
cd into the directory that contains this submodule and pull the newest changes as usual
git pull origin
Sometimes, there may be artefacts left over when switching from master to production. These are files that are ignored by Git and are easily cleaned up by running
git clean -dxf
Be aware that there will be people trying to crack your app. So cover your tracks. I won't go into details but Blocks and Grand Central Dispatch seem to be good tools for that.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
Neither the name of the copyright holders nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.