Cocoa Programming for Mac OS X - Aaron Hillegass [140]
When purchased from the Mac App Store, an application is downloaded to the user’s system. A file containing the application receipt will be placed in the application bundle. The receipt contains the application’s bundle identifier, its version string, and a hash of the computer’s GUID. Receipts are cryptographically signed by Apple.
By verifying the information in this receipt, your application can determine whether it is authorized to run on this system. The verification steps are:
1. Verify that the receipt is present.
2. Verify that the receipt is properly signed by Apple.
3. Verify that the bundle identifier in the receipt matches.
4. Verify that the version identifier matches.
5. Verify that the hash contained in the receipt matches this computer’s GUID hash.
A few notes: although the bundle and version identifiers can be obtained from the Info.plistfile (CFBundleIdentifier and CFBundleShortVersionString keys, respectively), it is strongly recommended that these values be duplicated as constants within the application itself. The reason is that the application’s Info.plistfile is easily modified by users; by trusting this information, the application could be tricked into accepting a valid receipt for another application on that system.
If validation fails, the application should terminate with a status of 173:
if (!validated)
exit(173);
This instructs the system that validation has failed for this application.
The code for performing this verification process is, frankly, unpleasant for most developers. Low-level C programmers will feel right at home, although working with cryptographic APIs can be daunting to most developers. You may be asking, “Why doesn’t Apple provide a reference implementation?”
The reason is that if Apple did provide a reference implementation, the vast majority of developers would use it, and a cracking tool could then be used to disarm the protection in all applications that use this code. By asking developers to concoct their own methods for verifying this information, the problem of cracking copy protection is made more difficult.
Apple has provided code snippets for performing parts of this process, as well as a sample receipt for testing purposes. This is an excellent use of build configurations: Use the debug build configuration, or create a new one that directs your code to use the sample receipt for its validation process.
The aforementioned code snippets can be found in the Mac OS X Developer Library article “Validating App Store Receipts.” Be creative in your receipt validation, and remember to use varying patterns between your applications.
Chapter 38. The End
When we teach a class, it always ends with the “Feel-Good Talk,” which delivers the following messages:
• The knowledge you have received from this experience never comes easy. You have learned a lot of stuff. Be proud.
• The only way to solidify what you have learned is to write applications. The sooner you start, the easier it will be.
• There is still much more to learn, but you have crossed the hump in the learning curve. Matters will be easier from here. Once again, the only way to progress is to write applications.
• As a speaker, Aaron is available for weddings, parties, bar mitzvahs, and other events. We also offer five- and seven-day classes at the Big Nerd Ranch. For a schedule, please see the Big Nerd Ranch Web site (www.bignerdranch.com/). Or use the RanchForecast exercise.
The final part of the “Feel-Good Talk” is a listing of resources that will help answer your questions as they arise. As with any programming topic, your answers will be found in a hodgepodge of online documentation, Web sites, and mailing lists.
• If you have a question about Cocoa, the first place to check is in the reference documentation. All the classes, protocols, functions, and constants are listed there.
• If you have a question about Objective-C, the first place to check is in the online Objective-C reference documentation.
• If you have