What is Receigen ?
Receigen is a code generator that is able to generate App Store receipt validation code for both OS X and iOS.
What is an App Store receipt validation ? Why is it needed ?
Basically, an App Store receipt is what an application must check to ensure that the copy is genuine and can be run. Apple provides a good introduction about receipt validation for OS X and for iOS.
What happens if I don't check the App Store receipt ?
Well, anybody with a copy of your application can run it, with or without proper authorization. On OS X, this happened to some developers in when the Mac App Store was launched.
Why should I use Receigen ?
Because, as an application developer, you should be freed from dealing with receipt validation code. Receigen takes care of this part so you can focus on what is really important for you: your application.
I already have receipt validation code built into my application. Why would I use Receigen ?
As said above, Receigen not only frees you from dealing with receipt validation code, but it ensures that the code changes between each generation. Every time Receigen generates code, the constants and the strings are re-obfuscated, the checks are performed differently, and the code flow changes.
How do I use Receigen ?
Receigen can either be used through a user interface interface or the Command Line. Check the guides for examples.
Does generated code depend on OpenSSL ?
Yes, the generated code does depend on OpenSSL being statically linked; a guide explains why and how to use it.
Is there any attribution to declare for the generated code ?
The generated code does not need any special attribution. You can use in your application at your sole discretion.
Is there any attribution to declare for the OpenSSL 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 (firstname.lastname@example.org).
When compiling the validation code, I get an error "Unknown type name '_STACK'; did you mean 'STACK’?". What is wrong ?
Starting with Receigen 3.0.0, the validation code requires a recent version of OpenSSL (version 1.0.0+). This error indicates that you are trying to link with a pre-1.0.0 version of OpenSSL. Check the OpenSSL Guide to properly configure your Xcode project.
I have upgrade to Receigen 3.0.0 and my Xcode integration does not work anymore. What can I do ?
Starting with Receigen 3.0.0, the command line interface has been heavily changed. Check the Command Line usage and Xcode integration guides for a complete example of integration.
I want to generated integrate Receigen with Xcode. How do I proceed ?
Check the Xcode integration guide for a complete example of integration.
What is the supported versions of OS X ?
The generated code can be used in applications that target OS X 10.6 and later. Prior versions of OS X are not supported.
What is the supported versions of iOS ?
The generated code can be used in applications that target iOS 4.3 and later, but only to validate iOS 7 receipts (iOS 7 is required because the validation code uses the SKReceiptRefreshRequest class).
Can I debug the code that Receigen has generated ?
Yes. Receigen produces a human-readable source code (well sort-of), that can be debugged. It also contains logs (in DEBUG mode) and comments if you are curious about what the code does.
Is the code generated by Receigen compatible with ARC (Automatic Reference Counting) ?
Yes, the generated code is fully compatible with ARC. The code adapts itself to your preference.
Is it possible to check receipt during my application lifetime ?
Yes, it is possible. You have numerous options to customize the generate code.
How do I test the receipt validation ?
Check the testing guide to learn about testing the validation.
How do I diagnose the receipt validation ?
Check the diagnostic guide to help you.
When I submit my application to Apple, what are the answers to provide regarding encryption ?
The code generated by Receigen qualifies for the exemptions provided in Category 5 part 2 of the Export Administration Regulations (See the Bureau of Industry and Security website, how to Identifying Encryption Items and their F.A.Q.), mainly because the code only uses cryptography to assert digital rights (proof of purchase and ownership); no encryption ever occurs in the code. In addition, cryptography functions are neither usable nor modifiable by the end-user. When you submit an application to Apple, here are the answers to provide under Export Compliance (note that they are related to the code generated by Receigen):
- Have you added or made changes to encryption features since you last uploaded a binary for this product ? If this is first time you include the code generated by Receigen, the answer is YES.
- Is your product designed to use cryptography or does it contain or incorporate cryptography ? The answer is YES.
- Does your product qualify for any of the exemptions provided in Category 5 part 2 ? The answer is YES.
Do I need to understand receipt validation to use Receigen ?
No, it is not needed to use Receigen. But it is recommended if you want to understand what the generated code does.
Do I need to understand cryptography to use Receigen ?
No, it is not needed to use Receigen. It is only required if you want to understand what the generated code does.
How Receigen obfuscate the code ?
Receigen uses several mechanisms like strings obfuscation (the strings are encrypted), constants computation (the values are computed instead of using constant), de-referenced function calls (the call site are shifted), non predictable branching (by tricking the compiler so it does not optimize the code flow), and inlining (intermediate functions are merged together) so the resulting binary code can be hardly reverse-engineered.
Is the generated code really secure/hacker-proof/unbreakable ?
Receigen provides non-obvious code that performs the validation required by Apple. Even with the various tricks used by Receigen, the generated is not guaranteed to be unbreakable. So a good way to burden a hacker is to spread several checks in your application, so the time spent to crack increases and may discourage script-kiddies.
How can I check that the code is obfuscated ?
First, you need to build your application in Release configuration.
Then, by using otool, strings and nm tools (or applications like Hopper Disassembler), you can browse the resulting assembly code or search for constant strings.
You will not see any constant of recognizable function calls; even the main entry point
NSApplicationMain is hidden.