The receipt validation code normally depends on OpenSSL 1.0 and higher. Plus, the code needs to be statically or dynamically linked. This guide describes how to prepare a Xcode project to use the OpenSSL static library.
The use of OpenSSL when linking statically requires to include these sentences in your application (in the
Credits.rtf file for example):
This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/). This product includes cryptographic software written by Eric Young (email@example.com).
One particular aspect of the OpenSSL project, is that the binaries are not distributed; only the sources are available.
So far, you have the following options:
- Use the Cocoa pods: execute the command
pod OpenSSL-LET(check out the CocoaPods website for more options). This is the preferred way as it makes the setup easier.
- Use the MacPort project: execute the command
sudo port install OpenSSL.
- Download a pre-built package.
If you don’t have the time or the resources to build OpenSSL by your own, here is the latest builds of the OpenSSL libraries. The distribution includes the header files and the
libssl static libraries, build as universal binaries:
- with the i386, x86_64 architectures for OS X
- wtth the i386, x86_64, armv7, armv7s and arm64 architectures for iOS
- OpenSSL 1.0.1u for OSX (SHA1: 2bf2f11958419ac9212ee25453eee5eec25a52e1)
- OpenSSL 1.0.1u for iOS (SHA1: 51df1b2d7dcdde9363ca3e30bfdbfb5954750ee7)
- OpenSSL 1.0.2q for OSX (SHA1: af0d7416f03f4b216ec5db6b3c69814987c32fac)
- OpenSSL 1.0.2q for iOS (SHA1: 337638c6697e2e42f69e9b91861d467f16bc4b0a)
- OpenSSL 1.1.0j for OSX (SHA1: 4d2d6c91354d2b95def9169dd5e278b402016039)
- OpenSSL 1.1.0j for iOS (SHA1: 7c13a6b0adf437f37c5cda8af2abda94c0d19880)
If you have downloaded a pre-built package, you need to configure your Xcode project in order to have access to the OpenSSL headers/libraries.
We assume that the pre-built package has been uncompressed in the
The folder should contains an
include folder and a
- Click on the project
- Select the application’s target
- Select the Build Settings tab
- Select the All and Combined filters.
- Add the following values:
/Users/Guest/Projects/openssl/includeto Header Search Paths
/Users/Guest/Projects/openssl/libto Library Search Paths
-lcryptoto Other Linker Flags
Specific configuration for Swift
If you are using the Swift generated code, you also need to use a bridging header to import the OpenSSL types and functions. Once the bridging header is created, insert the following in it:
// // Receigen imports // #import <CommonCrypto/CommonDigest.h> #import <openssl/asn1.h> #import <openssl/pem.h> #import <openssl/pkcs7.h> #import <openssl/sha.h> #import <openssl/x509.h>
Why OpenSSL ?
From the beginning, Receigen has always used up-to-date code and functions and carefully avoided deprecated APIs, in order to stay fully functional across system upgrades. As the system-bundled OpenSSL shared library is deprecated (since OS X 10.7), Receigen was using the Security framework functions for the receipt parsing and for the cryptographic operations. Unfortunately, using the Security framework has lead to a serie of exploits by offering a way to attack validation code; long story short, the Security framework symbols are vulnerable to runtime injection/swap/swizzling. An attacker can make the application load a shared libraries that will replace some symbols and bypass the various validation checks. In order to prevent this kind of attacks, Receigen is now using a statically linked OpenSSL library for all its cryptographic operations.
Another major reason to switch to OpenSSL was that iOS does not offer enough API to parse and verify the receipt. OpenSSL is therefore the best candidate to provide a robust and cross-platform receipt validation code.